我有一个包含多个节点的 Kubernetes 集群。我在 3 个节点上运行 kube-dns。
我遇到的问题是，如果这 3 个节点中的 1 个出现故障，我的 pod/容器之间的请求开始或多或少失败 1 次。
这是因为当容器解析 k8s 服务主机名时，它会调用 kube-dns 服务来解析该主机名，并且 kube-dns k8s 服务具有三个端点，但是这三个端点之一在节点关闭时无效。 K8s 在检测到节点宕机之前不会更新服务。 （目前我将该时间设置为 60 秒）。
知道如何缓解这种情况吗？是否可以在应用程序之外配置任何类型的重试？容器中或 k8s 级别的东西。
谢谢。
【问题讨论】：
标签： kubernetes kube-dns
特定节点上的底层 Kubernetes 资源与kube-apiserver 之间通信的主要贡献者是kubelet。它的角色可以确定为节点代理。因此，kubelet 在集群生命周期中发挥着重要作用，因为主要职责包括管理嵌套对象的活跃度和就绪度探测、更新ETCD 存储以便为资源写入元数据并定期刷新自身的健康状态以kube-apiserver，由 kubelet 配置中的 --node-status-update-frequency 标志指定。
--node-status-update-frequency duration 指定 kubelet 将节点状态发布到 master 的频率。注意：更改时要小心 常量，它必须与 nodecontroller 中的 nodeMonitorGracePeriod 一起使用。 （默认 10 秒）
但是，Kubernetes 中有一个特定的组件，称为 Node controller。 Node 控制器的重要角色之一是通过控制来自kubelet 的相关心跳来检查相关工作人员的状态。有一些特定的标志描述了这种行为，默认情况下这些标志已包含在kube-controller-manager 配置中：
--node-monitor-period - 在指定时间检查 kubelet 状态
间隔（默认值5s）；--node-monitor-grace-period - Kubernetes 控制器的时间
manager 考虑 Kubelet 的健康状态（默认值 40s）；--pod-eviction-timeout - 删除 pod 的宽限超时
失败的节点（默认值 5m）。当您想要缓解 DNS Pod 中断时，以防节点出现故障，您应该考虑这些选项。您还可以查看DNS horizontal autoscaller，以便与 DNS Pod 的稳定副本数保持一致，但它带来了一些需要实现的额外逻辑结构，这可能会消耗集群引擎上的更多计算资源。
【讨论】：