인그레스 엔진엑스 종료, 게이트웨이 API, 헬름 | 3월 이후 컨트롤러는 어디로 옮기나?
2026년 3월 이후 커뮤니티 인그레스 엔진엑스에는 패치가 없다. 인그레스 API는 살아 있고 컨트롤러만 종료됐다. 파드 셀렉터, 스니펫 어노테이션, 게이트웨이 API, 헬름 병렬 전환, NKS와 EKS 서울, 개발자, 쿠버네티스, 클라우드 기준으로 옮길 칸을 나눈다. 비용 최적화 글과 관리형 비교 글과 자리를 섞지 않는다.
3월 이후 커뮤니티 인그레스 엔진엑스에는 패치가 없습니다. 파드는 그대로 돕니다. 새 취약점은 안 막힙니다. 인그레스 API 자체는 살아 있습니다. 죽은 건 컨트롤러 한 종류입니다. 저는 12개 사이트를 버셀에 올려서 쿠버를 매일 만지진 않습니다. 다만 후배 클러스터를 보면 네이버 클라우드 쿠버 서비스와 EKS 서울에 이 헬름이 아직 남아 있습니다. 먼저 파드 셀렉터로 쓰는지 확인하고, 스니펫 어노테이션을 센 다음, 게이트웨이 API로 갈지 다른 인그레스 컨트롤러로 옮길지 나눕니다.
여기는 이미 켜 둔 컨트롤러가 3월에 유지보수가 끊긴 자리만 봅니다. 숫자는 2026년 8월 쿠버네티스 블로그와 시그 네트워크 공지, 씨엔씨에프 7월 안내 기준입니다.
인그레스 API는 안 죽는다
끊긴 건 커뮤니티 컨트롤러입니다. 인그레스 자원 자체는 쿠버네티스에 남습니다.
2025년 11월 11일 시그 네트워크와 보안대응위원회가 퇴직을 알렸습니다. 최선 유지보수는 2026년 3월까지였습니다. 그 뒤로는 릴리스도, 버그 수정도, 보안 패치도 없습니다. 저장소는 읽기 전용으로 남기고, 헬름 차트와 이미지 아티팩트는 받을 수 있습니다. 이미 뜬 파드는 꺼지지 않습니다. 꺼지는 건 다음 구멍입니다.
자주 섞는 두 칸이 있습니다. 하나는 인그레스 API입니다. 다른 하나는 kubernetes/ingress-nginx 컨트롤러입니다. 씨엔씨에프 7월 글도 같은 오해를 먼저 풉니다. API는 기능이 얼어 있을 뿐 제거되지 않았습니다. 컨트롤러만 사람이 없습니다. 에프파이브가 파는 상용 엔진엑스 컨트롤러는 다른 제품입니다. 이름에 엔진엑스가 들어 있다고 같은 저장소가 아닙니다.
파드가 뜬다고 안전한 상태가 아니다 | 공지는 기존 배포가 깨지지 않는다고 적습니다. 그건 오늘 트래픽이 살아 있다는 뜻입니다. 내일 공개되는 취약점을 막을 사람이 없다는 뜻은 아닙니다. 8월에 남아 있으면 이미 다섯 달을 패치 없이 버틴 겁니다.
스니펫이 남긴 빚을 먼저 센다
옮기기 전에 어노테이션을 셉니다. 스니펫이 많으면 컨트롤러만 갈아끼울 수 없습니다.
커뮤니티 컨트롤러가 인기를 끈 이유는 유연함이었습니다. nginx.ingress.kubernetes.io/configuration-snippet 한 줄로 엔진엑스 설정을 아무거나 넣을 수 있었습니다. 공지는 그 유연함이 나중에 갚을 수 없는 빚이 됐다고 적습니다. 어제의 편의 옵션이 오늘의 보안 구멍입니다. 다른 컨트롤러로 옮겨도 이 키는 조용히 무시됩니다. 라우팅이 깨진 뒤에야 압니다.
제가 후배 클러스터에서 먼저 돌린 건 배포가 아닙니다. 인그레스 목록과 스니펫 개수입니다. 재작성 헤더, 타임아웃, 화이트리스트, 카나리 무게가 스니펫 안에 숨어 있었습니다. 그 숫자를 보기 전에는 게이트웨이로 갈지 다른 인그레스로 갈지 고르지 않습니다.
스니펫과 재작성 어노테이션 개수부터 센다
kubectl get ingress -A -o json \
| grep -c 'nginx.ingress.kubernetes.io/configuration-snippet' || true
kubectl get ingress -A -o json \
| grep -c 'nginx.ingress.kubernetes.io/server-snippet' || true
kubectl get ingress -A \
-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName
커뮤니티 컨트롤러는 3월에 끊겼다. 파드가 떠 있어도 패치 창은 이미 닫혔다
지금 우리 클러스터가 이걸 쓰고 있나
공지가 준 셀렉터 한 줄이면 됩니다. 헬름 릴리스 이름만 보면 놓칩니다.
시그 네트워크는 관리자 권한으로 app.kubernetes.io/name=ingress-nginx를 보라고 적습니다. 차트 이름이 nginx이거나 ingress여도 라벨이 다르면 다른 제품입니다. 반대로 릴리스 이름이 web이어도 라벨이 같으면 커뮤니티 컨트롤러입니다. 네이버 클라우드 쿠버 서비스와 EKS 애드온 화면도 한 번 엽니다. 콘솔이 어떤 이미지를 쓰는지 이름만으로 단정하지 않습니다.
에이케이에스는 다릅니다. 마이크로소프트는 앱 라우팅 애드온의 엔진엑스 자원을 2026년 11월까지, 긴급 보안 패치에 한해 지원한다고 적었습니다. 커뮤니티 저장소가 끊긴 것과 애저가 떠안은 창은 같은 달이 아닙니다. 한국에서 EKS나 네이버 클라우드를 쓰면 그 11월 창이 없습니다.
공지가 적은 셀렉터와 헬름 목록을 같이 본다
kubectl get pods --all-namespaces \
--selector app.kubernetes.io/name=ingress-nginx
kubectl get ingressclass
helm list -A
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
-o wide
콘솔 애드온 이름만 믿지 않는다 | 관리형 쿠버 화면에 엔진엑스라고 적혀 있으면 이미지 저장소와 차트 출처를 한 줄 더 봅니다. 커뮤니티 차트면 3월 이후 패치가 없습니다. 클라우드가 포크해서 고치는 이미지면 그 클라우드의 지원 종료일을 따로 적습니다.
주석만 옮길 시간이 없으면 컨트롤러만 바꾼다
인그레스 YAML을 당장 버릴 필요는 없습니다. 클래스만 다른 컨트롤러로 옮기는 길이 있습니다.
씨엔씨에프 7월 안내는 두 갈래입니다. 하나는 인그레스 API를 유지한 채 컨투어 같은 다른 컨트롤러로 옮기는 길입니다. 다른 하나는 게이트웨이 API로 자원을 다시 쓰는 길입니다. 시간이 없으면 전자입니다. 다만 커뮤니티 전용 어노테이션은 전부 번역하거나 버려야 합니다. 헤더 재작성, 카나리, 타임아웃이 스니펫에 있으면 사실상 재작성입니다.
게이트웨이 쪽은 역할이 갈립니다. 인프라는 게이트웨이를 만들고, 앱 팀은 에이치티티피 라우트를 만듭니다. 트래픽 분할과 헤더 매칭이 표준에 들어 있습니다. 변환기는 ingress2gateway가 있습니다. 자동 변환을 믿고 바로 자르지 않습니다. 스테이징에서 응답 헤더와 리다이렉트를 한 번씩 봅니다.
수년 동안 개발은 퇴근 후와 주말의 한두 명이었습니다. 2024년 쿠버콘에서 유지보수 팀이 축소와 후속 컨트롤러를 알렸습니다. 손드는 사람이 늘지 않았습니다. 인게이트는 성숙한 대체가 되지 못한 채 같이 접혔습니다. 시그 네트워크와 보안대응위원회는 추가 지원을 찾다 지쳤고, 사용자 안전을 이유로 퇴직을 택했습니다.
오픈소스 캐시 포크 이야기와는 결이 다릅니다. 발키 글은 라이선스가 갈린 자리입니다. 오픈토푸 글도 라이선스입니다. 여기는 라이선스가 아니라 사람입니다. 쓰는 클러스터는 전 세계인데 고치는 손은 주말 두 명이었습니다. 1인 팀이 차트 기본값을 그대로 둔 이유가 그 인기였습니다. 그 인기가 패치를 약속하진 않았습니다.
한국 1인 팀은 관리형 로드밸런서로 빠지는 편이 낫다
클러스터 안에 엔진엑스 파드를 하나 더 키울 이유가 줄어듭니다. 클라우드가 주는 로드밸런서 컨트롤러를 먼저 봅니다.
저는 12사이트를 버셀과 슈퍼베이스로 돌립니다. 쿠버 인그레스가 매일의 일은 아닙니다. 그래서 더 짧게 말합니다. 주말 온콜이 한 명인 팀은 커뮤니티 컨트롤러를 다시 고르지 않습니다. EKS면 로드밸런서 컨트롤러, 지케면 클라우드의 게이트웨이, 에이케이에스면 앱 라우팅의 다음 칸을 봅니다. 에이더블유에스는 2026년 3월 글로 게이트웨이 API 지원과 이전 순서를 적어 두었습니다.
네이버 클라우드 쿠버 서비스를 쓰는 팀은 콘솔 인그레스 애드온이 커뮤니티 차트인지, 네이버가 이미지를 따로 고치는지부터 확인합니다. 카카오클라우드와 엔에이치엔도 같습니다. 서울 리전 인증서와 디엔에스 호스트만 맞추고 컨트롤러를 클러스터 밖에 두는 편이, 스니펫 번역보다 밤에 덜 깨집니다. 노드 비용 칸은 비용 가이드에 있습니다.
헬름을 병렬로 띄우는 순서
옛 컨트롤러를 먼저 지우지 않습니다. 새 클래스를 옆에 띄우고 호스트를 하나씩 옮깁니다.
운영 가이드의 헬름 습관은 프로덕션 운영에 있습니다. 여기는 컷오버만 적습니다. 스테이징에서 새 컨트롤러를 설치하고, 인그레스 클래스만 다른 복사본을 만듭니다. 디엔에스나 호스트 헤더로 일부를 새 쪽으로 보냅니다. 응답 코드, 리다이렉트, 인증서, 웹소켓이 같으면 다음 호스트를 옮깁니다. 마지막 호스트가 빠진 뒤에야 옛 릴리스를 지웁니다.
프로덕션에서 클래스를 한 번에 바꾸면, 스니펫이 무효가 된 경로가 한꺼번에 404가 됩니다. 저는 그 실수를 스테이징에서 한 번 보고 순서를 고쳤습니다. 깃허브 액션으로 클러스터에 붙는 자리는 액션 오아이디씨와 겹치지 않게, 배포 워크플로와 라우팅 이전을 같은 풀 리퀘스트에 넣지 않습니다.
새 클래스를 옆에 두고 호스트 하나만 먼저 옮긴다
# 새 컨트롤러는 별 릴리스 이름과 별 클래스로 설치
# 차트 값과 버전은 선택한 컨트롤러 공식 문서를 따른다
kubectl get ingressclass
kubectl get ingress -A
# 복사본의 spec.ingressClassName 만 새 클래스로 바꾼 뒤
# 스테이징 호스트 한 개로 응답 코드와 인증서를 비교한다
