参考:https://kubernetes.io/zh/docs/tasks/administer-cluster/coredns/
关于 CoreDNS
CoreDNS 是一个灵活可扩展的 DNS 服务器,可以作为 Kubernetes 集群 DNS。 与 Kubernetes 一样,CoreDNS 项目由 CNCF 托管。
通过在现有的集群中替换 kube-dns,可以在集群中使用 CoreDNS 代替 kube-dns 部署, 或者使用 kubeadm 等工具来为你部署和升级集群。
升级 CoreDNS
从 v1.9 起,Kubernetes 提供了 CoreDNS。 你可以在此处(https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md) 查看 Kubernetes 随附的 CoreDNS 版本以及对 CoreDNS 所做的更改。
如果你只想升级 CoreDNS 或使用自己的自定义镜像,则可以手动升级 CoreDNS。 参看指南和演练(https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md) 文档了解如何平滑升级。
升级 Kubernetes 集群时,在升级 CoreDNS 组件时应该注意一些问题,以避免向后不兼容的配置失败。 在较高级别,您需要查看 CoreDNS 发行说明以查看新版本是否引入了向后不兼容或弃用,并在升级 CoreDNS 之前根据需要调整您的 Corefile。
要确定可能的向后不兼容,您需要查看 CoreDNS 发行说明。 CoreDNS 发行说明位于 CoreDNS 博客中 。 CoreDNS 弃用政策是这样的,我们只会在 xx0 和 xx1 版本中引入向后不兼容。 因此,例如,如果您要从 1.1.5 升级到 1.3.1,您应该查看 1.2.0、1.2.1、1.3.0 和 1.3.1 的发行说明以了解任何弃用/向后不兼容通知。
如果您发现任何向后不兼容的通知,您应该检查您的 Corefile 以查看您是否受到影响。
手动升级 CoreDNS
1.在升级之前识别并解决您的 Corefile 中与新 CoreDNS 版本向后不兼容的任何配置。
2.如果您想降低 CoreDNS 停机的风险,请确保您的 CoreDNS 部署设置为处理滚动更新。 它应该有 > 1 个副本、一个 RollingUpdate 策略和一个指向 healthCoreDNS 中的插件。 例如……
readinessProbe:
httpGet:
path: /health
port: 8080
3.更新部署中的 CoreDNS 版本。 此步骤可与步骤 2 同时完成。
4.使用第 2 步和第 3 步更新 Deployment 后,监控 Pod 状态
kubectl -n kube-system get pods
5.如果您看到 Pod 崩溃,请查看日志以查看任何错误,然后在必要时调整配置或回滚。
kubectl -n kube-system logs
使用 Kubeadm 升级 CoreDNS
作为 Kubernetes 集群升级的一部分,Kubeadm 将为您更新 CoreDNS。 这样做时,它将替换/重置对 CoreDNS 部署的任何自定义更改。 例如,如果您增加了部署中的副本数量,升级后将重置为默认值 (2)。 但是,Kubeadm 不会更改您的 CoreDNS 配置映射。 如果您的 CoreDNS Corefile 包含任何向后不兼容的配置,您需要在更新之前手动修复它们。
CoreDNS 调优
当资源利用方面有问题时,优化 CoreDNS 的配置可能是有用的。 有关详细信息,请参阅有关扩缩 CoreDNS 的文档(https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)。
在大型 Kubernetes 集群中,CoreDNS 的内存使用主要受集群中 Pod 和服务数量的影响。 其他因素包括填充的 DNS 应答缓存的大小,以及每个 CoreDNS 实例的接收查询率 (QPS)。
使用默认 CoreDNS 设置
要估计 CoreDNS 实例所需的内存量(使用默认设置),您可以使用以下公式:
需要 MB(默认设置)=(Pods + 服务)/ 1000 + 54
该公式包含以下内容:
- 30 MB 用于缓存。 默认缓存大小为 10000 个条目,完全填满时使用大约 30 MB。
- 5 MB 操作缓冲区,用于处理查询。 在测试中,这是单个 CoreDNS 副本在 ~30K QPS 负载下使用的数量。
使用 autopath 插件
自动 路径 是一种可选优化,可提高集群外部名称查询的性能(例如 infoblox.com)。 但是,启用自动 路径 插件需要 CoreDNS 使用更多的内存来存储有关 Pod 的信息。 启用自动 路径 插件也会给 Kubernetes API 带来额外的负载,因为它必须监控对 Pod 的所有更改。
要估计 CoreDNS 实例所需的内存量(使用 autopath 插件),您可以使用以下公式:
需要 MB(带自动路径)=(Pods + 服务)/ 250 + 56
该公式包含以下内容:
- 30 MB 用于缓存。 默认缓存大小为 10000 个条目,完全填满时使用大约 30 MB。
- 5 MB 操作缓冲区,用于处理查询。 在测试中,这是单个 CoreDNS 副本在 ~30K QPS 负载下使用的数量。
您可以使用上面的公式来估计集群中 CoreDNS 所需的内存量,并相应地调整 CoreDNS 部署中的资源内存请求/限制。