第15章 Gateway [gateway.networking.k8s.io/v1]

addresses

array

このゲートウェイに対して要求されたアドレス。これはオプションであり、動作は実装によって異なります。仕様で値が設定され、要求されたアドレスが無効または利用できない場合、実装では GatewayStatus.Addresses の関連エントリーでこれを示す必要があります。

Addresses フィールドは、このゲートウェイに向かうトラフィックが使用する "ゲートウェイの外" のアドレスの要求を表します。これは、外部ロードバランサーまたはその他のネットワークインフラストラクチャーの IP アドレスやホスト名、あるいはトラフィックの送信先であるその他のアドレスである可能性があります。

Addresses が指定されていない場合、実装では、適切なアドレスセットを割り当てて、実装固有の方法でゲートウェイをスケジュールすることができます。

実装では、すべてのリスナーを、ゲートウェイに割り当てるすべての GatewayAddress にバインドし、GatewayStatus.Addresses に対応するエントリーを追加する必要があります。

サポート: Extended

addresses[]

object

GatewayAddress は、ゲートウェイにバインドできるアドレスを記述します。

gatewayClassName

string

このゲートウェイに使用される GatewayClassName。これは GatewayClass リソースの名前です。

infrastructure

object

インフラストラクチャーは、このゲートウェイインスタンスに関するインフラストラクチャーレベルの属性を定義します。

サポート: Extended

listeners

array

このゲートウェイに関連付けられたリスナー。listeners は、このゲートウェイのアドレスにバインドされる論理エンドポイントを定義します。少なくとも 1 つのリスナーを指定する必要があります。

区別されるリスナー

トラフィックフローは正確に 1 つのリスナーに割り当てられる必要があることを考慮すると、リスナーセット (たとえば 1 つのゲートウェイ) 内の各リスナーは 区別される 必要があります。(このセクションでは、"1 つのゲートウェイ内のリスナー" ではなく "リスナーセット" と使用しています。これは、実装によって複数のゲートウェイの設定が単一のデータプレーンにマージされる可能性があり、その場合も これらのルールが適用されるためです。)

これは実際には、セット内の各リスナーがポート、プロトコル、およびプロトコルでサポートされている場合はホスト名の一意の組み合わせを持つ必要があることを意味します。

ポート、プロトコル、および TLS 設定のいくつかの組み合わせはコアサポートとみなされ、サポートするオブジェクトに基づき実装でサポートされる必要があります。

HTTPRoute

1.HTTPRoute、ポート: 80、プロトコル: HTTP 2。HTTPRoute、ポート: 443、プロトコル: HTTPS、TLS モード: Terminate、TLS キーペア提供

TLSRoute

1.TLSRoute、ポート: 443、プロトコル: TLS、TLS モード: Passthrough

"区別される" リスナーには次のプロパティーがあります。

実装では、受信要求を単一の区別されるリスナーに一致させることができます。

複数のリスナーがフィールドの値を共有している場合 (たとえば、同じポート値を持つ 2 つのリスナー)、実装では他の Listener フィールドを使用して、要求を 1 つのリスナーにのみ一致させることができます。

複数のリスナーが Protocol フィールドに同じ値を持つ場合、一致するプロトコル値を持つ各リスナーは、他のフィールドに異なる値を持つ必要があります。

リスナーごとに異なる必要があるフィールドのセットは、プロトコルにより異なります。以下のルールは、ゲートウェイ API 仕様で現在定義されている各プロトコルにおいて、リスナーを区別するために考慮する必要があるフィールドのルールを定義します。

プロトコル値を共有するリスナーセットは、次のフィールドのうち 少なくとも 1 つ に 異なる 値を持たなければ一意にはなりません。

* HTTP、HTTPS、TLS: ポート、ホスト名 * TCP、UDP: ポート

注意すべき 非常に 重要なルールの 1 つは、以下の両方が実装に当てはまる場合に何が起きるかというものです。

* TCP プロトコルリスナーだけでなく、HTTP、HTTPS、または TLS プロトコルリスナーもサポートする。* 同じ port を使用する HTTP、HTTPS、または TLS プロトコルを TCP プロトコルと同じとみなす。

この場合、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" の両方に一致します。

区別できないリスナーの処理

リスナーのセットに区別できないリスナーが含まれている場合、それらのリスナーは 競合 しており、実装ではリスナーステータスの "Conflicted" 条件を "True" に設定する必要があります。

このドキュメントでは、"区別できない" と "競合する" という表現は同義とみなされます。

実装では、うち競合するリスナーが含まれない一部のリスナーセットのみを受け入れる場合に限り、一部のリスナーが競合するゲートウェイを受け入れることができます。

具体的には、実装では、次の規則に従ってリスナーセットを部分的に受け入れることができます。

* 実装では、1 つの競合するリスナーをウィナーとして選択してはなりません。区別できないすべてのリスナーは、処理対象として受け入れてはなりません。* 区別されるリスナーが 1 つ以上存在する必要があります。そうでない場合、実質的にはゲートウェイにはリスナーが 含まれておらず、全体として処理を拒否されなければなりません。

ゲートウェイに競合するリスナーが含まれている場合、ゲートウェイを受け入れるかどうかにかかわらず、実装ではゲートウェイステータスとして "ListenersNotValid" 条件が設定されなければなりません。その条件では、どのリスナーが競合しているか、どのリスナーが受け入れられたかを、メッセージで明示する必要があります。さらに、これらのリスナーのリスナーステータスでは、どのリスナーが競合していて受け入れられていないかを示す必要があります。

リスナーの基本動作

区別されるすべてのリスナーにおいて、要求は最大で 1 つのリスナーと一致することに注意してください。たとえば、"foo.example.com" と "*.example.com" に対してリスナーが定義されている場合、"foo.example.com" への要求は、"foo.example.com" リスナー ("*.example.com" リスナーではない) に割り当てられたルートのみを使用してルーティングされる必要があります。

これは "リスナーの分離" と呼ばれる概念で、ゲートウェイ API の拡張機能です。リスナーの分離をサポートしない実装では、その旨を明確に文書化する必要があり、GatewayHTTPListenerIsolation 機能のサポートを主張してはなりません。

リスナーの分離を サポートする 実装では、Extended GatewayHTTPListenerIsolation 機能のサポートを主張し、関連する適合テストに合格する必要があります。

互換リスナー

ゲートウェイのリスナーは、次の場合に 互換性がある とみなされます。

1.区別される場合。2. 実装では、割り当てられたすべてのアドレスですべてのリスナーを使用できる、というアドレス要件に準拠してサービスを提供できます。

延長サポートにおける互換性のある組み合わせは、実装ごとに異なることが予想されます。ある実装では互換性がある組み合わせが、別の実装では互換性がない場合があります。

たとえば、同じアドレスで TCP リスナーと UDP リスナーの両方に対応できない実装や、同じポートで HTTPS リスナーと汎用 TLS リスナーを混在させることができない実装では、これらのケースは区別できても互換性があるとはみなされません。

すべてのゲートウェイのすべてのリスナーに互換性がある場合、実装では個別のゲートウェイを単一のアドレスセットにマージできます。

今後のリリースでは、MinItems=1 の要件が削除される可能性があります。

サポート: Core

listeners[]

object

listener は、ゲートウェイがネットワーク接続を受け入れる論理エンドポイントの概念を体現したものです。

type

string

アドレスのタイプ。

value

string

アドレスの値。値の有効性は、コントローラーのタイプとサポートによって異なります。

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

annotations

object (string)

このゲートウェイに応じて作成されたすべてのリソースに適用する必要があるアノテーション。

他の Kubernetes オブジェクトを作成する実装の場合、これはリソースの metadata.annotations フィールドになります。それ以外の実装の場合、これは関連する (実装固有の) "アノテーション" の概念を指します。

実装では、必要に応じて実装固有の追加のアノテーションを追加することを選択できます。

サポート: Extended

labels

object (string)

このゲートウェイに応じて作成されるすべてのリソースに適用する必要があるラベル。

他の Kubernetes オブジェクトをする実装の場合、これはリソースの metadata.labels フィールドです。それ以外の実装の場合、これは関連する (実装固有の) "ラベル" の概念を指します。

実装では、必要に応じて実装固有の追加のラベルを追加することを選択できます。

実装がこれらのラベルを Pod にマッピングする場合、またはラベルの変更時にに再作成する必要があるその他のリソースにマッピングする場合は、この動作についてドキュメントで明確に警告する必要があります。

サポート: Extended

parametersRef

object

ParametersRef は、ゲートウェイに対応する設定パラメーターが含まれるリソースへの参照です。コントローラーに追加の設定が必要ない場合はオプションです。

これは、GatewayClass の parametersRef と同じセマンティクスに従いますが、ゲートウェイごとに異なります。

ゲートウェイの GatewayClass は独自の parametersRef を指定できます。両方が指定されている場合、マージ動作は実装固有です。一般的に、GatewayClass では、ゲートウェイによってオーバーライドできるデフォルトを指定することが推奨されます。

参照先が見つからない場合、サポートされていない kind を参照している場合、またはそのリソース内のデータが不正な形式である場合、ゲートウェイは "Accepted" ステータス条件を "False" に設定し、"InvalidParameters" の理由で拒否される必要があります。

サポート: 実装固有

group

string

group は参照先のグループです。

kind

string

kind は参照先の kind です。

name

string

name は参照先の名前です。

allowedRoutes

object

AllowedRoutes は、リスナーに割り当てることができるルートのタイプと、それらのルートリソースが存在する可能性がある信頼済み namespace を定義します。

クライアント要求は複数のルートルールに一致する可能性がありますが、最終的に要求を受信できるのは 1 つのルールのみです。一致の優先順位は、次の基準に従って決定される必要があります。

* ルートタイプによって定義される最も具体的な一致。* 作成タイムスタンプに基づく古い方のルート。たとえば、作成タイムスタンプが "2020-09-08 01:02:03" のルートは、作成タイムスタンプが "2020-09-08 01:02:04" のルートよりも優先されます。* 他のすべてが同じである場合、アルファベット順 (namespace /名前) で最初に表示されるルートが優先されます。たとえば、foo/bar は foo/baz よりも優先されます。

このリスナーに割り当てられたルート内のすべての有効なルールを実装する必要があります。無効なルートルールは無視できます (それが完全なルートの場合もあります)。ルートルールが有効から無効に遷移する場合、一貫性を保つためにそのルートルールのサポートを削除する必要があります。たとえば、ルートルールで指定されたフィルターが無効な場合でも、そのルート内の残りのルールは引き続きサポートされる必要があります。

サポート: Core

hostname

string

ホスト名は、この概念を定義するプロトコルタイプに一致する仮想ホスト名を指定します。指定しない場合は、すべてのホスト名が一致します。ホスト名に基づく一致を必要としないプロトコルの場合、このフィールドは無視されます。

実装では、次のプロトコルごとにホスト名の一致を適切に適用する必要があります。

* TLS: リスナーホスト名は SNI と一致する必要があります。* HTTP: リスナーホスト名は、要求のホストヘッダーと一致する必要があります。* HTTPS: リスナーホスト名は SNI とホストヘッダーの両方に一致する必要があります。SNI とホストヘッダーが同じである必要はないことに注意してください。以下は、このセマンティクスの詳しい説明です。

セキュリティーを確保するために、RFC-6066 のセクション 11.1 では、SNI ホスト名の一致に依存するサーバー実装は、アプリケーションプロトコル内のホスト名も検証する必要があることを強調しています。

RFC-7540 のセクション 9.1.2 では、HTTP 421 Misdirected Request ステータスコードで応答することで、サーバーが接続の再利用を拒否するメカニズムが提供されています。これは、要求が誤った宛先に送信された可能性があるため、元のサーバーが要求を拒否したことを示します。

誤った宛先への要求を検出するために、ゲートウェイは、要求の権限を、同じポートとプロトコル上のすべてのゲートウェイリスナーに設定されているすべての SNI ホスト名と一致させる必要があります。

* 別のリスナーに完全一致またはより具体的なワイルドカードエントリーがある場合、ゲートウェイは 421 を返す必要があります。* 現在のリスナー (ClientHello 中に SNI の一致により選択) がホストと一致しない場合: * 別のリスナーがホストと一致する場合、ゲートウェイは 421 を返す必要があります。* 他のリスナーがホストと一致しない場合、ゲートウェイは 404 を返す必要があります。

HTTPRoute および TLSRoute リソースの場合、spec.hostnames 配列との対話があります。リスナーとルートの両方でホスト名を指定する場合、値の間に共通部分が存在しなければルートは受け入れられません。詳細は、ルート固有のホスト名のドキュメントを参照してください。

ワイルドカードラベル (*.) が接頭辞として追加されているホスト名は、接尾辞一致として解釈されます。つまり、*.example.com に一致すると、test.example.com と foo.test.example.com の両方に一致しますが、example.com には一致しません。

サポート: Core

name

string

name はリスナーの名前です。この名前はゲートウェイ内で一意である必要があります。

サポート: Core

port

integer

port はネットワークポートです。リスナー互換性ルールに従って、複数のリスナーが同じポートを使用する場合があります。

サポート: Core

protocol

string

protocol は、このリスナーが受信することを想定しているネットワークプロトコルを指定します。

サポート: Core

tls

object

TLS はリスナーの TLS 設定です。Protocol フィールドが "HTTPS" または "TLS" の場合、このフィールドは必須です。Protocol フィールドが "HTTP"、"TCP"、または "UDP" の場合、このフィールドの設定は無効になります。

GatewayTLSConfig で定義された証明書への SNI の関連付けは、このリスナーの Hostname フィールドに基づいて定義されます。

GatewayClass は、あらゆる TLS ハンドシェイクに利用可能なすべての証明書の中で最も長く一致する SNI を使用する必要があります。

サポート: Core

kinds

array

Kinds は、このゲートウェイリスナーにバインドできるルートのグループと kind を指定します。指定されていない、または空の場合、選択されたルートの kind はリスナープロトコルを使用して決定されます。

RouteGroupKind は、リスナーの Protocol フィールドで指定されたアプリケーションプロトコルと互換性のあるルートの kind に対応している必要があります。実装がこのリソースタイプをサポートまたは認識しない場合は、このリスナーの "ResolvedRefs" 条件を "InvalidRouteKinds" の理由で False に設定する必要があります。

サポート: Core

kinds[]

object

RouteGroupKind は、ルートリソースのグループと kind を示します。

namespaces

object

namespace は、そこからルートがこのリスナーに割り当てられる可能性のある namespace を示します。デフォルトでは、このゲートウェイの namespace に制限されています。

サポート: Core

group

string

group はルートのグループです。

kind

string

kind はルートの kind です。

from

string

from は、このゲートウェイのルートが選択される場所を示します。以下の値が使用できます。

* All: このゲートウェイでは、すべての namespace 内のルートを使用できます。* Selector: このゲートウェイでは、セレクターによって選択された namespace 内のルートを使用できます。* Same: このゲートウェイでは、同じ namespace 内のルートのみを使用できます。

サポート: Core

selector

object

From が "Selector" に設定されている場合は、セレクターを指定する必要があります。その場合、このゲートウェイでは、このセレクターに一致する namespace 内のルートのみが選択されます。"From" が他の値の場合、このフィールドは無視されます。

サポート: Core

matchExpressions

array

matchExpressions はラベルセレクターの要件のリストです。要件は AND で結合されます。

matchExpressions[]

object

ラベルセレクター要件は、値、キー、およびキーと値を関連付ける Operator を含むセレクターです。

matchLabels

object (string)

matchLabels は、{key,value} ペアのマップです。matchLabels マップの 1 つの {key,value} は matchExpressions の要素と同じで、キーフィールドには "key"、演算子には "In"、値配列には "value" のみが含まれます。要件は AND で結合されます。

key

string

key は、セレクターの適用先のラベルキーです。

operator

string

operator はキーと値のセットの関係を表します。有効な演算子は In、NotIn、Exists、および DoesNotExist です。

values

array (string)

values は文字列値の配列です。operator が In または NotIn の場合には、values 配列を空白にできません。operator が Exists または DoesNotExist の場合には、values 配列は空白でなければなりません。この配列は、ストラテジーに基づいたマージパッチの適用中に置き換えられます。

certificateRefs

array

CertificateRefs には、TLS 証明書と秘密鍵を含む Kubernetes オブジェクトへの一連の参照が含まれています。これらの証明書は、関連付けられたリスナーのホスト名に一致する要求の TLS ハンドシェイクを確立するために使用されます。

Kubernetes Secret への単一の CertificateRef には "Core" サポートがあります。実装では、リスナーへの複数の証明書の割り当てをサポートすることを選択できますが、この動作は実装固有です。

異なる namespace のリソースへの参照は、証明書の割り当てを許可する ReferenceGrant がターゲット namespace にない限り無効です。ReferenceGrant がこの参照を許可しない場合は、このリスナーの "ResolvedRefs" 条件を "RefNotPermitted" の理由で False に設定する必要があります。

モードが "Terminate" (デフォルト) に設定されている場合、このフィールドには少なくとも 1 つの要素が必要ですが、それ以外の場合はオプションです。

CertificateRefs は、標準の Kubernetes リソース (Secret など) または実装固有のカスタムリソースを参照できます。

サポート: Core - kubernetes.io/tls タイプの Kubernetes Secret への単一の参照

サポート: 実装固有 (複数の参照またはその他のリソースタイプ)

certificateRefs[]

object

SecretObjectReference は、API オブジェクト (namespace を含む) を識別します。デフォルトは Secret です。

API オブジェクトはクラスター内で有効である必要があります。この参照を有効にするには、Group と Kind がクラスターに登録されている必要があります。

無効なグループと kind を持つオブジェクトへの参照は有効ではないため、実装によって拒否され、含まれるオブジェクトには適切な条件が設定される必要があります。

mode

string

mode は、クライアントによって開始された TLS セッションの TLS 動作を定義します。2 つのモードを使用できます。

- Terminate: ダウンストリームクライアントとゲートウェイ間の TLS セッションはゲートウェイで終了します。このモードでは、certificateRefs フィールドに入力するなど、何らかの方法で証明書を指定する必要があります。- Passthrough: TLS セッションはゲートウェイによって終了されません。これは、ゲートウェイが TLS プロトコルの ClientHello メッセージ以外の TLS ストリームを解読できないことを意味します。このモードでは certificateRefs フィールドは無視されます。

サポート: Core

options

object (string)

オプションは、各実装の拡張 TLS 設定を有効にするためのキー/値のペアのリストです。たとえば、最小の TLS バージョンまたはサポートされている暗号スイートを設定します。

今後、共通鍵のセットが API によって定義される可能性があります。曖昧さを避けるために、実装固有の定義では、example.com/my-custom-option などのように、接頭辞としてドメインを追加した名前を使用する必要があります。接頭辞が付いていない名前は、Gateway API が定義する鍵の名前用に予約されています。

サポート: 実装固有

group

string

group は参照先のグループです。たとえば "gateway.networking.k8s.io" です。指定されていないか空の文字列の場合、core API グループが推論されます。

kind

string

kind は参照先の kind です。たとえば "Secret" があります。

name

string

name は参照先の名前です。

namespace

string

namespace は参照されるオブジェクトの namespace です。指定しない場合は、ローカル namespace が推論されます。

ローカル namespace とは異なる namespace を指定する場合、その namespace の所有者が参照を受け入れるためには、参照先 namespace に ReferenceGrant オブジェクトが必要であることに注意してください。詳細は、ReferenceGrant ドキュメントを参照してください。

サポート: Core

addresses

array

addresses には、ゲートウェイにバインドされているネットワークアドレスがリスト表示されます。

一部の条件下では、このリストが仕様で提供されるアドレスと異なる場合があります。

* アドレスが指定されていない場合、すべてのアドレスが動的に割り当てられます * 指定されたアドレスと動的アドレスの組み合わせが割り当てられている場合 * 指定されたアドレスが使用できなかった場合 (すでに使用されているなど)

addresses[]

object

GatewayStatusAddress は、ゲートウェイにバインドされているネットワークアドレスを記述します。

conditions

array

conditions はゲートウェイの現在の条件を記述します。

実装では、Operator とツールがゲートウェイの状態を記述するための共通の語彙に収束できるように、GatewayConditionType および GatewayConditionReason 定数を使用してゲートウェイの状態を表現することを優先する必要があります。

既知の条件タイプは次のとおりです。

* "Accepted" * "Programmed" * "Ready"

conditions[]

object

condition には、この API Resource の現在の状態のある側面の詳細が含まれます。

listeners

array

listeners は、仕様で定義された一意のリスナーポートごとにステータスを指定します。

listeners[]

object

ListenerStatus は、リスナーに関連付けられたステータスです。

type

string

アドレスのタイプ。

value

string

アドレスの値。値の有効性は、コントローラーのタイプとサポートによって異なります。

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

lastTransitionTime

string

lastTransitionTime は、ある状態から別の状態に最後に遷移した時間です。これは、基本的な条件が変更された時点となります。不明な場合には、API フィールドが変更された時点を使用することも可能です。

message

string

message は、遷移の詳細を示す人が判読できるメッセージです。空の文字列の場合もあります。

observedGeneration

integer

observedGeneration は、それをベースに条件が設定された .metadata.generation を表します。たとえば、.metadata.generation が現在 12 で、.status.conditions[x].observedGeneration が 9 の場合、インスタンスの現在の状態に対して条件が古くなっています。

reason

string

reason には、条件の最後の遷移の理由を示すプログラムによる識別子が含まれます。特定の条件タイプのプロデューサーは、このフィールドの期待値と意味、および値が保証された API と見なされるかどうかを定義できます。値は CamelCase 文字列である必要があります。このフィールドには空白を指定できません。

status

string

条件のステータス、True、False、Unknown のいずれか。

type

string

CamelCase または foo.example.com/CamelCase の条件のタイプ。

attachedRoutes

integer

AttachedRoutes は、このリスナーに正常に割り当てられたルートの合計数を表します。

ルートをリスナーに正常に割り当てられるかどうかは、対応するリスナーの AllowedRoutes フィールドとルートの ParentRefs フィールドの組み合わせのみに基づいています。ルートがリスナーの AllowedRoutes フィールドによって選択され、かつ、そのルートにゲートウェイリソース全体または特定のリスナーを親リソースとして選択する有効な ParentRef がある場合、そのルートはリスナーに正常に割り当てられます (割り当てのセマンティクスの詳細は、さまざまな kind のルートの ParentRefs フィールドに関するドキュメントを参照してください)。リスナーまたはルートのステータスは、正常な割り当てには影響しません。つまり、AttachedRoutes フィールドの数は、Accepted: false 条件を持つリスナーに対して設定する必要があり、正常に割り当てられた Accepted: false 条件を持つルートをカウントする必要があります。

このフィールドの用途には、ルート割り当てのトラブルシューティングや、リスナーへの変更による影響範囲の測定などがあります。

conditions

array

conditions は、このリスナーの現在の状態を説明します。

conditions[]

object

condition には、この API Resource の現在の状態のある側面の詳細が含まれます。

name

string

name は、このステータスに対応するリスナーの名前です。

supportedKinds

array

supportedKinds は、このリスナーによってサポートされている Kinds を示すリストです。これは、そのリスナー設定に対して実装がサポートする kinds を表す必要があります。

仕様でサポートされていない kinds が指定されている場合、それらはこのリストに表示されてはならず、実装では "ResolvedRefs" 条件を "InvalidRouteKinds" の理由で "False" に設定する必要があります。有効および無効なルートの kinds が両方指定されている場合、実装では指定された有効なルートの kinds を参照する必要があります。

supportedKinds[]

object

RouteGroupKind は、ルートリソースのグループと kind を示します。

lastTransitionTime

string

lastTransitionTime は、ある状態から別の状態に最後に遷移した時間です。これは、基本的な条件が変更された時点となります。不明な場合には、API フィールドが変更された時点を使用することも可能です。

message

string

message は、遷移の詳細を示す人が判読できるメッセージです。空の文字列の場合もあります。

observedGeneration

integer

observedGeneration は、それをベースに条件が設定された .metadata.generation を表します。たとえば、.metadata.generation が現在 12 で、.status.conditions[x].observedGeneration が 9 の場合、インスタンスの現在の状態に対して条件が古くなっています。

reason

string

reason には、条件の最後の遷移の理由を示すプログラムによる識別子が含まれます。特定の条件タイプのプロデューサーは、このフィールドの期待値と意味、および値が保証された API と見なされるかどうかを定義できます。値は CamelCase 文字列である必要があります。このフィールドには空白を指定できません。

status

string

条件のステータス、True、False、Unknown のいずれか。

type

string

CamelCase または foo.example.com/CamelCase の条件のタイプ。

group

string

group はルートのグループです。

kind

string

kind はルートの kind です。