[CKA Ch-08] 시험 직전 핵심 요약: 30분에 훑는 명령, YAML 뼈대, 함정

결론부터

1. 과제마다 호스트, 네임스페이스, 리소스 이름 세 가지를 먼저 확인합니다. 지정된 호스트로 ssh해서 풀고 끝나면 exit로 base에 돌아옵니다. ssh 안에서 다시 ssh할 수는 없습니다.
2. YAML은 처음부터 쓰지 않습니다. kubectl create와 run에 --dry-run=client -o yaml을 붙여 뼈대를 받고 생성 명령이 없는 객체(NetworkPolicy, PV, PVC, StorageClass, Gateway, HTTPRoute)는 허용 문서의 예제를 복사해 고칩니다. 필드 이름은 kubectl explain으로 찾습니다.
3. 공식 기준 120분에 15~20문항이면 문항당 6~8분이고 합격선은 66%입니다. 5분을 넘긴 과제는 표시하고 넘어가고 15분 알림이 오면 새 과제를 멈춥니다.
4. 비중이 가장 큰 트러블슈팅(30%)은 get, describe의 Events, logs --previous, 노드의 journalctl -u kubelet과 crictl 순서로 한 층씩 내려갑니다. API 서버가 죽었으면 kubectl 대신 crictl이나 /var/log/pods입니다.
5. 2024년 이전 자료의 답은 버전이 바뀌어 틀릴 수 있습니다. 스냅샷 확인과 복구는 etcdutl, 엔드포인트 확인은 EndpointSlice, 사이드카는 initContainers에 restartPolicy: Always, HPA는 --cpu=60%입니다.

Ch-00부터 Ch-07까지에서 시험 직전에 다시 볼 것만 뽑았고 근거는 링크한 글에 있습니다.

1. 시험 시작 5분

1-1. 호스트에 있는 도구와 열 수 있는 문서

LF Important Instructions 기준으로 과제용 ssh 호스트에는 아래 도구가 있고 시작 호스트(base)에는 없습니다.

Resources Allowed는 배포판 패키지를 설치해도 되지만 과제 수행에 필요하지는 않다고 적습니다. 패키지 저장소에 닿는지는 공식 문서에 없습니다. 그래서 jq 대신 -o jsonpath, -o custom-columns, yq로 연습합니다. 직접 만든 alias는 ssh로 호스트를 옮기면 사라집니다.

시험 중 열 수 있는 문서는 kubernetes.io/docs, kubernetes.io/blog, helm.sh/docs, gateway-api.sigs.k8s.io(CKA만) 네 곳과 과제의 Quick Reference 링크이고 시험 VM 안 Firefox로만 엽니다. 터미널 복사와 붙여넣기는 Ctrl+Shift+C/V이고 INSERT 키는 쓰지 않습니다.

1
type k            # "k is aliased to `kubectl'"이면 준비됨
2
complete -p k     # 자동완성이 k에도 걸려 있는지

둘 중 하나가 비어 있을 때만 kubectl Quick Reference의 줄을 넣습니다.

1
source <(kubectl completion bash)
2
alias k=kubectl
3
complete -o default -F __start_kubectl k

1-2. 과제마다 호스트와 네임스페이스 확인

1
ssh <과제에 적힌 호스트>           # ssh 안에서 다시 ssh는 안 됨
2
k -n <네임스페이스> get all        # 네임스페이스는 명령마다 붙인다
3
# ... 풀이 ...
4
exit                              # base로 돌아온다

권한이 필요하면 sudo -i나 명령마다 sudo를 씁니다. 문항마다 use-context를 쳤다는 이야기는 2024년 이전 후기이고 현재 안내는 ssh 방식입니다.

1-3. vim 설정

공식 안내가 말하는 것은 i로 입력하고 Esc로 나온다는 것뿐입니다. ~/.vimrc에 set expandtab tabstop=2 shiftwidth=2를 넣는 것은 관행이고 호스트마다 다시 넣습니다. 붙여 넣을 때 들여쓰기가 밀리면 :set paste를 켜고 붙여 넣은 파일은 yq . 파일명으로 문법부터 봅니다.

1-4. 뼈대는 --dry-run=client -o yaml

1
# 그 호스트에서만 쓰는 변수 (관행)
2
export do="--dry-run=client -o yaml"
3

4
k run pay-api --image=nginx:1.27 -n payment $do > pod.yaml
5
k create deploy pay-api --image=nginx:1.27 --replicas=2 -n payment $do > deploy.yaml
6
k expose deploy pay-api --port=80 --target-port=8080 -n payment $do > svc.yaml

자세한 목록은 Ch-01.5에 있습니다.

1-5. 필드 이름은 kubectl explain

1
k explain deploy.spec.strategy.rollingUpdate
2
k explain pod.spec.containers.resources --recursive | head -30
3
k explain networkpolicy.spec.egress.to
4
k explain boardjob.spec          # CRD 스키마도 보인다

YAML 파일에 namespace:를 적었다면 -n을 빼고 적지 않았다면 -n을 붙입니다. 두 값이 다르면 the namespace from the provided object ... does not match 오류가 납니다.

2. 영역별 외울 것 (v1.37 비중 순)

2-1. 트러블슈팅 30%

2-2. 클러스터 아키텍처, 설치, 구성 25%

자세한 내용은 Ch-02에 있습니다.

2-3. 서비스와 네트워킹 20%

자세한 내용은 Ch-04에 있습니다.

2-4. 워크로드와 스케줄링 15%

자세한 내용은 Ch-03에 있습니다.

2-5. 스토리지 10%

자세한 내용은 Ch-05에 있습니다.

3. 손으로 바로 쓸 YAML 뼈대

3-1. NetworkPolicy: 기본 거부와 DNS 허용

1
apiVersion: networking.k8s.io/v1
2
kind: NetworkPolicy
3
metadata:
4
  name: default-deny-all
5
  namespace: shop
6
spec:
7
  podSelector: {}            # 네임스페이스의 모든 Pod
8
  policyTypes: ["Ingress", "Egress"]   # 규칙 필드가 없으면 전부 거부
9
---
10
apiVersion: networking.k8s.io/v1
11
kind: NetworkPolicy
12
metadata:
13
  name: allow-dns
14
  namespace: shop
15
spec:
16
  podSelector: {}
17
  policyTypes: ["Egress"]
18
  egress:
19
  - to:
20
    - namespaceSelector:     # 같은 항목 안이라 AND
21
        matchLabels:
22
          kubernetes.io/metadata.name: kube-system
23
      podSelector:
24
        matchLabels:
25
          k8s-app: kube-dns
26
    ports:
27
    - { protocol: UDP, port: 53 }
28
    - { protocol: TCP, port: 53 }

3-2. StorageClass, PV, PVC

1
apiVersion: storage.k8s.io/v1
2
kind: StorageClass
3
metadata:
4
  name: local-storage
5
provisioner: kubernetes.io/no-provisioner   # 동적 프로비저닝 없음
6
volumeBindingMode: WaitForFirstConsumer
7
---
8
apiVersion: v1
9
kind: PersistentVolume
10
metadata:
11
  name: board-files-pv
12
spec:
13
  storageClassName: manual
14
  capacity: { storage: 10Gi }
15
  accessModes: ["ReadWriteOnce"]
16
  persistentVolumeReclaimPolicy: Retain
17
  hostPath: { path: /mnt/data }
18
---
19
apiVersion: v1
20
kind: PersistentVolumeClaim
21
metadata:
22
  name: board-files
23
  namespace: shop
24
spec:
25
  storageClassName: manual   # PV와 같게. 생략하면 기본 클래스가 붙는다
26
  accessModes: ["ReadWriteOnce"]
27
  resources:
28
    requests: { storage: 3Gi }

Pod 쪽은 volumes[].persistentVolumeClaim.claimName: board-files이고 PV 이름을 직접 적지 않습니다.

3-3. Gateway와 HTTPRoute

1
apiVersion: gateway.networking.k8s.io/v1
2
kind: Gateway
3
metadata:
4
  name: shop-gw
5
  namespace: shop
6
spec:
7
  gatewayClassName: <k get gatewayclass 결과>
8
  listeners:
9
  - name: http
10
    protocol: HTTP
11
    port: 80
12
    hostname: "shop.example.com"
13
---
14
apiVersion: gateway.networking.k8s.io/v1
15
kind: HTTPRoute
16
metadata:
17
  name: shop-route
18
  namespace: shop
19
spec:
20
  parentRefs:
21
  - name: shop-gw
22
  hostnames: ["shop.example.com"]
23
  rules:
24
  - matches:
25
    - path: { type: PathPrefix, value: /orders }
26
    backendRefs:
27
    - name: order-api
28
      port: 80

가중치는 backendRefs[].weight, 헤더 매칭은 matches[].headers입니다. 예제는 시험 중 열 수 있는 gateway-api.sigs.k8s.io의 HTTP routing 가이드에 있습니다(Ch-04).

3-4. RBAC 명령형

1
k create sa order-api -n shop
2
k create role config-reader -n shop --verb=get,list,watch --resource=configmaps
3
k create rolebinding order-api-config -n shop --role=config-reader --serviceaccount=shop:order-api
4

5
k auth can-i list configmaps -n shop --as=system:serviceaccount:shop:order-api   # yes
6
k auth can-i --list -n shop --as=system:serviceaccount:shop:order-api

--as의 사용자 이름은 system:serviceaccount:(단수)이고 그룹은 system:serviceaccounts:(복수)입니다.

4. 절차형 과제 체크리스트

4-1. kubeadm 업그레이드

1
[첫 컨트롤 플레인]
2
1. 패키지 저장소를 목표 마이너(pkgs.k8s.io의 v1.37 경로)로 바꾼다
3
2. apt-mark unhold kubeadm -> apt-get install kubeadm='1.37.x-*' -> apt-mark hold kubeadm
4
3. kubeadm upgrade plan -> kubeadm upgrade apply v1.37.x
5
4. kubectl drain <노드> --ignore-daemonsets
6
5. kubelet, kubectl 패키지 교체 -> systemctl daemon-reload -> systemctl restart kubelet
7
6. kubectl uncordon <노드>
8

9
[나머지 컨트롤 플레인, 워커]
10
kubeadm 패키지 교체 -> kubeadm upgrade node -> 4~6 반복

컨트롤 플레인을 모두 끝낸 뒤 워커로 갑니다. kubelet은 kube-apiserver보다 새로울 수 없기 때문입니다. drain은 kubectl이 있는 호스트에서, apt와 kubeadm은 해당 노드에서 실행합니다. 3번이 성공하면 [upgrade] SUCCESS! A control plane node of your cluster was upgraded to "v1.37.1". 꼴의 줄이 나옵니다(Ch-02).

4-2. etcd 백업과 복구

etcdctl은 etcd 과제 호스트에 있을 가능성이 높지만 공식 목록에 없고 etcdutl은 근거가 없으니 which etcdctl etcdutl부터 봅니다.

1
# 0) 인증서 경로부터 확인
2
sudo grep -E 'cert|key|trusted|data-dir' /etc/kubernetes/manifests/etcd.yaml
3

4
# 1) 백업: 동작 중인 멤버에 접속하므로 etcdctl
5
sudo etcdctl --endpoints=https://127.0.0.1:2379 \
6
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
7
  --cert=/etc/kubernetes/pki/etcd/server.crt \
8
  --key=/etc/kubernetes/pki/etcd/server.key \
9
  snapshot save /opt/backup/etcd-snapshot.db
10

11
# 2) 확인: etcdutl
12
etcdutl --write-out=table snapshot status /opt/backup/etcd-snapshot.db
13

14
# 3) 복구: 새 디렉터리에 푼다
15
sudo etcdutl --data-dir /var/lib/etcd-restore snapshot restore /opt/backup/etcd-snapshot.db
16

17
# 4) etcd.yaml에서 name: etcd-data 볼륨의 hostPath.path를 /var/lib/etcd-restore로 바꾼다
18
sudo vi /etc/kubernetes/manifests/etcd.yaml
19

20
# 5) kubelet이 etcd를 다시 띄우는지 확인. 1분 넘게 걸릴 수 있음
21
sudo crictl ps | grep etcd
22

23
# 6) API 서버, 컨트롤러 매니저, 스케줄러 재시작: 매니페스트를 잠시 밖으로
24
sudo mkdir -p /tmp/cp && sudo mv /etc/kubernetes/manifests/kube-{apiserver,controller-manager,scheduler}.yaml /tmp/cp/
25
sleep 20 && sudo mv /tmp/cp/*.yaml /etc/kubernetes/manifests/
26
kubectl get deploy -A          # 복구한 시점의 객체가 보이는지
27

28
# 7) 노드마다 kubelet, 그리고 kube-proxy 재시작
29
sudo systemctl restart kubelet
30
kubectl -n kube-system delete pod -l k8s-app=kube-proxy

함정은 셋입니다.

• 6번을 빼면 etcd는 복구됐는데도 kubectl에 옛 상태가 보이지 않습니다. 7번을 빼면 워커의 새 Pod가 Pending에 머물거나 Service IP 접속이 안 될 수 있습니다(kind와 Lima VM에서 확인).
• 복구 뒤 kubeadm upgrade apply를 돌리면 kubeadm-config의 etcd.local.dataDir로 etcd.yaml이 다시 만들어지니 그 값도 새 경로로 고칩니다.
• ETCDCTL_API=3은 etcd 3.4부터 기본값이라 빼도 됩니다. etcdctl 3.7.0은 이 변수를 붙이면 unrecognized environment variable 경고를 찍습니다.

자세한 절차는 Ch-02에 있습니다.

4-3. 노드 drain

1
k drain <노드> --ignore-daemonsets [--delete-emptydir-data] [--force]
2
k get node                       # SchedulingDisabled
3
k uncordon <노드>

uncordon해도 내보낸 Pod는 돌아오지 않습니다.

4-4. 인증서 확인과 갱신

1
sudo kubeadm certs check-expiration
2
sudo kubeadm certs renew all
3
# renew 출력이 지목하는 네 구성요소 재시작: 매니페스트를 잠시 밖으로
4
sudo mkdir -p /tmp/cp && sudo mv /etc/kubernetes/manifests/{etcd,kube-apiserver,kube-controller-manager,kube-scheduler}.yaml /tmp/cp/
5
sleep 20 && sudo mv /tmp/cp/*.yaml /etc/kubernetes/manifests/
6

7
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -subject -issuer -enddate
8
# kubelet 클라이언트 인증서는 check-expiration 목록에 없다
9
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -subject -dates

kubeadm certs renew all의 출력은 kube-apiserver, kube-controller-manager, kube-scheduler, etcd 네 구성요소의 재시작을 요구합니다. kubelet 클라이언트 인증서의 정상 subject는 O = system:nodes, CN = system:node:<노드 이름>이고 만료됐을 때의 복구 절차는 Ch-06 1-4절에 있습니다.

4-5. CSR 승인

1
openssl genrsa -out settle-user.key 3072
2
openssl req -new -key settle-user.key -out settle-user.csr -subj "/CN=settle-user/O=finance"
3
cat settle-user.csr | base64 | tr -d "\n"     # CSR 객체의 spec.request
4

5
k apply -f settle-user-csr.yaml               # signerName, usages: [client auth]
6
k certificate approve settle-user
7
k get csr settle-user -o jsonpath='{.status.certificate}' | base64 -d > settle-user.crt
8
k config set-credentials settle-user --client-key=settle-user.key \
9
  --client-certificate=settle-user.crt --embed-certs=true
10
k config get-clusters                          # set-context --cluster에 넣을 실제 이름
11
k config set-context settle-user --cluster=<위 이름> --user=settle-user

kube-controller-manager가 자동 승인하는 내장 서명자는 kubernetes.io/kube-apiserver-client-kubelet뿐입니다. serverTLSBootstrap: true로 받는 kubelet 서빙 인증서 CSR도 손으로 승인합니다.

4-6. static Pod 장애 복구

1
1. ssh <컨트롤 플레인 노드>
2
2. sudo crictl ps -a | grep <구성요소>        종료된 컨테이너까지 (crictl이 없으면 /var/log/pods)
3
3. sudo crictl logs <컨테이너 ID>            첫 오류 줄
4
   (컨테이너가 아예 없으면) sudo journalctl -u kubelet -n 50   YAML 파싱 오류
5
   (컨테이너가 없고 Pod가 ImagePullBackOff면) image 태그 오류
6
4. sudo cp <매니페스트> /etc/kubernetes/backup/   백업은 manifests 밖에
7
5. 플래그 오타, 인증서 경로와 hostPath 마운트, --etcd-servers 포트, image 태그, 들여쓰기 확인
8
6. 저장 후 crictl ps로 새 컨테이너가 뜰 때까지 기다린 뒤 kubectl

kubectl 전체 실패는 kube-apiserver나 etcd, Pod 미생성은 kube-controller-manager, 이벤트 없는 Pending은 kube-scheduler를 의심합니다. kubectl delete pod kube-apiserver-<노드>는 mirror Pod만 지웁니다(Ch-06 2절).

4-7. 런타임 패키지 설치

1
1. ssh <노드>, sudo dpkg -i <과제가 준 .deb>
2
2. sudo systemctl daemon-reload            새 유닛 파일 읽기
3
3. sudo systemctl enable --now <서비스>     cri-dockerd는 cri-docker.service
4
4. systemctl status <서비스>, ls <소켓>     cri-dockerd 기본 /run/cri-dockerd.sock
5
5. kubeadm init/join --cri-socket unix:///run/cri-dockerd.sock

1.35가 containerd 1.x를 지원하는 마지막 버전이니(v1.35 릴리스 글) 1.37 노드는 containerd 2.3 이상으로 맞춥니다(containerd 호환표 기준. 1.7은 2026-09-30 지원 종료). sysctl은 /etc/sysctl.d/에 쓰고 sysctl --system으로 적용합니다(Ch-02).

5. 자주 틀리는 것 22개

왼쪽은 옛 자료나 흔한 착각, 오른쪽은 문서로 확인한 내용입니다.

6. 당일 시간 배분

과제 하나는 호스트 이동, 뼈대 생성, 적용, 검증, exit 순서로 풉니다. 알림은 30분, 15분, 5분 남았을 때 옵니다. 표시 기능은 LF ExamUI 문서에서 확인하지 못했고 후기들이 적은 것을 옮겼습니다. 당일 체크리스트와 D-30 계획은 Ch-07에 있습니다.

범위와 한계

• 이 글은 Ch-00~Ch-07과 Ch-01.5의 요약입니다. 요약에서 조건이 빠졌다면 링크한 원래 글이 기준입니다.
• 명령과 YAML은 kind v1.37과 Lima VM의 kubeadm 1.36→1.37 클러스터에서 2026년 10월에 직접 돌려 확인했습니다. 3-2, 3-3절의 스토리지와 Gateway 뼈대는 문서 예시를 옮긴 것이라 연습 클러스터에서 확인한 뒤 씁니다.
• etcdutl과 crictl이 시험 호스트에 있는지는 확인하지 못했습니다.
• metrics-server와 VPA가 시험 클러스터에 미리 설치되어 있는지는 확인하지 못했습니다.
• etcd 백업 복구와 kubeadm 업그레이드가 개정 후 출제되는지는 확인하지 못했습니다. “클러스터 수명주기 관리”에 걸려 남겼습니다.
• 버전 기준은 Kubernetes v1.37, etcd 3.7, Helm 4입니다. LF 문서는 새 마이너 출시 후 약 4~8주 안에 시험 환경을 맞춘다고 적지만 1.36은 건너뛰었으니 시험 전에 Important Instructions의 버전 표기를 봅니다. v1.38은 2026-12-16 출시 예정(sig-release 일정)이라 2027년 1~2월 응시자는 특히 다시 확인합니다.

참고 자료

• CNCF, CKA Curriculum v1.37
• Linux Foundation, Important Instructions: CKA and CKAD, Resources Allowed, FAQ
• Wayback Machine, Important Instructions 2025-02-11 판, 2025-03-28 판
• Kubernetes, kubectl Quick Reference, Version Skew Policy, Upgrading kubeadm clusters, Certificate Management with kubeadm, Operating etcd clusters for Kubernetes
• Kubernetes, Using RBAC Authorization, Certificates and Certificate Signing Requests
• Kubernetes, Network Policies, EndpointSlices, Persistent Volumes, Storage Classes, Create static Pods
• Kubernetes 블로그, v1.35, v1.37, Ingress NGINX Retirement
• etcd, CHANGELOG-3.6
• Gateway API, HTTP routing
• Helm, Helm 4 Overview