15장. Gateway [gateway.networking.k8s.io/v1]


설명
gateway는 Listeners를 IP 주소 집합에 바인딩하여 서비스 트래픽 처리 인프라의 인스턴스를 나타냅니다.
유형
object
필수 항목
  • spec

15.1. 사양

Expand
속성유형설명

apiVersion

string

APIVersion은 버전이 지정된 이 오브젝트 표현의 스키마를 정의합니다. 서버는 인식된 스키마를 최신 내부 값으로 변환해야 하며, 인식되지 않는 값을 거부할 수 있습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

string

kind는 이 오브젝트가 나타내는 REST 리소스에 해당하는 문자열 값입니다. 서버는 클라이언트에서 요청을 제출한 끝점에서 이를 유추할 수 있습니다. CamelCase로 업데이트할 수 없습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

메타데이터

ObjectMeta

표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

object

spec은 원하는 게이트웨이 상태를 정의합니다.

status

object

상태는 게이트웨이의 현재 상태를 정의합니다.

15.1.1. .spec

설명
spec은 원하는 게이트웨이 상태를 정의합니다.
유형
object
필수 항목
  • gatewayClassName
  • 리스너
Expand
속성유형설명

주소

array

이 게이트웨이에 대해 요청된 주소입니다. 이는 선택 사항이며 동작은 구현에 따라 달라질 수 있습니다. 사양에서 값이 설정되고 요청된 주소가 유효하지 않거나 사용할 수 없는 경우 구현은 GatewayStatus.Addresses의 연결된 항목에서 이 주소를 지정해야 합니다.

address 필드는 이 게이트웨이에 바인딩된 트래픽이 사용할 "게이트웨이"의 주소에 대한 요청을 나타냅니다. 이는 외부 로드 밸런서 또는 기타 네트워킹 인프라의 IP 주소 또는 호스트 이름 또는 트래픽이 전송될 다른 주소일 수 있습니다.

주소를 지정하지 않으면 구현에 따라 게이트웨이를 예약하여 적절한 주소 집합을 할당할 수 있습니다.

구현은 게이트웨이에 할당하는 모든 GatewayAddress에 모든 Listeners를 바인딩하고 GatewayStatus.Addresses에서 해당 항목을 추가해야 합니다.

지원: 확장

addresses[]

object

GatewayAddress는 게이트웨이에 바인딩할 수 있는 주소를 설명합니다.

gatewayClassName

string

이 게이트웨이에 사용되는 GatewayClassName입니다. 이는 GatewayClass 리소스의 이름입니다.

인프라

object

infrastructure는 이 게이트웨이 인스턴스에 대한 인프라 수준 속성을 정의합니다.

지원: 확장

리스너

array

이 게이트웨이와 연결된 리스너입니다. 리스너는 이 게이트웨이의 주소에 바인딩된 논리 끝점을 정의합니다. 하나 이상의 리스너를 지정해야 합니다.

별도의 Listeners

Listeners 세트(예: 단일 게이트웨이)의 각 리스너는 고유 해야 하며 트래픽 흐름을 정확히 하나의 리스너에 할당할 수 있어야 합니다. (이 섹션에서는 구현이 여러 게이트웨이에서 단일 데이터 플레인으로 구성을 병합할 수 있고 이러한 규칙이 적용되기 때문에 단일 게이트웨이의 "Listeners" 대신 " Listeners" 집합을 사용합니다.

실제로 이는 세트의 각 리스너가 포트, 프로토콜, 그리고 프로토콜에서 지원하는 경우 호스트 이름의 고유한 조합을 가져야 함을 의미합니다.

포트, 프로토콜 및 TLS 설정의 일부 조합은 핵심 지원으로 간주되며 지원하는 개체에 따라 구현에서 지원되어야 합니다.

HTTPRoute

1. HTTPRoute, 포트: 80, 프로토콜: HTTP 2. HTTPRoute, 포트: 443, 프로토콜: HTTPS, TLS 모드: 종료, TLS 키페어 제공

TLSRoute

1. TLSRoute, 포트: 443, 프로토콜: TLS, TLS 모드: 패스스루

"Distinct" 리스너는 다음과 같은 속성을 갖습니다.

구현 시 인바운드 요청을 단일의 고유한 Listener에 일치시킬 수 있습니다 .

여러 리스너가 필드 값을 공유하는 경우(예: 두 리스너가 동일한 포트 값을 갖는 경우), 구현 시 다른 리스너 필드를 사용하여 해당 리스너 중 하나에만 요청을 일치시킬 수 있습니다.

여러 리스너가 Protocol 필드에 대해 동일한 값을 갖는 경우, 일치하는 Protocol 값을 갖는 각 리스너는 다른 필드에 대해 서로 다른 값을 가져야 합니다.

리스너에 대해 반드시 달라야 하는 필드 세트는 프로토콜마다 다릅니다. 다음 규칙은 현재 Gateway API 사양에 정의된 각 프로토콜과 별도로 Listener에 대해 반드시 고려해야 하는 필드에 대한 규칙을 정의합니다.

모든 프로토콜 값을 공유하는 리스너 세트는 다음 필드 중 하나 이상 이 서로 다르기 위해 서로 다른 값을 가져야 합니다.

* HTTP, HTTPS, TLS : 포트, 호스트 이름 * TCP, UDP : 포트

구현 시 발생하는 일과 관련하여 주의해야 할 매우 중요한 규칙이 있습니다.

* TCP 프로토콜 리스너는 물론 HTTP, HTTPS 또는 TLS 프로토콜 리스너도 지원하고, * TCP 프로토콜과 동일한 포트를 사용하는 HTTP, HTTPS 또는 TLS 프로토콜을 확인합니다.

이 경우 TCP 리스너와 포트를 공유하는 모든 리스너는 서로 다르므로 수락되어서는 안 됩니다.

구현이 TCP 프로토콜 리스너를 지원하지 않는 경우 이전 규칙은 적용되지 않으며, TCP 리스너는 수락되어서는 안 됩니다.

tls 필드는 리스너가 고유한지 여부를 판별하는 데 사용되지 않습니다. TLS 구성 다른 리스너는 모든 경우에 충돌하기 때문입니다.

# 호스트 이름으로만 구별되는 리스너

호스트 이름만으로 리스너가 구별되는 경우, 올바른 리스너와 연관된 경로 세트를 선택하려면 인바운드 요청 호스트 이름이 가장 구체적인 호스트 이름 값부터 덜 구체적인 호스트 이름 값까지 일치해야 합니다.

정확한 일치는 와일드카드 일치보다 먼저 처리되어야 하며, 와일드카드 일치는 폴백(빈 호스트 이름 값) 일치보다 먼저 처리되어야 합니다. 예를 들어, "foo.example.com""*.example.com" 보다 우선하고, "\*.example.com"은 "" 보다 우선합니다.

또한, 와일드카드 항목이 여러 개 있는 경우 덜 구체적인 와일드카드 항목보다 더 구체적인 와일드카드 항목을 먼저 처리해야 합니다. 예를 들어, "*.foo.example.com"은 "\*.example.com" 보다 우선합니다.

여기서 정확한 정의는 와일드카드 문자 오른쪽에 있는 호스트 이름의 점의 수가 많을수록 우선순위가 높다는 것입니다.

와일드카드 문자는 왼쪽에 있는 아무리 많은 문자 와 점과도 일치합니다. 따라서 "*.example.com"은 "foo.bar.example.com" "bar.example.com" 모두와 일치합니다.

불분명한 리스너 처리

리스너 세트에 서로 구별되지 않는 리스너가 포함된 경우 해당 리스너는 충돌 상태 이며, 구현 시 리스너 상태의 "충돌" 조건을 "참"으로 설정해야 합니다.

이 문서의 목적상 "불분명한"과 "갈등된"이라는 단어는 동일한 것으로 간주됩니다.

구현에서는 충돌하는 리스너가 없는 부분 리스너 세트만 허용하는 경우에만 충돌하는 리스너가 있는 게이트웨이를 허용하기로 선택할 수 있습니다.

특히, 구현은 다음 규칙에 따라 부분적인 Listener 세트를 허용할 수 있습니다.

* 구현 시 충돌하는 리스너 중 하나를 승자로 선택해서는 안 됩니다. 모든 indistinct Listeners는 처리를 위해 허용되지 않아야 합니다. * 하나 이상의 고유 Listener가 있어야 하며, 그렇지 않은 경우 게이트웨이에는 청취자가 효과적으로 포함되어 있어야 하며 전체 처리에서 거부되어야 합니다.

게이트웨이 상태에 게이트웨이에 충돌된 청취자가 포함될 때 게이트웨이 상태에 "ListenersNotValid" 조건을 설정해야 합니다. 해당 상태는 수신 대기자가 충돌하고 수락되는 메시지에 명확하게 표시되어야 합니다. 또한 이러한 리스너의 Listener 상태는 충돌하고 수락되지 않는 Listeners를 나타냅니다.

일반 리스너 동작

모든 고유 Listeners의 경우 요청은 최대 하나의 Listener로 일치해야 합니다. 예를 들어, 청취자가 "foo.example.com" 및 "*.example.com"에 대해 정의된 경우 "foo.example.com" SHOULD에 대한 요청은 "foo.example.com" Listener에 연결된 경로만 사용하여 라우팅됩니다('*.example.com" Listener가 아님).

이 개념을 "Listener Isolation"이라고 하며 게이트웨이 API의 확장 기능입니다. Listener 격리를 지원하지 않는 구현은 이를 명확하게 문서화해야 하며 GatewayHTTPListenerIsolation 기능에 대한 지원을 요청해서는 안 됩니다.

확장 게이트웨이HTTP ListenerIsolation 기능에 대한 Listener Isolation SHOULD 클레임을 지원하는 구현에서는 관련 적합성 테스트를 전달합니다.

호환되는 Listeners

게이트웨이의 Listeners는 다음과 같은 경우 호환되는 것으로 간주됩니다.

1. 구분되어 있습니다. 2. 구현은 할당된 모든 주소에서 모든 Listeners를 사용할 수 있는 주소 요구 사항을 준수하여 제공할 수 있습니다.

확장 지원에서 호환되는 조합은 구현마다 다를 것으로 예상됩니다. 한 구현에 호환되는 조합이 다른 구현과 호환되지 않을 수 있습니다.

예를 들어 동일한 주소에서 TCP 및 UDP 리스너를 모두 제공할 수 없거나 동일한 포트에서 HTTPS와 일반 TLS 청취를 혼합할 수 없는 구현은 고유하더라도 이러한 케이스와 호환되는 경우를 고려하지 않습니다.

구현은 모든 게이트웨이의 모든 Listeners가 호환되는 경우 단일 주소 집합에 별도의 게이트웨이를 병합할 수 있습니다.Implementations MAY merge separate Gateways to a single set of addresses if all Listeners across all Gateways are compatible.

향후 릴리스에서는 MinItems=1 요구 사항이 삭제될 수 있습니다.

지원: Core

listeners[]

object

리스너는 게이트웨이가 네트워크 연결을 수락하는 논리 끝점의 개념을 나타냅니다.

15.1.2. .spec.addresses

설명

이 게이트웨이에 대해 요청된 주소입니다. 이는 선택 사항이며 동작은 구현에 따라 달라질 수 있습니다. 사양에서 값이 설정되고 요청된 주소가 유효하지 않거나 사용할 수 없는 경우 구현은 GatewayStatus.Addresses의 연결된 항목에서 이 주소를 지정해야 합니다.

address 필드는 이 게이트웨이에 바인딩된 트래픽이 사용할 "게이트웨이"의 주소에 대한 요청을 나타냅니다. 이는 외부 로드 밸런서 또는 기타 네트워킹 인프라의 IP 주소 또는 호스트 이름 또는 트래픽이 전송될 다른 주소일 수 있습니다.

주소를 지정하지 않으면 구현에 따라 게이트웨이를 예약하여 적절한 주소 집합을 할당할 수 있습니다.

구현은 게이트웨이에 할당하는 모든 GatewayAddress에 모든 Listeners를 바인딩하고 GatewayStatus.Addresses에서 해당 항목을 추가해야 합니다.

지원: 확장

유형
array

15.1.3. .spec.addresses[]

설명
GatewayAddress는 게이트웨이에 바인딩할 수 있는 주소를 설명합니다.
유형
object
필수 항목
  • value
Expand
속성유형설명

type

string

주소 유형입니다.

value

string

주소의 값입니다. 값의 유효성은 컨트롤러의 유형 및 지원에 따라 달라집니다.

예: 1.2.3.4,128::1,my-ip-address.

15.1.4. .spec.infrastructure

설명

infrastructure는 이 게이트웨이 인스턴스에 대한 인프라 수준 속성을 정의합니다.

지원: 확장

유형
object
Expand
속성유형설명

annotations

오브젝트(문자열)

이 게이트웨이에 대한 응답으로 생성된 모든 리소스에 적용해야 하는 주석입니다.

다른 Kubernetes 오브젝트를 생성하는 구현의 경우 리소스의 metadata.annotations 필드여야 합니다. 다른 구현예의 경우, 이는 임의의 관련(특정 구현) "항상" 개념을 나타냅니다.

구현 시 적합한 것으로 간주되는 구현별 주석을 추가하도록 선택할 수 있습니다.

지원: 확장

labels

오브젝트(문자열)

이 게이트웨이에 대한 응답으로 생성된 모든 리소스에 적용해야 하는 라벨입니다.

다른 Kubernetes 오브젝트를 생성하는 구현의 경우 리소스의 metadata.labels 필드여야 합니다. 다른 구현예의 경우 이는 관련(특정 구현) "레이블" 개념을 나타냅니다.

구현 시 적합한 것으로 간주되는 구현별 레이블을 추가하도록 선택할 수 있습니다.

구현에서 이러한 레이블을 Pod에 매핑하거나 라벨이 변경될 때 다시 생성해야 하는 기타 리소스는 문서에서 이 동작에 대해 명확하게 경고해야 합니다.

지원: 확장

parametersRef

object

ParametersRef는 게이트웨이에 해당하는 구성 매개 변수가 포함된 리소스에 대한 참조입니다. 컨트롤러에 추가 구성이 필요하지 않은 경우 선택 사항입니다.

이는 GatewayClass의 매개변수Ref 와 동일한 시맨틱을 따르지만Gateway를 기반으로 합니다.

게이트웨이의 GatewayClass는 자체 매개변수Ref 를 제공할 수 있습니다. 둘 다 지정되면 병합 동작이 구현됩니다. 일반적으로 GatewayClass는 Gateway에서 재정의할 수 있는 기본값을 제공하는 것이 좋습니다.

참조자를 찾을 수 없거나 지원되지 않는 종류 또는 해당 리소스 내의 데이터가 잘못된 경우 "Accepted" 상태 조건 및 "InvalidParameters"로 설정된 "Accepted" 상태 조건과 함께 게이트웨이가 거부됩니다.

지원: 구현별

15.1.5. .spec.infrastructure.parametersRef

설명

ParametersRef는 게이트웨이에 해당하는 구성 매개 변수가 포함된 리소스에 대한 참조입니다. 컨트롤러에 추가 구성이 필요하지 않은 경우 선택 사항입니다.

이는 GatewayClass의 매개변수Ref 와 동일한 시맨틱을 따르지만Gateway를 기반으로 합니다.

게이트웨이의 GatewayClass는 자체 매개변수Ref 를 제공할 수 있습니다. 둘 다 지정되면 병합 동작이 구현됩니다. 일반적으로 GatewayClass는 Gateway에서 재정의할 수 있는 기본값을 제공하는 것이 좋습니다.

참조자를 찾을 수 없거나 지원되지 않는 종류 또는 해당 리소스 내의 데이터가 잘못된 경우 "Accepted" 상태 조건 및 "InvalidParameters"로 설정된 "Accepted" 상태 조건과 함께 게이트웨이가 거부됩니다.

지원: 구현별

유형
object
필수 항목
  • group
  • kind
  • name
Expand
속성유형설명

group

string

그룹은 참조 그룹의 그룹입니다.

kind

string

이는 일종의 참조입니다.

name

string

이름은 참조의 이름입니다.

15.1.6. .spec.listeners

설명

이 게이트웨이와 연결된 리스너입니다. 리스너는 이 게이트웨이의 주소에 바인딩된 논리 끝점을 정의합니다. 하나 이상의 리스너를 지정해야 합니다.

##별 Listeners

Listeners 세트(예: 단일 게이트웨이)의 각 리스너는 고유 해야 하며 트래픽 흐름을 정확히 하나의 리스너에 할당할 수 있어야 합니다. (이 섹션에서는 구현이 여러 게이트웨이에서 단일 데이터 플레인으로 구성을 병합할 수 있고 이러한 규칙이 적용되기 때문에 단일 게이트웨이의 "Listeners" 대신 " Listeners" 집합을 사용합니다.

대략적으로, 이는 세트의 각 리스너가 포트, 프로토콜 및 프로토콜에서 지원하는 경우 고유 한 조합을 가져야 함을 의미합니다.

포트, 프로토콜 및 TLS 설정의 일부 조합은 Core 지원으로 간주되며 지원하는 개체를 기반으로 구현에서 지원해야 합니다.

HTTPRoute

  1. HTTPRoute, Port: 80, Protocol: HTTP
  2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS 모드: Terminate, TLS 키 쌍 제공

TLSRoute

  1. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough

"distinct" Listeners에는 다음과 같은 속성이 있습니다.

구현은 인바운드 요청을 하나의 고유 Listener로 일치시킬 수 있습니다.

여러 Listeners가 필드에 대한 값을 공유하는 경우(예: 동일한 포트 값이 있는 두 개의 Listeners) 구현에서 다른 Listener 필드를 사용하는 Listeners 중 하나에만 요청을 일치시킬 수 있습니다.

여러 리스너가 Protocol 필드에 대해 동일한 값을 갖는 경우, Protocol 값이 일치하는 각 Listeners는 다른 필드에 대해 서로 다른 값을 가져야 합니다.

Listener마다 달라야 하는 필드 세트는 프로토콜마다 다릅니다. 다음 규칙은 Listeners가 현재 게이트웨이 API 사양에 정의된 각 프로토콜과 구별되도록 고려해야 하는 필드에 대한 규칙을 정의합니다.

모두 프로토콜 값을 공유하는 리스너 세트는 다음 필드 중 하나 이상이 구별되도록 서로 다른 값을 가져야 합니다.

  • HTTP, HTTPS, TLS: 포트, 호스트 이름
  • TCP, UDP: 포트

호출해야 할 매우 중요한 규칙 중 하나는 구현 시 발생하는 작업을 포함합니다.

  • TCP 프로토콜 Listeners와 HTTP, HTTPS 또는 TLS 프로토콜 Listeners를 지원하며,
  • TCP 프로토콜이 있는 포트와 동일한 포트 를 사용하는 HTTP, HTTPS 또는 TLS 프로토콜을 참조하십시오.

이 경우 TCP 리스너와 포트를 공유하는 모든 Listeners는 고유하지 않으므로 수락해서는 안 됩니다.

구현에서 TCP Protocol Listeners를 지원하지 않으면 이전 규칙이 적용되지 않으며 TCP Listeners SHOULD는 허용되지 않습니다.

모든 경우에 TLS 구성 다르므로 tls 필드는 리스너가 구별되는지 확인하는 데 사용되지 않습니다.

# Hostname에 의해서만 구분되는 리스너

Listeners가 호스트 이름에만 따라 구분되는 경우 인바운드 요청 호스트 이름은 올바른 Listener 및 관련 경로 세트를 선택하기 위해 가장 구체적인 호스트 이름 값에서 일치해야 합니다.

일치하는 와일드카드를 일치하기 전에 정확히 일치해야 하며, 폴백(비어 있는 호스트 이름 값)이 일치하기 전에 와일드카드 일치를 처리해야 합니다. 예를 들어 "foo.example.com""*.example.com" 보다 우선하며 "\*.example.com""" 보다 우선합니다.

또한 와일드카드 항목이 여러 개인 경우 더 적은 특정 와일드카드 항목보다 먼저 와일드카드 항목을 처리해야 합니다. 예를 들어 "*.foo.example.com""\*.example.com" 보다 우선합니다.

여기서 정확한 정의는 와일드카드 문자 오른쪽에 있는 호스트 이름의 점 수가 클수록 우선순위가 높습니다.

와일드카드 문자는 원하는 수의 문자 와 점과 일치하지만, 따라서 "\*.example.com""foo.bar.example.com" "bar.example.com" 모두 일치합니다.

## 처리 인디언더

Listeners 세트에 고유하지 않은 Listeners가 포함된 경우, 해당 Listeners가 충돌하고 구현은 Listener Status의 " Conflicted " 조건을 "True"로 설정해야 합니다.

"indistinct" 및 "conflicted"라는 단어는 이 문서의 목적에 따라 동일하게 간주됩니다.

구현은 Conflicted Listeners가 없는 부분 리스너 세트만 수락하는 경우에만 일부 Conflicted Listeners가 있는 게이트웨이를 수락하도록 선택할 수 있습니다.

특히 구현에서는 다음 규칙에 따라 설정된 부분 리스너를 허용할 수 있습니다.

  • 구현이 실패로 충돌하는 요인 중 하나를 선택할 수 없습니다. 모든 indistinct Listeners는 처리를 위해 허용되지 않아야 합니다.
  • 하나 이상의 고유 Listener가 있어야 하며, 그렇지 않은 경우 게이트웨이에는 청취자가 효과적으로 포함되어 있어야 하며 전체 처리에서 거부되어야 합니다.

게이트웨이 상태에 게이트웨이에 충돌된 청취자가 포함될 때 게이트웨이 상태에 "ListenersNotValid" 조건을 설정해야 합니다. 해당 상태는 수신 대기자가 충돌하고 수락되는 메시지에 명확하게 표시되어야 합니다. 또한 이러한 리스너의 Listener 상태는 충돌하고 수락되지 않는 Listeners를 나타냅니다.

## 일반 리스너 동작

모든 고유 Listeners의 경우 요청은 최대 하나의 Listener로 일치해야 합니다. 예를 들어 Listeners가 "foo.example.com" 및 ". example.com"에 대해 정의된 경우 "foo.example.com" SHOULD에 대한 요청은 "foo.example.com" Listener에 연결된 경로만 사용하여 라우팅됩니다(' .example.com" Listener가 아님 ).

이 개념을 "Listener Isolation"이라고 하며 게이트웨이 API의 확장 기능입니다. Listener 격리를 지원하지 않는 구현은 이를 명확하게 문서화해야 하며 GatewayHTTPListenerIsolation 기능에 대한 지원을 요청해서는 안 됩니다.

확장 게이트웨이HTTP ListenerIsolation 기능에 대한 Listener Isolation SHOULD 클레임을 지원하는 구현에서는 관련 적합성 테스트를 전달합니다.

## 호환되는 Listeners

게이트웨이의 Listeners는 다음과 같은 경우 호환되는 것으로 간주됩니다.

  1. 구분되어 있습니다.
  2. 구현은 할당된 모든 주소에서 모든 Listeners를 사용할 수 있는 주소 요구 사항을 준수하여 제공할 수 있습니다.

확장 지원에서 호환되는 조합은 구현마다 다를 것으로 예상됩니다. 한 구현에 호환되는 조합이 다른 구현과 호환되지 않을 수 있습니다.

예를 들어 동일한 주소에서 TCP 및 UDP 리스너를 모두 제공할 수 없거나 동일한 포트에서 HTTPS와 일반 TLS 청취를 혼합할 수 없는 구현은 고유하더라도 이러한 케이스와 호환되는 경우를 고려하지 않습니다.

구현은 모든 게이트웨이의 모든 Listeners가 호환되는 경우 단일 주소 집합에 별도의 게이트웨이를 병합할 수 있습니다.Implementations MAY merge separate Gateways to a single set of addresses if all Listeners across all Gateways are compatible.

향후 릴리스에서는 MinItems=1 요구 사항이 삭제될 수 있습니다.

지원: Core

유형
array

15.1.7. .spec.listeners[]

설명
리스너는 게이트웨이가 네트워크 연결을 수락하는 논리 끝점의 개념을 나타냅니다.
유형
object
필수 항목
  • name
  • port
  • 프로토콜
Expand
속성유형설명

allowedRoutes

object

AllowedRoutes는 Listener에 연결할 수 있는 경로 유형과 해당 Route 리소스가 있을 수 있는 신뢰할 수 있는 네임스페이스를 정의합니다.

클라이언트 요청이 여러 경로 규칙과 일치할 수 있지만 하나의 규칙만 궁극적으로 요청을 수신할 수 있습니다. 일치하는 우선순위는 다음 기준의 순서대로 결정되어야 합니다.

경로 유형에서 정의한 가장 구체적인 일치입니다. * 생성 타임스탬프를 기반으로 하는 가장 오래된 경로입니다. 예를 들어 "2020-09-08 01:02:03" 생성 타임스탬프가 있는 경로의 생성 타임스탬프가 "2020-09-08 01:02:04"인 경로보다 우선합니다. * 다른 모든 항목이 동일한 경우 경로는 알파벳순(네임스페이스/이름)으로 먼저 표시됩니다. 예를 들어 foo/bar는 foo/baz보다 우선합니다.

이 Listener에 연결된 경로 내의 모든 유효한 규칙을 구현해야 합니다. 잘못된 경로 규칙을 무시할 수 있습니다(때로 전체 경로를 의미합니다). 경로 규칙이 유효하지 않은 상태로 전환되는 경우 일관성을 보장하기 위해 해당 경로 규칙에 대한 지원을 삭제해야 합니다. 예를 들어 경로 규칙에 의해 지정된 필터가 유효하지 않은 경우에도 해당 경로 내의 나머지 규칙을 계속 지원해야 합니다.

지원: Core

hostname

string

hostname은 이 개념을 정의하는 프로토콜 유형에 대해 일치시킬 가상 호스트 이름을 지정합니다. 지정되지 않은 경우 모든 호스트 이름이 일치합니다. 이 필드는 호스트 이름 기반 일치가 필요하지 않은 프로토콜에 대해 무시됩니다.

구현은 다음 프로토콜 각각에 적절하게 일치하는 Hostname을 적용해야 합니다.

* TLS: 리스너 호스트 이름은 SNI와 일치해야 합니다. * HTTP: 리스너 호스트 이름은 요청의 Host 헤더와 일치해야 합니다. * HTTPS: 리스너 호스트 이름은 SNI 및 Host 헤더와 일치해야 합니다. SNI 및 Host 헤더가 같을 필요는 없습니다. 이에 대한 의미 체계는 아래에 자세히 설명되어 있습니다.

보안을 보장하기 위해 RFC-6066 섹션 11.1은 SNI 호스트 이름 일치에 의존하는 서버 구현도 애플리케이션 프로토콜 내의 호스트 이름도 확인해야 함을 강조합니다.

RFC-7540 섹션 9.1.2는 서버가 HTTP 421 Misdirected Request 상태 코드로 응답하여 연결 재사용을 거부할 수 있는 메커니즘을 제공합니다. 이는 원본 서버가 잘못 리디렉션된 것처럼 보이므로 오리진 서버가 요청을 거부했음을 나타냅니다.

잘못 리디렉션된 요청을 감지하려면 게이트웨이가 동일한 포트 및 프로토콜의 모든 Gateway Listeners에 구성된 모든 SNI 호스트 이름을 가진 요청 권한과 일치해야 합니다.

* 다른 Listener에 정확히 일치하는 와일드카드 항목이 있는 경우 게이트웨이는 421을 반환합니다. * ClientHello에서 선택한 현재 Listener가 Host: * 다른 Listener가 호스트와 일치하는 경우 게이트웨이 SHOULD는 421을 반환합니다. * 다른 리스너가 호스트와 일치하지 않는 경우 게이트웨이는 404를 반환해야 합니다.

HTTPRoute 및 TLSRoute 리소스의 경우 spec.hostnames 어레이와 상호 작용합니다. 리스너와 경로 모두 호스트 이름을 지정하는 경우 경로 허용의 값 사이에 교집합이 있어야 합니다. 자세한 내용은 경로별 호스트 이름 설명서를 참조하십시오.

와일드카드 레이블(*.) 접두사가 붙은 호스트 이름은 접미사 일치로 해석됩니다. 즉, *. example.com 에 대한 일치는 test.example.comfoo.test.example.com 과 일치하지만 example.com은 일치하지 않습니다.

지원: Core

name

string

name은 Listener의 이름입니다. 이 이름은 게이트웨이 내에서 고유해야 합니다.

지원: Core

port

integer

port는 네트워크 포트입니다. Listener 호환성 규칙에 따라 여러 리스너가 동일한 포트를 사용할 수 있습니다.

지원: Core

프로토콜

string

protocol은 이 리스너가 수신할 것으로 예상되는 네트워크 프로토콜을 지정합니다.

지원: Core

tls

object

TLS는 Listener의 TLS 구성입니다. Protocol 필드가 "HTTPS" 또는 "TLS"인 경우 이 필드가 필요합니다. Protocol 필드가 "HTTP", "TCP" 또는 "UDP"인 경우 이 필드를 설정하는 것은 유효하지 않습니다.

GatewayTLSConfig에 정의된 SNI와 인증서 연결은 이 리스너의 Hostname 필드를 기반으로 정의됩니다.

GatewayClass는 모든 TLS 핸드셰이크에 사용 가능한 모든 인증서 중 가장 긴 일치 SNI를 사용해야 합니다.

지원: Core

15.1.8. .spec.listeners[].allowedRoutes

설명

AllowedRoutes는 Listener에 연결할 수 있는 경로 유형과 해당 Route 리소스가 있을 수 있는 신뢰할 수 있는 네임스페이스를 정의합니다.

클라이언트 요청이 여러 경로 규칙과 일치할 수 있지만 하나의 규칙만 궁극적으로 요청을 수신할 수 있습니다. 일치하는 우선순위는 다음 기준의 순서대로 결정되어야 합니다.

  • 경로 유형에서 정의한 가장 구체적인 일치입니다.
  • 생성 타임스탬프를 기반으로 하는 가장 오래된 경로입니다. 예를 들어 "2020-09-08 01:02:03" 생성 타임스탬프가 있는 경로의 생성 타임스탬프가 "2020-09-08 01:02:04"인 경로보다 우선합니다.
  • 다른 모든 항목이 동일한 경우 경로 앞에 알파벳순(네임스페이스/이름)이 지정되어야 합니다. 예를 들어 foo/bar는 foo/baz보다 우선합니다.

이 Listener에 연결된 경로 내의 모든 유효한 규칙을 구현해야 합니다. 잘못된 경로 규칙을 무시할 수 있습니다(때로 전체 경로를 의미합니다). 경로 규칙이 유효하지 않은 상태로 전환되는 경우 일관성을 보장하기 위해 해당 경로 규칙에 대한 지원을 삭제해야 합니다. 예를 들어 경로 규칙에 의해 지정된 필터가 유효하지 않은 경우에도 해당 경로 내의 나머지 규칙을 계속 지원해야 합니다.

지원: Core

유형
object
Expand
속성유형설명

kinds

array

kinds은 이 게이트웨이 리스너에 바인딩할 수 있는 경로의 그룹 및 종류를 지정합니다. 지정되지 않았거나 비어 있으면 선택한 경로의 종류가 Listener 프로토콜을 사용하여 결정됩니다.

RouteGroupKind는 Listener의 프로토콜 필드에 지정된 애플리케이션 프로토콜과 호환되는 경로의 종류와 일치해야 합니다. 구현에서 이 리소스 유형을 지원하거나 인식하지 못하는 경우 "ResolvedRefs" 조건을 "InvalidRouteKinds" 이유와 함께 False로 설정해야 합니다.

지원: Core

kinds[]

object

RouteGroupKind는 경로 리소스의 그룹 및 종류를 나타냅니다.

네임스페이스

object

네임스페이스는 경로가 이 리스너에 연결될 수 있는 네임스페이스를 나타냅니다. 이는 기본적으로 이 게이트웨이의 네임스페이스로 제한됩니다.

지원: Core

15.1.9. .spec.listeners[].allowedRoutes.kinds

설명

kinds은 이 게이트웨이 리스너에 바인딩할 수 있는 경로의 그룹 및 종류를 지정합니다. 지정되지 않았거나 비어 있으면 선택한 경로의 종류가 Listener 프로토콜을 사용하여 결정됩니다.

RouteGroupKind는 Listener의 프로토콜 필드에 지정된 애플리케이션 프로토콜과 호환되는 경로의 종류와 일치해야 합니다. 구현에서 이 리소스 유형을 지원하거나 인식하지 못하는 경우 "ResolvedRefs" 조건을 "InvalidRouteKinds" 이유와 함께 False로 설정해야 합니다.

지원: Core

유형
array

15.1.10. .spec.listeners[].allowedRoutes.kinds[]

설명
RouteGroupKind는 경로 리소스의 그룹 및 종류를 나타냅니다.
유형
object
필수 항목
  • kind
Expand
속성유형설명

group

string

group은 경로의 그룹입니다.

kind

string

kind는 경로의 종류입니다.

15.1.11. .spec.listeners[].allowedRoutes.namespaces

설명

네임스페이스는 경로가 이 리스너에 연결될 수 있는 네임스페이스를 나타냅니다. 이는 기본적으로 이 게이트웨이의 네임스페이스로 제한됩니다.

지원: Core

유형
object
Expand
속성유형설명

from

string

from은 이 게이트웨이에 대해 경로가 선택됨을 나타냅니다. 가능한 값은 다음과 같습니다.

* all: 모든 네임스페이스의 경로는 이 게이트웨이에서 사용할 수 있습니다. * selector: 선택기에서 선택한 네임스페이스의 경로는 이 게이트웨이에서 사용할 수 있습니다. *동일한: 이 게이트웨이에서 동일한 네임스페이스의 경로만 사용할 수 있습니다.

지원: Core

선택기

object

선택기는 From이 "Selector"로 설정된 경우 지정해야 합니다. 이 경우 이 Selector와 일치하는 네임스페이스의 경로만 이 게이트웨이에서 선택됩니다. 이 필드는 "From"의 다른 값에 대해 무시됩니다.

지원: Core

15.1.12. .spec.listeners[].allowedRoutes.namespaces.selector

설명

선택기는 From이 "Selector"로 설정된 경우 지정해야 합니다. 이 경우 이 Selector와 일치하는 네임스페이스의 경로만 이 게이트웨이에서 선택됩니다. 이 필드는 "From"의 다른 값에 대해 무시됩니다.

지원: 코어

유형
object
Expand
재산유형설명

matchExpressions

array

matchExpressions는 레이블 선택기 요구 사항 목록입니다. 요구 사항은 AND로 처리됩니다.

matchExpressions[]

object

레이블 선택기 요구 사항은 값, 키, 그리고 키와 값을 연결하는 연산자를 포함하는 선택기입니다.

matchLabels

객체(문자열)

matchLabels는 {key,value} 쌍의 맵입니다. matchLabels 맵의 단일 {key,value}는 matchExpressions의 요소와 동일합니다. 여기서 키 필드는 "key"이고, 연산자는 "In"이며, 값 배열에는 "value"만 포함됩니다. 요구 사항은 AND로 처리됩니다.

15.1.13. .spec.listeners[].allowedRoutes.namespaces.selector.matchExpressions

설명
matchExpressions는 레이블 선택기 요구 사항 목록입니다. 요구 사항은 AND로 처리됩니다.
유형
array

15.1.14. .spec.listeners[].allowedRoutes.namespaces.selector.matchExpressions[]

설명
레이블 선택기 요구 사항은 값, 키, 그리고 키와 값을 연결하는 연산자를 포함하는 선택기입니다.
유형
object
필수 항목
  • key
  • operator
Expand
재산유형설명

key

string

키는 선택자가 적용되는 레이블 키입니다.

operator

string

연산자는 키와 값의 관계를 나타냅니다. 유효한 연산자는 In, NotIn, Exists 및 DoesNotExist입니다.

가치

배열(문자열)

값은 문자열 값의 배열입니다. 연산자가 In 또는 NotIn인 경우, 값 배열은 비어 있으면 안 됩니다. 연산자가 Exists 또는 DoesNotExist인 경우, 값 배열은 비어 있어야 합니다. 이 배열은 전략적 병합 패치 중에 교체됩니다.

15.1.15. .spec.listeners[].tls

설명

TLS는 리스너에 대한 TLS 구성입니다. 프로토콜 필드가 "HTTPS" 또는 "TLS"인 경우 이 필드는 필수입니다. 프로토콜 필드가 "HTTP", "TCP" 또는 "UDP"인 경우 이 필드를 설정할 수 없습니다.

GatewayTLSConfig에 정의된 인증서에 대한 SNI 연결은 이 리스너의 호스트 이름 필드를 기반으로 정의됩니다.

GatewayClass는 모든 TLS 핸드셰이크에 대해 사용 가능한 모든 인증서 중에서 가장 긴 일치 SNI를 사용해야 합니다.

지원: 코어

유형
object
Expand
재산유형설명

certificateRefs

array

CertificateRefs에는 TLS 인증서와 개인 키가 포함된 Kubernetes 개체에 대한 일련의 참조가 포함되어 있습니다. 이러한 인증서는 연관된 리스너의 호스트 이름과 일치하는 요청에 대한 TLS 핸드셰이크를 설정하는 데 사용됩니다.

Kubernetes Secret에 대한 단일 CertificateRef에는 "Core" 지원이 있습니다. 구현에서는 리스너에 여러 인증서를 첨부하도록 선택할 수 있지만, 이러한 동작은 구현에 따라 다릅니다.

대상 네임스페이스에 인증서를 첨부할 수 있는 ReferenceGrant가 없는 한, 다른 네임스페이스의 리소스에 대한 참조는 유효하지 않습니다. ReferenceGrant가 이 참조를 허용하지 않으면 "ResolvedRefs" 조건은 "RefNotPermitted" 이유로 이 리스너에 대해 False로 설정되어야 합니다.

모드가 "종료"(기본값)로 설정된 경우 이 필드에는 최소한 하나의 요소가 있어야 하며, 그렇지 않은 경우에는 선택 사항입니다.

CertificateRefs는 표준 Kubernetes 리소스(예: Secret)나 구현에 맞는 사용자 정의 리소스를 참조할 수 있습니다.

지원: Core - kubernetes.io/tls 유형의 Kubernetes Secret에 대한 단일 참조

지원: 구현별(두 개 이상의 참조 또는 기타 리소스 유형)

certificateRefs[]

object

SecretObjectReference는 네임스페이스를 포함한 API 객체를 식별하며, 기본값은 Secret입니다.

API 객체는 클러스터에서 유효해야 하며, 이 참조가 유효하려면 그룹과 종류가 클러스터에 등록되어야 합니다.

잘못된 Group과 Kind가 있는 객체에 대한 참조는 유효하지 않으며, 포함 객체에 적절한 조건이 설정된 상태에서 구현에서 거부되어야 합니다.

mode

string

모드는 클라이언트가 시작한 TLS 세션에 대한 TLS 동작을 정의합니다. 가능한 모드는 두 가지가 있습니다.

- 종료: 다운스트림 클라이언트와 게이트웨이 간의 TLS 세션이 게이트웨이에서 종료됩니다. 이 모드에서는 certificateRefs 필드를 채우는 등의 방법으로 인증서를 지정해야 합니다. - 패스스루: TLS 세션은 게이트웨이에 의해 종료되지 않습니다. 이는 게이트웨이가 TLS 프로토콜의 ClientHello 메시지를 제외한 TLS 스트림을 해독할 수 없음을 의미합니다. 이 모드에서는 certificateRefs 필드가 무시됩니다.

지원: 코어

options

객체(문자열)

옵션은 각 구현에 대한 확장된 TLS 구성을 활성화하는 키/값 쌍의 목록입니다. 예를 들어, 최소 TLS 버전이나 지원되는 암호화 제품군을 구성합니다.

공통 키 세트는 나중에 API에서 정의될 수 있습니다. 모호성을 피하기 위해 구현별 정의는 example.com/my-custom-option 과 같이 도메인 접두사가 붙은 이름을 사용해야 합니다. 접두사가 없는 이름은 Gateway API에서 정의한 키 이름에만 사용됩니다.

지원: 구현별

15.1.16. .spec.listeners[].tls.certificateRefs

설명

CertificateRefs에는 TLS 인증서와 개인 키가 포함된 Kubernetes 개체에 대한 일련의 참조가 포함되어 있습니다. 이러한 인증서는 연관된 리스너의 호스트 이름과 일치하는 요청에 대한 TLS 핸드셰이크를 설정하는 데 사용됩니다.

Kubernetes Secret에 대한 단일 CertificateRef에는 "Core" 지원이 있습니다. 구현에서는 리스너에 여러 인증서를 첨부하도록 선택할 수 있지만, 이러한 동작은 구현에 따라 다릅니다.

대상 네임스페이스에 인증서를 첨부할 수 있는 ReferenceGrant가 없는 한, 다른 네임스페이스의 리소스에 대한 참조는 유효하지 않습니다. ReferenceGrant가 이 참조를 허용하지 않으면 "ResolvedRefs" 조건은 "RefNotPermitted" 이유로 이 리스너에 대해 False로 설정되어야 합니다.

모드가 "종료"(기본값)로 설정된 경우 이 필드에는 최소한 하나의 요소가 있어야 하며, 그렇지 않은 경우에는 선택 사항입니다.

CertificateRefs는 표준 Kubernetes 리소스(예: Secret)나 구현에 맞는 사용자 정의 리소스를 참조할 수 있습니다.

지원: Core - kubernetes.io/tls 유형의 Kubernetes Secret에 대한 단일 참조

지원: 구현별(두 개 이상의 참조 또는 기타 리소스 유형)

유형
array

15.1.17. .spec.listeners[].tls.certificateRefs[]

설명

SecretObjectReference는 네임스페이스를 포함한 API 객체를 식별하며, 기본값은 Secret입니다.

API 객체는 클러스터에서 유효해야 하며, 이 참조가 유효하려면 그룹과 종류가 클러스터에 등록되어야 합니다.

잘못된 Group과 Kind가 있는 객체에 대한 참조는 유효하지 않으며, 포함 객체에 적절한 조건이 설정된 상태에서 구현에서 거부되어야 합니다.

유형
object
필수 항목
  • name
Expand
재산유형설명

group

string

그룹은 참조 대상의 그룹입니다. 예를 들어, "gateway.networking.k8s.io". 지정되지 않았거나 빈 문자열인 경우 핵심 API 그룹이 유추됩니다.

kind

string

친절은 지시대상의 친절함입니다. 예를 들어 "비밀".

name

string

이름은 지시 대상의 이름입니다.

네임스페이스

string

네임스페이스는 참조된 객체의 네임스페이스입니다. 지정하지 않으면 로컬 네임스페이스가 유추됩니다.

로컬 네임스페이스와 다른 네임스페이스가 지정되면 해당 네임스페이스의 소유자가 참조를 수락할 수 있도록 참조 대상 네임스페이스에 ReferenceGrant 개체가 필요합니다. 자세한 내용은 ReferenceGrant 문서를 참조하세요.

지원: 코어

15.1.18. .status

설명
상태는 Gateway의 현재 상태를 정의합니다.
유형
object
Expand
재산유형설명

구애

array

주소는 게이트웨이에 바인딩된 네트워크 주소를 나열합니다.

다음과 같은 조건에 따라 이 목록은 사양에 제공된 주소와 다를 수 있습니다.

* 주소가 지정되지 않음, 모든 주소는 동적으로 할당됨 * 지정된 주소와 동적 주소의 조합이 할당됨 * 지정된 주소가 사용할 수 없음(예: 이미 사용 중)

addresses[]

object

GatewayStatusAddress는 Gateway에 바인딩된 네트워크 주소를 설명합니다.

conditions

array

조건은 게이트웨이의 현재 조건을 설명합니다.

구현에서는 GatewayConditionTypeGatewayConditionReason 상수를 사용하여 Gateway 조건을 표현하는 것이 좋습니다. 이렇게 하면 연산자와 도구가 Gateway 상태를 설명하기 위해 공통 어휘로 수렴할 수 있습니다.

알려진 조건 유형은 다음과 같습니다.

* "승인됨" * "프로그래밍됨" * "준비됨"

conditions[]

object

조건에는 이 API 리소스의 현재 상태의 한 측면에 대한 세부 정보가 포함되어 있습니다.

청취자

array

리스너는 사양에 정의된 각 고유 리스너 포트에 대한 상태를 제공합니다.

listeners[]

object

ListenerStatus는 Listener와 연관된 상태입니다.

15.1.19. .status.addresses

설명

주소는 게이트웨이에 바인딩된 네트워크 주소를 나열합니다.

다음과 같은 조건에 따라 이 목록은 사양에 제공된 주소와 다를 수 있습니다.

  • 주소가 지정되지 않으며 모든 주소는 동적으로 할당됩니다.
  • 지정된 주소와 동적 주소의 조합이 할당됩니다.
  • 지정된 주소가 사용할 수 없습니다(예: 이미 사용 중)
유형
array

15.1.20. .status.addresses[]

설명
GatewayStatusAddress는 게이트웨이에 바인딩된 네트워크 주소를 나타냅니다.
유형
object
필수 항목
  • value
Expand
속성유형설명

type

string

주소 유형입니다.

value

string

주소의 값입니다. 값의 유효성은 컨트롤러의 유형 및 지원에 따라 달라집니다.

예: 1.2.3.4,128::1,my-ip-address.

15.1.21. .status.conditions

설명

conditions는 게이트웨이의 현재 조건을 설명합니다.

구현은 GatewayConditionTypeGatewayConditionReason 상수를 사용하여 게이트웨이 조건을 표시하는 것을 선호하여 운영자와 툴이 게이트웨이 상태를 설명하기 위해 공통 용어에 통합할 수 있도록 해야 합니다.

알려진 조건 유형은 다음과 같습니다.

  • "허용됨"
  • "프로그래밍"
  • "ready"
유형
array

15.1.22. .status.conditions[]

설명
condition에는 이 API 리소스의 현재 상태에 대한 한 가지 측면에 대한 세부 정보가 포함되어 있습니다.
유형
object
필수 항목
  • lastTransitionTime
  • message
  • reason
  • status
  • type
Expand
속성유형설명

lastTransitionTime

string

lastTransitionTime은 마지막으로 한 상태에서 다른 상태로 전환된 시간입니다. 기본 조건이 변경된 경우여야 합니다. 이를 알 수 없는 경우 API 필드가 변경된 시간을 사용합니다.

message

string

message는 변환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지입니다. 빈 문자열일 수 있습니다.

observedGeneration

integer

observedGeneration은 조건에 따라 설정된 .metadata.generation을 나타냅니다. 예를 들어 .metadata.generation이 현재 12이지만 .status.conditions[x].observedGeneration이 9인 경우 현재 인스턴스 상태와 관련된 조건이 최신 상태가 아닙니다.

reason

string

이유에는 조건의 마지막 전환 이유를 나타내는 프로그래밍 식별자가 포함되어 있습니다. 특정 조건 유형의 생산자는 이 필드에 예상되는 값과 의미를 정의할 수 있으며 값이 보장된 API로 간주되는지 여부를 정의할 수 있습니다. 값은 CamelCase 문자열이어야 합니다. 이 필드는 비어 있지 않을 수 있습니다.

status

string

조건의 상태, True, False, 알 수 없음.

type

string

CamelCase 또는 foo.example.com/CamelCase의 조건 유형입니다.

15.1.23. .status.listeners

설명
리스너는 Spec에 정의된 각 고유 리스너 포트에 대한 상태를 제공합니다.
유형
array

15.1.24. .status.listeners[]

설명
ListenerStatus는 Listener와 연결된 상태입니다.
유형
object
필수 항목
  • attachedRoutes
  • conditions
  • name
  • 지원되는Kinds
Expand
속성유형설명

attachedRoutes

integer

AttachedRoutes는 이 Listener에 성공적으로 연결된 총 경로 수를 나타냅니다.

Listener로의 경로를 성공적으로 첨부하는 것은 해당 Listener 및 경로의 ParentRefs 필드의 AllowedRoutes 필드의 조합만을 기반으로 합니다. Listener의 AllowedRoutes 필드에서 선택한 Route가 Listener에 성공적으로 연결되고 경로에 전체 게이트웨이 리소스 또는 특정 Listener를 상위 리소스로 선택하는 유효한 ParentRef가 있습니다(연결 의미에 대한 자세한 내용은 다양한 경로 종류의 ParentRefs 필드에 대한 문서에서 찾을 수 있음). 리스너 또는 경로 상태는 성공적인 첨부 파일에 영향을 미치지 않습니다. 즉, AttachedRoutes 필드 수는 Accepted: false 조건이 있는 Listeners에 대해 설정되어야 하며, 사용자가 수락할 수 있는 성공적으로 연결된 경로를 계산해야 합니다: false 조건.

이 필드에는 경로 첨부 문제 해결 및 Listener에 대한 변경 사항의 마지막 반경/영향을 측정하는 작업이 포함됩니다.

conditions

array

conditions는 이 리스너의 현재 조건을 설명합니다.

conditions[]

object

condition에는 이 API 리소스의 현재 상태에 대한 한 가지 측면에 대한 세부 정보가 포함되어 있습니다.

name

string

name은 이 상태가 해당하는 Listener의 이름입니다.

지원되는Kinds

array

SupportedKinds는 이 리스너에서 지원하는 종류의 종류를 나타내는 목록입니다. 이 값은 구현에서 해당 Listener 구성에 대해 지원하는 종류를 표현해야 합니다.

지원되지 않는 Spec에 종류가 지정되면 이 목록에 표시되지 않아야 하며 구현은 "ResolvedRefs" 조건을 "False"로 설정해야 합니다. 유효한 경로 종류와 유효하지 않은 경로 종류를 모두 지정하면 구현에서 지정된 유효한 경로 종류를 참조해야 합니다.

supportedKinds[]

object

RouteGroupKind는 경로 리소스의 그룹 및 종류를 나타냅니다.

15.1.25. .status.listeners[].conditions

설명
conditions는 이 리스너의 현재 조건을 설명합니다.
유형
array

15.1.26. .status.listeners[].conditions[]

설명
condition에는 이 API 리소스의 현재 상태에 대한 한 가지 측면에 대한 세부 정보가 포함되어 있습니다.
유형
object
필수 항목
  • lastTransitionTime
  • message
  • reason
  • status
  • type
Expand
속성유형설명

lastTransitionTime

string

lastTransitionTime은 마지막으로 한 상태에서 다른 상태로 전환된 시간입니다. 기본 조건이 변경된 경우여야 합니다. 이를 알 수 없는 경우 API 필드가 변경된 시간을 사용합니다.

message

string

message는 변환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지입니다. 빈 문자열일 수 있습니다.

observedGeneration

integer

observedGeneration은 조건에 따라 설정된 .metadata.generation을 나타냅니다. 예를 들어 .metadata.generation이 현재 12이지만 .status.conditions[x].observedGeneration이 9인 경우 현재 인스턴스 상태와 관련된 조건이 최신 상태가 아닙니다.

reason

string

이유에는 조건의 마지막 전환 이유를 나타내는 프로그래밍 식별자가 포함되어 있습니다. 특정 조건 유형의 생산자는 이 필드에 예상되는 값과 의미를 정의할 수 있으며 값이 보장된 API로 간주되는지 여부를 정의할 수 있습니다. 값은 CamelCase 문자열이어야 합니다. 이 필드는 비어 있지 않을 수 있습니다.

status

string

조건의 상태, True, False, 알 수 없음.

type

string

CamelCase 또는 foo.example.com/CamelCase의 조건 유형입니다.

15.1.27. .status.listeners[].supportedKinds

설명

SupportedKinds는 이 리스너에서 지원하는 종류의 종류를 나타내는 목록입니다. 이 값은 구현에서 해당 Listener 구성에 대해 지원하는 종류를 표현해야 합니다.

지원되지 않는 Spec에 종류가 지정되면 이 목록에 표시되지 않아야 하며 구현은 "ResolvedRefs" 조건을 "False"로 설정해야 합니다. 유효한 경로 종류와 유효하지 않은 경로 종류를 모두 지정하면 구현에서 지정된 유효한 경로 종류를 참조해야 합니다.

유형
array

15.1.28. .status.listeners[].supportedKinds[]

설명
RouteGroupKind는 경로 리소스의 그룹 및 종류를 나타냅니다.
유형
object
필수 항목
  • kind
Expand
속성유형설명

group

string

group은 경로의 그룹입니다.

kind

string

kind는 경로의 종류입니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat