第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

string

APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。

kind

string

kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。

metadata

ObjectMeta

標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。

spec

object

spec は、DNS の望ましい動作の仕様です。

status

object

status は、DNS の最後に観察されたステータスです。

10.1.1. .spec

Description
spec は、DNS の望ましい動作の仕様です。
タイプ
object
プロパティータイプ説明

cache

object

キャッシュは、Corefile にリストされているすべてのサーバーブロックに適用されるキャッシュ設定を記述します。このフィールドを使用すると、クラスター管理者は任意で設定できます。* positiveTTL は、正の応答がキャッシュされる期間です。* negativeTTL。負のレスポンスをキャッシュする期間です。これが設定されていない場合、OpenShift はデフォルト値で、変更される可能性がある正および負のキャッシュを設定します。書き込み時点では、デフォルトの正TTL は 900 秒で、デフォルトの negativeTTL は 30 秒または OpenShift バージョンのそれぞれの Corefile に記載されています。

logLevel

string

logLevel は、CoreDNS の必要なロギングの詳細度を記述します。次のいずれかの値を指定できます。* アップストリームリゾルバーからの通常のログエラー。* デバッグログ、NXDOMAIN 応答、および NODATA 応答。* トレースは、エラーとすべての応答をログに記録します。logLevel: トレースを設定すると、非常に詳細なログが生成されます。有効な値は、Normal、Debug、Trace です。Defaults to "Normal".

managementState

string

managementState は、DNSOperator がクラスター DNS を管理する必要があるかどうかを示します

nodePlacement

object

nodePlacement は、DNSPod のスケジューリングを明示的に制御します。一般に、すべてのノードで DNSPod を実行すると、ネットワークを介して別のノードの DNSPod に移動するのではなく、常にローカル DNSPod によって DNS クエリーが処理されるようになります。ただし、セキュリティーポリシーでは、DNSPod の配置を特定のノードに制限する必要がある場合があります。たとえば、セキュリティーポリシーで、任意のノード上の Pod が API と通信することを禁止している場合、ノードセレクターを指定して、DNSPod を API との通信が許可されているノードに制限できます。逆に、特定のテイントのあるノードで DNSPod を実行する必要がある場合は、そのテイントに対して許容範囲を指定できます。設定されていない場合、デフォルトが使用されます。詳細については、nodePlacement を参照してください。

operatorLogLevel

string

operatorLogLevel は、DNS Operator のログレベルを制御します。有効な値は、Normal、Debug、Trace です。デフォルトは Normal です。operatorLogLevel: トレースを設定すると、非常に詳細なログが生成されます。

servers

array

サーバーは、クラスタードメインのスコープ外にある 1 つ以上のサブドメインに名前クエリーの委任を提供する DNS リゾルバーのリストです。サーバーが複数のサーバーで設定されている場合、サーバーを決定するために最長の接尾辞一致が使用されます。たとえば、foo.com 用と a.foo.com 用の 2 つのサーバーがあり、名前クエリーが www.a.foo.com 用である場合、次のようにサーバーにルーティングされます。ゾーン a.foo.com。このフィールドが nil の場合、サーバーは作成されません。

servers[]

object

サーバーは、CoreDNS のインスタンスごとに実行されるサーバーのスキーマを定義します。

upstreamResolvers

object

upstreamResolvers は、デフォルトの(".")サーバーの場合、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。このフィールドが指定されていない場合、使用されるアップストリームはデフォルトで /etc/resolv.conf に設定されており、ポリシー "sequential" が設定されます。

10.1.2. .spec.cache

説明
キャッシュは、Corefile にリストされているすべてのサーバーブロックに適用されるキャッシュ設定を記述します。このフィールドを使用すると、クラスター管理者は任意で設定できます。* positiveTTL は、正の応答がキャッシュされる期間です。* negativeTTL。負のレスポンスをキャッシュする期間です。これが設定されていない場合、OpenShift はデフォルト値で、変更される可能性がある正および負のキャッシュを設定します。書き込み時点では、デフォルトの正TTL は 900 秒で、デフォルトの negativeTTL は 30 秒または OpenShift バージョンのそれぞれの Corefile に記載されています。
タイプ
object
プロパティータイプ説明

negativeTTL

string

negativeTTL はオプションで、負の応答がキャッシュされる時間を指定します。設定する場合は、1 秒の値(1 秒)以上である必要があり、理論上の最大値は数年間である必要があります。このフィールドは、10 進数の符号なし期間文字列であり、それぞれにオプションの分数と単位接尾辞が付いています。以下に例を示します。"100s", "1m30s", "12h30m10s".秒の割合である値は、最も近い秒に切り捨てられます。設定した値が 1 秒未満の場合、デフォルト値が使用されます。設定されていない場合、値は 0s になり、OpenShift は、お使いの OpenShift バージョンのそれぞれの Corefile に特に記載がない限り、デフォルト値の 30 秒を使用します。デフォルト値の 30 秒は変更される可能性があります。

positiveTTL

string

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

object (string)

nodeSelector は、DNSPod に適用されるノードセレクターです。空の場合、デフォルトが使用されます。現在は次のとおりです。kubernetes.io/os:linux このデフォルトは変更される可能性があります。設定されている場合、指定されたセレクターが使用され、デフォルトが置き換えられます。

tolerations

array

tolerations は、DNSPod に適用される許容範囲のリストです。空の場合、DNSOperator は node-role.kubernetes.io/master テイントの許容範囲を設定します。このデフォルトは変更される可能性があります。node-role.kubernetes.io/master テイントの許容値を含めずに許容値を指定すると、すべてのワーカーノードが使用できなくなった場合に停止につながる可能性があるため、リスクが伴う可能性があります。デーモンコントローラーにもいくつかの許容値が追加されていることに注意してください。https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ を参照してください

tolerations[]

object

この 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

string

effect は、照合するテイントの効果を示します。空の場合は、すべてのテイント効果に一致します。指定されている場合、許可される値は NoSchedule、PreferNoSchedule、および NoExecute です。

key

string

key は toleration が適用されるテイントキーです。空の場合は、すべてのテイントキーに一致します。キーが空の場合、Operator は Exists である必要があります。この組み合わせは、すべての値とすべてのキーに一致することを意味します。

operator

string

Operator はキーと値の関係を表します。有効な Operator は Exists および Equal です。デフォルトは Equal です。Exists は、値のワイルドカードと同等であるため、Pod は特定のカテゴリーのすべてのテイントに耐えることができます。

tolerationSeconds

integer

tolerationSeconds は、toleration (effect は NoExecute でなければならず、NoExecute 以外の場合このフィールドは無視されます) がテイントを許容する期間を表します。デフォルトでは設定されていません。つまり、テイントを永久に許容します (エビクトしないでください)。ゼロ値と負の値は、システムによって 0 (すぐにエビクト) として扱われます。

value

string

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

object

forwardPlugin は、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。

name

string

name は必須であり、サーバーの一意の名前を指定します。名前は、rfc6335 のサービス名構文に準拠している必要があります。

ゾーン

array (string)

ゾーンは必須であり、サーバーが権限を持つサブドメインを指定します。ゾーンは、サブドメインの rfc1123 定義に準拠している必要があります。クラスタードメイン (つまり、cluster.local) の指定は無効です。

10.1.8. .spec.servers[].forwardPlugin

Description
forwardPlugin は、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。
タイプ
object
プロパティータイプDescription

policy

string

ポリシーは、クエリー用にアップストリームサーバーが選択される順序を決定するために使用されます。次のいずれかの値を指定できます。* "Random" は、クエリーごとにランダムなアップストリームサーバーを選択します。*roundrobin は、アップストリームサーバーをラウンドロビンの順序で選択し、新しいクエリーごとに次のサーバーに移動します。* シーナンは、1 つの応答まで、新しいクエリーごとに最初のサーバーから開始するまで、アップストリームサーバーを順番にクエリーしようとします。デフォルト値は random です。

protocolStrategy

string

protocolStrategy は、アップストリーム DNS 要求に使用するプロトコルを指定します。protocolStrategy の有効な値は TCP であり、省略されます。省略すると、これは意見がなく、プラットフォームは妥当なデフォルトを選択することになります。これは時間の経過とともに変更される可能性があります。現在のデフォルトは、元のクライアント要求のプロトコルを使用します。tcp は、クライアント要求が UDP を使用している場合でも、プラットフォームがすべてのアップストリーム DNS 要求に TCP を使用することを指定します。TCP は、準拠していないアップストリームリゾルバーによって作成されたものなど、UDP 固有の問題に便利ですが、より多くの帯域幅を使用したり、DNS 応答時間が増加する可能性があります。protocolStrategy は、CoreDNS がアップストリームリゾルバーに対して行う DNS 要求のプロトコルにのみ影響することに注意してください。クライアントと CoreDNS との間の DNS 要求のプロトコルには影響しません。

transportConfig

object

DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。

upstreams

array (string)

アップストリーム は、ゾーンのサブドメインの名前クエリーを転送するためのリゾルバーのリストです。CoreDNS の各インスタンスは、アップストリーム のヘルスチェックを実行します。正常なアップストリームが交換中にエラーを返すと、アップストリーム から別のリゾルバーが試行されます。アップストリームは、Policy で指定された順序で選択されます。各アップストリームは、アップストリームが 53 以外のポートでリッスンしている場合、IP アドレスまたは IP: ポートで表されます。forwardPlugin ごとに最大 15 の upstreams が許可されます。

10.1.9. .spec.servers[].forwardPlugin.transportConfig

説明
DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。
タイプ
object
プロパティータイプ説明

tls

object

TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。

transport

string

トランスポートを使用すると、クラスター管理者はクラスター 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

object

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)が含まれている必要があります。

serverName

string

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

string

name は、参照される設定マップの metadata.name です。

10.1.12. .spec.upstreamResolvers

説明
upstreamResolvers は、デフォルトの(".")サーバーの場合、DNS メッセージをアップストリームリゾルバーにプロキシーするように CoreDNS を設定するためのスキーマを定義します。このフィールドが指定されていない場合、使用されるアップストリームはデフォルトで /etc/resolv.conf に設定されており、ポリシー "sequential" が設定されます。
タイプ
object
プロパティータイプDescription

policy

string

ポリシーは、クエリー用にアップストリームサーバーが選択される順序を決定するために使用されます。次のいずれかの値を指定できます。* "Random" は、クエリーごとにランダムなアップストリームサーバーを選択します。*roundrobin は、アップストリームサーバーをラウンドロビンの順序で選択し、新しいクエリーごとに次のサーバーに移動します。* シーナンは、1 つの応答まで、新しいクエリーごとに最初のサーバーから開始するまで、アップストリームサーバーを順番にクエリーしようとします。デフォルト値は Sequential です。

protocolStrategy

string

protocolStrategy は、アップストリーム DNS 要求に使用するプロトコルを指定します。protocolStrategy の有効な値は TCP であり、省略されます。省略すると、これは意見がなく、プラットフォームは妥当なデフォルトを選択することになります。これは時間の経過とともに変更される可能性があります。現在のデフォルトは、元のクライアント要求のプロトコルを使用します。tcp は、クライアント要求が UDP を使用している場合でも、プラットフォームがすべてのアップストリーム DNS 要求に TCP を使用することを指定します。TCP は、準拠していないアップストリームリゾルバーによって作成されたものなど、UDP 固有の問題に便利ですが、より多くの帯域幅を使用したり、DNS 応答時間が増加する可能性があります。protocolStrategy は、CoreDNS がアップストリームリゾルバーに対して行う DNS 要求のプロトコルにのみ影響することに注意してください。クライアントと CoreDNS との間の DNS 要求のプロトコルには影響しません。

transportConfig

object

DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。デフォルト値は "" (空)で、DNS 要求をアップストリームリゾルバーに転送するときに標準のクリアテキスト接続が使用されます。

upstreams

array

upstreams は、. ドメインの名前クエリーを転送するためのリゾルバーのリストです。CoreDNS の各インスタンスは、アップストリーム のヘルスチェックを実行します。正常なアップストリームが交換中にエラーを返すと、アップストリーム から別のリゾルバーが試行されます。アップストリームは、Policy で指定された順序で選択されます。forwardPlugin ごとに最大 15 の upstreams が許可されます。Upstreams を指定しないと、デフォルトで /etc/resolv.conf が使用されます。

upstreams

object

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

object

TLS には、Transport が TLS に設定されている場合に使用する追加の設定オプションが含まれています。

transport

string

トランスポートを使用すると、クラスター管理者はクラスター 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

object

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)が含まれている必要があります。

serverName

string

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

string

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

string

Address は、Type が Network に設定されている場合に定義する必要があります。それ以外の場合は無視されます。有効な ipv4 アドレスまたは ipv6 アドレスである必要があります。

port

integer

Port は、Type が Network に設定されている場合に定義できます。それ以外の場合は無視されます。ポートは 65535 までの値でなければなりません。

type

string

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

string

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

string

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

conditions

array

条件は、クラスター上の DNS の状態に関する情報を提供します。サポートされている DNS 条件は次のとおりです。*使用可能 - 次の条件が満たされた場合に真になります。*DNS コントローラーデーモンセットが使用可能です。- これらの条件のいずれかが満たされていない場合は False。

conditions[]

object

OperatorCondition は、単なる標準の条件フィールドです。

10.1.19. .status.conditions

Description
条件は、クラスター上の DNS の状態に関する情報を提供します。サポートされている DNS 条件は次のとおりです。*使用可能 - 次の条件が満たされた場合に真になります。*DNS コントローラーデーモンセットが使用可能です。- これらの条件のいずれかが満たされていない場合は False。
タイプ
array

10.1.20. .status.conditions[]

Description
OperatorCondition は、単なる標準の条件フィールドです。
タイプ
object
プロパティータイプ説明

lastTransitionTime

string

 

message

string

 

reason

string

 

status

string

 

type

string

 
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.