일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- event loop
- asyncio
- github
- Service
- EC2
- ansible
- ebs
- Deployment
- intervals
- K8S
- terraform
- kernel
- Python
- dockerfile
- Django
- IAC
- elasticsearch
- POD
- IAM
- leetcode
- FastAPI
- 쿠버네티스
- 자바스크립트
- Kubernetes
- docker
- AWS
- YAML
- WSGI
- asgi
- EKS
- Today
- Total
궁금한게 많은 개발자 노트
[ k8s ] 쿠버네티스 네트워크 플로우 본문
[ 쿠버네티스의 아키텍처 ]
쿠버네티스는 크게 전체 클러스터를 관리하는 Control Plane과 실제 컨테이너들이 Pod단위로 실행되는 Worker Node로 구분될 수 있습니다. Control Plane은 Master Node라고도 불립니다. Node에는 컨테이너의 런타임 실행 환경을 제공하는 Docker Engine이 기본값으로 올라가 있으며, 이를 통해 실제 컨테이너가 배포되어 실행됩니다. 각 Worker Node들은 아래 그림에서 보이듯 자체 API를 통해 Control Plane과 통신하며 관제되며 시스템을 운영합니다.
Control Plane과 Worker Node에 설치되는 구성요소에 대해서 알아보자. 위에서 볼 수 있듯 Worker Node에는 Control Plane의 API 요청을 수신하는 Agent역할을 하는 kubelet과 컨테이너의 네트워킹을 제공하는 kube-proxy로 구성됩니다. 특히 kubelet은 수신받은 API 요청에 따라 컨테이너 엔진(보통 Docker Engine)을 통해 컨테이너의 Life-Cycle을 관리하기 때문에 Node에 설치된 컨테이너 엔진을 직접 제어하는 Agent라고 할 수 있습니다.
kubelet: container가 pod에서 수행되는 것을 보장하며, 실행하려는 Container의 제공된 PodSpec에 따라 동작하는 것을 보장합니다. 쿠버네티스에 의해 실행되지 않은 container들은 관리하지 X
kubeproxy: cluster내부의 각 노드의 network proxy. node에서의 network rule을 관리하며, node안의 pod사이의 network 통신을 가능하게 합니다. kube-proxy는 OS packet filtering layer가 존재하고 사용할 수 있으면 그것을 사용하고, 그렇지 않으면 트래픽 자체를 전달합니다.
Control Plane의 구성 요소로는 API Server가 모든 쿠버네티스에 대한 요청을 받아들이고, 해당 요청에 대한 유효성을 검사하고 요청 받은 정보를 etcd에 저장합니다. etcd는 쿠버네티스의 모든 리소스의 설정 및 상태 정보가 저장되는 오픈소스 key-value 저장소입니다. (*etcd는 worker node들에 대한 상태 정보, H/W resource, node의 docker container의 상태 정보, 이미지 정보 저장. worker node의 daemon인 kubelet이 실행되면서 cadvisor라는 컨테이너 모니터링 툴을 포함. cadvisor가 컨테이너 정보를 control plane에 전달하고 이 내용을 etcd에 저장합니다.)
또한 컨테이너를 어떤 Node에 배치하여 Pod로 실행시킬지 결정하는 스케쥴러인 sched (etcd에서 받은 정보를 바탕으로 적절한 node 선택), 전체 쿠버네티스의 컨테이너를 제어하는 controller-manager(=c-m) (Pod의 개수를 보장), 외부 클라우스 서비스 제공 업체의 API와 연동하여 쿠버네티스의 구성요소들과 상호작용 할 수 있도록 도와주는 cloud controller manager(=c-c-m)이 있으며 각 구성 요소들은 API를 통해 외부 Node들과 통신합니다.
[ 쿠버네티스의 동작 메커니즘 ]
쿠버네티스의 관리자는 kubectl이라는 쿠버네티스 클러스터를 관리하고 제어하기 위한 CLI도구를 가지고 Control Plane의 API서버를 통해 전체 클러스터를 관장합니다. 여기서 API는서버는 Control Plane과 Worker Node에 속한 모든 구성요소들로부터 리소스 정보를 전달받고 이를 etcd에 저장합니다. 관리자 뿐만 아니라 다른 구성요소들돌 API를 통해서 etcd에 저장된 리소스 정보에 접근할 수 있습니다.
kubectl은 Kubernetes API 서버와 통신하여 클러스터 내의 리소스를 관리하고 제어하는 역할을 합니다. 이를 통해 개발자와 시스템 관리자는 컨테이너화된 애플리케이션을 배포하고 스케일링, 로그 확인, 디버깅, 리소스 관리, 서비스 디스커버리 등 다양한 작업을 수행할 수 있습니다.
예를 들어 scheduler는 API서버를 통해 etcd에 접근하여 서비스에 필요한 리소스를 Node에 할당할 수 있고, c-m은 컨테이너 배포단위인 Pod의 리소스를 할당/추가/삭제 등 제어가 가능합니다. 뿐만 아니라 kubelet은 정기적으로 Node에 속한 컨테이너/파드의 상태 정보들을 API서버를 통해 etcd에 저장합니다.
쿠버네티스에서 각 Node는 컨테이너 엔진(보통 Docker Engine)을 탑재하고 있으며 해당 환경에서 배포, 관리되는 컨테이너들은 Pod라는 단위로 묶여 보통 한개 이상의 컨테이너로 구성됩니다. 이러한 컨테이너 엔진을 Node에서 직접 제어하는 대상이 kubelet입니다.
보통 kubelet을 API서버에서 Node로 전달된 요청 메시지를 받는 Agent로 정의하지만, 실제 중요한 기능은 kubectl에서 API서버를 통해 전달받은 요청 메시지를 수신받아 컨테이너 엔진을 제어하여 Pod내부의 컨테이너들을 관리하는 것 입니다. 그렇기 때문에 엄밀히 말해서 각 노드의 컨테이너 엔진을 kubelet이 관리한다고 볼 수 있습니다.
그리고 이런 kubelet을 통해 관리되는 Pod들의 네트워킹을 담당하는 것이 kube-proxy입니다. 예를 들어 internet을 통해 Node내부의 컨테이너에 접근하고자 하는 경우, 해당 트래픽을 Node에 있는 Pod내부 컨테이너로 라우팅하고, 해당 컨테이너의 전반적인 네트워크 통신을 관리하는 주체가 바로 kube-proxy입니다.
전체적인 쿠버네티스의 구조는 아래와 같으며, 위에서 설명한 Control Plane과 Worker Node의 역할과 각 Node의 구성요소를 세부적으로 살펴보고 아래 그림을 보면 쿠버네티스 운용에 도움이 될 것 같습니다.
[ 쿠버네티스 실제 운용 구조 팁 ]
- Control Plane의 개수 홀수 단위로 3개 이상 구성을 권장
백업 server로써 2개(짝수)의 Control Plane을 구성하는 경우, 각 Control Plane사이 네트워크 연결이 끊어지는 경우, 각 Control Plane이 관리하는 Cluster 영역이 분리되어 나중에 다시 하나의 Cluster로 복구 되었을 때, 각 Cluster의 리소스 데이터 정보가 서로 일치하지 않거나(정합성), 부정확한 데이터(무결성)로 인해 시스템의 완전한 복구가 불가능 할 수도 있기에 이 같은 Split Brain문제가 발생하지 않도록 홀수개 단위 3개 이상 Control Plane을 구성하는 것을 권장합니다.
- etcd는 Control Plane내부가 아닌 외부에 구축
쿠버네티스의 공식 아키텍처에는 etcd가 Control Plane내부에 존재합니다. 이 경우에는 Control Plane에서 장애가 발생할 경우 etcd까지 같이 중단되어 전체 컨테이너들이 포함된 클러스터가 정상 동작하지 않을 수 있습니다.
Control Plane의 외부에 etcd를 구축하는 경우 하나의 Control Plane에 장애가 발생하더라도 etcd서비스 자체가 중단되지 않기 때문에 다른 Control Plane을 통해 전체 컨테이너 관리가 가능합니다.
External etcd 구조
External etcd형 클러스터는 etcd에서 제공하는 분산 데이터 저장소가 컨트롤 플레인 구성 요소를 실행하는 노드에 의해 형성된 클러스터 외부에 있는 토폴로지이다.
external etcd형 클러스터에서 각 컨트롤 플레인 노드는 kube-apiserver, kube-scheduler, kube-controller-manager 인스턴스를 구동한다. kube-apiserver 는 로드밸런서를 이용하여 워커 노드에 노출된다. 하지만, etcd member는 호스트와 분리되어 구동한다. 각 etcd 호스트는 각 컨트롤 플레인 노드의 kube-apiserver 와 통신한다. 이 토폴로지는 컨트롤 플레인과 etcd member를 분리한다. 그러므로 이 토폴로지는 컨트롤 플레인 인스턴스나 etcd member의 손실은 클러스터 이중화에 미치는 영향이 적으며 High Availability 설정을 제공
전체 쿠버네티스의 구조와 각 컴포넌트의 기능을 살펴보면서, 쿠버네티스 운용 시 참고해야 할 부분에 대해 알아봤습니다.
'DevOps' 카테고리의 다른 글
[ k8s ] Statefulset과 Deployment의 차이점 (0) | 2023.07.20 |
---|---|
[ Dockerfile ] RUN, CMD, ENTRYPOINT 차이점 (0) | 2023.07.19 |
[ Ansible ] Helm Chart 정리 (0) | 2023.06.23 |
[ AWS ] Storage Service (0) | 2023.06.23 |
[ k8s ] StatefulSet 배포 시 복수의 Persistent Volume Dynamic Provisioning (0) | 2023.06.12 |