Certified Kubernetes Administrator (CKA) #26 시험 팁과 시간 관리, 자주 틀리는 패턴

인프라 쿠버네티스 컨테이너 오케스트레이션 자격증
11 분 소요

#1부터 #25까지 5개 도메인을 모두 정리했습니다. 이 글은 실기 시험에 들어가기 직전 한 번 더 읽고 갈 압축본입니다. 새로운 도메인은 없고, 2시간 실기를 어떻게 운영하는지와 시리즈 전체에서 운영자가 가장 자주 점수를 흘리는 함정만 모았습니다. 객관식이 아니라 실제 클러스터를 빈 터미널에서 고치고 만들어 내는 시험이라, 같은 지식이라도 운영이 합격과 불합격을 가릅니다.

2시간 운영 전략 #

작업 단위 운영 #

CKA는 약 15〜20개 작업을 2시간 안에 풀어야 합니다. 객관식처럼 문항당 균등하게 시간을 나누는 것이 아니라, 작업마다 배점이 화면에 표시되므로 그 배점이 곧 우선순위입니다. CKAD와 달리 CKA에는 etcd 복구나 클러스터 업그레이드처럼 한 작업이 10분 넘게 걸리는 고배점 문제와, generator 한 줄로 끝나는 저배점 문제가 같은 목록에 섞여 있습니다.

단계시간행동
1차 풀이약 90분배점 높고 손에 익은 작업부터. 막히면 flag 후 즉시 다음 작업
2차 풀이약 20분flag 한 작업만 다시 봄. 부분 점수라도 확보
검산약 10분k get으로 결과 확인, context,namespace,노드,파일명 재확인

시간 관리의 첫 번째 룰 #

한 작업에 과몰입하지 않습니다. 배점에 비해 시간이 오래 걸린다 싶으면 일단 가능한 데까지 만들어 두고 flag 후 넘어갑니다. 합격선은 66%이므로 어려운 한두 작업을 포기해도 됩니다. 배점 4점짜리 막히는 작업 하나를 붙들다가 배점 8점짜리 손에 익은 작업 두 개를 놓치는 것이 가장 흔한 실패입니다.

트러블슈팅을 우선순위로 본다 #

CKA는 Troubleshooting이 30%로 가장 큰 도메인입니다. 트러블슈팅 작업은 배점이 높고, 원인만 찾으면 수정 자체는 한 줄로 끝나는 경우가 많습니다. 다만 원인 추적이 길어지면 시간 전체를 소모하므로, 5분 안에 원인의 가닥이 잡히지 않으면 flag 후 넘어가는 기준선을 정해 두는 운영이 안전합니다. 반대로 etcd 복구처럼 절차가 정해진 고배점 작업은 손에 익혀 두면 시간 대비 점수가 가장 큽니다.

배점 높고 손에 익은 것부터 #

작업 목록을 처음부터 끝까지 한 번 훑으면서 배점 대비 난이도를 머릿속으로 표시합니다. RBAC 생성, PV/PVC 작성, Service 노출처럼 절차가 정해진 작업을 먼저 처리해 점수를 빠르게 쌓고, 원인 추적이 필요한 트러블슈팅과 손이 많이 가는 업그레이드를 중간에 배치하는 운영이 합격선을 넘기는 길입니다.

kubectl 속도 셋업 재정리 #

#1에서 잡은 셋업을 시험 시작 직후 1분 안에 끝냅니다. 작업당 수십 초씩 아끼는 투자입니다.

# kubectl을 k로
alias k=kubectl

# dry-run + YAML 출력을 do로
export do="--dry-run=client -o yaml"

# 즉시 삭제를 now로 (Pod를 빠르게 지우고 다시 만들 때)
export now="--force --grace-period=0"

# 자동완성 (k 까지 확장)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

~/.vimrc에는 YAML 들여쓰기 사고를 막는 설정을 넣습니다.

set expandtab
set tabstop=2
set shiftwidth=2
set number

CKA는 static Pod 매니페스트나 kubeadm 설정 파일의 특정 필드만 빠르게 바꿔야 하는 작업이 잦습니다. yq가 깔려 있으면 손편집보다 안전하고 빠릅니다.

# 특정 필드 읽기
yq '.spec.containers[0].command' /etc/kubernetes/manifests/kube-apiserver.yaml

# 필드 수정 (in-place)
yq -i '.spec.replicas = 3' deploy.yaml

추가로 손에 익혀 두면 좋은 vim 동작이 있습니다. YAML 블록을 통째로 들여쓰기할 때 비주얼 모드(V)로 줄을 선택한 뒤 >로 한 단계 들이고, .으로 반복합니다. static Pod 매니페스트를 편집할 때는 한 칸이라도 어긋나면 kubelet이 Pod를 다시 띄우지 못하므로 :set list로 탭과 공백을 눈으로 구분합니다.

context 전환을 가장 먼저 한다 #

CKA가 CKAD와 가장 크게 다른 운영 포인트입니다. CKA는 클러스터가 여러 개이고, 각 작업은 지정된 클러스터에서 풀어야 채점됩니다. 작업 설명 맨 위에 제시되는 use-context 명령을 먼저 실행하지 않으면, 답을 맞게 만들어도 다른 클러스터에 만들어져 0점입니다.

# 작업마다 가장 먼저 실행
k config use-context <작업에서 지정한 컨텍스트>

# 지금 어느 클러스터인지 확인
k config current-context

노드 안으로 들어가는 작업도 마찬가지입니다. static Pod 수정, kubelet 재시작, etcd 스냅샷 같은 작업은 지정된 노드에 SSH로 들어간 뒤에 풀어야 합니다. control plane 노드에서 해야 할 작업을 워커 노드에서 하면 점수가 없습니다.

# 작업에서 제시하는 호스트명으로 접속
ssh node01

# 작업이 끝나면 반드시 빠져나와 원래 환경으로
exit

SSH로 노드에 들어간 채 다음 작업을 풀기 시작하는 실수가 흔합니다. 노드 작업이 끝나면 exit로 빠져나오는 것을 한 동작으로 묶어 두는 습관이 오답을 막습니다.

공식 문서를 빠르게 활용한다 #

CKA는 시험 중 kubernetes.io/docs와 그 하위 문서 열람이 허용됩니다. 그래서 모든 YAML 필드나 긴 명령을 외울 필요는 없습니다. 다만 운영에 두 가지 원칙이 있습니다.

  • 검색으로 예시에 바로 간다. 문서 상단 검색창에 etcd backup,kubeadm upgrade,rbac처럼 키워드를 쳐서 예시 명령과 YAML로 바로 가는 동선을 손에 익힙니다. etcdctl 인증서 플래그, kubeadm upgrade 절차처럼 길고 외우기 어려운 명령은 문서에서 복사하는 편이 안전합니다.
  • 문서 시간도 시험 시간. 문서를 뒤지는 동안에도 타이머는 흐릅니다. 자주 쓰는 리소스는 generator로 뼈대를 즉시 만들고, 문서는 절차가 긴 작업이나 외우기 어려운 플래그를 확인하는 용도로 씁니다.

문서에서 YAML 스니펫을 복사할 때는 들여쓰기가 따라오므로, 붙여 넣은 직후 :set paste로 자동 들여쓰기 간섭을 끄는 것이 안전합니다.

자주 틀리는 패턴 #

운영자 실기에서 점수를 흘리는 단골 패턴입니다. 지식 부족보다 운영 실수로 잃는 점수가 더 많습니다.

1) context와 namespace 미전환 #

각 작업은 지정된 클러스터와 네임스페이스에서 풀어야 채점됩니다. 작업 설명에 제시되는 use-context 명령을 먼저 실행하지 않으면, 답을 맞게 만들어도 다른 클러스터에 만들어져 0점입니다. CKA는 클러스터가 여러 개라 이 실수가 특히 잦습니다.

k config use-context <작업에서 지정한 컨텍스트>
k config set-context --current --namespace=<작업 네임스페이스>

2) etcd 인증서 플래그 누락 #

etcdctl 명령은 ETCDCTL_API=3과 --cacert,--cert,--key 세 인증서 플래그가 모두 있어야 동작합니다. 하나라도 빠지면 인증 오류로 스냅샷을 뜨거나 복구하지 못합니다. 인증서 경로는 /etc/kubernetes/manifests/etcd.yaml의 --cert-file,--key-file,--trusted-ca-file에서 확인합니다.

ETCDCTL_API=3 etcdctl snapshot save /opt/snap.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

3) drain 옵션 누락 #

노드를 비울 때 --ignore-daemonsets를 빼면 DaemonSet Pod 때문에 명령이 멈추고, --delete-emptydir-data를 빼면 emptyDir을 쓰는 Pod에서 막힙니다. 업그레이드와 노드 정비 작업에서 이 두 옵션 누락이 단골입니다.

k drain node01 --ignore-daemonsets --delete-emptydir-data
# 작업이 끝나면 다시 스케줄 가능하게
k uncordon node01

4) static Pod 매니페스트 위치 혼동 #

control plane 컴포넌트(apiserver,etcd,scheduler,controller-manager)는 /etc/kubernetes/manifests/의 static Pod로 떠 있습니다. 이 디렉터리는 control plane 노드에 있으므로, 워커 노드에서 찾으면 보이지 않습니다. kubelet 설정의 staticPodPath가 바로 이 디렉터리를 가리킵니다. 파일을 디렉터리 밖으로 옮기면 kubelet이 해당 Pod를 내리고, 다시 넣으면 띄웁니다.

# control plane 노드에서
ls /etc/kubernetes/manifests/
# kubelet이 어느 경로를 보는지
grep staticPodPath /var/lib/kubelet/config.yaml

5) 업그레이드 순서 혼동 #

클러스터 업그레이드는 순서가 정해져 있습니다. control plane 먼저, 워커 나중이며, control plane 안에서도 kubeadm 업그레이드 후 kubelet,kubectl 순입니다. 노드는 한 대씩 drain → 업그레이드 → uncordon 순으로 진행합니다.

# 1) control plane 노드: kubeadm 먼저
kubeadm upgrade plan
kubeadm upgrade apply v1.xx.y
# 2) 같은 노드 drain 후 kubelet/kubectl 업그레이드, 재시작
k drain <cp-node> --ignore-daemonsets
# (apt/yum으로 kubelet kubectl 업그레이드)
systemctl daemon-reload && systemctl restart kubelet
k uncordon <cp-node>
# 3) 워커 노드는 kubeadm upgrade node 후 동일 절차

6) 부분 점수를 못 챙김 #

완벽하게 못 풀 작업도 만들 수 있는 데까지 만들어 두면 점수가 들어옵니다. 트러블슈팅에서 원인을 끝까지 못 고쳤더라도 진단한 내용을 반영해 가능한 수정을 적용해 두면 부분 점수가 잡힐 수 있습니다. 빈 상태로 두는 것이 가장 아깝습니다.

7) 작업을 끝까지 안 읽음 #

한 작업에 여러 조건이 붙는 경우가 많습니다. 스냅샷을 뜨라는 지시에 저장 경로까지 지정되어 있거나, RBAC 작업에서 특정 namespace 한정이라는 조건이 붙는 식입니다. 조건 하나를 빠뜨리면 부분 점수만 받습니다. 작업 설명의 모든 조건을 짚고 시작합니다.

8) 변경 후 적용,재시작 누락 #

YAML 파일만 고치고 apply를 안 하거나, static Pod 매니페스트를 고친 뒤 kubelet이 반영할 시간을 기다리지 않으면 클러스터에 반영되지 않습니다. 설정 파일을 바꾼 뒤에는 k apply -f 또는 systemctl restart kubelet까지 한 동작으로 묶습니다.

부분 점수와 검산 #

CKA는 작업 단위로 채점되며 일부 작업은 부분 점수가 있습니다. 그리고 작업을 끝낼 때마다 짧게 검산합니다. 운영자 작업은 “만들었다"가 아니라 “실제로 떴고 도는가"까지 확인해야 합니다.

# 만든 리소스가 실제로 떴는지
k get pod,deploy,svc -n <namespace>

# 노드 작업 후 노드가 Ready로 돌아왔는지
k get nodes

# control plane 컴포넌트가 다시 떴는지
k get pods -n kube-system

# 스냅샷 파일이 실제로 생겼는지
ls -l /opt/snap.db

검산은 30초 안에 끝나지만, “다 했다고 생각한 작업이 사실 실패해 있던” 가장 흔한 실점을 막습니다. 특히 static Pod를 고친 뒤에는 kubelet이 새 Pod를 띄우는 데 몇 초가 걸리므로, k get pods -n kube-system을 한 번 더 확인합니다.

헷갈리는 개념 쌍 #

작업 중 순간적으로 헷갈리기 쉬운 쌍을 한 줄 차이로 압축합니다.

쌍한 줄 차이
Role vs ClusterRolenamespace 한정 권한 vs 클러스터 전역,노드,PV 등 비네임스페이스 권한
RoleBinding vs ClusterRoleBinding한 namespace에 부여 vs 클러스터 전역 부여
taint/toleration vs nodeAffinity노드가 Pod를 밀어냄(toleration으로 허용) vs Pod가 노드를 골라 끌림
PV reclaim Delete vs RetainPVC 삭제 시 저장소까지 삭제 vs 데이터 보존하고 수동 회수
Service ClusterIP vs NodePort클러스터 내부 전용 vs 노드 포트로 외부 노출
drain vs cordon비우고 스케줄 차단 vs 새 스케줄만 차단(기존 Pod 유지)

taint/toleration과 affinity는 방향이 반대입니다. taint는 노드 쪽에서 Pod를 거부하고 toleration이 그 거부를 견디게 하는 반면, nodeAffinity는 Pod 쪽에서 특정 노드를 선호하거나 강제합니다. 둘을 함께 써야 “이 노드에는 이 Pod만” 같은 전용 배치가 완성됩니다.

도메인별 응시 직전 체크리스트 #

각 도메인에서 손이 바로 나와야 하는 핵심 명령과 절차입니다.

도메인 1: Cluster Architecture, Installation and Configuration (25%) #

  • kubeadm: kubeadm init,join, kubeadm token create --print-join-command
  • 업그레이드: kubeadm upgrade plan/apply, control plane 먼저,워커 나중
  • etcd: etcdctl snapshot save/restore에 인증서 플래그 세 개
  • RBAC: Role/ClusterRole,RoleBinding/ClusterRoleBinding, k auth can-i
  • 인증서,kubeconfig: kubeadm certs renew, /etc/kubernetes/pki 경로

도메인 2: Workloads and Scheduling (15%) #

  • k create deploy, k set image, k scale, k rollout status/undo
  • scheduling: nodeSelector,nodeAffinity,taint/toleration
  • requests/limits로 QoS 결정, LimitRange,ResourceQuota
  • ConfigMap/Secret: envFrom,valueFrom,volume 마운트

도메인 3: Services and Networking (20%) #

  • k expose로 Service, type ClusterIP/NodePort/LoadBalancer/ExternalName
  • Service selector와 Pod label 일치 확인
  • Ingress rules,paths,backend, IngressClass
  • CoreDNS 동작 확인, NetworkPolicy podSelector,policyTypes(기본 deny이해)

도메인 4: Storage (10%) #

  • PV/PVC 정적 프로비저닝, accessModes,capacity 일치
  • StorageClass와 동적 프로비저닝, reclaimPolicy(Delete/Retain)
  • PVC를 Pod에 volumeMounts,volumes로 연결
  • volume expansion(allowVolumeExpansion)

도메인 5: Troubleshooting (30%) #

  • Pod: k describe,k logs(--previous), Pending/CrashLoop/ImagePull/OOM 패턴
  • 노드: systemctl status kubelet,journalctl -u kubelet, NotReady,pressure
  • control plane: /etc/kubernetes/manifests/ static Pod, crictl ps로 컨테이너 확인
  • 네트워킹,DNS: k get ep로 endpoint 확인, CoreDNS Pod,Service
  • 인증서: openssl x509 -noout -dates로 만료 확인, kubeadm certs renew

온라인 감독 응시 직전 점검 #

CKA는 PSI 원격 터미널에 접속해 작업하는 온라인 감독 시험입니다. 시험 시작 전에 다음을 확인합니다.

신분증 #

  • 영문 표기가 있는 신분증 (여권 권장), 이름이 등록 정보와 정확히 일치
  • 감독관 채팅 안내에 따라 신분증 양면을 카메라에 제시

응시 환경 #

  • 책상 위 모든 물건 치움, 벽면 메모,포스터 제거
  • 듀얼 모니터는 한 대만 사용, 보조 화면 분리
  • 가족,룸메이트 출입 차단, 조용한 단독 공간 확보

시스템 #

  • 응시 30분 전 입실해 시스템 점검 통과
  • 백그라운드 앱,알림,VPN 종료, 안정적인 유선 네트워크 권장
  • 시험 시작 후 가장 먼저 alias k,do,자동완성,.vimrc 셋업, 첫 작업 전 context 확인

정리 #

이 글에서 잡은 것:

  • 2시간 운영. 작업당 배점이 우선순위. 배점 높고 손에 익은 것부터, 막히면 flag 후 다음, 과몰입 금지
  • 트러블슈팅 우선순위. 30% 도메인이라 점수가 크지만, 원인 추적이 길어지면 기준선에서 끊고 넘어감
  • 속도 셋업. alias k,do,now,자동완성,vim 들여쓰기,yq를 시작 1분 안에
  • context 최우선. CKA는 클러스터가 여러 개. 작업마다 use-context 먼저, 노드 작업 후 exit
  • 문서 활용. 검색으로 etcdctl,kubeadm 같은 긴 명령에 바로, 문서 시간도 시험 시간
  • 단골 실수. context/namespace, etcd 인증서 플래그, drain 옵션, static Pod 위치, 업그레이드 순서, 부분 점수, 작업 미완독, 적용,재시작 누락
  • 부분 점수와 검산. 만들 수 있는 데까지 만들고 k get nodes,k get pods -n kube-system으로 확인
  • 헷갈리는 개념 쌍, 5개 도메인별 핵심 절차, 온라인 감독 점검

다음: 풀스케일 실기 모의고사 #

#27 풀스케일 실기 모의고사 (전 도메인 통합 시나리오 + 해설)는 이 시리즈의 마지막 글입니다. 실제 시험과 비슷한 도메인 분포로 통합 시나리오를 풀고 상세 해설을 달겠습니다. 시험 환경처럼 시간을 재며 풀어 보고, 트러블슈팅과 클러스터 아키텍처처럼 비중 큰 도메인을 한 번 더 다지는 마지막 단계입니다.

X