原文来自kubernetes-reliability,译者对原文不合理的地方有删减

概览

类似于kubernetes的分布式系统旨在应对故障发生,有关kubernetesHA的更多文章,参阅Building High-Availability Clusters

为了获得更加简单的步骤,我们将跳过大部分内容来描述kubelet<->Controller Manager之间的通信

默认情况下,正常的行为如下:

1. kubelet定期向apiserver发送其状态,发送周期由--node-status-update-frequency参数指定,默认值是10s
2. Kubernetes Controller Manager定期的检查kubelet状态,该参数由–-node-monitor-period参数指定,默认值5秒s
3. Kubernetes Controller Manager对kubelet状态更新有一个容忍值,如果kubelet在这个容忍值内更新状态,那么Kubernetes Controller Manager认为kubelet状态有效.容忍值参数由--node-monitor-grace-period指定,默认值为40s

Kubernetes Controller Manager和kubelet异步工作,这意味着延迟可能包含网络延迟,API Server延迟,etcd延迟,节点负载等引起的延迟,所以如果设置--node-status-update-frequency参数为5秒时,那么当etcd无法将数据提交到仲裁节点时,它可能会在etcd中等待6-7秒甚至更长才能被呈现

失败

kubelet将尝试发送nodeStatusUpdateRetry ,当前nodeStatusUpdateRetry 在kubelet.go.中设置为5

kubelet将使用 tryUpdateNodeStatus方法发送状态.kubelet使用golang的http.Client()方法,但是没指定超时时长,因此当在apiserver过载时TCP连接会造成一些问题.

因此,这里尝试使用nodeStatusUpdateRetry 乘以 --node-status-update-frequency的值设置node状态.

在同时Kubernetes Controller Manager每隔--node-monitor-period设置的时间检查nodeStatusUpdateRetry设置的次数,经过--node-monitor-grace-period设定的时间将认为node不健康,Kubernetes Controller Manager通过--pod-eviction-timeout设置pod移除的容忍值.

同时Kube Proxywatch API server,一旦pod被移除,那么集群中所有kube proxy将更新其节点上的iptables规则,移除相应的endpoint,这使得请求无法被发送到故障节点的pod

针对不同案例的建议

快速更新以及快速反应

在该建议参数中,ep将在node认为挂掉后(第20秒)后移除(译者测试过程中--pod-eviction-timeout参数失效,issue72395处于open状态),该建议会对etcd造成一定的开销

如果集群中有1000个节点,那么在1分钟内会有15000次node节点更新,这需要考虑使用大型的etcd集群活专用节点.

如果我们计算尝试次数,除法将给出5,但是实际上nodeStatusUpdateRetry尝试都是3-5次,由于所有组件的延迟,尝试总次数将在15-25之间变化

中等更新和平均反应

在该建议参数中,kubelet每20秒上报状态,在Kubernetes Controller Manager考虑节点不健康前,1分钟后驱逐所有pod

此处情况适用于中等环境,因为1000个节点每分钟需要对etcd进行3000次更新

低更新和慢反应

在该建议参数中,kubelet将在每分钟上报状态,5分钟后,Kubernetes Controller Manager将节点设置为不健康

在译者测试中(kubernetes 集群版本1.13.4),--pod-eviction-timeout在设置后无效,pod依然会在5分钟后重新调度,参见issue72395

可以有不同的组合，例如快速更新和慢反应以满足特定情况。

PS: --node-status-update-frequency在未来可能弃用,在kubelet --config文件中使用nodeStatusUpdateFrequency字段