如果节点变为离线超时，Kubernetes 重新创建 pod

Question

我已经开始使用 docker 镜像并设置 Kubernetes。我已经修复了所有问题，但我遇到了 pod 娱乐超时的问题。

如果一个 pod 正在一个特定节点上运行并且我将其关闭，则在另一个在线节点上重新创建 pod 将需要大约 5 分钟的时间。

我检查了所有可能的配置文件，还设置了所有 pod-eviction-timeout、horizo​​ntal-pod-autoscaler-downscale、horizo​​ntal-pod-autoscaler-downscale-delay 标志，但它仍然无法正常工作。

当前 kube Controller 管理器配置:

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

谢谢你。

Answer 1

如 Taint Based Evictions存在于 pod 定义中， Controller 管理器将无法驱逐容忍该污点的 pod。即使你没有在你的配置中定义一个驱逐策略，它也会得到一个默认的，因为 Default Toleration Seconds默认情况下启用准入 Controller 插件。

默认的 Toleration Seconds 准入 Controller 插件配置您的 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 多岁，由于容忍， Controller 经理无能为力。

但是为什么要超过5分钟呢？因为节点在 --node-monitor-grace-period之后会被认为down默认为 40 秒。之后，Pod 容忍计时器启动。

推荐方案

如果您希望您的集群对节点中断做出更快的 react ，您应该使用 taints 和 tolerations 而不修改选项。例如，您可以像下面这样定义您的 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 上产生开销，因为每个节点都会尝试经常更新其状态。

除此之外，目前尚不清楚如何将 Controller 管理器、api 服务器和 kubelet 配置中的更改传播到事件集群中的所有节点。请查看 Tracking issue for changing the cluster和 Dynamic Kubelet Configuration .在撰写本文时， reconfiguring a node's kubelet in a live cluster处于测试阶段。

您可以在 kubeadm init 或 join 阶段配置控制平面和 kubelet。请引用 Customizing control plane configuration with kubeadm和 Configuring each kubelet in your cluster using kubeadm更多细节。

假设您有一个单节点集群:

controller manager包括:

--node-monitor-grace-period默认 40 秒

--node-monitor-period默认 5s

--pod-eviction-timeout默认 5m0s

api server包括:

--default-not-ready-toleration-seconds默认 300

--default-unreachable-toleration-seconds默认 300

kubelet包括:

--node-status-update-frequency默认 10 秒

如果您使用 kubeadm 设置集群你可以修改:

/etc/kubernetes/manifests/kube-controller-manager.yaml用于 Controller 管理器选项。

/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