すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:CoreDNSの設定

最終更新日:Nov 12, 2024

CoreDNSは、Container Service for Kubernetes (ACK) クラスターのデフォルトのドメインネームシステム (DNS) サーバーです。 このトピックでは、CoreDNSが提供するプラグインと、さまざまなシナリオでプラグインを設定する方法について説明します。

前提条件

利用シナリオ

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

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

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

CoreDNSのデフォルト設定

kube-system名前空間には、CoreDNS ConfigMapがあります。 ConfigMapを表示する方法の詳細については、「ConfigMapsの管理」をご参照ください。 CoreDNSは、ConfigMapで指定されたプラグインを構成および有効にします。 異なるCoreDNSバージョンのConfigMapsはわずかに異なります。 設定を変更する前に、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
    }
説明

ClusterDomainを、クラスターの作成時に指定したクラスタードメイン名に置き換えます。 デフォルトのクラスタードメイン名はcluster.localです。

パラメーター

説明

エラー

エラーを標準出力 (stdout) に出力します。

健康

CoreDNSのヘルスチェックレポートを生成します。 デフォルトのリスニングポートは8080です。 このプラグインは、CoreDNSのヘルスステータスを評価するために使用されます。 CoreDNSのヘルスチェックレポートを表示するには、http:// localhost:8080/healthにアクセスします。

準備完了

CoreDNSプラグインのステータスを報告します。 デフォルトのリスニングポートは8181です。 このプラグインは、CoreDNSプラグインの準備状況を評価するために使用されます。 http:// localhost:8181/readyにアクセスして、CoreDNSプラグインの準備状況を確認できます。 すべてのプラグインが実行中の状態になると、CoreDNSプラグインの準備ができているための200応答コードが返されます。

kubernetes

CoreDNSのkubernetesプラグインは、ACKクラスター内のサービスのDNS解決を提供するために使用されます。

プロメテウス

CoreDNSメトリクスをエクスポートします。 http:// localhost:9153/metricsにアクセスして、Prometheus形式のCoreDNSメトリクスを表示できます。

forwardまたはproxy

DNSクエリを定義済みのDNSサーバーに転送します。 デフォルトでは、Kubernetesのクラスタードメイン以外のドメイン名のDNSクエリは、定義済みのDNSリゾルバー (/etc/resolv.conf) に転送されます。 デフォルトの設定は、ホスト上の /etc/resolv.confファイルに基づいています。

キャッシュ

DNSキャッシュを有効にします。

ループ

ループ検出を実行します。 ループが検出されると、CoreDNSは中断されます。

リロード

変更したCorefileの自動リロードを許可します。 ConfigMapを編集した後、変更が有効になるまで2分待ちます。

loadbalance

ラウンドロビンDNSロードバランサーとして機能し、回答のa、AAAA、およびMXレコードの順序をランダム化します。

CoreDNSに基づいて拡張機能を構成する

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

  • シナリオ1: ログ収集の有効化

    CoreDNSによって実行されたすべてのDNS解決レコードのログを収集するには、logパラメーターをCorefileに追加してログプラグインを有効にします。 例:

      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
        }
  • シナリオ2: 指定したドメイン名のDNSサーバーのカスタマイズ

    f 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サーバーで解決できないドメイン名をAlibaba Cloud DNSに転送する必要があります。 ACKクラスターのECS (Elastic Compute Service) インスタンス上の /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プラグインを設定できます。たとえば、t www.example.comを127.0.0.1に設定する必要がある場合があります。 例:

      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: ACKクラスター内のサービスへの外部アクセスの有効化

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

    内部ネットワークでは、内部対応のServer Load Balancer (SLB) インスタンスを使用して、ACKクラスター内のサービスへの内部アクセスを許可できます。 次に、Alibaba Cloud DNS PrivateZoneコンソールにログインし、SLBインスタンスのプライベートIPアドレスを指すAレコードを追加します。

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

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

    • サービスfoo.de fault.svc.cluster.localは、インターネット接続SLBインスタンスを介した外部アクセスに公開されます。 ドメイン名のfoo.example.comは、インターネットに接続されたSLBインスタンスのIPアドレスに解決されます。

    • サービスfoo.de fault.svc.cluster.localは、内部対応のSLBインスタンスを介した内部アクセスに公開されます。 Alibaba Cloud DNS PrivateZoneコンソールにログインして、ACKクラスターがデプロイされている仮想プライベートクラウド (VPC) の内部対応SLBインスタンスのIPアドレスをポイントしfoo.example.com。 手順の詳細については、「シナリオ4: 指定したドメイン名のホストのカスタマイズ」をご参照ください。

    • ACKクラスター内で、書き換えプラグインを使用してCNAMEレコードを追加し、foo.example.comfoo.de fault.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を設定する

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

      Corefile: |
        .:53 {
            errors
            health {
               lameduck 15s
            }
            # Add the following line to enable the template plug-in. Do not modify other settings. 
            template IN AAAA .
        
        }
  • シナリオ8: ACK OneのMCS機能の有効化

    説明

    CoreDNS 1.9.3以降は、Distributed Cloud Container Platform for Kubernetes (ACK One) のマルチクラスタサービス (MCS) 機能をサポートしています。 この機能を有効にするには、CoreDNSが1.9.3以降に更新されていることを確認します。 詳細については、「CoreDNSを自動的に更新するようにACKを設定する」および「CoreDNSを手動で更新する」をご参照ください。

    1. 次のコマンドを実行して、CoreDNSのConfigMapを更新します。

      kubectl edit configmap/coredns -n kube-system
    2. kubernetesで始まる行の上に行を追加し、新しい行にmulticluster clusterset.localを指定して、ACK OneのMCS機能を有効にするためのマルチクラスタープラグインを有効にします。 この構成では、マルチクラスターサービスのドメイン名のサフィックスがclusterset.localに設定されます。

      Corefile: |
          .:53 {
              # Irrelevant lines are not shown. 
              # 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
              }
              # Irrelevant lines are not shown. 
          }
    3. [Esc] を押して :wq! と入力し、[enter] を押してファイルを保存し、編集モードを終了します。