[k8s]쿠버네티스의 구조

Yesol Lee·2023년 2월 23일

데브옵스

목록 보기

3/3

책: 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 3장 컨테이너를 다루는 표준 아키텍처, 쿠버네티스
인프런 강의 : 쉽게 시작하는 쿠버네티스(v1.25) - 쿠버네티스 환경 구성

저자의 github에서 제공하는 Vagrantfile을 다운로드받아 vagrant up으로 마스터노드 1개, 워커노드 3개로 구성된 가상머신 테스트환경을 구축하였다.

사용자가 kubectl을 이용해 API Server와 통신
API Server가 구성요소들의 상태값을 저장하는 etcd에 통신
etcd(엣시디)는 구성요소들의 상태값을 key-value 형태로 저장하고 있다. etcd에 작성된 상태값이 현재 구성요소의 상태값과 다른지를 계속 주시하고 있다가, 다른 점이 발견되면 업데이트 명령을 내린다. API Server에서는 원하는 최종 상태를 etcd에 작성하고, etcd는 작성된 요구사항에 맞게 현재 상태를 업데이트하도록 통신한다.
controller manager가 쿠버네티스 클러스터의 오브젝트 상태를 관리한다. controller manager 하위에 여러 컨트롤러가 있다. 예를 들면 노드 컨트롤러는 노드의 상태체크 및 복구, 레플리카셋 컨트롤러는 레플리카셋에 요청한 파드 개수 대로 파드를 생성한다.
scheduler는 노드의 상태, 자원, 레이블, 요구조건 등을 고려해 생성된 파드를 어떤 노드에 할당할 것인지 결정하고 할당한다.

kubelet : 파드의 구성내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고 파드 안의 컨테이너들이 정상작동하는지 모니터닝한다.
CRI, container Runtime Interface(컨테이너 런타임): 파드를 이루는 컨테이너 실행을 담당한다.
Pod(파드): 단일 목적의 일을 하는 단위. 한 개 이상의 컨테이너로 이루어져 있다. 쿠버네티스에서는 이 파드가 언제라도 죽을 수 있는 오브젝트라는 것을 가정하고, 파드가 죽고 새로 생성되어도 서비스에 문제가 없도록 한다.

Understanding Kubernetes: Part 1-Pods
파드를 생성, 수정, 삭제하는 과정을 가정하고 파드의 생명주기를 정리해보았다.

user가 kubectl을 통해 API Server에 파드 생성을 요청한다.
API Server는 새로운 요청을 받으면 etcd에 접근하여 가장 최신 상태값으로 업데이트한다. 각 요소가 상태를 업데이트할 때 마다 API Server에 변경된 상태를 전달하고, 그걸 etcd에 업데이트하는 것이다.
etcd에 기록된 상태와 현 상태가 다른 것, 즉 새로운 요청이 들어온 것을 컨트롤러 매니저가 인지하면 요청대로 새로운 파드를 생성하고, 생성했다는 내용을 API Server에 전달한다. 이때 아직 어떤 워커 노드에 해당 파드가 할당될지는 결정되지 않았다.
새로운 파드가 생성되었다는 소식을 API Server를 통해 스케줄러가 인지한다. 스케줄러는 해당 파드를 어떤 노드에 할당할지 결정하여 해당 노드에 파드를 띄우도록 요청을 보낸다.
스케줄러가 API Server에 전달된 정보대로 지정한 워커 노드에 파드가 속해있는지 각 노드의 kubelet으로 확인한다.
kubelet에서 컨테이너 런타임으로 파드 생성을 요청한다.
노드에 파드가 생성된다.
파드가 사용 가능한 상태가 된다.

kubectl은 API Server를 통해 쿠버네티스 클러스터에 접근한다. 즉 API Server 접속 정보만 알고 있으면 마스터노드가 아닌 워커노드에서도 kubectl로 명령을 내릴 수 있다.

파드의 생성, 상태관리, 복구 등을 담당하는 중요 요소.
책에서는 > systemctl stop kubelet 명령을 이용해 임의로 kubelet에 문제를 일으킨 뒤 pod의 삭제 등 관리가 제대로 되지 않음을 확인하였다.

파드의 통신을 담당한다. 책에서는 br_netfilter 커널 모듈을 적재하고 iptables를 거쳐 통신하도록 구성되어 있다. 임의로 br_netfilter모듈을 삭제한 후 파드의 nginx 웹서버와 통신이 잘 되지 않음을 확인하였다.

문서화를 좋아하는 개발자