Gateway API 1.4: 새로운 기능

쿠버네티스 네트워킹을 강화할 준비가 되셨나요? 쿠버네티스 SIG Network 커뮤니티가 Gateway API(v1.4.0)의 General Availability(GA) 릴리스를 발표했습니다! 2025년 10월 6일에 출시된 v1.4.0은 쿠버네티스에서 현대적이고 표현력이 풍부하며 확장 가능한 서비스 네트워킹의 길을 강화합니다.

Gateway API v1.4.0은 Gateway API의 GA 릴리스 채널인 Standard 채널에 세 가지 새로운 기능을 제공합니다:

• 게이트웨이와 백엔드 간 TLS를 위한 BackendTLSPolicy
• GatewayClass 상태의 supportedFeatures
• 경로(Route)를 위한 이름 지정된 규칙

또한 세 가지 새로운 실험적인 기능도 도입합니다:

• 서비스 메시 구성을 위한 메시(Mesh) 리소스
• 구성 부담을 줄이기 위한 기본 게이트웨이
• HTTPRoute를 위한 externalAuth 필터

표준 채널로의 졸업

백엔드 TLS 정책

책임자: Candace Holman, Norwin Schnyder, Katarzyna Łach

GEP-1897: BackendTLSPolicy

BackendTLSPolicy는 게이트웨이에서 백엔드 파드(pod)로의 연결에 대한 TLS 구성을 지정하는 새로운 Gateway API 타입입니다. BackendTLSPolicy 도입 전에는 게이트웨이에서 백엔드로의 홉(hop)에서 암호화된 트래픽을 허용하는 API 사양이 없었습니다.

BackendTLSPolicy의 validation 구성은 호스트 이름(hostname)을 요구합니다. 이 hostname은 두 가지 목적을 가집니다. 백엔드에 연결할 때 SNI(Server Name Indication) 헤더로 사용되며, 백엔드가 제시하는 인증서는 이 호스트 이름과 일치해야 인증이 수행됩니다. 단, subjectAltNames가 명시적으로 지정되지 않은 경우에 한합니다.

subjectAltNames(SAN)가 지정되면 hostname은 SNI에만 사용되며, 인증은 SAN에 대해 수행됩니다. 이 경우에도 호스트 이름 값에 대해 인증해야 한다면, 반드시 subjectAltNames 목록에 추가해야 합니다.

BackendTLSPolicy validation 구성은 또한 caCertificateRefs 또는 wellKnownCACertificates 중 하나를 요구합니다. caCertificateRefs는 하나 이상의(최대 8개) PEM 인코딩된 TLS 인증서 번들을 참조합니다. 사용할 특정 인증서가 없는 경우, 구현체에 따라 wellKnownCACertificates를 "System"으로 설정하여 게이트웨이가 구현별로 신뢰할 수 있는 CA 인증서 세트를 사용하도록 지시할 수 있습니다.

이 예시에서 BackendTLSPolicy는 auth-cert ConfigMap에 정의된 인증서를 사용하여 TLS로 암호화된 업스트림(upstream) 연결을 설정하도록 구성되어 있으며, auth 서비스의 백업 파드는 auth.example.com에 대한 유효한 인증서를 제공할 것으로 예상됩니다. subjectAltNames는 Hostname 타입을 사용하지만, URI 타입을 사용할 수도 있습니다.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRefs:
  - kind: Service
    name: auth
    group: ""
    sectionName: "https"
  validation:
    caCertificateRefs:
    - group: "" # core API group
      kind: ConfigMap
      name: auth-cert
    subjectAltNames:
    - type: "Hostname"
      hostname: "auth.example.com"

이 예시에서 BackendTLSPolicy는 시스템 인증서를 사용하여 TLS로 암호화된 백엔드 연결을 설정하도록 구성되어 있으며, dev 서비스의 백업 파드는 dev.example.com에 대한 유효한 인증서를 제공할 것으로 예상됩니다.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRefs:
  - kind: Service
    name: dev
    group: ""
    sectionName: "btls"
  validation:
    wellKnownCACertificates: "System"
    hostname: dev.example.com

Gateway API의 TLS 구성에 대한 자세한 정보는 Gateway API - TLS 구성에서 찾을 수 있습니다.

구현체가 지원하는 기능에 대한 상태 정보

책임자: Lior Lieberman, Beka Modebadze

GEP-2162: GatewayClass 상태의 지원 기능

GatewayClass 상태에는 새로운 필드인 supportedFeatures가 추가되었습니다. 이 추가 기능을 통해 구현체는 자신이 지원하는 기능 집합을 선언할 수 있습니다. 이는 사용자와 도구가 특정 GatewayClass의 기능을 명확하게 이해할 수 있는 방법을 제공합니다.

적합성 테스트(conformance test) 및 GatewayClass 상태 보고를 위한 이 기능의 이름은 SupportedFeatures입니다. 구현체는 GatewayClass가 승인되기 전 또는 동일한 작업에서 GatewayClass의 .status에 supportedFeatures 필드를 채워야 합니다.

다음은 GatewayClass의 .status 아래에 게시된 supportedFeatures의 예입니다:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
...
status:
  conditions:
  - lastTransitionTime: "2022-11-16T10:33:06Z"
    message: Handled by Foo controller
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  supportedFeatures:
  - HTTPRoute
  - HTTPRouteHostRewrite
  - HTTPRoutePortRedirect
  - HTTPRouteQueryParamMatching

SupportedFeatures가 표준으로 졸업하면서 Gateway API의 적합성 테스트 프로세스가 개선되었습니다. 이제 적합성 테스트 스위트는 GatewayClass 상태에 채워진 기능을 기반으로 자동으로 테스트를 실행합니다. 이는 구현체의 선언된 기능과 테스트 결과 간에 강력하고 검증 가능한 연결을 생성하여, 구현자가 올바른 적합성 테스트를 실행하고 사용자가 적합성 보고서를 신뢰하기 쉽게 만듭니다.

이는 SupportedFeatures 필드가 GatewayClass 상태에 채워지면 --supported-features, --exempt, --all-features와 같은 추가적인 적합성 테스트 플래그가 필요 없다는 것을 의미합니다. 메시 기능은 예외이며, 전용 리소스가 실험 채널에서 졸업할 때까지 적합성 프로필을 사용하거나 수동으로 관련 플래그의 조합을 제공하여 적합성을 테스트할 수 있다는 점에 유의해야 합니다.

경로(Route)를 위한 이름 지정된 규칙

GEP-995: 모든 xRouteRule 타입(HTTPRouteRule, GRPCRouteRule 등)에 새로운 name 필드 추가

책임자: Guilherme Cassolato

이 개선 사항은 Gateway API 생태계 전반에서 경로 규칙을 명시적으로 식별하고 참조할 수 있도록 합니다. 몇 가지 주요 사용 사례는 다음과 같습니다:

• 상태: 상태 조건이 특정 규칙을 이름으로 직접 참조할 수 있도록 합니다.
• 관찰성: 로그, 트레이스 및 메트릭에서 개별 규칙을 더 쉽게 식별할 수 있도록 합니다.
• 정책: 정책(GEP-713)이 targetRef[s] 필드의 sectionName 필드를 통해 특정 경로 규칙을 대상으로 할 수 있도록 합니다.
• 툴링: gwctl, kubectl과 같은 도구 및 jq, yq와 같은 일반 유틸리티에서 경로 규칙의 필터링 및 참조를 단순화합니다.
• 내부 구성 매핑: 게이트웨이 및 메시 구현체 내에서 경로 규칙을 이름으로 참조하는 내부 구성 생성을 용이하게 합니다.

이는 게이트웨이 리스너, 서비스 포트, 파드(및 컨테이너), 그리고 다른 많은 쿠버네티스 리소스에 이미 채택된 잘 확립된 패턴을 따릅니다.

새로운 name 필드는 선택 사항이지만(기존 리소스는 유효하게 유지됨), 그 사용은 강력히 권장됩니다. 구현체는 기본값을 할당할 필요는 없지만, 불변성(immutability)과 같은 제약 조건을 강제할 수 있습니다.

마지막으로, 이름 형식은 유효성 검사를 거치며, 다른 필드(예: sectionName)가 추가적인 간접 제약 조건을 부과할 수 있음을 명심하십시오.

실험 채널 변경 사항

HTTPRoute에 외부 인증(External Auth) 활성화

Gateway API에 게이트웨이 또는 HTTPRoute 수준에서 인증 및 권한 부여를 적용할 수 있는 기능을 부여하는 것은 오랫동안 매우 요청이 많았던 기능입니다. (자세한 내용은 GEP-1494 이슈를 참조하세요.)

이번 Gateway API 릴리스에서는 HTTPRoute에 실험적 필터를 추가하여 Gateway API 구현체가 외부 서비스로 호출하여 요청을 인증(선택적으로 권한 부여)하도록 합니다.

이 필터는 Envoy ext_authz API를 기반으로 하며, gRPC 또는 HTTP 프로토콜을 사용하는 Auth 서비스와 통신할 수 있도록 합니다.

두 가지 방법 모두 Auth 서비스로 전달할 헤더를 구성할 수 있으며, HTTP 프로토콜은 접두사 경로와 같은 추가 정보를 허용합니다.

HTTP 예시는 다음과 같습니다(이 예시는 Experimental 채널이 설치되어 있고 External Auth를 지원하는 구현체가 필요하다는 점에 유의하세요):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: require-auth
  namespace: default
spec:
  parentRefs:
  - name: your-gateway-here
  rules:
  - matches:
    - path:
        type: Prefix
        value: /admin
    filters:
    - type: ExternalAuth
      externalAuth:
        protocol: HTTP
        backendRef:
          name: auth-service
        http:
          # These headers are always sent for the HTTP protocol,
          # but are included here for illustrative purposes
          allowedHeaders:
          - Host
          - Method
          - Path
          - Content-Length
          - Authorization
    backendRefs:
    - name: admin-backend
      port: 8080

이를 통해 백엔드 Auth 서비스는 제공된 헤더를 사용하여 요청에 대한 인증을 결정할 수 있습니다.

요청이 허용되면 외부 Auth 서비스는 200 HTTP 응답 코드를 반환하며, 선택적으로 백엔드로 전달될 요청에 포함될 추가 헤더를 반환합니다. 요청이 거부되면 Auth 서비스는 403 HTTP 응답을 반환합니다.

인증(Authorization) 헤더는 많은 인증 방법에서 사용되므로, 이 방법은 Basic, Oauth, JWT 및 기타 일반적인 인증 및 권한 부여 방법을 수행하는 데 사용될 수 있습니다.

메시(Mesh) 리소스

책임자: Flynn

GEP-3949: 메시 전반의 구성 및 지원 기능

Gateway API v1.4.0은 새로운 실험적인 메시(Mesh) 리소스를 도입합니다. 이 리소스는 메시 전체 설정을 구성하고 특정 메시 구현체가 지원하는 기능을 검색하는 방법을 제공합니다. 이 리소스는 Gateway 리소스와 유사하며, 초기에는 주로 적합성 테스트에 사용될 예정이며, 향후 오프-클러스터 게이트웨이(off-cluster Gateway)로의 사용 확장을 계획하고 있습니다.

메시 리소스는 클러스터 스코프(cluster-scoped)이며, 실험적 기능으로서 XMesh로 명명되고 gateway.networking.x-k8s.io API 그룹에 속합니다. 핵심 필드는 controllerName으로, 리소스에 대한 책임을 지는 메시 구현체를 지정합니다. 리소스의 status 스탠자는 메시 구현체가 이를 수락했는지 여부와 메시가 지원하는 기능을 나열합니다.

이 GEP의 목표 중 하나는 사용자가 메시를 채택하는 것을 더 어렵게 만들지 않는 것입니다. 채택을 단순화하기 위해, 메시 구현체는 일치하는 controllerName을 가진 메시 리소스가 아직 존재하지 않으면 시작 시 기본 메시 리소스(Default Mesh resource)를 생성할 것으로 예상됩니다. 이는 메시 사용을 시작하기 위해 리소스를 수동으로 생성할 필요를 없애줍니다.

gateway.networking.x-k8s.io/v1alpha1 API 그룹 내의 새로운 XMesh API 종류는 메시 구성 및 기능 검색을 위한 중앙 지점을 제공합니다(원문).

최소한의 XMesh 오브젝트는 controllerName을 지정합니다:

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XMesh
metadata:
  name: one-mesh-to-mesh-them-all
spec:
  controllerName: one-mesh.example.com/one-mesh

메시 구현체는 상태 필드를 채워 리소스를 수락했음을 확인하고 지원하는 기능을 나열합니다(원문):

status:
  conditions:
  - type: Accepted
    status: "True"
    reason: Accepted
  supportedFeatures:
  - name: MeshHTTPRoute
  - name: OffClusterGateway

기본 게이트웨이(Default Gateways) 도입

책임자: Flynn

GEP-3793: 게이트웨이가 일부 경로를 기본으로 프로그래밍하도록 허용

애플리케이션 개발자에게서 흔히 나오는 피드백 중 하나는 모든 북-남(north-south) 경로(Route)에 대해 상위 게이트웨이(parent Gateway)를 명시적으로 지정해야 한다는 점이었습니다. 이러한 명시성은 모호함을 방지하지만, 특히 기본 인프라의 명명 체계에 대해 걱정하지 않고 단순히 애플리케이션을 외부에 노출하려는 개발자에게는 마찰을 더합니다. 이를 해결하기 위해 기본 게이트웨이(Default Gateways) 개념을 도입했습니다.

애플리케이션 개발자를 위한 "기본값 사용"

애플리케이션 개발자로서, 여러분은 트래픽이 어떤 특정 게이트웨이를 통해 흐르는지에 대해 종종 신경 쓰지 않고, 그저 작동하기를 원합니다. 이 개선 사항을 통해 이제 경로(Route)를 생성하고 단순히 기본 게이트웨이를 사용하도록 요청할 수 있습니다.

이는 경로의 spec에 새로운 useDefaultGateways 필드를 설정하여 이루어집니다.

다음은 기본 게이트웨이를 사용하는 간단한 HTTPRoute입니다:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  useDefaultGateways: All
  rules:
  - backendRefs:
    - name: my-service
      port: 80

그게 다입니다! 더 이상 환경에 맞는 올바른 게이트웨이 이름을 찾아 헤맬 필요가 없습니다. 이제 여러분의 경로는 "기본 설정된 경로(defaulted Route)"가 됩니다.

클러스터 운영자를 위한 제어권 유지

이 기능은 클러스터 운영자("치히로")로부터 제어권을 빼앗지 않습니다. 실제로, 어떤 게이트웨이가 기본 역할을 할 수 있는지에 대해 명시적인 제어권을 가집니다. 게이트웨이는 그렇게 구성된 경우에만 이러한 기본 설정된 경로를 수락합니다.

ValidatingAdmissionPolicy를 사용하여 경로(Route)가 기본 게이트웨이에 의존하도록 요구하거나 심지어 금지할 수도 있습니다.

클러스터 운영자는 (새로운) .spec.defaultScope 필드를 설정하여 게이트웨이를 기본값으로 지정할 수 있습니다:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-default-gateway
  namespace: default
spec:
  defaultScope: All
  # ... other gateway configuration

운영자는 기본 게이트웨이를 사용하지 않거나, 여러 개를 가질 수도 있습니다.

작동 방식 및 주요 세부 사항

• 깨끗하고 GitOps 친화적인 워크플로우를 유지하기 위해, 기본 게이트웨이는 경로의 spec.parentRefs를 수정하지 않습니다. 대신, 바인딩은 경로의 status 필드에 반영됩니다. 경로의 status.parents 스탠자를 항상 검사하여 어떤 게이트웨이가 이를 수락했는지 정확히 확인할 수 있습니다. 이는 원래 의도를 보존하고 CD 도구와의 충돌을 방지합니다.
• 이 디자인은 클러스터 내에서 여러 게이트웨이가 기본값으로 지정될 수 있도록 명시적으로 지원합니다. 이 경우, 기본 설정된 경로는 모든 게이트웨이에 바인딩됩니다. 이를 통해 클러스터 운영자는 새로운 기본 게이트웨이의 무중단 마이그레이션 및 테스트를 수행할 수 있습니다.
• 단일 경로로 북-남 트래픽(기본 게이트웨이를 통해 클러스터에 들어오거나 나가는 트래픽)과 동-서/메시 트래픽(클러스터 내 서비스 간 트래픽)을 모두 처리할 수 있습니다. 이는 parentRefs에서 서비스를 명시적으로 참조하여 이루어집니다.

기본 게이트웨이는 Gateway API를 일상적인 사용 사례에 대해 더 단순하고 직관적으로 만드는 데 중요한 진전이며, 운영자에게 필요한 유연성과 개발자가 원하는 단순성 사이의 간극을 메웁니다.

클라이언트 인증서 유효성 검사 구성

책임자: Arko Dasgupta, Katarzyna Łach

GEP-91: 연결 병합 보안 문제 해결

이번 릴리스는 클라이언트 인증서 유효성 검사 구성을 위한 업데이트를 제공하며, 연결 재사용과 관련된 중요한 보안 취약점을 해결합니다. HTTP 연결 병합(coalescing)은 클라이언트가 다른 도메인에 대한 요청에 기존 TLS 연결을 재사용할 수 있도록 하는 웹 성능 최적화 기술입니다. 이는 새로운 연결 설정 오버헤드를 줄이지만, API 게이트웨이의 맥락에서는 보안 위험을 초래합니다. 여러 리스너에 걸쳐 단일 TLS 연결을 재사용하는 기능은 무단 액세스를 방지하기 위해 공유 클라이언트 인증서 구성 도입의 필요성을 야기합니다.

SNI 기반 mTLS가 해결책이 아닌 이유

리스너를 구분하기 위해 SNI(Server Name Indication)를 사용하는 것이 이 문제를 해결할 것이라고 생각할 수 있습니다. 그러나 TLS SNI는 연결 병합(coalescing) 시나리오에서 보안 정책을 적용하는 신뢰할 수 있는 메커니즘이 아닙니다. 클라이언트는 여러 피어(peer) 연결에 대해 단일 TLS 연결을 사용할 수 있으며, 모든 연결이 동일한 인증서로 커버되는 한 가능합니다.

이는 클라이언트가 하나의 피어 ID를 나타내어(SNI 사용) 연결을 설정한 다음, 동일한 IP 주소와 포트에서 수신 대기하는 다른 가상 호스트에 액세스하기 위해 해당 연결을 재사용할 수 있음을 의미합니다. 클라이언트 측 휴리스틱에 의해 제어되는 이 재사용은 두 번째 리스너 구성에 특화된 상호 TLS 정책을 우회할 수 있습니다.

다음은 이를 설명하는 예입니다:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: wildcard-tls-gateway
spec:
  gatewayClassName: example
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - group: "" # core API group
        kind: Secret
        name: foo-example-com-cert # SAN: foo.example.com
  - name: wildcard-https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      certificateRefs:
      - group: "" # core API group
        kind: Secret
        name: wildcard-example-com-cert # SAN: *.example.com

저는 두 개의 리스너를 가진 게이트웨이를 구성했으며, 두 리스너 모두 호스트 이름이 겹칩니다. 제 의도는 foo-http 리스너가 foo-example-com-cert 인증서를 제시하는 클라이언트에게만 접근 가능하도록 하는 것입니다. 대조적으로, wildcard-https 리스너는 *.example.com 도메인에 유효한 모든 인증서를 사용하는 더 넓은 대상에게 접근을 허용해야 합니다.

클라이언트가 foo.example.com에 처음 연결하는 시나리오를 고려해봅시다. 서버는 foo-example-com-cert 인증서를 요청하고 성공적으로 유효성을 검사하여 연결을 설정합니다. 이후 동일한 클라이언트가 wildcard-https 리스너가 처리하는 bar.example.com과 같은 이 도메인 내의 다른 사이트에 액세스하고자 합니다. 연결 재사용으로 인해 클라이언트는 기존 연결에서 추가 TLS 핸드셰이크 없이 wildcard-https 백엔드에 액세스할 수 있습니다. 이 프로세스는 예상대로 작동합니다.

그러나 액세스 순서가 역전될 때 심각한 보안 취약점이 발생합니다. 만약 클라이언트가 bar.example.com에 먼저 연결하여 유효한 bar.example.com 인증서를 제시하고 연결이 성공적으로 설정된 시나리오를 고려해봅시다. 이 클라이언트가 foo.example.com에 액세스하려고 시도하면, 기존 연결의 클라이언트 인증서는 재검증되지 않습니다. 이는 클라이언트가 foo 백엔드에 대한 특정 인증서 요구 사항을 우회할 수 있게 하여 심각한 보안 침해로 이어집니다.

해결책: 포트별 TLS 구성

업데이트된 Gateway API는 Gateway의 .spec에 tls 필드를 추가하여 모든 리스너에 대한 기본 클라이언트 인증서 유효성 검사 구성을 정의할 수 있게 하며, 필요에 따라 포트별로 이를 재정의할 수 있습니다. 이는 TLS 정책을 관리하는 유연하고 강력한 방법을 제공합니다.

다음은 업데이트된 API 정의(Go 소스 코드로 표시)입니다:

// GatewaySpec defines the desired state of Gateway.
type GatewaySpec struct {
 ...
 // GatewayTLSConfig specifies frontend tls configuration for gateway.
 TLS *GatewayTLSConfig `json:"tls,omitempty"`
}

// GatewayTLSConfig specifies frontend tls configuration for gateway.
type GatewayTLSConfig struct {
 // Default specifies the default client certificate validation configuration
 Default TLSConfig `json:"default"`

 // PerPort specifies tls configuration assigned per port.
 PerPort []TLSPortConfig `json:"perPort,omitempty"`
}

// TLSPortConfig describes a TLS configuration for a specific port.
type TLSPortConfig struct {
 // The Port indicates the Port Number to which the TLS configuration will be applied.
 Port PortNumber `json:"port"`

 // TLS store the configuration that will be applied to all Listeners handling
 // HTTPS traffic and matching given port.
 TLS TLSConfig `json:"tls"`
}

호환성 변경 사항 (Breaking changes)

표준 GRPCRoute - .spec 필드 필수 (기술적 세부 사항)

GRPCRoute의 표준 승격은 최상위 .spec 필드의 존재에 관한 사소하지만 기술적으로 호환성을 깨는(breaking) 변경 사항을 도입합니다. 표준 상태 달성의 일환으로, Gateway API는 GRPCRoute CustomResourceDefinition (CRD) 내의 OpenAPI 스키마 유효성 검사를 강화하여 모든 GRPCRoute 리소스에 대해 spec 필드가 명시적으로 요구되도록 했습니다.

사용자가 어떤 사양도 없이 GRPCRoute를 정의하려고 시도했을 가능성은 매우 낮지만, 완전히 spec 필드가 없는 것을 허용하는 완화된 해석에 의존했을 수 있는 기존 자동화 또는 매니페스트는 이제 유효성 검사에 실패하며, 비어 있더라도 .spec 필드를 포함하도록 반드시 업데이트해야 합니다.

HTTPRoute의 실험적 CORS 지원 - allowCredentials 필드의 호환성 변경

Gateway API 서브프로젝트는 HTTPRoute의 실험적 CORS 지원에 호환성을 깨는 변경 사항을 도입했으며, 이는 CORS 정책 내의 allowCredentials 필드와 관련됩니다. 이 필드의 정의는 상위 CORS 사양과 엄격하게 일치하게 되었는데, 이는 해당 Access-Control-Allow-Credentials 헤더가 부울(Boolean) 값을 나타내야 한다고 규정합니다. 이전에는 구현체가 지나치게 허용적이었을 수 있으며, 완화된 스키마 유효성 검사로 인해 true와 같은 비표준 또는 문자열 표현을 받아들였을 수도 있습니다.

CORS 규칙을 구성하던 사용자는 이제 자신의 매니페스트를 검토하고 allowCredentials 값이 새롭고 더 제한적인 스키마에 엄격히 부합하는지 확인해야 합니다. 이 더 엄격한 유효성 검사를 따르지 않는 기존 HTTPRoute 정의는 이제 API 서버에 의해 거부되므로, 기능을 유지하기 위해 구성을 업데이트해야 합니다.

개발 및 사용 경험 개선

이번 릴리스의 일환으로, 몇 가지 개발자 경험 워크플로우가 개선되었습니다:

• Kube API Linter를 CI/CD 파이프라인에 추가하여 API 검토자의 부담을 줄이고 일반적인 실수를 줄였습니다.
• envtest 사용으로 CRD 테스트 실행 시간을 개선했습니다.

또한, Gateway API 사용 경험을 개선하기 위한 노력의 일환으로, 문서 웹사이트의 일부 모호함과 오래된 기술 부채를 제거하는 작업이 이루어졌습니다:

• 이제 필드가 experimental일 때 API 참조가 명시적입니다.
• GEP(GatewayAPI Enhancement Proposal) 탐색 바가 자동으로 생성되어 개선 사항의 실제 상태를 반영합니다.

직접 사용해보기

다른 쿠버네티스 API와 달리, 최신 Gateway API 버전을 사용하기 위해 쿠버네티스 최신 버전으로 업그레이드할 필요는 없습니다. 쿠버네티스 1.26 이상을 실행 중이라면, 이 버전의 Gateway API를 사용하여 시작하고 실행할 수 있습니다.

API를 사용해 보려면 시작하기 가이드를 따르세요.

현재 작성 시점 기준으로, 7개의 구현체가 Gateway API v1.4.0에 이미 적합합니다. 알파벳 순서:

• Agent Gateway (kgateway 포함)
• Airlock Microgateway
• Envoy Gateway
• GKE Gateway
• Istio
• kgateway
• Traefik Proxy

참여하기

어떤 기능이 언제 추가될지 궁금하신가요? 인그레스(ingress)와 서비스 메시(service mesh) 모두를 위한 쿠버네티스 라우팅 API의 미래를 정의하는 데 참여하고 도울 수 있는 많은 기회가 있습니다.

• 사용자 가이드를 확인하여 어떤 사용 사례를 해결할 수 있는지 알아보세요.
• 기존 게이트웨이 컨트롤러 중 하나를 사용해 보세요.
• 또는 커뮤니티에 참여하여 Gateway API의 미래를 함께 만들어 보세요!

유지보수 담당자들은 Gateway API에 기여한 모든 분들께 감사드립니다. 저장소에 대한 커밋, 토론, 아이디어 또는 일반적인 지원 등 어떤 형태든 관계없이 말입니다. 이 헌신적이고 활동적인 커뮤니티의 지원 없이는 이러한 진전을 이룰 수 없었을 것입니다.

관련 쿠버네티스 블로그 글

• Gateway API v1.3.0: 요청 미러링, CORS, 게이트웨이 병합 및 재시도 예산의 발전 (2025년 6월)
• Gateway API v1.2: WebSockets, 타임아웃, 재시도 등 (2024년 11월)
• Gateway API v1.1: 서비스 메시, GRPCRoute 등 (2024년 5월)
• Gateway API v1.0의 새로운 실험적 기능 (2023년 11월)
• Gateway API v1.0: GA 릴리스 (2023년 10월)