문제
The idea here is to misconfigure the Apiserver in different ways, then check possible log locations for errors.
You should be very comfortable with situations where the Apiserver is not coming back up.
Configure the Apiserver manifest with a new argument --this-is-very-wrong .
Check if the Pod comes back up and what logs this causes.
Fix the Apiserver again.
---
(구글 번역)
여기서의 아이디어는 Apiserver를 다양한 방식으로 잘못 구성한 다음 가능한 로그 위치에 오류가 있는지 확인하는 것입니다.
Apiserver가 다시 작동하지 않는 상황이 매우 편안할 것입니다.
새로운 인수 --this-is-very-wrong 으로 Apiserver 매니페스트를 구성합니다.
Pod가 다시 작동하는지 확인하고 이로 인해 발생하는 로그를 확인하세요.
Apiserver를 다시 수정하세요.
🟢 문제 분석하기
kube-apiserver의 매니페스트가 위치한 `/etc/kubernetes/manifests` 폴더에 `kube-apiserver.yaml` 파일을 백업한 뒤 일부러 고장시키고, 복구시키는 방법에 대한 방법 확인하기
🟠 Step 1. 매니페스트 백업하기
static pod를 생성하는 위치인 /etc/kubernetes/manifest 폴더 내 kube-apiserver.yaml 파일을 Home dir에 백업합니다.
cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.orig
🟠 Step 2. 매니페스트를 수정해서 static pod(kube-apiserver) 장애 발생시키기
vi /etc/kubernetes/manifests/kube-apiserver.yaml
`spec.containers.command` 하위에 `--this-is-very-wrong` 이라는 오류를 발생시키는 인자값을 추가 입력한 뒤 저장합니다.
아래와 같이 바로 장애가 발생하는것을 확인할 수 있습니다.
🟠 Step 3. kube-apiserver 장애 시 로그 확인 방법
방법 1. `/var/log/pods` 하위 로그 확인
방법 2. `/var/log/containers` 하위 로그 확인
방법 3. `crictl ps -a + crictl logs` 명령으로 확인
방법 4. kubelet logs : `/var/log/syslog` or `journalctl -u kubelet | tail -5` 명령으로 확인
🟢 정리
일단 kubectl get pod -A가 안된다면(apiserver가 응답을 못하는 경우), control-plane 노드에 접속해서 kubelet 데몬 상태를 확인 해본다. 그 후 로그를 확인해 봤을 때 6443 포트를 사용하는 kube-apiserver의 문제가 있음을 확인하고, /var/log/pods 혹은 crictl 명령을 사용해 api-server의 로그를 확인하고, 해당 로그 메시지에 맞춰 문제 해결을 진행하자!
'클라우드' 카테고리의 다른 글
[cks][killershell] Auditing Enable Audit Logging 실습 (0) | 2024.07.31 |
---|---|
[cks][killershell] NodeRestriction 실습 (0) | 2024.07.30 |
[EKS] IaC (0) | 2024.04.27 |
[k8s] Pod의 전략적 배치 - Node Affinity (0) | 2024.04.17 |
[EKS] CI/CD (0) | 2024.04.16 |