Question

我已经开始使用docker镜像并设置Kubernetes。我已经解决了所有问题，但豆荚娱乐的超时时间有问题。

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

我已经检查了所有可能的配置文件，还设置了所有pod 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

谢谢。

Answer 1

当节点死亡或进入离线模式时，会发生以下情况：

kubelet通过--node-status-update-fequency=10s将其状态发布给母版。
节点离线
kube-controller-manager正在通过--node-monitor-period=5s
kube-controller-manager将看到节点无响应，并具有宽限期--node-monitor-grace-period=40s，直到它认为节点不正常为止。 PS：此参数应位于N x node-status-update-fequency
一旦节点标记为不正常，则kube-controller-manager将基于--pod-eviction-timeout=5m移除吊舱

现在，如果您将参数pod-eviction-timeout调整为30秒，则仍然需要

 node status update frequency: 10s
 node-monitor-period: 5s
 node-monitor-grace-period: 40s
 pod-eviction-timeout: 30s

Total 70 seconds to evict the pod from node node-status-update-fequecy and node-monitor-grace-period的时间也计入node-monitor-grace-period中。您还可以调整这些变量，以进一步降低总节点驱逐时间。

这是我的kube-controller-manager.yaml文件（位于/ etc / kubernetes / manifests for kubeadm）：

containers:
  - command:
    - kube-controller-manager
    - --controllers=*,bootstrapsigner,tokencleaner
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --pod-eviction-timeout=30s
    - --address=127.0.0.1
    - --use-service-account-credentials=true
    - --kubeconfig=/etc/kubernetes/controller-manager.conf

关闭节点后，我可以有效地看到70s中的豆荚被逐出。

EDIT2：

在主服务器上运行以下命令，并检查--pod-eviction-timeout是否为20s。

[root@ip-10-0-1-12]# docker ps --no-trunc | grep "kube-controller-manager"

9bc26f99dcfe6ac0e7b2abf22bff67af6060561ee8c0cdff08e11c3a479f182c   sha256:40c8d10b2d11cbc3db2e373a5ffce60dd22dbbf6236567f28ac6abb7efbfc8a9                     
"kube-controller-manager --leader-elect=true --use-service-account-credentials=true --root-ca-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key \
**--pod-eviction-timeout=30s** --address=127.0.0.1 --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --service-account-private-key-file=/etc/kubernetes/pki/sa.key --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --allocate-node-cidrs=true --cluster-cidr=192.168.13.0/24 --node-cidr-mask-size=24"

如果此处--pod-eviction-timeout是5m而不是20s，则您的更改将无法正确应用。

Answer 2

如果在容器定义中包含Taint Based Evictions，则控制器管理器将无法逐出容忍异味的容器。即使您未在配置中定义驱逐策略，它也将成为默认策略，因为默认情况下Default Toleration Seconds接纳控制器插件已启用。

默认容忍秒接纳控制器插件将您的吊舱配置如下：

tolerations:
- key: node.kubernetes.io/not-ready
  effect: NoExecute
  tolerationSeconds: 300
- key: node.kubernetes.io/unreachable
  operator: Exists
  effect: NoExecute
  tolerationSeconds: 300

您可以通过检查广告连播的定义来验证这一点：

kubectl get pods -o yaml -n <namespace> <pod-name>`

根据上述容忍度，在另一个准备就绪的节点上重新创建容器需要5分钟以上的时间，因为容器可以容忍not-ready异味最多5分钟。在这种情况下，即使将--pod-eviction-timeout设置为20s，由于公差，控制器管理器也无能为力。

但是为什么要花5分钟以上呢？因为该节点将在--node-monitor-grace-period之后被视为关闭，默认为40s。之后，豆荚容忍计时器开始计时。

可用选项

如果您想在下面控制这些时间，则可以找到很多选择。但是，应避免修改这些选项。如果您使用的时间太紧，可能会在etcd上造成额外的开销，因为每个节点都会非常频繁地尝试更新其状态。

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

您可以在kubeadm初始化或加入阶段配置控制平面和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默认5秒
- --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用于控制器管理器选项。
/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

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

2 个答案:

推荐的解决方案

可用选项