[Udemy CKA - Core Concepts] Kube

 

Kube-API Server

• 쿠버네티스의 주요 관리 구성 요소
• kubectl 명령어를 실행하면 kube-apiserver에 도달
  • Pod 생성 예시
    1. 요청을 인증하고 유효성 검증(Authenticate User, Validate Request)
    2. API 서버는 Node에 할당하지 않고 Pod 객체 생성 후 생성된 사용자 업데이터(Update ETCD)
    3. Kube-scheduler는 지속적으로 API 서버를 모니터하고 Node가 할당되지 않은 Pod를 발견(Scheduler)
    4. API 서버는 해당 정보를 적절한 Worker Node에서 Kubelet에 전달.
    5. Kubelet는 Node에 Pod를 생성하고 Container Runtime Engine에 지시해 앱 이미지를 배포(Kubelet)
    6. 완료되면 Kubelet은 다시 Kube-apiserver에 상태를 업데이트
    7. Kube-apiserver는 이 정보를 ETCD에 업데이트

 

 

Kube Controller Manager

• 쿠버네티스의 다양한 컨트롤러 관리
• Node Controller
  • Kube-apiserver를 통해 Node의 상태를 모니터링
  • Node Monitor Period = 5s
  • Node Monitor Grace Period = 40s (Unreachable 상태로 업데이트)
  • POD Eviction Timeout = 5m (Unreachable 상태 5분 후 Pod 삭제)
• Replication Controller
  • 복제품 세트의 상태를 모니터링
  • 원하는 수의 Pod가 항상 사용 가능하도록 함(Pod가 죽으면 새로운 Pod 생성)

 

 

Kube Scheduler

• Node에 Pod를 스케줄링 한다.
• Pod를 직접 Node에 두는 것이 아니라 어느 곳으로 들어갈지만 결정(실제 할당은 Kubelet)
• 스케줄링 방법
  1. Filter Nodes : 맞지 않는 노드를 걸러낸다. ex) CPU가 10인 Pod인데 CPU가 4인 Node들은 후보에서 제외
  2. Rank Nodes : 우선순위 함수를 이용해 0~10점까지의 점수를 매김 (기준을 커스터마이징 가능)

 

 

Kubelet

• Worker Node의 선장(모든 활동 처리)
• Master의 유일한 연락망
• Register Node : 쿠버네티스 클러스터로 Node를 등록
• Create Pods : Container Runtime Engine에 요청하여 필요한 이미지를 다운로드해 인스턴스를 실행
• Monitor Node & Pods : Pod의 상태와 컨테이너를 계속 모니터링 + Kube-apiserver에 보고
• 클러스터 배포를 위해 kubeadm을 사용하면 자동으로 kubelet을 배포하지 않는다.

 

 

Kube Proxy

• 모든 Pod는 네트워킹 솔루션을 클러스터에 배포함으로써 다른 Pod와 소통 가능
  • 모든 Pod는 고유한 IP 주소를 가지고 있으며, 이 IP 주소를 통해 클러스터 내의 다른 모든 Pod와 통신 -> 서로 다른 Node에 있어도 네트워크 상에서 서로 소통 가능
  • Pod가 재시작되거나 다시 스케줄링되면 IP 주소가 변경될 수 있으므로 IP 주소가 동일하다는 보장이 없기 때문에 직접 통신 방식은 안정적이지 않음
  • 이 문제를 해결하기 위해 쿠버네티스에서는 서비스라는 추상화(물리적이 아닌 가상의 네트워크)된 네트워크 객체를 사용해, 특정 IP와 포트를 노출시켜 백엔드의 여러 Pod로 트래픽을 전달함. 이를 통해 서비스는 클러스터 내에서 안정적인 접근점을 제공하고 Pod 간의 통신이 안정적이고 일관되게 유지됨
• Kube-proxy
  • 쿠버네티스 클러스터에서 서비스에 접근하기 위한 네트워크 트래픽을 관리하고 라우팅 하는 역할
  • 각 노드에서 실행되는 프로세스로, 서비스가 정의되면 그 서비스와 관련된 네트워크 규칙을 설정하고 트래픽을 전달 ex) iptables