Kubernetes: 忽略的逐出逐出超时设置

报告错误时，请使用此模板，并提供尽可能多的信息。 不这样做可能会导致您的错误无法及时得到解决。 谢谢！ 如果此事与安全性有关，请通过https://kubernetes.io/security/私下披露

发生的事情：我修改了主节点上kube-controller-manager的pod-eviction-timeout设置（以减少在节点发生故障时k8s重新创建Pod之前的时间）。 默认值为5分钟，我配置为30秒。 使用sudo docker ps --no-trunc | grep "kube-controller-manager"命令，我检查修改是否成功应用：

kubeadmin<strong i="10">@nodetest21</strong>:~$ sudo docker ps --no-trunc | grep "kube-controller-manager"
387261c61ee9cebce50de2540e90b89e2bc710b4126a0c066ef41f0a1fb7cf38   sha256:0482f640093306a4de7073fde478cf3ca877b6fcc2c4957624dddb2d304daef5                         "kube-controller-manager --address=127.0.0.1 --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --client-ca-file=/etc/kubernetes/pki/ca.crt --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 --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 --pod-eviction-timeout=30s" 

我应用了具有两个副本的基本部署：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

在第一个工作程序节点上创建的第一个容器，在第二个工作程序节点上创建的第二个容器：

NAME         STATUS   ROLES    AGE   VERSION
nodetest21   Ready    master   34m   v1.13.3
nodetest22   Ready    <none>   31m   v1.13.3
nodetest23   Ready    <none>   30m   v1.13.3

NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE   IP          NODE         NOMINATED NODE   READINESS GATES
default       busybox-74b487c57b-5s6g7             1/1     Running   0          13s   10.44.0.2   nodetest22   <none>           <none>
default       busybox-74b487c57b-6zdvv             1/1     Running   0          13s   10.36.0.1   nodetest23   <none>           <none>
kube-system   coredns-86c58d9df4-gmcjd             1/1     Running   0          34m   10.32.0.2   nodetest21   <none>           <none>
kube-system   coredns-86c58d9df4-wpffr             1/1     Running   0          34m   10.32.0.3   nodetest21   <none>           <none>
kube-system   etcd-nodetest21                      1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-apiserver-nodetest21            1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-controller-manager-nodetest21   1/1     Running   0          20m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-proxy-6mcn8                     1/1     Running   1          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   kube-proxy-dhdqj                     1/1     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>
kube-system   kube-proxy-vqjg8                     1/1     Running   0          34m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-scheduler-nodetest21            1/1     Running   1          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-9qls7                      2/2     Running   3          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   weave-net-h2cb6                      2/2     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-vkb62                      2/2     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>

为了测试正确的Pod逐出，我关闭了第一个工作程序节点。 大约1分钟后，第一个工作程序节点的状态更改为“ NotReady”，然后
我必须等待+5分钟（这是默认的Pod逐出超时），才能在已关闭的节点上的Pod在另一个节点上重新创建。

您预期会发生什么：
节点状态报告“ NotReady”后，应在30秒后在另一个节点上重新创建Pod，而不是默认5分钟！

如何复制它（尽可能少且精确） ：
创建三个节点。 在第一个节点（ sudo kubeadm init ）上初始化Kubernetes，应用网络插件（ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ），然后加入其他两个节点（例如： kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ）。
将pod-eviction-timeout参数添加到主节点上的Kube Controller Manager： sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml ：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --address=127.0.0.1
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --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
    - --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
    - --pod-eviction-timeout=30s

（yaml被截断，此处仅显示相关的第一部分）。

检查设置是否已应用：
sudo docker ps --no-trunc | grep "kube-controller-manager"

应用具有两个副本的部署，检查是否在第一个工作程序节点上创建了一个Pod，并在第二个工作程序节点上创建了第二个Pod。
关闭节点之一，并检查事件报告节点“ NotReady”和重新创建Pod之间的时间间隔。

我们还需要知道什么吗？ ：
我在多主机环境中也遇到相同的问题。

环境：

• Kubernetes版本（使用kubectl version ）：v1.13.3
  客户端版本：version.Info {主要：“ 1”，次要：“ 13”，GitVersion：“ v1.13.3”，GitCommit：“ 721bfa751924da8d1680787490c54b9179b1fed0”，GitTreeState：“ clean”，BuildDate：“ 2019-02-01T20：08： 12Z“，GoVersion：” go1.11.5“，编译器：” gc“，平台：” linux / amd64“}
  服务器版本：version.Info {主要：“ 1”，次要：“ 13”，GitVersion：“ v1.13.3”，GitCommit：“ 721bfa751924da8d1680787490c54b9179b1fed0”，GitTreeState：“ clean”，BuildDate：“ 2019-02-01T20：00： 57Z”，GoVersion：“ go1.11.5”，编译器：“ gc”，平台：“ linux / amd64”}
• 云提供商或硬件配置：Azure VM
• 操作系统（例如： cat /etc/os-release ）：NAME =“ Ubuntu” VERSION =“ 16.04.5 LTS（Xenial Xerus）”
• 内核（例如uname -a ）：Linux nodetest21 4.15.0-1037-azure＃39〜16.04.1-Ubuntu SMP Tue Jan 15 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
• 安装工具：
• 其他：Docker v18.06.1-ce