6

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

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

我检查了所有可能的配置文件，还设置了所有 pod-eviction-timeout、horizo​​ntal-pod-autoscaler-downscale、horizo​​ntal-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

谢谢你。

4

2 回答 2

14

如果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-ready5 分钟的污点。在这种情况下，即使您设置--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
于 2019-09-05T12:53:05.530 回答
6

这是节点死亡或进入离线模式时发生的情况：

  1. kubelet 通过 将其状态发布给 master --node-status-update-fequency=10s。
  2. 节点下线
  3. kube-controller-manager 通过以下方式监控所有节点--node-monitor-period=5s
  4. kube-controller-manager 将看到节点无响应并具有宽限期，--node-monitor-grace-period=40s直到它认为节点不健康。PS：这个参数应该在N x node-status-update-fequency
  5. 一旦节点标记为不健康，kube-controller-manager 将根据--pod-eviction-timeout=5m

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

 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 nodenode-status-update-fequecy and node-monitor-grace-period时间也算在内node-monitor-grace-period。您也可以调整这些变量以进一步降低您的总节点驱逐时间。

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

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一旦我关闭我的节点，我就会有效地看到我的 pod 被逐出。

编辑2：

在 master 上运行以下命令并检查是否--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那么您的更改没有正确应用。

于 2018-12-06T03:25:41.997 回答