Section 1,2 : Introduction & Cluster Architecture & Docker vs ContainerD

1. Introduction

객관식이 아니기 때문에 기술이 어떻게 작동하고, 작동하는지 알아야 한다. 공식 문서를 잘 찾는 방법이 중요합니다. 최신 시험은 2시간이 주어지고, 참고자료는 아래와 같습니다.

 

인증된 Kubernetes 관리자: https://www.cncf.io/certification/cka/

시험 커리큘럼(주제): https://github.com/cncf/curriculum

후보자 핸드북: https://www.cncf.io/certification/candidate-handbook

시험 팁: http://training.linuxfoundation.org/go//Important-Tips-CKA-CKAD

 

노트, 문서 링크, 그리고 실습 문제의 답변들이 있는 저장소를 만들었습니다. 과정을 진행하는 동안 이를 꼭 확인할 링크

: https://github.com/kodekloudhub/certified-kubernetes-administrator-course

 

 

2. Cluster Architecture

 쿠버네티스의 목적은 여러분의 응용 프로그램을 컨테이너 형식으로 자동화 된 방식을 통해 호스트하는 것 입니다. 프로그램의 많은 인스턴스를 쉽게 배포할 수 있고 응용 프로그램 내 다양한 서비스 간의 통신이 쉽게 가능합니다.

 

 쿠버네티스를 2가지의 배가 있다고 가정했을 때 컨테이너를 싣고 바다를 건너는 일을 하는 화물선과 화물선을 감시하고 관리하는 관제선이 있습니다. 쿠버네티스 클러스터는 노드들로 구성되는데 물리적, 가상, 온프레미스 또는 클라우드일 수 있고, 컨테이너 형태의 응용 프로그램 호스트 일 수 있습니다. 클러스터의 Worker Nodes는 컨테이너를 로딩할 수 있는 배입니다.

 

 하지만 누군가는 선박에 컨테이너를 적재해야 합니다. 적재만 하는것이 아니라 어떻게 적재할지 계획, 선박을 식별하고 그에 맞는 정보를 저장하며 선박에 실린 컨테이너의 위치를 감시, 추적하여 전적인 적재 과정을 관리하는 일을 해야 합니다. 이를 Master Nodes가 해줍니다.

 

 Master Nodes는 쿠버네티스 클러스터를 관리하고, 노드에 대한 정보를 저장, 어떤 컨테이너가 어디로 갈지 계획하고 노드와 컨테이너를 모니터링 하는 등등 책임을 집니다.

 

 어떤 컨테이너(정보)가 어느 배에 있고, 언제 적재되는지 저장되는 이를 ETCD 클러스터에 저장됩니다. 키 값 형식으로 정보를 저장하는 데이터베이스 입니다. 배(Worker Nodes)가 관제선(Master Nodes)로 도착하면 크레인으로 컨테이너를 옮깁니다. 관제선, 선박에 실어야 할 컨테이너를 식별하는데, 선박의 크기와 적재 용량 선박에 실린 컨테이너 수 기타 조건을 기준으로 선박의 목적지와 실을 수 있는 컨테이너의 종류 등을 결정합니다. 이 역할을 하는 것이 kube-scheduler입니다.

 

 일정 관리자(kube-scheduler)는 컨테이너를 설치하기 위해 올바른 노드를 식별합니다. 컨테이너 리소스 요구 사항이나 Worker Node 용량 혹은 다른 정책이나 제약 조건들 등에 근거해서요.

 

선박(Master Node)에는 각각의 역할에 따라 구분되어 있습니다.

1. Node-Controller

: 노드를 관리합니다. 새로운 노드를 클러스터에 온보딩하고 노드가 사용 불가능하거나 파괴되는 상황을 처리합니다.

2. Controller-Manager

3. Replication-Controller

: 원하는 컨테이너 수가 복제 그룹에서 항상 실행되도록 보장합니다.

 

 이렇게 Master에는 각기 다른 사무실을 가지고 있는데 어떻게 서로 소통할까요? 이는 kube-apiserver 때문입니다. 쿠버네티스의 주요 관리 구성 요소이며 클러스터 내에서 모든 작업을 오케스트레이션합니다. 쿠버네티스 API를 공유합니다. 클러스터에서 관리 작업을 수행하는데 외부 사용자가 사용하는 것 입니다. 클러스터의 상태를 모니터링하는 다양한 컨트롤러에도요. 요구에 따라 필요한 변경을 합니다.

 

 그리고 Worker node에 의해 서버와 통신합니다. 우리는 여기서 컨테이너로 작업하고 있습니다. 컨테이너는 어디에나 있고, 모든 게 컨테이너와 맞아야 합니다. 그래서 이 컨테이너를 실행할 소프트웨어가 필요한데 그것이 Container-Runtime-Engine입니다. 인기 있는 것이 Docker 입니다. 클러스터 내 모든 노드에 설치돼 있습니다. 마스터 노드를 포함해서요. 컨트롤 구성 요소를 컨테이너로 호스트하고 싶다면요.

 

 이제 다시 화물선으로 돌아와서, 모든 배에는 선장이 있습니다. 선장은 이 배들의 모든 활동을 관리할 책임이 있는데, 이 선장은 쿠버네티스의 kubelet 입니다. kubelet은 클러스터의 각 노드에서 실행되는 에이전트입니다. kube-api-server의 지시를 듣고 필요한대로 노드에서 컨테이너를 배포하거나 파괴합니다.

 

 kube-api-server는 주기적으로 kubelet으로부터 컨테이너의 상태를 모니터하기 위해 상태 보고서를 받습니다. 선장(kubelet)은 컨테이너를 관리하는 선장이지만 Worker Node에서 실행되는 응용 프로그램은 서로 통신할 수 있어야 했습니다.

 예로 한 노드의 한 컨테이너에서 웹 서버가, 다른 노드에서 DB가 실행됩니다. 웹 서버가 어떻게 다른 DB 서버에 도달할까요? Workers Node간 통신은 또 다른 구성 요소로 kube-proxy입니다. kube-proxy Service는 Worker Nodes에서 실행되는 컨테이너가 서로 연결될 수 있도록 돕습니다. 필수적인 규칙 내에서. 

 

 요약하자면 Master, Worker Nodes 입니다. Master에는 ETCD 노드가 관련 정보를 저장하며, kube-scheduler는 Node의 응용 프로그램이나 컨테이너의 스케줄을 짜는 역할을 합니다. 여러가지 기능에 맞는 컨트롤러가 있고, kube-apiserver가 있으며 클러스터 내에서 모든 작업을 오케스트레이션합니다. 

 

Worker Node에는 kubelet이 kube-apiserver의 지시를 듣고 컨테이너와 kube-proxy를 관리합니다. 클러스터 내부의 서비스 간 통신을 가능하게 합니다.

 

 

3. Docker vs ContainerD

 쿠버네티스는 처음에 Docker만 컨테이너 런타임으로 사용하였습니다. rkt같은 다른 컨테이너 런타임도 추구하고자 CRI (Container Runtime Interface)를 지원하게 되었음. OCI(Open Container Initiative) 이는 imagespec, runtimespec으로 구성되어 있습니다.

 

 imagespec은 어떻게 이미지를 만들어야 하는지 설명한 것. 이미지 빌드 방식에 대한 기준을 정의합니다. 이런 기준으로 어떤 것이든 쿠버네티스와 작업할 수 있는 컨테이너 런타임을 만들 수 있습니다. 그래서 cri 도입으로 OCI 표준을 준수한 다른 컨테이너 런타임을 지원합니다. 

 

 하지만 Docker는 CRI가 나오기 전부터 이용했기 때문에 dockershim이라는 것을 도입했습니다. CRI 밖에서 지속적으로 지원하는 방안으로 채택한 것 입니다. 대부분의 Container Runtime이 작동하는 동안 Docker는 CRI 없이 작동했습니다. Docker는 Container Runtime만 있는 것이 아니라 함께 여러 구성요소로 이루어져 있어 k8s와 충돌을 겪었습니다. 결국 dockershim을 중단, Docker는 더이상 쿠버네티스 Runtime이 아니게 되었습니다.

 

 대신 도커에서 사용하던 Containerd라는 cri는 여전히 지원되며, cri-o와 함께 가장 많이 사용되는 런타임 중 하나가 됨. ContainerD는 CRI 호환이 가능하고, 다른 런타임처럼 쿠버네티스와 직접적으로 작업할 수 있습니다. Containerd는 별도의 런타임과 Docker에게서 분리되었고 쿠버네티스는 도커 엔진을 직접 지원했습니다.  Containerd는 Docker의 일부분이었지마 현재는 독립되었습니다. Docker를 설치할 필요없이 컨테이너를 자체 설치할 수 있습니다. Containerd는 컨테이너 런타임으로서 컨테이너의 관리 및 실행을 담당하는 핵심 컴포넌트입니다.

 

 

1. ctr 명령 유틸리티는 Contained와 함께 제공하고 작동합니다. 디버깅 목적으로 사용되고 기능은 매우 제한적입니다.

 

2. nerdctl 이것도 Containerd에서 온 것이며, 이것은 Docker입니다. ContainerD를 위한 CLI같은 것 입니다. 일반적으로 컨테이너를 만드는 데 사용되고, Docker CLI와 같거나 그 이상의 기능을 지원합니다. Docker CLI와 유사한 사용자 경험을 제공하면서도 Containerd나 다른 백엔드를 사용하여 컨테이너를 관리하는 도구입니다.

 

3. ctrctl 유틸리티도 있으며, 쿠버네티스에서 왔고, 주로 CRI 호환 가능한 런타임과 상호작용하는 데 사용됩니다. Containerd의 플러그인을 관리하는 데 사용되는 CLI 도구로, 보다 고급적인 기능을 다룰 때 유용합니다.