[kubernetes-troubleshooting] Namespace 삭제 명령에도 삭제되지 않는 Pod 삭제하기

# How to force deletion of pods on namespace ## 문제 상황 이전 게시글인 [삭제되지 않는 네임스페이스 ^Namespace 강제로 삭제하기](https://ccambo.blogspot.com/2021/01/kubernetes-troubleshooting-namespace.html) 를 통해 네임스페이를 삭제하는 방법을 알아 보았다. 이번 경우는 확실하게 눈으로 확인할 수 있는 파드 ^Pod 들이 남아 있고 `Terminating` 상태로 삭제되지 않는 문제가 발생했다. 테스트 했던 M3 오퍼레이터 ^Operator 를 장시간 유지하면서 etcd 클러스터가 응답하지 않는 상태가 발생했고, 삭제를 했지만 삭제되지 않는 문제인 상태다. ```bash $ kubectl -n m3cluster get pods NAME READY STATUS RESTARTS AGE ... etcd-0 1/1 Terminating 2 16d etcd-1 1/1 Terminating 2 16d etcd-2 1/1 Terminating 2 16d ... ``` ## 문제 원인 확인과 처리 방법 정상적으로 삭제될 수 있는 시간을 지나서도 `Terminating` 상태로 남아있는 상태는 대부분은 아래와 같은 원인으로 발생한다. - 파드에 처리되지 않는 파이널라이저 ^Finalizer 가 연결된 경우 - 파드가 종료 시그널에 응답하지 않는 경우 이런 상황에서 정보를 확인해야 한다. 1. **정보 출력** ```bash $ kubectl -n <namespace_name> get pod -p <pod_name> -o yml [> undeleted_pod.yaml] ``` 화면에 출력을 사용하던지 아니면 화일로 출력해서 내용 중에서 `status` 부분과 `metadata.finalizer` 내용을 검토한다. 2. **파이널라이저 확인** status 상에 별다른 문제가 없다면 출력된 정보에서 파이널라이저가 존재하는지 확인하고 아래의 명령을 사용해서 해당 파이널라이저를 제거한다. ```bash $ kubectl -n <namepsace_name> patch pod <pod_name> -p '{"metadata":{"finalizers":null}}' ``` 3. **노드 상태 확인** 파드가 정상적인 상태로 판단이 되면 노드를 확인해 봐야 한다. 출력물에서 `spec.nodeName` 을 통해서 배정된 노드 명을 확인하고 쿠버네티스 대시보드 등을 통해서 노드에 배정된 모든 파드가 `Terminating` 상태인지를 확인해야 한다. 이 상황이라면 쿠버네티스 마스터를 통해서 삭제 요청된 내용이 해당 노드가 응답할 수 있는 상태가 되어야 처리될 수 있으므로 노드를 재 부팅하는 등으로 처리하면 된다. 4. **포드 강제 삭제** 위의 모든 상황이 정상적이라면 종료 시그널에 응답하지 않는 상태인 것으로 일반적으로는 다음과 같은 상황일 수 있다. - 인터럽트 신호를 허용하지 않는 사용자 공간의 루프 실행 중 - 애플리케이션 런타임의 유지 관리 프로세스 진행 중 (예를 들면 가비지 수집 등) 이런 경우라면 강제로 종료 시키는 방법을 사용할 수 있다. 그러나 이런 처리는 향후 예상치 않은 문제가 발생할 수도 있다. ```bash $ kubectl -n <namespace_name> delete pod <pod_name> --grace-period=0 --force ``` 하나의 파드라면 위의 명령을 사용하면 되지만 여러 개의 파드가 대상이라면 아래와 같이 일괄처리도 가능하다. ```bash for p in $(kubectl -n <namespace_name> get pods | grep Terminating | awk '{print $1}'); do kubectl -n <namespace_name> delete pod $p --grace-period=0 --force; done ``` 5. **kubelet 재 시작** 마지막으로 해 볼 수 있는 것은 종료 시그널이 실제 배정된 노드의 `kubelet` 과 연결되지 못해서 처리가 안되는 경우로 SSH를 통해 해당 노드로 접근해서 kubelet을 재 시작하는 것이다. 당연히 이를 처리하기 위한 권한이 존재해야 하고, 처리하기 전에 kubelet 로그를 확인해서 의심되는 상황이 존재하는지를 우선 검토하도록 한다.