{"id":"IL-0180","org":"Sunwoo Park","date":"2023-05-18","docs":[],"title":{"en":"A GKE control plane auto-upgrade from 1.22 to 1.23 removed the v1beta1 Ingress and ValidatingWebhookConfiguration APIs that Istio 1.7.4 still used, and Istio stopped working in production","ko":"GKE 컨트롤 플레인이 1.22 에서 1.23 으로 자동 업그레이드되면서 v1beta1 API 를 쓰던 Istio 1.7.4 가 제대로 동작하지 않았다"},"domain":["kubernetes","gcp","networking"],"impact":{"scope":"Istio (istiod) in the production GKE cluster","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The first diagnosis, end of support for Istio, was wrong; the real cause was found by matching the alert time against the cluster's UPGRADE_MASTER operations in Logs Explorer.\n\nThe author recommends checking the version compatibility matrices of Kubernetes, Istio and other packages, keeping a production version for at least six months and upgrading three months before end of support, keeping the test environment on the latest version, backing up before upgrades, managing deployments and versions with a tool such as Argo CD, and testing upgrades in a test environment before production.","ko":"Kubernetes, Istio 처럼 함께 쓰는 패키지는 버전 호환성 매트릭스를 GitHub 이나 문서에서 확인한다. 업그레이드는 운영 환경에 올리기 전에 테스트 환경에서 먼저 해 본다. ArgoCD 같은 자동화 도구로 배포와 버전을 관리한다. 운영 환경은 버전을 최소 6개월 유지하되 지원 종료 3개월 전에는 업그레이드한다. 업그레이드 전에는 항상 백업한다. 처음에는 Istio 지원 종료를 원인으로 봤지만, GKE 업그레이드 기록을 다시 보고 나서야 진짜 원인을 찾았다."},"related":[],"sources":[{"url":"https://parksunwoo.github.io/dev/2024/03/10/gke-upgrade-istio-version-compatibility.html","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"The production GKE cluster ran Istio 1.7.4, released around late October to November 2020. Its code used the networking.k8s.io/v1beta1 API for Ingress and the admissionregistration.k8s.io/v1beta1 API for ValidatingWebhookConfiguration, and Istio 1.7 officially supported only Kubernetes 1.16, 1.17 and 1.18. Kubernetes 1.22 moved both APIs from v1beta1 to the GA version v1. When GKE auto-upgraded the control plane to 1.23 on 2023-05-18, istiod could no longer find the v1beta1 resources and Istio stopped working. Upgrading Istio from 1.7.4 to 1.13.3, whose code uses the v1 APIs, made it compatible with GKE 1.23 and resolved the outage.\n\nThe post works out why the failure came with 1.23 and not with the 1.22 upgrade in April. The reader found a GKE document saying that Ingress could keep using the v1beta1 API up to 1.23 as a one-time exception, and guessed that the webhook APIs had a similar grace period on GKE. The author then found that on GKE 1.23 and later the v1beta1 MutatingWebhookConfiguration and ValidatingWebhookConfiguration APIs are no longer available, which matches the timing. The reader also traced Istio's support history: up to 1.9 Istio used the v1beta1 APIs, 1.10 prepared for the deprecation and listed Kubernetes 1.22 as tested but not supported, and, by the reader's guess, 1.11 was the first to officially support 1.22. The reader suggested searching the Istio 1.7.4 code for the error \"Patch webhook failed\" to find where the deprecated API is used.\n\nThe original diagnosis, end of support for Istio, was corrected only because a reader questioned it by email; the cluster's upgrade history in Logs Explorer settled the timing.","ko":"글쓴이는 운영 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 를 쓴다.\n\n당시에는 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 으로 패치 업그레이드가 있었다.\n\nKubernetes 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 이었다."},"trigger":{"en":"GKE automatically upgraded the production cluster's control plane from 1.22.17-gke.7500 to 1.23.17-gke.1700 at 19:52 on 2023-05-18.","ko":"2023-05-18 19:52 에 GKE 컨트롤 플레인이 1.22.17-gke.7500 에서 1.23.17-gke.1700 으로 자동 업그레이드됐다. 클러스터의 Istio 1.7.4 는 networking.k8s.io/v1beta1 과 admissionregistration.k8s.io/v1beta1 API 를 쓰고 있었다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":"9m","resolved_after":null},"date_kind":"incident","detection":{"en":"A Slack alert at 20:01 on 2023-05-18, nine minutes after the control plane upgrade. The istiod error logs showed that the v1beta1 Ingress and ValidatingWebhookConfiguration resources could not be found.","ko":"GKE 자동 업그레이드 9분 뒤인 20:01 에 Slack 알림이 왔다."},"components":["istio","gke-control-plane","admission-webhook"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"upgraded Istio from 1.7.4 to 1.13.3","ko":"Istio 를 1.7.4 에서 1.13.3 으로 업그레이드해 GKE 1.23 과 호환되게 맞췄다."}}],"action_items":[],"contributing":["skipped-upgrades"],"recurrence_of":null,"symptoms_text":{"en":"On 2023-05-18 a Slack alert arrived at 20:01 and Istio stopped working properly in the production GKE cluster. The istiod error logs said that the v1beta1.Ingress and v1beta1.ValidatingWebhookConfiguration resources could not be found.\n\nIn an earlier post the author had put the outage down to Istio 1.7.4 being out of support and fixed it by upgrading Istio. About half a year later a reader (called A in the post) wrote that end of support by itself should not change anything, pointed at the two missing v1beta1 APIs, and asked which GKE versions the cluster had run before and after the outage. A Logs Explorer query, resource.type=\"gke_cluster\" protoPayload.metadata.operationType=~\"(UPDATE_CLUSTER|UPGRADE_MASTER)\" resource.labels.cluster_name=\"CLUSTER_NAME\", showed an UPGRADE_MASTER operation from 1.22.17-gke.7500 to 1.23.17-gke.1700 at 19:52 on 2023-05-18, nine minutes before the alert.\n\nThe control plane history for April and May read: 1.21.14-gke.18100 to 1.21.14-gke.18800 on April 2, 1.21.14-gke.18800 to 1.22.17-gke.5400 on April 11, 1.22.17-gke.5400 to 1.22.17-gke.6100 on April 15, 1.22.17-gke.6100 to 1.22.17-gke.7500 on May 13, and 1.22.17-gke.7500 to 1.23.17-gke.1700 on May 18. The outage followed the move to 1.23, not the move to 1.22 on April 11.","ko":"2023-05-18 20:01 에 Slack 알림이 왔고, 운영 GKE 클러스터의 Istio 가 제대로 동작하지 않았다.\n\nistiod 에러 로그에는 v1beta1.Ingress 와 v1beta1.ValidatingWebhookConfiguration 리소스를 찾을 수 없다는 오류가 찍혔다. 나중에 원인을 짚어 준 독자는 Istio 1.7.4 코드에서 \"Patch webhook failed\" 오류 문구를 찾아 보면 deprecated API 를 쓰는 곳을 확인할 수 있다고 알려 줬다.\n\n글쓴이는 처음에 Istio 지원 종료를 원인으로 보고 Istio 를 업그레이드해 장애를 정리했다. 반년쯤 지나 그 글을 읽은 독자가 메일로 Istio 지원 종료만으로는 달라질 것이 없어 보인다며, 그 무렵 GKE 자동 업그레이드가 있지 않았느냐고 물었다."},"updated_at":"2026-11-09T11:55:56.686943Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0180","org_slug":"sunwoo-park"}