在 Amazon EKS 集群中管理 DNS 的 CoreDNS
CoreDNS 是一个灵活、可扩展的 DNS 服务器,可用作 Kubernetes 集群 DNS。当您启动具有至少一个节点的 Amazon EKS 集群时,无论集群中部署的节点数量如何,预设情况下都会部署 CoreDNS 镜像的两个副本。这些 CoreDNS Pods 为集群中的所有 Pods 提供名称解析。如果您的集群包含命名空间与 CoreDNS deployment
的命名空间相匹配的定义启动时将使用 Amazon Fargate 的Pods定义启动时将使用 Amazon Fargate 的容器组(pod)时,则可以将 CoreDNS Pods 部署到 Fargate 节点。有关 CoreDNS 的更多信息,请参阅 Kubernetes 文档中的使用 CoreDNS 进行服务发现
CoreDNS 版本
下表列出了每个 Kubernetes 版本的 Amazon EKS 附加组件类型的最新版本。
Kubernetes 版本 | CoreDNS 版本 |
---|---|
1.31 |
v1.11.3-eksbuild.1 |
1.30 |
v1.11.3-eksbuild.1 |
1.29 |
v1.11.3-eksbuild.1 |
1.28 |
v1.10.1-eksbuild.13 |
1.27 |
v1.10.1-eksbuild.13 |
1.26 |
v1.9.3-eksbuild.17 |
1.25 |
v1.9.3-eksbuild.17 |
1.24 |
v1.9.3-eksbuild.17 |
1.23 |
v1.8.7-eksbuild.16 |
重要
如果您自行管理此附加组件,则表中的版本可能与可用的自行管理版本不同。有关更新此附加组件的自行管理类型的更多信息,请参阅更新 CoreDNS Amazon EKS 自行管理的附加组件。
重要的 CoreDNS 升级注意事项
-
为了提高 CoreDNS Deployment 的稳定性和可用性,版本
v1.9.3-eksbuild.6
及更高版本和v1.10.1-eksbuild.3
使用PodDisruptionBudget
进行部署。如果您已部署现有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
的更多信息,请参阅《[.noloc]Kubernetes
文档》中的指定 PodDisruptionBudget。 请注意,如果将
enabled
设置为false
,则不会删除PodDisruptionBudget
。将此字段设置为false
后,必须删除PodDisruptionBudget
对象。同样,如果您在升级到带有PodDisruptionBudget
的版本后编辑附加组件,以使用该附加组件的旧版本(降级附加组件),则不会删除PodDisruptionBudget
。要删除PodDisruptionBudget
,您可以运行以下命令:kubectl delete poddisruptionbudget coredns -n kube-system
-
在 EKS 插件版本
v1.10.1-eksbuild.5
及更高版本中,将默认容差从node-role.kubernetes.io/master:NoSchedule
更改为node-role.kubernetes.io/control-plane:NoSchedule
以符合 KEP 2067。有关 KEP 2067 的更多信息,请参阅 GitHub 上的《Kubernetes 增强建议(KEP)》中的 KEP-2067:重命名 kubeadm“master”标签和污点。 在 EKS 插件版本
v1.8.7-eksbuild.8
及更高版本和v1.9.3-eksbuild.9
及更高版本中,两个公差都设置为与每个 Kubernetes 版本兼容。 -
在 EKS 附加组件版本
v1.9.3-eksbuild.11
和v1.10.1-eksbuild.7
以及更高版本中,CoreDNSDeployment 为topologySpreadConstraints
设置一个默认值。如果多个可用性区域内都有节点,则该默认值可确保 CoreDNS Pods 分布在可用性区域内。您可以设置一个用于代替默认值的自定义值。默认值如下所示:topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: k8s-app: kube-dns
CoreDNSv1.11
升级注意事项
-
在 EKS 附加组件版本
v1.11.1-eksbuild.4
以及更高版本中,容器映像基于 Amazon EKS Distro 维护的最小基本映像,其中包含最少的软件包且没有外壳。有关更多信息,请参阅 Amazon EKS Distro 。CoreDNS 映像的使用和故障排查保持不变。