이번엔 쿠버네티스의 기본 개념에 대해 공부한다.
나도 현재 공부중이지만 이해한 내용을 적는다.
쿠버네티스에서 가장 핵짐적인 개념은 desired state
다.
이는 관리자가 추구하는 환경을 유지하기 위해 내부에서 동작한다는 뜻이라고 나는 이해했다.
이러한 개념 덕분에 관리자가 서버를 배포할 때 직접적인 동작을 명령하지 않고 상태를 선언하는 방식을 사용한다.
nginx 컨테이너를 실행하고 80번 포트를 사용한다
=> 명령
nginx 컨테이너를 1개 유지해줘
=> 원하는 상태 선언
쿠버네티스는 상태를 관리하기 위한 대상을 Object로 정의한다.
기본적으로 수십개의 오브젝트를 저공하고 새로운 오브젝트를 추가하더라도 확장성이 좋다. 구 중 주요 Object는 다음과 같다.
쿠버네티스에서 배포할 수 있는 가장 작은 단위
로 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가진다. Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근할 수 있다. 컨테이너를 하나만 사용하는 경우도 반드시 Pod으로 감싸서 관리한다.
Pod을 여러개 복제하여 관리하는 Object이다.
Pod를 생성하고 개수를 유지하려면 반드시 ReplicaSet을 사용해야 한다. ReplicaSet
은 복제할 개수, 개수를 체크할 라벨 선택자, 생성할 Pod의 설정값 등을 가지고 있다.
직접적으로 ReplicaSet을 사용하기 보다는 Deployment등 다른 Object에 의해 사용되는 경우가 많다.
네트워크 관련 Object이다. Pod을 외부 네트워크와 연결해주고 여러 개의 Pod을 바라보는 내부 로드 벨런서를 생성할 때 사용된다. 내부 DNS에 서비스 이름을 도메인으로 등록하기 때문에 Service Discovery 역할도 한다.
저장소와 관련된 Object이다. 호스트 디렉터리를 그대로 사용할 수 있고 EBS같은 스토리지를 동적으로 생성하여 사용할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: busybox
image: busybox:1.25
Object Spec은 YAML파일로 정의하고 오브젝트의 종류와 원하는 상태를 입력한다.
이는 생성, 조회, 삭제로 관리할 수 있기에 REST AOI로 쉽게 노출할 수 있다.
접근 권한 설정도 같은 개념을 적용해 누가 어떤 Object에 어떤 요청을 할 수 있는지 정의할 수 있다.
쿠버네티스 어플리케이션을 배포하기 위해 원하는 상태(desired state)를 다양한 Object에 라벨을 붙여 정의(yaml)하고 API서버에 전달하는 방식으로 사용한다.
"컨테이너를 2개 배포하고 80번 포트를 열어줘"라는 작업을 하기 위해서는
“컨테이너를 Pod으로 감싸고 type=app, app=web이라는 라벨을 달아줘. type=app, app=web이라는 라벨이 달린 Pod이 2개 있는지 체크하고 없으면 Deployment Spec에 정의된 템플릿을 참고해서 Pod을 생성해줘. 그리고 해당 라벨을 가진 Pod을 바라보는 가상의 서비스 IP를 만들고 외부의 80 포트를 방금 만든 서비스 IP랑 연결해줘.”
해당 사이트를 보고 공부했습니다.
https://subicura.com/2019/05/19/kubernetes-basic-1.html