検索

8.9. 高度なタスク

download PDF

8.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 に設定されている間はアップグレードできません。

8.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 のデーモンセットを特定のノードで実行できるようにするために、テイントと許容を設定します。

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

      $ oc edit dns.operator/default
    2. テイントのテイントキーおよび容認を指定します。

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

8.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.