第10章 DNS [operator.openshift.io/v1]
- Description
- DNS は CoreDNS コンポーネントを管理し、クラスター内の Pod およびサービスの名前解決サービスを提供します。DNS ベースのサービス検出仕様をサポートします。https://github.com/kubernetes/dns/blob/master/docs/specification.md 詳細: https://kubernetes.io/docs/tasks/administer-cluster/coredns 互換性レベル 1: メジャーリリース内で最低 12 か月または 3 つのマイナーリリース(いずれか長い方)の間安定しています。
- タイプ
-
object
10.1. 仕様
プロパティー | タイプ | 説明 |
---|---|---|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。 |
| 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。 | |
|
| spec は、DNS の望ましい動作の仕様です。 |
|
| status は、DNS の最後に観察されたステータスです。 |
10.1.1. .spec
- Description
- spec は、DNS の望ましい動作の仕様です。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| キャッシュは、Corefile にリストされているすべてのサーバーブロックに適用されるキャッシュ設定を記述します。このフィールドを使用すると、クラスター管理者は任意で設定できます。* positiveTTL は、正の応答がキャッシュされる期間です。* negativeTTL。負のレスポンスをキャッシュする期間です。これが設定されていない場合、OpenShift はデフォルト値で、変更される可能性がある正および負のキャッシュを設定します。書き込み時点では、デフォルトの正TTL は 900 秒で、デフォルトの negativeTTL は 30 秒または OpenShift バージョンのそれぞれの Corefile に記載されています。 |
|
| logLevel は、CoreDNS の必要なロギングの詳細度を記述します。次のいずれかの値を指定できます。* アップストリームリゾルバーからの通常のログエラー。* デバッグログ、NXDOMAIN 応答、および NODATA 応答。* トレースは、エラーとすべての応答をログに記録します。logLevel: トレースを設定すると、非常に詳細なログが生成されます。有効な値は、Normal、Debug、Trace です。Defaults to "Normal". |
|
| managementState は、DNSOperator がクラスター DNS を管理する必要があるかどうかを示します |
|
| nodePlacement は、DNSPod のスケジューリングを明示的に制御します。一般に、すべてのノードで DNSPod を実行すると、ネットワークを介して別のノードの DNSPod に移動するのではなく、常にローカル DNSPod によって DNS クエリーが処理されるようになります。ただし、セキュリティーポリシーでは、DNSPod の配置を特定のノードに制限する必要がある場合があります。たとえば、セキュリティーポリシーで、任意のノード上の Pod が API と通信することを禁止している場合、ノードセレクターを指定して、DNSPod を API との通信が許可されているノードに制限できます。逆に、特定のテイントのあるノードで DNSPod を実行する必要がある場合は、そのテイントに対して許容範囲を指定できます。設定されていない場合、デフォルトが使用されます。詳細については、nodePlacement を参照してください。 |
|
| operatorLogLevel は、DNS Operator のログレベルを制御します。有効な値は、Normal、Debug、Trace です。デフォルトは Normal です。operatorLogLevel: トレースを設定すると、非常に詳細なログが生成されます。 |
|
| サーバーは、クラスタードメインのスコープ外にある 1 つ以上のサブドメインに名前クエリーの委任を提供する DNS リゾルバーのリストです。サーバーが複数のサーバーで設定されている場合、サーバーを決定するために最長の接尾辞一致が使用されます。たとえば、foo.com 用と a.foo.com 用の 2 つのサーバーがあり、名前クエリーが www.a.foo.com 用である場合、次のようにサーバーにルーティングされます。ゾーン a.foo.com。このフィールドが nil の場合、サーバーは作成されません。 |
|
| サーバーは、CoreDNS のインスタンスごとに実行されるサーバーのスキーマを定義します。 |
|
| upstreamResolvers は、デフォルトの(".")サーバーの場合、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。このフィールドが指定されていない場合、使用されるアップストリームはデフォルトで /etc/resolv.conf に設定されており、ポリシー "sequential" が設定されます。 |
10.1.2. .spec.cache
- 説明
- キャッシュは、Corefile にリストされているすべてのサーバーブロックに適用されるキャッシュ設定を記述します。このフィールドを使用すると、クラスター管理者は任意で設定できます。* positiveTTL は、正の応答がキャッシュされる期間です。* negativeTTL。負のレスポンスをキャッシュする期間です。これが設定されていない場合、OpenShift はデフォルト値で、変更される可能性がある正および負のキャッシュを設定します。書き込み時点では、デフォルトの正TTL は 900 秒で、デフォルトの negativeTTL は 30 秒または OpenShift バージョンのそれぞれの Corefile に記載されています。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| negativeTTL はオプションで、負の応答がキャッシュされる時間を指定します。設定する場合は、1 秒の値(1 秒)以上である必要があり、理論上の最大値は数年間である必要があります。このフィールドは、10 進数の符号なし期間文字列であり、それぞれにオプションの分数と単位接尾辞が付いています。以下に例を示します。"100s", "1m30s", "12h30m10s".秒の割合である値は、最も近い秒に切り捨てられます。設定した値が 1 秒未満の場合、デフォルト値が使用されます。設定されていない場合、値は 0s になり、OpenShift は、お使いの OpenShift バージョンのそれぞれの Corefile に特に記載がない限り、デフォルト値の 30 秒を使用します。デフォルト値の 30 秒は変更される可能性があります。 |
|
| positiveTTL はオプションで、正の応答がキャッシュされる時間を指定します。設定する場合は、1 秒の値(1 秒)以上である必要があり、理論上の最大値は数年間である必要があります。このフィールドは、10 進数の符号なし期間文字列であり、それぞれにオプションの分数と単位接尾辞が付いています。以下に例を示します。"100s", "1m30s", "12h30m10s".秒の割合である値は、最も近い秒に切り捨てられます。設定した値が 1 秒未満の場合、デフォルト値が使用されます。設定されていない場合、値は 0s になり、OpenShift は、OpenShift バージョンのそれぞれの Corefile で特に記載されていない限り、デフォルト値の 900 秒を使用します。デフォルト値の 900 秒は変更される可能性があります。 |
10.1.3. .spec.nodePlacement
- Description
- nodePlacement は、DNSPod のスケジューリングを明示的に制御します。一般に、すべてのノードで DNSPod を実行すると、ネットワークを介して別のノードの DNSPod に移動するのではなく、常にローカル DNSPod によって DNS クエリーが処理されるようになります。ただし、セキュリティーポリシーでは、DNSPod の配置を特定のノードに制限する必要がある場合があります。たとえば、セキュリティーポリシーで、任意のノード上の Pod が API と通信することを禁止している場合、ノードセレクターを指定して、DNSPod を API との通信が許可されているノードに制限できます。逆に、特定のテイントのあるノードで DNSPod を実行する必要がある場合は、そのテイントに対して許容範囲を指定できます。設定されていない場合、デフォルトが使用されます。詳細については、nodePlacement を参照してください。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| nodeSelector は、DNSPod に適用されるノードセレクターです。空の場合、デフォルトが使用されます。現在は次のとおりです。kubernetes.io/os:linux このデフォルトは変更される可能性があります。設定されている場合、指定されたセレクターが使用され、デフォルトが置き換えられます。 |
|
| tolerations は、DNSPod に適用される許容範囲のリストです。空の場合、DNSOperator は node-role.kubernetes.io/master テイントの許容範囲を設定します。このデフォルトは変更される可能性があります。node-role.kubernetes.io/master テイントの許容値を含めずに許容値を指定すると、すべてのワーカーノードが使用できなくなった場合に停止につながる可能性があるため、リスクが伴う可能性があります。デーモンコントローラーにもいくつかの許容値が追加されていることに注意してください。https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ を参照してください |
|
| この toleration が割り当てられる Pod は、マッチング Operator <operator> を使用してトリプル <key,value,effect> と一致するテイントを許容します。 |
10.1.4. .spec.nodePlacement.tolerations
- Description
- tolerations は、DNSPod に適用される許容範囲のリストです。空の場合、DNSOperator は node-role.kubernetes.io/master テイントの許容範囲を設定します。このデフォルトは変更される可能性があります。node-role.kubernetes.io/master テイントの許容値を含めずに許容値を指定すると、すべてのワーカーノードが使用できなくなった場合に停止につながる可能性があるため、リスクが伴う可能性があります。デーモンコントローラーにもいくつかの許容値が追加されていることに注意してください。https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ を参照してください
- タイプ
-
array
10.1.5. .spec.nodePlacement.tolerations[]
- Description
- この toleration が割り当てられる Pod は、マッチング Operator <operator> を使用してトリプル <key,value,effect> と一致するテイントを許容します。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| effect は、照合するテイントの効果を示します。空の場合は、すべてのテイント効果に一致します。指定されている場合、許可される値は NoSchedule、PreferNoSchedule、および NoExecute です。 |
|
| key は toleration が適用されるテイントキーです。空の場合は、すべてのテイントキーに一致します。キーが空の場合、Operator は Exists である必要があります。この組み合わせは、すべての値とすべてのキーに一致することを意味します。 |
|
| Operator はキーと値の関係を表します。有効な Operator は Exists および Equal です。デフォルトは Equal です。Exists は、値のワイルドカードと同等であるため、Pod は特定のカテゴリーのすべてのテイントに耐えることができます。 |
|
| tolerationSeconds は、toleration (effect は NoExecute でなければならず、NoExecute 以外の場合このフィールドは無視されます) がテイントを許容する期間を表します。デフォルトでは設定されていません。つまり、テイントを永久に許容します (エビクトしないでください)。ゼロ値と負の値は、システムによって 0 (すぐにエビクト) として扱われます。 |
|
| value は、toleration が一致するテイントの値です。Operator が Exists の場合、値は空である必要があります。それ以外の場合は、通常の文字列のみになります。 |
10.1.6. .spec.servers
- Description
- サーバーは、クラスタードメインのスコープ外にある 1 つ以上のサブドメインに名前クエリーの委任を提供する DNS リゾルバーのリストです。サーバーが複数のサーバーで設定されている場合、サーバーを決定するために最長の接尾辞一致が使用されます。たとえば、foo.com 用と a.foo.com 用の 2 つのサーバーがあり、名前クエリーが www.a.foo.com 用である場合、次のようにサーバーにルーティングされます。ゾーン a.foo.com。このフィールドが nil の場合、サーバーは作成されません。
- タイプ
-
array
10.1.7. .spec.servers[]
- Description
- サーバーは、CoreDNS のインスタンスごとに実行されるサーバーのスキーマを定義します。
- タイプ
-
object
プロパティー | タイプ | Description |
---|---|---|
|
| forwardPlugin は、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。 |
|
| name は必須であり、サーバーの一意の名前を指定します。名前は、rfc6335 のサービス名構文に準拠している必要があります。 |
|
| ゾーンは必須であり、サーバーが権限を持つサブドメインを指定します。ゾーンは、サブドメインの rfc1123 定義に準拠している必要があります。クラスタードメイン (つまり、cluster.local) の指定は無効です。 |
10.1.8. .spec.servers[].forwardPlugin
- Description
- forwardPlugin は、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。
- タイプ
-
object
プロパティー | タイプ | Description |
---|---|---|
|
| ポリシーは、クエリー用にアップストリームサーバーが選択される順序を決定するために使用されます。次のいずれかの値を指定できます。* "Random" は、クエリーごとにランダムなアップストリームサーバーを選択します。*roundrobin は、アップストリームサーバーをラウンドロビンの順序で選択し、新しいクエリーごとに次のサーバーに移動します。* シーナンは、1 つの応答まで、新しいクエリーごとに最初のサーバーから開始するまで、アップストリームサーバーを順番にクエリーしようとします。デフォルト値は random です。 |
|
| protocolStrategy は、アップストリーム DNS 要求に使用するプロトコルを指定します。protocolStrategy の有効な値は TCP であり、省略されます。省略すると、これは意見がなく、プラットフォームは妥当なデフォルトを選択することになります。これは時間の経過とともに変更される可能性があります。現在のデフォルトは、元のクライアント要求のプロトコルを使用します。tcp は、クライアント要求が UDP を使用している場合でも、プラットフォームがすべてのアップストリーム DNS 要求に TCP を使用することを指定します。TCP は、準拠していないアップストリームリゾルバーによって作成されたものなど、UDP 固有の問題に便利ですが、より多くの帯域幅を使用したり、DNS 応答時間が増加する可能性があります。protocolStrategy は、CoreDNS がアップストリームリゾルバーに対して行う DNS 要求のプロトコルにのみ影響することに注意してください。クライアントと CoreDNS との間の DNS 要求のプロトコルには影響しません。 |
|
| DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。 |
|
| アップストリーム は、ゾーンのサブドメインの名前クエリーを転送するためのリゾルバーのリストです。CoreDNS の各インスタンスは、アップストリーム のヘルスチェックを実行します。正常なアップストリームが交換中にエラーを返すと、アップストリーム から別のリゾルバーが試行されます。アップストリームは、Policy で指定された順序で選択されます。各アップストリームは、アップストリームが 53 以外のポートでリッスンしている場合、IP アドレスまたは IP: ポートで表されます。forwardPlugin ごとに最大 15 の upstreams が許可されます。 |
10.1.9. .spec.servers[].forwardPlugin.transportConfig
- 説明
- DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。 |
|
| トランスポートを使用すると、クラスター管理者はクラスター DNS とアップストリームリゾルバーの間で DNS-over-TLS 接続を使用するようにオプトインできます。CABundle を設定せずにこのレベルで TLS をトランスポートとして設定すると、システム証明書を使用してアップストリームリゾルバーのサービング証明書を検証することになります。可能な値:"" (空)- これは、明示的な選択が行われていないことを意味し、プラットフォームが時間の経過とともに変更される可能性があります。現在のデフォルトは Cleartext です。"cleartext" - クラスター管理者が指定したクリアテキストオプション。これにより、空の値と同じ機能が生成されますが、クラスター管理者がトランスポートについてより明示的な場合や、TLS から Cleartext に明示的に切り替える場合に役立ちます。"TLS" - これは、DNS クエリーが TLS 接続で送信される必要があることを示します。Transport が TLS に設定されている場合、ServerName も設定する必要があります。ポートがアップストリーム IP に含まれていない場合は、デフォルトで RFC 7858 セクション 3.1 ごとにポート 853 が試行されます。https://datatracker.ietf.org/doc/html/rfc7858#section-3.1 |
10.1.10. .spec.servers[].forwardPlugin.transportConfig.tls
- 説明
- TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。
- タイプ
-
object
- 必須
-
serverName
-
プロパティー | タイプ | 説明 |
---|---|---|
|
|
CABundle は、単一の CA 証明書または CA Bundle のいずれかを含める必要のある ConfigMap を参照します。これにより、クラスター管理者は、アップストリームリゾルバーの証明書を検証するために独自の CA または CA バンドルを提供できます。1.configmap には |
|
| ServerName は、DNS クエリーを転送するときに接続するアップストリームサーバーです。これは、Transport が TLS に設定されている場合に必要です。serverName は RFC 1123 の DNS 命名規則に対して検証され、アップストリームリゾルバーにインストールされている TLS 証明書と一致する必要があります。 |
10.1.11. .spec.servers[].forwardPlugin.transportConfig.tls.caBundle
- 説明
-
CABundle は、単一の CA 証明書または CA Bundle のいずれかを含める必要のある ConfigMap を参照します。これにより、クラスター管理者は、アップストリームリゾルバーの証明書を検証するために独自の CA または CA バンドルを提供できます。1.configmap には
ca-bundle.crt
キーが含まれている必要があります。2. 値は PEM でエンコードされた CA 証明書または CA バンドルである必要があります。3. 管理者は、openshift-config 名前空間にこの configmap を作成する必要があります。4.アップストリームサーバー証明書には、ServerName に一致する Subject Alternative Name (SAN)が含まれている必要があります。 - タイプ
-
object
- 必須
-
name
-
プロパティー | タイプ | 説明 |
---|---|---|
|
| name は、参照される設定マップの metadata.name です。 |
10.1.12. .spec.upstreamResolvers
- 説明
- upstreamResolvers は、デフォルトの(".")サーバーの場合、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。このフィールドが指定されていない場合、使用されるアップストリームはデフォルトで /etc/resolv.conf に設定されており、ポリシー "sequential" が設定されます。
- タイプ
-
object
プロパティー | タイプ | Description |
---|---|---|
|
| ポリシーは、クエリー用にアップストリームサーバーが選択される順序を決定するために使用されます。次のいずれかの値を指定できます。* "Random" は、クエリーごとにランダムなアップストリームサーバーを選択します。*roundrobin は、アップストリームサーバーをラウンドロビンの順序で選択し、新しいクエリーごとに次のサーバーに移動します。* シーナンは、1 つの応答まで、新しいクエリーごとに最初のサーバーから開始するまで、アップストリームサーバーを順番にクエリーしようとします。デフォルト値は Sequential です。 |
|
| protocolStrategy は、アップストリーム DNS 要求に使用するプロトコルを指定します。protocolStrategy の有効な値は TCP であり、省略されます。省略すると、これは意見がなく、プラットフォームは妥当なデフォルトを選択することになります。これは時間の経過とともに変更される可能性があります。現在のデフォルトは、元のクライアント要求のプロトコルを使用します。tcp は、クライアント要求が UDP を使用している場合でも、プラットフォームがすべてのアップストリーム DNS 要求に TCP を使用することを指定します。TCP は、準拠していないアップストリームリゾルバーによって作成されたものなど、UDP 固有の問題に便利ですが、より多くの帯域幅を使用したり、DNS 応答時間が増加する可能性があります。protocolStrategy は、CoreDNS がアップストリームリゾルバーに対して行う DNS 要求のプロトコルにのみ影響することに注意してください。クライアントと CoreDNS との間の DNS 要求のプロトコルには影響しません。 |
|
| DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。 |
|
| upstreams は、. ドメインの名前クエリーを転送するためのリゾルバーのリストです。CoreDNS の各インスタンスは、アップストリーム のヘルスチェックを実行します。正常なアップストリームが交換中にエラーを返すと、アップストリーム から別のリゾルバーが試行されます。アップストリームは、Policy で指定された順序で選択されます。forwardPlugin ごとに最大 15 の upstreams が許可されます。Upstreams を指定しないと、デフォルトで /etc/resolv.conf が使用されます。 |
|
| upstream のタイプは、SystemResolvConf タイプ、または Network タイプのいずれかになります。* SystemResolvConf タイプの Upstream の場合、追加のフィールドは必要ありません:アップストリームは /etc/resolv.conf を使用するよう設定されます。*Network タイプの Upstream の場合は、アップストリームが 53 以外のポートでリッスンしている場合は、NetworkResolver フィールドを IP アドレスまたは IP:port で定義する必要があります。 |
10.1.13. .spec.upstreamResolvers.transportConfig
- 説明
- DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。 |
|
| トランスポートを使用すると、クラスター管理者はクラスター DNS とアップストリームリゾルバーの間で DNS-over-TLS 接続を使用するようにオプトインできます。CABundle を設定せずにこのレベルで TLS をトランスポートとして設定すると、システム証明書を使用してアップストリームリゾルバーのサービング証明書を検証することになります。可能な値:"" (空)- これは、明示的な選択が行われていないことを意味し、プラットフォームが時間の経過とともに変更される可能性があります。現在のデフォルトは Cleartext です。"cleartext" - クラスター管理者が指定したクリアテキストオプション。これにより、空の値と同じ機能が生成されますが、クラスター管理者がトランスポートについてより明示的な場合や、TLS から Cleartext に明示的に切り替える場合に役立ちます。"TLS" - これは、DNS クエリーが TLS 接続で送信される必要があることを示します。Transport が TLS に設定されている場合、ServerName も設定する必要があります。ポートがアップストリーム IP に含まれていない場合は、デフォルトで RFC 7858 セクション 3.1 ごとにポート 853 が試行されます。https://datatracker.ietf.org/doc/html/rfc7858#section-3.1 |
10.1.14. .spec.upstreamResolvers.transportConfig.tls
- 説明
- TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。
- タイプ
-
object
- 必須
-
serverName
-
プロパティー | タイプ | 説明 |
---|---|---|
|
|
CABundle は、単一の CA 証明書または CA Bundle のいずれかを含める必要のある ConfigMap を参照します。これにより、クラスター管理者は、アップストリームリゾルバーの証明書を検証するために独自の CA または CA バンドルを提供できます。1.configmap には |
|
| ServerName は、DNS クエリーを転送するときに接続するアップストリームサーバーです。これは、Transport が TLS に設定されている場合に必要です。serverName は RFC 1123 の DNS 命名規則に対して検証され、アップストリームリゾルバーにインストールされている TLS 証明書と一致する必要があります。 |
10.1.15. .spec.upstreamResolvers.transportConfig.tls.caBundle
- 説明
-
CABundle は、単一の CA 証明書または CA Bundle のいずれかを含める必要のある ConfigMap を参照します。これにより、クラスター管理者は、アップストリームリゾルバーの証明書を検証するために独自の CA または CA バンドルを提供できます。1.configmap には
ca-bundle.crt
キーが含まれている必要があります。2. 値は PEM でエンコードされた CA 証明書または CA バンドルである必要があります。3. 管理者は、openshift-config 名前空間にこの configmap を作成する必要があります。4.アップストリームサーバー証明書には、ServerName に一致する Subject Alternative Name (SAN)が含まれている必要があります。 - タイプ
-
object
- 必須
-
name
-
プロパティー | タイプ | 説明 |
---|---|---|
|
| name は、参照される設定マップの metadata.name です。 |
10.1.16. .spec.upstreamResolvers.upstreams
- 説明
- upstreams は、. ドメインの名前クエリーを転送するためのリゾルバーのリストです。CoreDNS の各インスタンスは、アップストリーム のヘルスチェックを実行します。正常なアップストリームが交換中にエラーを返すと、アップストリーム から別のリゾルバーが試行されます。アップストリームは、Policy で指定された順序で選択されます。forwardPlugin ごとに最大 15 の upstreams が許可されます。Upstreams を指定しないと、デフォルトで /etc/resolv.conf が使用されます。
- タイプ
-
array
10.1.17. .spec.upstreamResolvers.upstreams[]
- 説明
- upstream のタイプは、SystemResolvConf タイプ、または Network タイプのいずれかになります。* SystemResolvConf タイプの Upstream の場合、追加のフィールドは必要ありません:アップストリームは /etc/resolv.conf を使用するよう設定されます。*Network タイプの Upstream の場合は、アップストリームが 53 以外のポートでリッスンしている場合は、NetworkResolver フィールドを IP アドレスまたは IP:port で定義する必要があります。
- タイプ
-
object
- 必須
-
type
-
プロパティー | タイプ | 説明 |
---|---|---|
|
| Address は、Type が Network に設定されている場合に定義する必要があります。それ以外の場合は無視されます。有効な ipv4 アドレスまたは ipv6 アドレスである必要があります。 |
|
| Port は、Type が Network に設定されている場合に定義できます。それ以外の場合は無視されます。ポートは 65535 までの値でなければなりません。 |
|
| type は、このアップストリームに IP/IP:port リゾルバーまたはローカルの /etc/resolv.conf が含まれるかどうかを定義します。type は、SystemResolvConf または Network の 2 つの値を受け入れます。* SystemResolvConf を使用する場合、Upstream 構造体を定義する必要はありません:/etc/resolv.conf が使用されます * ネットワークを使用する場合、アップストリーム構造には少なくとも Address が含まれる必要があります。 |
10.1.18. .status
- Description
- status は、DNS の最後に観察されたステータスです。
- タイプ
-
object
- 必須
-
clusterDomain
-
clusterIP
-
プロパティー | タイプ | Description |
---|---|---|
|
| clusterDomain は、DNS サービスのローカルクラスター DNS ドメイン接尾辞です。これは、RFC 1034 のセクション 3.5 で定義されているサブドメインです。 https://tools.ietf.org/html/rfc1034#section-3.5 例: "cluster.local" 詳細: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service |
|
| clusterIP は、この DNS を利用できるようにするためのサービス IP です。デフォルトの DNS の場合、これは既知の IP であり、デフォルトの ClusterFirstDNS ポリシーを使用している Pod のデフォルトのネームサーバーとして使用されます。一般に、この IP は、Pod の spec.dnsConfig.nameservers リストで指定するか、クラスター内から名前解決を実行するときに明示的に使用できます。例: dig foo.com @<service IP> 詳細: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies |
|
| 条件は、クラスター上の DNS の状態に関する情報を提供します。サポートされている DNS 条件は次のとおりです。*使用可能 - 次の条件が満たされた場合に真になります。*DNS コントローラーデーモンセットが使用可能です。- これらの条件のいずれかが満たされていない場合は False。 |
|
| OperatorCondition は、単なる標準の条件フィールドです。 |
10.1.19. .status.conditions
- Description
- 条件は、クラスター上の DNS の状態に関する情報を提供します。サポートされている DNS 条件は次のとおりです。*使用可能 - 次の条件が満たされた場合に真になります。*DNS コントローラーデーモンセットが使用可能です。- これらの条件のいずれかが満たされていない場合は False。
- タイプ
-
array
10.1.20. .status.conditions[]
- Description
- OperatorCondition は、単なる標準の条件フィールドです。
- タイプ
-
object
プロパティー | タイプ | 説明 |
---|---|---|
|
| |
|
| |
|
| |
|
| |
|
|