6.6. OpenShift Container Platform の DNS Operator


OpenShift Container Platform の DNS Operator は、CoreDNS インスタンスをデプロイおよび管理して、クラスター内の Pod に名前解決サービスを提供し、DNS ベースの Kubernetes Service 検出を有効にし、内部の cluster.local 名を解決します。

6.6.1. DNS Operator のステータスの確認

DNS Operator は、operator.openshift.io API グループから dns API を実装します。この Operator は、デーモンセットを使用して CoreDNS をデプロイし、デーモンセットのサービスを作成し、kubelet を Pod に対して名前解決に CoreDNS サービス IP を使用するように指示するように設定します。

手順

DNS Operator は、インストール時に Deployment オブジェクトを使用してデプロイされます。

  1. oc get コマンドを使用してデプロイメントのステータスを表示します。

    $ oc get -n openshift-dns-operator deployment/dns-operator

    出力例

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h

  2. oc get コマンドを使用して DNS Operator の状態を表示します。

    $ oc get clusteroperator/dns

    出力例

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    dns       4.1.15-0.11  True        False         False      92m

    AVAILABLEPROGRESSING、および DEGRADED は、Operator のステータスに関する情報を示します。AVAILABLETrue になるのは、CoreDNS デーモンセットの 1 つ以上の Pod が AVAILABLE ステータス条件を報告し、DNS サービスがクラスター IP アドレスを持っている場合です。

6.6.2. デフォルト DNS の表示

すべての新規 OpenShift Container Platform インストールには、default という名前の dns.operator があります。

手順

  1. oc describe コマンドを使用してデフォルトの dns を表示します。

    $ oc describe dns.operator/default

    出力例

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 1
      Cluster IP:      172.30.0.10 2
    ...

    1
    Cluster Domain フィールドは、完全修飾 Pod およびサービスドメイン名を作成するために使用されるベース DNS ドメインです。
    2
    クラスター IP は、Pod が名前解決のためにクエリーするアドレスです。IP は、サービス CIDR 範囲の 10 番目のアドレスで定義されます。
  2. クラスターのサービス CIDR 範囲を確認するには、oc get コマンドを使用します。

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

    出力例

    [172.30.0.0/16]

6.6.3. DNS 転送の使用

次の方法で、DNS 転送を使用して /etc/resolv.conf ファイル内のデフォルトの転送設定をオーバーライドできます。

  • すべてのゾーンにネームサーバー (spec.servers) を指定します。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、そのドメインに対してアップストリームのネームサーバーが許可されている必要があります。
  • アップストリーム DNS サーバーのリスト (spec.upstreamResolvers) を指定します。
  • デフォルトの転送ポリシーを変更します。
注記

デフォルトドメインの DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。

手順

  1. default という名前の DNS Operator オブジェクトを変更します。

    $ oc edit dns.operator/default

    上記のコマンドを実行すると、Operator が、spec.servers に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成および更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。

    DNS 転送の設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        negativeTTL: 0s
        positiveTTL: 0s
      logLevel: Normal
      nodePlacement: {}
      operatorLogLevel: Normal
      servers:
      - name: example-server 1
        zones:
        - example.com 2
        forwardPlugin:
          policy: Random 3
          upstreams: 4
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 5
        policy: Random 6
        protocolStrategy: ""  7
        transportConfig: {}  8
        upstreams:
        - type: SystemResolvConf 9
        - type: Network
          address: 1.2.3.4 10
          port: 53 11
        status:
          clusterDomain: cluster.local
          clusterIP: x.y.z.10
          conditions:
       ...

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。
    3
    forwardPlugin にリストされているアップストリームリゾルバーを選択するポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。
    4
    forwardPlugin ごとに最大 15 の upstreams が許可されます。
    5
    upstreamResolvers を使用すると、デフォルトの転送ポリシーをオーバーライドし、デフォルトドメインの指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを提供しなかった場合、DNS 名のクエリーが /etc/resolv.conf で宣言されたサーバーに送信されます。
    6
    upstreams にリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。RandomRoundRobin、または Sequential のいずれかの値を指定できます。デフォルト値は Sequential です。
    7
    省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。TCP に設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。
    8
    DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
    9
    2 種類の upstreams (SystemResolvConf または Network) を指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、NetworkNetworkresolver を定義します。1 つまたは両方を指定できます。
    10
    指定したタイプがNetworkの場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    11
    指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドには 1 - 65535 の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。

関連情報

6.6.4. DNS Operator のステータスの確認

oc describe コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。

手順

  • DNS Operator のステータスを表示します。

    $ oc describe clusteroperators/dns

    メッセージとスペルはリリースによって異なる場合がありますが、期待されるステータス出力は次のようになります。

    Status:
      Conditions:
        Last Transition Time:  <date>
        Message:               DNS "default" is available.
        Reason:                AsExpected
        Status:                True
        Type:                  Available
        Last Transition Time:  <date>
        Message:               Desired and current number of DNSes are equal
        Reason:                AsExpected
        Status:                False
        Type:                  Progressing
        Last Transition Time:  <date>
        Reason:                DNSNotDegraded
        Status:                False
        Type:                  Degraded
        Last Transition Time:  <date>
        Message:               DNS default is upgradeable: DNS Operator can be upgraded
        Reason:                DNSUpgradeable
        Status:                True
        Type:                  Upgradeable

6.6.5. DNS Operator のログの表示

oc logs コマンドを使用して、DNS Operator ログを表示できます。

手順

  • DNS Operator のログを表示します。

    $ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

6.6.6. CoreDNS ログレベルの設定

CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。CoreDNS ログレベルを設定して、ログに記録されたエラーメッセージの情報量を決定できます。CoreDNS ログレベルの有効な値は、NormalDebug、および Trace です。デフォルトの logLevelNormal です。

注記

CoreDNS のエラーログレベルは常に有効です。次のログレベル設定では、それぞれ異なるエラー応答が報告されます。

  • logLevel: Normalは "errors" class: log . { class error } を有効にします。
  • logLevel: Debugは "denial" class: log . { class denial error } を有効にします。
  • logLevel: Traceは "all" class: log . { class all } を有効にします。

手順

  • logLevelDebug に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
  • logLevelTrace に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge

検証

  • 目的のログレベルが設定されていることを確認するには、config map を確認します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    たとえば、logLevelTrace に設定すると、各サーバーブロックに次のスタンザが表示されます。

    errors
    log . {
        class all
    }

6.6.7. CoreDNS Operator のログレベルの設定

CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel の有効な値は、NormalDebug、およびTraceです。Trace には最も詳細にわたる情報が含まれます。デフォルトのoperatorlogLevelNormalです。Operator の問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal、および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。

  • operatorLogLevel: "Normal"logrus.SetLogLevel("Info") を設定します。
  • operatorLogLevel: "Debug"logrus.SetLogLevel("Debug") を設定します。
  • operatorLogLevel: "Trace"logrus.SetLogLevel("Trace") を設定します。

手順

  • operatorLogLevelDebugに設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
  • operatorLogLevelTraceに設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge

検証

  1. 結果の変更を確認するには、次のコマンドを入力します。

    $ oc get dnses.operator -A -oyaml

    2 つのログレベルのエントリーが表示されるはずです。operatorLogLevel は OpenShift DNS Operator の問題に適用され、logLevel は CoreDNS Pod のデーモンセットに適用されます。

     logLevel: Trace
     operatorLogLevel: Debug
  2. デーモンセットのログを確認するには、次のコマンドを入力します。

    $ oc logs -n openshift-dns ds/dns-default

6.6.8. CoreDNS キャッシュのチューニング

CoreDNS の場合、成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間をチューニングすると、アップストリーム DNS リゾルバーの負荷を軽減できます。

警告

TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。

手順

  1. 次のコマンドを実行して、default という名前の DNS Operator オブジェクトを編集します。

    $ oc edit dns.operator.openshift.io/default
  2. Time-to-Live (TTL) キャッシュ値を変更します。

    DNS キャッシングの設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        positiveTTL: 1h 1
        negativeTTL: 0.5h10m 2

    1
    文字列値 1h は、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 900 を使用します。
    2
    文字列値は、0.5h10m などの単位の組み合わせにすることができ、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 30 を使用します。

検証

  1. 変更を確認するには、次のコマンドを実行して config map を再度確認します。

    oc get configmap/dns-default -n openshift-dns -o yaml
  2. 次の例のようなエントリーが表示されていることを確認します。

           cache 3600 {
                denial 9984 2400
            }

関連情報

キャッシュの詳細は、CoreDNS cache を参照してください。

6.6.9. 高度なタスク

6.6.9.1. DNS Operator managementState の変更

DNS Operator は、CoreDNS コンポーネントを管理し、クラスター内の Pod とサービスに名前解決サービスを提供します。DNS Operator の managementState は、デフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理していることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

  • 開発者は、CoreDNS の問題が修正されているかどうかを確認するために、設定変更をテストする必要があります。managementStateUnmanaged に設定することで、DNS Operator による設定変更の上書きを防止できます。
  • クラスター管理者は、CoreDNS の問題を報告していますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の managementState フィールドを Unmanaged に設定して、回避策を適用できます。

手順

  1. DNS Operator の managementStateUnmanated に変更します。

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
  2. jsonpath コマンドライン JSON パーサーを使用して DNS Operator の managementState を確認します。

    $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

    出力例

    "Unmanaged"

注記

managementStateUnmanaged に設定されている間はアップグレードできません。

6.6.9.2. DNS Pod 配置の制御

DNS Operator には 2 つのデーモンセットがあります。1 つは CoreDNS 用の dns-default という名前のデーモンセットで、もう 1 つは /etc/hosts ファイルの管理用の node-resolver という名前のデーモンセットです。

場合によっては、どのノードに CoreDNS Pod を割り当てて実行するかを制御する必要があります (ただし、これは一般的な操作ではありません)。たとえば、クラスター管理者がノードのペア間の通信を禁止できるセキュリティーポリシーを設定している場合、CoreDNS のデーモンセットが実行されるノードのセットを制限する必要があります。DNS Pod がクラスター内の一部のノードで実行されており、DNS Pod が実行されていないノードから DNS Pod が実行されているノードへのネットワーク接続がある場合、すべての Pod で DNS サービスが利用可能になります。

node-resolver デーモンセットは、すべてのノードホストで実行する必要があります。このデーモンセットにより、イメージのプルをサポートするクラスターイメージレジストリーのエントリーが追加されるためです。node-resolver Pod には、1 つのジョブのみがあります。コンテナーランタイムがサービス名を解決できるように、image-registry.openshift-image-registry.svc サービスのクラスター IP アドレスを検索し、それをノードホストの /etc/hosts に追加するジョブです。

クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。

前提条件

  • oc CLI がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • DNS Operator の managementStateManaged に設定されている。

手順

  • CoreDNS のデーモンセットを特定のノードで実行できるようにするために、taint と toleration を設定します。

    1. default という名前の DNS Operator オブジェクトを変更します。

      $ oc edit dns.operator/default
    2. taint の taint キーおよび toleration を指定します。

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only"
             operators: Equal
             value: abc
             tolerationSeconds: 3600 1
      1
      taint が dns-only である場合、それは無制限に許容できます。tolerationSeconds は省略できます。

6.6.9.3. TLS を使用した DNS 転送の設定

高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。

CoreDNS は転送された接続を 10 秒間キャッシュすることに注意してください。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。

手順

  1. default という名前の DNS Operator オブジェクトを変更します。

    $ oc edit dns.operator/default

    クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。

    TLS を使用した DNS 転送の設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: example-server 1
        zones:
        - example.com 2
        forwardPlugin:
          transportConfig:
            transport: TLS 3
            tls:
              caBundle:
                name: mycacert
              serverName: dnstls.example.com  4
          policy: Random 5
          upstreams: 6
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 7
        transportConfig:
          transport: TLS
          tls:
            caBundle:
              name: mycacert
            serverName: dnstls.example.com
        upstreams:
        - type: Network 8
          address: 1.2.3.4 9
          port: 53 10

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。クラスタードメインの cluster.local は、zones の無効な subdomain です。
    3
    転送された DNS クエリーの TLS を設定する場合、transport フィールドの値を TLS に設定します。
    4
    転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。
    5
    アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。
    6
    必須。アップストリームリゾルバーを指定するために使用します。forwardPlugin エントリーごとに最大 15 の upstreams エントリーが許可されます。
    7
    任意。これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。
    8
    TLS を使用する場合、Network タイプのみが許可され、IP アドレスを指定する必要があります。Network タイプは、このアップストリームリゾルバーが /etc/resolv.conf にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。
    9
    address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    10
    オプションでポートを指定できます。port の値は 165535 である必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。
    注記

    servers が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。

検証

  1. config map を表示します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    TLS 転送の例に基づく DNS ConfigMap のサンプル

    apiVersion: v1
    data:
      Corefile: |
        example.com:5353 {
            forward . 1.1.1.1 2.2.2.2:5353
        }
        bar.com:5353 example.com:5353 {
            forward . 3.3.3.3 4.4.4.4:5454 1
        }
        .:5353 {
            errors
            health
            kubernetes cluster.local in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            prometheus :9153
            forward . /etc/resolv.conf 1.2.3.4:53 {
                policy Random
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns

    1
    forwardPlugin への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.