목차
4.1 쿠버네티스 클러스터의 전체 구조
쿠버네티스는 크게 클라이언트를 관리하는 마스터와 실제 컨테이너를 실행시키는 노드 두 종류의 서버로 구성한다.
쿠버네티스 클러스터의 기본 구성
마스터에는 etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다.
컴포넌트 각각이 다른 마스터나 노드 서버에서 별개로 실행되어도 클러스터를 운영하는데 이상은 없다. 그러나 마스터가 서버 1대라면 프로세스 한 묶음을 해당 서버에서 같이 실행하는 것이 일반적인 구성이다.
마스터는 보통 고가용성을 만족하고자 서버 3대 정도 구성해서 운영한다. 리더 마스터 1대, 나머지 2대는 대기한다.
노드에는 kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다. 실제 사용하는 컨테이너 대부분은 노드에서 실행된다.
마스터와 노드의 구성과 통신 구조
4.1.1 마스터, 노드 서버의 컴포넌트 구성
kubelet | 마스터에 있는 도커를 관리. 도커 내에 아래의 관리용 컴포넌트들이 존재. |
API Server | 모든 요청이 이 컴포넌트를 거치며, 클러스터로 온 요청이 유효한지 검증 후 반환. |
Scheduler | 할당 가능한 노드를 선택하여 새로운 파드를 그 안에 실행. |
Kube-Controller Manager | 컨트롤러 각각을 실행하는 컴포넌트. |
Cloud Controller Manager | 클라우드 서비스와 연결. (Azure, AWS, Google Cloud 등) |
etcd | 쿠버네티스 클러스터의 데이터베이스 역할. (키-값 저장소) |
kubelet | 마스터의 apiserver와 통신하면서 파드 내 컨테이너들의 실행을 직접 관리.
(파드 스펙을 이용하여 실행 및 헬스 체크 진행) |
kube-proxy | 클러스터 안 별도의 가상 네트워크. 마스터와는 달리 컨테이너가 아니라 서버 프로세스로 실행할 수 있다.
(비공개 네트워크로, expose 하지 않는 한 외부에서 접속 불가) |
pod | 쿠버네티스가 관리하는 컨테이너의 묶음 단위.
(쿠버네티스는 파드 단위로 쿠버네티스를 관리한다.) |
4.2 쿠버네티스의 주요 컴포넌트
쿠버네티스는 근본적으로 클러스터를 관리하며, 클러스터는 여러 가지 컴포넌트를 포함한다.쿠버네티스의 컴포넌트는 마스터용 컴포넌트, 노드용 컴포넌트, 애드온용 컴포넌트(optional)로 구분한다.
4.2.1 마스터 컴포넌트
마스터용 컴포넌트들은 실제 클러스터 전체를 관리한다.
etcd
•
etcd는 쿠버네티스 클러스터 구성을 유지하는 분산 KVS. 데이터를 Key-Value형으로 관리한다.
•
어떤 노드를 어떻게 배치할지 등의 정보를 갖고 있어서 API Server가 이를 참조한다.
•
쿠버네티스에서는 필요한 모든 데이터를 저장하는 데이터베이스 역할을 한다.
•
서버 하나당 프로세스 1개만 사용할 수 있다. 보통 etcd 자체를 클러스터링한 후 여러 개 마스터 서버에 분산해서 실행하여 안정성을 보장하도록 구성한다.
kube-apiserver
•
쿠버네티스 클러스터로의 요청에 대한 유효성을 검증하여 API를 사용할 수 있도록 하는 컴포넌트.
•
API Server에 액세스 하려면 kubectl 명령을 사용한다. 또 애플리케이션 안에서 API Server를 호출할 수도 있다.
•
수평적으로 확장할 수 있도록 설계했으므로 서버 여러 대에 여러 개 kube-apiserver를 실행할 수 있다.
kube-scheduler
•
스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시하여, 스케줄링을 통해 해당 파드가 실행될 최상의 노드를 찾는다.
•
스케줄링이란 Kubelet이 Pod를 실행할 수 있도록, 파드가 노드에 적합한지 확인하는 과정
•
노드에 파드를 생성하는 것은 Kube Scheduler가 아닌 Kubelet의 일이다. Scheduler는 파드 실행에 적합한 노드를 선택해서 할당해주는 일만 한다!
kube-controller-manager
•
쿠버네티스의 다양한 컨트롤러를 생성하고 관리한다.
•
쿠버네티스 클러스터의 상태를 감시하고 본래 되어야 할 상태를 유지하는 백엔드 컴포넌트.
•
Relicaset 상태를 모니터링하여 set에 설정된 Pod 개수를 유지하는 ReplicaSet Controller, 노드를 모니터링하여 관리하는 Node Controller 등 다양한 컨트롤러를 관리한다.
cloud-controller-manager
•
쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해 관리하는 컴포넌트.
◦
노드 컨트롤러(Node Controller)
◦
라우트 컨트롤러(Route Controller)
◦
서비스 컨트롤러(Service Controller)
◦
볼륨 컨트롤러(Volume Controller)
4.2.2 노드 컴포넌트
노드용 컴포넌트는 쿠버네티스 실행 환경을 관리한다. 대표적으로 각 노드의 파드 실행을 관리하는 것이 있다.
kubelet
•
kublelt은 클러스터 안 모든 노드에서 실행되는 에이전트이다. 파드 컨테이너들의 실행을 직접 관리한다.
•
파드 정의 파일에 따라 컨테이너를 실행하거나 스토리지를 마운트 하는 기능을 갖고 있다.
•
노드의 Status를 정기적으로 감시하는 기능을 갖고 있어 정기적으로 API Server에게 통지한다.
kube-proxy
•
쿠버네티스는 클러스터 안에 별도의 가상 네트워크를 설정하고 관리하며, kube-proxy는 이런 가상 네트워크의 동작을 관리한다.
•
호스트의 네트워크 규칙을 관리하거나 연결을 전달할 수도 있다.
container runtime
•
실제로 컨테이너를 실행시킨다.
•
Docker, containerd, runc 등의 런타임을 지원.
4.2.3 애드온 컴포넌트
애드온은 클러스터 안에서 필요한 기능을 실행하는 파드이다.
네트워킹 애드온
•
클러스터 안에 가상 네트워크를 구성해 사용할 때 kuby-proxy 이외에 네트워킹 애드온을 사용한다.
DNS 애드온
•
클러스터 안에서 동작하는 DNS 서버. 쿠버네티스 서비스에 DNS레코드를 제공한다.
•
쿠버네티스 안에 실행된 컨테이너들은 자동으로 DNS 서버에 등록된다.
대시보드 애드온
•
대시보드는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 문제 해결을 할 수 있도록 해준다.
컨테이너 자원 모니터링
•
클러스터 안에서 실행 중인 컨테이너의 상태를 모니터링하는 애드온
클러스터 로깅
•
클러스터 안 개별 컨테이너의 로그와 쿠버네티스 구성 요소의 로그들을 중앙 화한 로그 수집 시스템에 모아서 보는 애드온
4.3 오브젝트와 컨트롤러
쿠버네티스는 크게 오브젝트와 오브젝트를 관리하는 컨트롤러로 나눈다. 사용자는 템플릿 등으로 쿠버네티스에 자원의 ‘바라는 상태’를 정의하고, 컨트롤러는 바라는 상대와 현재 상태가 일치하도록 오브젝트들을 생성/삭제 한다.
오브젝트 - 파드, 서비스, 볼륨, 네임스페이스 등
컨트롤러 - 레플리카세트, 디플로이먼트, 스테이트풀세트, 데몬세트, 잡 등
4.3.1 네임스페이스
네임스페이스는 쿠버네티스 클러스터 하나를 여러 개 논리적인 단위로 나눠서 사용하는 것이다.
클러스터 안에서 용도에 따라 실행해야 하는 앱을 구분할 때도 네임스페이스를 사용한다. 네임스페이스별로 별도의 쿼터를 설정해서 특정 네임스페이스의 사용량을 제한할 수도 있다.
kubectl get namespaces 명령으로 현재 생성되어 있는 네임스페이스들을 확인할 수 있다.
default, kube-system, kube-public, kube-node-lease 등은 쿠버네티스가 기본으로 생성하는 네임스페이스이다.
•
kubectl로 네임스페이스를 지정해서 사용할 때는 --namespace=kube-system 처럼 네임스페이스를 명시해야한다. 그런데 default 이외의 네임스페이스를 사용할 때 매번 옵션을 입력하는 것은 번거롭다.
•
기본 네임스페이스를 변경하려면 먼저 kubectl config current-context 명령어로 컨텍스트 정보를 확인해야하며, 처음 컨텍스트는 docker-desktop이다.
•
kubectl config get-contexts docker-desktop 으로 컨텍스트의 정보를 확인해보면, NAMESPACE 부분이 비어있다. 이는 기본 네임스페이스가 default라는 뜻이다.
•
이제 kubectl config set-context 컨텍스트이름 --namespace=kube-system 으로 기본 네임스페이스를 kube-system으로 변경한다.
•
다시 kubectl config get-contexts 컨텍스트이름 명령을 실행하면 NAMESPACE 부분이 kube-system으로 변경된 것을 확인할 수 있다.
•
kubectl config view | grep namespace 명령으로 기본 네임스페이스가 제대로 변경되었는지 호가인 가능.
처음 쿠버네티스를 사용하다 보면 어떤 파드의 기본 네임스페이스를 어떻게 설정했는지 헷갈릴 때가 종종 있다. 이때는 kubectl get pods --all-namespaces 명령으로 전체 네임스페이스를 한번에 찾아볼 수 있다.
기본 네임스페이스를 다시 default로 바꿀 때는 kubectl config set-context 컨텍스트이름 --namespace=default 또는 kubectl config set-context 컨텍스트이름 --namespace=""
네임스페이스를 변경할 때, kubens를 사용할 수 있다. brew install kubectx 로 설치 후 사용.
4.3.2 템플릿
쿠버네티스 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야 하는지를 적용할 때는 YAML 형식의 템플릿을 사용한다.
YAML은 ‘Scalars(strings/numbers)’, ‘Sequences(arrays/lists)’, ‘Mappings(hashes/dictionaries)’라는 세 가지 기초 요소로 표현한다. 주석은 ‘#’으로 시작하며, ‘--- ’은 성격이 다른 YAML 형식의 문서 여러 개가 있을 때 구분자로 사용한다. (YAML 파일의 시작을 알리는 용도로 사용하기도 한다.)
템플릿의 기본 형식은 다음과 같다.
---
apiVersion: v1
kind: Pod
metadata:
spec:
YAML
복사
각 항목은 필드라고 하며, 각각은 다음과 같은 설정을 한다.
•
apiVersion : 사용하려는 쿠버네티스 API 버전을 명시한다.
•
kind : 어떤 종류의 오브젝트 혹은 컨트롤러에 작업인지 명시한다.
•
metadata : 메타데이터를 설정한다. 해당 오브젝트의 이름이나 레이블 등을 설정한다.
•
spec : 파드가 어떤 컨테이너를 갖고 실행하며, 어떻게 동작해야 할지 명시한다.
어떤 하위 필드가 있고 어떤 역할을 하는지는 kubectl explain 명령으로 살펴볼 수 있다.
실행 결과에서는 각 필드의 데이터 타입도 확인할 수 있으며, .metadata처럼 데이터 타입이 Objects라면, 다시 kubectl explain pods.metadata 라는 명령을 실행해 .metadata의 하위 필드를 살펴볼 수 있다.
필드 설명 없이 특정 필드와 그 아래에 속한 모든 하위 필드를 한꺼번에 보려면 --recursive 옵션을 사용한다.
