CKA 시험 후기

728x90

2022년에 CKA 시험을 봤던 경험을 기억 속에서 꺼내어 후기를 작성해본다.

 

[시험 신청]

시험은 익히 알려있는 것과 같이 LF 홈페이지에서 신청할 수 있다.

시험 비용은 약 25만원? 정도 했던 것 같다.

 

[시험 준비]

시험 준비는 Youtube의 따배런 이성미 강사의 영상을 보면서 주로 공부했다.

초반에는 도대체 Container가 무엇이고, 왜 이게 좋은지 이해가 전혀되지 않아 어려웠다.

 

그런데 생각해보니까 K8S와 Cloud가 비슷 맥락이 있구나~ 하는 느낌을 많이 받기 시작했고,

그때부터 Cloud에 대입하면서 이해했고, 조금씩 눈이 띄어진 것 같다.

 

또 당시에는 브라우저의 북마크를 사용할 수 있었기 때문에 검색 시간을 최소화하고자,

북마크를 미리 준비하여 문제에 맞는 북마크를 사용할 수 있게 사전에 준비했다.

 

PSI Browser 도입 이후에는 북마크 사용이 불가능하다.

 

연습문제

 

1. ETCD Backup & Restore

 

1) master로 ssh 로그인

$ k config current-context
$ ssh {위 명령어 결과값} // 보통 ssh k8s-master

 

2) etcd Backup (key와 저장 경로는 문제에서 제공)

ETCDCTL_API=3 etcdctl --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 \\
  snapshot save /data/etcd-snapshot.db

 

3) etcd restore

ETCDCTL_API=3 etcdctl \\
--data-dir /var/lib/etcd-revious \\
snapshot restore /data/etcd-snapshot-previous.db

 

 

4) kubectl get pod -n kube-system

관리자 Static POD는 아래 경로에 Yaml파일이 저장되어 있음

하단에 hostPath가 기본이 /var/lib/etcd로 되어 있다.

 

경로 : /etc/kubernetes/manifests/etcd.yaml

이걸 restore에서 지정한 data-dir 경로로 변경

정상 반영되는지 docker 명령어로 상태 UP 확인

watch -n 1 "docker ps -a | grep etcd"

 

 

2. Pod 생성

 

문제 : 네임스페이스 만들고 그 네임스페이스에 파드 만들기

조건 : namespace name: ecommerce

pod Name : eshop-main
image: nginx:1.17
env: DB=mysql

 

## 네임 스페이스 생성
$ kubectl create namespace ecommerce

## 문법 체크
$ kubectl run eshop-main -—image=nginx:1.17 -—env=DB=mysql -—namespace=ecommerce
(—dry-run=client로 생성 체크)

## 위에서 이상 없으면 --dry-run=client 빼고 명령어 실행 
$ kubectl run eshop-main --image=nginx:1.17 --env=DB=mysql --namespace=ecommerce

 

3. Static Pod 생성

 

문제 : 특정 노드에 Static POD생성

조건 : pod name : web
          image : nginx

$ kubectl run web —image=nginx —dry-run=client -o yaml

ssh {worker node}
sudo -i
Static pod 위치 정보 확인

cat /var/lib/kubelet/config.yaml

....

staticPodPath: /etc/kubernetes/manifests
Static Pod 생성
cd /etc/kubernetes/manifests

## web.yaml

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
  - image: nginx
    name: web

control plan으로 와서 kubectl get pod로 생성 확인

 

 

4. multi-container POD

 

문제 : multi pod를 만들고 그 안에 nginx,redis,memcached 컨테이너를 생성하여라.

조건: lab004

작업 클러스터 : hk8s

 

# context 변경
$ kubectl config use-context hk8s

# pod 생성 명령어 dry-run
$ kubectl run lab004 —image=nginx —dry-run=client -o yaml > multi.yaml

#multi.yaml
apiVersion: v1
kind: Pod
metadata:
  name: lab004
spec:
  containers:
  - image: nginx
    name: nginx
  - image: redis
    name: redis
  - image: memcached
    name: memcached

kubectl apply -f multi.yaml

 

5. Side-car Container Pod 실행

 

 

6. Deployment & Pod Scale

 

문제 : eshop-order 파드를 확장 시켜라

조건

작업 클러스터 : k8s

네임스페이스 : devops

디플로이먼트명 : eshop-order

$ kubectl config use-context k8s
$ kubectl get namespaces devops
$ kubectl get deployments.apps -n devops
답 : $ kubectl scale deployment eshop-order -n devops --replicas=5
확인 : $ kubectl get pod -n devops

 

문제 : deployment 생성하고 Scaling 하기

조건

작업 클러스터 : k8s

TASK

• name : webserver
• 2 replicas
• label: app_env_stage=dev
• container name: webserver
• container image: nginx:1.14

Scale Out Deploument

• Scale the deployment webserver to 3 pods

$ kubectl create deployment webserver --image=nginx:1.17 --replicas=2 
--dry-run=client -o yaml > webserver.yaml
1. yaml 파일에서 lable app_env_stage: dev 값으로 수정
2. Container name 변경 : 기본 nginx > 수정 webserver

$ kubectl apply -f webserver.yaml
확인 : $ kubectl get deploy 

$ kubectl scale deployment webserver --replicas=3
확인 : $ kubectl get pod --show-lables 로 Pod 개수 확인

 

7. Rolling update & Roll back

문제 : Rolling update & back 하세요.

조건

클러스터 : k8s

Deployment 생성

name : nginx-app

nginx:1.11.10-alpine

replicas 3

nginx 버전 업데이트 : 1.11.13-alpine

$ kubectl config user-context k8s
$ kubectl create deployments nginx-app --image=nginx:1.11.10-alpine --replicas=3 --dry-run=client
$ kubectl get deploy nginx-app
$ kubectl get pod | grep nginx-app

## rolling update

$ kubectl set image deployment nginx-app nginx=nginx:1.11.13-alpine --record
$ kubectl rollout status deploy nginx-app
$ kubectl describe deploy nginx-app
$ kubectl rollout history deploy nginx-app

## rolling back

$ kubectl rollout undo deploy nginx-app
$ kubectl rollout status deploy nginx-app
$ kubectl describe deploy nginx-app

 

8. nodeselector

문제 : Schedule a pod

조건

클러스터 : k8s

name : eshop-store

image : nginx

node selector : disktype-ssd

$ kubectl config user-context k8s
## worker node label 확인
$ kubectl get nodes --show-labels
$ kubectl get nodes -L disktype # disktype 컬럼 추가하여 조회

## pod 실행을 위해 dry-run으로 yaml 형식으로 추출
$ kubectl run eshop-store --image=nginx --dry-run=client -o yaml

## nodeSelector 추가

apiVersion: v1
kind: Pod
metadata:
  name: eshop-store
spec:
  containers:
  - image: nginx
    name: eshop-store
  nodeSelector:
    disktype: ssd

## pod 생성
$ kubectl apply -f eshop-store.yaml
$ kubectl get pod -L disktype
$ kubectl get pod --show-label

 

9. node 관리

node 관리 관련 명령어

$ kubectl cordon {node name} ## 지정한 노드는 스케줄링에서 제외
$ kubectl uncordon {node name} ## 지정한 노드는 스케줄링에서 합류

$ kubectl drain {node name} 
## 요청 노드에 위치한 모든 리소스 삭제하고 다른 워커노드에서 재생성 단, 단독 pod의 경우 타 node에 생성되지 않고 삭제됨
## kube CNI등 관리 리소스의 경우 삭제할 수 없어 --ignore-daemonsets 을 추가하면 동작한다.

문제 : k8s-worker1 unavailable and reschedule

## k8s-worker1에 있는 자원 삭제 또는 리스케줄링
$ kubectl drain k8s-worker1 --ignore-daemonsets --force --delete-emptydir-data
## --delete-emptydir-data = 로컬 디스크를 사용할 경우 표시되므로 표시되면 추가해서 삭제하면 됨

$ kubectl get pod -o wide ## k8s-worker2로 이동되었는지 확인
$ kubectl get node ## k8s-worker1에 스케줄링이 정지되었는지 확인

 

10. node 정보 수집

문제 1: Ready 상태의 node를 찾아 카운트하여 /var/CKA2022/RN0001에 기록하되 tainted NoSchedule은 제외

$ kubectl get nodes | grep -iw ready ## status가 ready인것을 추출
$ kubectl describe node {node name} | grep -i NoSchedule
$ kubectl descirbe node {node name} | grep -i taints

echo "1" > /var/CKA2022/RN0001

 

문제2: Ready 상태의 노드가 몇개인지 확인하여 /var/CKA2022/NODE-Count에 카운트

# ready 노드 추출 > 갯수 카운트 > 카운트 입력
$ kubectl get node | grep -iw ready | wc -l > /var/CKA2022/NODE-Count

 

11. deployments & expose

문제 : front-end 80포트의 nginx에 대해 http라는 이름을 추가하여 reconfigure하고,

front-end-svc를 새로 만들고 http이름을 추가한 서비스를 만들고 nodeport를 지정

$ kubectl get deploy front-end

## 문제 환경 yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: front-end
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        name: http

## ports 네임 지정, service 생성 yaml 추가, service name 지정, type 지정
## front-end.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: front-end
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        name: http
        ports:
        - containerPort: 80
          name: http

---

apiVersion: v1
kind: Service
metadata:
  name: front-end-svc
spec:
  type: NodePort
  selector:
    run: nginx
  ports:
  - name: http
    port: 80
    targetPort: http

$ kubectl apply -f front-end.yaml
$ kubectl get pod
$ kubectl get node
$ curl http://{node name}:{nodeport}

 

12. Pod Log 추출

문제: file not found 라는 로그를 custom-app pod에서 추출하여 /var/CKA2022/podlog에 입력

조건: cluster k8s

$ kubectl config user-context k8s
$ kubectl get pod custom-app
$ kubectl logs custom-app | grep 'file not found' > /var/CKA2022/podlog

cat /var/CKA2022/podlog 확인

 

13. CPU 사용량이 높은 Pod 검색

$ kubectl top pods -l {lable}
$ kubectl top pods -l {lable} --sort-by=cpu ## 지정한 라벨에 해당하는 pod 중 CPU 높은 노드 출력
$ echo "첫번째 파드" > /var/CKA2022/cpu_load_pod.txt

tip : 가장 높은 CPU pod name 커맨드 한줄로 뽑기
$ kubectl top pod -l {label} --sort-by=cpu | head -n 2 | grep -v NAME | awk '{print $1}' > /var/CKA2022/cpu_load_pod.txt

1. init 컨테이너를 포함한 Pod 운영
2. NodePort 서비스 생성

문제 : NodePort Service 생성

조건

context : k8s

포트번호 : 32767

label : app: webui

image : nginx

$ kubectl config use-context k8s
$ kubectl get pod --selector app=webui --show-labels ## app=webui 라벨이 지정된 파드 추출

## webui.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: webui
  ports:
    - port: 80
      targetPort: 80
      nodePort: 32767

$ kubectl get svc -o wide ## nodeport 확인

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE   SELECTOR
kubernetes   ClusterIP   198.19.128.1     <none>        443/TCP        34d   <none>
my-service   NodePort    198.19.131.206   <none>        80:32767/TCP   15s   app=webui

curl http://{worker node}:32767
#nginx 기본 페이지 출력 확인

 

14. Service Account 생성

문제 : Service Account 생성 후 특정 namespaces에 맵핑

조건

Account name : john

namespace : development

# service account 생성
$ kubectl create serviceaccount john --dry-run=client -o yaml > sa.yaml
$ kubectl create -f sa.yaml

## role command 형식
$ kubectl create role developer --resource=pods --verb=create --namespace=development

## role.yaml 파일 형식
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-role-binding
  namespace: development
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: developer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: john

## rolebinding command 형식

$ kubectl create rolebinding developer-role-binding --role=developer --user=john --namespace=development

## rolebinding yaml 형식

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: developer-role-binding
  namespace: development
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: developer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: john

 

15. Node 상태 확인

문제 : 특정 Node의 상태가 Ready가 아닌 것을 확인하여 Ready 상태가 되도록 해결하라

## 문제 노드가 k8s-worker1 이라고 가정한다.

$ k get node
$ ssh k8s-worker
$ sudo -i
$ systemctl status kubelet
$ systemctl start kubelet
$ systemctl statsu kubelet (active 확인)
$ exit

$ k get node
## k8s-worker1 ready 확인

• 시험 당일

지금은 PSI Browser가 있어서 프로그램에 접속해서 시험을 보지만, 당시에는 Chrome 확장 도구를 추가해서 시험을 봤다.

확장 도구여서 그런지 웹 캠에서 받아오는 화질이 매우 나빠서 영문 면허증의 글씨를 알아 볼 수 없을 정도…

(PSI Browser로 바뀐 후에는 생각보다 화질이 좋은듯)

 

노트북의 웹캠으로 신원 확인을 하고 시험관한테 switch device를 외치며 데스크탑으로 다시 돌아왔던 기억이 있다.

(지금은 접속 때마다 감독관이 바뀌어 이런 방법은 불가능하다.)

 

또 생각보다 환경 체크를 꼼꼼하게 한다.

바닥과 천장 그리고 벽 4면을 다 보여줘야 하고, 키보드, 마우스 패드 밑을 보여줘야 한다거나…;;;

 

하이라이트는 시험 중에 시험을 멈추고 두 손을 들어 스마트 기기를 몰래 착용했는지 시험 중 2번 정도 체크한다.

시험 난이도는 위에 연습 문제와 비슷한 수준으로 출제되었고,

여러 블로그들에서 작성된 것과 달리 생각보다 시험 환경이 나쁘지 않아서 쉽게 치룰 수 있었다.

• 시험 결과

생각보다 준비하면서 애도 먹었고, 업무에 치여 공부를 못했던 시간이 많아,

불안했지만 다행히 꽤 높은 점수로 합격했다.