Amazon EKS クラスターで DNS の CoreDNS を管理する

CoreDNS は、Kubernetes クラスター DNS として機能できる柔軟で拡張可能な DNS サーバーです。1 つ以上のノードで Amazon EKS クラスターを起動すると、クラスターにデプロイされたノード数に関係なく、デフォルトで CoreDNS イメージの 2 つのレプリカがデプロイされます。CoreDNS の Pods は、クラスター内のすべての Pods の名前解決を行います。クラスターに 起動時にどの Pods が AWS Fargate を使用するのかを定義する が含まれ、名前空間が CoreDNS deployment の名前空間と一致している場合、CoreDNS Pods を Fargate ノードにデプロイできます。CoreDNS の詳細については、「Kubernetes ドキュメント」の「サービスディスカバリーに CoreDNS を使用する」を参照してください。

CoreDNS バージョン

次の表は、各 Kubernetes バージョンの Amazon EKS アドオンタイプの利用可能な最新バージョンを示しています。

Kubernetes バージョン	1.30	1.29	1.28	1.27	1.26	1.25	1.24	1.23
	v1.11.1-eksbuild.11	v1.11.1-eksbuild.11	v1.10.1-eksbuild.13	v1.10.1-eksbuild.13	v1.9.3-eksbuild.17	v1.9.3-eksbuild.17	v1.9.3-eksbuild.17	v1.8.7-eksbuild.16

重要

このアドオンを自己管理している場合、表のバージョンは、利用可能なセルフマネージドバージョンと同じではない可能性があります。このアドオンのセルフマネージドタイプの更新の詳細については、「CoreDNS Amazon EKS セルフマネージドアドオンの更新」を参照してください。

CoreDNS アップグレードに関する重要な考慮事項

• CoreDNS Deployment の安定性と可用性を向上させるために、PodDisruptionBudget を使用してバージョン v1.9.3-eksbuild.6 以降および v1.10.1-eksbuild.3 がデプロイされます。既存の PodDisruptionBudget をデプロイした場合、これらのバージョンへのアップグレードは失敗する可能性があります。アップグレードが失敗した場合は、次のいずれかのタスクを実行することで問題が解決します。

  • Amazon EKS アドオンをアップグレードする際は、競合解決のオプションとして既存の設定を上書きすることを選択してください。Deployment に他のカスタム設定を行った場合は、アップグレード後に他のカスタム設定を再適用できるように、アップグレード前に必ず設定をバックアップしてください。

  • 既存の PodDisruptionBudget を削除して、アップグレードを再試行してください。

• EKS アドオンバージョン v1.9.3-eksbuild.3 以降および v1.10.1-eksbuild.6 以降では、CoreDNS Deployment は readinessProbe を /ready エンドポイントを使用するように設定します。このエンドポイントは CoreDNS の Corefile 設定ファイルで有効になっています。

  カスタム Corefile を使用する場合は、ready プラグインを設定に追加して、プローブが使用できるように /ready エンドポイントを CoreDNS でアクティブにする必要があります。

• EKS アドオンバージョン v1.9.3-eksbuild.7 以降および v1.10.1-eksbuild.4 以降では、PodDisruptionBudget を変更できます。次の例では、フィールドを使用して、アドオンを編集したり、[任意の設定項目]でこれらの設定を変更したりできます。この例はデフォルトの PodDisruptionBudget を示しています。

  {
      "podDisruptionBudget": {
          "enabled": true,
          "maxUnavailable": 1
          }
  }

  maxUnavailable または minAvailable を設定できますが、両方を単一の PodDisruptionBudget で設定することはできません。PodDisruptionBudgets の詳細については、「Kubernetes ドキュメント」の「PodDisruptionBudget の指定」を参照してください。

  enabled を false に設定しても、PodDisruptionBudget は削除されないことに注意してください。このフィールドを false に設定後、PodDisruptionBudget オブジェクトを削除する必要があります。同様に、PodDisruptionBudget のあるバージョンにアップグレードした後、古いバージョンのアドオンを使用するようにアドオンを編集した場合 (アドオンをダウングレード)、PodDisruptionBudget は削除されません。次のコマンドを実行して、PodDisruptionBudget を削除します。

  kubectl delete poddisruptionbudget coredns -n kube-system
  

• EKS アドオンバージョン v1.10.1-eksbuild.5 以降では、デフォルトの許容値を KEP 2067 に準拠するように node-role.kubernetes.io/master:NoSchedule から node-role.kubernetes.io/control-plane:NoSchedule に変更してください。KEP 2067 の詳細については、GitHub の Kubernetes 拡張プロポーザル (KEP) の「KEP-2067: kubeadm の「マスター」ラベルとテイントの名前を変更する」を参照してください。

  EKS アドオンバージョン v1.8.7-eksbuild.8 以降、および v1.9.3-eksbuild.9 以降では、両方の許容範囲がすべての Kubernetes バージョンと互換性があるように設定されています。

• EKS アドオンバージョン v1.9.3-eksbuild.11 および v1.10.1-eksbuild.7 以降では、CoreDNS Deployment は topologySpreadConstraints のデフォルト値を設定します。デフォルト値により、複数のアベイラビリティーゾーンに使用可能なノードがある場合に、CoreDNS Pods がアベイラビリティーゾーン全体に分散されます。デフォルト値の代わりに使用するカスタム値を設定できます。デフォルト値は次のとおりです。

  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          k8s-app: kube-dns

CoreDNS v1.11 アップグレードに関する考慮事項

• EKS アドオン バージョン v1.11.1-eksbuild.4 以降では、コンテナイメージは、Amazon EKS Distro によって維持される最小ベースイメージに基づいています。これには最小限のパッケージが含まれ、シェルはありません。詳細については、「Amazon EKS Distro」を参照してください。CoreDNS イメージの使用方法とトラブルシューティングは変わりません。