사례4건

4건 중 1~4번째

1. IL-0204 Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다.

   Render2024

   증상

   2022년 1월 Render 의 프랑크푸르트 Kubernetes 클러스터 하나에서 새 배포와 크론 잡 실행이 실패했다. etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸린 상태였다.

   컨트롤 플레인 무응답배포 실패DNS 조회 실패오류율 상승

   촉발

   etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다.

   원인

   용량 한계

   구성 요소

   etcdCoreDNS쿠버네티스 API 서버

   기여 요인

   기본 설정 방치수동 조치 악화

   후속 조치

   • CoreDNS 를 컨트롤 플레인 노드가 아닌 데이터 플레인 노드에서 돌게 했다.
   • etcd 를 전용 노드에서 돌게 했다.

   교훈

   CoreDNS 는 API 서버가 내려가 있어도 메모리 캐시로 DNS 질의에 답할 수 있지만, 초기화할 때는 API 서버가 필요하다. CoreDNS 가 컨트롤 플레인 노드에 있었기 때문에, 컨트롤 플레인 장애 중에 노드를 재부팅하자 새 배포와 크론 잡만 실패하던 장애가 이미 돌던 서비스로 가는 요청까지 실패하는 장애로 커졌다. 핵심 문제는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되어 있지 않았다는 점이다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 CoreDNS 가 재시작될 수 있었다.

   사례 보기
2. IL-0184 kubeadm 클러스터의 API 서버와 내부 인증서가 만료돼 JupyterHub KubeSpawner 가 컨테이너를 만들지 못하고 kubectl 연결이 거부됐다

   dbhang2021

   증상

   JupyterHub 의 KubeSpawner 로 컨테이너를 만들 때 처음 보는 오류가 나며 생성이 실패했다. 오류는 SSL 인증서가 만료됐다는 내용이었다.

   컨트롤 플레인 무응답배포 실패

   원인

   인증서·자격 증명 만료

   구성 요소

   쿠버네티스 API 서버kubelet

   기여 요인

   한계 미인지한계 경보 부재

   감지

   KubeSpawner 가 컨테이너를 만들다가 처음 보는 SSL 인증서 오류를 냈다. 글쓴이는 오류 로그를 검색해 클러스터 내부 인증서 만료가 원인임을 알았다.

   조치

   • `kubeadm alpha certs check-expiration` 으로 인증서별 남은 기간을 확인했다.
   • 기존 인증서 파일과 `/etc/kubernetes/*.conf` 파일을 백업 디렉터리로 옮겼다.
   • `kubeadm init phase certs all` 로 모든 인증서를 새로 만들었다.
   • `kubeadm init phase kubeconfig all` 로 admin.conf 를 비롯한 kubeconfig 파일을 새로 만들었다.
   • 새 admin.conf 를 `~/.kube/config` 로 복사하고 kubelet 을 재시작했다.
   • 예전 인증 정보를 들고 있던 kube-system 컨테이너들을 `docker restart` 로 모두 재시작했다.

   교훈

   kubeadm 클러스터의 인증서가 만료되면 kubectl 이 API 서버에 연결하지 못하므로 kubectl 로는 갱신할 수 없고, 노드에서 kubeadm 으로 직접 갱신해야 한다. 갱신 뒤에는 인증서만이 아니라 kubeconfig 파일도 새로 만들어야 하고, 예전 인증 정보를 들고 있는 kube-system 파드도 재시작해야 한다. 글쓴이는 클러스터를 처음부터 직접 구성해 봤다면 인증서를 쓴다는 것을 바로 알았을 것이고, 명령 한 줄로 막을 수 있는 문제였다고 돌아봤다.

   사례 보기
3. IL-0108 워크숍 중 운영 클러스터에 적용한 Alcide admission 컨트롤러 때문에 Deployment 생성과 수정이 타임아웃되었다

   DFDS2020

   증상

   2020-11-04 14:41 CET 에 사용자들이 쿠버네티스 클러스터 Hellman 에 배포할 때 타임아웃이 난다고 알려 왔다.

   배포 실패컨트롤 플레인 지연

   촉발

   Alcide 워크숍 중 13:13 CET 에 운영 클러스터에 Alcide admission 컨트롤러를 적용했다. 팀은 이미 있던 것을 다시 적용하는 일이라 영향이 없을 거라고 여겼다.

   원인

   설정 변경

   구성 요소

   어드미션 웹훅쿠버네티스 API 서버

   기여 요인

   설정 테스트 부재미검증 가정모니터링 사각지대

   감지

   팀은 적용 1시간 28분 뒤인 14:41 CET 에 사용자들이 Hellman 에 배포할 때 타임아웃이 난다고 알려 와서 문제를 알았다. 이어 15:04 에 타임아웃을 확인했다.

   조치

   • Alcide admission 컨트롤러를 껐다 켜 보며 이 컨트롤러가 원인인지 확인했다.
   • Alcide admission 컨트롤러를 영구히 지웠다.

   후속 조치

   • 쿠버네티스 Deployment 의 타임아웃을 모니터링한다.
   • kube-apiserver 의 5xx 응답 코드를 모니터링한다.

   교훈

   새로 들이는 구성 요소는 샌드박스 클러스터에 적용한다. Alcide 를 완전히 걷어낼 때까지 팀은 이를 유지할 수 있는 지식을 갖춰야 한다.

   사례 보기
4. IL-0505 GKE 에서 kubectl logs 가 모든 파드에서 실패해 mybinder.org 사용자에게 빌드 로그가 가지 않았다

   Binder Project2019

   증상

   kubectl logs -f <pod> 가 모든 파드에서 실패했다. mybinder.org 는 파드 로그로 빌드 로그를 전달하므로 사용자가 새 빌드의 로그를 보지 못했다. 빌드 자체는 정상으로 돌았다.

   모니터링 중단배포 실패

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버

   기여 요인

   디버그 접근 제한

   조치

   • API 서버 로그가 가리킨 노드 gke-prod-a-users-b921bb88-rd5d 를 cordon 하고, 비면 풀에서 빼기로 했다.
   • rd5d 노드를 drain 해 풀에서 빼자 kubectl logs 가 돌아오고 모두 정상으로 동작했다.

   후속 조치

   • kubectl logs 가 동작하는지 시험하고 동작하지 않으면 알림을 보낸다.
   • API 서버 로그를 받는 명령을 SRE 가이드에 넣는다.
   • 의심스러운 네트워크 상태를 알아보는 방법을 SRE 가이드에 적는다.

   교훈

   kubectl logs 가 안 되고 클러스터 전체를 업그레이드하는 동안에도 실행 성공률은 97.5% 아래로 떨어지지 않았다. 문제 노드를 빼자 모두 돌아왔다. 원인이 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보여서 찾기가 아주 어려웠다. 노드를 의심했을 때 kubectl describe node gke-prod-a-users-b921bb88-rd5d 를 받아 두었으면 정상 노드와 비교할 수 있었다. 노드 주소 목록에서 ExternalIP 와 InternalIP 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다.

   사례 보기

원인별4