[데브옵스를 위한 쿠버네티스 마스터] 클러스터 유지와 보안, 트러블슈팅 - 클러스터, 애플리케이션 트러블 슈팅 가이드

클러스터, 애플리케이션 트러블 슈팅 가이드

---

트러블은 언제나 발생

• 트러블은 매번 이슈가 됨
• 쿠버네티스도 예외는 아니며 시스템이 단순하지 않기 때문에 더 철저한 점검 방법이 필요
• 트러블 슈팅의 기본은 최소단위로 테스트하기!
• 크게 두 가지로 클러스터, 애플리케이션 트러블이 발생 가능

---

애플리케이션 트러블 슈팅

• 애플리케이션에서 트러블이 발생하는 경우에는 해결 방법이 비교적 단순
• 각각의 포드, 컨피그맵 등의 로직에서 무엇이 잘못됐는지 확인
• 일반적으로 이름이나 레이블링이 다른 데서 발생

---

클러스터 트러블 슈팅

• 클러스터에서 발생하는 트러블 슈팅의 경우는 쿠버네티스 시스템에 대한 깊은 이해를 요구
• 일반적으로 다수에서 발생하기 보다는 한 두 군데의 장애가 존재
• Kubectl이 접속되지 않을 때는 serverapi 자체의 문제일 가능성이 큼
• 컨테이너가 장시간 배치되지 않는 현상은 스케줄러의 문제일 가능성이 존재
• Kubectl에 접속이 됐으나 다른 시스템에 사용되는 포드들이 올라오지 않을 경우에는 개별 yaml과 conf를 각각 확인 필요
• 특정 노드나 포드가 통신되지 않을 때는 kubelet이 제대로 동작하는지 확인, 특별한 경우 Certificate의 이슈가 있을 수 있음

• 참고하면 좋은 문서: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster/

---

클러스터 트러블 슈팅

• 마스터 노드의 로그 저장 위치

  • cat /var/log/pods/kube-system_kube-apiserver-master_b341289b9cc03b1fba72d50054ecfe2f//var/log/kube-scheduler.log
  • /var/log/kube-controller-manager.log

• 워커 노드의 로그 저장 위치

  • /var/log/kubelet.log
  • /var/log/kube-proxy.log

---

클러스터 트러블 슈팅

• Journalctl을 사용하여 동작하지 않는 노드의 데이터 확인
  • 서비스 쪽 장애 발생시
    • cni plugin 문제
    • 파일명이 잘못 되어있었음

      $ journalctl -u kubelet