このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Amazon EKS クラスターで DNS の CoreDNS を管理する
ヒント
Amazon EKS 自動モード ではネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については、「EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する」を参照してください。
CoreDNS は、Kubernetes クラスター DNS として機能する、フレキシブルで拡張可能な DNS サーバーです。少なくとも 1 つのノードで Amazon EKS クラスターを起動すると、クラスターにデプロイされたノード数に関係なく、デフォルトで CoreDNS イメージの 2 つのレプリカがデプロイされます。これらの CoreDNS ポッドは、クラスター内のすべてのポッドの名前解決を行います。クラスターに名前空間が CoreDNS deployment の名前空間と一致する名前空間を持つ Fargate プロファイルが含まれいる場合、CoreDNS ポッドを Fargate ノードにデプロイできます。CoreDNS の詳細については、Kubernetes ドキュメント の「Using CoreDNS for Service Discovery
CoreDNS のバージョン
次の表は、Kubernetes バージョンごとに Amazon EKS アドオンタイプの最新バージョンを示しています。
| Kubernetes バージョン | CoreDNS のバージョン |
|---|---|
|
1.33 |
v1.12.3-eksbuild.1 |
|
1.32 |
v1.11.4-eksbuild.22 |
|
1.31 |
v1.11.4-eksbuild.22 |
|
1.30 |
v1.11.4-eksbuild.22 |
|
1.29 |
v1.11.4-eksbuild.22 |
|
1.28 |
v1.10.1-eksbuild.38 |
|
1.27 |
v1.10.1-eksbuild.38 |
重要
このアドオンを自己管理している場合、表のバージョンは利用可能なセルフマネージドバージョンと同じではない可能性があります。このアドオンのセルフマネージドタイプの更新の詳細については「CoreDNS Amazon EKS セルフマネージドアドオンを更新する」を参照してください。
CoreDNS アップグレードに関する重要な考慮事項
-
CoreDNS 更新では PodDisruptionBudget が使用され、更新プロセス中に DNS サービスの可用性を維持します。
-
CoreDNS デプロイの安定性と可用性を高めるには、
PodDisruptionBudgetを使用してバージョンv1.9.3-eksbuild.6以降およびv1.10.1-eksbuild.3をデプロイします。既存のPodDisruptionBudgetをデプロイした場合、これらのバージョンへのアップグレードは失敗する可能性があります。アップグレードが失敗した場合は次のいずれかのタスクを実行することで問題が解決します。-
Amazon EKS アドオンをアップグレードする際は競合解決のオプションとして既存の設定を上書きすることを選択してください。デプロイに他のカスタム設定を行った場合は、アップグレード後に他のカスタム設定を再適用できるように、アップグレード前に必ず設定をバックアップしてください。
-
既存の
PodDisruptionBudgetを削除して、アップグレードを再試行してください。
-
-
EKS アドオンバージョン
v1.9.3-eksbuild.3以降およびv1.10.1-eksbuild.6以降では、CoreDNS デプロイは/readyエンドポイントを使用するようにreadinessProbeを設定します。このエンドポイントは、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 Enhancement Proposals (KEPs)」の「KEP-2067: Rename the kubeadm "master" label and taint」を参照してください。 EKS アドオンバージョン
v1.8.7-eksbuild.8以降、およびv1.9.3-eksbuild.9以降では、どちらの許容範囲もすべての Kubernetes バージョンと互換性を維持できるように設定されています。 -
EKS アドオンバージョン
v1.9.3-eksbuild.11およびv1.10.1-eksbuild.7以降では、CoreDNS デプロイはtopologySpreadConstraintsのデフォルト値を設定します。このデフォルト値により、複数のアベイラビリティーゾーンに使用可能なノードがある場合には、CoreDNS Pod がアベイラビリティーゾーン全体に分散します。デフォルト値の代わりに使用するカスタム値を設定できます。デフォルト値は次のとおりです。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 イメージの使用方法とトラブルシューティングは変わりません。