1. 마스터 노드

• kubectl
  1. 쿠버네티스 클러스터에 명령을 내리는 역할 (다른 구성요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없다.)
  2. api 서버와 주로 통신
  
  
• API 서버
  1. 쿠버네티스 클러스터의 중심 역할을 하는 통로
  2. 주로 상태 값을 저장하는 etcd와 통신하지만 다른 요소들도 api 서버와 통신하므로 역할이 중요
     
     
• etcd
  1. 구성 요소들의 상태 값이 모두 저장되는 곳(etcd외의 다른 구성요소는 상태 값을 관리하지 않음)
  2. etcd의 정보만 백업돼 있다면 장애 상황에서도 쿠버네티스 클러스터를 복구 할 수 있다.
  3. 분산 저장이 가능한 key-value 저장소이므로 복제해 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나더라도 시스템의 가용성 확보 가능
     
     
• 컨트롤러 매니저

  1. 쿠버네티스 클러스터의 오브젝트 상태를 관리

  2. ex) 1. 워커노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어짐

     ex) 2. 레플리카셋 컨트롤러는 레플리카셋에 요청받은 파드 개수대로 파드를 생성

     ex) 3. 서비스와 파드를 연결하는 역할을 하는 엔드포인트 컨트트롤러 매니저

• 스케줄러
  1. 노드의 상태와 자원, 레이블, 요구 조건등을 고려해 파드를 어떤 워커 노드에 생성할 것인가를 결정하고 할당하는 역할
  
  

2. 워커 노드

• kubelet
  1. 파드의 구성 내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링
  
  

• 컨테이너 런타임(CRI)
  1. 파드를 이루는 컨테이너의 실행을 담당.
  2. 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스
  
  

• 파드(Pod)

  1. 1개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위
  2. 가상 머신은 언제라도 죽을 수 있다고 가정하고 디자인 하지 않지만 파드는 언제라도 죽을 수 있다고 가정하고 설계

3. 선택 가능한 구성 요소

• 네트워크 플러그인
  1. 쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성해야 한다.
  2. 네트워크 플러그인은 일반적으로 CNI로 구성하는데 캘리코,프래널,실리움,큐브 라우터,로마나 등이 있다.

• CoreDNS

  1. 빠르고 유연한 DNS서버

  2. 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는데 사용한다.

  3. IP보다 도메인 네임을 편리하게 관리해주는 CoreDNS를 사용하는 것이 일반적

     파드 배포 순서(쿠버네티스의 기본 철학)