IL-0098 2i2c · 2026-03-31kubernetesnetworking
2i2c 는 최근 클러스터의 인그레스 컨트롤러를 ingress-nginx 에서 nginx-ingress 로 옮겼다. 컨트롤러를 옮기면서 여러 인그레스가 같은 호스트를 나눠 쓸 때의 동작이 바뀌었고, 적어도 2i2c-aws-us 와 awi-ciroh 두 클러스터에서 TLS 인증서 발급이 깨졌다. 2026년 3월 31일 16:00 새 허브를 띄우려다 실패하자 엔지니어가 장애를 선언했다.
cert-manager 는 ACME 발급 절차를 통과하려고 임시 인그레스를 만든다. nginx-ingress 에서는 같은 호스트의 허브 인그레스가 이 임시 인그레스보다 우선했고 요청은 301 응답을 받았다. 그래서 인증서 주문이 pending 에 머물렀다. 문제는 새 인증서가 필요한 배포를 할 때 나타났다.
엔지니어는 전날 밤 시도한 cert-manager 의 edit-in-place 어노테이션이 잘 듣지 않았다고 보고 master-minion 인그레스 방식을 먼저 시험했다. 인증서는 제대로 발급됐지만 minion 인그레스에 paths 를 넣어야 해서 인그레스를 둘로 나눠야 했고, 이를 범용으로 적용하기는 어려웠다. 그래서 다시 edit-in-place 방식으로 돌아가 TLS 가 필요한 인그레스 객체에 어노테이션을 달았고, 17:16 에 장애를 해결했다. 장애 시간은 1시간 15분 39초였다.
새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.
그 전날 엔지니어는 2i2c-aws-us 클러스터에서 support 배포를 다시 만들었고, TLS 인증서 주문이 pending 에 멈춰 있는 것을 봤다. nginx-ingress 로그에는 301 응답이 찍혀 있었고, 엔지니어는 이를 http 에서 https 로 넘기는 리다이렉트라고 짐작했다.
처음에는 SSL 리다이렉트 같은 새 기본값 때문인지 의심했지만, nginx-ingress 와 ingress-nginx 문서를 살펴보니 그렇지 않았다. 더 들여다보니 cert-manager 가 ACME 발급 절차를 위해 만드는 임시 인그레스보다 허브 인그레스 같은 본래 인그레스가 우선하고 있었다. 엔지니어는 이것이 301 의 원인이라고 봤다.
16:05 에 awi-ciroh 클러스터에서 폐기했던 워크숍 허브를 다시 배포하자 같은 현상이 나왔다. 최근 JS2 클러스터도 새 인그레스로 다시 배포했지만 거기서는 이 현상이 보이지 않았다.
원인 ? 업그레이드로 깨진 호환성
새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.
인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러