CKA-1일차

📍 CKA 1일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 1-17, 273

---

01. Course Introduction

쿠버네티스는 클라우드 컴퓨터 분야에서 최고 트렌드 기술 중 하나이다.
쿠버네티스 구직률은 1년전보다 173% 이상 빠르게 증가했다.

시험은 실용적이고 실무적이기 때문에 기술을 잘 알아야하고 충분히 연습해야 성공할 수 있다.

---

02. Certification

• 첫번째 시험을 통과하지 못하면 12개월 안에 무료로 한번 더 시험을 볼 수 있게 해준다.
• 시험은 온라인에서 치뤄지며 온라인 관독관이 감독한다.
• 시험에 필요한 요구사항은 자격증 웹사이트의 후보 지침서에서 상세하게 볼 수 있다.
• CKA는 객관식 시험이 아니며 온라인 실적 기반 시험으로 기술을 시험한다.
• 기술이 어떻게 작동하는지를 이해해야 한다. 2시간 동안 정해진 시험 가이드라인에 따라 다양한 과제를 수행해야 한다.
• 시험을 보는 동안 쿠버네티스 공식 문서 페이지를 참조할 수 있다.

---

10. 클러스터 아키텍처

먼저 높은 수준에서 아키텍처를 살펴보고 그런 다음 각각의 구성 요소로 파고든다.
각각의 역할과 책임은 무엇이고 어떻게 구성되어 있는지를 볼 수 있다.

• Kubernetes Architecture
• ETCD for beginners
• ETCD in Kubernetes
• Kube-API Server
• Controller Managers
• Kube Scheduler
• Kubelet
• Kube Proxy

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

마스터 노드는 쿠버네티스 클러스터를 관리하고 서로 다른 노드에 대한 정보를 저장하고 어떤 컨테이너가 어디로 갈지를 계획하고 노드와 컨테이너를 모니터링하는 등등을 책임진다.
마스터 노드는 컨트롤 플레인 구성 요소로 알려진 구성 요소 집합을 사용해서 이 모든 일을 다 한다.

ETCD는 키 값 형식으로 정보를 저장하는 데이터베이스이다.

스케쥴러는 컨테이너 리소스 요구사항이나 워커 노드 용량 혹은 다른 정책이나 제약 조건들 등에 근거해서 컨테이너를 설치하기 위한 올바른 노드를 식별한다.

컨트롤러가 있어서 다양한 영역을 관리할 수 있다. 노드 컨트롤러가 노드를 관리하고 새 노드를 클러스터에 온보딩하고 노드가 사용 불가능하거나 파괴되는 상황을 처리한다. 복제 컨트롤러는 원하는 컨테이너 수가 복제 그룹에서 항상 실행되도록 보장한다.

Kube API 서버는 클러스터 내에서 모든 작업을 오케스트레이션 한다.
클러스터 상태를 모니터링하고 다른 노드와 통신한다.

마스터 노드에 전체 관리 시스템을 형성하는 다양한 구성요소는 컨테이너 형태로 호스트될 수 있다.
DNS 서비스 네트워킹 솔루션은 컨테이너 형태로 배포될 수 있다.
그래서 컨테이너를 실행할 런타임 엔진인 Docker가 필요하다.
쿠버네티스는 containerd, cri-o, runc 등 다양한 런타입 엔진을 지원한다.
쿠버네티스에서 Dockershim가 사용 중지 되면서 쿠버네티스는 1.20부터 도커를 지원하지 않는다. 쿠버네티스는 컨테이너 런타임과 통신할 때 CRI라는 표준 인터페이스 API 를 사용하기 때문에 cri-o 와 containerd만 사용 가능하다.

kubelet은 클러스터의 각 노드에서 실행되는 에이전트이다. KubeAPI 서버의 지시를 듣고 필요한대로 노드에서 컨테이너를 배포하거나 파괴한다. KubeAPI 서버는 노드와 컨테이너의 상태를 모니터링하기 위해 주기적으로 Kubelet으로부터 상태 보고서를 가져온다.

Kube-proxy는 작업자 노드 간의 통신을 가능하게 한다. 또한 실행되는 컨테이너가 서로 닿을 수 있도록 작업자 노드에 필요한 규칙이 실행되도록 한다.

요약하자면 마스터 노드와 작업자 노드가 있다.
마스터 노드에는 ETCD Cluster가 있어서 클러스터에 대한 정보를 저장한다.
kube-scheduler는 노드의 응용 프로그램이나 컨테이너의 스케줄을 짜는 역할을 한다.
노드 컨트롤러, 복제 컨트롤러 등등이 존재해서 다양한 영역을 각자 관리한다.
Kube API 서버는 클러스터 내의 모든 작업을 오케스트레이션한다.

작업자 노드에는 kubelet이 있는데 Kube API 서버의 지시를 듣고 컨테이너와 Kube-proxy를 관리하여 클러스터 내부의 서비스 간 통신을 가능하게 한다.

---

12. 초보자를 위한 ETCD

• What is ETCD?

  ETCD is distributed reliable key-value store that is Simple, Secure & Fast.

  ETCD는 간단하고 안전하고 빠른, 신뢰성 있는 키-값 분산 저장소이다.

• What is a Key-Value Store?
  key-value 저장소는 문서나 페이지의 형태로 정보를 저장한다. 각 개인은 문서를 하나 갖고 그 개인에 관한 모든 정보가 해당 파일에 저장된다. 이런 파일은 어떤 형식이나 구조로든 될 수 있고 한 파일의 변화는 다른 파일에 영향을 주지 않는다.
  

• How to get started quickly?
  Github에서 운영 체제에 대한 관련 바이너리를 다운로드해 페이지를 배포하고 추출한 다음 ETCD 실행 파일을 실행하면 기본값으로 포트 2379를 듣는 ETCD 서비스가 시작한다.
  ETCD와 함께 오는 기본 크라이언트는 ETCD 컨트롤 클라이언트이다. ETCD 제어 클라이언트는 ETCD의 명령줄 클라이언트이다. 키 값을 저장하고 회수할 수 있다.
  

• How to operate ETCD?

   // version 2
   etcdctl set key1 value1		// key1-value1 저장
   etcdctl get key1			// key1를 갖는 value1 조회
   
   // version 3
   export ETCDCTL_API=3		// API version을 3으로 설정
   etcdctl version				// version 확인
   etcdctl put key1 value1		// key1-value1 저장
   etcdctl get key1			// key1를 갖는 value1 조회

  ETCD 버전2는 2015년 2월에 출시되었는데 2017년 1월에 3번째 버전이 출시되었다. 버전2는 많이 사용됐고 버전3에는 많은 변화가 있었다. 즉, etcdctl 명령어도 바뀌었다.

Later:

• What is a distributed system?
• How ETCD operates?
• RAFT Protocol
• Best practices on number of nodes

---

13. kubernetes의 ETCD

쿠버네티스에서 ETCD의 역할에 대해 알아보자.
ETCD 저장소는 클러스터에 대한 정보(Nodes, PODs, Configs, Secrets, Accounts, Roles, Bindings, Others)를 저장한다. 클러스터에 변화를 줄 때마다 ETCD에 반영되며 ETCD에 반영되어야 변화가 완료된 것으로 간주한다.

쿠버네티스 배포에는 두 가지 유형이 있다.
하나는 처음부터 배포하는 것이고 다른 하나는 kubeadm 도구를 이용하는 것이다. 두 방법의 차이점을 아는 것이 좋다.

클러스터를 스크래치에서 셋업하는 경우, 기타 등등의 바이너리를 직접 다운로드해서 배포한다.
마스터 노드에 바이너리를 설치하고 서비스로서 구성한다.
서비스에는 많은 선택지가 있다. 그 중 상당수가 인증서와 관련 있다.
--advertise-client-urls는 ETCD가 듣는 주소이다.

kubeadm을 이용해 클러스터를 배포하는 경우, kubeadm이 그 외 기타 서버를 배포한다.
kube 시스템 네임스페이스에 있는 파드로 etcd-master를 배포한다.
kubectl exec etcd-master -n kube-system etcdctl get key1 다음 명령어로 etcd 데이터베이스를 탐색할 수 있다.

쿠버네티스는 특정 디렉터리 구조에 데이터를 저장한다.
루트 디렉터리는 레지스트리로 그 아래에 다양한 쿠버네티스 구성체(minions, pods, replicasets, deployments, roles, secrets 등)가 있다.

고가용성 환경에서는 클러스터에 마스터 노드가 여러개이다.
그럼 마스터 노드 전체에 여러 개의 ETCD 인스턴스가 퍼지게 된다.
이 경우, ETCD 인스턴스들이 서로에 대해 알도록 해야 한다.
그러기 위해서는 ETCD 서비스 구성에 올바른 매개변수를 설정해야 한다.

---

14. ETCD 명령

ETCDCTL은 ETCD와 상호작용하는 데 사용되는 CLI 도구이다.
ETCDCTL은 2개의 API 버전(버전2, 버전3)을 사용하여 ETCD 서버와 상호작용할 수 있다.
기본적으로 버전2를 사용하도록 설정되어 있다.
각 버전에는 서로 다른 명령 집합이 있다.

API 버전을 설정하기 위해서는 export ETCDCTL_API=3와 같이 환경변수 ETCDCTL_API를 명시하면 된다. API 버전이 설정되지 않은 경우 버전2로 설정된 것으로 간주하고 버전3 명령이 작동하지 안헤 된다. 버전3으로 설정되면 버전2의 명령이 작동하지 않는다.

그 외에도 ETCDCTL이 ETCD API 서버에 인증할 수 있도록 인증서 파일의 경로도 지정해야 한다.

---

15. Kube-API 서버

Kube-API server는 쿠버네티스의 주요 관리 구성 요소이다.
kubectl 명령을 실행하면 kubectl 유틸리티가 Kube-API server에 도달한다.
큐브 관리자가 먼저 요청을 인증하고 유효성을 확인한다. 그럼 ETCD 클러스터에서 데이터를 회수해 요청된 정보로 응답한다. 굳이 kubectl 명령어를 사용할 필요 없이 API를 호출해도 된다.

1. Authenticate User
2. Validate Request
3. Retrieve data
4. Update ETCD
5. Scheduler
6. Kubelet

예를 들어, pod를 생성해보자.
curl -X POST /api/v1/namespaces/default/pods ... [other]
이 경우 API 서버는 노드에 할당하지 않고 pod 개체를 생성한다.
pod가 생성되었음을 ETCD 서버와 사용자에게 업데이트한다.
kube-scheduler는 지속적으로 API 서버를 모니터하고 노드가 할당되지 않은 새로운 pod가 있다는 것을 알게 된다. kube-scheduler는 새 pod가 위치할 올바른 노드를 식별해서 kube-api server와 통신한다.
API 서버는 해당 정보를 ETCD 클러스터에 업데이트한다. API 서버는 해당 정보를 작업자 노드의 kubelet에게 전달한다.
그럼 kubelet은 노드에 pod를 생성하고 컨테이너 런타임 엔진에게 지시해서 앱 이미지를 배포한다. 완료되면 kubelet은 상태를 API 서버에게 업데이트하고 API 서버는 ETCD 클러스터를 업데이트한다. 변화를 요구할 때마다 비슷한 패턴이 반복된다.

kube-API server는 클러스터에서 변경을 위해 수행해야 하는 모든 작업의 중심에 있다.
요약하자면 kube-API server는 요청의 인증과 유효성을 확인하고 ETCD 저장소에서 데이터를 검색하고 업데이트하는 일을 한다. 사실 kube-API server는 ETCD 저장소와 직접 상호작용하는 유일한 구성요소이다. 다른 구성요소들은 kube-API server을 이용해 업데이트를 수행하고 ETCD에 반영한다.

kube-API server는 많은 매개변수로 실행된다.
쿠버네티스 구조는 다양한 구성 요소로 구성되어 있다. 서로 협력하고 다양한 방식으로 대화한다.
그래서 다른 부품이 어디 있는지 알아야 한다. 인증, 승인, 암호화, 보안에는 다양한 방식이 있다. 그래서 선택지가 많다.

다수가 인증서로 서로 다른 구성 요소 간의 연결을 확보한다. 모든 다양한 구성 요소는 연결된 인증서를 갖고 있다. 기존 클러스터에서 kube-api server의 옵션을 어떻게 볼 수 있을까?

kubeadm 툴로 설정하면 kubeadm은 kube-api server를 마스터 노드의 kube-system 네임스페이스에 pod로 배포한다. 이 경우, etc/kubernetes/manifest/kube-apiserver.yaml 명령어를 통해 pod 정의 파일에서 옵션을 확인할 수 있다.

kubeadm 툴로 설정하지 않은 경우, cat /etc/systemd/system/kube-apiserver.service 명령어를 통해 kube-api server 서비스를 보면 옵션을 검사할 수 있다.

---

16. Kube Controller Manager

Kube Controller-Manager는 쿠버네티스의 다양한 컨트롤러를 관리한다.

1. Watch Status
2. Remediate Situation

controller는 시스템 내 다양한 구성 요소의 상태를 지속적으로 모니터링하고 시스템 전체를 원하는 기능 상태로 만드는 것이다.
노드 컨트롤러는 노드 상태를 모니터링한다.
복제 컨트롤러는 복제품 세트의 상태를 모니터링하고 원하는 수의 pod가 세트 내에서 항상 사용 가능하도록 한다.
실제로 쿠버네티스에는 이러한 컨트롤러가 훨씬 더 많다.
이러한 컨트롤러들은 Kube Controller Manager라는 하나의 프로세스로 패키지화되어 있다. 따라서, Kube Controller Manager를 설치하면 다른 컨트롤러들도 설치된다.

kubeadm 툴로 설정한 경우,
cat /etc/kubernetes/manifest/kube-controller-manager.yaml 명령어를 통해 pod 정의 파일에서 옵션을 확인할 수 있다.

kubeadm 툴로 설정하지 않은 경우,
cat /etc/systemd/system/kube-controller-manager.service 명령어를 통해 서비스 옵션을 확인할 수 있다.

---

17. Kube Scheduler

kube-scheduler는 pod의 일정 관리를 책임진다.
kube-scheduler는 어떤 pod가 어떤 node에 들어갈지만 결정한다.
pod를 node에 두는 것이 아니다. 이는 kubelet의 일이다.

쿠버네티스에서는 일정 관리자가 특정 기준에 따라 pod를 어느 node에 놓을지 결정한다.
리소스 요구사항이 다른 pod가 있을 수도 있고 특정 응용 프로그램에 한정된 node가 있을 수도 있다.

1. Filter Nodes
2. Rank Nodes

kube-scheduler는 두 단계를 거쳐 pod에 가장 적합한 node를 찾는다.
첫 단계에서는 kube-scheduler가 pod에 맞지 않는 노드를 걸러낸다.
그 다음 kube-scheduler는 pod에 가장 적합한 노드를 표시한다.
이것은 사용자 지정이 될 수 있고 고유의 스케쥴러를 작성할 수도 있다.

Scheduler와 관련해서 살펴볼 주제가 아주 많다.

• Labels & Selectors
• Resource Limits
• Manual Scheduling
• Daemon Sets
• Multiple Schedulers
• Scheduler Events
• Configure Kubernetes Scheduler

kubeadm 툴로 설정한 경우,
cat /etc/kubernetes/manifest/kube-scheduler.yaml 명령어를 통해 pod 정의 파일에서 옵션을 확인할 수 있다.