쿠버네티스 네트워크 대전환 재설계: Ingress의 끝, Gateway API의 시작

2026 “쿠버네티스 표준 아키텍처”

핵심은 단순히 “툴을 바꾼다”가 아니라, 클러스터 네트워킹의 ‘구성 방식(모델)’이 바뀌는 것입니다.

변화의 촉발점: Ingress NGINX 은퇴(EOL)

쿠버네티스 SIG Network/SRC는 Ingress NGINX 프로젝트가 2026년 3월에 유지보수 중단/은퇴하며, 이후에는 릴리스/버그픽스/보안패치가 더 이상 제공되지 않는다고 공지했습니다. 즉, “지금은 동작해도” 2026-03 이후는 보안 취약점이 떠도 고칠 수 없는 상태가 됩니다.

➡️ 그래서 2026의 네트워크 표준 이야기는 사실상
“Ingress 단일 API 중심에서 → Gateway API 중심으로”의 전환 이야기입니다.

Ingress 시대의 구조(구 방식)와 한계

Ingress 모델(구 방식) 요약

Ingress 리소스 하나로 Host/Path 라우팅을 정의
“실제 프록시/게이트웨이”는 Ingress Controller(NGINX/HAProxy/Traefik/Kong 등)가 구현
확장 기능(인증/레이트리밋/WAF/헤더변환 등)은 컨트롤러별 Annotation(주석) 또는 CRD로 붙이기 시작

Ingress의 대표 YAML(구 방식 예시)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    # 컨트롤러별로 달라지는 확장(이식성이 낮음)
    konghq.com/strip-path: "false"
spec:
  ingressClassName: kong
  rules:
  - host: web.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

Ingress의 구조적 한계(2026 전환의 본질)

Ingress는 “간단한 웹 라우팅”에 최적화되어 있어서, 다음 요구가 커질수록 불편해집니다.

역할 분리(거버넌스): 플랫폼팀(인프라)과 서비스팀(앱)이 서로 다른 책임을 져야 하는데, Ingress는 그 경계가 애매함
프로토콜 확장: HTTP/HTTPS 말고 TCP/UDP/TLS 같은 L4도 “표준 방식”으로 다루기 어려움
표준 확장 방식 부재: 인증/정책/필터가 사실상 컨트롤러별 어노테이션 난립
크로스 네임스페이스 보안 모델이 부족

이 문제를 해결하는 방향이 Gateway API입니다.

Gateway API 시대(새 방식): 네트워크 모델이 어떻게 바뀌나

Kubernetes 공식 문서는 Gateway API를 “동적 인프라 프로비저닝 + 고급 트래픽 라우팅을 제공하는 API 패밀리”이며, 확장 가능하고, 역할 지향(role-oriented), 프로토콜 인지(protocol-aware) 모델이라고 정의합니다.

핵심 변화 1: “역할 분리(거버넌스)”가 기본 설계로 들어옴

Gateway API는 리소스를 분리해서 조직 운영 구조를 그대로 담기 좋습니다.

GatewayClass: “이 클러스터에서 어떤 게이트웨이 구현체를 쓸 건지” (예: kong, gke, istio 등)
Gateway: 실제 진입점(LoadBalancer/NodePort/주소/리스너/인증서 등)
Route(HTTPRoute/TCPRoute/UDPRoute/TLSRoute 등): 서비스팀이 작성하는 라우팅 정의

➡️ 플랫폼팀은 GatewayClass/Gateway를 관리하고,
서비스팀은 자기 네임스페이스에서 HTTPRoute만 관리하는 구조가 자연스럽습니다.

핵심 변화 2: “프로토콜 확장”이 표준으로 들어옴

Kong 문서도 Gateway API가 Ingress를 확장해 HTTP/HTTPS뿐 아니라 TCP/UDP/TLS 라우트까지 다룰 수 있다고 설명합니다. (Kong Docs)

핵심 변화 3: 크로스 네임스페이스 참조를 ‘허용 기반’으로 통제

Gateway API는 기본적으로 다른 네임스페이스 리소스를 함부로 참조하지 못하게 하고, 필요하면 ReferenceGrant로 명시적 허용을 하게 합니다. (gateway-api.sigs.k8s.io)

➡️ 이게 보안/거버넌스에서 엄청 큽니다.
“서비스팀 A가 플랫폼팀 네임스페이스의 백엔드를 마음대로 물지 못하게” 기본적으로 막아줍니다.

Gateway API를 “실제로” 쓰는 구조: Kong(KIC) 예시 설명

Kong 공식 문서는 KIC를 이렇게 정의합니다.

KIC는 Kubernetes 리소스(Ingress, HTTPRoute)를 읽어서
이를 Kong Gateway 설정으로 변환한다.

또한 Kong 문서의 Gateway API 페이지는

Gateway API는 Ingress를 확장하며
KIC가 Gateway API CRD가 설치된 경우에만 Gateway API 리소스를 reconcile한다고 명시합니다.

(전제) Gateway API CRD 설치

Gateway API는 “쿠버네티스 기본 내장”이 아니라 CRD를 설치해야 합니다.

300x250

예시(표준 CRD 설치)

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml

(설치 방식 자체는 Gateway API 공식 배포물 기준입니다.)

Kong Gateway API 구성 흐름(정석)

아래는 “플랫폼팀/서비스팀 분리”까지 고려한 실전형 템플릿입니다.

플랫폼팀: GatewayClass 선택 (클러스터 구현체 지정)

GatewayClass는 “이 클러스터에서 어떤 게이트웨이 컨트롤러가 처리할 건가”를 나타내는 최상위 선택입니다.

예시(개념)

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: kong
spec:
  controllerName: konghq.com/kic-gateway-controller

플랫폼팀: Gateway 생성 (실제 진입점)

Gateway는 “리스너(포트/프로토콜/호스트/TLS) + 어디에 붙는지(LB 등)”를 담습니다.

예시

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge-gw
  namespace: gateway-system
spec:
  gatewayClassName: kong
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "api.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: api-cert

서비스팀: HTTPRoute 생성 (라우팅 정의)

HTTPRoute는 부모(ParentRefs)로 어떤 Gateway에 붙을지 지정하고, host/path 매칭과 backendRefs를 둡니다.

예시

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: team-a
spec:
  parentRefs:
  - name: edge-gw
    namespace: gateway-system
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: api-svc
      port: 80

여기서 “Ingress 시대”와 비교하면 차이가 명확합니다.

Ingress는 “한 리소스에 다 때려 넣기”
Gateway API는 “Gateway(진입점)와 Route(라우팅)”를 분리해 운영 책임을 분리합니다.

크로스 네임스페이스 보안: ReferenceGrant로 ‘명시적 허용’

예를 들어 team-a의 HTTPRoute가 gateway-system의 어떤 리소스를 참조하려면, ReferenceGrant로 허용해주는 패턴이 등장합니다.

공식 문서 예시 흐름(개념)

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-team-a
  namespace: gateway-system
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: team-a
  to:
  - group: ""
    kind: Secret

(ReferenceGrant는 “누가(from)가 무엇(to)을 참조할 수 있는지”를 명시적으로 선언하는 모델입니다.)

보안적으로 중요한 이유

Ingress 시대에는 TLS Secret/Backend 참조가 팀/네임스페이스 경계를 어기며 난잡해지기 쉬웠는데,
Gateway API는 기본적으로 막고, 필요하면 허용 기반(allow-list)으로 열게 합니다.

Kong(KIC)의 “정책 엔진” 활용: 플러그인으로 네트워크 정책을 표준화

KIC 문서(개요)는 KIC가 Ingress/HTTPRoute를 Kong Gateway 설정으로 변환한다고 설명합니다.
그리고 Kong 생태계의 강점은 “플러그인(정책)”입니다.

레이트리밋(예시): 네트워크 레벨에서 API 보호

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rl-10rps
plugin: rate-limiting
config:
  second: 10
  policy: local

서비스/라우트에 붙이기(예시)

apiVersion: v1
kind: Service
metadata:
  name: api-svc
  namespace: team-a
  annotations:
    konghq.com/plugins: rl-10rps
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080

➡️ 효과

앱 수정 없이 “Ingress/Gateway 레이어”에서 API 남용을 차단
조직 공통 정책(예: 기본 10rps, 특정 경로는 더 낮게)을 표준화 가능

Path 처리(예시): strip-path 같은 “장애 원인 1순위”를 표준 규칙으로

Kong은 strip-path를 동작 옵션으로 제공하고(켜고 끌 수 있음), 이는 Ingress 시절에도 트러블이 많은 지점입니다. (KIC에서 동작 옵션을 제공)
→ 조직 표준으로 “외부 URL과 내부 URL 매핑 규칙”을 정하고, 리뷰 포인트로 고정하는 게 중요합니다.

2026 네트워크 표준 운영 가이드(실무형)

“Ingress → Gateway API” 전환을 실패하지 않는 방법

단계 1: 공존 설계

기존 Ingress는 유지
신규 서비스는 HTTPRoute로 먼저 전개
Gateway는 단일 진입점으로 먼저 표준화

단계 2: 정책 표준화

레이트리밋/인증/헤더/로그를 Kong 플러그인으로 “표준 패키지”화
팀이 임의로 annotation을 난사하지 못하도록 가이드/템플릿 제공

단계 3: 거버넌스 강화

ReferenceGrant로 cross-namespace 참조를 엄격 관리
Gateway는 플랫폼팀만 변경, HTTPRoute는 서비스팀이 변경(승인 체계)

보안관리 관점 점검 포인트

EOL 리스크: Ingress NGINX를 2026-03 이후 계속 쓰는 구간은 “취약점 패치 불가” 구간
Gateway API 거버넌스: Gateway(진입점)와 Route(라우팅) 책임 분리, ReferenceGrant로 네임스페이스 경계 통제
정책 부착 위치 표준화
- 공통 보안 정책(기본 레이트리밋/기본 헤더)은 Gateway/Route 레벨
- 서비스별 예외는 HTTPRoute 레벨
- 민감 인증키/시크릿은 “플러그인에 직접 박지 않는” 원칙(별도 Secret/Vault 전략 필요)

2026 네트워크 관점 결론

2026 변화의 핵심은 Ingress 컨트롤러 교체가 아니라 Ingress 모델 → Gateway API 모델로의 전환입니다.
Gateway API는 역할 분리(거버넌스) + 프로토콜 확장 + 허용 기반 크로스네임스페이스 보안(ReferenceGrant)을 기본으로 제공합니다.
Kong(KIC)은 Ingress/HTTPRoute를 모두 처리하며, Gateway API 사용을 공식 문서로 지원합니다.

완성형 템플릿 세트

아래 3종을 운영 기준(온프렘/클라우드, 멀티팀, 도메인, 인증서, 로그/SIEM 연계)에 맞춰볼 수 있습니다.

Kong + Gateway API 표준 템플릿(GatewayClass/Gateway/HTTPRoute/ReferenceGrant)
Ingress NGINX → Kong/Gateway API 마이그레이션 플랜(단계/검증/롤백)
보안 점검표(RBAC, Secret/Vault, Admin API 격리, 로그/감사, 정책 부착 규칙)

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

pages.kr 날으는물고기 <º)))><

쿠버네티스 네트워크 대전환 재설계: Ingress의 끝, Gateway API의 시작

쿠버네티스 네트워크 대전환 재설계: Ingress의 끝, Gateway API의 시작

2026 “쿠버네티스 표준 아키텍처”

변화의 촉발점: Ingress NGINX 은퇴(EOL)

Ingress 시대의 구조(구 방식)와 한계

Ingress 모델(구 방식) 요약

Ingress의 대표 YAML(구 방식 예시)

Ingress의 구조적 한계(2026 전환의 본질)

Gateway API 시대(새 방식): 네트워크 모델이 어떻게 바뀌나

핵심 변화 1: “역할 분리(거버넌스)”가 기본 설계로 들어옴

핵심 변화 2: “프로토콜 확장”이 표준으로 들어옴

핵심 변화 3: 크로스 네임스페이스 참조를 ‘허용 기반’으로 통제

Gateway API를 “실제로” 쓰는 구조: Kong(KIC) 예시 설명

(전제) Gateway API CRD 설치

Kong Gateway API 구성 흐름(정석)

플랫폼팀: GatewayClass 선택 (클러스터 구현체 지정)

플랫폼팀: Gateway 생성 (실제 진입점)

서비스팀: HTTPRoute 생성 (라우팅 정의)

크로스 네임스페이스 보안: ReferenceGrant로 ‘명시적 허용’

Kong(KIC)의 “정책 엔진” 활용: 플러그인으로 네트워크 정책을 표준화

레이트리밋(예시): 네트워크 레벨에서 API 보호

Path 처리(예시): strip-path 같은 “장애 원인 1순위”를 표준 규칙으로

2026 네트워크 표준 운영 가이드(실무형)

“Ingress → Gateway API” 전환을 실패하지 않는 방법

보안관리 관점 점검 포인트

2026 네트워크 관점 결론

완성형 템플릿 세트

댓글

티스토리툴바

쿠버네티스 네트워크 대전환 재설계: Ingress의 끝, Gateway API의 시작

쿠버네티스 네트워크 대전환 재설계: Ingress의 끝, Gateway API의 시작

2026 “쿠버네티스 표준 아키텍처”

변화의 촉발점: Ingress NGINX 은퇴(EOL)

Ingress 시대의 구조(구 방식)와 한계

Ingress 모델(구 방식) 요약

Ingress의 대표 YAML(구 방식 예시)

Ingress의 구조적 한계(2026 전환의 본질)

Gateway API 시대(새 방식): 네트워크 모델이 어떻게 바뀌나

핵심 변화 1: “역할 분리(거버넌스)”가 기본 설계로 들어옴

핵심 변화 2: “프로토콜 확장”이 표준으로 들어옴

핵심 변화 3: 크로스 네임스페이스 참조를 ‘허용 기반’으로 통제

Gateway API를 “실제로” 쓰는 구조: Kong(KIC) 예시 설명

(전제) Gateway API CRD 설치

Kong Gateway API 구성 흐름(정석)

플랫폼팀: GatewayClass 선택 (클러스터 구현체 지정)

플랫폼팀: Gateway 생성 (실제 진입점)

서비스팀: HTTPRoute 생성 (라우팅 정의)

크로스 네임스페이스 보안: ReferenceGrant로 ‘명시적 허용’

Kong(KIC)의 “정책 엔진” 활용: 플러그인으로 네트워크 정책을 표준화

레이트리밋(예시): 네트워크 레벨에서 API 보호

Path 처리(예시): strip-path 같은 “장애 원인 1순위”를 표준 규칙으로

2026 네트워크 표준 운영 가이드(실무형)

“Ingress → Gateway API” 전환을 실패하지 않는 방법

보안관리 관점 점검 포인트

2026 네트워크 관점 결론

완성형 템플릿 세트

관련글

댓글

티스토리툴바