14장. GRPCRoute [gateway.networking.k8s.io/v1]

호스트 이름

배열(문자열)

호스트 이름은 GRPC Host 헤더와 일치시킬 호스트 이름 세트를 정의하여 요청을 처리할 GRPCRoute를 선택합니다. 이는 두 가지 주요 예외가 있는 호스트 이름의 RFC 1123 정의와 일치합니다.

1. IP는 허용되지 않습니다. 2. 호스트 이름 앞에 와일드카드 레이블(*.)이 붙일 수 있습니다. 와일드카드 레이블은 첫 번째 레이블로 직접 표시되어야 합니다.

호스트 이름이 Listener 및 GRPCRoute 모두에 의해 지정되면 GRPCRoute가 Listener에 연결되기 위해 하나 이상의 교차 호스트 이름이 있어야 합니다. 예를 들면 다음과 같습니다.

* 호스트 이름으로 test.example.com 이 있는 Listener는 호스트 이름을 지정하지 않았거나 test.example.com 또는 *.example.com 중 하나를 지정한 GRPCRoutes와 일치합니다. * 호스트 이름으로 *.example.com 이 있는 Listener는 호스트 이름을 지정하지 않았거나 Listener 호스트 이름과 일치하는 호스트 이름을 하나 이상 지정한 GRPCRoutes와 일치합니다. 예를 들어 test.example.com 및 \*.example.com 은 둘 다 일치합니다. 반면 example.com 및 test.example.net 이 일치하지 않습니다.

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

Listener와 GRPCRoute의 호스트 이름이 모두 지정된 경우 Listener 호스트 이름과 일치하지 않는 GRPCRoute 호스트 이름을 무시해야 합니다. 예를 들어 Listener가 *.example.com 을 지정하고 GRPCRoute 지정 test.example.com 및 test.example.net,test.example.net 이 일치하는 것으로 간주해서는 안 됩니다.

Listener와 GRPCRoute 둘 다 호스트 이름을 지정하고 위의 기준과 일치하지 않는 경우 구현 시 GRPCRoute를 수락해서는 안 됩니다. 구현은 RouteParentStatus에서 False 상태로 'Accepted' 조건을 제기해야 합니다.

HTTPRoute 또는 GRPCRoute 유형의 경로(A)가 Listener에 연결되어 있고 해당 리스너에 연결된 다른 경로(B)가 이미 연결되어 있고 호스트 이름과 B의 교집합이 비어 있지 않은 경우 구현은 다음 기준에 따라 결정되는 이 두 경로 중 하나를 정확히 수락해야 합니다.

* 생성 타임스탬프를 기반으로 하는 가장 오래된 경로입니다. * "{namespace}/{name}"에 의해 알파벳순으로 먼저 나타나는 경로.

거부된 경로는 해당 RouteParentStatus에서 'False' 상태로 'Accepted' 조건을 제기해야 합니다.

지원: Core

parentRefs

array

ParentRefs는 경로를 연결하려는 리소스(일반적으로 게이트웨이)를 참조합니다. 참조된 상위 리소스는 이 경우 첨부 파일이 완료될 수 있도록 허용해야 합니다. 게이트웨이의 경우 게이트웨이는 이 종류 및 네임스페이스의 경로에서 연결을 허용해야 함을 의미합니다. 서비스의 경우 서비스는 "producer" 경로에 대해 동일한 네임스페이스에 있거나 메시 구현에서 참조된 서비스에 대한 "소유자" 경로를 지원하고 허용해야 함을 의미합니다. ReferenceGrant는 서비스에 대한 상위 참조 관리에는 적용되지 않습니다 - 경로와 다른 네임스페이스에서 서비스에 대한 "생성자" 경로를 생성할 수 없습니다.

"Core" 지원이 포함된 두 가지 종류의 상위 리소스가 있습니다.

* 게이트웨이 (Gateway 적합성 프로파일) * 서비스 (Mesh 적합성 프로파일, ClusterIP 서비스 만 해당)

이 API는 나중에 추가 종류의 상위 리소스를 지원하도록 확장될 수 있습니다.

parentRef는 구별 되어야 합니다. 즉, 다음과 같습니다.

* 다양한 개체를 선택합니다. 이 경우 parentRef 항목이 구분됩니다. 필드 측면에서 이는 그룹,종류,네임스페이스, name 으로 정의된 다중 파트 키가 경로의 모든 parentRef 항목에서 고유해야 함을 의미합니다. * 서로 다른 오브젝트를 선택하지 않지만, 사용된 각 선택적 필드에 대해 동일한 오브젝트를 선택하는 각 parentRef는 동일한 선택적 필드 세트를 다른 값으로 설정해야 합니다. 하나의 ParentRef가 선택적 필드의 조합을 설정하는 경우 모두 동일한 조합을 설정해야 합니다.

몇 가지 예:

* 하나의 ParentRef가 sectionName 을 설정하는 경우 동일한 오브젝트를 참조하는 모든 ParentRefs도 sectionName 을 설정해야 합니다. * 하나의 ParentRef가 포트 를 설정하는 경우 동일한 오브젝트를 참조하는 모든 ParentRefs도 포트 를 설정해야 합니다. * 하나의 ParentRef가 sectionName 및 port 를 설정하는 경우 동일한 오브젝트를 참조하는 모든 ParentRefs도 sectionName 및 port 를 설정해야 합니다.

구현에 의해 축소될 수 있는 여러 개의 개별 개체를 별도로 참조할 수 있습니다. 예를 들어 일부 구현에서는 호환 가능한 게이트웨이 수신기를 함께 병합하도록 선택할 수 있습니다. 이 경우 해당 리소스에 연결된 경로 목록도 병합해야 합니다.

parentRefs의 경우 네임스페이스 경계를 통한 특정 규칙이 있습니다. 네임스페이스 간 참조는 참조하는 네임스페이스의 항목에서 명시적으로 허용되는 경우에만 유효합니다. 예를 들어 게이트웨이에는 AllowedRoutes 필드가 있으며 ReferenceGrant는 다른 종류의 네임스페이스를 사용할 수 있는 일반적인 방법을 제공합니다.

parentRefs[]

object

ParentReference는 이 리소스의 상위(일반적으로 경로)로 간주할 수 있는 API 오브젝트(일반적으로 게이트웨이)를 식별합니다. "Core" 지원이 포함된 두 가지 종류의 상위 리소스가 있습니다.

* 게이트웨이 (Gateway 적합성 프로파일) * 서비스 (Mesh 적합성 프로파일, ClusterIP 서비스 만 해당)

이 API는 나중에 추가 종류의 상위 리소스를 지원하도록 확장될 수 있습니다.

API 오브젝트는 클러스터에서 유효해야 합니다. 이 참조가 유효하려면 Group 및 Kind를 클러스터에 등록해야 합니다.

규칙

array

규칙은 GRPC 일치자, 필터 및 작업의 목록입니다.

rules[]

object

GRPCRouteRule은 조건(matches), 처리(filters)를 기반으로 gRPC 요청을 일치시키고, 요청을 API 오브젝트(backendRefs)로 전달하기 위한 시맨틱을 정의합니다.

group

string

그룹은 참조 그룹의 그룹입니다. 지정되지 않은 경우 "gateway.networking.k8s.io"가 유추됩니다. 코어 API 그룹(예: "Service" kind referent의 경우)을 설정하려면 그룹을 명시적으로 ""(빈 문자열)로 설정해야 합니다.

지원: Core

kind

string

이는 일종의 참조입니다.

"Core" 지원이 포함된 두 가지 종류의 상위 리소스가 있습니다.

* 게이트웨이 (Gateway 적합성 프로파일) * 서비스 (Mesh 적합성 프로파일, ClusterIP 서비스 만 해당)

다른 리소스에 대한 지원은 Implementation-Specific입니다.

name

string

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

지원: Core

네임스페이스

string

네임스페이스는 참조의 네임스페이스입니다. 지정되지 않은 경우 경로의 로컬 네임스페이스를 나타냅니다.

네임스페이스 경계를 통과하는 ParentRefs에 대한 특정 규칙이 있습니다. 네임스페이스 간 참조는 참조하는 네임스페이스의 항목에서 명시적으로 허용되는 경우에만 유효합니다. 예를 들어 게이트웨이에는 AllowedRoutes 필드가 있으며 ReferenceGrant는 다른 종류의 네임스페이스를 활성화하는 일반적인 방법을 제공합니다.

지원: Core

port

integer

port는 이 경로가 대상으로 하는 네트워크 포트입니다. 상위 리소스 유형에 따라 다르게 해석될 수 있습니다.

상위 리소스가 게이트웨이인 경우 이러한 종류의 경로도 지원하는 지정된 포트에서 수신 대기 중인 모든 리스너를 대상으로 하고 이 경로를 선택합니다. 경로에 지정된 네트워킹 동작을 포트를 변경할 수 있는 리스너와 달리 특정 포트에 적용해야 하는 경우를 제외하고 Port 를 설정하지 않는 것이 좋습니다. Port 및 sectionName을 둘 다 지정하면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다.

구현은 다른 상위 리소스를 지원하도록 선택할 수 있습니다. 다른 유형의 상위 리소스를 지원하는 구현은 Port가 해석되는 방법을 명확하게 문서화해야 합니다.

상태를 위해 상위 리소스에서 부분적으로 수락하면 첨부 파일이 성공한 것으로 간주됩니다. 예를 들어 게이트웨이 리스너는 경로 종류, 네임스페이스 또는 호스트 이름을 통해 연결할 수 있는 경로를 제한할 수 있습니다. 2개 중 1개의 게이트웨이 리스너가 참조 경로의 첨부 파일을 수락하는 경우 경로는 성공적으로 연결된 것으로 간주해야 합니다. 게이트웨이 리스너가 이 경로의 첨부 파일을 수락하지 않으면 게이트웨이에서 경로를 분리하는 것으로 간주해야 합니다.

지원: 확장

sectionName

string

sectionName은 대상 리소스에 있는 섹션의 이름입니다. 다음 리소스에서 sectionName은 다음과 같이 해석됩니다.

* 게이트웨이: 리스너 이름입니다. Port(experimental) 및 sectionName이 모두 지정되면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다. * 서비스: 포트 이름입니다. Port(experimental) 및 sectionName이 모두 지정되면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다.

구현은 다른 리소스에 경로 연결을 지원하도록 선택할 수 있습니다. 이 경우 sectionName을 해석하는 방법을 명확하게 문서화해야 합니다.

지정되지 않은 경우(빈 문자열) 전체 리소스를 참조합니다. 상태의 목적을 위해 부모 리소스의 하나 이상의 섹션에서 이를 수락하는 경우 첨부 파일이 성공한 것으로 간주됩니다. 예를 들어 게이트웨이 리스너는 경로 종류, 네임스페이스 또는 호스트 이름을 통해 연결할 수 있는 경로를 제한할 수 있습니다. 2개 중 1개의 게이트웨이 리스너가 참조 경로의 첨부 파일을 수락하는 경우 경로는 성공적으로 연결된 것으로 간주해야 합니다. 게이트웨이 리스너가 이 경로의 첨부 파일을 수락하지 않으면 게이트웨이에서 경로를 분리하는 것으로 간주해야 합니다.

지원: Core

backendRefs

array

BackendRefs는 일치하는 요청을 보내야 하는 백엔드를 정의합니다.

여기에서 실패 동작은 지정된 BackendRef 수와 유효하지 않은 횟수에 따라 달라집니다.

BackendRefs의 모든 항목이 유효하지 않고 이 경로 규칙에 지정된 필터도 없는 경우 이 규칙과 일치하는 모든 트래픽은 UNAVAILABLE 상태를 받아야 합니다.

GRPCBackendRef 단일 GRPCBackendRef를 만드는 방법에 대한 규칙은 GRPCBackendRef 정의를 참조하십시오.

GRPCBackendRef가 유효하지 않으면 잘못된 백엔드로 라우팅된 요청에 대해 UNAVAILABLE 상태를 반환해야 합니다. 여러 백엔드가 지정되고 일부는 유효하지 않은 경우, 그렇지 않으면 잘못된 백엔드로 라우팅된 요청 비율이 UNAVAILABLE 상태를 받아야 합니다.

예를 들어 두 백엔드가 동일한 가중치로 지정되고 하나는 유효하지 않은 경우 트래픽의 50%는 UNAVAILABLE 상태를 수신해야 합니다. 구현은 50%를 결정하는 방법을 선택할 수 있습니다.

지원: Kubernetes 서비스 코어

지원: 다른 리소스에 대한 구현별

가중치 지원: Core

backendRefs[]

object

GRPCBackendRef는 GRPCRoute가 gRPC 요청을 전달하는 방법을 정의합니다.

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

filters

array

필터는 이 규칙과 일치하는 요청에 적용되는 필터를 정의합니다.

여러 동작의 순서를 지정하는 영향은 현재 지정되지 않습니다. 이는 알파 단계의 피드백에 따라 향후 변경될 수 있습니다.

이 수준의 적합성 수준은 필터 유형에 따라 정의됩니다.

- All core filters must be supported by all implementations that support GRPCRoute. - 구현자는 확장 필터를 지원하는 것이 좋습니다. - 구현별 사용자 지정 필터에는 구현에 API가 보장되지 않습니다.

필터에 명시적으로 표시되지 않는 한 동일한 필터를 여러 번 지정하는 것은 지원되지 않습니다.

구현에서 필터 조합을 지원할 수 없는 경우 해당 제한을 명확하게 문서화해야 합니다. 호환되지 않거나 지원되지 않는 필터가 지정되고 Accepted 조건이 False 상태로 설정되는 경우 구현에서 IncompatibleFilters 이유를 사용하여 이 구성 오류를 지정할 수 있습니다.

지원: Core

filters[]

object

GRPCRouteFilter는 요청 또는 응답 라이프사이클 중에 완료해야 하는 처리 단계를 정의합니다. GRPCRouteFilters는 게이트웨이 구현에서 수행할 수 있는 처리를 나타내는 확장 지점입니다. 일부 예로는 요청 또는 응답 수정, 인증 전략 구현, 속도 제한 및 트래픽 형성이 포함됩니다. API Guarantee/conformance는 필터 유형에 따라 정의됩니다.

일치

array

matches는 들어오는 gRPC 요청과 대조되는 규칙과 일치하는 데 사용되는 조건을 정의합니다. 일치 항목이 독립적입니다. 즉, 일치 항목 중 하나가 충족되면 이 규칙이 일치합니다.

예를 들어 다음과 같은 구성이 일치하도록 합니다.

matches: - method: service: foo.bar headers: values: version: 2 - method: service: foo.bar.v2

이 규칙에 대한 요청이 일치하려면 다음 두 조건 중 EITHER를 충족해야 합니다.

- foo.bar의 서비스 및 헤더 버전을 포함합니다: 2 - foo.bar.v2의 서비스

ANDed할 여러 일치 조건을 지정하는 방법은 GRPCRouteMatch에 대한 설명서를 참조하십시오.

일치하는 항목이 없는 경우 구현이 모든 gRPC 요청과 일치해야 합니다.

GRPCRoutes에서 생성된 프록시 또는 로드 밸런서 라우팅 구성은 다음 기준에 따라 우선 순위를 정하고 연결 상태를 유지해야 합니다. GRPCRoutes와 HTTPRoutes 간에 병합해서는 안 됩니다. 다음 중 가장 큰 수를 가진 규칙에 우선순위를 부여해야 합니다.

일치하는 와일드카드 호스트 이름의 문자입니다. 일치하는 호스트 이름의 문자입니다. 일치하는 서비스의 문자입니다. 일치하는 메서드의 문자입니다. * 헤더 일치.

여러 경로에 걸쳐 연결이 여전히 존재하는 경우 일치하는 우선순위는 다음 기준의 순서대로 결정되어야 하며 연결에서 계속해야 합니다.

* 생성 타임스탬프를 기반으로 하는 가장 오래된 경로입니다. * "{namespace}/{name}"에 의해 알파벳순으로 먼저 나타나는 경로.

우선 순위가 지정된 경로 내에 관계가 있는 경우 위의 기준을 충족하는 첫 번째 일치 규칙에 일치하는 우선순위를 부여해야 합니다.

matches[]

object

GRPCRouteMatch는 지정된 작업에 요청을 일치시키는 데 사용되는 서술자를 정의합니다. 여러 일치 유형이 함께 ANDed됩니다. 즉, 모든 조건이 충족되는 경우에만 일치가 true로 평가됩니다.

예를 들어 아래 일치 항목은 서비스가 foo 이고 version: v1 헤더가 포함된 경우에만 gRPC 요청과 일치합니다.

matches: - method: type: Exact service: "foo" headers: - name: "version" value "v1"

filters

array

이 수준에서 정의된 필터는 요청이 여기에 정의된 백엔드로 전달되는 경우에만 실행해야 합니다.

지원: 구현에 따라 (필터의 광범위한 지원을 위해 GRPCRouteRule의 Filters 필드를 사용하십시오.)

filters[]

object

GRPCRouteFilter는 요청 또는 응답 라이프사이클 중에 완료해야 하는 처리 단계를 정의합니다. GRPCRouteFilters는 게이트웨이 구현에서 수행할 수 있는 처리를 나타내는 확장 지점입니다. 일부 예로는 요청 또는 응답 수정, 인증 전략 구현, 속도 제한 및 트래픽 형성이 포함됩니다. API Guarantee/conformance는 필터 유형에 따라 정의됩니다.

group

string

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

kind

string

kind는 참조의 Kubernetes 리소스 유형입니다. 예: "Service".

지정하지 않는 경우 기본값은 "Service"입니다.

ExternalName 서비스는 클러스터 외부에 있을 수 있는 CNAME DNS 레코드를 참조할 수 있으므로 적합성 측면에서 이유하기가 어렵습니다. 또한 안전하게 전달하지 못할 수도 있습니다(자세한 내용은 CVE-2021-25740 참조). 구현은 ExternalName 서비스를 지원하지 않아야 합니다.

지원: Core (ExternalName 이외의 유형이 있는 서비스)

지원: 구현별 ( ExternalName 유형의 서비스)

name

string

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

네임스페이스

string

네임스페이스는 백엔드의 네임스페이스입니다. 지정하지 않으면 로컬 네임스페이스가 유추됩니다.

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

지원: Core

port

integer

port는 이 리소스에 사용할 대상 포트 번호를 지정합니다. 참조가 Kubernetes 서비스인 경우 포트가 필요합니다. 이 경우 포트 번호는 대상 포트가 아닌 서비스 포트 번호입니다. 기타 리소스의 경우 대상 포트가 참조 리소스 또는 이 필드에서 파생될 수 있습니다.

weight

integer

weight는 참조된 백엔드로 전달된 요청 비율을 지정합니다. 이 값은 weight/(이 BackendRefs 목록의 모든 가중치 합계)로 계산됩니다. 0이 아닌 값의 경우 구현에서 지원하는 전체 범위에 따라 여기에 정의된 정확한 비율에서 몇 가지 epsilon이 있을 수 있습니다.For non-zero values, there may be some epsilon from the exact proportion defined here depending on the precision an implementation supports. weight는 백분율이 아니며 가중치 합계는 100과 같을 필요가 없습니다.

하나의 백엔드만 지정되고 가중치가 0보다 크면 트래픽의 100%가 해당 백엔드로 전달됩니다. weight가 0으로 설정된 경우 이 항목에 대해 트래픽을 전달하지 않아야 합니다. 지정되지 않은 경우 weight는 기본적으로 1입니다.

이 필드에 대한 지원은 사용되는 컨텍스트에 따라 다릅니다.

extensionRef

object

ExtensionRef는 "필터" 동작에 대한 구현별 선택적 확장입니다. 예를 들어 "networking.example.net" 그룹의 리소스 "myroutefilter". ExtensionRef는 코어 및 확장 필터에는 사용해서는 안 됩니다.

지원: 구현별

이 필터는 동일한 규칙 내에서 여러 번 사용할 수 있습니다.

requestHeaderModifier

object

RequestHeaderModifier는 요청 헤더를 수정하는 필터의 스키마를 정의합니다.

지원: Core

requestMirror

object

RequestMirror는 요청을 미러링하는 필터의 스키마를 정의합니다. 요청은 지정된 대상으로 전송되지만 해당 대상의 응답은 무시됩니다.

이 필터는 동일한 규칙 내에서 여러 번 사용할 수 있습니다. 모든 구현이 여러 백엔드에 대한 미러링을 지원할 수 있는 것은 아닙니다.

지원: 확장

responseHeaderModifier

object

ResponseHeaderModifier는 응답 헤더를 수정하는 필터의 스키마를 정의합니다.

지원: 확장

type

string

type은 적용할 필터 유형을 식별합니다. 다른 API 필드와 마찬가지로 유형은 세 가지 적합성 수준으로 분류됩니다.

- core: 이 패키지의 "Support: Core"에서 정의한 유형과 해당 구성을 필터링합니다. 예를 들면 다음과 같습니다. "RequestHeaderModifier". GRPCRoute를 지원하는 모든 구현에서는 핵심 필터를 지원해야 합니다.

- Extended: 이 패키지의 "Support: Extended"에 의해 정의된 필터 유형 및 해당 구성, 예를 들면 다음과 같습니다. "RequestMirror". 구현자는 확장 필터를 지원하는 것이 좋습니다.

- 구현별: 특정 공급업체에서 정의하고 지원하는 필터입니다. 향후 여러 구현에 걸쳐 동작에 융합되는 필터가 확장 또는 핵심 적합성 수준에 포함되는 것으로 간주됩니다. 이러한 필터에 대한 필터별 구성은 ExtensionRef 필드를 사용하여 지정됩니다. 사용자 지정 필터에 대해 Type 을 "ExtensionRef"로 설정해야 합니다.

구현자는 구현별 동작을 사용하여 코어 API를 확장하기 위해 사용자 지정 구현 유형을 정의하는 것이 좋습니다.

사용자 지정 필터 유형에 대한 참조를 확인할 수 없는 경우 필터를 건너뛰지 않아야 합니다. 대신 해당 필터로 처리된 요청은 HTTP 오류 응답을 받아야 합니다.

group

string

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

kind

string

이는 일종의 참조입니다. 예: "HTTPRoute" 또는 "Service".

name

string

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

add

array

Add는 작업 전에 지정된 헤더(이름, 값)를 요청에 추가합니다. 헤더 이름과 연결된 기존 값에 추가됩니다.

input: GET /foo HTTP/1.1 my-header: foo

config: add: - name: "my-header" 값: "bar,baz"

출력: GET /foo HTTP/1.1 my-header: foo,bar,baz

add[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

제거

배열(문자열)

작업 전에 HTTP 요청에서 지정된 헤더를 제거합니다. Remove 값은 HTTP 헤더 이름 목록입니다. 헤더 이름은 대소문자를 구분하지 않습니다( https://datatracker.ietf.org/doc/html/rfc2616#section-4.2참조).

입력: GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

config: remove: ["my-header1", "my-header3"]

출력: GET /foo HTTP/1.1 my-header2: bar

set

array

set은 작업 전에 지정된 헤더(이름, 값)로 요청을 덮어씁니다.

input: GET /foo HTTP/1.1 my-header: foo

config: set: - name: "my-header" value: "bar"

출력: GET /foo HTTP/1.1 my-header: bar

set[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

backendRef

object

BackendRef는 미러링된 요청이 전송되는 리소스를 참조합니다.

미러링된 요청은 이 백엔드Ref 내에 있는 끝점 수에 관계없이 이 BackendRef 내의 단일 대상 끝점에만 전송되어야 합니다.

참조자를 찾을 수 없는 경우 이 BackendRef는 유효하지 않으며 게이트웨이에서 삭제해야 합니다. 컨트롤러는 경로 상태의 "ResolvedRefs" 조건이 status: False 로 설정되어 있고 기본 구현에서 이 백엔드를 구성하지 않는지 확인해야 합니다.

ReferenceGrant에서 허용하지 않는 기존 오브젝트에 대한 네임스페이스 간 참조가 있는 경우 컨트롤러는 경로의 "ResolvedRefs" 조건이 status: False 로 설정되어 있고 기본 구현에서 이 백엔드를 구성하지 않도록 해야 합니다.

두 경우 모두 ResolvedRefs Condition의 Message of the ResolvedRefs Condition을 사용하여 문제에 대한 자세한 정보를 제공해야 합니다.

지원: Kubernetes 서비스에 대한 확장

지원: 다른 리소스에 대한 구현별

분수

object

fraction는 BackendRef로 미러링해야 하는 요청의 일부를 나타냅니다.

Fraction 또는 Percent 중 하나만 지정할 수 있습니다. 둘 다 지정하지 않으면 요청의 100%가 미러링됩니다.

백분율

integer

percent는 BackendRef에 미러링해야 하는 요청의 백분율을 나타냅니다. 최소 값은 0(요청의 0%를 나타내는)이고 최대값은 100입니다(요청의 100%를 나타냄).

Fraction 또는 Percent 중 하나만 지정할 수 있습니다. 둘 다 지정하지 않으면 요청의 100%가 미러링됩니다.

group

string

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

kind

string

종류는 참조 대상의 Kubernetes 리소스 종류입니다. 예를 들어 "서비스".

지정하지 않으면 기본적으로 "서비스"가 사용됩니다.

ExternalName 서비스는 클러스터 외부에 있는 CNAME DNS 레코드를 참조할 수 있으므로 적합성 측면에서 추론하기 어렵습니다. 또한 이를 전달하는 것이 안전하지 않을 수도 있습니다(자세한 내용은 CVE-2021-25740 참조). 구현에서는 ExternalName 서비스를 지원하지 않아야 합니다.

지원: Core(ExternalName이 아닌 유형의 서비스)

지원: 구현별(ExternalName 유형의 서비스)

name

string

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

네임스페이스

string

네임스페이스는 백엔드의 네임스페이스입니다. 지정하지 않으면 로컬 네임스페이스가 유추됩니다.

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

지원: 코어

port

integer

포트는 이 리소스에 사용할 대상 포트 번호를 지정합니다. 참조 대상이 Kubernetes 서비스인 경우 포트가 필요합니다. 이 경우 포트 번호는 대상 포트가 아닌 서비스 포트 번호입니다. 다른 리소스의 경우 대상 포트는 참조 리소스나 이 필드에서 파생될 수 있습니다.

분모

integer

분자

integer

add

array

Add는 작업 전에 요청에 지정된 헤더(이름, 값)를 추가합니다. 헤더 이름과 연관된 기존 값에 추가됩니다.

입력: GET /foo HTTP/1.1 my-header: foo

구성: 추가: - 이름: "my-header" 값: "bar,baz"

출력: GET /foo HTTP/1.1 my-header: foo,bar,baz

add[]

object

HTTPHeader는 RFC 7230에 정의된 HTTP 헤더 이름과 값을 나타냅니다.

제거하다

배열(문자열)

작업 전에 HTTP 요청에서 주어진 헤더를 제거합니다. Remove의 값은 HTTP 헤더 이름 목록입니다. 헤더 이름은 대소문자를 구분하지 않습니다( https://datatracker.ietf.org/doc/html/rfc2616#section-4.2 참조).

입력: GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

구성: 제거: ["my-header1", "my-header3"]

출력: GET /foo HTTP/1.1 my-header2: bar

set

array

Set은 작업 전에 주어진 헤더(이름, 값)로 요청을 덮어씁니다.

입력: GET /foo HTTP/1.1 my-header: foo

구성: 설정: - 이름: "my-header" 값: "bar"

출력: GET /foo HTTP/1.1 my-header: bar

set[]

object

HTTPHeader는 RFC 7230에 정의된 HTTP 헤더 이름과 값을 나타냅니다.

name

string

Name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2 참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 동등한 이름을 가진 첫 번째 항목은 반드시 일치하는 것으로 간주됩니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름은 대소문자를 구분하지 않으므로 "foo"와 "Foo"는 동일한 것으로 간주됩니다.

value

string

Value는 일치시킬 HTTP 헤더의 값입니다.

name

string

Name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2 참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 동등한 이름을 가진 첫 번째 항목은 반드시 일치하는 것으로 간주됩니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름은 대소문자를 구분하지 않으므로 "foo"와 "Foo"는 동일한 것으로 간주됩니다.

value

string

Value는 일치시킬 HTTP 헤더의 값입니다.

extensionRef

object

ExtensionRef는 "필터" 동작에 대한 선택적이고 구현에 맞는 확장입니다. 예를 들어, 그룹 "networking.example.net"의 리소스 "myroutefilter"입니다. ExtensionRef는 핵심 필터와 확장 필터에 사용해서는 안 됩니다.

지원: 구현별

이 필터는 동일한 규칙 내에서 여러 번 사용할 수 있습니다.

requestHeaderModifier

object

RequestHeaderModifier는 요청 헤더를 수정하는 필터에 대한 스키마를 정의합니다.

지원: 코어

requestMirror

object

RequestMirror는 요청을 미러링하는 필터에 대한 스키마를 정의합니다. 요청은 지정된 대상지로 전송되지만 해당 대상에서의 응답은 무시됩니다.

이 필터는 동일한 규칙 내에서 여러 번 사용할 수 있습니다. 모든 구현이 여러 백엔드로의 미러링을 지원할 수 있는 것은 아니라는 점에 유의하세요.

지원: 확장됨

responseHeaderModifier

object

ResponseHeaderModifier는 응답 헤더를 수정하는 필터에 대한 스키마를 정의합니다.

지원: 확장됨

type

string

유형은 적용할 필터의 유형을 식별합니다. 다른 API 필드와 마찬가지로 유형은 세 가지 적합성 수준으로 분류됩니다.

- Core: 이 패키지의 "지원: Core"에서 정의된 필터 유형 및 해당 구성, 예: "RequestHeaderModifier". GRPCRoute를 지원하는 모든 구현은 핵심 필터를 지원해야 합니다.

- 확장: 이 패키지의 "지원: 확장"에서 정의된 필터 유형 및 해당 구성, 예: "RequestMirror". 구현자는 확장 필터를 지원하는 것이 좋습니다.

- 구현별: 특정 공급업체에서 정의하고 지원하는 필터입니다. 앞으로는 여러 구현에서 동작의 수렴을 보여주는 필터가 확장 또는 핵심 적합성 수준에 포함되는 것이 고려될 것입니다. 이러한 필터에 대한 필터별 구성은 ExtensionRef 필드를 사용하여 지정됩니다. 사용자 지정 필터의 경우 유형을 "ExtensionRef"로 설정해야 합니다.

구현자는 구현에 맞는 동작으로 핵심 API를 확장하기 위해 사용자 정의 구현 유형을 정의하는 것이 좋습니다.

사용자 지정 필터 유형에 대한 참조를 확인할 수 없는 경우 필터를 건너뛰어서는 안 됩니다. 대신, 해당 필터에 의해 처리될 요청은 반드시 HTTP 오류 응답을 받아야 합니다.

group

string

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

kind

string

이는 일종의 참조입니다. 예: "HTTPRoute" 또는 "Service".

name

string

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

add

array

Add는 작업 전에 지정된 헤더(이름, 값)를 요청에 추가합니다. 헤더 이름과 연결된 기존 값에 추가됩니다.

input: GET /foo HTTP/1.1 my-header: foo

config: add: - name: "my-header" 값: "bar,baz"

출력: GET /foo HTTP/1.1 my-header: foo,bar,baz

add[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

제거

배열(문자열)

작업 전에 HTTP 요청에서 지정된 헤더를 제거합니다. Remove 값은 HTTP 헤더 이름 목록입니다. 헤더 이름은 대소문자를 구분하지 않습니다( https://datatracker.ietf.org/doc/html/rfc2616#section-4.2참조).

입력: GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

config: remove: ["my-header1", "my-header3"]

출력: GET /foo HTTP/1.1 my-header2: bar

set

array

set은 작업 전에 지정된 헤더(이름, 값)로 요청을 덮어씁니다.

input: GET /foo HTTP/1.1 my-header: foo

config: set: - name: "my-header" value: "bar"

출력: GET /foo HTTP/1.1 my-header: bar

set[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

backendRef

object

BackendRef는 미러링된 요청이 전송되는 리소스를 참조합니다.

미러링된 요청은 이 백엔드Ref 내에 있는 끝점 수에 관계없이 이 BackendRef 내의 단일 대상 끝점에만 전송되어야 합니다.

참조자를 찾을 수 없는 경우 이 BackendRef는 유효하지 않으며 게이트웨이에서 삭제해야 합니다. 컨트롤러는 경로 상태의 "ResolvedRefs" 조건이 status: False 로 설정되어 있고 기본 구현에서 이 백엔드를 구성하지 않는지 확인해야 합니다.

ReferenceGrant에서 허용하지 않는 기존 오브젝트에 대한 네임스페이스 간 참조가 있는 경우 컨트롤러는 경로의 "ResolvedRefs" 조건이 status: False 로 설정되어 있고 기본 구현에서 이 백엔드를 구성하지 않도록 해야 합니다.

두 경우 모두 ResolvedRefs Condition의 Message of the ResolvedRefs Condition을 사용하여 문제에 대한 자세한 정보를 제공해야 합니다.

지원: Kubernetes 서비스에 대한 확장

지원: 다른 리소스에 대한 구현별

분수

object

fraction는 BackendRef로 미러링해야 하는 요청의 일부를 나타냅니다.

Fraction 또는 Percent 중 하나만 지정할 수 있습니다. 둘 다 지정하지 않으면 요청의 100%가 미러링됩니다.

백분율

integer

percent는 BackendRef에 미러링해야 하는 요청의 백분율을 나타냅니다. 최소 값은 0(요청의 0%를 나타내는)이고 최대값은 100입니다(요청의 100%를 나타냄).

Fraction 또는 Percent 중 하나만 지정할 수 있습니다. 둘 다 지정하지 않으면 요청의 100%가 미러링됩니다.

group

string

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

kind

string

kind는 참조의 Kubernetes 리소스 유형입니다. 예: "Service".

지정하지 않는 경우 기본값은 "Service"입니다.

ExternalName 서비스는 클러스터 외부에 있을 수 있는 CNAME DNS 레코드를 참조할 수 있으므로 적합성 측면에서 이유하기가 어렵습니다. 또한 안전하게 전달하지 못할 수도 있습니다(자세한 내용은 CVE-2021-25740 참조). 구현은 ExternalName 서비스를 지원하지 않아야 합니다.

지원: Core (ExternalName 이외의 유형이 있는 서비스)

지원: 구현별 ( ExternalName 유형의 서비스)

name

string

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

네임스페이스

string

네임스페이스는 백엔드의 네임스페이스입니다. 지정하지 않으면 로컬 네임스페이스가 유추됩니다.

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

지원: Core

port

integer

port는 이 리소스에 사용할 대상 포트 번호를 지정합니다. 참조가 Kubernetes 서비스인 경우 포트가 필요합니다. 이 경우 포트 번호는 대상 포트가 아닌 서비스 포트 번호입니다. 기타 리소스의 경우 대상 포트가 참조 리소스 또는 이 필드에서 파생될 수 있습니다.

denominator

integer

numerator

integer

add

array

Add는 작업 전에 지정된 헤더(이름, 값)를 요청에 추가합니다. 헤더 이름과 연결된 기존 값에 추가됩니다.

input: GET /foo HTTP/1.1 my-header: foo

config: add: - name: "my-header" 값: "bar,baz"

출력: GET /foo HTTP/1.1 my-header: foo,bar,baz

add[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

제거

배열(문자열)

작업 전에 HTTP 요청에서 지정된 헤더를 제거합니다. Remove 값은 HTTP 헤더 이름 목록입니다. 헤더 이름은 대소문자를 구분하지 않습니다( https://datatracker.ietf.org/doc/html/rfc2616#section-4.2참조).

입력: GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

config: remove: ["my-header1", "my-header3"]

출력: GET /foo HTTP/1.1 my-header2: bar

set

array

set은 작업 전에 지정된 헤더(이름, 값)로 요청을 덮어씁니다.

input: GET /foo HTTP/1.1 my-header: foo

config: set: - name: "my-header" value: "bar"

출력: GET /foo HTTP/1.1 my-header: bar

set[]

object

HTTPHeader는 RFC 7230에서 정의한 HTTP 헤더 이름과 값을 나타냅니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

name

string

name은 일치시킬 HTTP 헤더의 이름입니다. 이름 일치는 대소문자를 구분하지 않아야 합니다. ( https://tools.ietf.org/html/rfc7230#section-3.2참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 이름을 가진 첫 번째 항목을 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

value

string

value는 일치시킬 HTTP 헤더의 값입니다.

headers

array

헤더는 gRPC 요청 헤더 일치자를 지정합니다. 여러 일치 값은 함께 ANDed되며, 즉, 경로를 선택하기 위해 지정된 모든 헤더와 일치해야 합니다.

headers[]

object

GRPCHeaderMatch는 gRPC 요청 헤더와 일치하여 gRPC 경로를 선택하는 방법을 설명합니다.

method

object

method는 gRPC 요청 서비스/메서드 선택기를 지정합니다. 이 필드를 지정하지 않으면 모든 서비스와 방법이 일치합니다.

name

string

name은 일치시킬 gRPC 헤더의 이름입니다.

여러 항목이 동등한 헤더 이름을 지정하는 경우 일치하는 항목이 동일한 이름을 가진 첫 번째 항목만 고려해야 합니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름의 case-insitivity로 인해 "foo" 및 "Foo"는 동등한 것으로 간주됩니다.

type

string

type은 헤더 값과 일치하는 방법을 지정합니다.

value

string

value는 일치시킬 gRPC 헤더의 값입니다.

method

string

일치시킬 메서드의 값입니다. 비워 두거나 생략한 경우 는 모든 서비스와 일치합니다.

Service 및 Method 중 하나 이상이 비어 있지 않은 문자열이어야 합니다.

서비스

string

일치시킬 서비스의 값입니다. 비어 있거나 생략된 경우 는 서비스와 일치합니다.

Service 및 Method 중 하나 이상이 비어 있지 않은 문자열이어야 합니다.

type

string

type은 서비스 및/또는 방법과 일치하는 방법을 지정합니다. 지원: Core (service 및 method specified 사용)

지원: 구현에 따라 (지정된 방법은 적용되지만 서비스가 지정되지 않은 경우)

지원: 구현별 (RegularExpression)

부모

array

상위 리소스(일반적으로 게이트웨이)는 경로와 연결된 상위 리소스 목록 및 각 상위와 관련된 경로의 상태입니다. 이 경로가 상위에 연결되면 컨트롤러가 먼저 경로를 볼 때 상위 목록을 관리하는 컨트롤러에서 해당 경로를 볼 때 해당 목록에 항목을 추가해야 하며 경로 또는 게이트웨이가 수정될 때 항목을 적절하게 업데이트해야 합니다.

이 API의 구현으로 해결할 수 없는 상위 참조는 이 목록에 추가되지 않습니다. 이 API의 구현은 담당하는 Gateways/parent 리소스의 경로 상태만 채울 수 있습니다.

이 목록에 최대 32 개의 게이트웨이가 표시됩니다. 빈 목록은 경로가 게이트웨이에 연결되지 않았음을 의미합니다.

parents[]

object

RouteParentStatus는 관련 상위와 관련하여 경로의 상태를 설명합니다.

conditions

array

conditions는 게이트웨이와 관련된 경로 상태를 설명합니다. 경로의 가용성은 게이트웨이의 자체 상태 조건 및 리스너 상태에도 적용됩니다.

경로의 ParentRef가 이러한 종류의 경로를 지원하는 기존 게이트웨이를 지정하고 게이트웨이의 컨트롤러에 충분한 액세스 권한이 있는 경우 게이트웨이의 컨트롤러에서 경로에 "Accepted" 조건을 설정해야 하며 게이트웨이에서 경로가 수락되었는지 또는 거부되었는지 여부를 나타냅니다.

경로 중 하나 이상이 게이트웨이에 의해 구현되는 경우 경로 "Accepted"로 간주되어야 합니다.

다음과 같은 경우를 포함하여 컨트롤러 가시성 부족으로 인해 "Accepted" 조건이 설정되지 않을 수 있습니다.

* 경로는 존재하지 않는 부모를 나타냅니다. * 경로는 컨트롤러가 지원하지 않는 유형입니다. * 컨트롤러가 액세스할 수 없는 네임스페이스에 있습니다.

conditions[]

object

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

controllerName

string

ControllerName은 이 상태를 작성한 컨트롤러의 이름을 나타내는 domain/path 문자열입니다. 이는 GatewayClass의 controllerName 필드에 해당합니다.

Example: "example.net/gateway-controller".

이 필드의 형식은 DOMAIN "/" PATH입니다. 여기서 DOMAIN 및 PATH는 유효한 Kubernetes 이름(https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)입니다.

컨트롤러는 상태를 작성할 때 이 필드를 채워야 합니다. 컨트롤러는 ControllerName으로 채워진 상태에 대한 항목이 더 이상 필요하지 않을 때 정리되도록 해야 합니다.

parentRef

object

ParentRef는 이 RouteParentStatus 구조가 의 상태를 설명하는 사양의 ParentRef에 해당합니다.

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의 조건 유형입니다.

group

string

그룹은 참조 그룹의 그룹입니다. 지정되지 않은 경우 "gateway.networking.k8s.io"가 유추됩니다. 코어 API 그룹(예: "Service" kind referent의 경우)을 설정하려면 그룹을 명시적으로 ""(빈 문자열)로 설정해야 합니다.

지원: Core

kind

string

이는 일종의 참조입니다.

"Core" 지원이 포함된 두 가지 종류의 상위 리소스가 있습니다.

* 게이트웨이 (Gateway 적합성 프로파일) * 서비스 (Mesh 적합성 프로파일, ClusterIP 서비스 만 해당)

다른 리소스에 대한 지원은 Implementation-Specific입니다.

name

string

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

지원: Core

네임스페이스

string

네임스페이스는 참조의 네임스페이스입니다. 지정되지 않은 경우 경로의 로컬 네임스페이스를 나타냅니다.

네임스페이스 경계를 통과하는 ParentRefs에 대한 특정 규칙이 있습니다. 네임스페이스 간 참조는 참조하는 네임스페이스의 항목에서 명시적으로 허용되는 경우에만 유효합니다. 예를 들어 게이트웨이에는 AllowedRoutes 필드가 있으며 ReferenceGrant는 다른 종류의 네임스페이스를 활성화하는 일반적인 방법을 제공합니다.

지원: Core

port

integer

port는 이 경로가 대상으로 하는 네트워크 포트입니다. 상위 리소스 유형에 따라 다르게 해석될 수 있습니다.

상위 리소스가 게이트웨이인 경우 이러한 종류의 경로도 지원하는 지정된 포트에서 수신 대기 중인 모든 리스너를 대상으로 하고 이 경로를 선택합니다. 경로에 지정된 네트워킹 동작을 포트를 변경할 수 있는 리스너와 달리 특정 포트에 적용해야 하는 경우를 제외하고 Port 를 설정하지 않는 것이 좋습니다. Port 및 sectionName을 둘 다 지정하면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다.

구현은 다른 상위 리소스를 지원하도록 선택할 수 있습니다. 다른 유형의 상위 리소스를 지원하는 구현은 Port가 해석되는 방법을 명확하게 문서화해야 합니다.

상태를 위해 상위 리소스에서 부분적으로 수락하면 첨부 파일이 성공한 것으로 간주됩니다. 예를 들어 게이트웨이 리스너는 경로 종류, 네임스페이스 또는 호스트 이름을 통해 연결할 수 있는 경로를 제한할 수 있습니다. 2개 중 1개의 게이트웨이 리스너가 참조 경로의 첨부 파일을 수락하는 경우 경로는 성공적으로 연결된 것으로 간주해야 합니다. 게이트웨이 리스너가 이 경로의 첨부 파일을 수락하지 않으면 게이트웨이에서 경로를 분리하는 것으로 간주해야 합니다.

지원: 확장

sectionName

string

sectionName은 대상 리소스에 있는 섹션의 이름입니다. 다음 리소스에서 sectionName은 다음과 같이 해석됩니다.

* 게이트웨이: 리스너 이름입니다. Port(experimental) 및 sectionName이 모두 지정되면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다. * 서비스: 포트 이름입니다. Port(experimental) 및 sectionName이 모두 지정되면 선택한 리스너의 이름과 포트가 지정된 두 값과 일치해야 합니다.

구현은 다른 리소스에 경로 연결을 지원하도록 선택할 수 있습니다. 이 경우 sectionName을 해석하는 방법을 명확하게 문서화해야 합니다.

지정되지 않은 경우(빈 문자열) 전체 리소스를 참조합니다. 상태의 목적을 위해 부모 리소스의 하나 이상의 섹션에서 이를 수락하는 경우 첨부 파일이 성공한 것으로 간주됩니다. 예를 들어 게이트웨이 리스너는 경로 종류, 네임스페이스 또는 호스트 이름을 통해 연결할 수 있는 경로를 제한할 수 있습니다. 2개 중 1개의 게이트웨이 리스너가 참조 경로의 첨부 파일을 수락하는 경우 경로는 성공적으로 연결된 것으로 간주해야 합니다. 게이트웨이 리스너가 이 경로의 첨부 파일을 수락하지 않으면 게이트웨이에서 경로를 분리하는 것으로 간주해야 합니다.

지원: Core