IL-0180 Sunwoo Park · 2023-05-18kubernetesgcpnetworking
글쓴이는 운영 GKE 클러스터에서 Istio 1.7.4 를 쓰고 있었다. 2023-05-18 19:52 에 GKE 컨트롤 플레인이 1.22.17-gke.7500 에서 1.23.17-gke.1700 으로 자동 업그레이드됐고, 9분 뒤 20:01 에 Slack 알림이 왔다. istiod 는 v1beta1.Ingress 와 v1beta1.ValidatingWebhookConfiguration 리소스를 찾지 못했다. Istio 1.7.4 는 Ingress 와 ValidatingWebhookConfiguration 관련 코드에서 v1beta1 API 를 썼는데, 업그레이드된 클러스터에서는 이 API 를 쓸 수 없었다. 글쓴이는 Istio 를 1.13.3 으로 올려 문제를 해결했다. 1.13.3 은 같은 코드에서 v1 API 를 쓴다.
당시에는 Istio 지원 종료를 원인으로 정리했다. 글쓴이는 나중에 독자의 메일을 받고 GCP 로그 탐색기에서 클러스터 업그레이드 기록을 찾았다. resource.type="gke_cluster" 와 protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)" 조건으로 검색해 위 자동 업그레이드를 확인했다. 그 전 마이너 버전 업그레이드는 04-11 에 1.21.14-gke.18800 에서 1.22.17-gke.5400 으로 올라간 것이었다. 그 뒤 04-15 에 1.22.17-gke.6100 으로, 05-13 에 1.22.17-gke.7500 으로 패치 업그레이드가 있었다.
Kubernetes 1.22 부터 이 v1beta1 API 들이 deprecated 됐는데도 04-11 의 1.22 업그레이드 때는 문제가 없었다. 독자는 GKE 가 Ingress 의 v1beta1 API 를 1.23 까지 한 번 유예해 준다는 GKE 문서 내용을 근거로, 웹훅 API 도 GKE 가 유예해 줬을 것으로 추측했다. 글쓴이는 1.23 부터 MutatingWebhookConfiguration 과 ValidatingWebhookConfiguration 의 v1beta1 API 를 더 이상 쓸 수 없다는 점을 확인하고, 1.23 자동 업그레이드가 원인이라고 결론 내렸다. 참고로 Istio 1.7 이 공식 지원하는 Kubernetes 버전은 1.16, 1.17, 1.18 이었다.
2023-05-18 20:01 에 Slack 알림이 왔고, 운영 GKE 클러스터의 Istio 가 제대로 동작하지 않았다.
istiod 에러 로그에는 v1beta1.Ingress 와 v1beta1.ValidatingWebhookConfiguration 리소스를 찾을 수 없다는 오류가 찍혔다. 나중에 원인을 짚어 준 독자는 Istio 1.7.4 코드에서 "Patch webhook failed" 오류 문구를 찾아 보면 deprecated API 를 쓰는 곳을 확인할 수 있다고 알려 줬다.
글쓴이는 처음에 Istio 지원 종료를 원인으로 보고 Istio 를 업그레이드해 장애를 정리했다. 반년쯤 지나 그 글을 읽은 독자가 메일로 Istio 지원 종료만으로는 달라질 것이 없어 보인다며, 그 무렵 GKE 자동 업그레이드가 있지 않았느냐고 물었다.
증상 ? 서비스 중단
원인 ? 업그레이드로 깨진 호환성
GKE 자동 업그레이드 9분 뒤인 20:01 에 Slack 알림이 왔다.
–
Kubernetes, Istio 처럼 함께 쓰는 패키지는 버전 호환성 매트릭스를 GitHub 이나 문서에서 확인한다. 업그레이드는 운영 환경에 올리기 전에 테스트 환경에서 먼저 해 본다. ArgoCD 같은 자동화 도구로 배포와 버전을 관리한다. 운영 환경은 버전을 최소 6개월 유지하되 지원 종료 3개월 전에는 업그레이드한다. 업그레이드 전에는 항상 백업한다. 처음에는 Istio 지원 종료를 원인으로 봤지만, GKE 업그레이드 기록을 다시 보고 나서야 진짜 원인을 찾았다.
같은 원인 · 공통 GKE 컨트롤 플레인
같은 원인 · 공통 어드미션 웹훅
같은 원인 · 공통 어드미션 웹훅