[Kubernetes] Certified Kubernetes Administrator 연습 (1)

 

 

 

Q1. 가상의 회사에서 요청이 왔다

 

blog라는 namespace를 만들고, 그 안에 블로그 앱을 배포하라.

1. namespace: blog
2. Secret: 이름 blog-secret, 내용은 DB_PASSWORD=supersecret
3. PVC: 이름 blog-storage, ReadWriteOnce, 2Gi
4. Deployment: 이름 blog-app, 이미지 nginx, replicas 2개
   • Secret blog-secret을 환경변수로 주입
   • PVC blog-storage를 /var/data 경로에 마운트 (/data 아님)
5. Service: 이름 blog-svc, NodePort, 포트 80

 

 

명령어로 namespace 만들고 secret 만들고, k8s docs 기반으로 PVC 만들고, dry-run으로 deployment yaml 만들고 수정하고, 명령어로 service 돌려주면 된다. 

 

명령어는 계속 쳐봐야 늘고 YAML도 많이 만져봐야 는다.

envFrom volumeMounts volumes 위치, configMapRef secretRef 아래 들여쓰기 apiVersion 누락 등.. 

 

뭐가 잘 안되면 describe로 이벤트 읽어서 찾아야 함. 이름 미스매칭한 오류같은것도 다 찾아낼 수 있다. 

envFrom은 사실 명령어로 가능하긴 함. kubectl set env deployment/blog-app --from=secret/blog-secret -n blog 

중간중간 get 으로 검증하는것도 좋음. 

 

Deployment를 작성할 때는 한 번에 하지 말고 세 조각으로 나눈다. 

본체는 명령어로 바로 생성하고 Secret 주입은 명령어로, 볼륨은 YAML으로 수정하는게 좋다. edit 명령어 활용. 

 

 

 

 

---

 

 

 

etcd 는 클러스터의 모든 상태를 저장하는 데이터베이스로 etcd를 백업하는건 클러스터 전체를 백업하는것과 같다.

kubectl으로 쿠버를 다루듯 etcdctl으로 etcd를 직접 다룰 수 있음. 다만 항상 인증 정보를 함께 줘야 함.

 

--cacert는 CA 인증서 / --cert는 클라이언트 인증서 / --key는 클라이언트 키 / --endpoints는 etcd 주소

 

1. 백업 
ETCDCTL_API=3 etcdctl snapshot save /opt/backup.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
  
2. 백업 검증
ETCDCTL_API=3 etcdctl snapshot status /opt/backup.db

3. 복원 
ETCDCTL_API=3 etcdctl snapshot restore /opt/backup.db \
  --data-dir=/var/lib/etcd-restore
  
vim /etc/kubernetes/manifests/etcd.yaml
-> volumes 부분의 hostPath.path를 etcd-restore로 수정

 

 

인증서 경로는 환경마다 다를 수 있으니 확인하고 사용해야 한다. snapshot save + 인증서 3종만 기억하면 된다. 

 

etcd Pod의 정의 파일에 인증서 경로가 다 적혀있다. etcd는 static pod 이니 파일로 실행됨. 

cat /etc/kubernetes/manifests/etcd.yaml

 

etcd.yaml을 수정하면 kubelet이 변화를 감지하고 etcd Pod를 재시작시킨다. 

static pod로 띄워지기에 api-server를 거치지 않는다. kubelet이 혼자 띄울 수 있음. 

 

--trusted-ca-file 은 etcdctl의 --cacert이고 --certfile은 etccdctl의 --cert이고 --key-file은 --key이다. 

 

 

 

---

 

 

 

Q2.이커머스 상품 서비스 배포

 

shop이라는 namespace를 만들고, 상품 서비스를 배포하라.

1. namespace: shop
2. ConfigMap: 이름 product-config, 내용 두 개 — CURRENCY=USD, MAX_ITEMS=100 (이번엔 Secret 아니라 ConfigMap, 값도 2개)
3. PVC: 이름 product-pvc, ReadWriteOnce, 1Gi
4. Deployment: 이름 product-app, 이미지 httpd, replicas 4개
5. ConfigMap product-config를 환경변수로 주입
6. PVC product-pvc를 /usr/local/apache2/htdocs 경로에 마운트
7. Service: 이름 product-svc, ClusterIP, 포트 80

 

 

# 1. namespace
k create namespace shop

# 2. ConfigMap
k create configmap product-config \
  --from-literal=CURRENCY=USD \
  --from-literal=MAX_ITEMS=100 \
  -n shop

# 3. PVC (YAML - docs)
#    kind: PersistentVolumeClaim, name: product-pvc, RWO, 1Gi
k apply -f product-pvc.yaml

# 4-1. Deployment 본체 (dry-run)
k create deployment product-app --image=httpd --replicas=4 \
  -n shop --dry-run=client -o yaml > product-deploy.yaml

# 4-2. YAML엔 볼륨만 추가 후 apply
k apply -f product-deploy.yaml

# 4-3. ConfigMap 주입은 명령어
k set env deployment/product-app --from=configmap/product-config -n shop

# 5. Service (ClusterIP)
k expose deployment product-app --name=product-svc \
  --type=ClusterIP --port=80 -n shop

# 검증
k get all,pvc -n shop
k exec -n shop deploy/product-app -- env | grep CURRENCY
k exec -n shop deploy/product-app -- df -h /usr/local/apache2/htdocs

 

 

k create ... / k expose / k set env 는 외워야함. 많이 쓰다 보면 외워진다. 

k8s docs에서 찾는 예시는 Pod 기준으로 설명하는 경우가 많은데 Pod로 설명된거를 그대로 적용할 수 있어야 함. 

 

-o 는 출력형식 -f 는 파일을 읽으라는 뜻 -n은 네임스페이스 

-는 짧은 옵션을 설정할 때, --는 긴 옵션을 설정할 때 사용한다. 짧은 옵션은 o f n 이런것 한글자 

 

volumeMount의 name과 volume name은 서로 일치해야 한다. 

claimName과 PVC의 name은 서로 일치해야 한다. 문제에서 정해줬다면 그 이름을 사용하기 

 

secret을 만들 때는 데이터 타입을 붙여야 하니 generic을 붙여야 한다. configmap은 이런거 없긴 함. 

명령어 칠 때 -n 옵션 설정하는거 절대 까먹지 말기. 그게 싫으면 set context 설정하는게 좋다. 

k config set-context --current --namespace=monitor 이런식

 

 

 

---

 

 

 

13months@13monthsBook k8s % k get pods -n ts
NAME                      READY   STATUS         RESTARTS   AGE
web-app-f5599db7c-gl586   0/1     ErrImagePull   0          11s
web-app-f5599db7c-kkl6v   0/1     ErrImagePull   0          11s
web-app-f5599db7c-rpf2r   0/1     ErrImagePull   0          11s
13months@13monthsBook k8s %

 

 

ErrImagePull 에러가 발생한다. etcd에 정의된 yaml을 보는 것도 가능하지만 describe 명령어로 보는게 더 좋은 방법이다. 

k describe <리소스종류> <이름> -n <namespace> 

 

다만 describe 명령어는 보여주는게 너무 많다. 그러니 리소스마다 핵심이 되는 부분만 확인해야 함. 

 

deployment/web-app 이나 deployment web-app 은 표기법 차이지 같은 의미임.

이미지만 빠르게 바꾸는 경우면 set image가 더 빠르다. 

 

k set image deployment/web-app web=nginx:1.29-alpine -n ts

web=... 부분은 컨테이너 이름과 새 이미지를 의미한다. 

컨테이너 이름은 describe에서 확인할 수 있음. 

edit은 vim을 열고 찾아서 고쳐야 함. 볼륨처럼 복잡한거 수정할 때는 k edit으로 yaml을 직접 수정하자. 

 

k describe pod web-app-f5599db7c-gl586 -n ts  

k describe pod -l app=web-app -n ts

k describe deployment web-app -n ts

원래는 전체 이름을 설정해 줘야 하는데, -l을 사용해 라벨로 지정하는것도 가능하다.

app=web-app 라벨이 붙은 Pod를 찾아낸다. 

그것도 싫으면 Pod 말고 Deployment를 describe해도 됨. 

 

describe 출력의 제일 아래에는 Events가 있음. 이 리소스에서 무슨 일이 일어났는지 기록한다. 

k describe pod xxx -n ts | grep -A 10 Events

grep Events만 하면 한 줄만 나오는데 -A를 추가하면 After로 찾은 줄 뒤에 있는 10줄을 추가로 불러온다.

 

리소스마다 확인할 부분이 다름. Pod는 Events를 봐야하고, Deployment는 Events말고 Replicas Conditions Image필드를 봐야함. 

 

생각흐름 

1. k get pods -n ts : 일단 get pods로 뭐가 고장났는지 확인. 이미지 문제네.. 

2. k describe pod -l app=web-app -n ts | grep -i image : 전체는 길어서 보기 힘드니 이미지 부분만 grep. -i는 대소문자 무시함.

3. k set image deployment/web-app web=nginx:1.29-alpine -n ts : 이미지만 바꾸면 되니까 yaml 대신 set image 사용함. 

4. k get pods -n ts : 다시 확인 

 

 

 

---

 

 

 

13months@13monthsBook k8s % k get pods -n ts
NAME                     READY   STATUS   RESTARTS      AGE
worker-f949fd657-8jgrz   0/1     Error    4 (72s ago)   118s
worker-f949fd657-j4mcf   0/1     Error    4 (73s ago)   118s
13months@13monthsBook k8s %

 

STATUS가 Error나 CrashLoopBackOff면 로그를 봐야 한다.

쿠버 수준의 describe로 확인할 수 없는 애플리케이션 수준 에러임. 

 

k logs <pod이름> -n <namespace> --previous

previous 옵션을 붙이면 죽기 직전의 로그를 확인할 수 있다. 

 

추가로 nginx나 httpd같은 서버 이미지는 자체적으로 계속 실행되니 sleep이 필요 없음. 

다만 컨테이너는 메인 명령이 끝나면 죽는다. CrashLoop를 진단할 때도 명령이 끝나서 죽는걸 알고 있어야 함. 

그러니 디버깅용 Pod에는 항상 sleep을 붙이는게 좋음. 붙일 때 한 줄로 붙이는거에 주의...

 

 

 

---

 

 

 

 

13months@13monthsBook k8s % k get pods -n ts
NAME                       READY   STATUS    RESTARTS   AGE
frontend-84bcb9b5b-rmfgf   1/1     Running   0          12s
frontend-84bcb9b5b-wrwpp   1/1     Running   0          12s
13months@13monthsBook k8s % k get svc -n ts
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
frontend-svc   ClusterIP   10.111.75.127   <none>        80/TCP    16s
13months@13monthsBook k8s % k describe svc frontend-svc -n ts
Name:                     frontend-svc
Namespace:                ts
Labels:                   <none>
Annotations:              <none>
Selector:                 app=frontnd
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.111.75.127
IPs:                      10.111.75.127
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
Endpoints:                
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>
13months@13monthsBook k8s %

 

 

Service는 떴는데 Pod와 연결되지 않았다. 

k describe svc 명령어로 확인해보면 Endpoints 부분이 없음을 확인할 수 있다.

Endpoints -> selector -> Port 순서로 점검하면 됨. 

 

kubectl get pods -n ts --show-label 으로 Pod에 붙여진 라벨을 확인할 수 있다. 

이걸 기반으로 selector를 수정해 주면 됨.