쿠버네티스 네트워킹의 종말과 부활: 2026년 3월 이전에 반드시 알아야 할 5가지 변화

  ┌─────────────────────────────────────────────────────────────────┐
  │                    2026년 쿠버네티스 네트워킹 전환 로드맵         │
  ├──────────┬──────────┬──────────┬──────────┬──────────┬──────────┤
  │ 2025.03  │ 2025.11  │ 2026.03  │ 2026.06  │ 2026.11  │ 2027+   │
  │          │          │          │          │          │          │
  │ Ingress  │ 은퇴     │ ■ EOL ■  │ Gateway  │ AKS/GKE  │ Ingress │
  │ Nightmare│ 공식     │ 보안패치 │ API v1.5 │ 연장지원 │ API     │
  │ CVE 발생 │ 발표     │ 완전종료 │ (예상)   │ 종료     │ 잔존    │
  │          │          │          │          │          │ 가능성↓ │
  │ GW API   │ GW API   │          │          │          │          │
  │ v1.2     │ v1.4 GA  │          │          │          │          │
  └──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘
         ▲                    ▲                    ▲
         │                    │                    │
    CVE-2025-1974        커뮤니티 지원          클라우드 벤더
    CVSS 9.8             완전 종료             연장 지원 종료

  ┌─────────────────────────────────────────────────────────┐
  │                  은퇴 범위 명확화                        │
  │                                                         │
  │  ✗ 은퇴 대상:  kubernetes/ingress-nginx 컨트롤러         │
  │               (커뮤니티 유지보수 프로젝트)                │
  │                                                         │
  │  ✓ 유지 대상:  Ingress API (networking.k8s.io/v1)        │
  │               F5 NGINX Ingress Controller (상용)         │
  │               기타 서드파티 Ingress 구현체                │
  │                                                         │
  │  ★ 새 표준:   Gateway API (gateway.networking.k8s.io)    │
  └─────────────────────────────────────────────────────────┘

  공격자 (Pod 네트워크 접근 가능)
       │
       ▼
  ┌──────────────────────────┐
  │  Admission Webhook       │  ← 인증 없이 접근 가능
  │  (8443 포트)             │
  └──────────┬───────────────┘
             │ 악의적 Ingress 객체 전송
             ▼
  ┌──────────────────────────┐
  │  NGINX 설정 주입         │  ← 임의의 NGINX directive 삽입
  │  (CVE-2025-1097/1098/    │
  │   24514 활용)            │
  └──────────┬───────────────┘
             │ 조작된 설정으로 RCE 달성
             ▼
  ┌──────────────────────────┐
  │  컨트롤러 Pod 장악       │  ← CVE-2025-1974
  │  (CVSS 9.8)             │
  └──────────┬───────────────┘
             │ ServiceAccount 토큰 탈취
             ▼
  ┌──────────────────────────┐
  │  전체 클러스터 시크릿    │  ← 모든 네임스페이스의
  │  접근 및 클러스터 탈취   │     Secret 열람 가능
  └──────────────────────────┘

# 이 오타를 발견할 수 있겠습니까?
metadata:
  annotations:
    # 오타: "rewrite-target" → "rewrite-traget"
    nginx.ingress.kubernetes.io/rewrite-traget: /$2
    # 타입 오류: 숫자여야 하지만 문자열 전달
    nginx.ingress.kubernetes.io/proxy-read-timeout: 'sixhundred'
    # 잘못된 prefix: "nginx.ingress.kubernetes.io" → "nginx.kubernetes.io"
    nginx.kubernetes.io/ssl-redirect: 'true'

# ingress-nginx 전용
nginx.ingress.kubernetes.io/canary: 'true'
nginx.ingress.kubernetes.io/canary-weight: '20'

# Traefik 전용
traefik.ingress.kubernetes.io/router.middlewares: default-rate-limit@kubernetescrd

# HAProxy 전용
haproxy.org/rate-limit-requests: '100'

# AWS ALB 전용
alb.ingress.kubernetes.io/target-type: ip

# 위험: 임의의 NGINX 설정 주입 가능
metadata:
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      # 정상적 사용 의도: 커스텀 헤더 추가
      more_set_headers "X-Custom-Header: value";

      # 악의적 활용: 서버 정보 탈취
      # proxy_pass http://internal-service.kube-system.svc.cluster.local;

      # 악의적 활용: 인증 우회
      # satisfy any;
      # allow all;

# Ingress 방식: 어노테이션에 의존
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/proxy-read-timeout: '600'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '600'
    nginx.ingress.kubernetes.io/proxy-body-size: '100m'
    nginx.ingress.kubernetes.io/cors-allow-origin: 'https://example.com'
    nginx.ingress.kubernetes.io/cors-allow-methods: 'GET, POST, PUT'
    nginx.ingress.kubernetes.io/cors-allow-headers: 'Content-Type, Authorization'
    nginx.ingress.kubernetes.io/enable-cors: 'true'
    nginx.ingress.kubernetes.io/limit-rps: '100'
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-weight: '20'
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-service
                port:
                  number: 80

# Gateway API 방식: 구조화된 스펙
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - app.example.com
  rules:
    # 규칙 1: HTTPS 리다이렉트 (어노테이션 없이 스펙으로 표현)
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301
      matches:
        - headers:
            - name: X-Forwarded-Proto
              value: http
    # 규칙 2: API 라우팅
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-service
          port: 80
          weight: 80
        - name: api-service-canary
          port: 80
          weight: 20

# 타임아웃 정책: 별도의 리소스로 관리
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: api-timeout-policy
spec:
  targetRefs:
    - group: ''
      kind: Service
      name: api-service
  sessionPersistence:
    sessionName: my-session
    type: Cookie
---
# TLS 정책: 백엔드 TLS 설정을 별도 리소스로 분리
apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
  name: api-backend-tls
spec:
  targetRefs:
    - group: ''
      kind: Service
      name: api-service
  validation:
    caCertificateRefs:
      - name: backend-ca-cert
        group: ''
        kind: ConfigMap
    hostname: api-internal.example.com

# Ingress: 인프라와 애플리케이션 설정이 혼재
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  # 누가 이 어노테이션을 관리하는가? 인프라팀? 개발팀?
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: 'true' # 인프라 관심사
    nginx.ingress.kubernetes.io/proxy-body-size: '50m' # 인프라 관심사
    nginx.ingress.kubernetes.io/rewrite-target: /$1 # 애플리케이션 관심사
    nginx.ingress.kubernetes.io/canary-weight: '10' # 애플리케이션 관심사
spec:
  ingressClassName: nginx # 인프라 관심사
  tls:
    - hosts:
        - app.example.com
      secretName: production-tls-cert # 인프라 관심사 (시크릿 관리)
  rules:
    - host: app.example.com # 혼합 관심사
      http:
        paths:
          - path: /api/(.*) # 애플리케이션 관심사
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-service # 애플리케이션 관심사
                port:
                  number: 80

  ┌─────────────────────────────────────────────────────────────┐
  │  Layer 1: GatewayClass                                      │
  │  ─────────────────────                                      │
  │  담당: Infrastructure Provider (클라우드 벤더, 플랫폼 팀)    │
  │  역할: 데이터 플레인 구현체 정의                              │
  │  예시: "nginx", "envoy", "gke-l7-global"                    │
  │  RBAC: cluster-admin 수준                                   │
  ├─────────────────────────────────────────────────────────────┤
  │  Layer 2: Gateway                                           │
  │  ─────────────────                                          │
  │  담당: Cluster Operator (플랫폼/인프라 엔지니어)              │
  │  역할: 리스너, TLS, IP 주소, 포트, 허용 네임스페이스 설정     │
  │  예시: 443 포트 HTTPS 리스너, 와일드카드 인증서               │
  │  RBAC: namespace-admin 수준 (인프라 네임스페이스)             │
  ├─────────────────────────────────────────────────────────────┤
  │  Layer 3: HTTPRoute / GRPCRoute / TCPRoute                  │
  │  ───────────────────────────────────────────                 │
  │  담당: Application Developer (서비스 개발자)                  │
  │  역할: 라우팅 규칙, 백엔드 서비스 매핑, 트래픽 가중치         │
  │  예시: /api → api-service, 카나리 20%                       │
  │  RBAC: namespace-editor 수준 (애플리케이션 네임스페이스)      │
  └─────────────────────────────────────────────────────────────┘

# 인프라 제공자가 정의하는 GatewayClass
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gateway-fabric
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller
  parametersRef:
    group: gateway.nginx.org
    kind: NginxProxy
    name: production-proxy-config

# 클러스터 운영자가 관리하는 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: gateway-infra # 인프라 전용 네임스페이스
spec:
  gatewayClassName: nginx-gateway-fabric
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls-cert
            kind: Secret
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: 'true' # 허용된 네임스페이스만
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
---
# 교차 네임스페이스 참조 허용
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-to-app-secrets
  namespace: app-team-a
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: gateway-infra
  to:
    - group: ''
      kind: Service

# 개발자가 자신의 네임스페이스에서 관리하는 HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-routes
  namespace: app-team-a # 애플리케이션 네임스페이스
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-infra # 인프라 네임스페이스의 Gateway 참조
      sectionName: https
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 8080
          weight: 80
        - name: api-v2
          port: 8080
          weight: 20 # 카나리 배포: 20% 트래픽을 v2로

# 개발자용 Role: HTTPRoute만 생성/수정 가능
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: route-editor
  namespace: app-team-a
rules:
  - apiGroups: ['gateway.networking.k8s.io']
    resources: ['httproutes', 'grpcroutes']
    verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
  - apiGroups: ['gateway.networking.k8s.io']
    resources: ['gateways']
    verbs: ['get', 'list'] # Gateway는 조회만 가능
---
# 인프라 운영자용 Role: Gateway 관리 가능, Route 생성 불가
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: gateway-admin
  namespace: gateway-infra
rules:
  - apiGroups: ['gateway.networking.k8s.io']
    resources: ['gateways', 'referencegrants']
    verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
  - apiGroups: ['']
    resources: ['secrets']
    verbs: ['get', 'list', 'watch', 'create', 'update']

  ┌─────────────────────────────────────────────────────────────┐
  │                  Ingress API의 이식성 한계                   │
  │                                                             │
  │  Ingress spec (표준)      어노테이션 (비표준)                 │
  │  ┌───────────────────┐   ┌──────────────────────────────┐   │
  │  │ host: app.com     │   │ nginx.ingress.k8s.io/...     │   │
  │  │ path: /api        │   │ traefik.ingress.k8s.io/...   │   │
  │  │ tls: cert         │   │ alb.ingress.k8s.io/...       │   │
  │  │                   │   │ haproxy.org/...               │   │
  │  │ (이식 가능)        │   │ (이식 불가 - 벤더 종속)        │   │
  │  └───────────────────┘   └──────────────────────────────┘   │
  │         20%                        80%                      │
  │    실제 설정의 20%만이          나머지 80%는 벤더 고유         │
  │    이식 가능                   어노테이션에 의존               │
  └─────────────────────────────────────────────────────────────┘

# 이 HTTPRoute는 어떤 Gateway API 구현체에서든 동일하게 동작합니다
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: portable-route
spec:
  parentRefs:
    - name: my-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix # Core: 경로 매칭
            value: /api
        - headers: # Core: 헤더 매칭
            - name: X-Version
              value: v2
      filters:
        - type: RequestHeaderModifier # Core: 헤더 조작
          requestHeaderModifier:
            add:
              - name: X-Gateway
                value: production
      backendRefs:
        - name: api-service
          port: 8080

# Extended 기능: 대부분의 구현체가 지원하지만 확인 필요
rules:
  - filters:
      - type: RequestRedirect # Extended: HTTP 리다이렉트
        requestRedirect:
          scheme: https
          statusCode: 301
      - type: URLRewrite # Extended: URL 재작성
        urlRewrite:
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /v2
    backendRefs:
      - name: api-v1
        port: 8080
        weight: 90 # Extended: 트래픽 가중치 (카나리)
      - name: api-v2
        port: 8080
        weight: 10

  ┌─────────────────────────────────────────────────────────────┐
  │               Conformance Test 프로세스                      │
  │                                                             │
  │  1. Gateway API 테스트 스위트 실행                            │
  │     └─> 표준 Gateway/HTTPRoute 리소스 배포                    │
  │                                                             │
  │  2. 실제 트래픽 전송 및 동작 검증                              │
  │     └─> 경로 매칭, 헤더 필터링, 리다이렉트 등                  │
  │                                                             │
  │  3. 결과 리포트 생성                                         │
  │     └─> Core 100%, Extended features 목록                   │
  │                                                             │
  │  4. 공식 인증 (Conformance Profile)                          │
  │     └─> Gateway API 공식 구현체 목록 등재                     │
  └─────────────────────────────────────────────────────────────┘

  ┌──────────────────┐     ┌──────────────────┐
  │   AWS EKS        │     │   Azure AKS      │
  │                  │     │                  │
  │  GatewayClass:   │     │  GatewayClass:   │
  │  aws-gateway     │     │  azure-gateway   │
  │  (구현체 변경)    │     │  (구현체 변경)    │
  │                  │     │                  │
  │  Gateway: ───────┼─────┼─ Gateway: ──────┐│
  │  (최소 수정)      │     │  (최소 수정)     ││
  │                  │     │                  ││
  │  HTTPRoute: ─────┼─────┼─ HTTPRoute: ────┘│
  │  (동일 재사용)    │     │  (동일 재사용)    │
  └──────────────────┘     └──────────────────┘
           │                        │
           └───────┬────────────────┘
                   │
        동일한 HTTPRoute 매니페스트를
        GatewayClass만 변경하여 재사용

  HTTP/2 over TCP의 Head-of-Line Blocking 문제:

  TCP 연결
  ┌─────────────────────────────────────────────────┐
  │  Stream 1: [패킷1][패킷2][  손실  ][패킷4]      │
  │  Stream 2: [패킷A][패킷B]  ← 대기   [패킷D]     │  ← 블로킹!
  │  Stream 3: [패킷X][패킷Y]  ← 대기   [패킷Z]     │  ← 블로킹!
  └─────────────────────────────────────────────────┘
               패킷3 손실 시 → 모든 스트림이 대기

  HTTP/3 over QUIC의 독립 스트림:

  QUIC 연결
  ┌─────────────────────────────────────────────────┐
  │  Stream 1: [패킷1][패킷2][  손실  ][패킷4]      │  ← 이 스트림만 영향
  │  Stream 2: [패킷A][패킷B][패킷C]   [패킷D]      │  ← 정상 진행!
  │  Stream 3: [패킷X][패킷Y][패킷Z]               │  ← 정상 진행!
  └─────────────────────────────────────────────────┘
               패킷3 손실 시 → Stream 1만 영향

apiVersion: gateway.nginx.org/v1alpha1
kind: NginxProxy
metadata:
  name: http3-enabled-proxy
spec:
  config:
    http:
      http3: true
      http3MaxConcurrentStreams: 128
      altSvcHeader: true # Alt-Svc 헤더 자동 추가

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: http3-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: nginx-gateway-fabric
  listeners:
    # HTTPS (TCP) + HTTP/3 (UDP) 동시 리스닝
    - name: https-tcp
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls-cert
    - name: https-udp
      protocol: HTTPS # HTTP/3는 HTTPS 프로토콜로 선언
      port: 443 # 동일 포트, UDP로 QUIC 처리
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls-cert

apiVersion: v1
kind: Service
metadata:
  name: nginx-gateway-fabric
  namespace: gateway-infra
spec:
  type: LoadBalancer
  ports:
    - name: https-tcp
      port: 443
      targetPort: 443
      protocol: TCP
    - name: https-udp
      port: 443
      targetPort: 443
      protocol: UDP # QUIC을 위한 UDP 포트 필수

  ┌─────────────────────────────────────────────────────────┐
  │              HTTP/3 네트워크 요구사항                     │
  │                                                         │
  │  인바운드 규칙에 UDP 443 추가 필수:                       │
  │                                                         │
  │  기존 (HTTP/2만):                                       │
  │  ┌──────────────────────────────────────┐               │
  │  │ TCP 80   ← HTTP                     │               │
  │  │ TCP 443  ← HTTPS (TLS over TCP)     │               │
  │  └──────────────────────────────────────┘               │
  │                                                         │
  │  HTTP/3 추가 후:                                        │
  │  ┌──────────────────────────────────────┐               │
  │  │ TCP 80   ← HTTP                     │               │
  │  │ TCP 443  ← HTTPS (TLS over TCP)     │               │
  │  │ UDP 443  ← QUIC (HTTP/3 over UDP)   │  ← 추가 필수  │
  │  └──────────────────────────────────────┘               │
  │                                                         │
  │  주의: 많은 기업 방화벽과 클라우드 보안 그룹이             │
  │  UDP 443을 기본적으로 차단합니다.                         │
  └─────────────────────────────────────────────────────────┘

Alt-Svc: h3=":443"; ma=86400

# nginx.conf에서 eBPF 기반 QUIC 라우팅 활성화
quic_bpf on;  # Linux 5.7+ 필수

  ┌──────────────────────────────────────────────────────────────┐
  │              단계적 마이그레이션 전략                          │
  │                                                              │
  │  Phase 1: 인벤토리 및 평가 (1~2주)                           │
  │  ├─ 전체 Ingress 리소스 목록화                                │
  │  ├─ 사용 중인 어노테이션 분류                                  │
  │  ├─ snippets 사용 여부 파악 (보안 위험 우선 제거)              │
  │  └─ 의존성 매핑 (cert-manager, external-dns 등)               │
  │                                                              │
  │  Phase 2: Gateway API 인프라 구축 (1~2주)                    │
  │  ├─ Gateway API CRD 설치                                     │
  │  ├─ NGINX Gateway Fabric 또는 대안 컨트롤러 배포              │
  │  ├─ GatewayClass, Gateway 리소스 생성                        │
  │  └─ 비프로덕션 환경에서 검증                                   │
  │                                                              │
  │  Phase 3: 점진적 라우팅 전환 (2~4주)                          │
  │  ├─ ingress2gateway 도구로 초기 변환                          │
  │  ├─ 수동 검토 및 어노테이션 → 필터/정책 변환                   │
  │  ├─ 서비스별 순차 전환 (비핵심 → 핵심 서비스)                  │
  │  └─ 병렬 운영(Ingress + Gateway API) 기간                    │
  │                                                              │
  │  Phase 4: 완전 전환 및 정리 (1~2주)                          │
  │  ├─ 모든 트래픽이 Gateway API 경유 확인                       │
  │  ├─ Ingress 리소스 제거                                      │
  │  ├─ ingress-nginx 컨트롤러 제거                               │
  │  └─ 모니터링 및 알림 재설정                                    │
  └──────────────────────────────────────────────────────────────┘

# 모든 네임스페이스의 Ingress 리소스 목록
kubectl get ingress -A -o wide

# 사용 중인 어노테이션 전체 추출
kubectl get ingress -A -o json | \
  jq -r '.items[].metadata.annotations // {} | keys[]' | \
  sort | uniq -c | sort -rn

# snippets 어노테이션 사용 여부 긴급 확인 (보안 위험)
kubectl get ingress -A -o json | \
  jq -r '.items[] | select(.metadata.annotations["nginx.ingress.kubernetes.io/configuration-snippet"] != null or .metadata.annotations["nginx.ingress.kubernetes.io/server-snippet"] != null) | .metadata.namespace + "/" + .metadata.name'

# IngressClass 확인
kubectl get ingressclass

# Go 환경이 있는 경우
go install github.com/kubernetes-sigs/ingress2gateway@latest

# 또는 GitHub Releases에서 바이너리 다운로드
# https://github.com/kubernetes-sigs/ingress2gateway/releases

# 클러스터의 Ingress 리소스를 자동 변환
ingress2gateway print --all-namespaces

# 특정 네임스페이스만 변환
ingress2gateway print --namespace production

# 파일 기반 변환
ingress2gateway print --input-file ingress-resources.yaml

# ingress-nginx 프로바이더 지정 (어노테이션 변환 지원)
ingress2gateway print --providers ingress-nginx --all-namespaces

# 결과를 파일로 저장
ingress2gateway print --providers ingress-nginx --all-namespaces > gateway-resources.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-app
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-service
                port:
                  number: 80

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx
  namespace: production
spec:
  gatewayClassName: nginx
  listeners:
    - name: app-example-com-https
      hostname: app.example.com
      port: 443
      protocol: HTTPS
      tls:
        certificateRefs:
          - name: app-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-app
  namespace: production
spec:
  parentRefs:
    - name: nginx
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-service
          port: 80

# Gateway API CRD 설치
kubectl kustomize \
  "https://github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.2.1" \
  | kubectl apply -f -

# NGINX Gateway Fabric 설치
helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace \
  --namespace nginx-gateway \
  --set service.type=LoadBalancer

# 설치 후 GatewayClass 확인
kubectl get gatewayclass
# NAME            CONTROLLER                                    ACCEPTED
# nginx           gateway.nginx.org/nginx-gateway-controller     True

# Gateway 리소스 적용
kubectl apply -f gateway.yaml

# Gateway 상태 확인
kubectl get gateway -n gateway-infra
# NAME                  CLASS   ADDRESS         PROGRAMMED   AGE
# production-gateway    nginx   203.0.113.10    True         5m

# HTTPRoute 적용
kubectl apply -f httproute.yaml

# HTTPRoute 상태 확인
kubectl get httproute -n app-team-a
# NAME          HOSTNAMES           AGE
# api-routes    ["api.example.com"] 2m

# 실제 트래픽 테스트
curl -H "Host: api.example.com" https://203.0.113.10/v1/health

# 지금 바로 실행하세요
kubectl get ingress -A -o json | \
  jq -r '[.items[] | {
    namespace: .metadata.namespace,
    name: .metadata.name,
    annotations: (.metadata.annotations // {} | keys | length),
    has_snippets: ((.metadata.annotations // {}) |
      has("nginx.ingress.kubernetes.io/configuration-snippet") or
      has("nginx.ingress.kubernetes.io/server-snippet"))
  }]'

go install github.com/kubernetes-sigs/ingress2gateway@latest
ingress2gateway print --providers ingress-nginx -A > gateway-migration.yaml

# 비프로덕션 클러스터에서 테스트
kubectl kustomize \
  "https://github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.2.1" \
  | kubectl apply -f -

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace --namespace nginx-gateway