쿠버네티스 컴포넌트는? (part 2)
지난번에는 쿠버네티스 소개를 했습니다. Part 1은 여기서 확인 해보세요!
이번 시간에는 쿠버네티스의 자세한 컴포넌트, 스펙에 대해서 이야기를 해보시죠.
k8s components
Control Plane Component
- 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트를 감지하고 반응한다.
ex)디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동 - 컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있으나 간결성을 위해 보통 관련 머신에 컨트롤 플레인 컴포넌트만 구동시키고 사용자 컨테이너는 별도로 워커노드에 구동
- In EKS
- 각 Amazon EKS 클러스터 제어 플레인은 단일 테넌트이고 고유하며 자체 Amazon EC2 인스턴스 세트에서 실행
- 클러스터 컨트롤 플레인은 여러 가용 영역에 걸쳐 프로비저닝
- kube-api-server
- k8s 서비스의 api를 노출하는 서버로, 컨트롤 플레인의 프론트 엔드 - etcd
- 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성 고가용성 key-value 저장소
- 만일을 위해 데이터를 백업해두는게 좋음 (관련 이유와 방법) - kube-scheduler
- 노드가 배정되지 않은 새로 생성된 파드를 감지, 실행할 노드를 선택해주는 컨트롤 플레인 컴포넌트 리소스에 대한 개별 및 총체적 요구 사항
> 하드웨어/소프트웨어/정책적 제약
> 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세
> 데이터 지역성 등 - kube-controller-manager
- 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트로 각 분리된 프로세스이지만 복잡성을 낮추기 위해 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행됨
> 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
> 잡 컨트롤러: 일회성 작업을 나타내는 잡 오브젝트를 감시한 다음, 해당 작업을 완료할 때까지 동작하는 파드를 생성
> 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채움 (즉, 서비스와 파드를 연결)
> 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정 과 API 접근 토큰을 생성 - cloud-controller-manager
- 클라우드별 컨트롤 로직을 포함하는 컴포넌트로 이를 통해 클러스터를 클라우드 공급자의 API에 매핑해 연결하고, 클라우드 플랫폼과 상호작용 하는 녀석과, 클러스터와만 상호 작용하는 녀석을 구분할 수 있게 해줌
- 위와 마찬가지로 단일 바이너리로 컴파일.
- 다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.
> 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인
> 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성
> 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제
Node Component
동작 중인 파드를 유지시키고, 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.
- kubelet
- 클러스터의 각 노드 에서 실행되는 에이전트, kubelet은 pod에서 container가 확실하게 동작하게 관리
- 다양한 메커니즘을 통해 제공되는 PodSpeck의 집합을 받아 이 스펙에 따라 파드가 정상 구동 되도록 함 - kube-proxy
- 클러스터의 각 node 에서 실행되는 netwrok proxy로 쿠버네티스의 서비스 개념의 구현부
- kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. - Container Runtime
- 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
- 쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지
원한다.
Addon (주로 eks 관련 Addon 설명)
애드온은 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현.
클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 리소스는 kube-system 네임스페이스에 속한다.
- DNS
- 여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 필요로 하기 때문에 모든 쿠버네티스 클러스터는 클러스터 DNS를 갖추어야만 한다.
- 클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.
- 쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다.
- In eks - coreDNS - VPC CNI
- CNI = Linux 컨테이너에서 네트워크 인터페이스를 구성하기 위한 플러그인을 작성하기 위한 사양 및 라이브러리
- 컨테이너가 뜨고 내려갈때 컨테이너 별로 VPC에 연결 시키기 위해 필요한 플러그인 - kube-proxy (per node)
- EBS CSI driver (per node)
- 클러스터에 Amazon EBS 스토리지를 제공하는 Kubernetes CSI(컨테이너 스토리지 인터페이스) 플러그인
Part 2는 어떠셨나요? 다음 3화(last part)에는 쿠버네티스의 API와 Object를 탐색하여 k8s 시리즈를 마무리하겠습니다! part 3️⃣ coming SOON!