Kubernetes의 Cluster Architecture에 대해 알아보고 각 구성 요소에 대해 설명한다.
추가로 Pod 생성 과정에 대해서도 설명한다.
다음 그림을 통해 구성 요소들을 살펴볼 수 있다.
Control Plane과 Node로 크게 분리할 수 있다.
Control Plane
kube-apiserver
- k8s cluster의 중심 역할을 하는 통로
- k8s control plane의 프론트엔드
etcd
- k8s의 백엔드 데이터 저장소
- 구성 요소들의 상태 값이 저장되는 곳
kube-scheduler
- node의 상태와 자원, 레이블, 요구 조건 등을 고려해 pod를 어떤 worker node에 생성할 것인지 결정하고 할당
kube- controller-manager
- k8s cluster의 오브젝트 상태 관리
- 여러 컨트롤러 프로세스들을 실행하는 역할
사진 상에 cloud-controller-manager가 존재한다.
이를 사용하면 cluster를 클라우드 제공업체의 API에 연결할 수 있으며, 해당 클라우드 플랫폼과 상호 작용하는 구성 요소와 cluster와만 상호 작용하는 구성 요소를 분리할 수 있다.
클라우드 전용 제어 로직을 내장한 k8s의 control plane 구성요소이다.
그렇기 때문에 온프레미스로 구성을 하면 존재하지 않는다.
Node
kubelet
- cluster의 각 node에서 실행되는 agent
- pod의 생성과 상태 관리 및 복구 등을 담당
- kubelet에 문제가 생기면 pod가 정상적으로 관리되지 않음
kube-proxy (optional)
- node에 대한 네트워크 규칙을 유지
- 클러스터 내부 또는 외부의 네트워크 세션에서 pod로 네트워크 통신 수행
- 즉, pod의 통신을 담당
Contianer Runtime (CRI)
- pod를 이루는 컨테이너의 실행을 담당
- 컨테이너의 실행 및 수명 주기를 관리
- containerd, CRI-O, Kubernetes CRI, Docker ...
Pod
- 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위
ETC.
kubectl
- k8s cluster에 명령을 내리는 역할
- API 서버를 통해 쿠버네티스에 명령을 내린다.
→ API 서버 접속 정보만 있으면 어디서든 쿠버네티스 클러스터에 명령을 내릴 수 있다. - /etc/kubernetes/admin.conf: 쿠버네티스 클러스터의 정보
- 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 구성
- ~/.kube/config 와 같은 것으로, admin.conf를 복사해서 만든 것이 ~/.kube/config 다.
→ kubectl명령줄 도구는 kubeconfig 파일을 사용하여 클러스터를 선택하고 클러스터의 API 서버와 통신하는 데 필요한 정보를 찾는다.
네트워크 플러그인
- CNI로 보통 구성
- Calico, Flannel, Cilium, Kube-router, Romana, WeaveNet, Canal ...
CoreDNS
- 빠르고 유연한 DNS 서버
Master(manager) Node와 Control Plane은 다른가?
master node는 control palne 구성 요소들이 실제로 실행되는 물리적 또는 가상 노드
클러스터 내부 요소들을 제어하는 control plane 역할을 수행하는 것이 master node이다.
즉, control plane이 실행되는 장소이다.
Cluster의 중앙 관리 노드로 control plane의 모든 구성 요소가 master node에서 실행된다.
Life Cycle
- kubectl을 통해 apiserver에 pod 생성 요청
- apiserver는 etcd에 전달된 내용을 모두 기록하고 apiserver로 응답
이를 통해 cluster의 상태값을 최신으로 유지 - apiserver가 controller manager에게 pod 생성 요청
controller manager는 pod를 생성하고 apiserver로 응답
이때 생성된 pod는 node가 할당되지 않은 pod이다. - apiserver는 생성된 pod에 대한 명세를 etcd에 기록
- pod가 생성됐다는 정보를 scheduler가 인지
scheduler는 생성된 pod를 어떤 worker node에 적용할지 조건을 고려해 결정하고 해당 worker node에 pod를 띄우도록 apiserver로 응답 - apiserver는 scheduler에 의해 배치된 node 정보를 etcd에 기록
- apiserver가 kubelet에 pod 할당 감시 요청
- kubelet에서 container runtime으로 컨테이너 생성을 요청
- kubelet은 주기적으로 pod의 상태를 apiserver로 전달
참고
https://kubernetes.io/docs/concepts/architecture/
컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커
https://velog.io/@mang7h/k8s-pod-%EC%83%9D%EC%84%B1-%EC%9B%90%EB%A6%AC
'Study > Kubernetes' 카테고리의 다른 글
| [Kubernetes]Deployment 업데이트 전략 (0) | 2024.05.01 |
|---|---|
| [Kubernetes]Elasticsearch, Kibana를 Docker로 띄우기 & Fluentd는 Pod로 띄우기 (0) | 2023.11.04 |