[CKA] KodeKloud - Control Plane Failure

안녕하세요, 쯀리입니다.

지난번 Application Failure에 이어 오늘은 ControlPlane Failure에 관해 다뤄보겠습니다. 

https://kubernetes.io/docs/tasks/debug/debug-application/

 

---

 

Application Failure

"Application Failure"에 대한 학습은 애플리케이션이 실패하거나 비정상적으로 동작할 때, 그 원인을 분석하고 이를 방지하거나 복구하는 방법을 배우는 중요한 과정입니다. 이 주제를 학습할 때 다루게 될 주요 개념은 다음과 같습니다:

1. Failure Types (실패 유형)

• Crash Failures: 애플리케이션이 예기치 않게 종료되거나 충돌하는 상황.
• Performance Failures: 애플리케이션이 예상보다 느리게 동작하거나 응답 시간이 길어지는 경우.
• Resource Exhaustion: 메모리, CPU, 디스크 공간 등 시스템 리소스가 부족하여 애플리케이션이 정상적으로 동작하지 않는 경우.
• Dependency Failures: 외부 서비스, 데이터베이스, API 등의 의존성 문제로 인해 발생하는 실패.

2. Root Cause Analysis (원인 분석)

• 로그 분석: 로그 파일을 통해 애플리케이션 실패의 원인을 추적하고 분석하는 방법.
• 메트릭 및 모니터링 도구: Prometheus, Grafana 등 모니터링 도구를 사용하여 애플리케이션의 성능 지표를 분석하고, 실패의 원인을 파악하는 방법.
• 분산 트레이싱: Jaeger, Zipkin 같은 도구를 사용하여 애플리케이션의 분산 환경에서 발생한 문제를 추적하는 방법.

3. Failure Detection (실패 감지)

• 헬스 체크: Kubernetes에서 liveness와 readiness 프로브를 사용하여 애플리케이션의 상태를 모니터링하고, 비정상적인 동작을 감지하는 방법.
• 알림 시스템: 실패가 발생했을 때, 이메일, SMS, Slack 등을 통해 경고 알림을 설정하는 방법.
• 자동 복구: Kubernetes의 ReplicaSet 또는 Deployment를 통해 실패한 파드를 자동으로 재시작하거나 대체하는 방법.

4. Failure Mitigation (실패 완화)

• 회복력 있는 아키텍처: 애플리케이션이 실패하더라도 빠르게 복구할 수 있도록 설계하는 방법 (예: Circuit Breaker 패턴, Retry 패턴).
• 캡슐화 및 격리: 문제가 있는 애플리케이션 컴포넌트를 격리하여 전체 시스템에 영향을 미치지 않도록 하는 방법.
• 부하 분산 및 이중화: 하나의 인스턴스 실패 시에도 서비스가 지속될 수 있도록 부하 분산과 이중화를 설정하는 방법.

5. Failure Recovery (실패 복구)

• 백업 및 복원: 데이터를 손실 없이 복구하기 위한 백업 및 복원 절차.
• 롤백 전략: 실패한 배포를 이전 버전으로 롤백하는 방법.
• 애플리케이션 리스타트: 실패한 애플리케이션을 자동으로 다시 시작하여 복구하는 방법.

6. Best Practices (최선의 방법)

• 테스트 및 검증: 애플리케이션이 예상치 못한 실패에 대해 얼마나 잘 대응하는지 확인하기 위한 스트레스 테스트 및 장애 시나리오 테스트.
• Documentation (문서화): 실패 대응 및 복구 절차를 문서화하여 팀 내에서 공유하고 일관된 대응이 가능하도록 하는 방법.
• Continuous Improvement (지속적인 개선): 실패에서 교훈을 얻고, 시스템과 프로세스를 지속적으로 개선하여 미래의 실패를 예방하는 방법.

---

Quiz.

1. The cluster is broken. We tried deploying an application but it's not working. Troubleshoot and fix the issue.
Start looking at the deployments.

 

controlplane ~ ➜  k get po -n kube-system 
NAME                                   READY   STATUS             RESTARTS       AGE
coredns-768b85b76f-mkjwh               1/1     Running            0              7m6s
coredns-768b85b76f-wkmwm               1/1     Running            0              7m6s
etcd-controlplane                      1/1     Running            0              7m20s
kube-apiserver-controlplane            1/1     Running            0              7m20s
kube-controller-manager-controlplane   1/1     Running            0              7m21s
kube-proxy-ltgxz                       1/1     Running            0              7m6s
kube-scheduler-controlplane            0/1     CrashLoopBackOff   5 (100s ago)   5m4s


controlplane ~ ➜  k describe po -n kube-system kube-scheduler-controlplane 
Name:                 kube-scheduler-controlplane
...
Command:
### kube-schedulerrrr 잘못 써져있습니다. kube-scheduler로 수정해줄게요! 
      kube-schedulerrrr
      --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
      --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
      --bind-address=127.0.0.1
      --kubeconfig=/etc/kubernetes/scheduler.conf
      --leader-elect=true
State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       StartError
      Message:      failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "kube-schedulerrrr": executable file not found in $PATH: unknown
...

해당 manifest를 수정하기 위해서는 /etc/kubernetes/manifests/kube-scheduler.yaml 여기서 수정해주어야합니다

controlplane /etc/kubernetes/manifests ➜  vi kube-scheduler.yaml 
'''
  - command:
  ### 이부분 수정
    - kube-scheduler
    
 '''

 

2. Scale the deployment app to 2 pods.

Replicaset을 늘려주면 됩니다.

controlplane ~ ➜  k get rs
NAME             DESIRED   CURRENT   READY   AGE
app-5f58858856   1         1         1       20m

controlplane ~ ➜  k scale --replicas=2 rs/app-5f58858856 
replicaset.apps/app-5f58858856 scaled

 

3. Even though the deployment was scaled to 2, the number of PODs does not seem to increase. Investigate and fix the issue. Inspect the component responsible for managing deployments and replicasets

controlplane /etc/kubernetes/manifests ➜  kubectl logs -n kube-system kube-controller-manager-controlplane
I0822 15:33:31.385264       1 serving.go:380] Generated self-signed cert in-memory
E0822 15:33:31.385403       1 run.go:74] "command failed" err="stat /etc/kubernetes/controller-manager-XXXX.conf: no such file or directory"

controlplane /etc/kubernetes ➜  ls
admin.conf               kubelet.conf  pki             super-admin.conf
controller-manager.conf  manifests     scheduler.conf

controlplane /etc/kubernetes ➜  vi manifests/kube-controller-manager.yaml 
  containers:
  - command:
    - kube-controller-manager
...
	### controller-manager.conf 로 수정
	- --kubeconfig=/etc/kubernetes/controller-manager-XXXX.conf
...



controlplane /etc/kubernetes ➜  k get rs
NAME             DESIRED   CURRENT   READY   AGE
app-5f58858856   2         2         2       25m

 

 4. Something is wrong with scaling again. We just tried scaling the deployment to 3 replicas. But it's not happening. Investigate and fix the issue.

원인분석:

controlplane ~ ➜  k get deploy
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    2/3     2            2           27m

controlplane ~ ➜  k get po -n kube-system 
NAME                                   READY   STATUS             RESTARTS      AGE
coredns-768b85b76f-mkjwh               1/1     Running            0             29m
coredns-768b85b76f-wkmwm               1/1     Running            0             29m
etcd-controlplane                      1/1     Running            0             30m
kube-apiserver-controlplane            1/1     Running            0             30m
kube-controller-manager-controlplane   0/1     CrashLoopBackOff   3 (37s ago)   84s
kube-proxy-ltgxz                       1/1     Running            0             29m
kube-scheduler-controlplane            1/1     Running            0             11m

controlplane ~ ➜  k logs kube-controller-manager-controlplane -n kube-system 
I0822 15:39:58.782940       1 serving.go:380] Generated self-signed cert in-memory
E0822 15:39:59.381117       1 run.go:74] "command failed" err="unable to load client CA provider: open /etc/kubernetes/pki/ca.crt: no such file or directory"

 

hostPath가 잘못되었습니다. 

controlplane /etc/kubernetes/manifests ➜  vi kube-controller-manager.yaml 
## 수정 전
- hostPath:
      path: /etc/kubernetes/WRONG-PKI-DIRECTORY
      type: DirectoryOrCreate
      
 ## 수정후 
   - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate

 

---

오늘 Control Plane Failure에 대해 알아보았습니다. 

Manifest 위치를 잊어버려서 조금 애먹었지만 이제 확실히 알게 되었습니다. 

다음시간에는 Worker Node Failure 를 알아보겠습니다. 

 

---

참조

※ Udemy Labs - Certified Kubernetes Administrator with Practice Tests