[Kubernetes] 2. 쿠버네티스 Architecture

[주의] 개인 공부를 위해 쓴 글이기 때문에 주관적인 내용은 물론, 쓰여진 정보가 틀린 것일 수도 있습니다!

피드백 부탁드립니다. (- -)(_ _) 꾸벅

 

k8s

---

[Kubernetes 기본 구조]

 

쿠버네티스 하나의 클러스터에는 다음과 같이 기본적으로 이루어져 있다.

 

 

Kubernetes Master (Control Plan Component)

• API Server : 쿠버네티스 control plan의 주 구성요소로, 기본적으로 REST-ful API 방식을 통해 명령을 주고받는다. 그렇기 때문에 API-server를 프런트 앤드로 두고 있다.
• Scheduler : Pod A를 돌리고 싶을 때 어디 Node에 할당할지 각 노드의 상황을 바탕으로 결정하는 스케줄러. 운영체제의 스케줄링을 생각하면 편할 것 같다.
• Controller Manager :  그 안의 상태정보(복제/배포/상태/..)를 종합적으로 관리하는 것.
• etcd : 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소. 예를 들어 어느 노드에 어떤 Pod가 돌고 있나? 같은 상태들을 모두 etcd라는 칠판에 적어놓는 것. 

 

Worker Node (Node Component)

• Kubelet :  클러스터의 각 노드에서 실행되는 에이전트로 자신의 Pod에서 컨테이너가 동작하도록 관리한다. Master의 API-server와 짝이 되어 통신하는 백그라운드에 이어진 놈
• Pod : 쿠버에서 생성하고 배포할 수 있는 가장 작은 컴퓨팅 단위 (하나 이상의 컨테이너 그룹)
• Container Engine : 컨테이너 실행을 담당. (ex. Docker, CRI-O etc...)
• Kube-proxy : 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

 

명령을 내리면? 

Developer가 API로 명령을 내리면, API server를 통해 etcd에 그 명령이 기록되게 된다. 그러면 kubelet이 API 서버를 통해 지속적으로 etcd라는 칠판을 주시하므로 쓰인 정보를 보고 상황에 맞게 행동하는 것. 즉 etcd에 의도하고 싶은 상태를 써놓기만 하면 kubelet들이 쳐다보고 알아서 처리해준다는 뜻이다.

 

 

외부와 상호작용

아키텍처를 좀 더 간략하게 표시하면 위 그림과 같다. API 서버를 kubectl을 통해, 오픈소스 프로젝트 helm이나 GUI(web) 혹은 api로 직접 등등 다양하게 명령을 내릴 수 있다. 

중요하게 생각해 볼 것은 모든 명령이 API server를 통해 내려진다는 것이다. 

 

---

[ Node > Pod > Container ]

쿠버네티스에서 컨테이너가 작동되는 기본자원을 Pod라고 정의한다. 

Docker 등의 컨테이너 엔진으로 생성된 컨테이너들은 Pod안에 묶이게 되는데, 보통은 기본적으로 컨테이너 하나가 존재하여 Network나 Storage 기능을 백그라운드로 수행하게 되고, 나머지 하나는 내 컨테이너 일거리를 돌리게 된다.