Kubernetes Gateway API vs Ingress vs LoadBalancer: 2026년에 무엇을 사용해야 할까

Source: Dev.to

저는 팀들이 “그냥 어노테이션 하나 추가한다”는 식으로 실수로 인그레스 컨트롤러를 아무도 관리하지 않는 프로덕션 API로 바꾸는 모습을 보았습니다.

2026년에 Service type LoadBalancer, Ingress, 그리고 Gateway API 중에서 선택한다면, 실제로는 누가 트래픽 규칙을 변경할 수 있는지, 얼마나 안전하게 할 수 있는지, 그리고 새벽 2시에 롤백이 얼마나 끔찍하게 느껴지는지를 선택하는 것입니다.

블런트 2026 규칙: 레이어를 먼저 선택하라

대부분의 논쟁은 L7에서 발생하지만, 잘못된 공유 객체를 변경했을 때 L4에서 시작되는 장애도 많이 있습니다.

• 원시 TCP/UDP 노출: Service type LoadBalancer를 사용하세요. 지루한 L4 배관이며, 움직이는 부품이 가장 적습니다.
• 한 팀의 클러스터에서 HTTP(S) 라우팅: 조직 내에서 컨트롤러와 어노테이션이 이미 안정적인 제품처럼 동작한다면 Ingress를 유지하세요.
• 팀 및 네임스페이스 간에 하나의 엣지를 공유: Gateway API를 사용하세요. “플랫폼이 Gateway를 소유하고, 애플리케이션 팀이 Routes를 소유한다”는 내장된 분할 방식을 제공합니다.

의사결정 트리 (실제로 사용할 수 있는 버전)

우리가 “Ingress 표준화”를 시도했을 때 큰 골칫거리가 생겼습니다. 서로 다른 주석 방언이 여섯 가지나 생겨났고, 타임아웃을 건드릴 때마다 일주일 동안 추측과 검증을 반복했습니다.

Requirements Checklist

하나 이상의 제약 조건에 부딪히면 마이그레이션을 진행하세요. 그렇지 않으면 되돌릴 수 없는 작업에 얽히게 됩니다.

Multi‑tenant Routing and Cross‑namespace Delegation

플랫폼이 엣지를 소유하고 앱 팀이 라우트를 소유한다면 Ingress는 끊임없는 협상이 됩니다. 하나의 거대한 공유 Ingress는 병합 충돌과 공유 블라스트 반경을 초래합니다.

Gateway API는 소유권 분리를 내장합니다: 플랫폼은 Gateway를, 앱 팀은 HTTPRoute를 소유합니다. 리스너는 어떤 네임스페이스가 라우트를 연결할 수 있는지 제어합니다.

Policy Attachment

Ingress는 처음에 얇게 시작했지만 실제 동작은 컨트롤러 어노테이션과 별도 CRD로 이동했습니다. 그래서 “Kubernetes‑y”한 YAML이 나오지만 특정 컨트롤러에서만 동작하게 됩니다.

Gateway API는 정책 부착을 모델에 포함시키지만, 여전히 거버넌스가 필요합니다. 그렇지 않으면 팀이 새로운 구현‑특정 정책 객체를 사용해 어노테이션 스프레드를 다시 만들게 됩니다.

TLS/SNI and Certificate Ownership

인증서 소유권이 정치적인 문제로 변한 사례를 본 적이 있습니다. Ingress는 종종 “시크릿을 앱 네임스페이스에 복사한다”거나 “모두를 중앙화하고 팀을 차단한다”는 선택을 강요합니다.

Gateway listeners는 플랫폼이 인증서 참조를 소유하도록 하고, 팀은 호스트명으로 라우트를 연결할 수 있게 합니다.

Typed Routing

HTTPRoute, GRPCRoute, TCPRoute, TLSRoute, UDPRoute. gRPC를 진지하게 운영한다면 “Ingress가 gRPC를 지원한다”는 보통 “컨트롤러에 관례가 있다”는 의미입니다. Gateway API는 타입별 Route로 라우팅 의도를 명시하지만, 컨트롤러 지원 정도는 다양합니다.

Compatibility Reality Check

GitHub 커밋 수에 신경 쓰지 마세요. 중요한 것은 선택한 컨트롤러, 클라우드 로드밸런서, 보안 규칙이 여러분이 의존하려는 기능을 지원하는지 여부입니다.

• Service (LoadBalancer) portability: 중간 수준. API는 안정적이지만 클라우드‑특정 어노테이션은 다릅니다.
• Ingress portability: 낮음에서 중간 수준. 프로덕션 기능은 컨트롤러‑특정 어노테이션에 존재합니다.
• Gateway API portability: 컨트롤러가 적합성 테스트에서 입증한 범위 내에서는 중간에서 높음 수준.

프로덕션에서도 살아남는 마이그레이션 (Ingress → Gateway API)

Do not “big‑bang” this. I’ve seen that movie and it ends with a rollback and a post‑mortem full of screenshots.
한 번에 진행하지 마세요. 그런 경우를 본 적이 있는데, 결국 롤백과 스크린샷이 가득한 사후 분석으로 끝났습니다.

Phase 0 – 실제로 사용하고 있는 것 파악

1. Export every Ingress.
   모든 Ingress를 내보냅니다.
2. List every annotation in use.
   사용 중인 모든 어노테이션을 나열합니다.
3. Group by controller.
   컨트롤러별로 그룹화합니다.
4. Capture baseline signals: 4xx/5xx rates, p95 latency, TLS handshake errors, upstream resets.
   기본 신호를 캡처합니다: 4xx/5xx 비율, p95 지연시간, TLS 핸드쉐이크 오류, 업스트림 리셋.

Phase 1 – 컨트롤러 선택 및 지원 검증

Gateway API is a spec. Your controller determines how it behaves, how it fails, and what “supported” means. Validate conformance level, the exact features you need, and how it maps to your cloud load balancer model.
Gateway API는 사양(spec)입니다. 컨트롤러가 동작 방식, 실패 방식, 그리고 “지원”이 무엇을 의미하는지를 결정합니다. 적합성 수준, 필요한 정확한 기능, 그리고 클라우드 로드밸런서 모델과의 매핑을 검증하세요.

Phase 2 – Ingress와 함께 Gateway 실행

Most clusters can run both at once. Use separate namespaces, separate external addresses, and explicit class selection. Keep the old Ingress path alive until dashboards show equivalence under real load.
대부분의 클러스터는 두 가지를 동시에 실행할 수 있습니다. 별도의 네임스페이스, 별도의 외부 주소, 명시적인 클래스 선택을 사용하세요. 실제 부하 하에서 대시보드가 동등성을 보여줄 때까지 기존 Ingress 경로를 유지합니다.

Phase 3 – 하나의 플랫폼 Gateway, 그 다음 하나의 서비스 마이그레이션

I prefer one shared Gateway owned by the platform team, at least at the start. App teams attach HTTPRoutes from their namespaces with explicit hostname ownership.
시작 단계에서는 플랫폼 팀이 소유하는 공유 Gateway 하나를 선호합니다. 애플리케이션 팀은 자신의 네임스페이스에서 명시적인 호스트네임 소유권을 가진 HTTPRoutes를 연결합니다.

• 플랫폼 소유 Gateway: Listener on 443, hostname wildcard you actually own, allowedRoutes restricted by namespace selector.
  • 플랫폼 소유 Gateway: 443 포트 리스너, 실제로 소유한 호스트네임 와일드카드, 네임스페이스 셀렉터로 제한된 allowedRoutes.
• 앱 소유 HTTPRoute: Hostname, path matches, backendRefs with weights for controlled cut‑over testing.
  • 앱 소유 HTTPRoute: 호스트네임, 경로 매치, 가중치를 가진 backendRefs를 사용해 제어된 전환 테스트를 수행합니다.

Phase 4 – DNS 또는 가중치로 트래픽 전환

DNS cut‑over stays low‑drama if you manage TTLs and have a rollback plan. Keep the old path ready. Roll back the moment error budgets start burning.
TTL을 관리하고 롤백 계획을 마련한다면 DNS 전환은 큰 이슈 없이 진행됩니다. 기존 경로를 준비해 두세요. 에러 예산이 소진되기 시작하면 즉시 롤백합니다.

I don’t trust “known issues: none” from any project. Build your own checks and pick a rollback trigger before you start.
나는 어떤 프로젝트에서도 “알려진 이슈: 없음”이라는 말을 믿지 않습니다. 직접 체크를 만들고 시작하기 전에 롤백 트리거를 선택하세요.

Phase 5 – 어노테이션을 정책으로 변환

This is where migrations fail. Teams copy every annotation into a controller‑specific policy CRD and then nobody can reason about behavior.
여기가 마이그레이션이 실패하는 지점입니다. 팀이 모든 어노테이션을 컨트롤러 전용 정책 CRD에 복사하면, 아무도 동작을 이해할 수 없게 됩니다.

Decide which policies platform owns (timeouts, max body size, TLS settings, etc.) and which teams can override. Consolidate them into Gateway API‑native policy resources (e.g., GatewayClass, ReferenceGrant, Policy CRDs) instead of scattering controller‑specific annotations.
플랫폼이 소유할 정책(타임아웃, 최대 본문 크기, TLS 설정 등)과 팀이 오버라이드할 수 있는 정책을 결정하세요. 컨트롤러 전용 어노테이션을 흩뿌리는 대신 Gateway API 네이티브 정책 리소스(예: GatewayClass, ReferenceGrant, Policy CRD)로 통합합니다.

TL;DR

• LoadBalancer → raw L4, 단일 IP 격리.
• Ingress → simple L7, 하지만 어노테이션 남발 및 소유권 분쟁.
• Gateway API → 플랫폼과 앱 책임을 명확히 분리하고, 타입이 지정된 라우트와 미래에도 견딜 수 있는 트래픽 관리 경로—적합한 컨트롤러를 선택하고 정책을 중앙에서 관리한다면.

Happy routing! 🚀

Production Pitfalls (The 2 am List)

• Annotation sprawl returns: 작고 지원되는 정책 집합을 설정하고 임의의 회피 경로를 차단하십시오.
• Delegation foot‑guns: 호스트명 충돌을 방지하고 인증서 비밀 참조를 잠그세요.
• Catch‑all behavior surprises: 오래된 Ingress 기본 백엔드는 종종 손상된 호스트명을 숨깁니다.
• Traffic splitting under load: 재시도와 HTTP/2 멀티플렉싱이 “가중치”를 왜곡할 수 있습니다.
• Upgrades magnify instability: 새로운 컨트롤러로 엣지 트래픽을 옮기기 전에 노드 변동을 해결하세요.

핵심 요약

• Service 타입 LoadBalancer 사용: 최소한의 추상화로 L4 노출이 필요할 때.
• Ingress 사용: HTTP 라우팅이 기본 수준이고, 어노테이션 세트가 이미 관리된 표준처럼 동작할 때.
• Gateway API 사용: 다팀 위임, 타입이 지정된 라우트(gRPC 포함), 정책 연결이 필요하고 어노테이션을 실제 API로 전환하지 않을 때.

FAQ

2026년에 Ingress에서 Gateway API로 마이그레이션해야 할까요?
새로 시작한다면, 반드시 Gateway API를 사용하세요. 이미 작동 중인 Ingress 설정이 있다면, 구체적인 제한에 직면했을 때만 마이그레이션하십시오.

Ingress와 Gateway API를 동시에 실행할 수 있나요?
네 — 이것이 권장되는 마이그레이션 방법입니다. 대부분의 컨트롤러가 두 API를 동시에 지원합니다.

Gateway API와 서비스 메시는 어떻게 다른가요?
Gateway API는 북‑남 트래픽(외부 → 클러스터)을 처리합니다. 서비스 메시는 동‑서 트래픽(서비스‑간)을 처리합니다. 두 기술은 서로 보완합니다.

관련 읽을거리

• Kubernetes 1.32 종료: 마이그레이션 플레이북
• 인기 있는 Kubernetes 배포판 비교 (2026)
• 프로덕션 환경에서 Docker vs Kubernetes (2026)
• Kubernetes 지원 및 종료 정책

원본은 ReleaseRun에 게시되었습니다.