자격증 취득 후기
EKS 환경에서 업무를 진행하고 있었고 관련해서는 스터디도 한번 진행했었기 떄문에 생각보다 별로 어렵지 않을거라고 생각하고
공부를 시작했었는데 내가 대충 알고 있었던 부분도 많았고 생각보다 공부해야하는 범위가 많았었다.
그리고 정말 주어지는 문제를 풀어야하기때문에 각 상황들을 정확하게 이해하는게 중요했었고 이번 시험 준비를 통해서
기존에 어렵풋 알던 지식들을 정확하게 알게 되었고 업무에서 활용하면 좋을 것 같은 개념들도 많이 알 수 있었다.
가격이 비싸서 조금 망설여지기는 하지만 그래도 개념위주보다는 실무 위주의 시험이기 때문에 쿠버네티스 환경에서(혹은 EKS 같은 플랫폼 서비스) 업무를 진행하고 있고지식적으로 좀 더 향상을 원하시는 분들이 있다면 정말 강력 추천하는 자격증이다!
공부 기간
CKA를 취득하겠다고 마음 먹었을때부터 단순하게 자격증을 취득하는게 목표가 아니라 쿠버네티스 전반에 대해서 정확하게 이해하는 것이 목표 였기 때문에 생각보다 기간 자체는 좀 걸렸던것같다.
기본적인 클라우드 지식이 있는상태에서 인터넷 강의 내용을 천천히 정리하면서 진행을 했는데 중간중간에 공부하지 못했던 시간을 빼고 보면 대략 2달 반정도 시간이 걸렸던거 같다 (시험 탈락후 재시험 공부하는 것 포함 + 직장인이기 때문에 시간이 부족한것 포함)
만약 정말 시험만을 목적으로 핵심만 공부한다면 2~4주 정도면 가능할것도 같다
꼼꼼하게 공부하려고한다면 2달정도잡으면 될것 같다
기타 시험 팁
1.
나는 시험을 총 3번 쳤는데 처음 시험을 쳤을때 중간에 시험창이 꺼져버린 현상이 있어서 시간을 통으로 날린적이 있었다
결국은 관련해서 문의를 하고 시험을 리셋 받아서 다시 2번의 기회는 받았었다.
답변 받은 내용을 보면 일단 네트워크 이슈가 좀 있다고 했었는데 당시 스터디룸을 빌려서 시험을 쳤는데 해당 스터디룸의 네트워크 속도가 좀 안좋았을 수 도 있었던것 같다.
cka시험 환경 준비사항중에 스피드 체크를 하는 사이트 링크가 적혀있는데 실제로 시험을 치는 환경에서 해당 인터넷의 스피드 체크를 꼭 해보기를 바란다.(다운로드 5mbps이상, 업로드 1mbps이상, 지연 100ms이하)
그리고 혹시나 저처럼 창이 꺼진다면 당황하지 않고 해당 페이지 다시 접속하면 시험 페이지로 다시 들어가는게 가능했었다 (다시 체크인 프로세스는 받아야한다)
2.
생각보다 체크인 과정에서 이것 저것 많이 확인한다 그래서 정말 아무것도 없는 방에서 하는게 좋다
스터디룸을 빌려서 했을때도 위쪽에 cctv카메라가 있는거로 머라고해서 a4용지 빌려서 해당 cctv를 막고 시험을 쳤었다.
3.
시험은 결국 오픈북이기 때문에 쿠버네티스 공식 홈페이지에 익숙해지는게 중요하다.
어떤 주제에는 어떤 페이지를 가야한다는것 정도는 모두 숙지를 하고 가는게 시간 단축에 유리하다
(물론 기본적인 주제에 관해서는 시험에서 링크까지 걸어주기는한다)
공부 방법
공부 방법은 강의를 일단 쭉 들으면서 개념에 대해서 정리를 했다.
강의 자체가 엄청 많아서 사실 다 듣기는 어렵긴한데 앞쪽부분에 사전 개념 설명 부분은 알고 있다면 듣지 않고
넘어가는것 도 괜찮았을것 같기는하다
위의 강의가 좋았던건 설명보다도 실습할 수 있는환경을 무료로 제공한다는 점이였다
사실 환경 자체는 그냥 무료로 제공하는것 같고 이것에 대해서 강의로 설명 까지 해주는게 좋았다.
Udemy Labs - Certified Kubernetes Administrator with Practice Tests Course | KodeKloud
Course Duration: 43 Hours
learn.kodekloud.com
개념 강의를 다 수강하고 난 뒤에는 mock-exam 과 lighting-lab을 열심히 풀었다
4~5번은 풀어본것 같고 마지막에는 그냥 시험치면 다 맞을 수 있는 정도로 풀 수 있었다.
그리고 killer.sh 같은경우는 처음에 환경이 어떤지 궁금해서 들어가 봤었는데 한번 들어가고 계속 다시 칠수 있는줄 알았는데 그게 아니였다
한번 접속하면 시험기회가 끝나고 딱 2번만 기회를 제공하기 떄문에 준비가 되었고 시간 확보를 해둔뒤에 접속해야한다
나는 두번을 그냥 날려버려서 관련 해설들만 한번 정리를 했었다
시험 핵심 개념
아직 시험이 끝나고 얼마 시간이 안지나서 핵심적인 개념들은 아래에 정리해 두었다.
시험 치고 가기전에 아래의 개념들에 대해서는 확실하게 인지하고 시험치면 좋을것 같다
Deployment/Servic/Pod
쿠버네티스에서 가장 기본이 되는 개념이기때문에 기본적으로 알고 가야한다
아래의 명령어들에 대해서는 알아두면 빠르게 문제를 풀 수 가 있다.
추가로 --help 명령어는 잘 활용하는게 좋다
기본 명령어만 암기해두고 나머지는 시험장에서 --help로 상세 내용을 확인할 수 있다.
기본 개념 링크
pod , deployment , service
기본 명령어
# 모든 객체에서 공통 사용하는 명령어
kubectl get all # kubernetes의 현재 전체 객체 보기
kubectl get pods # 생성되어인는 ~ 보기
kubectl describe pod <pod이름> # 생성된 ~ 상세보기
kubectl delete pod <pod이름> # ~ 객체 삭제 하기
kubectl create -f redis.yaml # ~ 객체 생성하기
kubectl apply -f redis.yaml # ~ 객체 생성/변경 하기
# pod
kubectl get pods -o wide #파드 정보 상세보기 어떤 노드에 생성되었는지 확인 가능
kubectl run nginx --image=nginx # 파드 명령어로 간단하게 생성하기
kubectl run nginx --image=nginx --dry-run=client -o yaml > redis.yaml # 실제 생성안하고 yaml로만 만들기
# deployment
kubectl set image deployment nginx nginx=nginx:1.18 # 이미지 변경 하기
kubectl create deployment nginx --image=nginx # deployment 명령어로 생성하기
kubectl scale deployment nginx --replicas=4 # 복제본 개수 수정하기
# deployment 변경 이력 및 롤백
kubectl rollout history deployment my-deployment
kubectl rollout history deployment my-deployment --revision=3
kubectl rollout undo deployment my-deployment --to-revision=3 #특정 버전으로 롤백
# service
kubectl expose pod redis --port=6379 --name=redis-service # 기존 pod, deploy 에 대응하는거 만들떄
주요 시험 내용
- 단순하게 개념적으로 각각의 ~ 를 만들라는 내용으로는 문제가 안나온다
기존에 이미 deployment가 있을때 어떤 수정을 해서 조정을 한다던가
기존 deployment에 적합산 service를 만들라는 식으로 문제가 나오게된다.
- 다른 개념들에서 문제가 나올때 이 개념이 기본이 되어서 나온다고 보면 된다.
- deployment와 pod의 경우 문제가 발생했을때 어떤 문제가 발생한건지 알 수 있어야한다.
그럴때는 describe 명령어를 사용하거나 혹은 logs 명령어로 pod의 실제 로그를 확인해봐야한다.
pod안에 멀티 컨테이너 환경이라면 -c 옵션으로 컨테이너 내부 로그를 보는것도 알고 있어야한다.
스케줄링
pod가 어떤 node에 스케줄링 되는가에 대한 문제로 아래 개념들은 필수로 알아두고 들어가야한다.
Taint : 링크
개념 : 노드에 특정 조건을걸고 해당하는 조건이 없는 pod는 들어 올 수 없도록 설정
문제 : ~ 파드가 ~ 노드에 들어가도록 설정 , 들어가지 못하도록 설정
Node Selectors & Affiniry : 링크
개념: taint 는 node에서 이제 ~ 아니면 못들어온다고 막는것 (pod는 다른 노드로 들어갈수있음) 과다르게
pod가 어떤 노드로 들어가고 싶다고 설정하는 개념이라고 보면된다.
Resource request & limit : 링크
개념: pod 생성할때 어느정도의 cpu, memory를 부여할지 설정
문제 : 해당 설정값이 충분하지 않으면 pod가 생성이 안된다. 그래서 적합한 수치를 넣어서 pod가 생성되도록 하는 케이스 문제 있음
Static pod : 링크
개념 : kubelet이 독립적으로 생성하고 관리하는 pod
/etc/kubernetes/manifests 에 yaml 파일을 생성하면 자동으로 pod를 생성/변경한다
문제: 쿠버네티스의 주요 관리 pod 들이 모두 static pod로 생성되어있기 때문에
해당 경로는 무조건 알고 있어야한다 kube-apiserver 라던가 etcd 라던가
각가의 설정에서 잘 못 된 부분을 수정해서 정상 동작하게 하는등의 문제가 많이 나온다.
환경 변수 설정
deployment에서 pod를 생성할때 환경변수를 넣어주는 부분 : 링크
단순하게 name/value로 환경변수를 넣어주는것 말고도
secret/configmap의 값을 환경 변수로 넣어주는것
그리고 pod 자체의 정보를 환경 변수로 넣어주는 것 까지 알고 있어야한다.
(ex 노드이름, 공식 문서 -> 시험치는 중이라면 environment variables로 검색해서 들어갈 수 있다)
멀티 컨테이너 파드
하나의 컨테이너에서 여러개의 파드가 떠있는 상태 : 링크
요거는 무조건 시험에 나오는 개념이라고 생각한다
기본적으로 2개의 컨테이너가 떠있을때 공통 volume를 마운트해서
한쪽은 로그를 생성하고 한쪽은 로그를 출력하는 형태로 시험 문제가 나온다.
공식문서에서 sidecar 를 검색해서 나오는 문서를 확인해서 문제를 풀면된다. 공식 문서
공유 volume이고 종료시 사라지는건 emptyDir:{}을 사용하면된다.
HPA
pod의 수를 자동으로 늘리거나 줄이는 기능 : 링크
관련해서는 꼭 시험문제로 나오는것 같다.
hpa 관련해서는 공식문서에서 나오는 2가지 페이지를 적절히 참고하면서 문제를 풀면된다.
공식문서에서 hpa로 검색했을 때나오는
Horizontal Pod Autoscaling | Kubernetes -> sacleDown 정보 확인
HorizontalPodAutoscaler Walkthrough | Kubernetes -> 기본 yaml 및 스케일 업 조건 확인
쿠버네티스 업데이트
쿠버네티스를 업데이트하는 방법은
공식문서에 상세하게 설명이 나와있기 때문에 관련 문서를 읽고
순서를 잘 이해하고 있으면 된다고 생각한다
Etcd 백업 복원
etcd 백업과 복원도 중요한 개념이다. 링크
명령어 자체는 조금 복잡해 보이지만 결국 공식문서에서 가이드를 제공해주기때문에
인증서 경로 설정하는 부분만 정확하게 알고 있으면 된다.
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 /path/to/snapshot.db
적합한 인증서, endpoint를 확인하려면
kube-apiserver.yaml | grep etcd를 하면 관련 정보를 쉽게 확인할 수 있다.
| --cert-file=... | --cert | 클라이언트 인증서 (서버가 클라이언트를 신뢰하기 위해 확인) |
| --key-file=... | --key | 클라이언트 인증서의 개인 키 |
| --trusted-ca-file=... | --cacert | 서버 인증서가 진짜인지 확인하기 위한 CA (서버 인증용) |
인증 발급 관련
특정 사용자 정보를 통해서 CSR로 요청서를 만들고 승인 이후 role을 생성해서 맵핑 처리하는 작업으로
관련해서 공식문서의 내용을 정확하게 파악하고 있어야한다.
john의 csr 을통해서 csr을 만든다는게 처음에는 이해가 잘 안갔는데
로컬환경에서 만든 csr 정보를 쿠버네티스 양식에 맞게 csr로 만들어주는 과정이라고 이해하면 된다.
KubeConfig 관련 문제
쿠버네티스트를 사용하기 위한 로컬 인증서 파일로
어떤 클러스터와 유저를 통해서 쿠버네티스에 접속할지 설정하는 파일 .
해당 파일의 구조와 어떤 명령어를 통해서 현재 인증서 파일 상태를 알 수 있는지 정도는
알고 있어야한다. 링크
Role / RoleBinding
기본적으로 쿠버네티스에서 권한관리는 RBAC 형태로
Role을 만들고 그것을 맵핑해주는 방식을 사용한다.
관련되서 role 혹은 clusterRole을 만들어야하는 문제가 많이 나오는데
쿠버네티스 문서 검색해서 처리하는 방법도 있지만
kubectl create role --help 로 명령어 구성을 찾아봐서 바로 만드는게 오히려 간단한것 같다
Network Policy
쿠버네티스에서 pod간 트래픽 허용을 어떻게 할지 설정하는 객체로
과련해서 직접 networkpolicy를 만드는 케이스도 있지만
보통은 특정 조건을 주고 3개의 yaml 파일을 보기로 제시해서
해당 파일중 가장 적합한것을 apply 하라는 식의 문제를 많이 본것 같다
개념 : 링크
참고로 network policy에서는 protocol은 TCP이다
Custom Resource
기본적으로 쿠버네티스에서 제공하는 객체가 아니라 custom으로 객체를 생성하는 개념이다
관련해서는 직접적으로 만드는 것보다는 이미 만들어져있는 custom Resource가 있고
해당 custom resource 에 대한 정보를 확인할 수 있는지를 물어보는 것 같다
개념 : 링크
문제는 kubectl get crd | grep sample 과같이 특정 ~ 인 crd 정보를 조회하는것
kubectl explain crd 와같이 특정 crd의 정보 설명을 저장하는것 등의 문제를 봤었다.
Volumes (pv, pvc, storageclass)
쿠버네티스에서 사용하는 저장소를 어떻게 사용하는지에 대한 개념으로
pv는 저장소 pvc는 어떤 사이즈가 필요하난는 요청서, storageclass는 pv를 자동으로 생성해주는것
결과적으로 pvc (pod쪽에설정 ) 하면 -> 생성된 pv와 매칭되는 개념이다
pvc의 조건과 pv의 조건이 매칭이 안되면 mount되지 않고 pending 되는데 이 pending 상황을 해결하라는 문제가 많이 나온다
보통은 RWO, ROX,RWX가 일치 하지 않거나 용량 사이즈가 맞지 않는 경우다.
CNI
쿠버네티스는 cni를 통해서 pod 생성시 ip 를 할당하고 pod간 통신이 가능하도록 한다
관련해서 cni를 설치하라는 문제가 나오는데 kubectl create -f "제공된 다운로드 링크" 로 설치가 가능하다
설치된 이후에는 해당 cni 에관련된 namespace가 생성되고 해당 namespace에 pod도 생성되게 된다.
개념 : 링크
DNS
쿠버네티스에서 서비스 혹은 파드를 생성하면 CoreDns에 해당 도메인이 저장되고
해당 도메인으로 통신을 할 수 있게 된다. 링크
Service : <service-name>.<namespace>.svc.cluster.local
Pod : 10-244-1-5.default.pod.cluster.local
Ingress
path를 정의해서 외부에서 전달 받은 호출을 내부 서비스로 전달 할 수 있도록 해주는 객체로
기본적으로 메니페스트를 읽고 수정할 줄 알아야한다.
개념 : 링크
rewrite 개념이 살짝 헷갈렸는데 결국은 요청이왔을때
해당 요청을 서비스로 전달할때는 / 루트 형태로 전달하기 위함이라고 이해하면된다.
Gateway api
시험에 필수적으로 나오는 개념이라고 생각한다
ingress에서 부족한 부분을 보안해서 나온 개념으로
GatewayClass, Gateway, HttpRoute
이렇게 3가지 개념이 어떤걸 의미하는지 그리고 어떻게 사용하면 되는지 정확하게 알고 있어야한다.
gateway는 수신을 필터링하는거고 , httpRoute는 라우팅할떄 필터링하는것
그리고 gateway 에서 Terminate, Passthrough 의 차이를 알아야한다.
listeners:
- name: passthrough
protocol: TLS
port: 443
hostname: "example.com"
tls:
mode: Passthrough
listeners:
- name: https
protocol: HTTPS
port: 443
hostname: "example.com"
tls:
mode: Terminate
certificateRefs:
- name: my-cert
kind: Secret
그리고 쿠버네티스 공식 홈페이지에서는 각각의 항목들을 간단하게만 설명해주고 있어서
gateway관련 문서에서 원하는 필드 구조에 익숙해 지는것도 중요하다 (링크 )
개념 : 링크
ingress 형태에서 gateway형태로전환하는 방법도 알고 있어야한다
Helm
helm도 시험을치기전에 꼭 알아야하는 개념이다.
처음에는 익숙하지 않아서 어렵게 느껴졌는데 기본적인 구조만 알고나면
가장 쉽게 점수를 획득 할 수 있는게 helm 인것 같다.
repo라는 저장소를 추가해주고
해당 저장소에서 chart를 설치할 수 있고
chart는 설치하면 release라는 형태로 독립적으로 동작한다는것
그리고 설치되는 객체들은 특정 namespace에만 저장이 된다는것을 인지하면 된다.
위의개념과 기본적인 명령어들만 인지한다면 문제를 쉽게 풀 수 있다.
개념 : 링크
참고로 helm의 릴리즈 정보는 lebel로 남아있다
metadata:
labels:
app.kubernetes.io/name: nginx (차트 이름)
app.kubernetes.io/instance: my-nginx-release (사용자가 release할때 지정한 이름)
app.kubernetes.io/managed-by: Helm
기타 팁
시험을 칠때 내가 정리해두었던 내용들을 간단하게 적어두면 아래와 같다 .
- kube-apiserver는 기본적으로 6443번 포트라는점
- -o 형태로 조회되는 보기를 변경 가능한것 -o jsonpath, -o json, -o custom-column 등에 대한 사용방법 익숙해지기
- deb 파일 설치는 dpkg -i
- pod의 ip 범위확인은 해당 node 정보를 확인해야한다.
- 리눅스 kubelet 로그 보기 journal -u kubulet -r
- kubelet의 설정 파일 위치 /var/lib/kublet/config.yaml
- service 객체 start/status , systemctl start/staus 객체 (서비스 제어 명령어)
- containerd 등과 통신 하는 명렁어 (kubectl 안될때 ) crictl ps/pod/logs/inspect
- sysctl 리눅스 커널 설정 ex) sysctl net.ipv.ip_forward
- netstate -tulnp 실행중인 프로세스 출력 (-t: TCP,-u: UDP, -l: Listening 중인 포트, -n: 숫자로 출력 (포트번호 그대로), -p: 관련된 프로세스(PID/이름) 표시)
- 복호화, 암호화 echo -n 'YWRtaW4=' | base64 --decode # 복호화 echo -n 'admin' | base64 # 인코딩
- k -n project-miami get role --no-headers | wc -l 전체 개수 가져오는 명령어
- cni 바로 설정하는 명령어 sudo sysctl -w net.bridge.bridge-nf-call-iptables=1
- whereis kubelet 명령어 kubelet 의 바이너리 경로를 확인가능
- cni 파일로 설정 하는 내용 container runtime
- kubectl api-resource -> api resource 전체 확인
- systemctl cat kubelet 쿠블렛 설정파일 위치 찾기
- cni 설치할때 조건은로 networkpolicy 사용이 필요하다고 하면 calico 로 설치
- config맵 설정을 이용하는 pod가 있을때 config 정보를 변경하면 pod도 재시작 시켜줘야한다.