[쿠버네티스 어나더 클래스 (지상편) - Sprint 1] 08. Component 동작으로 이해하기 (강의를 보고)

 

* 본 게시물은쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2강의와 강의 자료를 바탕으로 작성되었습니다.
 

쿠버네티스 컴포넌트 개요

• kubeadm
  Master Node의 yaml 파일을 참고하여 k8s Cluster를 전반적으로 관리하는 요소들을 Pod 형태로 생성하고, 이 요소들의 집합을 Control Plane Component라고 함
• kubectl
  Master Node의 /root/.kube/config 경로에 쿠버네티스 인증서를 가지고 있고 이를 참조해 kube-apiserver에 Pod 생성 명령을 내림.
  생성 요청을 받은 kube-apiserver는 해당 Pod의 정보를 etcd라는 데이터베이스에 저장함
• kubelet
  Container 생성 명령을 내리고, 주기적으로 Container의 상태를 확인함
• Add-on Pod
  쿠버네티스의 기본 기능을 확장시키기 위한 Pod들을 의미
  • metrics-server
  • coredns
  • Calico (CNI)
  • kube-dashboard

 

다른 인스턴스에 필요한 Components를 설치하고 kubeadm을 이용해 Master Node에 join하여 Cluster에 추가할 수 있음

• Worker Node를 만드는 이유?
  
  1. Master Node에 많은 것을 올리면, 사용량이 그 만큼 증가하여 심하면 Master Node가 죽어버려 Cluster 전체가 작동하지 않게 될 수 있음
  2. 때문에, Application에 자원이 필요한 만큼 Worker Node를 만들어 운영하면 트래픽이 분산되기 때문에 안정적

 

Resource

namespace level (resources)

• Controller
  다른 Controller나 Objects를 제어하여 자동화시킬 목적으로 사용

• Object
  하나의 인프라 개념으로써 독립적으로 기능하며 사용 가능

 

cluster level (resources)

• PV

 

기능 별 Components 간의 동작

1. Pod 생성 및 Probe

• Pod 생성
  1. kubectl을 통해 Pod(Deployment) 생성을 요청하면, kube-apiserver가 이 요청을 받아 etcd에 저장
  2. kube-controller-manager는 kube-apiserver를 통해 etcd를 모니터링을 하다가 새로운 Pod(Deployment) 가 확인되면, ReplicaSet을 생성하도록 kube-apiserver에 명령
  3. 다시, etcd에서 ReplicaSet이 확인되면, kube-controller-manager는 해당 Pod(App)를 생성하라는 API를 호출
  4. kube-scheduler는 kube-apiserver를 통해 etcd와 각 Node들에 대한 자원을 모니터링을 하다가 새로운 Pod(App)이 확인되면, 해당 Pod를 띄울 Node를 스케줄링
  5. kubelet은 kube-apiserver를 통해 etcd를 모니터링을 하다가, 자신에게 스케줄링된 새로운 Pod가 확인되면 Container Runtime에 Container 생성을 요청
     • Probe에 정의된 내용대로 kubelet은 주기적으로 해당 Container의 HealthCheck를 함

 

2. Service

nodePort 타입의 Service를 만들고 Pod에 연결을 했을 때,

• kubelet은 kube-proxy에 해당 네트워크 생성 요청
  1. kube-proxy는 iptables에 Service에서 정의된 port로 트래픽이 들어오면 Service로 갈 수 있도록 매핑 룰을 업데이트
     (iptables은 해당 Node로 들어오는 모든 Packets을 관리
  2. 외부에서 API 호출을 통해 접근하려 할 경우, iptables에서 ServerIP:Port는 PodIP:Port로 바뀌게 되고, Calico가 이를 올바른 곳으로 트래픽을 전달해주는 역할을 함

 

3. Secret

• Container 내부의 Secret 파일은 Node의 Memory 영역에 마운팅 됨
  -> 때문에, Secret 파일이 많아지게 되면 Node의 메모리가 부족하게 되는 현상이 발생할 수도 있음
• kubelet이 Secret을 주기적으로 모니터링을 하다가, 변경 사항이 발생하면 Container의 Secret 파일에도 반영
  -> 업데이트에 딜레이가 발생 할 수 있음

 

4. HPA (Horizontal Pod Autoscaling)

• kubelet은 주기적으로 Container Runtime을 통해 Container의 성능을 확인함
  (Container Runtime이 자신이 생성한 Container의 정보를 가지고 있기 때문)
  • 이 때, HPA에 mertrics를 설정하고 Deployment에 연결된 상태라고 하더라도, Container의 현재 성능을 알 방법이 없어 스케일링이 발생하지 않음
  • 때문에, Add-on Pod은 metrics-server를 설치하여 이것이 주기적으로 kubelet에 직접 성능 데이터를 요청하여 자체적으로 저장함
  • kube-controller-manager는 metrics 정보를 kube-apiserver에 요청하면 metrics-server에서 가져와 전달해주면, 현재 metrics 값과 HPA에 정의된 목표 metrics 값을 비교하여 적정 Pod 수를 계산하고 현재 Pod 수와 다를 경우, replicas 필드를 업데이트 하도록 kube-apiserver에 요청하여 etcd에 저장
    -> 업데이트 되면, 앞의 Pod 생성 과정과 똑같이 kube-controller-manager에서 ReplicaSet을 새로 만들도록 함