[Kubernetes] Certified Kubernetes Administrator 연습 (3)

 

 

 

Q1. GPU 작업용 워크로드를 minikube-m03 노드에 배포하려는데 Pod이 안뜬다. m03노드는 GPU 전용임. 일반 워크로드가 못 들어오도록 설정해뒀음. m03 기본설정은 유지하되 Pod 2개가 m03에서 Running 되도록 조치하기. 

 

특정 노드에 Pod를 배치하지 않도록 설정하는건 taint. toleration은 그 거부 표시를 견딜 수 있음을 명시하는 표식으로 Pod에 붙인다.

 

0/3 nodes are available:
  1 node(s) had untolerated taint(s)                    ← m03: taint 있는데 Pod에 통행증 없음
  2 node(s) didn't match Pod's node affinity/selector   ← minikube, m02: nodeSelector가 m03을 지정했으니 당연히 안 맞음

 

나머지 2개는 원래 배제 대상이고 한개는 확인해 봐야 함. untolerated taint는 Pod이 taint를 견딜 toleration이 없음을 의미함. 

 

13months@13monthsBook k8s % k describe node minikube-m03 | grep -i taint
Taints:             dedicated=gpu:NoSchedule
13months@13monthsBook k8s % k edit deployment gpu-job -n prod
deployment.apps/gpu-job edited
13months@13monthsBook k8s % k get pods -n prod -o wide       
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
gpu-job-6c765f4fff-9rb66   1/1     Running   0          5s    10.244.2.39   minikube-m03   <none>           <none>
gpu-job-6c765f4fff-mq7h5   1/1     Running   0          3s    10.244.2.40   minikube-m03   <none>           <none>
13months@13monthsBook k8s %

 

Pod에 toleration을 추가하면 된다. 위치는 spec.template.spec 아래, containers 옆에다가 배치하면 됨. 

taint를 확인하고 그대로 YAML에 적으면 된다. operator: Equal은 고정으로 붙임. 그냥 k8s docs에서 복붙하면 되긴해.

 

 

---

 

 

 

Q2. 모니터링 담당자가 monitor-sa 계정으로 prod namespace의 Pod을 조회하려는데 권한이 없다고 함. 고쳐라. 

 

13months@13monthsBook k8s % k auth can-i get pods --as=system:serviceaccount:prod:monitor-sa -n prod
no
13months@13monthsBook k8s % k auth can-i list pods --as=system:serviceaccount:prod:monitor-sa -n prod
no
13months@13monthsBook k8s %

 

can-i 로 확인해보면 진짜 안되는걸 확인할 수 있음. 

 

13months@13monthsBook k8s % k describe role pod-reader -n prod
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  services   []                 []              [get list]
13months@13monthsBook k8s % k describe rolebinding monitor-binding -n prod
Name:         monitor-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  pod-reader
Subjects:
  Kind            Name        Namespace
  ----            ----        ---------
  ServiceAccount  monitor-sa  prod
13months@13monthsBook k8s %

 

Role의 이름은 pod-reader인데 권한은 services 관련 권한으로 설정되어있음. 

일단 rolebinding은 정상이다. 

 

pod-reader를 수정하면 됨. k edit으로 수정하면 된다. 

 

1. 리소스 이름이니까 k get role -n prod 로 이름을 찾아준다.

2. can-i 명령어로 무슨 리소스에 대한 무슨 동작을 누구의 권한에서 수행할 수 있는지 확인할 수 있음 

3. describe role 도 마찬가지임 그냥 쓰던대로 해 

 

 

 

---

 

 

 

Q3. DB 서비스 배포했는데 Pod이 안뜬다. 고치고 /var/lib/data 에 볼륨 마운트되도록 수정하기 

 

Pod이 안 뜨면 STATUS 부터 봐야함. YAML에는 볼륨이 있으니 PVC도 함께 확인해야 함. 

볼륨을 쓴다면 Pod와 PVC를 한 세트로 봐야 한다. (k get pods, k get pvc)

 

PVC가 Pending이면 당연히 Pod도 Pending이다. PVC 부터 고쳐야함.

k describe pvc data-claim -n prod로 확인해보니 fast-ssd 를 못찾는다고 함. 이게 머임? 이건 storageClass임. k get storageClass로 확인해보면 standard 하나만 뜬다. PVC는 fast-ssd를 요구하니까 이 부분을 고쳐야 함. 

 

k edit pvc 로 고치려는데 안된다. pvc는 immutable이니까.. 한 번 만들면 수정이 안 됨. 삭제 후 재작성 해야 한다. 먼저 Pod가 쓰고 있으니 Deployment를 먼저 삭제하고 PVC를 삭제해야 한다. vim 으로 storage-issue.yaml을 수정하고 재생성한다. standard가 기본이니 그 줄을 그냥 지워버리는게 합리적이다. 

 

바꾸고 나니까 아직도 Pending 인데 Events를 확인하자. provisioner를 확인하라고 함. k get pods -n kube-system으로 확인해보면 프로비저너가 없는걸 확인할 수 있음. 즉, 클러스터 문제라는거임. 그러니 minikube addons enable storage-provisioner로 활성화 해 주면 해결됨. 

 

 

 

---

 

 

Q4. prod namespace에 로깅 에이전트를 배포해야 함. 노드 하나에 정확하게 하나씩 실행되어야 함. log-agent / busybox:1.36 / sh -c "while true; do echo collecting; sleep 30; done" 마스터 노드에도 배치되어야 함. 

 

Deployemnt로 replicas: 3을 지정해도 스케쥴러가 노드 한개에 2개를 몰아줄 수 있음. 그러니 노드마다 한개를 강제하려면 DaemonSet을 사용해야 한다. Deployment yaml 템플릿에서 kind 부분만 바꿔주면 됨. 

 

minikube는 마스터 노드도 Pod를 배치할 수 있어서 그냥 그대로 쓰면 된다. 

 

k create deployment log-agent --image=busybox:1.36 -n prod --dry-run=client -o yaml > agent.yaml

템플릿 뽑고 거기다가 kind 바꾸고 replicas 삭제하고 strategy 삭제하면 된다. 

 

혹시나 노드 중에서 taint 붙어있는거 있을 수 있으니 최종 점검하고 확인하면 됨. DaemonSet도 taint를 무시할 수는 없다. 

그리고 yaml 작성할 때 commands 위치도 좀 알아두면 좋을듯.. "sh" "-c" "나머지" 이런 순서로 배치해야 한다. 

 

 

 

---

 

 

 

Q5. 프론트 배포했는데 서비스가 불안정함. frontend Pod 정상으로 만들고 SITE_NAME 환경변수 체크하고 frontend-svc로 접속되도록 수정하기.

 

서비스가 불안정하다는건 아예 안뜨는게 아니라 떴다 죽었다를 반복하는 것. get pods 에서 RESTARTS 되는걸 확인한다.

describe로 확인해보면 Pod는 잘 뜸. 에러도 없음. 그런데 SIGQUIT를 받고 죽었다는건? 누군가 외부에서 죽인거다. 쿠버가 죽인듯. 

 

Events를 보면 Liveness Probe에서 실패해서 재시작중이라고 함. 실패하면 컨테이너를 재시작하는거니까.. 

컨테이너가 듣는 포트는 80인데 실제로 헬스체크하는 포트는 8080이다. k edit deployment로 수정해줬음. 

 

echo로 환경변수 찍을 때는 " " 말고 ' ' 로 감싸줘야 정상작동함. 

 

 

---

 

 

 

Q6. 리포트 서비스를 배포했는데 Pod이 만들어지지 않음. 아예 안보임. 고쳐보기.

 

k get pods 했더니 없음. 그러면 describe deployment로 확인한다.

must specify limits.cpu limits.memory 라고 함. 이러면 requests를 설정해 줘야 하는걸 알 수 있음. 

 

resources는 컨테이너의 속성이니 containers의 아래, image name과 같은 라벨로 위치시켜야 함. 

컨테이너의 속성은 containers 안에다가 배치하고 pod의 속성은 template.spec 아래에 배치한다. 

헷갈리면 Managing Resources for Containers 를 k8s docs에 검색하면 됨. 

 

 

 

---

 

 

 

Q7. 매 분 마다 실행되는 백업 작업을 배포했는데 작업이 완료되지 않고 있음. CronJob은 만들어졌고 Job도 생성됨. 고쳐보기.

 

CronJob  ──(시간 되면)──>  Job  ──(만듦)──>  Pod
  틀                      실행 단위          실제 작업

 

CronJob은 작업을 반복해서 실행하라는 규칙이고, Job은 그 실제로 만들어진 작업을 의미한다. Pod는 Job이 실행하는 컨테이너임.

Deployment -> ReplicaSet -> Pod 계층과 유사하다.

 

k get cronjob -n prod 
k get jobs -n prod       
k get pods -n prod     

 

Job은 생기는데 Pod가 안생김. 그러니 describe job 으로 확인해보자.

확인하면 또 request와 limit를 설정해 줘야 한다고 함. 그러면 CronJob을 수정해서 해당 부분을 명시해 주면 됨. 

위치는 컨테이너와 같은 위치.

 

또 안된다. 이번에는 describe pod을 본다. 확인해보니 ConfigMap 이름 문제임. 

CronJob을 수정해서 이름 맞춰주면 된다. 

 

다만 Deployment와 다르게 CronJob을 고쳐도 이미 만들어진 Job은 수정되지 않음. 그러니 k delete job --all -n prod 로 모두 삭제한 후 확인하면 된다. 

 

 

 

---

 

 

 

Q8. API 게이트웨이를 배포했는데 서비스로 접속이 안된다. Pod는 살아있는 상태. gateway-svc로 정상 접속되도록 고치기. 

 

k get pods로 확인했을 때 Running 이지만 READY 컬럼이 0/1 상태임. 뭔가 문제가 있다.

k describe svc 와 pod로 봤을 때 Endpoints가 비어있음. 그런데 Selector는 정상이네? 

pod를 보니 /healthz 로 요청을 보내고 있다. 

 

/healthz 경로가 nginx에 없으니 404를 뱉고, READY 0/1이 되는 것. 그러니 Service가 Endpoints에서 제거되는거고.. 

READY가 0/1 이면 Selector가 아니라 다른걸 봐야한다. 

 

k describe로 볼 때 | less 를 사용하면 vim 처럼 확인할 수 있음. 

 

 

 

---

 

 

 

Q9. 장바구니 API가 배포가 안되고 서비스도 동작하지 않음. MODE 환경변수 확인하고 8080으로 접속되도록 확인하기 

 

Deployment의 selector는 immutable이다. 그러니 바꾸려면 삭제 후 재생성 해야 함.

Service의 selector는 수정할 수 있으니 라벨 불일치 문제는 Service쪽을 수정하는게 합리적임.