CKA 강의 정리
쿠버네티스의 목적 : 응용 프로그램을 자동화된 방식으로 컨테이너 형태로 호스팅하는 것.
쿠버네티스는 노드 세트로 구성되는데, 가상환경일 수도, 온 프레미스일수도, 클라우드일 수도 있다.
Node 분리
Master Node (감독선)
컨테이너의 위치 감시, 추적, 어떤 것을 컨테이너로 실을지를 감지해야함
노드 정보를 감시하고, 어디 갈지 계획하고, 모니터링 해야함 마스터 노드는 실제로 이 모든 걸 한다.
어느 컨테이너가 어느 배에 있고 몇 시에 적재되었는가? -> 이 모든 정보가 ETCD에 모두 저장된다. key:value 형태의 데이터베이스이다.
배가 도착하면 컨테이너를 감독선에 싣는다. 이 때 크레인으로 싣는다.
크레인은 선박의 크기와 적재 용량 선박에 실린 컨테이너의 수와 기타 조건을 기준으로 실을 수 있는 컨테이너의 종류 등을 결정한다.
이 작업을 수행하는 것이 쿠버네티스 스케쥴러 이다.
감독선에는 단순히 감독선만이 아니라 다양한 사무실이 존재한다.
컨테이너는 화물팀이 감시한다. 컨테이너가 망가지면 새 컨테이너를 준비해둔다. 서비스 사무실이 있고, IT와 함선 간의 통신을 관리해준다. 쿠버네티스에서도 컨트롤러가 있어서 다양한 영역을 감시한다.
- Node-controller
노드를 관리한다. 새 노드를 온보딩하고 사용 불가능해지는 상황을 다룬다. - Replication-Controller
- Controller-Manager
이 사무실들은 어떻게 소통하고, 누가 이 사무실들을 관리해줄까?
이 관리 사무실이 kube-apiserver 이다.
Worker node
모든 워커 노드에도 선장이 있다. 선장은 워커노드 하나에 대한 책임이 있다.
주요 선박들과 연락을 하는 일을 맡아야 하고, masternode에 합류할 의사가 있음을 알려야 한다. 컨테이너를 싣고 싶은 만큼 보고한다. 이를 kubelet 이라 한다.
한 노드의 한 컨테이너에서 웹 서버가 실행되고 다른 노드의 다른 컨테이너에서 데이터베이스 서버가 실행된다. 웹서버가 어떻게 다른 노드의 데이터베이스에 접근할까? 이를 Kube-proxy 라 한다.
어플리케이션은 컨테이너 형태이며, DNS 서비스 네트워킹 솔루션은 컨테이너 형태로 배포될 수 있는데, 이 컨테이너를 실행시킬 도구가 필요하다. 이 컨테이너 실행 도구를 Docker라고하는데, 모든 클러스터 내부의 컴퓨터에 Docker가 설치되어있다.
그런데 굳이 도커이지 않아도 containerD, rkt 등이 있다.
Docker vs ContainerD
Docker와 containerD는 둘 다 많이 보게 될 것이다.
컨테이너가 발명되기 전
Docker가 혜성처럼 떠올랐으며 이를 관리하기에 kubernetes가 발명되었다.
이렇게 밀접한 관계가 있었지만 쿠버네티스는 Docker와만 일했고 다른 컨테이너 솔루션을 지원하지 않았다. 쿠버네티스의 인기가 많아지며 rkt 같은 다른 컨테이너 런타임 도구를 사용하길 원했고, 인터페이스, CRI라는 인터페이스를 소개하게 되었다. OCI 표준을 준수하는 한 모든 컨테이너 런타임을 지원하게 했다. 누구나 쿠버네티스와 작동할 수 있는 런타임을 구성했지만, 도커는 CRI표준을 지키기 위해 만들어진 게 아니었으나, 쿠버네티스는 계속 Docker를 지원해야만 했다.
컨테이너 런타임 바깥에서 Docker를 지원하기 위해 Dockershim을 만들었다.
하지만 Docker는 컨테이너 런타임만 있는 게 아니었다.
도커 CLI, API, 그 밖에 다양한 기능들을 모두 지원이 가능했다. 이 와중에 containerD는 도커와 별도의 런타임으로 쿠버네티스와 호환이 잘 되었고, Dockershim을 지원하기 위한 노력에 많은 노력을 해야했다.
ContainerD
Docker를 설치할 필요 없이 쿠버네티스 클러스터 내부에서 컨테이너를 구성할 수 있다.
nerdctl은 Docker가 실행하는 대부분의 옵션을 지원하고, 컨테이너에 구현된 최신 기능에 액세스 가능하다. Docker와 비슷한 명령어 다 실행 가능
docker run --name redis redis:alpinenerdctl run --name redis redis:alpine이런 식으로 가능
crictl도 있다. 디버깅 툴이다. cri도 디버깅 툴이지만 컨테이너를 만들기 쉽지 않아서 kubelet과 같이 사용하게 된다.
kubelet이 한 번에 특정 컨테이너나 포드를 특정 개수씩 노드에서 사용할 수 있게 보장한다. 만약 cri를 통해 컨테이너를 만들게 된다면 kubelet이 자기 모르게 만들어진 컨테이너 및 pods를 삭제할 때 같이 삭제되게 될 것이다.
따라서, cri는 디버깅 목적으로만 사용된다.
ctr - containerd와 같이 사용되며 디버깅에 사용되고 기능이 매우 제한적이다.
nerdctl - Docker다. 컨테이너를 만드는데 사용하고 docker cli와 같으면서 그 이상의 기능을 지원한다.
crictl - 주로 디버깅 목적으로 사용하게 될 것이다.
ETCD for beginner
ETCD가 뭔데
key:value 스토어가 있는 단순하고 안전하고 신속한 데이터베이스이다.
SQL 관계형 데이터베이스는 행과 열 형태로 데이터를 저장한다.
binaries로 다운로드 받는다.
./etcd./etcdctl set key1 value1기본적으로 2379에서 수신 대기하는 서비스가 시작된다.
ETCD는 2013년 8월에 출시됐고 stable version은 2014년 12월에 출시되었다.
2018년 11월 CNCF로 합류했다. version 2에서 version 3로 넘어갈 때 CNCF에 합류하게 되었으니 가장 많은 변화가 있었는데, etcdctl 명령어도 많이 변화되었다.
etcd --version입력하여 etcd 버전을 알아낸다. 버전은 2가지가 있다.
etcdctl version과 API version이 있다.
하나는 말 그대로 etcd utility version이며 하나는 호출 API 버전이다.
그래서 etcd가 어떻게 쿠버네티스와 함께 작동하게 될까
- Nodes
- Pods
- Configs
- Secrets
- Accounts
- Roles
- Bindings
- Others
etcd 데이터 저장소는 클러스터에 관한 정보를 저장할 것이다. 위에 나열된 정보들과 같다.
kube control get 이라는 명령어를 실행한다고 했을 때, etcd 서버에서 갖고 오는 것이다.
클러스터에 대한 모든 변경사항, 노드 추가, pods 배포 등 모든 replica sets가 etcd 서버에서 업데이트 된다. etcd 서버에서 업데이트 된 한 번만 변경이 완료된 것으로 간주한다.
클러스터 설정 방법에 따라 etcd가 다르게 배포되는데, 2가지 kubernetes배포에 대해 알아본다.
- 클러스터를 처음부터 설정하는 경우
etcd 바이너리 직접 다운로드하고 설치 및 etcd 구성
마스터 노드에서 직접 서비스로 제공되며, 많은 옵션이 전달된다.
etcd가 수신하는 주소는 서버의 ip와 포트 2379이다.
kube API 서버에서 etcd 서버에 도달하려고 할 때 kubeadm을 사용하여 클러스터를 설정하는 경우, kubeadm은 etcd 서버를 파드로 배포한다. kube system namespace에 있으며, etcd 데이터베이스를 탐색할 수 있다.
kubectl get pods -n kube-system이 pod 내에서 etcd 제어 유틸리티를 사용한다.
kubernetes에 저장된 모든 키를 나열하려면
etcdctl get / --prefix -keys-only루트 디렉터리는 레지스트리이고 그 아래에는 다양한 kubernetes 구성이 있다.
고가용성 환경에서는 클러스터에는 여러 마스터 노드가 있을 텐데, 이러면 etcd 인스턴스가 여러개 생길 것이다.
이 경우 etcd 인스턴스가 서로에 대해 알고, 올바른 매개변수를 설정하고 초기 클러스터 옵션이 etcd 서비스의 다른 인스턴스를 지정해야 한다.
- Qadium 도구를 사용하여 배포
Kube-API server
kubectl 명령어를 실행하면 kubectl 유틸리티가 실제로 kube-api server로 접근한다. kube-api server는 처음으로 제대로 된 정보인지 인증을 하고, 데이터를 검색한다. 이후 etcd 클러스터에서 요청한 정보와 함께 응답을 하게 되는 것이다.
kubectl get nodes실제 kubectl 명령어를 사용할 필요는 없고, API를 직접 호출할 수도 있다.
curl -X POST /api/v1/namespaces/default/pods ...[other]이 경우 API 서버가 pod 객체를 생성하고, 노드에 할당하지 않으며 etcd 서버의 정보를 업데이트 하게 될 것이다.
Pod이 생성되었음을 사용자에게 업데이트하면, 스케줄러는 API서버를 지속적으로 모니터링 한다.
이후 새로운 pod이 있다는 것을 깨닫지만, 할당된 노드가 없다.
스케줄러가 올바른 노드를 식별하고, 이 pod을 배치하려면 kube-apiserver에 다시 한 번 전달해야 한다.
그렇게 하면 kube-apiserver가 etcd에서 정보를 업데이트 한다.
kube-apiserver는 유일한 구성 요소이며 etcd 데이터 저장소와 직접 상호작용한다.
인증을 담당하고, 요청을 검증한다.
