Kubernetes: configuración de tiempo de espera de desalojo de vaina ignorada

Creado en 27 feb. 2019  ·  15Comentarios  ·  Fuente: kubernetes/kubernetes

Utilice esta plantilla cuando informe un error y proporcione la mayor cantidad de información posible. Si no lo hace, es posible que su error no se solucione de manera oportuna. ¡Gracias! Si el asunto está relacionado con la seguridad, infórmelo de forma privada a través de https://kubernetes.io/security/

Qué sucedió : modifiqué la configuración pod-eviction-timeout de kube-controller-manager en el nodo maestro (para disminuir la cantidad de tiempo antes de que k8s vuelva a crear un pod en caso de falla del nodo). El valor predeterminado es de 5 minutos, configuré 30 segundos. Usando el comando sudo docker ps --no-trunc | grep "kube-controller-manager" , verifiqué que la modificación se haya aplicado correctamente:

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"

Apliqué una implementación básica con dos réplicas:

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

El primer pod creado en el primer nodo trabajador, el segundo pod creado en el segundo nodo trabajador:

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>

Para probar el desalojo correcto de la vaina, apago el primer nodo trabajador. Después de ~ 1 min, el estado del primer nodo trabajador cambió a "NotReady", luego
Tuve que esperar +5 minutos (que es el tiempo de espera de desalojo predeterminado del pod) para que el pod en el nodo apagado se vuelva a crear en el otro nodo.

Qué esperabas que sucediera :
Después de que el estado del nodo informe "NotReady", el pod debe volver a crearse en el otro nodo después de 30 segundos en lugar de los 5 minutos predeterminados.

Cómo reproducirlo (de la forma más mínima y precisa posible) :
Crea tres nodos. Inicie Kubernetes en el primer nodo ( sudo kubeadm init ), aplique el complemento de red ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ), luego únase a los otros dos nodos (como: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ).
Agregue el parámetro pod-eviction-timeout a Kube Controller Manager en el nodo principal: 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

(el yaml está truncado, aquí solo se muestra la primera parte relacionada).

Compruebe que se aplique la configuración:
sudo docker ps --no-trunc | grep "kube-controller-manager"

Aplique una implementación con dos réplicas, verifique que se cree un pod en el primer nodo trabajador y el segundo en el segundo nodo trabajador.
Apague uno de los nodos y verifique el tiempo transcurrido entre el evento, cuando el nodo informa "NotReady" y el pod se vuelve a crear.

¿Algo más que necesitemos saber? :
También experimento el mismo problema en un entorno multimaestro.

Medio ambiente :

  • Versión de Kubernetes (use kubectl version ): v1.13.3
    Versión del cliente: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 08: 12Z ", GoVersion:" go1.11.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}
    Versión del servidor: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 00: 57Z ", GoVersion:" go1.11.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}
  • Proveedor de nube o configuración de hardware: máquina virtual de Azure
  • SO (por ejemplo: cat /etc/os-release ): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"
  • Kernel (por ejemplo, uname -a ): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP Mar 15 de enero 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
  • Instalar herramientas:
  • Otros: Docker v18.06.1-ce
kinbug siapps sinode
Fuente
picture danielloczi

Comentario más útil

¡Gracias por sus comentarios ChiefAlexander!
Esa es la situación, escribiste. Revisé los pods y me aseguré de que existen los valores predeterminados asignados al pod para la tolerancia:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

Así que simplemente agregué mis propios valores a la implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

Después de aplicar la implementación en caso de falla del nodo, el estado del nodo cambia a "NotReady", luego los pods se vuelven a crear después de 2 segundos.

Por lo tanto, ya no tenemos que lidiar con el tiempo de espera de desalojo de pod, ¡el tiempo de espera se puede establecer en base a Pod! ¡Frio!

¡De nuevo, gracias por tu ayuda!

picture danielloczi en 28 feb. 2019
🎉6 🚀2 👍1

Todos 15 comentarios

@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs

danielloczi picture danielloczi en 27 feb. 2019

@danielloczi : Reiterando las menciones para activar una notificación:
@ kubernetes / sig-node-bugs, @ kubernetes / sig-apps-bugs

En respuesta a esto :

@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs

Las instrucciones para interactuar conmigo usando comentarios de relaciones públicas están disponibles aquí . Si tiene preguntas o sugerencias relacionadas con mi comportamiento, presente un problema en el repositorio de kubernetes / test-infra .

k8s-ci-robot picture k8s-ci-robot en 27 feb. 2019

También encontré este problema al probar la configuración del tiempo de espera de desalojo más bajo. Después de hurgar en esto durante algún tiempo, descubrí que la causa es el nuevo TaintBasedEvictions.

En la versión 1.13, la función TaintBasedEvictions se promueve a beta y se habilita de forma predeterminada, por lo tanto, NodeController (o kubelet) agrega automáticamente las taints y la lógica normal para desalojar pods de nodos basados ​​en Ready NodeCondition está deshabilitada.

Establecer el indicador de función para esto en falso hace que los pods se desalojen como se esperaba. No me he tomado el tiempo de buscar en el código de desalojo basado en la corrupción, pero supongo que no estamos utilizando esta marca de tiempo de espera de desalojo en él.

ChiefAlexander picture ChiefAlexander en 27 feb. 2019
👍6

Mirando esto más. Con TaintBasedEvictions establecido en verdadero, puede establecer el tiempo de desalojo de sus pods dentro de sus especificaciones bajo tolerancias:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
Los valores predeterminados de estos los establece un controlador de admisión: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Esas dos banderas se pueden configurar a través de kube-apiserver y deberían lograr el mismo efecto.

ChiefAlexander picture ChiefAlexander en 27 feb. 2019
👍6 
// Controller will not proactively sync node health, but will monitor node
// health signal updated from kubelet. There are 2 kinds of node healthiness
// signals: NodeStatus and NodeLease. NodeLease signal is generated only when
// NodeLease feature is enabled. If it doesn't receive update for this amount
// of time, it will start posting "NodeReady==ConditionUnknown". The amount of
// time before which Controller start evicting pods is controlled via flag
// 'pod-eviction-timeout'.
// Note: be cautious when changing the constant, it must work with
// nodeStatusUpdateFrequency in kubelet and renewInterval in NodeLease
// controller. The node health signal update frequency is the minimal of the
// two.
// There are several constraints:
// 1. nodeMonitorGracePeriod must be N times more than  the node health signal
//    update frequency, where N means number of retries allowed for kubelet to
//    post node status/lease. It is pointless to make nodeMonitorGracePeriod
//    be less than the node health signal update frequency, since there will
//    only be fresh values from Kubelet at an interval of node health signal
//    update frequency. The constant must be less than podEvictionTimeout.
// 2. nodeMonitorGracePeriod can't be too large for user experience - larger
//    value takes longer for user to see up-to-date node health.
liucimin picture liucimin en 28 feb. 2019

¡Gracias por sus comentarios ChiefAlexander!
Esa es la situación, escribiste. Revisé los pods y me aseguré de que existen los valores predeterminados asignados al pod para la tolerancia:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

Así que simplemente agregué mis propios valores a la implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

Después de aplicar la implementación en caso de falla del nodo, el estado del nodo cambia a "NotReady", luego los pods se vuelven a crear después de 2 segundos.

Por lo tanto, ya no tenemos que lidiar con el tiempo de espera de desalojo de pod, ¡el tiempo de espera se puede establecer en base a Pod! ¡Frio!

¡De nuevo, gracias por tu ayuda!

danielloczi picture danielloczi en 28 feb. 2019
🎉6 🚀2 👍1

@danielloczi Hola danielloczi, ¿Cómo solucionas este problema? También me encuentro con este problema

nick0323 picture nick0323 en 10 jun. 2019

@ 323929 Creo que a @danielloczi no le importa el parámetro pod-eviction-timeout en kube-controller-manager, pero lo resuelve usando Taint based Evictions , probé con Taint based Evictions , funcionó para mi.

zdyxry picture zdyxry en 25 jun. 2019

Así es: simplemente comencé a usar Taint based Eviction .

danielloczi picture danielloczi en 26 jun. 2019

¿Es posible hacerlo global? No quiero habilitar eso para cada configuración de pod, especialmente porque uso muchas cosas preparadas de helm

kamilgregorczyk picture kamilgregorczyk en 2 ene. 2020
👍4

+1 por tener la posibilidad de configurarlo por todo el cluster. El ajuste por módulo o por implementación rara vez es útil: en la mayoría de los casos, un valor global sensato es mucho más conveniente y el valor predeterminado actual de 5 m es demasiado largo para muchos casos.

por favor, vuelva a abrir este problema.

morgwai picture morgwai en 8 feb. 2020

Estoy enfrentando este mismo problema, ¿hay alguna manera de inhabilitar los desalojos basados ​​en Taint y que el tiempo de espera de desalojo de pod funcione en modo global?

richardqa picture richardqa en 7 mar. 2020

Estoy enfrentando este mismo problema, ¿hay alguna manera de inhabilitar los desalojos basados ​​en Taint y que el tiempo de espera de desalojo de pod funcione en modo global?

Creo que puede configurar el desalojo global de pod a través de apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
No probé esto, pero como puedo ver, hay opciones: --default-not-ready-toleration-seconds y --default-unreachable-toleration-seconds.

hrbasic picture hrbasic en 30 mar. 2020
👍1

¿Por qué se marcó este error como cerrado? Parece que el problema original no está resuelto, solo funciona.
No me queda claro por qué la marca de tiempo de espera de desalojo de pod no funciona

enricovittorini picture enricovittorini en 13 abr. 2020

mismo problema

pythonzm picture pythonzm en 15 abr. 2020
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

tbchj picture tbchj  ·  3Comentarios
jason-riddle picture jason-riddle  ·  3Comentarios
arun-gupta picture arun-gupta  ·  3Comentarios
theothermike picture theothermike  ·  3Comentarios
alexferl picture alexferl  ·  3Comentarios