[CKA] 자격증 공부 개요 및 Core Concepts - 1

CKA 자격증 공부

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

 

개요

아래 내용들은 자격증 합격 후기 및 유용한 팁 발췌함

1. 합격은 66%점 기준
2. 시험 시간은 2시간
3. 3년 유효기간 (2024.01.01 기준 3년 -> 2년으로 변경)
   1. 링크를 확인 해보면 알겠지만 유효 기간이 2024.04.01 00:00 기준으로 기존 3년에서 2년으로 변경 되었다. 그 전에 시험을 통과하면 유효기간이 3년이니 빨리 합격하는 것이 좋을 것 같다.
4. 1번의 Retake 제공
5. ❗시험 등록 시 입력한 Verify Name을 기준으로 국문 으로 입력 시 국문 주민등록증 / 운전 면허증으로 가능하나, 영문으로 입력 시 여권이나 영문 운전 면허증을 준비해야함.
6. 각 문제마다 컨텍스트를 바꿔서 문제를 수행할 수 있도록 되어있다. kubectl config set-context <컨텍스트명>
7. 시험 내용
   1. Kubernetes 클러스터 설정 및 관리
   2. 애플리케이션 배포 및 스케일링
   3. 네트워킹 구성과 관리
   4. 스토리지 설정과 관리
   5. 보안 및 권한 관리
   6. 클러스터 유지 보수와 문제 해결
8. ~./vimrc 파일 수정할 것

# tab을 2칸으로 설정
set tabstop=2

# tab 사용시 발생하는 공백을 띄어쓰기(스페이스)로 채움

set expandtab

# shift(>, >>, <, << 등)를 2칸으로 설정

set shiftwidth=2

cheat sheet 잘 활용하기
https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/

Autocomplete 설정 완료하기 & kubectl alias 설정

https://kubernetes.io/docs/reference/kubectl/quick-reference/

source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first.
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.

alias k=kubectl
complete -o default -F __start_kubectl k

 

문제 배점

 

알아두면 좋은 핵심 문제 유형

etcd 스냅샷 생성 및 복구

지정된 크러스터의 마스터 노드 etcd 백업 및 복원 방법을 알아두어야 한다. 배점도 크다고 함...
etcdctl APi의 버전 3 기준으로 CA 인증서, 서버 인증서 및 키파일 경로를 포함하여 snapshot 생성하고 복원하는 명령어 전체를 매뉴얼 없이 바로 입력 가능하도록 연습하는 게 좋다고 한다.

클러스터 노드 업그레이드

마스터 노드 및 워커 노드의 업그레이드 절차를 숙지해야 함.
공식 문서에 방법이 나와 있다고 하니 천천히 진행하면 된다고 한다. 업그레이드 과정 중간에 노드의 drain과 cordon, uncordon 절차를 반드시 따라야 한다고 함.

클러스터 업그레이드
kubeadm 이용한 클러스터 업그레이드

파드 간 네트워크 구성

Service 와 Ingress, 그리고 NetworkPolicy 를 이용한 파드 간 네트워크 구성을 반드시 알아야한다.
이 유형은 유데미 강의 만으로는 안되어서 하위 링크 참조하셨다고 한다.

NetworkPolicy resource

로그 스트리밍용 사이드카(Sidecar) 컨테이너 구현

emptyDir 또는 hostPath 유형의 공유 볼륨을 이용해 로깅 에이전트 기능을 하는 사이드카 컨테이너 구현도 연습해야한다.
이를 위해서는 멀티 컨테이너 파드를 구성하는 방법, 그리고 이 컨테이너들이 함께 공유하는 볼륨 설정법을 알아야 한다.

Logging Architecture: Using a sidecar container with the logging agent
멀티 컨테이너 파드의 대표적인 디자인 패턴들

트러블슈팅(Troubleshooting)

CKA 과정에서 다루게 되는 트러블슈팅의 유형은 크게 네 가지로 나뉜다.

• 애플리케이션(파드/컨테이너) 구동 문제
• 컨트롤 플레인 구성 요소의 구동 문제
• 워커 노드의 구동 상태 확인 및 복원 문제
• 네트워크 문제

하위 공식 문서들이 트러블 슈팅에 도움이 된다.

Troubleshoot Applications
Troubleshoot Clusters
Debugging Kubernetes nodes with crictl
Debug Services

 

그 외 참고할만한 링크

https://velog.io/@iaj0204/CKA-%EC%8B%9C%ED%97%98-%ED%9B%84%EA%B8%B0-%EB%B0%8F-%ED%8C%81-pv3unahb

https://gain-yoo.github.io/kubernetes/CKA-%EC%8B%9C%ED%97%98-%ED%9B%84%EA%B8%B0/#%EC%8B%9C%ED%97%98%EC%9D%84-%EB%A7%88%EC%B9%98%EA%B3%A0

https://inspirit941.tistory.com/424

https://ls-altr.tistory.com/82

 

---

코어 지식

• 쿠버네티스의 목적은 응용 프로그램을 컨테이너 형식으로 흐스트하는 것 자동화된 방식으로 그래야 요구에 따라 응용 프로그램의 많은 인스턴스를 쉽게 배포할 수 있고 응용 프로그램 내 다양한 서비스 간의 통신이 쉽게 가능하니까
• 쿠버네티스는 노드로 구성이 되는데 워커 노드와 마스터 노드(컨트롤 플레인)로 구성된다.
  • 워커 노드는 컨테이너를 로딩할 수 있는 배
  • 누군가는 선박에 컨테이너를 적재해야 하는데 적재만 하는 게 아니라 어떻게 적재할지 계획하고 선박을 식별하고 그에 대한 정보를 저장하고 선박에 실린 컨테이너의 위치를 감시하고 추적하고 전적인 적재 과정을 관리하는 등등을 하는 역할을 하는 마스터 노드
  • 마스터 노드는 쿠버네티스 클러스터를 관리하고 노드에 대한 정보를 저장하고 노드와 컨테이너를 모니터링 등등을 책임지는 역할

 

마스터 노드

• Etcd : 각 선박에 대한 정보를 유지해야 함. 어떤 컨테이너가 어떤 배에 있고 몇 시에 적재됐는지 등을. 이러한 정보들이 HA Key-Value Store인 Etcd에 저장된다. 키 값 형식으로 데이터를 저장하는 데이터베이스
• kube-scheduler : 컨테이너를 설치하기 위해 올바른 노드를 식별한다.
• Controller-Manager :
  • Node-Controller : 노드를 관리해주는 컨트롤러
  • Replication-Controller : 원하는 수가 복제 컨트롤러 수에 맞게끔 해주는
• Kube-apiserver : 모든 클러스터에서 수행되는 작업을 오케스트레이션하는 녀석. 위 모든 구성 요소와 통신한다.

 

워커 노드

• 컨테이너 런타임 엔진 : 컨테이너를 실행하기위한 소프트웨어. 보통 Docker 늘 Docker일 필요는 없다.
• Kubelet API :
  • 마스터 노드와 통신하면서 컨테이너에 대한 정보를 받고 필요한 만큼 실행하며, 해당 선박의 컨테이너 상태와 선박에 실린 컨테이너의 상태 등을 마스터 노드에게 보고하는 역할 kube-api 서버의 지시를 듣고 필요한 대로 노드에서 컨테이너를 배포하거나 파괴
  • 주기적으로 Kubelet은 Kube API에게 상태 보고서를 보내서 노드와 컨테이너의 상태를 모니터함.
• Kube-proxy : 다른 노드와 통신하기 위한 역할

이거는 그냥 kube in action 책에서 배운 내용으로 생각하는 게 나을 듯

 

Docker vs ContainerD

• 쿠버네티스가 발전함에 따라 다른 컨테이너 런타임도 나오게 됐고, Docker말고도 rkt가 나오게 됨
• 다른 컨테이너 런타임과 작업하려면 컨테이너 런타임 인터페이스, CRI라는 인터페이스를 통해 작업함
• CRI는 어떤 공급업체든 쿠버네티스의 컨테이너 런타임으로 작업하게 해준다. OCI(Open Container Initiative) 표준을 준수하는 한
  • OCI 표준에는 imagespec과 runtimespec이 존재함
    • imagespec : 이미지 빌드 방식에 대한 기준을 정의, 이미지를 어떻게 만들어야 하는지 설명
    • runtimespec : 컨테이너 런타임을 개발하는 방법에 대한 표준을 정의
• Docker는 CRI를 지원하기 위해서 만든게 아니다. Docker는 CRI가 나오기 이전에 만들어 졌고, 쿠버네티스는 Docker를 지원해야 하기 때문에 Dockershim을 도입했다.
  • 컨테이너 런타임 인터페이스 밖에서 Docker를 지속 지원하는 임시방편
  • Dockershim 또한 22.05.03 일자로 지원이 종료됨
• Docker는 다중 도구로 구성 돼 있다. Containerd는 CRI 호환이 가능하고 다른 런타임처럼 쿠버네티스와 직접적으로 작업할 수 있다.
• Containerd는 Docker와 별도로 런타임으로 사용될 수 있다.
• 그러나 도커심을 유지하기 위한 불필요한 노력으로 문제가 더 커졌고 Docker 지원이 해제 되었다.
• 그러나 Docker 이미지는 지원이 된다. Docker 이미지는 OCI 표준 스펙을 따르기 때문에.
• Dcoker 자체는 사라졌지만 Containerd로 지원이 된다.

containerD

• Docker에서 만든 Container runtime
• 도커가 제공하는 도구를 사용하지 않아도 된다면 ctr cli 도구를 이용해서 컨테이너를 Run 할 수 있다.
• 디버깅 용도로 사용되기 때문에 사용자 친화적이지 않음
• nerdctl cli를 사용하면 Docker가 사용하는 도구들을 거의 사용 가능하다.
• crictl 도 있음 디버깅 목적으로만 사용된다. kubelet과 잘 어울림
• 그러나 docker에 비해 까다로움 runc, containerd, ctr 등 낯선 라이브러리를 익혀야 하는 단점이 있음

 

etcd

개요

• 분산되고 신뢰할 수 있는 Key-value 스토어로 간단하고 안전하며 신속하다.
• Key-Value store란?
  • 전통적으로 데이터베이스는 테이블형 포맷이었는데, 문서나 페이지의 형태로 정보를 저장해 각 개인은 문서를 하나 갖고 그 개인에 대한 정보가 파일에 저장되는 형태
  • 이러한 파일은 어떠한 형태로 변화할 수 있고 한 파일의 변화는 다른 파일에 영향을 주지 않는다.
  • JSON 또는 YAML 형태로 저장 되기도 한다.
• Etcd는 2379번 포트를 사용한다.
• etcd control client : etcd의 명령줄 클라이언트임. 이걸 사용해 키-값 쌍을 저장하고 회수할 수 있다.

etcdctl set key1 value1  
etcdctl get key1

• etcd in kubernetes
• 클러스터에 관한 정보를 저장한다. 예를 들어 Nodes, pods, config, secret, account, role, binding 등등
• 클러스터에 변화를 줄 때마다 etcd 서버에 업데이트 된다. etcd 서버에 업데이트 될 때만 완료된 것으로 간주된다.
• 클러스터를 어떻게 설정하느냐에 따라 다양하게 배포된다.
  • 두가지 유형이 있음 하나는 from-scratch 하나는 qadium 도구를 이용해서
    • from-scratch : 이전 데이터나 구성이 존재하지 않는 새로운 etcd 클러스터를 초기화한다는 의미이다.
    • qadium tool : 
  • 스크랫치로 설치하게 되면 직접 바이너리를 설치하고 서비스로서 구성하게 된다.
• kubeadm으로 구성하게 되면 etcd는 kube-system 네임스페이스의 pod의 형태로 생성되게 된다.

kubectl exec etcd-master -n kube-system etcdctl get / --prefix -key-only 
# ectd에 직접적으로 get 할 수 있다.

• 쿠버네티스는 특정 디렉터리 구조에 데이터를 저장한다. 루트 디렉터리는 레지스트리로 그 아래에 다양한 구조가 있다. 예를 들어 minions, pods, replicasets, deployments 등등...
• 고가용성 환경에서는 마스터 노드가 여럿일 것이다. 그렇게되면 마스터 노드 전체에 etcd 인스턴스가 여러 개가 생길 것이다.
• 이런 경우 etcd service configuration에서 올바른 parameter를 설정해서 각각의 etcd 인스턴스가 서로를 알게 해야한다.

 

Kube-API 서버

• kubectl get nodes 명령어를 관리자가 입력하면 먼저 kube-apiserver에 도달한다.
• 도달 이후 kube-apiserver가 먼저 요청을 인증하고 유효성을 확인한다.
• 이후 etcd 클러스터에 도달해 데이터를 회수해 요청된 정보로 응답한다.
• API 를 직접적으로 요청하는 방법도 있다.
  • curl -X POST /api/vi/namespaces/default/pods ...[other]
  • 이 명령어를 입력하면 아래와 같은 과정을 거친다.
  1. 요청이 먼저 인증되고 유효성 확인
  2. API 서버는 노드에 할당하지 않고 pod 개체를 생성
  3. etcd 서버에 있는 정보를 업데이트하고 pod가 생성된 사용자를 업데이트
  4. 스케줄러는 지속적으로 API 서버를 모니터하고 노드가 할당되지 않은 새로운 pod가 있다는 것을 알게 됨
  5. 스케줄러가 올바른 노드를 식별해 새 pod를 켜고 다시 kube-apiserver와 통신
  6. API 서버는 etcd 클러스터 정보를 업데이트
  7. API 서버는 해당 정보를 적절한 워커 노드에 kubelet에 전달
  8. kubelet은 노드에 pod를 생성하고 컨테이너 런타임 엔진에 지시해 이미지 배포
  9. 완료되면 kubelet은 상태를 api 서버로 업데이트하고
  10. API 서버는 etcd 클러스터의 데이터를 업데이트
• kube-apiserver는 클러스터에서 변경을 위해 수행해야 하는 모든 작업의 중심에 있다.
• 요약하자면 kube-apiserver는 요청의 인증과 유효성을 확인하고 기타 등등의 데이터 스토어에서 데이터를 검색하고 업데이트하는 일을 한다.
• kube-apiserver는 etcd와 직접 상호작용하는 유일한 구성요소
• 또한 스케쥴러, kube-controller-manager와 kubelet 같은 구성요소는 다 API 서버를 이용해 각 영역의 클러스터에서 업데이트를 수행함.

/etc/systemd/system/kube-apiserver.service 이 위치에서 api-server의 옵션 확인 가능
ps -aux |grep kube-apiserver 로 kube-apiserver에 대한 프로세스 확인 및 옵션 확인 가능

 

Kube controller manager

• 컨트롤러 매니저는 쿠버네티스의 다양한 컨트롤러를 관리한다.
• 컨트롤러 매니저는 마스터 쉽 내의 사무실이나 부서와 같다.
• 그래서 하는일은
  1. 첫째로 컨테이너의 상태를 확인하는 일
  2. 상황을 재조정하기 위해 필요한 조치를 취한다.
• 컨트롤러는 시스템 내 다양한 구성 요소의 상태를 지속적으로 모니터링하고 시스템 전체를 원하는 기능 상태로 만드는 것이다.
• Node-Controller
  • 예를 들어 노드 컨트롤러는 노드의 상태를 모니터링하고 응용 프로그램이 계속 실행되도록 필요한 행동을 한다.
  • Node Monitor Period = 5s 옵션을 이용해서 노드 컨트롤러의 상태 확인 주기를 변경 가능
  • Node Monitor Grace Period = 40s 옵션을 이용해서 Unreachable 상태로 표시하기 전에 실행 중인 노드가 응답하지 않도록 허용하는 시간을 변경 가능하다.
  • POD Eviction Timeout = 5m 옵션을 이용해서 파드를 다시 기동하는 데 걸리는 시간 즉 대기시간을 변경 가능하다. 이 시간이 지나면 노드 내 파드들은 모두 삭제 된다.
• Replication Controller
  • 원하는 수의 파드가 세트 내에서 항상 사용 가능하도록 함.
  • 파드가 죽으면 다른 파드가 곧장 생긴다.
• 컨트롤러는 정말 다양하다. Deployment / Cronjob / Service Account / Node / Namespace / Job / Statefulset / PV Binder / Endpoint / PV Protection / Repliacaset / Replication Controller
• /etc/kubernetes/manifests/kube-controller-manager.yaml 에서 옵션을 확인 가능하다.
• ps -aux | grep kube-controller-manager 로도 확인 가능하다.

 

Scheduler

• 스케줄러는 노드의 일정 관리를 책임진다.
• 스케줄러는 어떤 파드가 어떤 노드에 들어갈지만 결정한다.
• 파드를 노드에 직접적으로 두는 것은 kubelet이 한다.
• 스케줄러는 왜 필요한가?
  • 많은 배와 컨테이너가 있을 때는 알맞은 컨테이너를 알맞은 배에 실어야 한다.
  • 예를 들어 배와 컨테이너의 크기가 다른 경우 배가 컨테이너를 충분히 수용할 수 있는지 확인해야 한다.
• 결국 스케줄러가 특정 기준에 따라 파드를 어느 노드에 놓을지 결정한다.
• 스케줄러는 각 파드를 보고 최적의 노드를 찾으려 한다.
  1. 첫번째로는 파드에 맞지 않는 노드를 걸러낸다.
  2. 스케줄러는 파드에 가장 적합한 노드를 표시한다.
     • 우선순위 함수를 이용해 0에서 10까지 노드에 점수를 매긴다.
• /etc/kubernetes/manifests/kube-scheduler.yaml 에서 옵션을 확인 가능하다.
• 마찬가지로 ps -aux | grep kube-scheduler 로 옵션 확인 가능하다.

 

[출처] :

자격증 합격 후기 및 유용한 팁

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/