Container Compute Service:アンマネージド CoreDNS を構成する

シナリオ

このトピックでは、DNS 解決に CoreDNS を使用する Pod を例として使用します。dnsPolicy: ClusterFirst は、Pod の DNS ポリシー構成で指定されています。例:

apiVersion: v1
kind: Pod
metadata:
  name: alinux3
  namespace: default
spec:
  containers:
  - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alinux3
  dnsPolicy: ClusterFirst

dnsPolicy パラメータのさまざまなシナリオでの構成方法の詳細については、DNS 解決を構成するを参照してください。

CoreDNS のデフォルト構成

ACK クラスタの kube-system ネームスペースには、CoreDNS ConfigMap があります。CoreDNS は、ConfigMap で指定されたプラグインを構成して有効にします。異なる CoreDNS バージョンの ConfigMap は若干異なります。構成を変更する前に、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 に基づいて拡張機能を構成する

次のシナリオでは、CoreDNS に基づいて拡張機能を構成できます。

• シナリオ 1: ログ収集を有効にする

  CoreDNS によって実行されるすべての DNS 解決レコードのログを収集するには、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 サーバー (DNS サーバー 10.10.0.10 など) で解決する必要がある場合は、ドメイン名にカスタム解決設定を追加する必要があります。例:

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

  次のコードブロックは、完全な Corefile 構成を示しています。

    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 サーバーで解決する必要があるドメイン名に同じ接尾辞が含まれていない場合は、ユーザー定義の DNS サーバーを使用してすべての外部ドメイン名の DNS 解決を実行できます。たとえば、ユーザー定義の 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: 指定されたドメイン名のホストをカスタマイズする

  www.example.com を 127.0.0.1 にポイントするなど、指定されたドメイン名に静的 IP アドレスを指定する場合は、hosts プラグインを構成できます。この方法は、/etc/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
      }

  重要

  hosts に fallthrough パラメータを指定する必要があります。そうしないと、指定されていないドメイン名が解決に失敗する可能性があります。

• シナリオ 5: ACK クラスタのサービスへの外部アクセスを有効にする

  ACK クラスタの ECS インスタンスのプロセスがクラスタ内のサービスにアクセスできるようにするには、ECS インスタンスの nameserver/etc/resolv.conf ファイルの /etc/resolv.conf パラメータの値として、クラスタ内の kube-dns のクラスタ IP アドレスを指定します。 ファイルの他の設定は変更しないでください。

  内部ネットワークでは、インターネット向けクラシックロードバランサ (CLB) インスタンスを使用して、ACK クラスタのサービスへの内部アクセスを許可できます。次に、Alibaba Cloud DNS PrivateZone コンソールにログオンし、CLB インスタンスのプライベート IP アドレスをポイントする A レコードを追加します。

• シナリオ 6: ドメイン名を使用して ACK クラスタのサービスへのアクセスを許可する、または ACK クラスタの CNAME 解決を有効にする

  foo.example.com を使用して、インターネット、内部ネットワーク、および ACK クラスタ内から ACK クラスタのサービスへのすべてのアクセスを許可できます。次のセクションでは、この機能を有効にする方法について説明します。

  • サービス foo.default.svc.cluster.local は、インターネット向け CLB インスタンスを使用して外部アクセスに公開されます。ドメイン名 foo.example.com は、インターネット向け CLB インスタンスの IP アドレスに解決されます。

  • サービス foo.default.svc.cluster.local は、内部向け CLB インスタンスを使用して内部アクセスに公開されます。Alibaba Cloud DNS PrivateZone コンソールにログオンして、foo.example.com を、ACK クラスタがデプロイされている仮想プライベートクラウド (VPC) 内の内部向け CLB インスタンスの IP アドレスにポイントします。詳細については、CoreDNS を構成するを参照してください。

  • ACK クラスタ内で rewrite プラグインを使用して CNAME レコードを追加し、foo.example.com を foo.default.svc.cluster.local にポイントできます。例:

      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: AAAA レコードに基づいて解決された IPv6 アドレスを返さないように CoreDNS を構成する

  アプリケーション Pod が AAAA レコードに基づく解決結果を必要としない場合は、解決結果をインターセプトして NODATA コードを返すように CoreDNS を構成できます。これにより、データ転送が最小限に抑えられます。例:

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          # template プラグインを有効にするには、次の行を追加します。他の設定は変更しないでください。
          template IN AAAA .
      }