Kubernetes: Certains nœuds ne sont pas pris en compte dans la planification en cas de déséquilibre de zone

/ sig planification

Pouvez-vous fournir le yaml complet du nœud, de l'ensemble de démons, d'un exemple de pod et de l'espace de noms contenant comme récupéré à partir du serveur?

nœud:
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

démonset:
https://gist.github.com/zetaab/31bb406c8bd622b3017bf4f468d0154f

exemple de pod (en fonctionnement):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

exemple de pod (pas de planification):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

espace de noms:
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

Les pods DaemonSet planifient avec un sélecteur nodeAffinity qui ne correspond qu'à un seul nœud, donc le message «12 sur 13 ne correspond pas» est attendu.

Je ne vois pas de raison pour laquelle le planificateur ne serait pas satisfait du combo pod / nœud ... il n'y a pas de ports qui pourraient entrer en conflit dans le podspec, le nœud n'est pas imprévisible ou corrompu, et dispose de ressources suffisantes

D'accord, j'ai redémarré les 3 planificateurs (changé le niveau de journalisation à 4 si nous pouvons y voir quelque chose d'intéressant). Cependant, cela a résolu le problème

% kubectl get ds --all-namespaces
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
falco         falco-daemonset            13        13        13      13           13          <none>                            338d
kube-system   audit-webhook-deployment   3         3         3       3            3           node-role.kubernetes.io/master=   175d
kube-system   calico-node                13        13        13      13           13          kubernetes.io/os=linux            36d
kube-system   kops-controller            3         3         3       3            3           node-role.kubernetes.io/master=   194d
kube-system   metricbeat                 6         6         6       6            6           <none>                            36d
kube-system   openstack-cloud-provider   3         3         3       3            3           node-role.kubernetes.io/master=   338d
logging       fluent-bit                 13        13        13      13           13          <none>                            338d
monitoring    node-exporter              13        13        13      13           13          kubernetes.io/os=linux            59d
volume        csi-cinder-nodeplugin      6         6         6       6            6           <none>                            239d
weave         weave-scope-agent          13        13        13      13           13          <none>                            194d
weave         weavescope-iowait-plugin   6         6         6       6            6           <none>                            194d

maintenant, tous les démonsets sont correctement provisionnés. Bizarre, de toute façon quelque chose ne va pas avec le planificateur

cc @ kubernetes / sig-scheduling-bugs @ ahg-g

Nous voyons le même problème similaire sur v1.18.3, un nœud ne peut pas être planifié pour les pods de daemonset.
le planificateur de redémarrage aide.

[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get pod -A|grep Pending
kube-system   coredns-vc5ws                                                 0/1     Pending   0          2d16h
kube-system   local-volume-provisioner-mwk88                                0/1     Pending   0          2d16h
kube-system   svcwatcher-ltqb6                                              0/1     Pending   0          2d16h
ncms          bcmt-api-hfzl6                                                0/1     Pending   0          2d16h
ncms          bcmt-yum-repo-589d8bb756-5zbvh                                0/1     Pending   0          2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get ds -A
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
kube-system   coredns                    3         3         2       3            2           is_control=true                 2d16h
kube-system   danmep-cleaner             0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   kube-proxy                 8         8         8       8            8           <none>                          2d16h
kube-system   local-volume-provisioner   8         8         7       8            7           <none>                          2d16h
kube-system   netwatcher                 0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   sriov-device-plugin        0         0         0       0            0           sriov=enabled                   2d16h
kube-system   svcwatcher                 3         3         2       3            2           is_control=true                 2d16h
ncms          bcmt-api                   3         3         0       3            0           is_control=true                 2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get node
NAME                                  STATUS   ROLES    AGE     VERSION
tesla-cb0434-csfp1-csfp1-control-01   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-02   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-03   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-01      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-02      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-01    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-02    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-03    Ready    <none>   2d16h   v1.18.3

Difficile à déboguer sans savoir reproduire. Avez-vous les journaux du planificateur par hasard pour le pod qui n'a pas pu planifier?

D'accord, j'ai redémarré les 3 planificateurs

Je suppose qu'un seul d'entre eux est nommé default-scheduler , n'est-ce pas?

changé le niveau de log à 4 si nous pouvons y voir quelque chose d'intéressant

Pouvez-vous partager ce que vous avez remarqué?

réglez loglevel à 9, mais il semble qu'il n'y ait rien de plus intéressant, les journaux ci-dessous sont en boucle.

I0601 01:45:05.039373       1 generic_scheduler.go:290] Preemption will not help schedule pod kube-system/coredns-vc5ws on any node.
I0601 01:45:05.039437       1 factory.go:462] Unable to schedule kube-system/coredns-vc5ws: no fit: 0/8 nodes are available: 7 node(s) didn't match node selector.; waiting
I0601 01:45:05.039494       1 scheduler.go:776] Updating pod condition for kube-system/coredns-vc5ws to (PodScheduled==False, Reason=Unschedulable)

ouais je ne pouvais rien voir de plus que la même ligne

no fit: 0/8 nodes are available: 7 node(s) didn't match node selector.; waiting

la chose étrange est que le message du journal affiche le résultat pour 7 nœuds uniquement, comme le problème signalé dans https://github.com/kubernetes/kubernetes/issues/91340

/ cc @damemi

@ ahg-g cela ressemble au même problème que j'ai signalé ici, il semble que nous ayons soit un plugin de filtre qui ne signale pas toujours son erreur, soit une autre condition qui échoue silencieusement si je devais deviner

Notez que dans mon problème, le redémarrage du planificateur l'a également corrigé (comme mentionné dans ce fil de discussion également https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

Le mien concernait également un ensemble de démons, donc je pense que c'est un doublon. Si tel est le cas, nous pouvons fermer cela et poursuivre la discussion sur https://github.com/kubernetes/kubernetes/issues/91340

Quoi qu'il en soit, le planificateur a besoin d'une option de journalisation plus détaillée, il est impossible de déboguer ces problèmes s'il n'y a pas de journaux sur ce qu'il fait

@zetaab +1, le planificateur pourrait utiliser des améliorations significatives de ses capacités de journalisation actuelles. C'est une mise à jour que je voulais aborder depuis un moment et j'ai enfin ouvert un problème ici: https://github.com/kubernetes/kubernetes/issues/91633

/attribuer

Je regarde ça. Quelques questions pour m'aider à préciser le cas. Je n'ai pas encore pu me reproduire.

• Qu'est-ce qui a été créé en premier: l'ensemble de démons ou le nœud?
• Utilisez-vous le profil par défaut?

• Avez-vous des prolongateurs?

les nœuds ont été créés avant l'ensemble de démons.
supposons que nous ayons utilisé le profil par défaut, de quel profil parlez-vous et comment le vérifier?
pas de prolongateurs.

    command:
    - /usr/local/bin/kube-scheduler
    - --address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/kube-scheduler.kubeconfig
    - --profiling=false
    - --v=1

Une autre chose qui peut avoir un impact est que les performances du disque ne sont pas très bonnes pour etcd, etcd se plaint de la lenteur des opérations.

Oui, ces indicateurs feraient fonctionner le planificateur avec le profil par défaut. Je vais continuer à chercher. Je ne pouvais toujours pas me reproduire.

Toujours rien ... Y a-t-il autre chose que vous utilisez et qui, selon vous, pourrait avoir un impact? souillures, ports, autres ressources?

J'ai fait quelques essais à ce sujet. Lorsque le problème est activé, les pods peuvent toujours être planifiés sur le nœud (sans définition ou avec le sélecteur "nodeName").

Si vous essayez d'utiliser Affinity / Antiaffinity, les pods ne sont pas programmés sur le nœud.

Travailler lorsque le problème est sur:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  nodeName: master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

Ne fonctionne pas en même temps:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

De plus, une fois vérifiés, ceux-ci étaient même assez intéressants:

Warning  FailedScheduling  4m37s (x17 over 26m)  default-scheduler  0/9 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  97s (x6 over 3m39s)   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  53s                   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  7s (x5 over 32s)      default-scheduler  0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector.

• Le premier événement se produit lorsque le manifeste vient d'être appliqué (rien n'est fait au nœud non planifiable).
• Les deuxième et troisième ont été lorsque le nœud a été supprimé avec kubectl, puis redémarré.
• Le quatrième est venu lorsque le nœud est remonté. Le nœud qui avait un problème était maître, donc le nœud n'y allait pas (mais cela montre que le nœud n'a pas été trouvé lors de 3 événements précédents). Ce qui est intéressant avec le quatrième événement, c'est qu'il manque encore des informations d'un nœud. L'événement indique qu'il y a 0/9 nœuds disponibles, mais la description n'est donnée qu'à partir de 8.

"nodeName" n'est pas un sélecteur. L'utilisation de nodeName contournerait la planification.

Le quatrième est venu lorsque le nœud est remonté. Le nœud qui avait un problème était maître, donc le nœud n'y allait pas (mais cela montre que le nœud n'a pas été trouvé lors de 3 événements précédents). Ce qui est intéressant avec le quatrième événement, c'est qu'il manque encore des informations d'un nœud. L'événement indique qu'il y a 0/9 nœuds disponibles, mais la description n'est donnée qu'à partir de 8.

Vous dites que la raison pour laquelle le pod n'aurait pas dû être planifié dans le nœud manquant est qu'il s'agissait d'un maître?

Nous voyons 8 node(s) didn't match node selector aller à 7. Je suppose qu'aucun nœud n'a été supprimé à ce stade, n'est-ce pas?

"nodeName" n'est pas un sélecteur. L'utilisation de nodeName contournerait la planification.

"NodeName" essayez de mettre en évidence, ce nœud est utilisable et le pod y arrive si vous le souhaitez. Ce n'est donc pas l'incapacité du nœud à démarrer des pods.

Le quatrième est venu lorsque le nœud est remonté. Le nœud qui avait un problème était maître, donc le nœud n'y allait pas (mais cela montre que le nœud n'a pas été trouvé lors de 3 événements précédents). Ce qui est intéressant avec le quatrième événement, c'est qu'il manque encore des informations d'un nœud. L'événement indique qu'il y a 0/9 nœuds disponibles, mais la description n'est donnée qu'à partir de 8.

Vous dites que la raison pour laquelle le pod n'aurait pas dû être planifié dans le nœud manquant est qu'il s'agissait d'un maître?

Nous voyons 8 node(s) didn't match node selector aller à 7. Je suppose qu'aucun nœud n'a été supprimé à ce stade, n'est-ce pas?

Le cluster de test a 9 nœuds; 3 maîtres et 6 ouvriers. Avant le démarrage réussi du nœud non fonctionnel, les événements ont fourni des informations sur tous les nœuds disponibles: 0/8 nodes are available: 8 node(s) didn't match node selector. . Mais quand ce nœud qui correspondrait au sélecteur de nœud est apparu, l'événement a dit à 0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector. explication indique qu'il y en a 8 qui ne correspondent pas, mais ne dit rien sur le neuvième (qui a été reconnu lors de l'événement précédent).

Donc, l'état de l'événement:

• 1er événement: 9 nœuds disponibles, l'erreur constatée avec le daemonset
• 2ème et 3ème événement: 8 nœuds disponibles. Celui qui ne recevait pas le pod redémarrait
• 4ème événement: 9 nœuds disponibles (donc celui démarré qui a été redémarré).

À la fin, le pod de test n'a pas été démarré sur le nœud correspondant à cause de taches, mais c'est une autre histoire (et aurait dû être le cas déjà au 1er événement).

"NodeName" essayez de mettre en évidence, ce nœud est utilisable et le pod y arrive si vous le souhaitez. Ce n'est donc pas l'incapacité du nœud à démarrer des pods.

Notez que rien ne protège contre la sur-validation d'un nœud, mais le planificateur. Donc, cela ne montre pas vraiment grand-chose.

À la fin, le pod de test n'a pas été démarré sur le nœud correspondant à cause de taches, mais c'est une autre histoire (et aurait dû être le cas déjà au 1er événement).

Ma question est la suivante: le 9e nœud a-t-il été contaminé depuis le début? J'essaie de rechercher (1) des étapes reproductibles pour atteindre l'état ou (2) où le bogue pourrait être.

Ma question est la suivante: le 9e nœud a-t-il été contaminé depuis le début? J'essaie de rechercher (1) des étapes reproductibles pour atteindre l'état ou (2) où le bogue pourrait être.

Oui, la souillure était là tout le temps dans ce cas, car le nœud non récepteur était maître. Mais nous avons vu le même problème sur les maîtres et les ouvriers.

Toujours aucune idée d'où vient le problème, juste qu'au moins la recréation du nœud et le redémarrage du nœud semblent résoudre le problème. Mais ce sont des moyens un peu «difficiles» de résoudre les problèmes.

Plan long, mais si vous le rencontrez à nouveau ... pourriez-vous vérifier s'il y a des pods nommés pour le nœud qui n'apparaissent pas?

Je poste des questions en pensant à des scénarios possibles:

• Avez-vous d'autres nœuds maîtres dans votre cluster?
• Avez-vous des prolongateurs?

* Do you have other master nodes in your cluster?

Tous les clusers ont 3 maîtres (donc le redémarrage de ceux-ci est facile)

* Do you have extenders?

Non.

Une chose intéressante a été remarquée aujourd'hui: j'avais un cluster où un maître ne recevait pas de pod de DaemonSet. Nous avons ChaosMonkey en cours d'utilisation, qui a terminé l'un des nœuds de travail. C'est intéressant, cela a amené le pod à aller chez le maître qui ne le recevait pas plus tôt. Ainsi, la suppression d'un autre nœud que le nœud problématique semblait résoudre le problème à ce stade.

À cause de ce «correctif», je dois attendre que le problème se reproduise pour pouvoir répondre à propos des pods nominés.

Je suis confus maintenant ... Votre daemonset tolère-t-il la corruption des nœuds maîtres? En d'autres termes ... le bogue pour vous est-il juste l'événement de planification ou aussi le fait que les pods auraient dû être planifiés?

Le problème est que ce nœud n'est pas trouvé par le planificateur, même s'il y a au moins un paramètre d'affinité (ou d'antiaffinité) correspondant.

C'est pourquoi j'ai dit que l'erreur de contamination était attendue, et qu'elle aurait dû être déjà présente lors du premier événement (car la contamination ne fait pas partie des critères d'affinité)

Compris. J'essayais de confirmer votre configuration pour m'assurer de ne rien manquer.

Je ne pense pas que le nœud soit "invisible" par le planificateur. Étant donné que nous voyons 0/9 nodes are available , nous pouvons conclure que le nœud est bien dans le cache. C'est plutôt comme si la raison imprévisible est perdue quelque part, nous ne l'incluons donc pas dans l'événement.

Il est vrai que le nombre total correspond toujours au nombre réel de nœuds. Un texte d'événement plus descriptif n'est pas donné sur tous les nœuds, mais cela peut être un problème distinct comme vous l'avez mentionné.

Êtes-vous capable de consulter les journaux de votre planificateur kube? Quelque chose qui semble pertinent?

Je pense que @zetaab a essayé de chercher cela sans succès. Je peux essayer lorsque le problème se reproduit (ainsi que le pod nommé demandé plus tôt)

Si possible, exécutez également 1.18.5, au cas où nous aurions résolu le problème par inadvertance.

Je suis en mesure de reproduire cela de manière fiable sur mon cluster de test si vous avez besoin de plus de journaux

@dilyevsky Veuillez partager les étapes de la repro. Pouvez-vous identifier d'une manière ou d'une autre quel est le filtre qui échoue?

Il semble que ce ne soit que les métadonnées.nom du nœud pour le pod ds ... bizarre. Voici le pod yaml:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: "2020-07-09T23:17:53Z"
  generateName: cilium-
  labels:
    controller-revision-hash: 6c94db8bb8
    k8s-app: cilium
    pod-template-generation: "1"
  managedFields:
    # managed fields crap
  name: cilium-d5n4f
  namespace: kube-system
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: DaemonSet
    name: cilium
    uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: /api/v1/namespaces/kube-system/pods/cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - us-central1-dilyevsky-master-qmwnl
  containers:
  - args:
    - --config-dir=/tmp/cilium/config-map
    command:
    - cilium-agent
    env:
    - name: K8S_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    - name: CILIUM_K8S_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    - name: CILIUM_FLANNEL_MASTER_DEVICE
      valueFrom:
        configMapKeyRef:
          key: flannel-master-device
          name: cilium-config
          optional: true
    - name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      valueFrom:
        configMapKeyRef:
          key: flannel-uninstall-on-exit
          name: cilium-config
          optional: true
    - name: CILIUM_CLUSTERMESH_CONFIG
      value: /var/lib/cilium/clustermesh/
    - name: CILIUM_CNI_CHAINING_MODE
      valueFrom:
        configMapKeyRef:
          key: cni-chaining-mode
          name: cilium-config
          optional: true
    - name: CILIUM_CUSTOM_CNI_CONF
      valueFrom:
        configMapKeyRef:
          key: custom-cni-conf
          name: cilium-config
          optional: true
    image: docker.io/cilium/cilium:v1.7.6
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command:
          - /cni-install.sh
          - --enable-debug=false
      preStop:
        exec:
          command:
          - /cni-uninstall.sh
    livenessProbe:
      exec:
        command:
        - cilium
        - status
        - --brief
      failureThreshold: 10
      initialDelaySeconds: 120
      periodSeconds: 30
      successThreshold: 1
      timeoutSeconds: 5
    name: cilium-agent
    readinessProbe:
      exec:
        command:
        - cilium
        - status
        - --brief
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 30
      successThreshold: 1
      timeoutSeconds: 5
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        - SYS_MODULE
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/cilium
      name: cilium-run
    - mountPath: /host/opt/cni/bin
      name: cni-path
    - mountPath: /host/etc/cni/net.d
      name: etc-cni-netd
    - mountPath: /var/lib/cilium/clustermesh
      name: clustermesh-secrets
      readOnly: true
    - mountPath: /tmp/cilium/config-map
      name: cilium-config-path
      readOnly: true
    - mountPath: /lib/modules
      name: lib-modules
      readOnly: true
    - mountPath: /run/xtables.lock
      name: xtables-lock
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: cilium-token-j74lr
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  initContainers:
  - command:
    - /init-container.sh
    env:
    - name: CILIUM_ALL_STATE
      valueFrom:
        configMapKeyRef:
          key: clean-cilium-state
          name: cilium-config
          optional: true
    - name: CILIUM_BPF_STATE
      valueFrom:
        configMapKeyRef:
          key: clean-cilium-bpf-state
          name: cilium-config
          optional: true
    - name: CILIUM_WAIT_BPF_MOUNT
      valueFrom:
        configMapKeyRef:
          key: wait-bpf-mount
          name: cilium-config
          optional: true
    image: docker.io/cilium/cilium:v1.7.6
    imagePullPolicy: IfNotPresent
    name: clean-cilium-state
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/cilium
      name: cilium-run
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: cilium-token-j74lr
      readOnly: true
  priority: 2000001000
  priorityClassName: system-node-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: cilium
  serviceAccountName: cilium
  terminationGracePeriodSeconds: 1
  tolerations:
  - operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/disk-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/pid-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/network-unavailable
    operator: Exists
  volumes:
  - hostPath:
      path: /var/run/cilium
      type: DirectoryOrCreate
    name: cilium-run
  - hostPath:
      path: /opt/cni/bin
      type: DirectoryOrCreate
    name: cni-path
  - hostPath:
      path: /etc/cni/net.d
      type: DirectoryOrCreate
    name: etc-cni-netd
  - hostPath:
      path: /lib/modules
      type: ""
    name: lib-modules
  - hostPath:
      path: /run/xtables.lock
      type: FileOrCreate
    name: xtables-lock
  - name: clustermesh-secrets
    secret:
      defaultMode: 420
      optional: true
      secretName: cilium-clustermesh
  - configMap:
      defaultMode: 420
      name: cilium-config
    name: cilium-config-path
  - name: cilium-token-j74lr
    secret:
      defaultMode: 420
      secretName: cilium-token-j74lr
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-07-09T23:17:53Z"
    message: '0/6 nodes are available: 5 node(s) didn''t match node selector.'
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
  qosClass: BestEffort

La façon dont je reproduis cela est de créer un nouveau cluster avec 3 maîtres et 3 nœuds de travail (à l'aide de l'API de cluster) et d'appliquer Cilium 1.7.6:

---
# Source: cilium/charts/agent/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cilium
  namespace: kube-system
---
# Source: cilium/charts/operator/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cilium-operator
  namespace: kube-system
---
# Source: cilium/charts/config/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:

  # Identity allocation mode selects how identities are shared between cilium
  # nodes by setting how they are stored. The options are "crd" or "kvstore".
  # - "crd" stores identities in kubernetes as CRDs (custom resource definition).
  #   These can be queried with:
  #     kubectl get ciliumid
  # - "kvstore" stores identities in a kvstore, etcd or consul, that is
  #   configured below. Cilium versions before 1.6 supported only the kvstore
  #   backend. Upgrades from these older cilium versions should continue using
  #   the kvstore by commenting out the identity-allocation-mode below, or
  #   setting it to "kvstore".
  identity-allocation-mode: crd

  # If you want to run cilium in debug mode change this value to true
  debug: "false"

  # Enable IPv4 addressing. If enabled, all endpoints are allocated an IPv4
  # address.
  enable-ipv4: "true"

  # Enable IPv6 addressing. If enabled, all endpoints are allocated an IPv6
  # address.
  enable-ipv6: "false"

  # If you want cilium monitor to aggregate tracing for packets, set this level
  # to "low", "medium", or "maximum". The higher the level, the less packets
  # that will be seen in monitor output.
  monitor-aggregation: medium

  # The monitor aggregation interval governs the typical time between monitor
  # notification events for each allowed connection.
  #
  # Only effective when monitor aggregation is set to "medium" or higher.
  monitor-aggregation-interval: 5s

  # The monitor aggregation flags determine which TCP flags which, upon the
  # first observation, cause monitor notifications to be generated.
  #
  # Only effective when monitor aggregation is set to "medium" or higher.
  monitor-aggregation-flags: all

  # ct-global-max-entries-* specifies the maximum number of connections
  # supported across all endpoints, split by protocol: tcp or other. One pair
  # of maps uses these values for IPv4 connections, and another pair of maps
  # use these values for IPv6 connections.
  #
  # If these values are modified, then during the next Cilium startup the
  # tracking of ongoing connections may be disrupted. This may lead to brief
  # policy drops or a change in loadbalancing decisions for a connection.
  #
  # For users upgrading from Cilium 1.2 or earlier, to minimize disruption
  # during the upgrade process, comment out these options.
  bpf-ct-global-tcp-max: "524288"
  bpf-ct-global-any-max: "262144"

  # bpf-policy-map-max specified the maximum number of entries in endpoint
  # policy map (per endpoint)
  bpf-policy-map-max: "16384"

  # Pre-allocation of map entries allows per-packet latency to be reduced, at
  # the expense of up-front memory allocation for the entries in the maps. The
  # default value below will minimize memory usage in the default installation;
  # users who are sensitive to latency may consider setting this to "true".
  #
  # This option was introduced in Cilium 1.4. Cilium 1.3 and earlier ignore
  # this option and behave as though it is set to "true".
  #
  # If this value is modified, then during the next Cilium startup the restore
  # of existing endpoints and tracking of ongoing connections may be disrupted.
  # This may lead to policy drops or a change in loadbalancing decisions for a
  # connection for some time. Endpoints may need to be recreated to restore
  # connectivity.
  #
  # If this option is set to "false" during an upgrade from 1.3 or earlier to
  # 1.4 or later, then it may cause one-time disruptions during the upgrade.
  preallocate-bpf-maps: "false"

  # Regular expression matching compatible Istio sidecar istio-proxy
  # container image names
  sidecar-istio-proxy-image: "cilium/istio_proxy"

  # Encapsulation mode for communication between nodes
  # Possible values:
  #   - disabled
  #   - vxlan (default)
  #   - geneve
  tunnel: vxlan

  # Name of the cluster. Only relevant when building a mesh of clusters.
  cluster-name: default

  # DNS Polling periodically issues a DNS lookup for each `matchName` from
  # cilium-agent. The result is used to regenerate endpoint policy.
  # DNS lookups are repeated with an interval of 5 seconds, and are made for
  # A(IPv4) and AAAA(IPv6) addresses. Should a lookup fail, the most recent IP
  # data is used instead. An IP change will trigger a regeneration of the Cilium
  # policy for each endpoint and increment the per cilium-agent policy
  # repository revision.
  #
  # This option is disabled by default starting from version 1.4.x in favor
  # of a more powerful DNS proxy-based implementation, see [0] for details.
  # Enable this option if you want to use FQDN policies but do not want to use
  # the DNS proxy.
  #
  # To ease upgrade, users may opt to set this option to "true".
  # Otherwise please refer to the Upgrade Guide [1] which explains how to
  # prepare policy rules for upgrade.
  #
  # [0] http://docs.cilium.io/en/stable/policy/language/#dns-based
  # [1] http://docs.cilium.io/en/stable/install/upgrade/#changes-that-may-require-action
  tofqdns-enable-poller: "false"

  # wait-bpf-mount makes init container wait until bpf filesystem is mounted
  wait-bpf-mount: "false"

  masquerade: "true"
  enable-xt-socket-fallback: "true"
  install-iptables-rules: "true"
  auto-direct-node-routes: "false"
  kube-proxy-replacement:  "probe"
  enable-host-reachable-services: "false"
  enable-external-ips: "false"
  enable-node-port: "false"
  node-port-bind-protection: "true"
  enable-auto-protect-node-port-range: "true"
  enable-endpoint-health-checking: "true"
  enable-well-known-identities: "false"
  enable-remote-node-identity: "true"
---
# Source: cilium/charts/agent/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cilium
rules:
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  - services
  - nodes
  - endpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - get
  - list
  - watch
  - update
- apiGroups:
  - cilium.io
  resources:
  - ciliumnetworkpolicies
  - ciliumnetworkpolicies/status
  - ciliumclusterwidenetworkpolicies
  - ciliumclusterwidenetworkpolicies/status
  - ciliumendpoints
  - ciliumendpoints/status
  - ciliumnodes
  - ciliumnodes/status
  - ciliumidentities
  - ciliumidentities/status
  verbs:
  - '*'
---
# Source: cilium/charts/operator/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cilium-operator
rules:
- apiGroups:
  - ""
  resources:
  # to automatically delete [core|kube]dns pods so that are starting to being
  # managed by Cilium
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  # to automatically read from k8s and import the node's pod CIDR to cilium's
  # etcd so all nodes know how to reach another pod running in in a different
  # node.
  - nodes
  # to perform the translation of a CNP that contains `ToGroup` to its endpoints
  - services
  - endpoints
  # to check apiserver connectivity
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - cilium.io
  resources:
  - ciliumnetworkpolicies
  - ciliumnetworkpolicies/status
  - ciliumclusterwidenetworkpolicies
  - ciliumclusterwidenetworkpolicies/status
  - ciliumendpoints
  - ciliumendpoints/status
  - ciliumnodes
  - ciliumnodes/status
  - ciliumidentities
  - ciliumidentities/status
  verbs:
  - '*'
---
# Source: cilium/charts/agent/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cilium
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cilium
subjects:
- kind: ServiceAccount
  name: cilium
  namespace: kube-system
---
# Source: cilium/charts/operator/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cilium-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cilium-operator
subjects:
- kind: ServiceAccount
  name: cilium-operator
  namespace: kube-system
---
# Source: cilium/charts/agent/templates/daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: cilium
  name: cilium
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cilium
  template:
    metadata:
      annotations:
        # This annotation plus the CriticalAddonsOnly toleration makes
        # cilium to be a critical pod in the cluster, which ensures cilium
        # gets priority scheduling.
        # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        k8s-app: cilium
    spec:
      containers:
      - args:
        - --config-dir=/tmp/cilium/config-map
        command:
        - cilium-agent
        livenessProbe:
          exec:
            command:
            - cilium
            - status
            - --brief
          failureThreshold: 10
          # The initial delay for the liveness probe is intentionally large to
          # avoid an endless kill & restart cycle if in the event that the initial
          # bootstrapping takes longer than expected.
          initialDelaySeconds: 120
          periodSeconds: 30
          successThreshold: 1
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - cilium
            - status
            - --brief
          failureThreshold: 3
          initialDelaySeconds: 5
          periodSeconds: 30
          successThreshold: 1
          timeoutSeconds: 5
        env:
        - name: K8S_NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: CILIUM_K8S_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: CILIUM_FLANNEL_MASTER_DEVICE
          valueFrom:
            configMapKeyRef:
              key: flannel-master-device
              name: cilium-config
              optional: true
        - name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
          valueFrom:
            configMapKeyRef:
              key: flannel-uninstall-on-exit
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTERMESH_CONFIG
          value: /var/lib/cilium/clustermesh/
        - name: CILIUM_CNI_CHAINING_MODE
          valueFrom:
            configMapKeyRef:
              key: cni-chaining-mode
              name: cilium-config
              optional: true
        - name: CILIUM_CUSTOM_CNI_CONF
          valueFrom:
            configMapKeyRef:
              key: custom-cni-conf
              name: cilium-config
              optional: true
        image: "docker.io/cilium/cilium:v1.7.6"
        imagePullPolicy: IfNotPresent
        lifecycle:
          postStart:
            exec:
              command:
              - "/cni-install.sh"
              - "--enable-debug=false"
          preStop:
            exec:
              command:
              - /cni-uninstall.sh
        name: cilium-agent
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
            - SYS_MODULE
          privileged: true
        volumeMounts:
        - mountPath: /var/run/cilium
          name: cilium-run
        - mountPath: /host/opt/cni/bin
          name: cni-path
        - mountPath: /host/etc/cni/net.d
          name: etc-cni-netd
        - mountPath: /var/lib/cilium/clustermesh
          name: clustermesh-secrets
          readOnly: true
        - mountPath: /tmp/cilium/config-map
          name: cilium-config-path
          readOnly: true
          # Needed to be able to load kernel modules
        - mountPath: /lib/modules
          name: lib-modules
          readOnly: true
        - mountPath: /run/xtables.lock
          name: xtables-lock
      hostNetwork: true
      initContainers:
      - command:
        - /init-container.sh
        env:
        - name: CILIUM_ALL_STATE
          valueFrom:
            configMapKeyRef:
              key: clean-cilium-state
              name: cilium-config
              optional: true
        - name: CILIUM_BPF_STATE
          valueFrom:
            configMapKeyRef:
              key: clean-cilium-bpf-state
              name: cilium-config
              optional: true
        - name: CILIUM_WAIT_BPF_MOUNT
          valueFrom:
            configMapKeyRef:
              key: wait-bpf-mount
              name: cilium-config
              optional: true
        image: "docker.io/cilium/cilium:v1.7.6"
        imagePullPolicy: IfNotPresent
        name: clean-cilium-state
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
          privileged: true
        volumeMounts:
        - mountPath: /var/run/cilium
          name: cilium-run
      restartPolicy: Always
      priorityClassName: system-node-critical
      serviceAccount: cilium
      serviceAccountName: cilium
      terminationGracePeriodSeconds: 1
      tolerations:
      - operator: Exists
      volumes:
        # To keep state between restarts / upgrades
      - hostPath:
          path: /var/run/cilium
          type: DirectoryOrCreate
        name: cilium-run
      # To install cilium cni plugin in the host
      - hostPath:
          path:  /opt/cni/bin
          type: DirectoryOrCreate
        name: cni-path
        # To install cilium cni configuration in the host
      - hostPath:
          path: /etc/cni/net.d
          type: DirectoryOrCreate
        name: etc-cni-netd
        # To be able to load kernel modules
      - hostPath:
          path: /lib/modules
        name: lib-modules
        # To access iptables concurrently with other processes (e.g. kube-proxy)
      - hostPath:
          path: /run/xtables.lock
          type: FileOrCreate
        name: xtables-lock
        # To read the clustermesh configuration
      - name: clustermesh-secrets
        secret:
          defaultMode: 420
          optional: true
          secretName: cilium-clustermesh
        # To read the configuration from the config map
      - configMap:
          name: cilium-config
        name: cilium-config-path
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 2
    type: RollingUpdate
---
# Source: cilium/charts/operator/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    io.cilium/app: operator
    name: cilium-operator
  name: cilium-operator
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      io.cilium/app: operator
      name: cilium-operator
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      annotations:
      labels:
        io.cilium/app: operator
        name: cilium-operator
    spec:
      containers:
      - args:
        - --debug=$(CILIUM_DEBUG)
        - --identity-allocation-mode=$(CILIUM_IDENTITY_ALLOCATION_MODE)
        - --synchronize-k8s-nodes=true
        command:
        - cilium-operator
        env:
        - name: CILIUM_K8S_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: K8S_NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: CILIUM_DEBUG
          valueFrom:
            configMapKeyRef:
              key: debug
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTER_NAME
          valueFrom:
            configMapKeyRef:
              key: cluster-name
              name: cilium-config
              optional: true
        - name: CILIUM_CLUSTER_ID
          valueFrom:
            configMapKeyRef:
              key: cluster-id
              name: cilium-config
              optional: true
        - name: CILIUM_IPAM
          valueFrom:
            configMapKeyRef:
              key: ipam
              name: cilium-config
              optional: true
        - name: CILIUM_DISABLE_ENDPOINT_CRD
          valueFrom:
            configMapKeyRef:
              key: disable-endpoint-crd
              name: cilium-config
              optional: true
        - name: CILIUM_KVSTORE
          valueFrom:
            configMapKeyRef:
              key: kvstore
              name: cilium-config
              optional: true
        - name: CILIUM_KVSTORE_OPT
          valueFrom:
            configMapKeyRef:
              key: kvstore-opt
              name: cilium-config
              optional: true
        - name: AWS_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              key: AWS_ACCESS_KEY_ID
              name: cilium-aws
              optional: true
        - name: AWS_SECRET_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              key: AWS_SECRET_ACCESS_KEY
              name: cilium-aws
              optional: true
        - name: AWS_DEFAULT_REGION
          valueFrom:
            secretKeyRef:
              key: AWS_DEFAULT_REGION
              name: cilium-aws
              optional: true
        - name: CILIUM_IDENTITY_ALLOCATION_MODE
          valueFrom:
            configMapKeyRef:
              key: identity-allocation-mode
              name: cilium-config
              optional: true
        image: "docker.io/cilium/operator:v1.7.6"
        imagePullPolicy: IfNotPresent
        name: cilium-operator
        livenessProbe:
          httpGet:
            host: '127.0.0.1'
            path: /healthz
            port: 9234
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          timeoutSeconds: 3
      hostNetwork: true
      restartPolicy: Always
      serviceAccount: cilium-operator
      serviceAccountName: cilium-operator

Voici le journal du planificateur:
I0709 23:08:22.055830 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:22.056081 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:23.137451 1 serving.go:313] Generated self-signed cert in-memory W0709 23:08:33.843509 1 authentication.go:297] Error looking up in-cluster authentication configuration: etcdserver: request timed out W0709 23:08:33.843671 1 authentication.go:298] Continuing without authentication configuration. This may treat all requests as anonymous. W0709 23:08:33.843710 1 authentication.go:299] To require authentication configuration lookup to succeed, set --authentication-tolerate-lookup-failure=false I0709 23:08:33.911805 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:33.911989 1 registry.go:150] Registering EvenPodsSpread predicate and priority function W0709 23:08:33.917999 1 authorization.go:47] Authorization is disabled W0709 23:08:33.918162 1 authentication.go:40] Authentication is disabled I0709 23:08:33.918238 1 deprecated_insecure_serving.go:51] Serving healthz insecurely on [::]:10251 I0709 23:08:33.925860 1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.926013 1 shared_informer.go:223] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.930685 1 secure_serving.go:178] Serving securely on 127.0.0.1:10259 I0709 23:08:33.936198 1 tlsconfig.go:240] Starting DynamicServingCertificateController I0709 23:08:34.026382 1 shared_informer.go:230] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:34.036998 1 leaderelection.go:242] attempting to acquire leader lease kube-system/kube-scheduler... I0709 23:08:50.597201 1 leaderelection.go:252] successfully acquired lease kube-system/kube-scheduler E0709 23:08:50.658551 1 factory.go:503] pod: kube-system/coredns-66bff467f8-9rjvd is already present in the active queue E0709 23:12:27.673854 1 factory.go:503] pod kube-system/cilium-vv466 is already present in the backoff queue E0709 23:12:58.099432 1 leaderelection.go:320] error retrieving resource lock kube-system/kube-scheduler: etcdserver: leader changed

Après avoir redémarré les pods du planificateur, le pod en attente est immédiatement planifié.

Quels événements de pod obtenez-vous? Savez-vous s'il y a des taches dans le nœud
où il n'est pas programmé? Cela échoue-t-il uniquement pour les nœuds maîtres ou
nœuds? Y a-t-il suffisamment d'espace dans le nœud?

Le jeu.9 juillet 2020, 19h49, dilyevsky, [email protected]
a écrit:

Il semble que ce ne soit que les métadonnées.nom du nœud du pod ds ...
bizarre. Voici le pod yaml:

apiVersion: v1kind: Podmetadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: cilium-
Étiquettes:
contrôleur-révision-hachage: 6c94db8bb8
k8s-app: cilium
pod-template-generation: "1"
managedFields:
# champs gérés merde
nom: cilium-d5n4f
espace de noms: kube-system
propriétaireRéférences:

• apiVersion: apps / v1
  blockOwnerDeletion: vrai
  contrôleur: vrai
  genre: DaemonSet
  nom: cilium
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: / api / v1 / namespaces / kube-system / pods / cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  affinité:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - clé: metadata.name
  opérateur: In
  valeurs:
  - us-central1-dilyevsky-master-qmwnl
  conteneurs:
• args:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    commander:
  
  
  • agent au cil
    
    env:
  
  
  • nom: K8S_NODE_NAME
    
    valeurDe:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: spec.nodeName
  
  
  • nom: CILIUM_K8S_NAMESPACE
    
    valeurDe:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: metadata.namespace
  
  
  • nom: CILIUM_FLANNEL_MASTER_DEVICE
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: flannel-master-device
    
    nom: cilium-config
    
    facultatif: vrai
  
  
  • nom: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: flanelle-désinstallation-en-sortie
    
    nom: cilium-config
    
    facultatif: vrai
  
  
  • nom: CILIUM_CLUSTERMESH_CONFIG
    
    valeur: / var / lib / cilium / clustermesh /
  
  
  • nom: CILIUM_CNI_CHAINING_MODE
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: cni-chaining-mode
    
    nom: cilium-config
    
    facultatif: vrai
  
  
  • nom: CILIUM_CUSTOM_CNI_CONF
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: custom-cni-conf
    
    nom: cilium-config
    
    facultatif: vrai
    
    image: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    cycle de la vie:
    
    postStart:
    
    exec:
    
    commander:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = false
      
      
      preStop:
      
      
      exec:
      
      
      commander:
    
    
    
    • /cni-uninstall.sh
      
      
      la vivacité
      
      
      exec:
      
      
      commander:
      
      
      
      
      
      
      
      • cil
      
      
      
      
      • statut
      
      
      
      
      • --bref
        
        
        
        échec Seuil: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSecondes: 30
        
        
        
        succès Seuil: 1
        
        
        
        timeoutSecondes: 5
        
        
        
        nom: cilium-agent
        
        
        
        préparation
        
        
        
        exec:
        
        
        
        commander:
      
      
      
      
      • cil
      
      
      
      
      • statut
      
      
      
      
      • --bref
        
        
        
        échec Seuil: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSecondes: 30
        
        
        
        succès Seuil: 1
        
        
        
        timeoutSecondes: 5
        
        
        
        Ressources: {}
        
        
        
        securityContext:
        
        
        
        capacités:
        
        
        
        ajouter:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        privilégié: vrai
        
        
        
        terminaisonMessagePath: / dev / terminaison-log
        
        
        
        terminaisonMessagePolicy: Fichier
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nom: cilium-run
  
  
  • mountPath: / hôte / opt / cni / bin
    
    nom: cni-path
  
  
  • mountPath: /host/etc/cni/net.d
    
    nom: etc-cni-netd
  
  
  • mountPath: / var / lib / cilium / clustermesh
    
    nom: clustermesh-secrets
    
    readOnly: vrai
  
  
  • mountPath: / tmp / cilium / config-map
    
    nom: chemin-de-configuration-cilium
    
    readOnly: vrai
  
  
  • mountPath: / lib / modules
    
    nom: lib-modules
    
    readOnly: vrai
  
  
  • mountPath: /run/xtables.lock
    
    nom: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nom: cilium-token-j74lr
    
    readOnly: vrai
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: true
    
    hostNetwork: vrai
    
    initContainers:
  
  
• commander:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • nom: CILIUM_ALL_STATE
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: clean-cilium-state
    
    nom: cilium-config
    
    facultatif: vrai
  
  
  • nom: CILIUM_BPF_STATE
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: clean-cilium-bpf-state
    
    nom: cilium-config
    
    facultatif: vrai
  
  
  • nom: CILIUM_WAIT_BPF_MOUNT
    
    valeurDe:
    
    configMapKeyRef:
    
    clé: wait-bpf-mount
    
    nom: cilium-config
    
    facultatif: vrai
    
    image: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    nom: clean-cilium-state
    
    Ressources: {}
    
    securityContext:
    
    capacités:
    
    ajouter:
    
    
    
    
    
    • NET_ADMIN
      
      
      privilégié: vrai
      
      
      terminaisonMessagePath: / dev / terminaison-log
      
      
      terminaisonMessagePolicy: Fichier
      
      
      volumeMounts:
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nom: cilium-run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nom: cilium-token-j74lr
    
    readOnly: vrai
    
    priorité: 2000001000
    
    priorityClassName: système critique pour le nœud
    
    restartPolicy: toujours
    
    schedulerName: programmateur par défaut
    
    securityContext: {}
    
    serviceAccount: cilium
    
    serviceAccountName: cilium
    
    terminaisonGracePeriodSecondes: 1
    
    tolérances:
  
  
• opérateur: existe
• effet: NoExecute
  clé: node.kubernetes.io/not-ready
  opérateur: existe
• effet: NoExecute
  clé: node.kubernetes.io/unreachable
  opérateur: existe
• effet: NoSchedule
  clé: node.kubernetes.io/disk-pressure
  opérateur: existe
• effet: NoSchedule
  clé: node.kubernetes.io/memory-pressure
  opérateur: existe
• effet: NoSchedule
  clé: node.kubernetes.io/pid-pressure
  opérateur: existe
• effet: NoSchedule
  clé: node.kubernetes.io/unschedulable
  opérateur: existe
• effet: NoSchedule
  clé: node.kubernetes.io/network-unavailable
  opérateur: existe
  volumes:
• hostPath:
  chemin: / var / run / cilium
  type: DirectoryOrCreate
  nom: cilium-run
• hostPath:
  chemin: / opt / cni / bin
  type: DirectoryOrCreate
  nom: cni-path
• hostPath:
  chemin: /etc/cni/net.d
  type: DirectoryOrCreate
  nom: etc-cni-netd
• hostPath:
  chemin: / lib / modules
  tapez: ""
  nom: lib-modules
• hostPath:
  chemin: /run/xtables.lock
  type: FileOrCreate
  nom: xtables-lock
• nom: clustermesh-secrets
  secret:
  defaultMode: 420
  facultatif: vrai
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  nom: cilium-config
  nom: chemin-de-configuration-cilium
• nom: cilium-token-j74lr
  secret:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  conditions:
• lastProbeTime: null
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  message: '0/6 nœuds sont disponibles: 5 nœuds ne correspondent pas au sélecteur de nœuds.'
  raison: non planifiable
  statut: "Faux"
  type: PodScheduled
  phase: en attente
  qosClass: BestEffort

La façon dont je reproduis cela est de créer un nouveau cluster avec 2 maîtres et
3 nœuds de travail (utilisant l'API de cluster) et appliquant Cilium 1.7.6:

--- # Source: cilium / charts / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nom: cilium
espace de noms: kube-system
--- # Source: cilium / charts / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nom: opérateur-cil
espace de noms: kube-system
--- # Source: cilium / charts / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
nom: cilium-config
espace de noms: kube-systemdata:

# Le mode d'allocation d'identité sélectionne la manière dont les identités sont partagées entre cilium
# nœuds en définissant leur mode de stockage. Les options sont "crd" ou "kvstore".
# - "crd" stocke les identités dans kubernetes en tant que CRD (définition de ressource personnalisée).
# Ceux-ci peuvent être interrogés avec:
# kubectl obtenir ciliumid
# - "kvstore" stocke les identités dans un kvstore, etcd ou consul, c'est-à-dire
# configuré ci-dessous. Les versions de Cilium antérieures à 1.6 ne supportaient que le kvstore
# backend. Les mises à niveau de ces anciennes versions de cilium devraient continuer à utiliser
# le kvstore en commentant le mode d'allocation d'identité ci-dessous, ou
# en le définissant sur "kvstore".
mode d'allocation d'identité: crd

# Si vous souhaitez exécuter cilium en mode débogage, changez cette valeur en true
debug: "false"

# Activez l'adressage IPv4. Si activé, tous les points de terminaison se voient attribuer un IPv4
# adresse.
enable-ipv4: "vrai"

# Activez l'adressage IPv6. S'il est activé, tous les points de terminaison reçoivent un IPv6
# adresse.
enable-ipv6: "faux"

# Si vous voulez que cilium monitor agrège le traçage des paquets, définissez ce niveau
# à "faible", "moyen" ou "maximum". Plus le niveau est élevé, moins il y a de paquets
# qui sera vu dans la sortie du moniteur.
moniteur-agrégation: moyen

# L'intervalle d'agrégation du moniteur régit le temps typique entre le moniteur
# événements de notification pour chaque connexion autorisée.
#
# Efficace uniquement lorsque l'agrégation des moniteurs est définie sur "moyen" ou supérieur.
intervalle d'agrégation de surveillance: 5 s

# Les indicateurs d'agrégation de moniteur déterminent les indicateurs TCP qui, lors de la
# première observation, provoque la génération de notifications de surveillance.
#
# Efficace uniquement lorsque l'agrégation des moniteurs est définie sur "moyen" ou supérieur.
indicateurs-d'agrégation de contrôle: tous

# ct-global-max-entries- * spécifie le nombre maximum de connexions
# pris en charge sur tous les points de terminaison, répartis par protocole: tcp ou autre. Une paire
Le nombre de cartes utilise ces valeurs pour les connexions IPv4 et une autre paire de cartes
# utilisez ces valeurs pour les connexions IPv6.
#
# Si ces valeurs sont modifiées, lors du prochain démarrage de Cilium, le
# le suivi des connexions en cours peut être interrompu. Cela peut conduire à un bref
# abandon de politique ou modification des décisions d'équilibrage de charge pour une connexion.
#
# Pour les utilisateurs qui mettent à niveau depuis Cilium 1.2 ou version antérieure, afin de minimiser les perturbations
# pendant le processus de mise à niveau, commentez ces options.
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max a spécifié le nombre maximum d'entrées dans endpoint
# policy map (par point de terminaison)
bpf-policy-map-max: "16384"

# La pré-allocation des entrées de carte permet de réduire la latence par paquet, à
# les frais d'allocation mémoire initiale pour les entrées dans les cartes. le
# la valeur par défaut ci-dessous minimisera l'utilisation de la mémoire dans l'installation par défaut;
# les utilisateurs sensibles à la latence peuvent envisager de définir ce paramètre sur "true".
#
# Cette option a été introduite dans Cilium 1.4. Cilium 1.3 et versions antérieures ignorent
# cette option et se comportent comme si elle était définie sur "true".
#
# Si cette valeur est modifiée, lors du prochain démarrage de Cilium, la restauration
Le nombre de points de terminaison existants et le suivi des connexions en cours peuvent être interrompus.
# Cela peut entraîner des baisses de politique ou un changement dans les décisions d'équilibrage de charge pour un
# connexion depuis un certain temps. Les points de terminaison doivent peut-être être recréés pour restaurer
# connectivité.
#
# Si cette option est définie sur "false" lors d'une mise à niveau de la version 1.3 ou antérieure vers
# 1.4 ou version ultérieure, cela peut provoquer des perturbations ponctuelles pendant la mise à niveau.
préallouer-bpf-maps: "false"

# Expression régulière correspondant au sidecar Istio compatible istio-proxy
# noms d'image de conteneur
sidecar-istio-proxy-image: "cilium / istio_proxy"

# Mode d'encapsulation pour la communication entre nœuds
# Valeurs possibles:
# - désactivée
# - vxlan (par défaut)
# - genève
tunnel: vxlan

# Nom du cluster. Uniquement pertinent lors de la création d'un maillage de clusters.
nom-cluster: par défaut

# DNS Polling émet périodiquement une recherche DNS pour chaque matchName de
# cilium-agent. Le résultat est utilisé pour régénérer la stratégie de point de terminaison.
# Les recherches DNS sont répétées avec un intervalle de 5 secondes et sont faites pour
# Adresses A (IPv4) et AAAA (IPv6). Si une recherche échoue, l'adresse IP la plus récente
# data est utilisé à la place. Un changement d'IP déclenchera une régénération du Cilium
# stratégie pour chaque endpoint et incrémenter la stratégie par agent cilium
# révision du référentiel.
#
# Cette option est désactivée par défaut à partir de la version 1.4.x en faveur
# d'une implémentation basée sur un proxy DNS plus puissante, voir [0] pour plus de détails.
# Activez cette option si vous souhaitez utiliser des stratégies FQDN mais ne souhaitez pas utiliser
# le proxy DNS.
#
# Pour faciliter la mise à niveau, les utilisateurs peuvent choisir de définir cette option sur "true".
# Sinon, veuillez vous référer au Guide de mise à niveau [1] qui explique comment
# préparer les règles de stratégie pour la mise à niveau.
#
# [0] http://docs.cilium.io/en/stable/policy/language/#dns -based
# [1] http://docs.cilium.io/en/stable/install/upgrade/#changes -that-may-require-action
tofqdns-enable-poller: "false"

# wait-bpf-mount fait attendre le conteneur d'initialisation jusqu'à ce que le système de fichiers bpf soit monté
wait-bpf-mount: "faux"

mascarade: "vrai"
enable-xt-socket-fallback: "vrai"
install-iptables-rules: "vrai"
auto-direct-node-routes: "false"
remplacement de kube-proxy: "sonde"
enable-host-reachable-services: "false"
enable-external-ips: "faux"
enable-node-port: "false"
protection de liaison de port de nœud: "vrai"
enable-auto-protect-node-port-range: "true"
enable-endpoint-health-checking: "vrai"
enable-well-known-identities: "false"
enable-remote-node-identity: "vrai"
--- # Source: cilium / charts / agent / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
nom: ciliumrules:

• apiGroups:
  
  
  
  • networking.k8s.io
    
    Ressources:
  
  
  • politiques de réseau
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Ressources:
  
  
  • points de terminaison
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressources:
  
  
  • espaces de noms
  
  
  • prestations de service
  
  
  • nœuds
  
  
  • points de terminaison
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressources:
  
  
  • gousses
  
  
  • nœuds
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
  • mettre à jour
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressources:
  
  
  • nœuds
  
  
  • nœuds / état
    
    verbes:
  
  
  • pièce
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    Ressources:
  
  
  • définitions personnalisées
    
    verbes:
  
  
  • créer
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
  • mettre à jour
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ressources:
  
  
  • politiques de réseau cilium
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolitiques
  
  
  • ciliumclusterwidenetworkpolitiques / statut
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • noeuds cilium
  
  
  • ciliumnodes / status
  
  
  • ciliumidentités
  
  
  • cilium identités / statut
    
    verbes:
  
  
  • '*'
    
    --- # Source: cilium / charts / operator / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    nom: règles d'opérateur cil:
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressources:
    
    # pour supprimer automatiquement les pods dns [core | kube] afin qu'ils commencent à être
    
    # géré par Cilium
  
  
  • gousses
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
  • effacer
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Ressources:
  
  
  • points de terminaison
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressources:
    
    # pour lire automatiquement à partir de k8 et importer le CIDR du pod du nœud dans celui de cilium
    
    # etcd pour que tous les nœuds sachent comment atteindre un autre pod s'exécutant dans un autre
    
    # nœud.
  
  
  • nœuds
    
    # pour effectuer la traduction d'un CNP contenant ToGroup vers ses points de terminaison
  
  
  • prestations de service
  
  
  • points de terminaison
    
    # pour vérifier la connectivité Apiserver
  
  
  • espaces de noms
    
    verbes:
  
  
  • avoir
  
  
  • liste
  
  
  • regarder
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ressources:
  
  
  • politiques de réseau cilium
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolitiques
  
  
  • ciliumclusterwidenetworkpolitiques / statut
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • noeuds cilium
  
  
  • ciliumnodes / status
  
  
  • ciliumidentités
  
  
  • cilium identités / statut
    
    verbes:
  
  
  • '*'
    
    --- # Source: cilium / charts / agent / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    nom: ciliumrole Réf:
    
    apiGroup: rbac.authorization.k8s.io
    
    genre: ClusterRole
    
    nom: ciliumsubjects:
  
  
• genre: ServiceAccount
  nom: cilium
  espace de noms: kube-system
  --- # Source: cilium / charts / operator / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  nom: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  genre: ClusterRole
  nom: cilium-operatorsubjects:
• genre: ServiceAccount
  nom: opérateur-cil
  espace de noms: kube-system
  --- # Source: cilium / charts / agent / templates / daemonset.yamlapiVersion: apps / v1kind: DaemonSetmetadata:
  Étiquettes:
  k8s-app: cilium
  nom: cilium
  espace de noms: kube-systemspec:
  sélecteur:
  matchLabels:
  k8s-app: cilium
  modèle:
  métadonnées:
  annotations:
  # Cette annotation et la tolérance CriticalAddonsOnly rendent
  # cilium pour être un pod critique dans le cluster, ce qui garantit le cil
  # obtient une planification prioritaire.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  scheduler.alpha.kubernetes.io/critical-pod: ""
  Étiquettes:
  k8s-app: cilium
  spec:
  conteneurs:
  
  
  
  • args:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      commander:
    
    
    
    • agent au cil
      
      
      la vivacité
      
      
      exec:
      
      
      commander:
      
      
      
      
      
      
      
      • cil
      
      
      
      
      • statut
      
      
      
      
      • --bref
        
        
        
        échec Seuil: 10
        
        
        
        # Le délai initial de la sonde de vivacité est intentionnellement
        
        
        
        # éviter un cycle d'arrêt et de redémarrage sans fin si dans le cas où
        
        
        
        # l'amorçage prend plus de temps que prévu.
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSecondes: 30
        
        
        
        succès Seuil: 1
        
        
        
        timeoutSecondes: 5
        
        
        
        préparation
        
        
        
        exec:
        
        
        
        commander:
      
      
      
      
      • cil
      
      
      
      
      • statut
      
      
      
      
      • --bref
        
        
        
        échec Seuil: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSecondes: 30
        
        
        
        succès Seuil: 1
        
        
        
        timeoutSecondes: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • nom: K8S_NODE_NAME
      
      
      valeurDe:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nom: CILIUM_K8S_NAMESPACE
      
      
      valeurDe:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nom: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: flannel-master-device
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: flanelle-désinstallation-en-sortie
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_CLUSTERMESH_CONFIG
      
      
      valeur: / var / lib / cilium / clustermesh /
    
    
    
    • nom: CILIUM_CNI_CHAINING_MODE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: cni-chaining-mode
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_CUSTOM_CNI_CONF
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: custom-cni-conf
      
      
      nom: cilium-config
      
      
      facultatif: vrai
      
      
      image: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      cycle de la vie:
      
      
      postStart:
      
      
      exec:
      
      
      commander:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        exec:
        
        
        
        commander:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        nom: cilium-agent
        
        
        
        securityContext:
        
        
        
        capacités:
        
        
        
        ajouter:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          privilégié: vrai
          
          
          
          
          volumeMounts:
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nom: cilium-run
    
    
    
    • mountPath: / hôte / opt / cni / bin
      
      
      nom: cni-path
    
    
    
    • mountPath: /host/etc/cni/net.d
      
      
      nom: etc-cni-netd
    
    
    
    • mountPath: / var / lib / cilium / clustermesh
      
      
      nom: clustermesh-secrets
      
      
      readOnly: vrai
    
    
    
    • mountPath: / tmp / cilium / config-map
      
      
      nom: chemin-de-configuration-cilium
      
      
      readOnly: vrai
      
      
      # Nécessaire pour pouvoir charger les modules du noyau
    
    
    
    • mountPath: / lib / modules
      
      
      nom: lib-modules
      
      
      readOnly: vrai
    
    
    
    • mountPath: /run/xtables.lock
      
      
      nom: xtables-lock
      
      
      hostNetwork: vrai
      
      
      initContainers:
    
    
    
  
  
  • commander:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • nom: CILIUM_ALL_STATE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: clean-cilium-state
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_BPF_STATE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: clean-cilium-bpf-state
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_WAIT_BPF_MOUNT
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: wait-bpf-mount
      
      
      nom: cilium-config
      
      
      facultatif: vrai
      
      
      image: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nom: clean-cilium-state
      
      
      securityContext:
      
      
      capacités:
      
      
      ajouter:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        privilégié: vrai
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nom: cilium-run
      
      
      restartPolicy: toujours
      
      
      priorityClassName: système critique pour le nœud
      
      
      serviceAccount: cilium
      
      
      serviceAccountName: cilium
      
      
      terminaisonGracePeriodSecondes: 1
      
      
      tolérances:
    
    
    
  
  
  • opérateur: existe
    
    volumes:
    
    # Pour conserver l'état entre les redémarrages / mises à niveau
  
  
  • hostPath:
    
    chemin: / var / run / cilium
    
    type: DirectoryOrCreate
    
    nom: cilium-run
    
    # Pour installer le plugin cilium cni dans l'hôte
  
  
  • hostPath:
    
    chemin: / opt / cni / bin
    
    type: DirectoryOrCreate
    
    nom: cni-path
    
    # Pour installer la configuration cilium cni dans l'hôte
  
  
  • hostPath:
    
    chemin: /etc/cni/net.d
    
    type: DirectoryOrCreate
    
    nom: etc-cni-netd
    
    # Pour pouvoir charger les modules du noyau
  
  
  • hostPath:
    
    chemin: / lib / modules
    
    nom: lib-modules
    
    # Pour accéder à iptables simultanément avec d'autres processus (par exemple kube-proxy)
  
  
  • hostPath:
    
    chemin: /run/xtables.lock
    
    type: FileOrCreate
    
    nom: xtables-lock
    
    # Pour lire la configuration du clustermesh
  
  
  • nom: clustermesh-secrets
    
    secret:
    
    defaultMode: 420
    
    facultatif: vrai
    
    secretName: cilium-clustermesh
    
    # Pour lire la configuration depuis la carte de configuration
  
  
  • configMap:
    
    nom: cilium-config
    
    nom: chemin-de-configuration-cilium
    
    updateStrategy:
    
    RollingUpdate:
    
    max Non disponible: 2
    
    type: RollingUpdate
    
    --- # Source: cilium / charts / operator / templates / deployment.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    Étiquettes:
    
    io.cilium / app: opérateur
    
    nom: opérateur-cil
    
    nom: opérateur-cil
    
    espace de noms: kube-systemspec:
    
    répliques: 1
    
    sélecteur:
    
    matchLabels:
    
    io.cilium / app: opérateur
    
    nom: opérateur-cil
    
    stratégie:
    
    RollingUpdate:
    
    maxSurge: 1
    
    max Non disponible: 1
    
    type: RollingUpdate
    
    modèle:
    
    métadonnées:
    
    annotations:
    
    Étiquettes:
    
    io.cilium / app: opérateur
    
    nom: opérateur-cil
    
    spec:
    
    conteneurs:
  
  
  • args:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identity-allocation-mode = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-nodes = vrai
      
      
      commander:
    
    
    
    • opérateur cilium
      
      
      env:
    
    
    
    • nom: CILIUM_K8S_NAMESPACE
      
      
      valeurDe:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nom: K8S_NODE_NAME
      
      
      valeurDe:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nom: CILIUM_DEBUG
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: déboguer
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_CLUSTER_NAME
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: nom du cluster
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_CLUSTER_ID
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: ID de cluster
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_IPAM
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: ipam
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: disable-endpoint-crd
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_KVSTORE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: kvstore
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_KVSTORE_OPT
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: kvstore-opt
      
      
      nom: cilium-config
      
      
      facultatif: vrai
    
    
    
    • nom: AWS_ACCESS_KEY_ID
      
      
      valeurDe:
      
      
      secretKeyRef:
      
      
      clé: AWS_ACCESS_KEY_ID
      
      
      nom: cilium-aws
      
      
      facultatif: vrai
    
    
    
    • nom: AWS_SECRET_ACCESS_KEY
      
      
      valeurDe:
      
      
      secretKeyRef:
      
      
      clé: AWS_SECRET_ACCESS_KEY
      
      
      nom: cilium-aws
      
      
      facultatif: vrai
    
    
    
    • nom: AWS_DEFAULT_REGION
      
      
      valeurDe:
      
      
      secretKeyRef:
      
      
      clé: AWS_DEFAULT_REGION
      
      
      nom: cilium-aws
      
      
      facultatif: vrai
    
    
    
    • nom: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valeurDe:
      
      
      configMapKeyRef:
      
      
      clé: mode d'allocation d'identité
      
      
      nom: cilium-config
      
      
      facultatif: vrai
      
      
      image: "docker.io/cilium/ opérateur: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nom: opérateur-cil
      
      
      la vivacité
      
      
      httpGet:
      
      
      hôte: '127.0.0.1'
      
      
      chemin: / healthz
      
      
      port: 9234
      
      
      schéma: HTTP
      
      
      initialDelaySeconds: 60
      
      
      periodSecondes: 10
      
      
      timeoutSecondes: 3
      
      
      hostNetwork: vrai
      
      
      restartPolicy: toujours
      
      
      serviceAccount: opérateur cilium
      
      
      serviceAccountName: opérateur cilium
    
    
    
  
  

-
Vous recevez cela parce que vous avez été affecté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

Pourriez-vous essayer d'augmenter le niveau de journalisation et d'utiliser grep pour filtrer le nœud
ou le pod?

Le jeu.9 juillet 2020, 19h55 dilyevsky, [email protected]
a écrit:

Voici le journal du planificateur:

I0709 23: 08: 22.056081 1 registry.go: 150] Enregistrement de la fonction de prédicat et de priorité EvenPodsSpread
I0709 23: 08: 23.137451 1 portion.go: 313] Certificat auto-signé généré en mémoire
W0709 23: 08: 33.843509 1 authentication.go: 297] Erreur lors de la recherche de la configuration de l'authentification dans le cluster: etcdserver: la requête a expiré
W0709 23: 08: 33.843671 1 authentication.go: 298] Poursuite sans configuration d'authentification. Cela peut traiter toutes les demandes comme anonymes.
W0709 23: 08: 33.843710 1 authentication.go: 299] Pour exiger que la recherche de configuration d'authentification réussisse, définissez --authentication-tolerate-lookup-failure = false
I0709 23: 08: 33.911805 1 registry.go: 150] Enregistrement du prédicat et de la fonction de priorité EvenPodsSpread
I0709 23: 08: 33.911989 1 registry.go: 150] Enregistrement de la fonction de prédicat et de priorité EvenPodsSpread
W0709 23: 08: 33.917999 1 authorisation.go: 47] L'autorisation est désactivée
W0709 23: 08: 33.918162 1 authentication.go: 40] L'authentification est désactivée
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Traitement non sécurisé de healthz sur [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] Démarrage de client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.926013 1 shared_informer.go: 223] En attente de synchronisation des caches pour client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Service en toute sécurité sur 127.0.0.1:10259
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] Démarrage de DynamicServingCertificateController
I0709 23: 08: 34.026382 1 shared_informer.go: 230] Les caches sont synchronisés pour client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 34.036998 1 leaderelection.go: 242] essayant d'acquérir le bail leader kube-system / kube-scheduler ...
I0709 23: 08: 50.597201 1 leaderelection.go: 252] a acquis avec succès le bail kube-system / kube-scheduler
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd est déjà présent dans la file d'attente active
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 est déjà présent dans la file d'attente d'interruption
E0709 23: 12: 58.099432 1 leaderelection.go: 320] erreur lors de la récupération du verrou de ressource kube-system / kube-scheduler: etcdserver: leader changé

Après avoir redémarré les pods du planificateur, le pod en attente est immédiatement planifié.

-
Vous recevez cela parce que vous avez été affecté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Ce sont des événements:
`` Événements:
Tapez la raison Âge du message
---- ------ ---- ---- -------
Échec de l'avertissementdefault-scheduler 0/6 nœuds sont disponibles: 5 nœuds ne correspondent pas au sélecteur de nœuds.
Échec de l'avertissementdefault-scheduler 0/6 nœuds sont disponibles: 5 nœuds ne correspondent pas au sélecteur de nœuds.

The node only has two taints but the pod tolerates all existing taints and yeah it seems to only happen on masters:

Taints: node-role.kubernetes.io/ master: NoSchedule
node.kubernetes.io/network-un disponible: NoSchedule

There is enough space and pod is best effort with no reservation anyway:
```  Resource                   Requests    Limits
  --------                   --------    ------
  cpu                        650m (32%)  0 (0%)
  memory                     70Mi (0%)   170Mi (2%)
  ephemeral-storage          0 (0%)      0 (0%)
  hugepages-1Gi              0 (0%)      0 (0%)
  hugepages-2Mi              0 (0%)      0 (0%)
  attachable-volumes-gce-pd  0           0

Je vais essayer d'augmenter le niveau de journal du planificateur maintenant ...

Votre pod yaml n'a pas réellement node-role.kubernetes.io/master tolérance

Salut! Nous rencontrons le même problème. Cependant, nous constatons le même problème avec les déploiements, où nous utilisons l'anti-affinité pour nous assurer qu'un pod est planifié sur chaque nœud ou un sélecteur de pod ciblant le nœud spécifique.
La simple création d'un pod avec un sélecteur de nœud défini pour correspondre au nom d'hôte du nœud défaillant était suffisante pour provoquer l'échec de la planification. Il disait que 5 nœuds ne correspondaient pas au sélecteur, mais rien sur le sixième. Le redémarrage du planificateur a résolu le problème. Cela ressemble à quelque chose qui est mis en cache sur ce nœud et empêche la planification sur le nœud.
Comme d'autres personnes l'ont déjà dit, nous n'avons rien dans le journal concernant l'échec.

Nous avons réduit le déploiement échoué au strict minimum (nous avons supprimé le tache sur le maître qui échoue):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
      restartPolicy: Always
      schedulerName: default-scheduler
      nodeSelector:
        kubernetes.io/hostname: master-2

Nous avions le même problème lorsque le maître avait une souillure et le déploiement une tolérance pour la souillure. Cela ne semble donc pas lié aux démonsets, aux tolérances ou à l'affinité / anti-affinité en particulier. Lorsque l'échec commence à se produire, rien qui cible le nœud spécifique ne peut être planifié. Nous voyons le problème de 1.18.2 à 1.18.5 (je n'ai pas essayé avec 1.18.0 ou .1)

La simple création d'un pod avec un sélecteur de nœud défini pour correspondre au nom d'hôte du nœud défaillant était suffisante pour provoquer l'échec de la planification

Pourriez-vous préciser s'il a commencé à échouer après la création d'un tel pod ou avant? Je suppose que ce nœud n'avait pas de souillure que le pod ne tolérait pas.

@nodo va aider à se reproduire. Pourriez-vous regarder le code de NodeSelector? Vous devrez peut-être ajouter des lignes de journal supplémentaires lors du test. Vous pouvez également imprimer le cache.

• Obtenir le PID de kube-scheduler: $ pidof kube-scheduler
• Déclencher le vidage de la file d'attente: $ sudo kill -SIGUSR2 <pid> . Notez que cela ne tuera pas le processus du planificateur.
• Ensuite, dans le journal du planificateur, recherchez les chaînes "Dump of cached NodeInfo", "Dump of scheduling queue" et "cache comparateur started".

/ priorité critique-urgente

/ annuler l'attribution

Nous voyions déjà un ensemble de démons et un déploiement bloqués dans «En attente» avant d'essayer de déployer ce déploiement de test, il échouait donc déjà. et les souillures avaient été enlevées du nœud.
À l'heure actuelle, nous avons perdu l'environnement dans lequel cela se produisait car nous avons dû redémarrer les nœuds pour que le problème ne soit plus visible. Dès que nous nous reproduirons, nous essaierons de revenir avec plus d'infos

S'il-vous-plaît faites ainsi. J'ai essayé de reproduire cela dans le passé sans succès. Je suis plus intéressé par la première instance d'échec. Cela pourrait encore être lié aux souillures.

Nous avons reproduit le numéro. J'ai exécuté la commande que vous avez demandée, voici les informations:

I0716 14:47:52.768362       1 factory.go:462] Unable to schedule default/test-deployment-558f47bbbb-4rt5t: no fit: 0/6 nodes are available: 5 node(s) didn't match node selector.; waiting
I0716 14:47:52.768683       1 scheduler.go:776] Updating pod condition for default/test-deployment-558f47bbbb-4rt5t to (PodScheduled==False, Reason=Unschedulable)
I0716 14:47:53.018781       1 httplog.go:90] verb="GET" URI="/healthz" latency=299.172µs resp=200 UserAgent="kube-probe/1.18" srcIP="127.0.0.1:57258": 
I0716 14:47:59.469828       1 comparer.go:42] cache comparer started
I0716 14:47:59.470936       1 comparer.go:67] cache comparer finished
I0716 14:47:59.471038       1 dumper.go:47] Dump of cached NodeInfo
I0716 14:47:59.471484       1 dumper.go:49] 
Node name: master-0-bug
Requested Resources: {MilliCPU:1100 Memory:52428800 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}
Allocatable Resources:{MilliCPU:2000 Memory:3033427968 EphemeralStorage:19290208634 AllowedPodNumber:110 ScalarResources:map[hugepages-1Gi:0 hugepages-2Mi:0]}
Scheduled Pods(number: 9):
...
I0716 14:47:59.472623       1 dumper.go:60] Dump of scheduling queue:
name: coredns-cd64c8d7c-29zjq, namespace: kube-system, uid: 938e8827-5d17-4db9-ac04-d229baf4534a, phase: Pending, nominated node: 
name: test-deployment-558f47bbbb-4rt5t, namespace: default, uid: fa19fda9-c8d6-4ffe-b248-8ddd24ed5310, phase: Pending, nominated node: 

Malheureusement, cela ne semble pas aider

Le vidage du cache sert au débogage, cela ne changera rien. Pourriez-vous s'il vous plaît inclure la décharge?

De plus, en supposant qu'il s'agissait de la première erreur, pourriez-vous inclure le pod yaml et le nœud?

c'est à peu près tout ce qui a été vidé, je viens de supprimer les autres nœuds. Ce n'était pas la première erreur, mais vous pouvez voir le pod coredns dans la décharge, c'était la première. Je ne sais pas ce que vous demandez d'autre dans le dépotoir.
Je vais chercher les yamls

Merci, je ne savais pas que vous aviez coupé le nœud et le pod appropriés.

Pourriez-vous cependant inclure les pods planifiés pour ce nœud? Juste au cas où il y aurait un bogue dans les calculs d'utilisation des ressources.

Requested Resources: {MilliCPU:1100 Memory:52428800 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}

Ce AllowedPodNumber: 0 semble étrange.

Voici les autres pods sur ce nœud:
` name: kube-controller-manager-master-0-bug, namespace: kube-system, uid: 095eebb0-4752-419b-aac7-245e5bc436b8, phase: Running, nominated node: name: kube-proxy-xwf6h, namespace: kube-system, uid: 16552eaf-9eb8-4584-ba3c-7dff6ce92592, phase: Running, nominated node: name: kube-apiserver-master-0-bug, namespace: kube-system, uid: 1d338e26-b0bc-4cef-9bad-86b7dd2b2385, phase: Running, nominated node: name: kube-multus-ds-amd64-tpkm8, namespace: kube-system, uid: d50c0c7f-599c-41d5-a029-b43352a4f5b8, phase: Running, nominated node: name: openstack-cloud-controller-manager-wrb8n, namespace: kube-system, uid: 17aeb589-84a1-4416-a701-db6d8ef60591, phase: Running, nominated node: name: kube-scheduler-master-0-bug, namespace: kube-system, uid: 52469084-3122-4e99-92f6-453e512b640f, phase: Running, nominated node: name: subport-controller-28j9v, namespace: kube-system, uid: a5a07ac8-763a-4ff2-bdae-91c6e9e95698, phase: Running, nominated node: name: csi-cinder-controllerplugin-0, namespace: kube-system, uid: 8b16d6c8-a871-454e-98a3-0aa545f9c9d0, phase: Running, nominated node: name: calico-node-d899t, namespace: kube-system, uid: e3672030-53b1-4356-a5df-0f4afd6b9237, phase: Running, nominated node:

Tous les nœuds ont permitPodNumber mis à 0 dans les ressources demandées dans le vidage, mais les autres nœuds sont planifiables

Le nœud yaml:

apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
  creationTimestamp: "2020-07-16T09:59:48Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    beta.kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/region: regionOne
    failure-domain.beta.kubernetes.io/zone: nova
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: master-0-bug
    kubernetes.io/os: linux
    node-role.kubernetes.io/master: ""
    node.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    node.uuid: 00324054-405e-4fae-a3bf-d8509d511ded
    node.uuid_source: cloud-init
    topology.kubernetes.io/region: regionOne
    topology.kubernetes.io/zone: nova
  name: master-0-bug
  resourceVersion: "85697"
  selfLink: /api/v1/nodes/master-0-bug
  uid: 629b6ef3-3c76-455b-8b6b-196c4754fb0e
spec:
  podCIDR: 192.168.0.0/24
  podCIDRs:
  - 192.168.0.0/24
  providerID: openstack:///00324054-405e-4fae-a3bf-d8509d511ded
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
status:
  addresses:
  - address: 10.0.10.14
    type: InternalIP
  - address: master-0-bug
    type: Hostname
  allocatable:
    cpu: "2"
    ephemeral-storage: "19290208634"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 2962332Ki
    pods: "110"
  capacity:
    cpu: "2"
    ephemeral-storage: 20931216Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 3064732Ki
    pods: "110"
  conditions:
  - lastHeartbeatTime: "2020-07-16T10:02:20Z"
    lastTransitionTime: "2020-07-16T10:02:20Z"
    message: Calico is running on this node
    reason: CalicoIsUp
    status: "False"
    type: NetworkUnavailable
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient memory available
    reason: KubeletHasSufficientMemory
    status: "False"
    type: MemoryPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has no disk pressure
    reason: KubeletHasNoDiskPressure
    status: "False"
    type: DiskPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient PID available
    reason: KubeletHasSufficientPID
    status: "False"
    type: PIDPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T10:19:44Z"
    message: kubelet is posting ready status. AppArmor enabled
    reason: KubeletReady
    status: "True"
    type: Ready
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250
  nodeInfo:
    architecture: amd64
    bootID: fe410ed3-2825-4f94-a9f9-08dc5e6a955e
    containerRuntimeVersion: docker://19.3.11
    kernelVersion: 4.12.14-197.45-default
    kubeProxyVersion: v1.18.5
    kubeletVersion: v1.18.5
    machineID: 00324054405e4faea3bfd8509d511ded
    operatingSystem: linux
    systemUUID: 00324054-405e-4fae-a3bf-d8509d511ded

et le pod:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-07-16T10:13:35Z"
  generateName: pm-node-exporter-
  labels:
    controller-revision-hash: 6466d9c7b
    pod-template-generation: "1"
  name: pm-node-exporter-mn9vj
  namespace: monitoring
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: DaemonSet
    name: pm-node-exporter
    uid: 5855a26f-a57e-4b0e-93f2-461c19c477e1
  resourceVersion: "5239"
  selfLink: /api/v1/namespaces/monitoring/pods/pm-node-exporter-mn9vj
  uid: 0db09c9c-1618-4454-94fa-138e55e5ebd7
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - master-0-bug
  containers:
  - args:
    - --path.procfs=/host/proc
    - --path.sysfs=/host/sys
    image: ***
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: 9100
        scheme: HTTP
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1
      timeoutSeconds: 1
    name: pm-node-exporter
    ports:
    - containerPort: 9100
      hostPort: 9100
      name: metrics
      protocol: TCP
    resources:
      limits:
        cpu: 200m
        memory: 150Mi
      requests:
        cpu: 100m
        memory: 100Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /host/proc
      name: proc
      readOnly: true
    - mountPath: /host/sys
      name: sys
      readOnly: true
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: pm-node-exporter-token-csllf
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  hostPID: true
  nodeSelector:
    node-role.kubernetes.io/master: ""
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: pm-node-exporter
  serviceAccountName: pm-node-exporter
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/disk-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/pid-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/network-unavailable
    operator: Exists
  volumes:
  - hostPath:
      path: /proc
      type: ""
    name: proc
  - hostPath:
      path: /sys
      type: ""
    name: sys
  - name: pm-node-exporter-token-csllf
    secret:
      defaultMode: 420
      secretName: pm-node-exporter-token-csllf
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-07-16T10:13:35Z"
    message: '0/6 nodes are available: 2 node(s) didn''t have free ports for the requested
      pod ports, 3 node(s) didn''t match node selector.'
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
  qosClass: Burstable

Merci beaucoup pour toutes les informations. @nodo pouvez-vous le prendre?

Nous essayons également avec https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc maintenant, pour obtenir plus d'informations

/Aidez-moi

@maelk, n'hésitez pas à le prendre et à soumettre un PR si vous trouvez le bogue. Les lignes de journal que vous avez ajoutées seront probablement utiles. Sinon, je m'ouvre aux contributeurs.

@alculquicondor :
Cette demande a été marquée comme nécessitant l'aide d'un contributeur.

Veuillez vous assurer que la demande répond aux exigences énumérées ici .

Si cette demande ne répond plus à ces exigences, l'étiquette peut être supprimée
en commentant avec la commande /remove-help .

/attribuer

@maelk Y a-t-il quelque chose de spécifique au moment où ce problème se produit pour la première fois? Par exemple, cela se produit-il juste après le démarrage du nœud?

Non, il y a pas mal de pods qui y sont programmés et qui fonctionnent bien. Mais une fois que le problème se produit, aucun de ne peut plus être programmé.

Réduire la priorité jusqu'à ce que nous ayons un cas reproductible.

Nous avons pu reproduire le bogue avec un planificateur contenant les entrées de journal supplémentaires. Ce que nous voyons, c'est que l'un des maîtres disparaît complètement de la liste des nœuds qui sont itérés. Nous pouvons voir que le processus commence avec les 6 nœuds (à partir de l'instantané):

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}

mais après, nous pouvons voir qu'il n'itère que sur 5 nœuds, puis nous obtenons:

I0720 13:58:28.247420       1 generic_scheduler.go:505] pod kube-system/coredns-cd64c8d7c-tcxbq : processed 5 nodes, 0 fit

Ainsi, l'un des nœuds est supprimé de la liste des nœuds potentiels. Malheureusement, nous n'avions pas assez de journalisation au début du processus, mais nous essaierons d'en obtenir plus.

Références de code par ligne de journal:

1. https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R441
2. https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R505

@maelk
Avez-vous vu des lignes pour %v/%v on node %v, too many nodes fit ?

Sinon, @pancernik pourriez-vous rechercher des bogues sur workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) ?

Non, ce journal n'apparaît pas. Je pense également qu'il se pourrait que nous ayons un problème avec la parallélisation ou que ce nœud soit filtré plus tôt. S'il échouait avec une erreur ici: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464 essayerait il serait plus visible dans les journaux afaik spécifiquement fonction et la parallélisation.

Je viens de réaliser qu'un nœud subit le filtrage deux fois!

Les journaux sont:

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}
I0720 13:58:28.246793       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.246970       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.246819       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-0-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247019       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-2-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247144       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247172       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler : status is not success
I0720 13:58:28.247210       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247231       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler : status is not success
I0720 13:58:28.247206       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247297       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.247246       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247340       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler : status is not success
I0720 13:58:28.247147       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247375       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler : status is not success
I0720 13:58:28.247420       1 generic_scheduler.go:505] pod kube-system/coredns-cd64c8d7c-tcxbq : processed 5 nodes, 0 fit
I0720 13:58:28.247461       1 generic_scheduler.go:430] pod kube-system/coredns-cd64c8d7c-tcxbq After scheduling, filtered: []*v1.Node{}, filtered nodes: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)}
I0720 13:58:28.247527       1 generic_scheduler.go:185] Pod kube-system/coredns-cd64c8d7c-tcxbq failed scheduling:
  nodes snapshot: &cache.Snapshot{nodeInfoMap:map[string]*nodeinfo.NodeInfo{"master-0-scheduler":(*nodeinfo.NodeInfo)(0xc000607040), "master-1-scheduler":(*nodeinfo.NodeInfo)(0xc0001071e0), "master-2-scheduler":(*nodeinfo.NodeInfo)(0xc000326a90), "worker-pool1-60846k0y-scheduler":(*nodeinfo.NodeInfo)(0xc000952000), "worker-pool1-7dt1xd4k-scheduler":(*nodeinfo.NodeInfo)(0xc0007d08f0), "worker-pool1-hyk0hg7r-scheduler":(*nodeinfo.NodeInfo)(0xc0004f35f0)}, nodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}, havePodsWithAffinityNodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000607040)}, generation:857} 
  statuses: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)} 

Comme vous pouvez le voir, le nœud worker-pool1-60846k0y-scheduler passe deux fois par filtrage

Non, ce journal n'apparaît pas. Je pense également qu'il se pourrait que nous ayons un problème avec la parallélisation ou que ce nœud soit filtré plus tôt. S'il échouait avec une erreur ici: Nordix @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464, il serait visible dans les journaux afaik, je vais donc essayer d'ajouter plus d'entrées de débogage autour spécifiquement de la fonction et de la parallélisation.

Ouais, une erreur se manifesterait par une erreur de planification dans les événements du pod.

Je viens de réaliser qu'un nœud subit le filtrage deux fois!

Honnêtement, je ne pense pas que la parallélisation comporte des bogues (qui valent toujours la peine d'être vérifiés), mais cela pourrait être le signe que nous n'avons pas réussi à créer l'instantané à partir du cache (comme nous l'avons vu dans le vidage du cache, le cache est correct), en ajoutant un nœud deux fois. Puisque les statuts sont une carte, il est logique que nous ne "voyions" que 5 nœuds à la dernière ligne du journal.

C'est le code (astuce de 1.18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

J'essaierai d'ajouter beaucoup de journaux sur la partie cache du planificateur, en particulier autour de l'ajout et de la mise à jour de nœuds, et autour de l'instantané. Cependant, à partir de la dernière ligne des journaux, vous pouvez voir que l'instantané est en fait correct et contient tous les nœuds, donc tout ce qui se passe semble se produire plus tard, lorsque vous travaillez sur cet instantané

cache! = instantané

Le cache est la chose vivante qui est mise à jour à partir des événements. L'instantané est mis à jour (à partir du cache) avant chaque cycle de planification pour "verrouiller" l'état. Nous avons ajouté des optimisations pour rendre ce dernier processus aussi rapide que possible. Il est possible que le bogue soit là.

Merci @maelk! Ceci est très utile. Vos journaux indiquent que (*nodeinfo.NodeInfo)(0xc000952000) est déjà dupliqué dans la liste à l' adresse https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R avant l'exécution de tout code parallèle441. Cela signifierait en effet qu'il est dupliqué avant la mise à jour de l'instantané.

En fait, cela vient de l'instantané, qui se produit avant ce message de journal: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R161. Il semble donc que le contenu de l'instantané ait la duplication, car il provient de https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R436

C'est vrai. Je voulais dire qu'il était déjà dupliqué avant la fin de la mise à jour de l'instantané.

C'est vrai. Je voulais dire qu'il était déjà dupliqué avant la fin de la mise à jour de l'instantané.

Non, l'instantané est mis à jour au début du cycle de planification. Le bogue est soit pendant la mise à jour de l'instantané, soit avant cela. Mais le cache est correct, selon le dump dans https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008

EDIT: je l'ai mal lu, je n'ai pas vu le mot "finit" :)

L'instantané de mise à jour d'optimisation des relations publiques a été effectué dans la version 1.18: https://github.com/kubernetes/kubernetes/pull/85738 et https://github.com/kubernetes/kubernetes/pull/86919

Je me demande si l'arborescence des nœuds a également des enregistrements en double

Je me demande si l'arborescence des nœuds a également des enregistrements en double

@maelk pourriez-vous afficher un vidage de la liste complète des nœuds dans le cache?

nous n'ajoutons / supprimons pas d'éléments de NodeInfoList, nous créons la liste complète à partir de l'arbre ou non, donc s'il y a des doublons, ceux-ci proviennent probablement de l'arbre, je pense.

Juste pour clarifier:
1) le cluster a 6 nœuds (y compris les maîtres)
2) le nœud qui est censé héberger le pod n'a pas du tout été examiné (aucune ligne de journal ne l'indique), ce qui peut signifier qu'il n'est pas du tout dans NodeInfoList
3) NodeInfoList a 6 nœuds, mais l'un d'eux est en double

Je me demande si l'arborescence des nœuds a également des enregistrements en double

@maelk pourriez-vous afficher un vidage de la liste complète des nœuds dans le cache?

un vidage de chaque arbre de nœuds, liste et carte serait génial.

Je vais travailler pour les obtenir. En attendant, une petite mise à jour. Nous pouvons voir dans les journaux:

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

Et c'est le moment exact où le nœud manquant disparaît. La dernière occurrence dans les journaux est à 13:37:24. Dans la planification suivante, le nœud manquant a disparu. il semble donc que le bogue se trouve dans / suit la mise à jour de node_tree. Tous les nœuds passent par cette mise à jour, c'est juste que ce worker 608 est le dernier à y passer.

Lors du vidage du cache (avec SIGUSR2), les six nœuds y sont répertoriés, les pods s'exécutant sur les nœuds, sans duplication ni nœuds manquants.

Nous allons lui donner un nouvel essai avec un débogage supplémentaire autour de la fonctionnalité d'instantané: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Suppression du nœud "worker-pool1-60846k0y-scheduler" dans le groupe "" de NodeTree

Intéressant, je pense que les suppressions / ajouts sont déclenchés par un appel updateNode. La clé de zone est manquante sur la suppression, mais existe sur l'ajout, donc la mise à jour ajoutait essentiellement les étiquettes de zone et de région?

Avez-vous d'autres journaux de planificateur liés à ce nœud?

Nous essayons de reproduire le bogue avec la journalisation ajoutée. Je reviendrai quand j'aurai plus d'infos

Je vais travailler pour les obtenir. En attendant, une petite mise à jour. Nous pouvons voir dans les journaux:

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

Je ferai remarquer qu'un tel nœud est le nœud qui se répète. @maelk , avez-vous vu des messages similaires pour d'autres nœuds ou pas du tout? Comme @ ahg-g, cela devrait être prévu lorsqu'un nœud reçoit ses étiquettes de topologie pour la première fois.

oui, c'est arrivé pour tous les nœuds, et c'est attendu. la coïncidence étant que ce nœud est spécifiquement le dernier mis à jour, et c'est à ce moment précis que l'autre nœud disparaît

Avez-vous obtenu des journaux de mise à jour pour le nœud manquant?

Avez-vous obtenu des journaux de mise à jour pour le nœud manquant?

lol, tapait juste cette question.

peut-être que le bogue est que toute la zone est supprimée de l'arborescence avant que tous les nœuds ne soient supprimés.

Juste pour clarifier, je ne regarde pas personnellement le code, j'essaie simplement de m'assurer que nous avons toutes les informations. Et je pense qu'avec ce que nous avons maintenant, nous devrions être capables de repérer le bogue. N'hésitez pas à soumettre des PR et bien mieux si vous pouvez fournir un test unitaire qui échoue.

Avez-vous obtenu des journaux de mise à jour pour le nœud manquant?

oui, cela montre que la zone est mise à jour pour ce nœud manquant. Il existe une entrée de journal pour tous les nœuds

Pour être honnête, je n'ai toujours aucune idée de la raison du bogue, mais si nous pouvons arriver à le découvrir, je soumettrai un PR ou des tests unitaires.

oui, cela montre que la zone est mise à jour pour ce nœud manquant. Il existe une entrée de journal pour tous les nœuds

Si c'est le cas, alors je pense en supposant que c'est "le moment exact où le nœud manquant disparaît". peut ne pas être corrélé. Attendons les nouveaux journaux. Ce serait formidable si vous pouviez partager tous les journaux du planificateur que vous obtenez dans un fichier.

Je le ferai quand nous reproduirons avec la nouvelle journalisation. À partir de celles existantes, nous pouvons en fait voir que la planification du pod immédiatement après cette mise à jour est la première à échouer. Mais cela ne donne pas assez d'informations pour savoir ce qui s'est passé entre les deux, alors restez à l'écoute ...

@maelk Avez-vous vu un message commençant par snapshot state is not consistent dans les journaux du planificateur?

Serait-il possible pour vous de fournir des journaux complets du planificateur?

non, ce message n'est pas présent. Je pourrais donner un fichier journal rayé (pour éviter la répétition), mais attendons d'abord d'avoir la sortie avec plus de journaux autour de l'instantané

J'ai trouvé le bogue. Le problème vient de la fonction nodeTree next (), qui ne renvoie pas une liste de tous les nœuds dans certains cas. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

Il est visible si vous ajoutez ce qui suit ici: https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree_test.go#L443

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[5:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

Le principal problème est que lorsque vous ajoutez un nœud, les index ne sont pas à 0 pour certaines zones. Pour que cela se produise, vous devez avoir au moins deux zones, l'une étant plus courte que l'autre, et la plus longue ayant un index non défini sur 0 lors de l'appel de la fonction suivante pour la première fois.

Le correctif que j'ai choisi est de réinitialiser l'index avant d'appeler next () la première fois. J'ai ouvert un PR pour montrer mon correctif. Bien sûr, c'est contre la version 1.18 car c'est ce sur quoi j'ai travaillé, mais c'est surtout pour discuter de la façon de le réparer (ou peut-être de corriger la fonction next () elle-même). Je peux ouvrir un PR approprié vers le maître et faire les backports si nécessaire par la suite.

J'ai remarqué le même problème avec l'itération. Mais je n'ai pas réussi à lier cela à un doublon dans l'instantané. Avez-vous réussi à créer un scénario où cela se produirait, @maelk?

oui, vous pouvez l'exécuter dans les tests unitaires en ajoutant le petit code que j'ai mis

Je travaille maintenant sur l'ajout d'un cas de test pour l'instantané, pour m'assurer qu'il est correctement testé.

grand merci à

Merci à tous pour le débogage de ce problème notoire. La réinitialisation de l'index avant de créer la liste est sûre, donc je pense que nous devrions aller avec cela pour les correctifs 1.18 et 1.19, et avoir un correctif approprié dans la branche master.

Le but de la fonction next changé avec l'introduction de NodeInfoList, et nous pouvons donc certainement le simplifier et peut-être le changer en toList , une fonction qui crée une liste à partir de l'arborescence et commence simplement depuis le début à chaque fois.

Je comprends maintenant le problème: le calcul de l'épuisement ou non d'une zone est erroné car il ne considère pas où dans chaque zone nous avons commencé ce processus "UpdateSnapshot". Et oui, ce ne serait visible qu'avec des zones inégales.

Excellent travail de repérer ce @maelk!

Je pense que nous avons le même problème dans les anciennes versions. Cependant, il est caché par le fait que nous faisons un passage d'arbre à chaque fois. Alors qu'en 1.18, nous avons instantané le résultat jusqu'à ce qu'il y ait des changements dans l'arbre.

Maintenant que la stratégie round-robin est implémentée dans generic_scheduler.go, nous pourrions être d'accord avec la simple réinitialisation de tous les compteurs avant UpdateSnapshot, comme le fait votre PR.

https://github.com/kubernetes/kubernetes/blob/02cf58102a61b6d1e021e256381ff750573ce55d/pkg/scheduler/core/generic_scheduler.go#L357

Juste pour vérifier @ ahg-g, cela devrait être bien même dans un cluster où de nouveaux nœuds sont ajoutés / supprimés tout le temps, non?

Merci @maelk d' avoir repéré la cause profonde!

Le but de la fonction suivante a changé avec l'introduction de NodeInfoList, et nous pouvons donc certainement le simplifier et peut-être le changer en toList, une fonction qui crée une liste à partir de l'arborescence et recommence simplement depuis le début à chaque fois.

Étant donné que cache.nodeTree.next() n'est appelé que lors de la construction de l'instantané nodeInfoList, je pense qu'il est également sûr de supprimer les index (à la fois zoneIndex et nodeIndex) de la structure nodeTree. Au lieu de cela, créez une simple fonction nodeIterator() pour parcourir sa zone / nœud de manière circulaire.

BTW: il y a une faute de frappe dans https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090, le cas devrait être:

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[6:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
    // with codecase on master and 1.18, its output is [node-6 node-7 node-3 node-8 node-6 node-3]
},

Juste pour vérifier @ ahg-g, cela devrait être bien même dans un cluster où de nouveaux nœuds sont ajoutés / supprimés tout le temps, non?

Je suppose que vous parlez de la logique dans generic_scheduler.go, si oui, peu importe si des nœuds ont été ajoutés ou supprimés, la principale chose que nous devons éviter est d'itérer les nœuds dans le même ordre à chaque fois nous planifions un pod, nous avons juste besoin d'une bonne approximation de l'itération sur les nœuds à travers les pods.

Étant donné que cache.nodeTree.next () n'est appelé que lors de la construction de l'instantané nodeInfoList, je pense qu'il est également sûr de supprimer les index (à la fois zoneIndex et nodeIndex) de la structure nodeTree. Au lieu de cela, créez une simple fonction nodeIterator () pour parcourir sa zone / nœud de manière circulaire.

oui, nous avons juste besoin d'itérer sur toutes les zones / nœuds dans le même ordre à chaque fois.

J'ai mis à jour le PR avec un test unitaire pour la fonction de mise à jour de la liste de clichés, pour ce bogue en particulier. Je peux également prendre soin de refactoriser la fonction next () pour itérer sur les zones et les nœuds sans round-robin, supprimant ainsi le problème.

Merci, ça sonne bien, mais nous devrions toujours itérer entre les zones de la même manière que nous le faisons maintenant, c'est-à-dire par conception.

Je ne comprends pas vraiment ce que tu veux dire ici. Est-ce pour que l'ordre des nœuds compte et qu'il faut encore faire un tour de rôle entre les zones ou peut-on lister tous les nœuds d'une zone, une zone après l'autre? Disons que vous avez deux zones de deux nœuds chacune, dans quel ordre les attendez-vous, ou est-ce même important?

L'ordre compte, nous devons alterner entre les zones lors de la création de la liste. Si vous avez deux zones de deux nœuds chacun z1: {n11, n12} et z2: {n21, n22} , alors la liste devrait être {n11, n21, n12, n22}

ok, merci, je vais y réfléchir. Pouvons-nous entre-temps procéder à la solution miracle? btw, certains tests échouent, mais je ne sais pas comment cela se rapporte à mon PR

Ce sont des flocons. Veuillez également envoyer un correctif à la version 1.18.

OK je le ferai. Merci

{
  name:           "add nodes to a new and to an exhausted zone",
  nodesToAdd:     append(allNodes[5:9], allNodes[3]),
  nodesToRemove:  nil,
  operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
  expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

@maelk , voulez-vous dire que ce test ignore le 'node-5'?

J'ai trouvé après avoir corrigé l'ajout dans https://github.com/kubernetes/kubernetes/pull/93516 , le résultat du test, tous les nœuds peuvent être itérés:

{
            name:           "add nodes to a new and to an exhausted zone",
            nodesToAdd:     append(append(make([]*v1.Node, 0), allNodes[5:9]...), allNodes[3]),
            nodesToRemove:  nil,
            operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
            expectedOutput: []string{"node-5", "node-6", "node-3", "node-7", "node-8", "node-5"},
},

Les nœuds 5, 6, 7, 8, 3 peuvent être itérés.

Pardonnez-moi si vous ne comprenez pas quelque chose ici.

oui, c'était exprès, basé sur ce qui était là, mais je peux voir comment cela peut être cryptique, alors mieux vaut faire en sorte que l'append se comporte de manière plus claire. Merci pour le patch.

À quelle distance pensez-vous que ce bug était présent? 1.17? 1.16? Je viens de voir exactement le même problème dans la version 1.17 sur AWS et le redémarrage du nœud non planifié a résolu le problème.

@judgeaxl pourriez-vous fournir plus de détails? Lignes de journal, vidages de cache, etc. Nous pouvons donc déterminer si le problème est le même.

Comme je l'ai noté dans https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695, je pense que ce bogue était présent dans les anciennes versions, mais je pense que c'est transitoire.

@maelk seriez-vous en mesure d'enquêter?

Veuillez également partager la répartition des nœuds dans les zones.

@alculquicondor, malheureusement, je ne peux pas à ce stade. Désolé.

@alculquicondor désolé, j'ai déjà reconstruit le cluster pour d'autres raisons, mais cela peut avoir été un problème de configuration réseau lié aux déploiements multi-az, et dans quel sous-réseau le nœud défectueux a été lancé, donc je ne m'inquiéterais pas pour le moment dans le contexte de cette question. Si je le remarque à nouveau, je ferai un rapport avec de meilleurs détails. Merci!

/ retitle Certains nœuds ne sont pas pris en compte dans la planification en cas de déséquilibre de zone