kbpark9898
commented
1 year ago 4.1 쿠버네티스 클러스터의 전체 구조
쿠버네티스 클러스터는 마스터 (cp) 와 worker 노드로 구성되어 있다.
cp 에서는 etc, kube-apiserver, Kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다.
cp는 보통 고가용성을 만족시키고자 서버 3대정도를 구성하여 운영한다. (앞선 스터디의 고가용성 토폴로지 참조) 그리고 이 3대중 2대는 평소에 대기상태이며, 1대가 리더 cp 노드 역할을 맡는다.
일반 worker node에는 kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다.
cp 와 worker 노드간의 통신은 kube-apiserver를 중심으로 이루어진다. 특히 etcd는 kube-apiserver를 통해서만 접근이 가능하다.
Cp 에서는 kubelet이 여러 cp component를 도커 컨테이너로써 감싸 관리하며, etcd는 이 컨테이너 외부에 별도의 프로세스로 존재한다.
4.2 쿠버네티스의 주요 컴포넌트
Control plane 워커 노드와 pods들을 매니징 하는 노드이다. 스케줄링과 같은 클러스터의 전역적인 결정을 담당하며 클러스터의 이벤트를 감지하고 응답한다.
컨트롤 플레인 노드에서 실행되는 컨트롤 플레인 컴포넌트들은 클러스터 내부의 어떤 머신에서든 다 실행될 수 있다. 다만 , 보통은 동일 머신 내부에 컨트롤 플레인 컴포넌트를 모두 실행시키고, 이러한 컨트롤 플레인 노드를 여러개 두어 고가용성을 유지한다. etcd를 별도의 클러스터로 분리하여 호스트하는 고가용성 토폴로지도 존재한다.
- https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/
- 여담이지만, 현재 LICO의 cp node의 롤에는 etcd가 모두 붙어서 내려온다..
-
Control plane components
- Kube-apiserver
- 쿠버네티스 클러스터의 api를 사용할 수 있도록 해주는 컴포넌트. Kube-api를 통해 특정 자원의 조회 명령을 받으면 해당 작업을 수행하고 돌려주는 역할이다.
- Etcd
- 클러스터 데이터를 저장하는 고가용성 key-value 스토어이다.
- Kube-scheduler
- 새롭게 실행할 파드에 알맞는 노드를 탐색하고, 파드를 할당하는 역할을 수행한다.
- Kube-controller-manager
- 쿠버네티스에서 파드들을 관리하는 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트
- cloud-controller-manager
- 쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결하여 관리하는 컴포넌트이다.
- Kube-apiserver
-
worker node component
- kubelet
- control plane의 kube-apiserver와 통신하며pod contatiner의 실행을 관리한다. 단, 파드 내에서도 쿠버네티스에 의해 만들어지지 않은 컨테이너들은 관리하지 않는다.
- kube-proxy
- 클러스터 내부의 별도 가상 테느워크를 설정하고 관리하기 위한 컴포넌트이다. kube-proxy는 이런 가상 네트워크의 동작을 관리한다.
- 컨테이너 런타임
- docker
- kubelet
-
애드온
- DNS
- 여타 애드온들이 절대적으로 요구되지는 않지만, 많은 경우 필요로하기 때문에 모든 cluster는 cluster dns를 갖추어야 한다. Cluster dns에는 쿠버네티스 서비스를 위해 dns레코드를 제공해주는 dns 서버이며, 쿠버네티스에 의해 구동되는 컨테이너는 dns 검색에서 이 dns 서버를 이용하게 된다.
- 웹 UI (대시보드)
- 쿠버네티스 클러스터를 위한 범용 웹 기반 UI를 제공해준다.
- 컨테이너 리소스 모니터링
- 컨테이너 리소스 모니터링 은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
- 클러스터-레벨-로 깅
- 클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
- DNS
4.3 오브젝트와 컨트롤러
쿠버네티스 클러스터는 사용자가 제시한 desired state를 유지하고 작업을 수행하는 object와, 이 object를 관리하는 controller로 나뉜다. Pod, service, volume, namespace 등이 object에 해당하며, 이들을 종합하여 관리할 수 있는 deployment, replicaSet, stateufulSet 등이 존재한다.
이중 namespace는 cluster를 논리적으로 분리하여 사용할 수 있도록 해준다. 보통 하나의 namespace에는 동일한 역할을 수행하는 object들이 묶여있으며, 하나의 클러스터 내에는 다양한 namespace가 존재할 수 있다.
이게 어떤 namespace 들의 모임인지는 필자는 정말 알지 못하겠다. 대체 어떤 클러스터일까???????
만약 특정 클러스터의 기본 namespace를 변경하고자 한다면 충분히 가능하다. 자세한 명령어를 기술하는것은 무의미해 보여 설명하진 않겠다..
kubctx 라는 패키지를 설치하면 kubens 라는 명령어를 통해 쉽게 기본 namespace 변경이 가능하다고 한다.
brew install kubectx
kubeens {namespace name}또한 k8s는 yaml 파일로 지정한 템플릿을 이용해 쉽게 desired state를 전달할 수 있다. 이 yaml file에서 사용할 수 있는 field는 공식 문서를 참조하자.
https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/
DrawingProcess
initmumu
csw1511
4장 쿠버네티스 아키텍처