Container Service for Kubernetes:アンマネージド CoreDNS の設定

このトピックでは、ACK クラスターの CoreDNS を名前解決に使用するシナリオについて説明します。このシナリオでは、次のサンプル設定に示すように、dnsPolicy: ClusterFirst ポリシーが使用されます。

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: default
spec:
  containers:
  - image: alpine
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alpine
  dnsPolicy: ClusterFirst

ACK クラスターには、kube-system 名前空間に CoreDNS の設定項目が含まれています。CoreDNS は、この設定項目に基づいてプラグインを有効化し、設定します。設定項目は CoreDNS のバージョンによって若干異なる場合があります。設定を変更する前に、CoreDNS の公式ドキュメントをご参照ください。次のコードは、CoreDNS 1.6.2 のデフォルト設定ファイルを示しています。

  Corefile: |
    .:53 {
        errors
        log
        health {
           lameduck 15s
        }
        ready
        kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {
          pods verified
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf {
              prefer_udp
        }
        cache 30
        loop
        reload
        loadbalance
    }

CoreDNS 設定を拡張して、次のシナリオをサポートできます。

• シナリオ 1: ログサービスを有効にする

  CoreDNS が処理するすべての名前解決リクエストをログに記録するには、log プラグインを有効にします。次のサンプル設定に示すように、Corefile に log を追加します。

    Corefile: |
      .:53 {
          errors
          log
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
                prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• シナリオ 2: 特定のドメイン名にカスタム DNS サーバーを使用する

  サフィックスが example.com のドメイン名を自己管理 DNS サーバー (IP アドレス 10.10.0.10) を使用して解決するには、そのドメイン名に対して個別のサーバーブロックを設定できます。次のサンプル設定に例を示します。

  example.com:53 {
    errors
    cache 30
    forward . 10.10.0.10 {
    prefer_udp
    }
  }

  完全な設定は次のとおりです。

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }
      example.com:53 {
          errors
          cache 30
          forward . 10.10.0.10 {
          prefer_udp
          }
      }

• シナリオ 3: すべての外部ドメイン名に自己管理 DNS サーバーを使用する

  オンプレミス DNS で解決されるドメイン名に共通のサフィックスがない場合、CoreDNS を設定して、すべての外部ドメイン名に自己管理 DNS サーバーを使用できます。この場合、オンプレミス DNS が解決できないドメイン名のリクエストを Alibaba Cloud DNS に転送する必要があります。クラスターの ECS インスタンス上の /etc/resolv.conf ファイルを直接変更しないでください。たとえば、自己管理 DNS サーバーの IP アドレスが 10.10.0.10 と 10.10.0.20 の場合、次のサンプル設定に示すように forward パラメーターを変更できます。

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . 10.10.0.10 10.10.0.20 {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• シナリオ 4: hosts をカスタマイズする

  特定のドメイン名を IP アドレスにマッピングする (www.example.com に IP アドレス 127.0.0.1 を割り当てるなど) には、次のサンプル設定に示すように hosts プラグインを使用できます。

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          
          hosts {
            127.0.0.1 www.example.com
            fallthrough
          }
        
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

  重要

  fallthrough を設定する必要があります。そうしないと、カスタマイズされていないホストの名前解決が失敗します。

• シナリオ 5: クラスター外からクラスター内のサービスにアクセスする

  クラスターノード (ECS インスタンス) で実行されているプロセスがクラスター内のサービスにアクセスできるようにするには、各 ECS インスタンスの /etc/resolv.conf ファイルの nameserver を kube-dns の ClusterIP に設定します。ただし、ECS インスタンス上の /etc/resolv.conf ファイルを直接変更することは強く推奨しません。

  内部ネットワークシナリオの場合、より良いアプローチは、プライベート向け SLB インスタンスを使用してクラスター内のサービスを公開することです。次に、Alibaba Cloud DNS PrivateZone コンソールで、サービスのドメイン名を SLB の内部 IP アドレスに解決する A レコードを追加します。

• シナリオ 6: 統一されたドメイン名を使用してサービスにアクセスするか、クラスター内のドメイン名の CNAME 解決を実行する

  foo.example.com などの統一されたドメイン名を使用して、インターネット、内部ネットワーク、およびクラスター内からサービスにアクセスできます。これは次のように実現されます。

  • クラスター内のサービス foo.default.svc.cluster.local は、インターネット向け SLB を使用して公開されます。ドメイン名 foo.example.com は、この SLB のパブリック IP アドレスに解決されるように設定されます。

  • クラスター内のサービス foo.default.svc.cluster.local は、プライベート向け SLB インスタンスを介して公開されます。VPC では、Alibaba Cloud DNS PrivateZone を使用して foo.example.com をこのプライベート向け SLB インスタンスの IP アドレスに解決できます。詳細については、「シナリオ 4: hosts をカスタマイズする」をご参照ください。

  • クラスター内では、rewrite プラグインを使用して、次のサンプル設定に示すように、foo.example.com を foo.default.svc.cluster.local にマッピングする CNAME レコードを作成できます。

      Corefile: |
        .:53 {
            errors
            health {
               lameduck 15s
            }
            ready
            
            rewrite stop {
              name exact foo.example.com foo.default.svc.cluster.local
              answer name foo.default.svc.cluster.local foo.example.com 
            }
    
            kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
              ttl 30
            }
            prometheus :9153
            forward . /etc/resolv.conf {
              prefer_udp
            }
            cache 30
            loop
            reload
            loadbalance
        }

• シナリオ 7: CoreDNS が AAAA レコード (IPv6) のクエリに応答を返すのを防ぐ

  アプリケーションコンテナーが AAAA レコードを必要としない場合、CoreDNS を設定して AAAA レコードのクエリをインターセプトし、空 (NODATA) の応答を返すことができます。これにより、不要なネットワークトラフィックが削減されます。次のサンプル設定にその方法を示します。

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          # Add the following line for the Template plugin. Keep other data unchanged.
          template IN AAAA .
      
      }

• シナリオ 8: ACK One マルチクラスターサービス機能を有効にする

  説明

  ACK One マルチクラスターサービス機能は、CoreDNS 1.9.3 以降でサポートされています。CoreDNS コンポーネントが 1.9.3 より前のバージョンの場合、この機能を有効にする前に CoreDNS をアップグレードする必要があります。詳細については、「アンマネージド CoreDNS の自動アップグレード」および「アンマネージド CoreDNS の手動アップグレード」をご参照ください。

  1. 次のコマンドを実行して、CoreDNS 設定項目を編集します。

     kubectl edit configmap/coredns -n kube-system

  2. kubernetes を含む行の上に multicluster clusterset.local の行を追加します。これにより、multicluster プラグインが有効になり、マルチクラスターサービスのドメイン名サフィックスが clusterset.local に設定されます。

     Corefile: |
         .:53 {
             # Other content is omitted.
             # Add the following line.
             multicluster clusterset.local
             kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               fallthrough in-addr.arpa ip6.arpa
               ttl 30
             }
             # Other content is omitted.
         }

  3. 変更を加えた後、[Esc] キーを押し、:wq! と入力してから [Enter] キーを押して設定ファイルを保存し、編集モードを終了します。

• シナリオ 9: 異なる外部ドメイン名に異なるアップストリーム DNS サーバーを指定する

  前提条件:

  CoreDNS v1.11.3 以降。

  設定方法:

  単一のサーバーブロックで、forward プラグインを使用して、異なるドメイン名に異なるアップストリーム DNS サーバーを設定できます。forward プラグインのパラメーターの詳細については、「forward」をご参照ください。

  サンプル設定:

  Corefile: |
      .:53 {
          # 他のコンテンツは省略されます。
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          # foo.com の DNS サーバーとして 10.20.0.1 を指定します。
          forward foo.com 10.20.0.1
          # bar.com の DNS サーバーとして 10.30.0.1 を指定します。
          forward bar.com 10.30.0.1
          # 他のドメイン名については、ノード上の /etc/resolv.conf で指定された DNS サーバーを使用します。 
          forward . /etc/resolv.conf
          # 他のコンテンツは省略されます。
      }