kubernetes - 如果节点变为离线超时,Kubernetes 会重新创建 pod
问题描述
我已经开始使用 docker 镜像并设置 Kubernetes。我已经修复了所有问题,但我遇到了 pod 娱乐超时的问题。
如果一个 pod 正在一个特定节点上运行,并且我将其关闭,则在另一个在线节点上重新创建 pod 大约需要 5 分钟。
我检查了所有可能的配置文件,还设置了所有 pod-eviction-timeout、horizontal-pod-autoscaler-downscale、horizontal-pod-autoscaler-downscale-delay 标志,但它仍然无法正常工作。
当前 kube 控制器管理器配置:
spec:
containers:
- command:
- kube-controller-manager
- --address=192.168.5.135
- --allocate-node-cidrs=false
- --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
- --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --cluster-cidr=192.168.5.0/24
- --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
- --controllers=*,bootstrapsigner,tokencleaner
- --kubeconfig=/etc/kubernetes/controller-manager.conf
- --leader-elect=true
- --node-cidr-mask-size=24
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --root-ca-file=/etc/kubernetes/pki/ca.crt
- --service-account-private-key-file=/etc/kubernetes/pki/sa.key
- --use-service-account-credentials=true
- --horizontal-pod-autoscaler-downscale-delay=20s
- --horizontal-pod-autoscaler-sync-period=20s
- --node-monitor-grace-period=40s
- --node-monitor-period=5s
- --pod-eviction-timeout=20s
- --use-service-account-credentials=true
- --horizontal-pod-autoscaler-downscale-stabilization=20s
image: k8s.gcr.io/kube-controller-manager:v1.13.0
谢谢你。
解决方案
如果Pod 定义中存在基于污染的驱逐,控制器管理器将无法驱逐容忍污染的 Pod。即使您没有在配置中定义驱逐策略,它也会获得一个默认策略,因为默认情况下启用了Default Toleration Seconds准入控制器插件。
默认容忍秒准入控制器插件配置您的 pod,如下所示:
tolerations:
- key: node.kubernetes.io/not-ready
effect: NoExecute
tolerationSeconds: 300
- key: node.kubernetes.io/unreachable
operator: Exists
effect: NoExecute
tolerationSeconds: 300
您可以通过检查 pod 的定义来验证这一点:
kubectl get pods -o yaml -n <namespace> <pod-name>`
根据上述容忍度,在另一个就绪节点上重新创建 pod 需要超过 5 分钟,因为 pod 最多可以容忍not-ready
5 分钟的污点。在这种情况下,即使您设置--pod-eviction-timeout
为 20 秒,控制器管理器也因容错而无能为力。
但为什么需要超过 5 分钟?因为该节点将被视为关闭,之后--node-monitor-grace-period
默认为 40 秒。之后,pod 容忍计时器启动。
推荐解决方案
如果您希望集群对节点中断做出更快的反应,您应该使用污点和容忍度而不修改选项。例如,您可以像下面这样定义您的 pod:
tolerations:
- key: node.kubernetes.io/not-ready
effect: NoExecute
tolerationSeconds: 0
- key: node.kubernetes.io/unreachable
effect: NoExecute
tolerationSeconds: 0
有了上述容忍度,您的 pod 将在当前节点标记为未就绪之后在就绪节点上重新创建。这应该不到一分钟,因为--node-monitor-grace-period
默认为 40 秒。
可用选项
如果您想控制下面的这些时间,您会发现很多选择。但是,应避免修改这些选项。如果您使用时间紧迫,这可能会在 etcd 上产生开销,因为每个节点都会尝试频繁更新其状态。
除此之外,目前还不清楚如何将控制器管理器、api 服务器和 kubelet 配置中的更改传播到活动集群中的所有节点。请参阅更改集群和动态 Kubelet 配置的跟踪问题。在撰写本文时,在实时集群中重新配置节点的 kubelet处于测试阶段。
您可以在 kubeadm init 或 join 阶段配置控制平面和 kubelet。有关详细信息,请参阅使用 kubeadm 自定义控制平面配置和使用 kubeadm配置集群中的每个 kubelet。
假设您有一个单节点集群:
- 控制器管理器包括:
--node-monitor-grace-period
默认40s--node-monitor-period
默认5s--pod-eviction-timeout
默认5m0s
- api服务器包括:
--default-not-ready-toleration-seconds
默认 300--default-unreachable-toleration-seconds
默认 300
- kubelet包括:
--node-status-update-frequency
默认10s
如果您设置集群,kubeadm
您可以修改:
/etc/kubernetes/manifests/kube-controller-manager.yaml
用于控制器管理器选项。/etc/kubernetes/manifests/kube-apiserver.yaml
用于 api 服务器选项。
注意:修改这些文件将重新配置并重新启动节点中的相应 pod。
为了修改kubelet
配置,您可以添加以下行:
KUBELET_EXTRA_ARGS="--node-status-update-frequency=10s"
到/etc/default/kubelet
(对于 DEB)或/etc/sysconfig/kubelet
(对于 RPM)然后重新启动 kubelet 服务:
sudo systemctl daemon-reload && sudo systemctl restart kubelet
推荐阅读
- java - 如何使用 SpEL 结果作为 @Value 键
- c# - 使用 Unity 时缺少 ViGEm.NET 命名空间?
- ios - 如何启用 Ios Callkit 呼叫目录扩展
- javascript - 如何确保javascript事件第二次运行?
- bash - 将 CSV 文件与条件组合
- powershell - 如何在 PowerShell 中使用 -AsSecureString 参数向已创建的本地用户添加密码
- reactjs - Docker 运行给出错误:找不到模块'/app/NPM'
- c# - 如何一次将多行插入数据库
- android - 显示灰色的按钮(新的 onClickListener())
- firebase - 在 express 中,他们为什么使用 app 和 main?