CKAD(Certified Kubernetes Application Developer) 후기 (k8s v1.26)

시작하며

이 글에서는 CKAD (Kubernetes v1.26)에 관한 준비기간, 준비방법 그리고 소소하고 작은 팁에 대해 정리하였습니다.

CKAD Badge

credly.com

준비 기간

2023년 01월 09일 ~ 2023년 01월 27일(시험일)
CKA 취득 후 기간이 오래 되었기 때문에, 약 3주 정도를 잡고 준비했습니다.

준비 방법

CKA를 취득한 분이라면 아래 실습 환경 연습 및 K8s 문서 정독만으로도 충분하실 것 같습니다.
1. Kodekloud - Udemy Labs(Certified Kubernetes Application Developer)
Udemy에서 CKAD 강의를 구매하면 실습 환경이 제공 되는 Kodekloud의 Lab을 통해 학습할 수 있습니다. 여기에서 기본기 Recap부터 CKAD의 각 커리큘럼별 연습문제를 풀어볼 수 있습니다. 또한, 함께 제공되는 강의 중 JSON Path Test – Free Course 강의도 유용했습니다.

2. Killer.sh - Kubernetes Exam Simulator-CKAD
CNCF에서 시험을 구매하면, Killer.sh에서 2번의 시험 시뮬레이션을 제공해줍니다. 실제 시험 환경과 가장 비슷한 환경이며, 연습문제 또한 본 시험보다 약간 어렵게 출제되어서 시험 준비하는데 가장 많은 도움이 되었습니다.

3. Kubernetes Documentation - Kubernetes Documentation
사실 애매하게 기억에 남은 개념과, 기본기, 동작원리를 다시 찾기 위한 정석은 공식 문서를 제대로 다시 읽어보고 실제 터미널에서 kubectl explain으로 오브젝트 명세를 보는 수 밖에 없습니다. 예전엔 알았지만, 지금은 가물가물한 어렴풋한 기억을 다시 상기시켜 주고, 미처 몰랐던 개념들을 다시 잡게 되었습니다.
엔지니어는 문서를 정확하게 읽고 이해해야 하며, 필요한 정보를 빠르게 찾아 효율적으로 사용하는것도 실력이라고 생각합니다.

4. kubectl Cheat Sheet - kubectl Cheat Sheet
쿠버네티스를 관리 / 운영하면서 자주 마주치게 되는 상황마다 유용하게 사용할 수 있는 커맨드 치트시트 입니다.
본 시험때는 kubectl 을 사용한 명령형 (Imperative) 컨트롤이 시간 절약에 효과적이기 때문에 유용한 커맨드들을 쭉 훑어보면 도움이 됩니다.
본 시험에서는 주로 명령형 커맨드(kubectl create or run)와 함께 --dry-run=client -o yaml을 함께 사용해서 선언적 명령을 위한 Object Specification(YAML)의 뼈대를 빠르게 만들고 부족한 Spec을 채워넣어 Apply 하는 패턴을 사용했습니다.

소소하고 작은 팁들

Terminal Setting
본 시험 환경에서도 기본적인 .vim세팅과 .bashrc 세팅은 되어 있기 때문에 본 시험때 별도로 추가 세팅을 하지는 않았습니다. 하지만, 로컬환경에도 적용해 두고 사용하면 실제 업무, 연습 때도 유용하기 때문에 적어봅니다.

# .vimrc
syntax on # 문법 하이라이팅
set autoindent # 자동 들여쓰기
set ts=2 # tabpstop, 탭 간격
set sw=2 # shiftwidth(making shift operations (<< or >>))
set et # expandtab, tab 공백을 space 공백으로 전환가능, 즉, tab 공백을 스페이스로 한칸씩 제거 가능
set nu # line number
set ruler # 화면 오른쪽 아래에 현재 커서위치 표시

### minimum .vimrc
set tabstop=2
set expandtab
set shiftwidth=2

# .zshrc
[[ $commands[kubectl] ]] && source <(kubectl completion zsh) # kubectl 자동완성
alias k=kubectl # 단축어

Faster Command

# dry-run
export do="--dry-run=client -o yaml"
-> k run pod1 --image=nginx $do

# pod delete
export now="--force --grace-period 0"
-> k delete pod1 $now

Basic recap
저는 아래 나열된 부분들이 헷갈렸기 때문에 자주 보고 공부하고 연습했던것 같습니다. 역시 기본이 제일 중요한것 같습니다.
pod & svc domain

# pod, ip 주소는 10-0-244-1 와 같이 '-'를 사용
pod-ip-address.my-namespace.pod.cluster-domain.example

# svc에 노출된 pod는 다음 도메인도 추가로 갖는다.
pod-ip-address.service-name.my-namespace.svc.cluster-domain.example

# svc (full domain)
my-svc.my-namespace.svc.cluster-domain.example

# svc (short, different namespace)
my-svc.my-namespace

# svc (short, same namespace)
my-svc

Taints, Tolerations
Taints를 통해 특정 Node에 Pod 스케쥴링을 하지 않도록 하거나, Toleration을 통해 Pod를 Taints가 등록된 특정 노드에 배치시킬수 있도록 스케쥴러에게 명령을 내릴 수 있습니다.

# taints formt
key=value:effect

# If a taint with that key and effect already exists, its value is replaced as specified.
kubectl taint nodes foo dedicated=special-user:NoSchedule

# effect
NoExcute # 파드 실행 및 배치 금지, 현재 실행중인 pod는 evict
NoSchedule # toleration이 없는 한 스케쥴러에게 파드를 배치하지 못하도록 함
PreferNoSchedule # toleration이 없는 pod는 최대한 node에 배치하지 않지만, 필수는 아니다.

Multi-Container(Init, SideCar) Logging
SideCar 로깅에 대해 알고는 있었지만, 정확한 사용 목적과 효율성에 대해선 알지 못했고, 구성 방법도 능숙하진 않았던것 같습니다. 최소한 이러한 개념이 존재하는 이유와 사용 목적을 알아야 시험을 보는것 뿐만 아니라 실제로 기억에 남기 때문에 업무에도 도움이 됩니다.

• Sidecar logging -> pod(container)에서 발생하는 Log를 stdout/stderr로 Redirect하게 되면, kubelet에서 처리되기 때문에, kubectl logs로 조회 가능
• Init Container -> 어플리케이션 컨테이너가 시작되기 전에 초기 준비를 위한 컨테이너로서, 정상 실행 완료 후 종료, 어플리케이션 컨테이너는 initContainer가 정상 실행 후 종료 되기까지 대기

Admission Controller
21년 9월에 CKAD 커리큘럼이 업데이트 되면서 추가된 시험 항목이라고 합니다. 제겐 조금 낯선 개념이라서 개념 공부 위주로 준비했습니다.
개요
K8s의 API Server로 오는 Client의 요청(request)은 인증(Authentication)/인가(Authorization)를 거친 후 Admission Control 순서로 처리되는데, 이때 3번째인 Admission Control단계 에서 관리자가 준비해둔 플러그인에 따라 요청을 강제로 변형(Mutation)하거나 요청이 올바른지 검증(Validattion)하여 클러스터에 올바른 명령을 내릴 수 있습니다. 즉, Admission controller는 Authentication/Authorization 이후에 적용되는 관리자의 세부 정책으로 볼 수 있습니다.
A Guide to Kubernetes Admission Controllers
예를 들면, 요청을 보낸 사용자는 Namespace를 만들 권한은 있지만, 존재하지 않는 Namespace에 Pod를 만드는 요청일 경우 Admission controller의 Validation 작업에 의해 거부될 수 있으며, 혹은 Namespace를 자동으로 만드는 Admission controller plugin이 API Server에 있다면, 요청이 변형(Mutation)되어 Namespace를 자동으로 만들어서 Pod를 새로생성된 Namespace에 배치시키도록 설정해 둘 수 있습니다. 또는, PVC 생성시 StorageClass 입력하지 않아도, Default로 설정된 StorageClass가 적용되는 이유는 클러스터의 Default StorageClass를 지정하는 Admission controller가 존재하기 때문입니다.

즉, 인증과 인가를 받은 요청이지만, 이후 요청의 액션(CRUD)에 대해 요청이 올바른지 검증(validation)하여 제한하거나, 혹은 요청 정보가 불충분 하다면, 요청을 변형(mutation)할 수 있도록 하는 컨트롤러 입니다.

CRD & CR
Custom Resource Definition & Custom Resource
이 부분도 업데이트된 시험 항목인데 저에겐 많이 낯설었습니다.
CRD는 K8s API를 확장(Extension)해서 사용자가 Custom Resource를 만들 수 있도록 제공하는 Object입니다. ConfigMap으로 애플리케이션을 사용자화 하는것 이상으로, 사용자가 직접 새로운 Object 명세를 CRD로 생성 및 ETCD에 등록 해 두면, CR로 새로운 리소스를 생성하고 ETCD에 저장 할 수 있습니다.

즉, CRD를 통해 apiVersion, kind, name, spec의 property를 미리 선언해두고, CR을 생성하면 클러스터에 사용자가 커스텀한 Object가 생성됩니다.

사실 K8s에서 커스텀 리소스를 만들기 위한 방법으로 CRD외에 Aggregated API를 사용한 방법이 있습니다.
Aggregated API 도 저에겐 낯설지만, CRD와의 차이점 위주로 간단한 개념을 살펴보면, CRD는 프로그래밍 없이 간단하게 작성하지만, 그만큼 자유도가 낮고, API Aggreation은 API Server를 직접 설계하고 구축해서 사용하기 때문에 그만큼 자유도가 높은 방식인것 같습니다.

CRDs are simple and can be created without any programming.
API Aggregation requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.

Depracated K8s API Version Converting
시험 준비하면서 알게된 Tool인데, depracated된 k8s api version으로 작성된 YAML 스펙을 현시점에 맞게 자동으로 Converting 해주는 유용한 툴입니다. 시험에서도 다운로드 받아 사용할 수 있습니다.
kubectl convert -f FILENAME > NEW-FILENAME
Install kubectl convert plugin

마치면서

결국 결론은 CKAD 커리큘럼 CKAD Curriculum 에 나와있는 모든 항목과 기타 K8s 기본 Object들을 능숙하게 관리할 정도로 연습하면 좋습니다.

CKA 시험을 보신 분이라면 CKA와 겹치는 부분도 많고, 생각보다 CKA보다 난이도가 높지 않기 때문에 부담없이 도전해보면 좋을 것 같습니다.

평소 쿠버네티스 및 컨테이너 환경을 좋아하지만, 실무에서 접하기 어렵거나, 컨테이너 환경에 대한 감을 살려두고 싶으신 분들이라면 충분히 많은 도움을 얻어갈 수 있는 자격증 이라고 생각합니다.

마지막으로, 시험 전 시스템 체크 및 시험 준비사항을 꼭 숙지하고 계시면 많은 도움이 됩니다.
Important Instructions: CKA and CKAD