[Kubernetes] 쿠버네티스 Component 동작으로 이해하기

해당 포스팅은 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 내용을 기반으로 작성했습니다.

---

전체 개요

쿠버네티스를 설치할 때 마스터 노드를 만들고 kubeadm, kubectl, kubelet 패키지를 설치한다.

이후 kubeadm 명령어로 클러스터를 생성하는데 이 때 /etc/kubernetes/manifests 경로에 파드를 만들어주는 manifest 파일들이 있어 etcd, kube-controller-manager, kube-scheduler, kube-apiserver, kube-proxy 라는 컴포넌트들을 만들어준다.

이 파드들은 쿠버네티스가 돌아가는데 필요한 역할들을 하고 통틀어서 Control Plane Component라고 한다.

다른 VM으로 여러 대의 워커 노드를 만들고 마스터 노드에 조인하면 워커 노드 컴포넌트 영역이 생긴다.

그러면 이 때 kube-proxy라는 컴포넌트만 추가로 만들어지는데, 이 영역은 사용자가 만든 app을 올리는 영역이다.

마스터 노드에 모든 앱을 올리게되면 부하가 생겨 마스터 노드가 죽는 경우가 발생할 수 있기 때문에 어플리케이션은 워커노드에 올리고 자원이 더 필요한 만큼 워커 노드를 추가하는 방식으로 운영한다.

그리고 대시보드나 metrics-server 같은 쿠버네티스의 기본 기능을 확장시키기 위한 app들을 추가로 설치하는데, 이것들을 addon pod라고 한다. 

 

설치 이후 오브젝트를 생성하게 되면 /root/.kube/config에 쿠버네티스 인증서가 있고, kubectl이 kube-apiserver로 API를 날려서 etcd에 오브젝트들에 관한 데이터를 저장한다. 또한 오브젝트들은 서로 연결관계를 가지고 있는데, 실제로는 Service, Configmap, Secret, Pod, PVC 등을 Object라 하고 HPA, Deployment, ReplicaSet은 Controller라고 한다.

Object는 하나의 인프라 개념으로서 단독 기능을 하고, Controller는 다른 Controller나 Object를 제어하는 기능을 한다.

이 전체를 칭할 때는 Resource라고 하며 이 resource는 또 namespace level과 cluster level로 나눠진다.

 

인프라에는 네트워크나 볼륨, 환경 변수라는 요소들이 있는데 이 요소들을 가상화한 것이 Object이고, 이 Object들을 자동화 시킬 목적으로 Controller라는 개념이 만들어졌다. 전체 Resource들은 Control Plane Component 파드들에 의해 움직인다. 

 

 

각 리소스별 동작

Probe

1. kubectl로 Deployment를 생성하는 명령어를 실행하면 생성 API를 kube-apiserver에 날린다.
2. etcd를 통해서 데이터를 저장시킨다. 그러면 Deployment를 조회할 수 있게 된다.
3. kube-controller-manager는 etcd를 모니터링 하고 있다가 deployment가 조회되면 Replicaset을 생성하라는 API를 날린다.
4. 마찬가지로 생성할 replicaset의 데이터를 etcd에 저장하면 kube-controller-manager가 Pod 생성 API를 날린다. 이 데이터 역시 etcd에 저장된다.
5. kube-scheduler는 노드 자원을 kube-apiserver를 통해 모니터링 하다가 데이터베이스에 파드가 추가된게 확인되면 파드를 띄울 노드를 스케쥴링 해준다.
6. kubelet은 자신의 노드 정보가 있는 파드를 모니터링하고 있다가 이걸 발견하고 container runtime에 컨테이너 생성요청을 한다
7. containerd가 컨테이너를 만들어 준다.
8. probe를 설정했다면 kubelet이 설정에 맞게 주기적으로 컨테이너에 헬스체크 API를 주기적으로 날린다.

Service

1. NodePort 타입으로 서비스를 생성하고 파드에 연결한다.
2. kubelet이 kube-proxy에 network 생성 요청을 한다.
3. kube-proxy는 iptables에 특정 포트와 서비스를 매핑하는 룰을 업데이트 한다.
4. iptables는 리눅스로 들어오는 모든 패킷을 관리하기 때문에 사용자가 API를 날리면 컨테이너로 트래픽을 전달해주는데, 트래픽의 전달은 CNI로 설치했던 Calico가 수행한다

Secret

1. Secret의 자체적인 보안 기능은 크게 체감이 되지 않는다.
2. 컨테이너 내부 파일은 노드의 메모리 영역에 마운트 된다. 메모리 영역은 전원이 꺼질 때 지워지기 때문에 물리적으로 디스크를 변경하는 경우 데이터를 복구할 수 없다.
3. 또한 Secret이 메모리에 저장되기 때문에 시크릿을 엄청 많이 만들게 되면 노드에 메모리가 부족해질 수도 있다. 하지만 거의 그럴일이 없다.
4. 시크릿 데이터를 수정할 때 바로 변경되지는 않고 kubelet이 주기적으로 변경사항을 확인하여 업데이트하기 때문에 약간의 딜레이는 존재한다.

HPA

1. 현재 컨테이너에 대한 자원 사용량은 contained가 알고 있다. kubelet이 cpu와 memory를 10초에 한번 씩 조회하고있다.
2. HPA에 metrics를 설정하고 deployment에 연결하면 pod에 부하가 올라간다해도 아무 일도 일어나지 않는다. metrics-server라는 addon pod를 설치해야한다.
3. metrics-server는 60초 단위로 주기적인 자원 사용량 수집을 해서 저장을 한다.
4. kube-controller-manager가 HPA의 임계값과 metric을 15초 단위로 비교를 하면서 스케일링을 발생시킨다.
5. 따라서 수직구간들의 타이밍이 잘맞는다면 즉시 스케일링을 수행하고, 타이밍이 안좋으면 부하가 발생하고 최대 85초 이후에야 스케일링을 수행하게 될 수 도 있다.