본문 바로가기

프로그래밍/kubernetes

CKA 연습문제 풀이 정리(1)

여기에서 언급하는 연습문제는 Certified Kubernetes Administrator (CKA) with Practice Tests 강의의 연습문제를 풀어가는 과정에서 관련 내용을 정리해본 것이다. 모든 문제 풀이에 있어서 공통적으로 해야 할 행동(?)은 어떤 값을 설정하는 부분에 대해서는 타이핑 하지 말고 복사해서 붙여넣기 할것. 옵션 같은 경우 오타가 나면 명령어 자체가 실행이 안되는데다가 거의 모든 상황에서 --help 하면 옵션이 나오기 때문에 그걸 보고 수정하면 되지만 어떤 옵션에 값을 설정하는 작업에 있어서는 값 부분에 오타가 나면 입력한값 그대로 적용되는데다가 그걸로 문제 풀이가 틀려지기 때문에 복붙하는 방식으로 진행하는게 안전하다(복사할때 개행문자 안들어가게 블록 드래그 잘 할것) 

 

Lightning Lab - 1

 

1번 문제 : kubeadm을 이용해서 kubernetes cluster를 업그레이드 하는 문제

Upgrading kubeadm clusters 에 나온 내용대로 그대로 따라하면 된다. 단 버전 표기만 문제에 맞춰서 진행하면 된다.

 

2번 문제

특정 namespace에 있는 deployment 목록을 출력하는 것이었는데 양식을 정해준 문제였다. 각 항목의 타이틀을 DEPLOYMENT, CONTAINER_IMAGE, READY_REPLICAS, NAMESPACE 이렇게 4개로 출력하게 하고 여기에 deployment 이름, container에서 사용된 이미지 이름, replicas에서 ready 갯수, namespace 이렇게 출력하며 deployment 이름으로 순차정렬 해서 보여지도록 하는 문제였다. 여기서 JsonPath 라는걸 처음 사용했다. 강좌 동영상에서 jsonpath에 대한 강의가 있긴 했었는데 별로 중요한게 아닐꺼라 생각하고 건너뛰었더니만..ㅠㅠ 

일단 답을 먼저 보여줘야 jsonpath 에 대한 설명이 쉬울것 같아서 그것부터 보여주겠다

kubectl -n admin2406 get deployment -o custom-columns=DEPLOYMENT:.metadata.name,CONTAINER_IMAGE:.spec.template.spec.containers[].image,READY_REPLICAS:.status.readyReplicas,NAMESPACE:.metadata.namespace --sort-by=.metadata.name > /opt/admin2406_data

-o 옵션에 custom-columns 를 설정해서 column 에 대한 customizing 을 하겠다고 알려주고 여기에 어떻게 customizing을 하는지 알려주면 된다. 처음에 보면 DEPLOYMENT:.metadata.name 이렇게 있는데 이 의미는 kubectl get을 통해 결과를 보여줄때 첫번째 컬럼을 deployment 이름을 보여주며 그 컬럼의 Header를 DEPLOYMENT로 표기하겠다는 의미이다. 그리고 :을 붙인뒤에 그 다음에 실제 deployment에서 어떤 항목을 보여줄지를 결정하게 되는데 여기서 사용하는 표기법이 JsonPath이다. yaml 구조를 표현하는것과 차이가 없다. 다만 시작할때 .을 먼저 붙이고 시작한다는게 차이였다. 그리고 deployment의 container가 배열이기 때문에 .spec.template.spec.containers[].image 이런 식으로 사용했는데 정작 나는 0번째라는 것을 밝히기 위해 .spec.template.spec.containers[0].image 이런 식으로 사용했다. 답을 푸는 방법은 특정 deployment를 yaml 형식으로 보기 위해 kubectl get deployment deploy01 -o yaml 이런 식으로 명령을 내려서 deployment에 대한 yaml 구조를 파악한뒤 보여주고자 하는 항목을 거기서 보고 그걸 jsonpath(기존 yaml 멤버 표기법 앞에 .을 하나 더 찍음)로 바꿔서 지정하는게 다 였다. 그리고 여러개의 컬럼을 수정해야 했기 때문에 각 컬럼을 ,(콤마)로 연결해서 custom-columns 옵션 값을 설정했다. 정렬을 하는 방법은 --sort-by 옵션에 정렬 기준이 되는 항목을 jsonpath 표기법으로 적용해서 진행했다. 이렇게 실행하면 이런 형태로 실행 결과가 보여지게 된다.

 

DEPLOYMENT CONTAINER_IMAGE READY_REPLICAS NAMESPACE
deploy01 nginx:1.16 1 admin2406
deploy02 redis 1 admin2406
deploy03 busybox 2 admin2406
deploy04 busybox 1 admin2406

 

3번 문제는 잘못된 kubeconfig 파일을 수정해서 이를 반영하는 것이었다. kubeconfig 파일 위치랑 파일명은 문제에서 알려줬다. 일단 kubectl cluster-info 를 실행하면 다음과 비슷한 형태가 나온다(IP 정보는 다를수 있음)

 

Kubernetes control plane is running at https://192.168.101.11:6443
KubeDNS is running at https://192.168.101.11:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

 

여기서 master node에서 실행중인 kube-apiserver를 접속하기 위한 주소(6443번 포트를 사용하는)를  보여주고 있는데 잘못된 kubeconfig 파일은 이 포트번호가 다른 번호로 설정되어 있었다. 그래서 이 번호를 수정해준뒤 kubectl cluster-info --kubeconfig /root/admin.kubeconfig 를 실행하여 해당 설정파일로 적용되도록 했다

 

4번 문제는 deployment를 생성한뒤 해당 deployment의 이미지를 수정하되 이 수정사항을 기록되게끔 하는 것이었다.

kubectl set image deployment/nginx-deploy nginx=nginx:1.17 --record 이렇게 실행하여 수정 사항이 기록되게끔 한다.

이렇게 기록된 내용은 kubectl rollout history deployment/nginx-deploy 를 실행하여 기록되었는지 확인할 수 있다

 

5번 문제는 Pod이 정상동작 하지 않아 발생한 문제인데 Pod이 volume으로 pvc를 사용하는 상황이었다. pvc와 이를 연결해야 할 pv가 맞지 않아서 pvc를 사용하는 Pod이 Pending 상태였던것이었다. 그래서 pvc와 pv가 연결이 될 수 있게끔 pvc 내용을 pv에 맞게 수정하고 pvc의 이름도 Pod에서 사용하는 pvc 이름으로 맞춰주어서 pvc를 수정했다(문제에서 pv를 수정하지 말라고 언급을 했기 때문에 결국 pv를 놔두고 pv를 기준으로 해서 pvc를 pv에 맞춰서 수정했다). pvc 파일은 kubectl get pvc pvc이름 -o yaml > pvc.yaml 이런 식으로 yaml로 뽑은뒤 파일을 수정하는 식으로 진행했다.

 

6번 문제는 문제에서 지정한 파일로 ETCD를 백업하라는 명령이었다. ETCD 백업 명령은 외우기는 애매해서 일단 다음과 같이 정리했다.

- export ETCDCTL_API=3 을 먼저 실행한다(이 부분은 Backing up an etcd cluster 에서 언급되고 있기 때문에..다만 링크된 문서에서는 export 명령을 이용한 환경변수 설정이 아닌 etcdctl 명령을 사용하기 전에 항상 ETCDCTL_API=3를 실행하는 식으로 되어 있다)

- ETCD 백업을 위해 etcdctl --help 명령을 실행하면 etcdctl 에 대한 도움말이 나오는데 거기서 COMMANDS 항목을 보자. 거길 보면 다음과 같은 내용이 있다.

 

snapshot save           Stores an etcd node backend snapshot to a given file

 

대강 번역해보면 etcd node 백엔드 스냅샷을 주어진 파일에 저장한다고 하니 이게 백업이란 느낌(?)이 올것이다. 그리고 OPTIONS 항목을 읽어보면 인증서 관련으로 3개의 옵션이 있다.(--cacert, --cert, --key) 모든 명령어들이 그런건 아니지만 인증서 관련으로 쓰이는 단어는 공통적으로 4가지 단어가 사용된다. ca, cert, key, pki 이 4가지 단어는 인증서와 관련된 단어로 자주 쓰이기 때문에 이 단어들이 들어간거면 인증서 관련 옵션이라 보면 되겠다. 이제 /etc/kubernetes 디렉토리에 가보자. 그러면 pki 디렉토리가 있음을 확인할 수 있다. 느낌 온다. 여기 들어가보자. 그러면 etcd 디렉토리가 그 안에 있음을 확인할 수 있다. etcd 관련이겠구나..하는 느낌이 온다. 이제 또 그 안을 들어가보자. 그럼 그 안에 여러 파일이 있는데 여기서 알아야 할 것은 파일명에 ca가 들어간 것과 server가 들어간것 이 2가지 종류만 알면 된다. 아까 옵션에서 --cacert가 있었는데 옵션명에 ca가 들어가니 ca가 들어가는 파일명의 것을 사용한다고 보면 되며 cert가 들어가니 확장자는 crt인것을 찾으면 된다. 그래서 --cacert 옵션에 매치되는건 ca.crt 파일이다. 나머지 두 옵션인 --cert와 --key는 옵션명에 ca가 들어가지 않으니까 파일명에서 ca가 들어가지 않을 것이다. 그럼 남은건 server니까 옵션명에서 cert를 사용하니 ca가 안들어간 server.cert 파일이 매치된다. --key도 이러한 개념에서 server.key 가 매핑된다고 보면 된다. 사용해야 할 옵션과 그 옵션에 사용할 파일은 이런 개념으로 외우면 된다(이해를 못한 상태니 이렇게라도 외울수밖에..)

 

좀더 간략한 버전으로 설명하면 Master Node 내부에서 Pod으로 실행되는 etcd는 Static Pod 이기 때문에 /etc/kubernetes/manifests 디렉토리에 있는 etcd.yaml 파일 내용을 보면 spec.containers.command 항목에 etcd를 실행하면서 --cert와 --key 옵션을 사용하고 있다. 그것을 그대로 사용하면 된다. 단 백업했을때 사용한 옵션인 --cacert 를 사용하고 있지는 않고 대신 --cacert 옵션에 사용했던 값인 /etc/kubernetes/pki/etcd/ca.crt를 etcd.yaml 파일에서 etcd를 실행할때 --trusted-ca-file 옵션이 사용하고 있다. 정리하면 /etc/kubernetes/etcd.yaml 파일에서 --cacert 옵션과 --key 옵션은 그대로 사용하고 --trusted-ca-file 옵션 대신 --cacert 옵션을 사용하라는거..

 

그래서 전체적으로 etcdctl 명령어를 다음과 같이 사용한다.

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

여기서는 --endpoints 옵션을 사용했는데 이 옵션에 대한 help를 보면 이 옵션을 사용하지 않을경우 default로 127.0.0.1:2379를 사용하기 때문에 생략해도 되는 옵션이라 생략했다. 그러나 ETCD 서버를 kubernetes cluster 안에서 운영하는 것이 아닌 kubernetes 밖의 ETCD Cluster를 별도로 구축했다면 이 옵션을 사용하면서 IP를 ETCD Cluster의 대표가 되는 Server IP를 사용하면 된다.

 

ETCD Restore 는 문제로 출제되지는 않았지만 어차피 Backup과 Restore는 한통속인지라 같이 묶어서 정리 하겠다.

 

ETCD Restore의 명령어 구성은 다음과 같다

etcdctl snapshot restore /opt/etcd-backup.db --data-dir=/var/lib/etcd-backup

kubernetes에서 사용중인 etcd의 data file은 /var/lib/etcd 에 있는데 기존에 백업했던 파일인 /opt/etcd-backup.db 파일을 이용해서 새로운 디렉토리인 /var/lib/etcd-backup 디렉토리에 retore 해둔다. 그러면 백업된 데이터 파일이 /var/lib/etcd-backup 디렉토리에 있으니 현재 실행중인 etcd가 바라보는 데이터 파일이 있는 디렉토리를 /var/lib/etcd-backup 으로 보게끔 해주면 된다. etcd Pod은 static pod 이기 때문에 /etc/kubernetes/manifests 디렉토리에 가면 etcd.yaml 파일로 Pod 이 생성된다. 이제 이 파일을 열어서 수정해주면 된다. etcd.yaml 파일을 열어서 spec.volumes 항목을 보면 다음과 같이 되어 있다.

  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data

hostPath.path 항목에 /var/lib/etcd 라고 되어 있는 부분이 있는데 저 디렉토리는 아까 위에서 언급했듯이 etcd의 데이터 터 파일이 있는 디렉토리다. 저 부분을 우리가 restore 해둔 디렉토리인 /var/lib/etcd-backup 으로 수정해준다. 이 부분을 수정해주면 Pod 내부에서는 해당 hostPath의 이름인 etcd-data를 사용하는 곳에서는 전부 적용되기 때문에 저 부분만 수정해주면 데이터 파일을 사용하는 부분은 새로운 디렉토리로 적용된다고 보면 된다.

이렇게 수정해주면 etcd Pod을 새로 재생성하기 때문에 기다렸다가 재생성이 완료 되면 kubernetes 관련 Resource들을 체크하여 Restore가 되었는지 확인하면 된다

 

7번 문제는 secret을 사용하는 Pod을 만드는 것인데 Kubernetes Secrets 문서의 Using Secrets as files from a Pod 을 보면 Secrets를 사용하는 Pod을 생성하는 yaml 예시를 볼 수 있다. 이것을 기본으로 해서 문제를 풀었다. 다만 Pod에서 사용한 이미지가 busybox인데 컨테이너의 명령어 설정 방법은 이 예시에서 사용하고 있지를 않아서 이 부분은 kubernetes document 에서 command 로 검색어를 주어 검색 결과로 나온 Define a Command and Arguments for a Container 문서를 참고해서 Pod 구성 yaml을 수정했다. 이렇게 모르는 내용은 kubernetes document 에서 검색해서 찾거나 kubectl 의 help 옵션을 사용해서 관련 사항을 찾을수가 있다. 그리고 공부하면서 검색해서 나온걸 써먹은게 있다면 해당 내용을 북마크 해두면 시험볼때 바로바로 볼 수 있을것이다.