Kubernetes: paramètres de délai d'expiration de pod ignorés

Créé le 27 févr. 2019  ·  15Commentaires  ·  Source: kubernetes/kubernetes

Veuillez utiliser ce modèle lorsque vous signalez un bogue et fournissez autant d'informations que possible. Si vous ne le faites pas, votre bogue pourrait ne pas être résolu en temps opportun. Merci! Si le problème est lié à la sécurité, veuillez le divulguer en privé via https://kubernetes.io/security/

Ce qui s'est passé : J'ai modifié les paramètres pod-eviction-timeout de kube-controller-manager sur le nœud maître (afin de réduire le temps avant que k8s ne recrée un pod en cas de défaillance du nœud). La valeur par défaut est de 5 minutes, j'ai configuré 30 secondes. En utilisant la commande sudo docker ps --no-trunc | grep "kube-controller-manager" j'ai vérifié que la modification a été appliquée avec succès:

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"

J'ai appliqué un déploiement de base avec deux 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

Le premier pod créé sur le premier nœud de travail, le deuxième pod créé sur le deuxième nœud de travail:

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>

Pour tester l'expulsion de pod correcte, j'ai arrêté le premier nœud de travail. Après ~ 1 min, l'état du premier nœud de travail est passé à "NotReady", puis
J'ai dû attendre +5 minutes (qui est le délai d'expiration par défaut du pod) pour que le pod sur le nœud désactivé soit recréé sur l'autre nœud.

Ce à quoi vous vous attendiez :
Après que l'état du nœud rapporte "NotReady", le pod doit être recréé sur l'autre nœud après 30 secondes à la place si la valeur par défaut est de 5 minutes!

Comment le reproduire (de la manière la plus minimale et la plus précise possible) :
Créez trois nœuds. Lancez Kubernetes sur le premier nœud ( sudo kubeadm init ), appliquez le plugin réseau ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ), puis rejoignez les deux autres nœuds (comme: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ).
Ajoutez le paramètre pod-eviction-timeout à Kube Controller Manager sur le nœud maître: 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

(le yaml est tronqué, seule la première partie associée est affichée ici).

Vérifiez que les paramètres sont appliqués:
sudo docker ps --no-trunc | grep "kube-controller-manager"

Appliquez un déploiement avec deux réplicas, vérifiez qu'un pod est créé sur le premier nœud de travail, le second est créé sur le deuxième nœud de travail.
Arrêtez l'un des nœuds et vérifiez le temps écoulé entre l'événement, lorsque le nœud signale «NotReady» et le pod recréé.

Y a-t-il autre chose que nous devons savoir? :
Je rencontre également le même problème dans un environnement multi-maître.

Environnement :

  • Version Kubernetes (utilisez kubectl version ): v1.13.3
    Version du client: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 08: 12Z ", GoVersion:" go1.11.5 ", Compilateur:" gc ", Plate-forme:" linux / amd64 "}
    Version du serveur: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.3", GitCommit: "721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState: "clean", BuildDate: "2019-02-01T20: 00: 57Z ", GoVersion:" go1.11.5 ", Compilateur:" gc ", Plate-forme:" linux / amd64 "}
  • Fournisseur de cloud ou configuration matérielle: Azure VM
  • OS (par exemple: cat /etc/os-release ): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"
  • Noyau (par exemple uname -a ): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP mar 15 janvier 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
  • Installer les outils:
  • Autres: Docker v18.06.1-ce
kinbug siapps sinode
Source
picture danielloczi

Commentaire le plus utile

Merci pour vos commentaires ChiefAlexander!
Telle est la situation, avez-vous écrit. J'ai vérifié les pods et je suis sûr que les valeurs par défaut sont attribuées au pod pour la tolérance:

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

J'ai donc simplement ajouté mes propres valeurs au déploiement:

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

Après avoir appliqué le déploiement en cas de défaillance du nœud, l'état du nœud passe à "NotReady", puis les pods sont recréés après 2 secondes.

Nous n'avons donc plus à gérer le délai d'expiration du pod, le délai peut être défini sur la base du pod! Cool!

Merci encore pour votre aide!

picture danielloczi le 28 févr. 2019
🎉6 🚀2 👍1

Tous les 15 commentaires

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

danielloczi picture danielloczi le 27 févr. 2019

@danielloczi :
@ kubernetes / sig-node-bugs, @ kubernetes / sig-apps-bugs

En réponse à cela :

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

Les instructions pour interagir avec moi en utilisant les commentaires PR sont disponibles ici . Si vous avez des questions ou des suggestions concernant mon comportement, veuillez signaler un problème avec le

k8s-ci-robot picture k8s-ci-robot le 27 févr. 2019

J'ai également rencontré ce problème en testant la réduction du délai d'expulsion. Après avoir fouillé là-dessus pendant un certain temps, j'ai compris que la cause était les nouvelles TaintBasedEvictions.

Dans la version 1.13, la fonctionnalité TaintBasedEvictions est promue en version bêta et activée par défaut, par conséquent, les teintes sont automatiquement ajoutées par le NodeController (ou kubelet) et la logique normale d'expulsion des pods des nœuds basée sur Ready NodeCondition est désactivée.

La définition de l'indicateur de fonctionnalité pour cela sur false entraîne l'expulsion des pods comme prévu. Je n'ai pas pris le temps de chercher dans le code d'expulsion basé sur la corruption, mais je suppose que nous n'utilisons pas cet indicateur de délai d'expiration.

ChiefAlexander picture ChiefAlexander le 27 févr. 2019
👍6

En regardant cela plus. Avec TaintBasedEvictions défini sur true, vous pouvez définir le temps d'expulsion de vos pods dans ses spécifications sous les tolérances:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
Les valeurs par défaut de celles-ci sont définies par un contrôleur d'admission: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Ces deux drapeaux peuvent être définis via le kube-apiserver et devraient avoir le même effet.

ChiefAlexander picture ChiefAlexander le 27 févr. 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 le 28 févr. 2019

Merci pour vos commentaires ChiefAlexander!
Telle est la situation, avez-vous écrit. J'ai vérifié les pods et je suis sûr que les valeurs par défaut sont attribuées au pod pour la tolérance:

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

J'ai donc simplement ajouté mes propres valeurs au déploiement:

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

Après avoir appliqué le déploiement en cas de défaillance du nœud, l'état du nœud passe à "NotReady", puis les pods sont recréés après 2 secondes.

Nous n'avons donc plus à gérer le délai d'expiration du pod, le délai peut être défini sur la base du pod! Cool!

Merci encore pour votre aide!

danielloczi picture danielloczi le 28 févr. 2019
🎉6 🚀2 👍1

@danielloczi Bonjour danielloczi, Comment résolvez-vous ce problème? Je rencontre aussi ce problème

nick0323 picture nick0323 le 10 juin 2019

@ 323929 Je pense que @danielloczi ne se soucie pas du paramètre pod-eviction-timeout dans kube-controller-manager, mais le résout en utilisant Taint based Evictions ， J'ai testé avec Taint based Evictions , ça a marché pour moi.

zdyxry picture zdyxry le 25 juin 2019

C'est vrai: j'ai simplement commencé à utiliser Taint based Eviction .

danielloczi picture danielloczi le 26 juin 2019

Est-il possible de le rendre mondial? Je ne veux pas activer cela pour chaque configuration de pod, surtout que j'utilise beaucoup de choses préparées à partir de la barre

kamilgregorczyk picture kamilgregorczyk le 2 janv. 2020
👍4

+1 pour avoir la possibilité de le configurer par cluster entier. le réglage par pod ou par déploiement est rarement utile: dans la plupart des cas, une valeur globale raisonnable est plus pratique et la valeur par défaut actuelle de 5 m est trop longue dans de nombreux cas.

veuillez rouvrir ce numéro.

morgwai picture morgwai le 8 févr. 2020

Je suis confronté au même problème, existe-t-il un moyen de désactiver les expulsions basées sur Taint et que le délai d'expulsion de pod fonctionne en mode global?

richardqa picture richardqa le 7 mars 2020

Je suis confronté au même problème, existe-t-il un moyen de désactiver les expulsions basées sur Taint et que le délai d'expulsion de pod fonctionne en mode global?

Je pense que vous pouvez configurer l'expulsion globale des pod via apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
Je n'ai pas essayé cela, mais comme je peux le voir, il existe des options: --default-not-ready-toleration-seconds et --default-uneachable-toleration-seconds.

hrbasic picture hrbasic le 30 mars 2020
👍1

Pourquoi ce bogue a-t-il été marqué comme fermé? Il semble que le problème d'origine ne soit pas résolu, mais seulement contourné.
Je ne vois pas pourquoi l'indicateur de délai d'expulsion de pod ne fonctionne pas

enricovittorini picture enricovittorini le 13 avr. 2020

même problème

pythonzm picture pythonzm le 15 avr. 2020
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

alexferl picture alexferl  ·  3Commentaires
sjenning picture sjenning  ·  3Commentaires
pwittrock picture pwittrock  ·  3Commentaires
Seb-Solon picture Seb-Solon  ·  3Commentaires
jason-riddle picture jason-riddle  ·  3Commentaires