[k8s] 쿠버네티스에서 컨테이너 동작 flow

쿠버네티스에서 컨테이너 동작 flow

 

https://ssup2.github.io/theory_analysis/Kubernetes_Architecture/

 

새로운 컨테이너를 실행시키는 flow

1) kube-apiserver는 REST API Server로서 kubectl 커맨드나 yaml로 작성된 파일의 요청을 받고 처리한다. api-server는 우선 etcd에서 worker노드들의 상태 정보를 수집한 뒤 scheduler로 보낸다.

2) scheduler는 api-server로부터 요청을 받고 worker 노드의 상태를 확인한 뒤 어느 노드에 배치시키는 것이 가장 좋을지 결정 후 api-server로 응답한다.

3) api-server가 응답을 받고 해당하는 노드로 컨테이너 배치를 요청한다. 이때 해당 worker노드의 kubelet으로 요청을 보낸다.

4) worker노드의 kubelet이 컨테이너 런타임으로 요청을 보낸다.

5) 컨테이너 런타임은 도커허브나 다른 컨테이너 레지스트리로부터 이미지를 받아와서 실행시킨다.

6) 쿠버네티스에서는 이렇게 동작하는 컨테이너를 Pod라는 단위로 관리한다.

 

 

쿠버네티스 컴포넌트 소개

1. master 컴포넌트 (master node가 1대일 경우로 가정)

1) etcd

- key-value 타입의 저장소이다.

- worker노드들의 상태 정보(HW 리소스의 사용정보, 컨테이너의 동작 상태, 이미지의 상태)를 저장한다.

- worker 노드의 상태를 가고 있을 수 있는 이유는 worker노드에 데몬 형태로 동작 중인 kubelet이 있기 때문이다.

- kubelet에는 cAdvisor라는 컨테이너 모니터링 툴이 포함되며 이를 통해 etcd에 저장할 수 있게 된다.

 

2) kube-apiserver

- client로부터 kubectl 커맨드나 yaml 형태의 요청을 받는다.

- kubectl 커맨드의 요청이 유효한지 검사한다. (문법이나 권한이 적절한지)

 

3) kube-scheduler

- 파드를 실행할 노드를 선택한다. 우선 api-server가 etcd에서 worker노드들의 상태 정보를 가져와 scheduler로 요청하면 scheduler는 해당 데이터를 기반으로 어느 worker노드에 컨테이너를 실행시킬지 결정하고 api-server에게 응답한다.

 

4) kube-controller-manager

- 파드를 관찰하며 개수를 보장한다. 만약 특정 worker 노드가 다운되면 이를 감지하고 해당 노드에서 실행 중이던 컨테이너들을 다시 실행될 수 있도록 api-server로 요청을 보낸다.

 

2. worker 컴포넌트

1) kubelet

- '모든 노드에서 실행되는' k8s 에이전트이다.

- 데몬 형태로 동작한다.

- master의 api-server로부터 요청을 받고 처리한다.

- kubelet에는 cAdvisor라는 컨테이너 모니터링 툴이 포함되어 worker노드의 상태 정보를 모니터링한다. 이 데이터는 master의 etcd에 저장된다.

- kubelet은 컨테이너 런타임에게 컨테이너 실행을 요청한다.

 

2) kube-proxy

- k8s의 network 동작을 관리한다.

- iptables rule을 구성한다.

 

3) 컨테이너 런타임

- 컨테이너를 실행하는 엔진으로 도커허브나 각종 레지스트리(사내 Private 레지스트리도 가능)로부터 이미지를 가져오고 압축을 해제하며 컨테이너로 실행시킨다.

- containerd, CRI-O, runC 등이 포함된다. (https://jh-labs.tistory.com/477)

 

 

* Master에도 컨테이너 런타임, kubelet, kube-proxy가 있을까?

-> yes, 'kubectl get pods -n kube-system -o wide'를 통해 확인 가능. 컨테이너 런타임은 쿠버네티스의 컴포넌트가 아니기 때문에 해당 커맨드로 보이진 않으나 컴포넌트의 일부들이 컨테이너로 동작하기 때문에 컨테이너 런타임도 역시 master에 존재한다.

 

참고
- master에도 kubelet이 들어있지만 이는 worker에서는 kubelet과 목적이 약간 다르다. master의 kubelet은 쿠버네티스 운영환경을 목적으로 하는 kubelet이다.
- apiserver와 같이 pod로 동작하는 컴포넌트들은 scale-up되어 여러 개로 동작될 수 있다.

 

 

cf. add-on 프로그램

- add-on 프로그램은 필요에 따라 추가적으로 설치하는 프로그램이다.

 

1) CNI plugin (네트워크 애드온)

https://www.altoros.com/blog/kubernetes-networking-writing-your-own-simple-cni-plug-in-with-bash/

 

- CNI 플러그인은 새로 생성된 컨테이너에 네트워크 인터페이스를 할당하는 역할을 담당한다.

- 쿠버네티스는 먼저 네트워크 인터페이스 없이 컨테이너를 생성한 다음 CNI 플러그인을 호출한다.

- CNI 플러그인은 컨테이너 네트워킹을 구성하고 할당된 네트워크 인터페이스, IP 주소 등에 대한 정보를 반환한다. 쿠버네티스가 CNI 플러그인에 보내는 '매개변수와 응답 구조'는 CNI Specification을 충족해야 한다.

- pod의 네티워크를 설정할 때 사용한다. master에도 app이 구동된다면 Master에서도 사용해야 한다.

- weave net, calico, flaneld 등 다양한 플러그인이 존재한다.

- 자세한 내용은 쿠버네티스 네트워크 모델을 참고하자.

- 컨테이너 런타임은 CNI 플러그인을 로드하도록 구성해야 한다.

- 쿠버네티스 1.24 이전까지는 kubelet이 CNI 플러그인을 관리하게 할 수도 있었지만 1.24부터는 CNI가 더 이상 kubelet의 관리대상에 포함되지 않는다고 한다.

 

2) DNS 애드온

- DNS 애드온 중에 대표적인 것이 'CoreDNS'이다.

- CoreDNS는 add-on 이긴 하지만 쿠버네티스 설정 시 기본으로 설치된다.

- Pod의 IP는 언제나 바뀔수 있기 때문에 Pod과 통신하기 위해서는 Pod의 IP를 직접 이용하는 것보다는 DNS를 통해서 Pod의 IP를 얻는 방식을 이용하는 것이 좋다. coredns는 Pod안에서 다른 Pod의 IP를 찾을 수 있는 DNS 역할을 수행한다. 이와 유사하게 Kubernetes의 Service IP도 언제든지 바뀔 수 있기 때문에, coredns는 Pod안에서 Service IP를 찾을 수 있는 DNS 역할도 수행한다.

 

 

** 그 외 추가적으로 설치 가능한 애드온

1) 대시보드 애드온

- pod, deployment, etcd 등이 어떤 상태로 동작중인지 GUI로 표현

 

2) 컨테이너 자원 모니터링 애드온

- cAdvisor: kubelet에 기본으로 포함

 

3) 클러스터 로깅 애드온

- 컨테이너 로그, k8s 운영 로그를 수집해서 중앙화

- 여기서 중앙화란 노드들이 여러개로 분산되어 있기 때문에 한 곳에서 볼 수 있도록 하는 것

- ELK, EFK, DataDog 등

 

 

 

Reference

- pod Networking, https://www.altoros.com/blog/kubernetes-networking-writing-your-own-simple-cni-plug-in-with-bash/

- k8s component architecture, https://ssup2.github.io/theory_analysis/Kubernetes_Architecture/