{"id":"IL-0098","org":"2i2c","date":"2026-03-31","docs":["https://github.com/2i2c-org/infrastructure/issues/8016","https://github.com/2i2c-org/infrastructure/issues/3278"],"title":{"en":"After 2i2c moved from ingress-nginx to nginx-ingress, a hub's Ingress took priority over cert-manager's temporary Ingress for the same host, so new hubs could not get TLS certificates","ko":"ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다."},"domain":["kubernetes","networking"],"impact":{"scope":"TLS certificate issuance on at least two 2i2c clusters (2i2c-aws-us and awi-ciroh); new hubs that needed new certificates could not be launched","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Swapping one ingress controller for another can change how Ingress objects that share a host are combined. cert-manager's temporary challenge Ingress depends on that behaviour, so the breakage shows up when a deployment needs a new certificate.\n\n2i2c notes that it got lucky: it had already learned of this possible cause while testing on an internal cluster, and changing the cert-manager configuration was quick.","ko":"인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다."},"related":[],"sources":[{"url":"https://github.com/2i2c-org/incident-reports/blob/main/reports/2026-03-31-unable-to-provision-new-tls-certs.pdf","kind":"github","license":"unknown","archived":null}],"summary":{"en":"2i2c had recently migrated its clusters from the ingress-nginx controller to nginx-ingress, and the two treat several Ingress objects that share the same host differently. To satisfy the ACME issuer flow, cert-manager creates a temporary Ingress for the host it needs a certificate for. Under nginx-ingress the hub's existing Ingress for that host took priority, the challenge request was answered with a 301, and certificate orders stayed pending. The problem showed up when a deployment needed a new certificate, on at least the 2i2c-aws-us and awi-ciroh clusters.\n\nAn incident was declared at 16:00 on 31 March 2026. The night before, the engineer had tried cert-manager's annotations for editable Ingresses without clear success. At 16:43 the engineer tried the master-minion Ingress model instead; it issued the certificates, but it requires the paths to be set in the minion Ingress, which would mean splitting each Ingress in two, and that was hard to do in a general way. The engineer went back to editable Ingresses: annotating the Ingress objects that need TLS so that cert-manager may change them in place (edit-in-place) restored certificate issuance. The incident was resolved at 17:16, 1 hour 15 minutes 39 seconds after it was declared.","ko":"2i2c 는 최근 클러스터의 인그레스 컨트롤러를 ingress-nginx 에서 nginx-ingress 로 옮겼다. 컨트롤러를 옮기면서 여러 인그레스가 같은 호스트를 나눠 쓸 때의 동작이 바뀌었고, 적어도 2i2c-aws-us 와 awi-ciroh 두 클러스터에서 TLS 인증서 발급이 깨졌다. 2026년 3월 31일 16:00 새 허브를 띄우려다 실패하자 엔지니어가 장애를 선언했다.\n\ncert-manager 는 ACME 발급 절차를 통과하려고 임시 인그레스를 만든다. nginx-ingress 에서는 같은 호스트의 허브 인그레스가 이 임시 인그레스보다 우선했고 요청은 301 응답을 받았다. 그래서 인증서 주문이 pending 에 머물렀다. 문제는 새 인증서가 필요한 배포를 할 때 나타났다.\n\n엔지니어는 전날 밤 시도한 cert-manager 의 edit-in-place 어노테이션이 잘 듣지 않았다고 보고 master-minion 인그레스 방식을 먼저 시험했다. 인증서는 제대로 발급됐지만 minion 인그레스에 paths 를 넣어야 해서 인그레스를 둘로 나눠야 했고, 이를 범용으로 적용하기는 어려웠다. 그래서 다시 edit-in-place 방식으로 돌아가 TLS 가 필요한 인그레스 객체에 어노테이션을 달았고, 17:16 에 장애를 해결했다. 장애 시간은 1시간 15분 39초였다."},"trigger":{"en":"Creating new hub deployments that needed new TLS certificates on clusters recently migrated from ingress-nginx to nginx-ingress.","ko":"nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다."},"severity":"unknown","symptoms":["requests-misrouted","deploys-failing"],"timeline":{"detected_after":null,"resolved_after":"1h 15m"},"date_kind":"incident","detection":{"en":"An attempt to launch a new hub failed; the engineer had seen certificate orders stuck pending on another cluster the day before and declared an incident.","ko":"새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다."},"components":["ingress","cert-manager"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"annotated the Ingress objects that need TLS so that cert-manager could edit them in place to complete the ACME challenge","ko":"TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다."}}],"action_items":[{"text":{"en":"Follow-up tracked in https://github.com/2i2c-org/infrastructure/issues/8016","ko":"후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다."}},{"text":{"en":"Follow-up tracked in https://github.com/2i2c-org/infrastructure/issues/3278","ko":"후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다."}}],"contributing":["delayed-effect-change"],"recurrence_of":null,"symptoms_text":{"en":"An attempt to launch a new hub failed because its ingress could not obtain a new TLS certificate. The day before, the same engineer had recreated the support deployment on the 2i2c-aws-us cluster and seen its TLS certificate orders stuck pending.\n\nThe nginx-ingress logs showed 301 responses, which the engineer suspected were HTTP-to-HTTPS redirects. The first question was whether redirecting to SSL had become a new default, but the documentation for both nginx-ingress and ingress-nginx suggested it had not. Looking at how the ACME issuer flow works, the engineer then found evidence that the hub's own Ingress was taking priority over the temporary Ingress that cert-manager creates for the challenge, which likely produced the 301.\n\nThe same failure then appeared on the awi-ciroh cluster, where a decommissioned workshop hub had just been redeployed and needed new certificates. The JS2 cluster, recently redeployed with the new ingress controller, had shown no sign of it.","ko":"새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.\n\n그 전날 엔지니어는 2i2c-aws-us 클러스터에서 support 배포를 다시 만들었고, TLS 인증서 주문이 pending 에 멈춰 있는 것을 봤다. nginx-ingress 로그에는 301 응답이 찍혀 있었고, 엔지니어는 이를 http 에서 https 로 넘기는 리다이렉트라고 짐작했다.\n\n처음에는 SSL 리다이렉트 같은 새 기본값 때문인지 의심했지만, nginx-ingress 와 ingress-nginx 문서를 살펴보니 그렇지 않았다. 더 들여다보니 cert-manager 가 ACME 발급 절차를 위해 만드는 임시 인그레스보다 허브 인그레스 같은 본래 인그레스가 우선하고 있었다. 엔지니어는 이것이 301 의 원인이라고 봤다.\n\n16:05 에 awi-ciroh 클러스터에서 폐기했던 워크숍 허브를 다시 배포하자 같은 현상이 나왔다. 최근 JS2 클러스터도 새 인그레스로 다시 배포했지만 거기서는 이 현상이 보이지 않았다."},"updated_at":"2026-11-10T00:00:32.893324Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0098","org_slug":"2i2c"}