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

シナリオ

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

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： Simple Log Service の有効化

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

  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 サーバーで解決する必要があるドメイン名に同じサフィックスが含まれていない場合は、ユーザー定義の 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: 指定されたドメイン名のホストをカスタマイズする

  hosts プラグインを設定して、www.example.com を 127.0.0.1 にポイントするなど、指定したドメイン名に静的 IP アドレスを指定します。この方法は、/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 クラスター内の Elastic Compute Service (ECS) インスタンス上のプロセスがクラスター内のサービスにアクセスできるようにするには、ECS インスタンスの /etc/resolv.conf ファイルで、クラスター内の kube-dns のクラスター IP アドレスを nameserver パラメーターの値として指定します。/etc/resolv.conf ファイルの他の設定は変更しないでください。

  内部ネットワークでは、内部向けの Classic Load Balancer (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 コンソールにログインして、ACK クラスターがデプロイされている VPC で、foo.example.com を内部向け 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 レコードに基づく解決結果を必要としない場合、CoreDNS が解決結果をインターセプトして NODATA コードを返すように設定します。これにより、データ転送が最小限に抑えられます。例：

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