17장. HTTPRoute [gateway.networking.k8s.io/v1]

호스트 이름

배열(문자열)

호스트 이름은 요청을 처리하는 데 사용되는 HTTPRoute를 선택하기 위해 HTTP 호스트 헤더와 일치해야 하는 호스트 이름 세트를 정의합니다. 구현은 매치를 수행하는 동안 HTTP 호스트 헤더에 지정된 모든 포트 값을 무시해야 하며 (적용 가능한 헤더 수정 구성이 없는 경우) 이 헤더를 수정하지 않고 백엔드로 전달해야 합니다.

호스트 이름에 대한 유효한 값은 RFC 1123 호스트 이름 정의에 따라 결정되며, 두 가지 주목할 만한 예외가 있습니다.

1. IP는 허용되지 않습니다. 2. 호스트 이름 앞에는 와일드카드 레이블( *. )을 붙일 수 있습니다. 와일드카드 레이블은 첫 번째 레이블로 단독으로 나타나야 합니다.

Listener와 HTTPRoute 모두 호스트 이름을 지정하는 경우 HTTPRoute가 Listener에 연결되려면 최소한 하나 이상의 교차하는 호스트 이름이 있어야 합니다. 예를 들면 다음과 같습니다.

* 호스트 이름이 test.example.com 인 Listener는 호스트 이름을 지정하지 않았거나 test.example.com 또는 *.example.com 중 하나 이상을 지정한 HTTPRoutes와 일치합니다. * 호스트 이름이 *.example.com 인 Listener는 호스트 이름을 지정하지 않았거나 Listener 호스트 이름과 일치하는 호스트 이름을 하나 이상 지정한 HTTPRoutes와 일치합니다. 예를 들어, \*.example.com , test.example.com , foo.test.example.com 은 모두 일치합니다. 반면, example.com 과 test.example.net은 일치하지 않습니다.

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

Listener와 HTTPRoute가 모두 호스트 이름을 지정한 경우 Listener 호스트 이름과 일치하지 않는 HTTPRoute 호스트 이름은 반드시 무시해야 합니다. 예를 들어, Listener가 *.example.com을 지정하고 HTTPRoute가 test.example.com 과 test.example.net을 지정한 경우 test.example.net은 일치 항목으로 간주되어서는 안 됩니다.

Listener와 HTTPRoute가 모두 호스트 이름을 지정했고 위의 기준과 일치하는 것이 없으면 HTTPRoute는 허용되지 않습니다. 구현에서는 해당 RouteParentStatus에서 False 상태의 '수락됨' 조건을 발생시켜야 합니다.

여러 HTTPRoute가 교차하는 호스트 이름(예: 중복되는 와일드카드 일치 및 정확히 일치하는 호스트 이름)을 지정하는 경우 다음 중 가장 많은 수의 HTTPRoute의 규칙이 우선해야 합니다.

* 일치하는 와일드카드가 아닌 호스트 이름의 문자입니다. * 호스트 이름이 일치하는 문자입니다.

여러 경로에 걸쳐 연결이 존재하는 경우 HTTPRouteMatches에 대한 일치 우선순위 규칙이 적용됩니다.

지원: 코어

parentRefs

array

ParentRefs는 Route가 연결되길 원하는 리소스(일반적으로 Gateway)를 참조합니다. 첨부 파일을 완성하려면 참조된 상위 리소스에서 이를 허용해야 합니다. 게이트웨이의 경우 게이트웨이가 이러한 종류와 네임스페이스의 경로에서의 첨부를 허용해야 함을 의미합니다. 서비스의 경우, 서비스는 "생산자" 경로에 대해 동일한 네임스페이스에 있어야 하거나 메시 구현은 참조된 서비스에 대한 "소비자" 경로를 지원하고 허용해야 함을 의미합니다. ReferenceGrant는 서비스에 대한 ParentRefs를 관리하는 데 적용할 수 없습니다. Route와 다른 네임스페이스에 있는 서비스에 대한 "생산자" 경로를 만드는 것은 불가능합니다.

"핵심" 지원을 제공하는 두 가지 유형의 부모 리소스가 있습니다.

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

이 API는 향후에 추가 종류의 부모 리소스를 지원하도록 확장될 수 있습니다.

ParentRefs는 서로 달라야 합니다. 이는 다음을 의미합니다.

* 그들은 다양한 물건을 선택합니다. 이 경우 parentRef 항목은 서로 다릅니다. 필드 측면에서 이는 group , kind , namespace 및 name 으로 정의된 다중 부분 키가 Route의 모든 parentRef 항목에서 고유해야 함을 의미합니다. * 이들은 서로 다른 객체를 선택하지 않지만, 사용된 각 선택적 필드에 대해 동일한 객체를 선택하는 각 ParentRef는 동일한 선택적 필드 집합을 다른 값으로 설정해야 합니다. 한 ParentRef가 선택적 필드의 조합을 설정하는 경우, 모든 ParentRef는 동일한 조합을 설정해야 합니다.

몇 가지 예:

* 하나의 ParentRef가 sectionName을 설정하는 경우, 동일한 객체를 참조하는 모든 ParentRef도 sectionName을 설정해야 합니다. * 하나의 ParentRef가 port를 설정하는 경우, 동일한 객체를 참조하는 모든 ParentRef도 port를 설정해야 합니다. * 하나의 ParentRef가 sectionName 과 port를 설정하는 경우, 동일한 객체를 참조하는 모든 ParentRef도 sectionName 과 port를 설정해야 합니다.

구현에 따라 축소될 수 있는 여러 개의 개별 객체를 별도로 참조하는 것이 가능합니다. 예를 들어, 일부 구현에서는 호환 가능한 Gateway Listener를 병합하기로 선택할 수 있습니다. 그렇다면 해당 리소스에 연결된 경로 목록도 병합해야 합니다.

네임스페이스 경계를 넘는 ParentRefs의 경우 특정 규칙이 있습니다. 교차 네임스페이스 참조는 참조하는 네임스페이스의 어떤 것에서 명시적으로 허용되는 경우에만 유효합니다. 예를 들어, Gateway에는 AllowedRoutes 필드가 있고 ReferenceGrant는 다른 종류의 크로스 네임스페이스 참조를 활성화하는 일반적인 방법을 제공합니다.

parentRefs[]

object

ParentReference는 이 리소스(일반적으로 경로)의 부모로 간주될 수 있는 API 객체(일반적으로 게이트웨이)를 식별합니다. "핵심" 지원을 제공하는 두 가지 유형의 부모 리소스가 있습니다.

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

이 API는 향후에 추가 종류의 부모 리소스를 지원하도록 확장될 수 있습니다.

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

규칙

array

규칙은 HTTP 매처, 필터 및 작업의 목록입니다.

rules[]

object

HTTPRouteRule은 조건(일치)에 따라 HTTP 요청을 매칭하고, 이를 처리(필터)하고, 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의 모든 항목이 유효하지 않고 이 경로 규칙에 지정된 필터도 없는 경우 이 규칙과 일치하는 모든 트래픽은 500 상태 코드를 받아야 합니다.

단일 HTTPBackendRef가 유효하지 않은 항목에 대한 규칙은 HTTPBackendRef 정의를 참조하십시오.

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

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

HTTPBackendRef가 준비되지 않은 엔드포인트가 없는 서비스를 참조하면 구현에서 해당 백엔드에 대한 요청에 대해 503을 반환해야 합니다. 구현에서 이 작업을 수행하는 경우 500 응답에 대한 위의 모든 규칙도 503을 반환하는 응답을 적용해야 합니다.

지원: Kubernetes 서비스 코어

지원: Kubernetes ServiceImport에 대한 확장

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

가중치 지원: Core

backendRefs[]

object

HTTPBackendRef는 HTTPRoute가 HTTP 요청을 전달하는 방법을 정의합니다.

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

filters

array

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

가능한 경우 구현에서는 지정된 순서대로 필터를 구현해야 합니다.

구현은 이러한 순서를 엄격하게 구현하여 지원되지 않는 필터의 조합 또는 순서를 거부합니다. 구현에서 필터 순서의 엄격한 해석을 선택하는 경우 해당 동작을 명확하게 문서화해야 합니다.

잘못된 조합 또는 필터 순서를 거부하려면 구현이 이 구성이 잘못된 경로 규칙으로 간주해야 합니다. 경로의 모든 경로 규칙이 유효하지 않으면 전체 경로가 유효하지 않은 것으로 간주됩니다. 경로 규칙의 일부만 유효하지 않은 경우 구현에서는 경로에 대해 "PartiallyInvalid" 조건을 설정해야 합니다.

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

- 모든 핵심 필터는 모든 구현에서 지원해야 합니다. - 구현자는 확장된 필터를 지원하는 것이 좋습니다. - 구현별 사용자 지정 필터에는 구현마다 API가 보장되지 않습니다.

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

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

지원: Core

filters[]

object

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

일치

array

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

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

matches: - path: value: "/foo" headers: - name: "version" value: "v2" - path: value: "/v2/foo"

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

- /foo AND로 접두사가 지정된 경로에는 헤더 버전이 포함되어 있습니다. v2 - 경로 접두사 /v2/foo

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

일치하는 항목이 없는 경우 기본값은 "/"와 일치하는 접두사 경로입니다. 이 경로는 모든 HTTP 요청과 일치하는 효과가 있는 "/"입니다.

HTTPRoutes에서 생성된 프록시 또는 로드 밸런서 라우팅 구성은 다음 기준에 따라 일치하는 항목을 우선시하여 연결 상태를 유지해야 합니다. 해당 경로에 지정된 모든 규칙에서 일치 항목에 우선순위를 지정해야 합니다.

* "exact" 경로가 일치합니다. * "prefix" 경로는 가장 큰 문자 수와 일치합니다. * 방법이 일치합니다. * 가장 많은 헤더가 일치하는 경우입니다. * 가장 많은 쿼리 매개 변수가 일치합니다.

참고: 정규식 경로 일치의 우선순위는 구현에 따라 다릅니다.

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

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

If ties still within an HTTPRoute, matching precedence must be granted to the FIRST matching rule (in list order) with a match meet the above criteria.

요청과 일치하는 규칙이 부모에 성공적으로 첨부되지 않은 경우 요청이 수신되는 경우 HTTP 404 상태 코드를 반환해야 합니다.

matches[]

object

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

예를 들어 아래 일치 항목은 경로가 /foo 로 시작되고 version: v1 헤더가 포함된 경우에만 HTTP 요청과 일치합니다.

일치:

path: value: "/foo" headers: - name: "version" value "v1"

시간 초과

object

시간 초과는 HTTP 요청에 구성할 수 있는 타임아웃을 정의합니다.

지원: 확장

filters

array

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

지원: 구현별(광범위한 필터를 사용하려면 HTTPRouteRule의 필터 필드를 사용합니다.)

filters[]

object

HTTPRouteFilter는 요청 또는 응답 라이프사이클 중에 완료해야 하는 처리 단계를 정의합니다. HTTPRouteFilter는 게이트웨이 구현에서 수행될 수 있는 처리의 확장 지점입니다. 일부 예로는 요청 또는 응답 수정, 인증 전략 구현, 속도 제한 및 트래픽 형성이 포함됩니다. 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는 요청을 미러링하는 필터의 스키마를 정의합니다. 요청은 지정된 대상으로 전송되지만 해당 대상의 응답은 무시됩니다.

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

지원: 확장

requestRedirect

object

RequestRedirect는 HTTP 리디렉션을 사용하여 요청에 응답하는 필터의 스키마를 정의합니다.

지원: Core

responseHeaderModifier

object

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

지원: 확장

type

string

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

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

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

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

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

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

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

urlRewrite

object

URLRewrite는 전달 중에 요청을 수정하는 필터의 스키마를 정의합니다.

지원: 확장

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

hostname

string

hostname은 응답의 Location 헤더 값에 사용할 호스트 이름입니다. 비어 있으면 요청의 Host 헤더에 있는 호스트 이름이 사용됩니다.

지원: Core

path

object

path는 들어오는 요청의 경로를 수정하는 데 사용되는 매개변수를 정의합니다. 그런 다음 수정된 경로를 사용하여 Location 헤더를 구성합니다. 비어있는 경우 요청 경로가 그대로 사용됩니다.

지원: 확장

port

integer

port는 응답의 Location 헤더 값에 사용할 포트입니다.

포트를 지정하지 않으면 다음 규칙을 사용하여 리디렉션 포트를 파생해야 합니다.

* 리디렉션 스키마가 비어 있지 않은 경우 리디렉션 포트는 리디렉션 체계와 연결된 잘 알려진 포트여야 합니다. 특히 포트 80 및 "https"를 포트 443으로 포트 "http"로 설정합니다. 리디렉션 체계에 잘 알려진 포트가 없으면 게이트웨이의 리스너 포트를 사용해야 합니다. * 리디렉션 스키마가 비어 있는 경우 리디렉션 포트는 Gateway Listener 포트여야 합니다.

구현은 다음과 같은 경우 'Location' 헤더에 포트 번호를 추가하지 않아야 합니다.

* HTTP를 사용할 Location 헤더(Listener 프로토콜 또는 Scheme 필드를 통해 결정됨)를 사용하고 포트 80을 사용합니다. * HTTPS를 사용할 위치 헤더(Listener 프로토콜 또는 Scheme 필드를 통해 결정됨)를 사용하고 포트 443을 사용합니다.

지원: 확장

스키마

string

스키마는 응답의 Location 헤더 값에 사용할 스키마입니다. 비어있는 경우 요청 스키마가 사용됩니다.

스키마 리디렉션은 리디렉션 포트에 영향을 줄 수 있습니다. 자세한 내용은 이 필터의 포트 필드에 대한 설명서를 참조하십시오.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

지원: 확장

statusCode

integer

StatusCode는 응답에 사용할 HTTP 상태 코드입니다.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

지원: Core

replaceFullPath

string

ReplaceFullPath는 재작성 또는 리디렉션 중에 요청의 전체 경로를 교체할 값을 지정합니다.

replacePrefixMatch

string

ReplacePrefixMatch는 재작성 또는 리디렉션 중에 요청의 접두사 일치를 교체할 값을 지정합니다. 예를 들어 접두사 일치 "/foo"와 "/xyz"의 ReplacePrefixMatch가 "/xyz/bar"인 "/foo/bar"에 대한 요청이 수정됩니다.

이는 PathPrefix 일치 유형의 동작과 일치합니다. 이는 전체 경로 요소와 일치합니다. path 요소는 경로의 레이블 목록을 / 구분 기호로 분할한 것입니다. 지정하면 후행 / 가 무시됩니다. 예를 들어 /abc,/abc/, /abc/def 경로는 모두 접두사 /abc 과 일치하지만 경로 /abcd 는 그렇지 않습니다.

ReplacePrefixMatch는 PathPrefix HTTPRouteMatch와만 호환됩니다. 동일한 HTTPRouteRule에서 다른 HTTPRouteMatch 유형을 사용하면 경로의 Accepted Condition이 status: False 로 설정됩니다.

요청 경로 | 접두사 일치 | 접두사 교체 | 접두사 | 경로 교체

type

string

type은 경로 수정자의 유형을 정의합니다. 향후 API 릴리스에 추가 유형이 추가될 수 있습니다.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

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 헤더의 값입니다.

hostname

string

hostname은 전달 중에 Host 헤더 값을 교체하는 데 사용할 값입니다.

지원: 확장

path

object

path는 경로 재작성을 정의합니다.

지원: 확장

replaceFullPath

string

ReplaceFullPath는 재작성 또는 리디렉션 중에 요청의 전체 경로를 교체할 값을 지정합니다.

replacePrefixMatch

string

ReplacePrefixMatch는 재작성 또는 리디렉션 중에 요청의 접두사 일치를 교체할 값을 지정합니다. 예를 들어 접두사 일치 "/foo"와 "/xyz"의 ReplacePrefixMatch가 "/xyz/bar"인 "/foo/bar"에 대한 요청이 수정됩니다.

이는 PathPrefix 일치 유형의 동작과 일치합니다. 이는 전체 경로 요소와 일치합니다. path 요소는 경로의 레이블 목록을 / 구분 기호로 분할한 것입니다. 지정하면 후행 / 가 무시됩니다. 예를 들어 /abc,/abc/, /abc/def 경로는 모두 접두사 /abc 과 일치하지만 경로 /abcd 는 그렇지 않습니다.

ReplacePrefixMatch는 PathPrefix HTTPRouteMatch와만 호환됩니다. 동일한 HTTPRouteRule에서 다른 HTTPRouteMatch 유형을 사용하면 경로의 Accepted Condition이 status: False 로 설정됩니다.

요청 경로 | 접두사 일치 | 접두사 교체 | 접두사 | 경로 교체

type

string

type은 경로 수정자의 유형을 정의합니다. 향후 API 릴리스에 추가 유형이 추가될 수 있습니다.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

extensionRef

object

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

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

지원: 구현별

requestHeaderModifier

object

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

지원: Core

requestMirror

object

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

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

지원: 확장

requestRedirect

object

RequestRedirect는 HTTP 리디렉션을 사용하여 요청에 응답하는 필터의 스키마를 정의합니다.

지원: Core

responseHeaderModifier

object

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

지원: 확장

type

string

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

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

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

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

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

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

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

urlRewrite

object

URLRewrite는 전달 중에 요청을 수정하는 필터의 스키마를 정의합니다.

지원: 확장

group

string

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

kind

string

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

name

string

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

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 헤더의 값입니다.

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

hostname

string

hostname은 응답의 Location 헤더 값에 사용할 호스트 이름입니다. 비어 있으면 요청의 Host 헤더에 있는 호스트 이름이 사용됩니다.

지원: Core

path

object

path는 들어오는 요청의 경로를 수정하는 데 사용되는 매개변수를 정의합니다. 그런 다음 수정된 경로를 사용하여 Location 헤더를 구성합니다. 비어있는 경우 요청 경로가 그대로 사용됩니다.

지원: 확장

port

integer

port는 응답의 Location 헤더 값에 사용할 포트입니다.

포트를 지정하지 않으면 다음 규칙을 사용하여 리디렉션 포트를 파생해야 합니다.

* 리디렉션 스키마가 비어 있지 않은 경우 리디렉션 포트는 리디렉션 체계와 연결된 잘 알려진 포트여야 합니다. 특히 포트 80 및 "https"를 포트 443으로 포트 "http"로 설정합니다. 리디렉션 체계에 잘 알려진 포트가 없으면 게이트웨이의 리스너 포트를 사용해야 합니다. * 리디렉션 스키마가 비어 있는 경우 리디렉션 포트는 Gateway Listener 포트여야 합니다.

구현은 다음과 같은 경우 'Location' 헤더에 포트 번호를 추가하지 않아야 합니다.

* HTTP를 사용할 Location 헤더(Listener 프로토콜 또는 Scheme 필드를 통해 결정됨)를 사용하고 포트 80을 사용합니다. * HTTPS를 사용할 위치 헤더(Listener 프로토콜 또는 Scheme 필드를 통해 결정됨)를 사용하고 포트 443을 사용합니다.

지원: 확장

스키마

string

스키마는 응답의 Location 헤더 값에 사용할 스키마입니다. 비어있는 경우 요청 스키마가 사용됩니다.

스키마 리디렉션은 리디렉션 포트에 영향을 줄 수 있습니다. 자세한 내용은 이 필터의 포트 필드에 대한 설명서를 참조하십시오.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

지원: 확장

statusCode

integer

StatusCode는 응답에 사용할 HTTP 상태 코드입니다.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

지원: Core

replaceFullPath

string

ReplaceFullPath는 재작성 또는 리디렉션 중에 요청의 전체 경로를 교체할 값을 지정합니다.

replacePrefixMatch

string

ReplacePrefixMatch는 재작성 또는 리디렉션 중에 요청의 접두사 일치를 교체할 값을 지정합니다. 예를 들어 접두사 일치 "/foo"와 "/xyz"의 ReplacePrefixMatch가 "/xyz/bar"인 "/foo/bar"에 대한 요청이 수정됩니다.

이는 PathPrefix 일치 유형의 동작과 일치합니다. 이는 전체 경로 요소와 일치합니다. path 요소는 경로의 레이블 목록을 / 구분 기호로 분할한 것입니다. 지정하면 후행 / 가 무시됩니다. 예를 들어 /abc,/abc/, /abc/def 경로는 모두 접두사 /abc 과 일치하지만 경로 /abcd 는 그렇지 않습니다.

ReplacePrefixMatch는 PathPrefix HTTPRouteMatch와만 호환됩니다. 동일한 HTTPRouteRule에서 다른 HTTPRouteMatch 유형을 사용하면 경로의 Accepted Condition이 status: False 로 설정됩니다.

요청 경로 | 접두사 일치 | 접두사 교체 | 접두사 | 경로 교체

type

string

type은 경로 수정자의 유형을 정의합니다. 향후 API 릴리스에 추가 유형이 추가될 수 있습니다.

이 enum에 값이 추가될 수 있으며, 구현은 알 수 없는 값이 충돌하지 않도록 해야 합니다.Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

여기에서 알 수 없는 값은 경로의 상태가 Accepted Condition으로 설정되어야 합니다. False. , 이유 UnsupportedValue.

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 참조).

여러 항목이 동등한 헤더 이름을 지정하는 경우 동등한 이름을 가진 첫 번째 항목은 반드시 일치하는 것으로 간주됩니다. 동일한 헤더 이름을 가진 후속 항목은 무시되어야 합니다. 헤더 이름은 대소문자를 구분하지 않으므로 "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 헤더의 값입니다.

hostname

string

호스트 이름은 전달 중에 호스트 헤더 값을 대체하는 데 사용되는 값입니다.

지원: 확장됨

path

object

경로는 경로 재작성을 정의합니다.

지원: 확장됨

replaceFullPath

string

ReplaceFullPath는 재작성 또는 리디렉션 중에 요청의 전체 경로를 교체할 값을 지정합니다.

replacePrefixMatch

string

ReplacePrefixMatch는 다시 쓰기 또는 리디렉션 중에 요청의 접두사 일치를 대체할 값을 지정합니다. 예를 들어, "/foo"의 접두사 일치와 "/xyz"의 ReplacePrefixMatch를 갖는 "/foo/bar"에 대한 요청은 "/xyz/bar"로 수정됩니다.

이는 PathPrefix 일치 유형의 동작과 일치한다는 점에 유의하세요. 이는 전체 경로 요소와 일치합니다. 경로 요소는 / 구분 기호로 구분된 경로의 레이블 목록을 참조합니다. 지정된 경우 끝에 오는 /는 무시됩니다. 예를 들어, 경로 /abc , /abc/ , /abc/def 는 모두 접두사 /abc 와 일치하지만 경로 /abcd 는 일치하지 않습니다.

ReplacePrefixMatch는 PathPrefix HTTPRouteMatch와만 호환됩니다. 동일한 HTTPRouteRule에 다른 HTTPRouteMatch 유형을 사용하면 구현에서 경로에 대한 허용 조건이 False 상태로 설정됩니다.

요청 경로 | 접두사 일치 | 접두사 바꾸기 | 수정된 경로

type

string

유형은 경로 수정자의 유형을 정의합니다. API의 향후 릴리스에서는 추가 유형이 추가될 수 있습니다.

이 열거형에 값이 추가될 수 있으며, 구현 시 알 수 없는 값으로 인해 충돌이 발생하지 않도록 해야 합니다.

여기에 알 수 없는 값이 있는 경우 구현에서 Route to status: False 에 대한 Accepted Condition을 설정하고 Reason을 UnsupportedValue 로 설정해야 합니다.

headers

array

헤더는 HTTP 요청 헤더 매처를 지정합니다. 여러 개의 일치 값을 AND로 연결하면, 경로를 선택하려면 요청이 지정된 모든 헤더와 일치해야 합니다.

headers[]

object

HTTPHeaderMatch는 HTTP 요청 헤더를 일치시켜 HTTP 경로를 선택하는 방법을 설명합니다.

method

string

메서드는 HTTP 메서드 매처를 지정합니다. 이 옵션이 지정되면, 요청에 지정된 메서드가 있는 경우에만 이 경로가 매칭됩니다.

지원: 확장됨

path

object

Path는 HTTP 요청 경로 매처를 지정합니다. 이 필드가 지정되지 않으면 "/" 경로에 대한 기본 접두사 일치가 제공됩니다.

queryParams

array

QueryParams는 HTTP 쿼리 매개변수 매처를 지정합니다. 여러 개의 일치 값을 AND로 연결하면, 요청은 경로를 선택하기 위해 지정된 모든 쿼리 매개변수와 일치해야 합니다.

지원: 확장됨

queryParams[]

object

HTTPQueryParamMatch는 HTTP 쿼리 매개변수를 일치시켜 HTTP 경로를 선택하는 방법을 설명합니다.

name

string

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

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

HTTP 요청에서 헤더가 반복되는 경우, 이를 표현하는 방법은 구현에 따라 달라집니다. 일반적으로 프록시는 반복 헤더 처리와 관련하여 RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 의 지침을 따라야 하며, 특히 "Set-Cookie"에 대한 특별 처리가 필요합니다.

type

string

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

지원: 핵심(정확히)

지원: 구현별(RegularExpression)

RegularExpression HeaderMatchType은 구현에 따라 적합성이 다르므로 구현 시 POSIX, PCRE 또는 기타 정규 표현식 방언을 지원할 수 있습니다. 지원되는 방언을 확인하려면 구현 문서를 읽어보세요.

value

string

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

type

string

유형은 경로 값과 일치하는 방법을 지정합니다.

지원: Core(Exact, PathPrefix)

지원: 구현별(RegularExpression)

value

string

일치시킬 HTTP 경로의 값입니다.

name

string

Name은 일치시킬 HTTP 쿼리 매개변수의 이름입니다. 정확히 일치하는 문자열이어야 합니다. ( https://tools.ietf.org/html/rfc7230#section-2.7.3 참조).

여러 항목이 동등한 쿼리 매개변수 이름을 지정하는 경우, 동등한 이름을 가진 첫 번째 항목만 일치 항목으로 간주되어야 합니다. 동일한 쿼리 매개변수 이름을 가진 후속 항목은 무시되어야 합니다.

HTTP 요청에서 쿼리 매개변수가 반복되는 경우, 서로 다른 데이터 플레인의 기능이 다르기 때문에 의도적으로 동작이 정의되지 않은 상태로 남겨둡니다. 그러나 게이트웨이 API 외부의 다른 부하 분산 컨텍스트에서는 이러한 동작이 예상되므로 데이터 플레인이 지원하는 경우 구현은 매개변수의 첫 번째 값과 일치하도록 하는 것이 좋습니다 .

사용자는 구현상의 잠재적인 차이로부터 자신을 보호하기 위해 반복되는 쿼리 매개변수를 기반으로 트래픽을 라우팅해서는 안 됩니다.

type

string

유형은 쿼리 매개변수 값과 일치하는 방법을 지정합니다.

지원: 확장(정확히)

지원: 구현별(RegularExpression)

RegularExpression QueryParamMatchType은 구현에 따라 특정 규칙을 따르므로 구현에서는 POSIX, PCRE 또는 기타 정규 표현식 방언을 지원할 수 있습니다. 지원되는 방언을 확인하려면 구현 문서를 읽어보세요.

value

string

Value는 일치시킬 HTTP 쿼리 매개변수의 값입니다.

backendRequest

string

BackendRequest는 게이트웨이에서 백엔드로 가는 개별 요청에 대한 시간 초과를 지정합니다. 여기에는 게이트웨이에서 요청이 처음 전송된 시간부터 백엔드에서 전체 응답을 수신할 때까지의 시간이 포함됩니다.

시간 초과를 0 기간으로 설정(예: "0s")는 시간 초과를 완전히 비활성화해야 합니다. 타임아웃을 완전히 비활성화할 수 없는 구현은 대신 0 기간을 타임아웃을 설정할 수 있는 가장 긴 값으로 해석해야 합니다.

요청 시간 초과에 의해 처리되는 게이트웨이와의 전체 클라이언트 HTTP 트랜잭션은 예를 들어 자동 재시도가 지원되는 경우 게이트웨이에서 대상 백엔드로의 호출을 두 번 이상 발생시킬 수 있습니다.

BackendRequest의 값은 GEP-2257에서 정의한 Gateway API Duration 문자열이어야 합니다. 이 필드가 지정되지 않으면 동작은 구현에 따라 달라집니다. 지정된 경우 BackendRequest 값은 요청 시간 초과 값보다 클 수 없습니다(요청 시간 초과는 BackendRequest 시간 초과를 포함하기 때문입니다).

지원: 확장됨

요구

string

요청은 게이트웨이가 HTTP 요청에 응답하는 데 걸리는 최대 기간을 지정합니다. 게이트웨이가 이 마감 기한을 맞추기 전에 응답하지 못하면 게이트웨이는 시간 초과 오류를 반환해야 합니다.

예를 들어, HTTPRoute 에서 rules.timeouts.request 필드를 값 10s 로 설정하면 클라이언트 요청이 완료되는 데 10초 이상 걸리는 경우 시간 초과가 발생합니다.

시간 초과를 0 기간으로 설정(예: "0s")는 시간 초과를 완전히 비활성화해야 합니다. 타임아웃을 완전히 비활성화할 수 없는 구현은 대신 0 기간을 타임아웃을 설정할 수 있는 가장 긴 값으로 해석해야 합니다.

이 타임아웃은 가능한 한 전체 요청-응답 트랜잭션을 포괄하도록 설계되었지만, 구현에 따라 클라이언트가 트랜잭션을 시작한 직후가 아니라 전체 요청 스트림을 수신한 후에 타임아웃을 시작하도록 선택할 수도 있습니다.

요청 값은 GEP-2257에서 정의한 Gateway API 기간 문자열입니다. 이 필드가 지정되지 않으면 요청 시간 초과 동작은 구현에 따라 달라집니다.

지원: 확장

부모

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