我有一个带有多个节点的kubernetes集群。我有在3个节点上运行的kube-dns。
我遇到的问题是，如果这3个节点中的1个发生故障，我的吊舱/容器之间的请求就会开始或多或少地失败3次。
这是因为，当容器解析k8s服务主机名时，它将调用kube-dns服务来解析该主机名，而kube-dns k8s服务具有三个端点，但是这三个端点之一无效，因为该节点已关闭。在检测到节点已关闭之前，K8s不会更新服务。 （目前，我将该时间设置为60秒）。
关于如何缓解这种情况的任何想法？是否可以在应用程序外部配置任何种类的重试？容器中或k8s级的东西。
谢谢。
答案 0 :(得分：0)
特定节点上的基础Kubernetes资源与kube-apiserver之间的通信的主要贡献者是kubelet。可以确定其角色为节点代理。因此，kubelet在集群生命周期中起着重要作用，这归因于以下主要职责：管理嵌套对象的活动性和就绪性探针，更新ETCD存储以写入资源元数据并定期刷新在kubelet配置中由kube-apiserver标志指定的--node-status-update-frequency拥有自己的健康状态。
-node-status-update-frequency持续时间指定kubelet多久将一次节点状态发布到主节点。注意：更改时要谨慎 常量，它必须与nodecontroller中的nodeMonitorGracePeriod一起使用。 （默认10秒）
但是，Kubernetes中有一个称为Node controller的特定组件。节点控制器的基本作用之一是通过控制kubelet的相关心跳来检查所涉及工作人员的状态。有一些描述此行为的特定标志，默认情况下，这些标志已包含在kube-controller-manager配置中：
--node-monitor-period-在指定时间检查kubelet的状态
间隔（默认值为5s）； --node-monitor-grace-period-Kubernetes控制器的时间
经理认为Kubelet的健康状态（默认值为40s）； --pod-eviction-timeout-用于删除上的广告连播的宽限超时
失败的节点（默认值为5m）。无论何时要缓解DNS Pods中断，如果节点发生故障，都应考虑以下选项。您也可以查看DNS horizontal autoscaller以便与DNS Pod的稳定副本数保持一致，但是它带来了一些附加的逻辑结构要实施，这可能会消耗群集引擎上的更多计算资源。