Kubernetes: Einige Knoten werden bei der Planung nicht berücksichtigt, wenn ein Zonenungleichgewicht vorliegt

/ sig Scheduling

Können Sie das vollständige Yaml des Knotens, des Daemonsets, eines Beispiel-Pods und des vom Server abgerufenen enthaltenen Namespace bereitstellen?

Knoten:
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

Daemonset:
https://gist.github.com/zetaab/31bb406c8bd622b3017bf4f468d0154f

Beispiel Pod (funktioniert):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

Beispiel-Pod (keine Planung):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

Namespace:
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

DaemonSet-Pods planen mit einem NodeAffinity-Selektor, der nur einem einzelnen Knoten entspricht. Daher wird die Meldung "12 von 13 stimmten nicht überein" erwartet.

Ich sehe keinen Grund, warum der Scheduler mit der Pod / Node-Kombination unzufrieden wäre. Es gibt keine Ports, die in der Podspec in Konflikt geraten könnten. Der Node ist nicht außerplanmäßig oder fehlerhaft und verfügt über ausreichende Ressourcen

Okay, ich habe alle 3 Scheduler neu gestartet (Googlevel auf 4 geändert, wenn wir dort etwas Interessantes sehen können). Das Problem wurde jedoch behoben

% 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

Jetzt werden alle Daemonsets korrekt bereitgestellt. Seltsam, sowieso scheint etwas mit dem Scheduler nicht zu stimmen

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

Wir sehen dasselbe ähnliche Problem in Version 1.18.3. Ein Knoten kann nicht für Daemonset-Pods geplant werden.
Neustart Scheduler hilft.

[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

Schwer zu debuggen, ohne zu wissen, wie man es wieder herstellt. Haben Sie die Scheduler-Protokolle zufällig für den fehlgeschlagenen Pod?

Okay, ich habe alle 3 Scheduler neu gestartet

Ich nehme an, nur einer von ihnen heißt default-scheduler , richtig?

loglevel wurde auf 4 geändert, wenn wir dort etwas Interessantes sehen können

Können Sie uns mitteilen, was Ihnen aufgefallen ist?

setze loglevel auf 9, aber es scheint nichts interessanteres zu geben, unten protokollieren sich die Protokolle.

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)

Ja, ich konnte nicht mehr als dieselbe Zeile sehen

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

Das Seltsame ist, dass die Protokollnachricht das Ergebnis nur für 7 Knoten anzeigt, wie das unter https://github.com/kubernetes/kubernetes/issues/91340 gemeldete Problem

/ cc @damemi

@ ahg-g das sieht aus wie das gleiche Problem, das ich dort gemeldet habe, es scheint, als hätten wir entweder ein Filter-Plugin, das seinen Fehler nicht immer meldet, oder eine andere Bedingung, die stillschweigend fehlschlägt, wenn ich raten müsste

Beachten Sie, dass in meinem Problem durch einen Neustart des Schedulers auch das Problem behoben wurde (wie auch in diesem Thread erwähnt https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092).

Bei mir ging es auch um ein Daemonset, daher denke ich, dass dies ein Duplikat ist. In diesem Fall können wir dies schließen und die Diskussion unter https://github.com/kubernetes/kubernetes/issues/91340 fortsetzen

Auf jeden Fall benötigt der Scheduler eine ausführlichere Protokollierungsoption. Es ist unmöglich, diese Probleme zu debuggen, wenn keine Protokolle darüber vorhanden sind, was er tut

@zetaab +1, der Scheduler könnte seine aktuellen Protokollierungsfähigkeiten erheblich verbessern. Das ist ein Upgrade, das ich schon seit einiger Zeit angehen wollte, und ich habe hier endlich ein Problem dafür geöffnet: https://github.com/kubernetes/kubernetes/issues/91633

/zuordnen

Ich untersuche das. Ein paar Fragen, die mir helfen sollen, den Fall einzugrenzen. Ich konnte mich noch nicht reproduzieren.

• Was wurde zuerst erstellt: das Daemonset oder der Knoten?
• Verwenden Sie das Standardprofil?

• Hast du Extender?

Knoten wurden vor dem Daemonset erstellt.
Angenommen, wir haben das Standardprofil verwendet. Welches Profil meinen Sie und wie wird es überprüft?
keine Extender.

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

Eine andere Sache, die sich auswirken kann, ist, dass die Festplattenleistung für etcd nicht sehr gut ist, etcd beschwert sich über langsame Operationen.

Ja, diese Flags würden den Scheduler mit dem Standardprofil ausführen lassen. Ich werde weiter suchen. Ich konnte mich immer noch nicht reproduzieren.

Immer noch nichts ... Sonst noch etwas, von dem Sie glauben, dass es Auswirkungen haben könnte? Flecken, Häfen, andere Ressourcen?

Habe einige Versuche im Zusammenhang damit gemacht. Wenn das Problem besteht, können Pods weiterhin für den Knoten geplant werden (ohne Definition oder mit der Auswahl "Knotenname").

Wenn Sie versuchen, Affinity / Antiaffinity zu verwenden, werden Pods nicht für den Knoten geplant.

Arbeiten, wenn das Problem aktiv ist:

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

Nicht gleichzeitig arbeiten:

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

Auch bei der Überprüfung waren letztere sogar sehr interessant:

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.

• Das erste Ereignis ist, wenn das Manifest gerade angewendet wurde (nichts wurde mit dem nicht planbaren Knoten gemacht).
• An zweiter und dritter Stelle wurde der Knoten mit kubectl entfernt und dann neu gestartet.
• Der vierte kam, als der Knoten wieder hochkam. Der Knoten, bei dem ein Problem aufgetreten ist, war der Master, sodass der Knoten nicht dorthin ging (dies zeigt jedoch, dass der Knoten bei drei früheren Ereignissen nicht gefunden wurde). Interessant beim vierten Ereignis ist, dass noch Informationen von einem Knoten fehlen. Ereignis sagt, dass 0/9 Knoten verfügbar sind, aber Beschreibung wird nur von 8 gegeben.

"nodeName" ist kein Selektor. Die Verwendung von nodeName würde die Zeitplanung umgehen.

Der vierte kam, als der Knoten wieder hochkam. Der Knoten, bei dem ein Problem aufgetreten ist, war der Master, sodass der Knoten nicht dorthin ging (dies zeigt jedoch, dass der Knoten bei drei früheren Ereignissen nicht gefunden wurde). Interessant beim vierten Ereignis ist, dass noch Informationen von einem Knoten fehlen. Ereignis sagt, dass 0/9 Knoten verfügbar sind, aber Beschreibung wird nur von 8 gegeben.

Sie sagen, dass der Grund, warum der Pod nicht im fehlenden Knoten geplant werden sollte, darin besteht, dass er ein Master war?

Wir sehen, dass 8 node(s) didn't match node selector auf 7 geht. Ich gehe davon aus, dass zu diesem Zeitpunkt keine Knoten entfernt wurden, richtig?

"nodeName" ist kein Selektor. Die Verwendung von nodeName würde die Zeitplanung umgehen.

"NodeName" -Versuch war zu markieren, dieser Knoten ist verwendbar und der Pod kommt dorthin, wenn er gewünscht wird. Es ist also nicht die Unfähigkeit des Knotens, Pods zu starten.

Der vierte kam, als der Knoten wieder hochkam. Der Knoten, bei dem ein Problem aufgetreten ist, war der Master, sodass der Knoten nicht dorthin ging (dies zeigt jedoch, dass der Knoten bei drei früheren Ereignissen nicht gefunden wurde). Interessant beim vierten Ereignis ist, dass noch Informationen von einem Knoten fehlen. Ereignis sagt, dass 0/9 Knoten verfügbar sind, aber Beschreibung wird nur von 8 gegeben.

Sie sagen, dass der Grund, warum der Pod nicht im fehlenden Knoten geplant werden sollte, darin besteht, dass er ein Master war?

Wir sehen, dass 8 node(s) didn't match node selector auf 7 geht. Ich gehe davon aus, dass zu diesem Zeitpunkt keine Knoten entfernt wurden, richtig?

Testcluster hat 9 Knoten; 3 Meister und 6 Arbeiter. Bevor der nicht funktionierende Knoten erfolgreich gestartet wurde, gaben Ereignisse Informationen zu allen verfügbaren Knoten an: 0/8 nodes are available: 8 node(s) didn't match node selector. . Als jedoch der Knoten auftauchte, der mit der Knotenauswahl übereinstimmen würde, teilte das Ereignis 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. Erläuterung besagt, dass 8 nicht übereinstimmen, aber nichts über den neunten (der beim vorherigen Ereignis bestätigt wurde).

Also der Ereignisstatus:

• 1. Ereignis: 9 Knoten verfügbar, der Fehler bei Daemonset festgestellt
• 2. und 3. Ereignis: 8 Knoten verfügbar. Derjenige, der keinen Pod erhielt, wurde neu gestartet
• 4. Ereignis: 9 Knoten verfügbar (also der gestartete, der neu gestartet wurde).

Am Ende wurde der Test-Pod wegen Verschmutzungen nicht am passenden Knoten gestartet, aber das ist eine andere Geschichte (und sollte bereits beim 1. Event der Fall sein).

"NodeName" -Versuch war zu markieren, dieser Knoten ist verwendbar und der Pod kommt dorthin, wenn er gewünscht wird. Es ist also nicht die Unfähigkeit des Knotens, Pods zu starten.

Beachten Sie, dass nichts vor einem übermäßigen Festschreiben eines Knotens schützt, sondern der Scheduler. Das zeigt also nicht wirklich viel.

Am Ende wurde der Test-Pod wegen Verschmutzungen nicht am passenden Knoten gestartet, aber das ist eine andere Geschichte (und sollte bereits beim 1. Event der Fall sein).

Meine Frage ist: War der 9. Knoten von Anfang an befleckt? Ich versuche nach (1) reproduzierbaren Schritten zu suchen, um den Zustand zu erreichen, oder (2) wo der Fehler sein könnte.

Meine Frage ist: War der 9. Knoten von Anfang an befleckt? Ich versuche nach (1) reproduzierbaren Schritten zu suchen, um den Zustand zu erreichen, oder (2) wo der Fehler sein könnte.

Ja, in diesem Fall war die ganze Zeit ein Makel vorhanden, da der nicht empfangende Knoten Master war. Aber wir haben das gleiche Problem sowohl bei den Meistern als auch bei den Arbeitern gesehen.

Immer noch keine Ahnung, woher das Problem kommt, nur dass zumindest die Neuerstellung des Knotens und der Neustart des Knotens das Problem zu beheben scheinen. Aber das sind ein bisschen "harte" Wege, um die Dinge zu reparieren.

Long Shot, aber wenn Sie erneut darauf stoßen ... könnten Sie überprüfen, ob der Knoten nominierte Pods enthält, die nicht angezeigt werden?

Ich stelle Fragen, wenn ich über mögliche Szenarien nachdenke:

• Haben Sie andere Masterknoten in Ihrem Cluster?
• Hast du Extender?

* Do you have other master nodes in your cluster?

Alle Cluser haben 3 Master (so ist ein Neustart dieser einfach)

* Do you have extenders?

Nein.

Eine interessante Sache ist heute aufgefallen: Ich hatte einen Cluster, in dem ein Master keinen Pod von DaemonSet erhielt. Wir haben ChaosMonkey im Einsatz, der einen der Worker-Knoten beendet hat. Das ist interessant, das hat den Pod dazu gebracht, zu dem Meister zu gehen, der ihn nicht früher erhalten hat. Irgendwie schien das Entfernen eines anderen als des problematischen Knotens das Problem an diesem Punkt zu beheben.

Aufgrund dieses "Fixes" muss ich warten, bis das Problem erneut auftritt, um über die nominierten Pods antworten zu können.

Ich bin jetzt verwirrt ... Verträgt Ihr Daemonset den Makel für Masterknoten? Mit anderen Worten ... ist der Fehler für Sie nur das Planungsereignis oder auch die Tatsache, dass die Pods geplant werden sollten?

Das Problem ist, dass der Knoten vom Scheduler nicht gefunden wird, obwohl mindestens eine übereinstimmende Affinitäts- (oder Antiaffinitäts-) Einstellung vorhanden ist.

Deshalb habe ich gesagt, dass der Taint-Fehler erwartet wird und bereits beim ersten Ereignis vorhanden sein sollte (da Taint nicht Teil der Affinitätskriterien ist)

Verstanden. Ich habe versucht, Ihr Setup zu bestätigen, um sicherzustellen, dass mir nichts fehlt.

Ich glaube nicht, dass der Knoten vom Scheduler "unsichtbar" ist. Wenn wir 0/9 nodes are available , können wir daraus schließen, dass sich der Knoten tatsächlich im Cache befindet. Es ist eher so, als ob der außerplanmäßige Grund irgendwo verloren geht, also nehmen wir ihn nicht in die Veranstaltung auf.

Richtig, die Gesamtzahl stimmt immer mit der tatsächlichen Knotenzahl überein. Nur beschreibenderer Ereignistext wird nicht auf allen Knoten angegeben, aber das kann, wie Sie erwähnt haben, ein separates Problem sein.

Können Sie Ihre Kube-Scheduler-Protokolle anzeigen? Was scheint relevant zu sein?

Ich denke, @zetaab hat erfolglos versucht, danach zu suchen. Ich kann versuchen, wenn das Problem erneut auftritt (sowie das zuvor gestellte nominierte Pod-Ding).

Führen Sie nach Möglichkeit auch 1.18.5 aus, falls wir das Problem versehentlich behoben haben.

Ich kann dies zuverlässig in meinem Testcluster reproduzieren, wenn Sie weitere Protokolle benötigen

@dilyevsky Bitte teilen Sie Repro Schritte. Können Sie irgendwie erkennen, welcher Filter ausfällt?

Es scheint nur der metadata.name des Knotens für den ds pod zu sein ... seltsam. Hier ist die Schote 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

Ich reproduziere dies, indem ich einen neuen Cluster mit 3 Mastern und 3 Worker-Knoten (unter Verwendung der Cluster-API) hochfahre und Cilium 1.7.6 anwende:

---
# 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

Hier ist das Scheduler-Protokoll:
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

Nach dem Neustart der Scheduler-Pods wird der ausstehende Pod sofort geplant.

Welche Pod-Events bekommst du? Wissen Sie, ob der Knoten Flecken aufweist?
wo wird es nicht geplant? Schlägt es nur für Masterknoten oder andere fehl?
Knoten? Ist im Knoten genügend Platz?

Am Do., 9. Juli 2020, 19:49 Uhr dilyevsky, [email protected]
schrieb:

Es scheint nur der metadata.name des Knotens für den ds pod zu sein ...
seltsam. Hier ist die Schote Yaml:

apiVersion: v1kind: Podmetadata:
Anmerkungen:
scheduler.alpha.kubernetes.io/critical-pod: ""
CreationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: cilium-
Etiketten:
Controller-Revision-Hash: 6c94db8bb8
k8s-app: cilium
Pod-Template-Generierung: "1"
verwaltete Felder:
# verwaltete Felder Mist
Name: Cilium-d5n4f
Namespace: Kubesystem
EigentümerReferenzen:

• apiVersion: apps / v1
  blockOwnerDeletion: true
  Controller: wahr
  Art: 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-f0964cde2f22spec:
  Affinität:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - Schlüssel: metadata.name
  Betreiber: In
  Werte:
  - us-central1-dilyevsky-master-qmwnl
  Behälter:
• Argumente:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    Befehl:
  
  
  • Cilium-Mittel
    
    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:
    
    Schlüssel: Flanell-Master-Gerät
    
    Name: Cilium-Konfiguration
    
    optional: wahr
  
  
  • Name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    Schlüssel: Flanell-Deinstallation-beim-Beenden
    
    Name: Cilium-Konfiguration
    
    optional: wahr
  
  
  • Name: CILIUM_CLUSTERMESH_CONFIG
    
    Wert: / var / lib / cilium / clustermesh /
  
  
  • Name: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    Taste: Cni-Chaining-Modus
    
    Name: Cilium-Konfiguration
    
    optional: wahr
  
  
  • Name: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    Schlüssel: custom-cni-conf
    
    Name: Cilium-Konfiguration
    
    optional: wahr
    
    Bild: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    Lebenszyklus:
    
    postStart:
    
    exec:
    
    Befehl:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = false
      
      
      preStop:
      
      
      exec:
      
      
      Befehl:
    
    
    
    • /cni-uninstall.sh
      
      
      LivenessProbe:
      
      
      exec:
      
      
      Befehl:
      
      
      
      
      
      
      
      • Wimper
      
      
      
      
      • Status
      
      
      
      
      • --kurz
        
        
        
        Fehlerschwelle: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        ZeitraumSekunden: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        Name: Cilium-Agent
        
        
        
        ReadinessProbe:
        
        
        
        exec:
        
        
        
        Befehl:
      
      
      
      
      • Wimper
      
      
      
      
      • Status
      
      
      
      
      • --kurz
        
        
        
        Fehlerschwelle: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        ZeitraumSekunden: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        Ressourcen: {}
        
        
        
        securityContext:
        
        
        
        Fähigkeiten:
        
        
        
        hinzufügen:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        privilegiert: wahr
        
        
        
        terminationMessagePath: / dev / terminierungsprotokoll
        
        
        
        terminationMessagePolicy: Datei
        
        
        
        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-Geheimnisse
    
    readOnly: wahr
  
  
  • mountPath: / tmp / cilium / config-map
    
    Name: Cilium-Konfigurationspfad
    
    readOnly: wahr
  
  
  • mountPath: / lib / modules
    
    Name: lib-Module
    
    readOnly: wahr
  
  
  • mountPath: /run/xtables.lock
    
    name: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    Name: Cilium-Token-j74lr
    
    readOnly: wahr
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: true
    
    hostNetwork: wahr
    
    initContainer:
  
  
• Befehl:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • Name: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    Schlüssel: Clean-Cilium-Zustand
    
    Name: Cilium-Konfiguration
    
    optional: wahr
  
  
  • Name: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    Schlüssel: Clean-Cilium-Bpf-Zustand
    
    Name: Cilium-Konfiguration
    
    optional: wahr
  
  
  • Name: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    Schlüssel: wait-bpf-mount
    
    Name: Cilium-Konfiguration
    
    optional: wahr
    
    Bild: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    Name: Clean-Cilium-Zustand
    
    Ressourcen: {}
    
    securityContext:
    
    Fähigkeiten:
    
    hinzufügen:
    
    
    
    
    
    • NET_ADMIN
      
      
      privilegiert: wahr
      
      
      terminationMessagePath: / dev / terminierungsprotokoll
      
      
      terminationMessagePolicy: Datei
      
      
      volumeMounts:
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    Name: Cilium-Run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    Name: Cilium-Token-j74lr
    
    readOnly: wahr
    
    Priorität: 2000001000
    
    priorityClassName: systemknotenkritisch
    
    restartPolicy: Immer
    
    SchedulerName: Standard-Scheduler
    
    securityContext: {}
    
    serviceAccount: Cilium
    
    serviceAccountName: cilium
    
    terminierungGracePeriodSeconds: 1
    
    Toleranzen:
  
  
• Operator: Existiert
• Effekt: NoExecute
  Schlüssel: node.kubernetes.io/not-ready
  Operator: Existiert
• Effekt: NoExecute
  Schlüssel: node.kubernetes.io/unreachable
  Operator: Existiert
• Effekt: NoSchedule
  Schlüssel: node.kubernetes.io/disk-pressure
  Operator: Existiert
• Effekt: NoSchedule
  Schlüssel: node.kubernetes.io/memory-pressure
  Operator: Existiert
• Effekt: NoSchedule
  Schlüssel: node.kubernetes.io/pid-pressure
  Operator: Existiert
• Effekt: NoSchedule
  Schlüssel: node.kubernetes.io/unschedulable
  Operator: Existiert
• Effekt: NoSchedule
  Schlüssel: node.kubernetes.io/network-unavailable
  Operator: Existiert
  Bände:
• hostPath:
  Pfad: / var / run / cilium
  Typ: DirectoryOrCreate
  Name: Cilium-Run
• hostPath:
  Pfad: / opt / cni / bin
  Typ: DirectoryOrCreate
  name: cni-path
• hostPath:
  Pfad: /etc/cni/net.d
  Typ: DirectoryOrCreate
  Name: etc-cni-netd
• hostPath:
  Pfad: / lib / modules
  Art: ""
  Name: lib-Module
• hostPath:
  Pfad: /run/xtables.lock
  Typ: FileOrCreate
  name: xtables-lock
• Name: Clustermesh-Geheimnisse
  Geheimnis:
  defaultMode: 420
  optional: wahr
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  Name: Cilium-Konfiguration
  Name: Cilium-Konfigurationspfad
• Name: Cilium-Token-j74lr
  Geheimnis:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  Bedingungen:
• lastProbeTime: null
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  Meldung: '0/6 Knoten sind verfügbar: 5 Knoten stimmten nicht mit der Knotenauswahl überein.'
  Grund: Unplanbar
  Status: "Falsch"
  Typ: PodScheduled
  Phase: Ausstehend
  qosClass: BestEffort

Die Art und Weise, wie ich dies reproduziere, besteht darin, einen neuen Cluster mit 2 Mastern und zu starten
3 Worker-Knoten (unter Verwendung der Cluster-API) und Anwenden von Cilium 1.7.6:

--- # Quelle: cilium / chart / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
Name: Cilium
Namespace: kube-system
--- # Quelle: cilium / chart / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
Name: Cilium-Operator
Namespace: Kubesystem
--- # Quelle: cilium / chart / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
Name: Cilium-Konfiguration
Namespace: kube-systemdata:

# Der Identitätszuweisungsmodus legt fest, wie Identitäten zwischen Cilium geteilt werden
# Knoten durch Festlegen, wie sie gespeichert werden. Die Optionen sind "crd" oder "kvstore".
# - "crd" speichert Identitäten in Kubernetes als CRDs (benutzerdefinierte Ressourcendefinition).
# Diese können abgefragt werden mit:
# kubectl bekommen Ciliumid
# - "kvstore" speichert Identitäten in einem kvstore usw. oder einem Konsul
# unten konfiguriert. Cilium-Versionen vor 1.6 unterstützten nur den kvstore
# Backend. Upgrades von diesen älteren Cilium-Versionen sollten weiterhin verwendet werden
# den kvstore durch Auskommentieren des Identitätszuweisungsmodus unten oder
# Setzen Sie es auf "kvstore".
Identitätszuweisungsmodus: crd

# Wenn Sie Cilium im Debug-Modus ausführen möchten, ändern Sie diesen Wert in true
Debug: "false"

# Aktivieren Sie die IPv4-Adressierung. Wenn aktiviert, wird allen Endpunkten eine IPv4 zugewiesen
# Adresse.
enable-ipv4: "true"

# Aktivieren Sie die IPv6-Adressierung. Wenn aktiviert, wird allen Endpunkten ein IPv6 zugewiesen
# Adresse.
enable-ipv6: "false"

# Wenn der Cilium-Monitor die Ablaufverfolgung für Pakete aggregieren soll, legen Sie diese Stufe fest
# auf "niedrig", "mittel" oder "maximal". Je höher der Pegel, desto weniger Pakete
#, die in der Monitorausgabe angezeigt wird.
Monitoraggregation: mittel

# Das Monitoraggregationsintervall bestimmt die typische Zeit zwischen den Monitoren
# Benachrichtigungsereignisse für jede zulässige Verbindung.
#
# Nur wirksam, wenn die Monitoraggregation auf "mittel" oder höher eingestellt ist.
Monitor-Aggregationsintervall: 5s

# Die Monitoraggregationsflags bestimmen, welche TCP-Flags welche auf dem
# Bei der ersten Beobachtung werden Monitorbenachrichtigungen generiert.
#
# Nur wirksam, wenn die Monitoraggregation auf "mittel" oder höher eingestellt ist.
Monitor-Aggregation-Flags: alle

# ct-global-max-entry- * gibt die maximale Anzahl von Verbindungen an
# wird über alle Endpunkte hinweg unterstützt, aufgeteilt nach Protokoll: TCP oder andere. Ein Paar
Anzahl der Karten verwendet diese Werte für IPv4-Verbindungen und ein weiteres Kartenpaar
# Verwenden Sie diese Werte für IPv6-Verbindungen.
#
# Wenn diese Werte geändert werden, wird beim nächsten Cilium-Start die
# Die Verfolgung laufender Verbindungen ist möglicherweise unterbrochen. Dies kann zu Kurzschluss führen
# Richtlinienabbrüche oder eine Änderung der Lastausgleichsentscheidungen für eine Verbindung.
#
# Für Benutzer, die ein Upgrade von Cilium 1.2 oder früher durchführen, um Störungen zu minimieren
# Kommentieren Sie diese Optionen während des Upgrade-Vorgangs aus.
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max hat die maximale Anzahl von Einträgen im Endpunkt angegeben
# Richtlinienzuordnung (pro Endpunkt)
bpf-policy-map-max: "16384"

# Durch die Vorbelegung von Karteneinträgen kann die Latenz pro Paket reduziert werden
# die Kosten für die Speicherzuweisung im Voraus für die Einträge in den Karten. Das
# Der unten angegebene Standardwert minimiert die Speichernutzung in der Standardinstallation.
# Benutzer, die empfindlich auf Latenz reagieren, können dies auf "true" setzen.
#
# Diese Option wurde in Cilium 1.4 eingeführt. Cilium 1.3 und früher ignorieren
# diese Option und verhalten Sie sich so, als ob sie auf "true" gesetzt ist.
#
# Wenn dieser Wert geändert wird, erfolgt beim nächsten Cilium-Start die Wiederherstellung
Die Anzahl der vorhandenen Endpunkte und die Verfolgung laufender Verbindungen können unterbrochen werden.
# Dies kann zu Richtlinieneinbrüchen oder zu einer Änderung der Lastausgleichsentscheidungen für a führen
# Verbindung für einige Zeit. Endpunkte müssen möglicherweise neu erstellt werden, um sie wiederherzustellen
# Konnektivität.
#
# Wenn diese Option während eines Upgrades von 1.3 oder früher auf "false" gesetzt ist
# 1.4 oder höher, dann kann es während des Upgrades zu einmaligen Unterbrechungen kommen.
preallocate-bpf-maps: "false"

# Regulärer Ausdruck passend zum kompatiblen Istio Sidecar Istio-Proxy
# Container-Bildnamen
Sidecar-Istio-Proxy-Bild: "cilium / istio_proxy"

# Kapselungsmodus für die Kommunikation zwischen Knoten
# Mögliche Werte:
# - behindert
# - vxlan (Standard)
# - geneve
Tunnel: Vxlan

# Name des Clusters. Nur relevant beim Aufbau eines Clusternetzes.
Clustername: Standard

# DNS Polling gibt regelmäßig eine DNS-Suche für jedes matchName aus
# Cilium-Mittel. Das Ergebnis wird verwendet, um die Endpunktrichtlinie neu zu generieren.
# DNS-Suchvorgänge werden im Abstand von 5 Sekunden wiederholt und sind für gemacht
# A (IPv4) und AAAA (IPv6) Adressen. Sollte eine Suche fehlschlagen, wird die neueste IP angezeigt
Stattdessen werden # Daten verwendet. Eine IP-Änderung löst eine Regeneration des Cilium aus
# Richtlinie für jeden Endpunkt und erhöhen Sie die Richtlinie pro Cilium-Agent
# Repository-Revision.
#
# Diese Option ist standardmäßig ab Version 1.4.x deaktiviert
# einer leistungsstärkeren DNS-Proxy-basierten Implementierung, siehe [0] für Details.
# Aktivieren Sie diese Option, wenn Sie FQDN-Richtlinien verwenden möchten, diese jedoch nicht verwenden möchten
# den DNS-Proxy.
#
# Um das Upgrade zu vereinfachen, können Benutzer diese Option auf "true" setzen.
# Andernfalls lesen Sie bitte das Upgrade-Handbuch [1], in dem die Vorgehensweise erläutert wird
# Richtlinienregeln für das Upgrade vorbereiten.
#
# [0] http://docs.cilium.io/en/stable/policy/language/#dns -basiert
# [1] http://docs.cilium.io/en/stable/install/upgrade/#changes -das-kann-eine-Aktion erfordern
tofqdns-enable-poller: "false"

# wait-bpf-mount lässt den Init-Container warten, bis das bpf-Dateisystem bereitgestellt wird
wait-bpf-mount: "false"

Maskerade: "wahr"
enable-xt-socket-fallback: "true"
install-iptables-rules: "true"
Auto-Direct-Node-Routen: "false"
kube-proxy-ersatz: "probe"
Enable-Host-Reachable-Services: "false"
enable-external-ips: "false"
enable-node-port: "false"
Node-Port-Bind-Schutz: "true"
Enable-Auto-Protect-Node-Port-Bereich: "true"
Enable-Endpoint-Health-Checking: "true"
Aktivieren Sie bekannte Identitäten: "false"
enable-remote-node-identity: "true"
--- # Quelle: cilium / chart / agent / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
Name: Ciliumrules:

• apiGroups:
  
  
  
  • network.k8s.io
    
    Ressourcen:
  
  
  • Netzwerkrichtlinien
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
• apiGroups:
  
  
  
  • Discovery.k8s.io
    
    Ressourcen:
  
  
  • Endpunktscheiben
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressourcen:
  
  
  • Namespaces
  
  
  • Dienstleistungen
  
  
  • Knoten
  
  
  • Endpunkte
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressourcen:
  
  
  • Schoten
  
  
  • Knoten
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
  • aktualisieren
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressourcen:
  
  
  • Knoten
  
  
  • Knoten / Status
    
    Verben:
  
  
  • Patch
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    Ressourcen:
  
  
  • benutzerdefinierte Ressourcendefinitionen
    
    Verben:
  
  
  • erstellen
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
  • aktualisieren
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ressourcen:
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • Ciliumendpunkte
  
  
  • ciliumendpoints / status
  
  
  • Ciliumknoten
  
  
  • Ciliumknoten / Status
  
  
  • Ciliumidentitäten
  
  
  • ciliumidentities / status
    
    Verben:
  
  
  • '*'
    
    --- # Quelle: cilium / chart / operator / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    Name: Cilium-Operator-Regeln:
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressourcen:
    
    # um [core | kube] DNS-Pods automatisch zu löschen, so dass sie anfangen zu sein
    
    # verwaltet von Cilium
  
  
  • Schoten
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
  • löschen
  
  
• apiGroups:
  
  
  
  • Discovery.k8s.io
    
    Ressourcen:
  
  
  • Endpunktscheiben
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
• apiGroups:
  
  
  
  • ""
    
    Ressourcen:
    
    #, um automatisch von k8s zu lesen und die Pod-CIDR des Knotens in Cilium zu importieren
    
    # etcd, damit alle Knoten wissen, wie sie einen anderen Pod erreichen, der in einem anderen ausgeführt wird
    
    # Knoten.
  
  
  • Knoten
    
    #, um die Übersetzung eines CNP durchzuführen, der ToGroup zu seinen Endpunkten enthält
  
  
  • Dienstleistungen
  
  
  • Endpunkte
    
    #, um die Apiserver-Konnektivität zu überprüfen
  
  
  • Namespaces
    
    Verben:
  
  
  • bekommen
  
  
  • Liste
  
  
  • Uhr
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ressourcen:
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • Ciliumendpunkte
  
  
  • ciliumendpoints / status
  
  
  • Ciliumknoten
  
  
  • Ciliumknoten / Status
  
  
  • Ciliumidentitäten
  
  
  • ciliumidentities / status
    
    Verben:
  
  
  • '*'
    
    --- # Quelle: cilium / chart / agent / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    Name: ciliumroleRef:
    
    apiGroup: rbac.authorization.k8s.io
    
    Art: ClusterRole
    
    Name: Ciliumsubjekte:
  
  
• Art: ServiceAccount
  Name: Cilium
  Namespace: Kubesystem
  --- # Quelle: cilium / chart / operator / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  name: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  Art: ClusterRole
  Name: Cilium-Operatoren Themen:
• Art: ServiceAccount
  Name: Cilium-Operator
  Namespace: Kubesystem
  --- # Quelle: cilium / chart / agent / templates / daemonset.yamlapiVersion: apps / v1kind: DaemonSetmetadata:
  Etiketten:
  k8s-app: cilium
  Name: Cilium
  Namespace: kube-systemspec:
  Wähler:
  matchLabels:
  k8s-app: cilium
  Vorlage:
  Metadaten:
  Anmerkungen:
  # Diese Anmerkung plus die CriticalAddonsOnly-Toleranz macht
  # Cilium soll ein kritischer Pod im Cluster sein, der Cilium sicherstellt
  # erhält Prioritätsplanung.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  scheduler.alpha.kubernetes.io/critical-pod: ""
  Etiketten:
  k8s-app: cilium
  spec:
  Behälter:
  
  
  
  • Argumente:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      Befehl:
    
    
    
    • Cilium-Mittel
      
      
      LivenessProbe:
      
      
      exec:
      
      
      Befehl:
      
      
      
      
      
      
      
      • Wimper
      
      
      
      
      • Status
      
      
      
      
      • --kurz
        
        
        
        Fehlerschwelle: 10
        
        
        
        # Die anfängliche Verzögerung für die Lebendigkeitssonde ist absichtlich groß
        
        
        
        # Vermeiden Sie einen endlosen Kill & Restart-Zyklus, falls die Initiale
        
        
        
        # Bootstrapping dauert länger als erwartet.
        
        
        
        initialDelaySeconds: 120
        
        
        
        ZeitraumSekunden: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        ReadinessProbe:
        
        
        
        exec:
        
        
        
        Befehl:
      
      
      
      
      • Wimper
      
      
      
      
      • Status
      
      
      
      
      • --kurz
        
        
        
        Fehlerschwelle: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        ZeitraumSekunden: 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:
      
      
      Schlüssel: Flanell-Master-Gerät
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Flanell-Deinstallation-beim-Beenden
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_CLUSTERMESH_CONFIG
      
      
      Wert: / var / lib / cilium / clustermesh /
    
    
    
    • Name: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Taste: Cni-Chaining-Modus
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: custom-cni-conf
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
      
      
      Bild: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      Lebenszyklus:
      
      
      postStart:
      
      
      exec:
      
      
      Befehl:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        exec:
        
        
        
        Befehl:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        Name: Cilium-Agent
        
        
        
        securityContext:
        
        
        
        Fähigkeiten:
        
        
        
        hinzufügen:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          privilegiert: wahr
          
          
          
          
          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-Geheimnisse
      
      
      readOnly: wahr
    
    
    
    • mountPath: / tmp / cilium / config-map
      
      
      Name: Cilium-Konfigurationspfad
      
      
      readOnly: wahr
      
      
      # Muss Kernelmodule laden können
    
    
    
    • mountPath: / lib / modules
      
      
      Name: lib-Module
      
      
      readOnly: wahr
    
    
    
    • mountPath: /run/xtables.lock
      
      
      name: xtables-lock
      
      
      hostNetwork: wahr
      
      
      initContainers:
    
    
    
  
  
  • Befehl:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • Name: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Clean-Cilium-Zustand
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Clean-Cilium-Bpf-Zustand
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: wait-bpf-mount
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
      
      
      Bild: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      Name: Clean-Cilium-Zustand
      
      
      securityContext:
      
      
      Fähigkeiten:
      
      
      hinzufügen:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        privilegiert: wahr
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      Name: Cilium-Run
      
      
      restartPolicy: Immer
      
      
      priorityClassName: systemknotenkritisch
      
      
      serviceAccount: Cilium
      
      
      serviceAccountName: cilium
      
      
      terminierungGracePeriodSeconds: 1
      
      
      Toleranzen:
    
    
    
  
  
  • Operator: Existiert
    
    Bände:
    
    # Um den Status zwischen Neustarts / Upgrades beizubehalten
  
  
  • hostPath:
    
    Pfad: / var / run / cilium
    
    Typ: DirectoryOrCreate
    
    Name: Cilium-Run
    
    # So installieren Sie das Cilium CNI-Plugin auf dem Host
  
  
  • hostPath:
    
    Pfad: / opt / cni / bin
    
    Typ: DirectoryOrCreate
    
    name: cni-path
    
    # So installieren Sie die cilium cni-Konfiguration auf dem Host
  
  
  • hostPath:
    
    Pfad: /etc/cni/net.d
    
    Typ: DirectoryOrCreate
    
    Name: etc-cni-netd
    
    # Um Kernelmodule laden zu können
  
  
  • hostPath:
    
    Pfad: / lib / modules
    
    Name: lib-Module
    
    # Zugriff auf iptables gleichzeitig mit anderen Prozessen (z. B. kube-proxy)
  
  
  • hostPath:
    
    Pfad: /run/xtables.lock
    
    Typ: FileOrCreate
    
    name: xtables-lock
    
    # Zum Lesen der Clustermesh-Konfiguration
  
  
  • Name: Clustermesh-Geheimnisse
    
    Geheimnis:
    
    defaultMode: 420
    
    optional: wahr
    
    secretName: cilium-clustermesh
    
    # Zum Lesen der Konfiguration aus der Konfigurationszuordnung
  
  
  • configMap:
    
    Name: Cilium-Konfiguration
    
    Name: Cilium-Konfigurationspfad
    
    updateStrategy:
    
    rollendes Update:
    
    maxUnavailable: 2
    
    Typ: RollingUpdate
    
    --- # Quelle: cilium / chart / operator / templates / deploy.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    Etiketten:
    
    io.cilium / app: operator
    
    Name: Cilium-Operator
    
    Name: Cilium-Operator
    
    Namespace: kube-systemspec:
    
    Repliken: 1
    
    Wähler:
    
    matchLabels:
    
    io.cilium / app: operator
    
    Name: Cilium-Operator
    
    Strategie:
    
    rollendes Update:
    
    maxSurge: 1
    
    maxUnavailable: 1
    
    Typ: RollingUpdate
    
    Vorlage:
    
    Metadaten:
    
    Anmerkungen:
    
    Etiketten:
    
    io.cilium / app: operator
    
    Name: Cilium-Operator
    
    spec:
    
    Behälter:
  
  
  • Argumente:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identitätszuweisungsmodus = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-node = true
      
      
      Befehl:
    
    
    
    • 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:
      
      
      Schlüssel: Debug
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Clustername
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Cluster-ID
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: ipam
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: disable-endpoint-crd
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: kvstore
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: kvstore-opt
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
    
    
    
    • Name: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      Schlüssel: AWS_ACCESS_KEY_ID
      
      
      Name: Cilium-Aws
      
      
      optional: wahr
    
    
    
    • Name: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      Schlüssel: AWS_SECRET_ACCESS_KEY
      
      
      Name: Cilium-Aws
      
      
      optional: wahr
    
    
    
    • Name: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      Schlüssel: AWS_DEFAULT_REGION
      
      
      Name: Cilium-Aws
      
      
      optional: wahr
    
    
    
    • Name: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      Schlüssel: Identitätszuweisungsmodus
      
      
      Name: Cilium-Konfiguration
      
      
      optional: wahr
      
      
      Bild: "docker.io/cilium/ operator: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      Name: Cilium-Operator
      
      
      LivenessProbe:
      
      
      httpGet:
      
      
      Host: '127.0.0.1'
      
      
      Pfad: / healthz
      
      
      Port: 9234
      
      
      Schema: HTTP
      
      
      initialDelaySeconds: 60
      
      
      ZeitraumSekunden: 10
      
      
      timeoutSeconds: 3
      
      
      hostNetwork: wahr
      
      
      restartPolicy: Immer
      
      
      serviceAccount: Cilium-Betreiber
      
      
      serviceAccountName: Cilium-Operator
    
    
    
  
  

- -
Sie erhalten dies, weil Sie zugewiesen wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

Könnten Sie versuchen, den Google-Level zu erhöhen und grep zum Filtern nach dem Knoten zu verwenden?
oder die Kapsel?

Am Do., 9. Juli 2020, 19:55 Uhr dilyevsky, [email protected]
schrieb:

Hier ist das Scheduler-Protokoll:

I0709 23: 08: 22.056081 1 registry.go: 150] Registrieren der Prädikat- und Prioritätsfunktion EvenPodsSpread
I0709 23: 08: 23.137451 1 Serving.go: 313] Generiertes selbstsigniertes Zertifikat im Speicher
W0709 23: 08: 33.843509 1 authentication.go: 297] Fehler beim Nachschlagen der Konfiguration der Cluster-Authentifizierung: etcdserver: Zeitüberschreitung bei Anforderung
W0709 23: 08: 33.843671 1 authentication.go: 298] Fortsetzung ohne Authentifizierungskonfiguration. Dies kann alle Anfragen als anonym behandeln.
W0709 23: 08: 33.843710 1 authentication.go: 299] Damit die Suche nach Authentifizierungskonfigurationen erfolgreich ist, setzen Sie --authentication-tolerate-lookup-fail = false
I0709 23: 08: 33.911805 1 registry.go: 150] Registrieren der Prädikat- und Prioritätsfunktion EvenPodsSpread
I0709 23: 08: 33.911989 1 registry.go: 150] Registrieren der Prädikat- und Prioritätsfunktion EvenPodsSpread
W0709 23: 08: 33.917999 1 authorisation.go: 47] Die Autorisierung ist deaktiviert
W0709 23: 08: 33.918162 1 authentication.go: 40] Die Authentifizierung ist deaktiviert
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Healthz unsicher bedienen auf [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] Starten von client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.926013 1 shared_informer.go: 223] Warten auf die Synchronisierung der Caches für die Datei client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Sicheres Servieren auf 127.0.0.1:10259
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] Starten von DynamicServingCertificateController
I0709 23: 08: 34.026382 1 shared_informer.go: 230] Caches werden für client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file synchronisiert
I0709 23: 08: 34.036998 1 Leaderelection.go: 242] Versuch, Leader Lease Kube-System / Kube-Scheduler zu erwerben ...
I0709 23: 08: 50.597201 1 Leaderelection.go: 252] erfolgreich erworbenes Lease-Kube-System / Kube-Scheduler
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd ist bereits in der aktiven Warteschlange vorhanden
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 ist bereits in der Backoff-Warteschlange vorhanden
E0709 23: 12: 58.099432 1 Leaderelection.go: 320] Fehler beim Abrufen der Ressourcensperre Kube-System / Kube-Scheduler: etcdserver: Leader geändert

Nach dem Neustart der Scheduler-Pods wird der ausstehende Pod sofort geplant.

- -
Sie erhalten dies, weil Sie zugewiesen wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Dies sind Ereignisse:
`` `Ereignisse:
Geben Sie Grund Alter aus Nachricht ein
---- ------ ---- ---- -------
Warnung FailedSchedulingStandard-Scheduler 0/6 Knoten sind verfügbar: 5 Knoten stimmten nicht mit der Knotenauswahl überein.
Warnung FailedSchedulingStandard-Scheduler 0/6 Knoten sind verfügbar: 5 Knoten stimmten nicht mit der Knotenauswahl überein.

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 verfügbar: 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

Ich werde jetzt versuchen, die Scheduler-Protokollstufe zu erhöhen ...

Ihr Pod Yaml hat eigentlich keine node-role.kubernetes.io/master Toleranz. Es sollte also nicht im Master geplant sein.

Hallo! Wir treffen das gleiche Problem. Wir sehen jedoch das gleiche Problem bei Bereitstellungen, bei denen Anti-Affinität verwendet wird, um sicherzustellen, dass ein Pod auf jedem Knoten geplant wird oder ein Pod-Selektor auf den bestimmten Knoten abzielt.
Das einfache Erstellen eines Pods mit einer Knotenauswahl, die dem Hostnamen des fehlerhaften Knotens entspricht, reichte aus, um die Planung fehlzuschlagen. Es wurde gesagt, dass 5 Knoten nicht mit dem Selektor übereinstimmten, aber nichts über den sechsten. Durch einen Neustart des Schedulers wurde das Problem behoben. Das sieht so aus, als würde etwas an diesem Knoten zwischengespeichert und verhindert die Planung auf dem Knoten.
Wie andere bereits sagten, haben wir nichts im Protokoll über den Fehler.

Wir haben die fehlgeschlagene Bereitstellung auf das Nötigste reduziert (wir haben den Fehler auf dem fehlerhaften Master entfernt):

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

Wir hatten das gleiche Problem, als der Meister einen Makel hatte und der Einsatz eine Duldung für den Makel. Es scheint also nicht spezifisch mit Dämonen, Toleranzen oder Affinität / Anti-Affinität verbunden zu sein. Wenn der Fehler auftritt, kann nichts geplant werden, das auf den bestimmten Knoten abzielt. Wir sehen das Problem in 1.18.2 bis 1.18.5 (nicht mit 1.18.0 oder .1 versucht)

Das einfache Erstellen eines Pods mit einer Knotenauswahl, die dem Hostnamen des fehlerhaften Knotens entspricht, reichte aus, um die Planung fehlzuschlagen

Können Sie klären, ob es nach dem Erstellen eines solchen Pods oder zuvor fehlschlägt? Ich gehe davon aus, dass dieser Knoten keinen Makel hatte, den der Pod nicht tolerierte.

@nodo wird bei der Reproduktion helfen. Könnten Sie sich den Code für NodeSelector ansehen? Möglicherweise müssen Sie beim Testen zusätzliche Protokollzeilen hinzufügen. Sie können den Cache auch drucken.

• Holen Sie sich die PID des Kube-Schedulers: $ pidof kube-scheduler
• Warteschlangen-Dump auslösen: $ sudo kill -SIGUSR2 <pid> . Beachten Sie, dass dies den Scheduler-Prozess nicht beendet.
• Suchen Sie dann im Scheduler-Protokoll nach den Zeichenfolgen "Speicherauszug der zwischengespeicherten NodeInfo", "Speicherauszug der Planungswarteschlange" und "Cache-Vergleicher gestartet".

/ Priorität kritisch-dringend

/ nicht zuweisen

Wir haben bereits einige Daemonsets und Bereitstellungen in "Ausstehend" gesehen, bevor wir versucht haben, diese Testbereitstellung bereitzustellen, sodass sie bereits fehlgeschlagen ist. und die Flecken waren vom Knoten entfernt worden.
Im Moment haben wir die Umgebung verloren, in der dies geschah, weil wir die Knoten neu starten mussten, damit das Problem nicht mehr sichtbar ist. Sobald wir reproduzieren, werden wir versuchen, mit weiteren Informationen zurückzukommen

Bitte tun Sie dies. Ich habe in der Vergangenheit erfolglos versucht, dies zu reproduzieren. Ich bin mehr an der ersten Instanz des Scheiterns interessiert. Es könnte immer noch mit Flecken zusammenhängen.

Wir haben das Problem reproduziert. Ich habe den Befehl ausgeführt, nach dem Sie gefragt haben. Hier sind die Informationen:

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: 

Leider scheint das nicht zu helfen

Das Speichern des Caches dient zum Debuggen und ändert nichts. Könnten Sie bitte die Müllkippe einschließen?

Könnten Sie unter der Annahme, dass dies der erste Fehler war, das Pod-Yaml und den Knoten einschließen?

Das ist so ziemlich alles, was abgeladen wurde. Ich habe nur die anderen Knoten entfernt. Dies war nicht der erste Fehler, aber Sie können Coredns Pod im Dump sehen, das war der erste. Ich bin mir nicht sicher, was Sie sonst noch in der Müllkippe verlangen.
Ich werde die Yamswurzeln holen

Vielen Dank, ich habe nicht bemerkt, dass Sie den entsprechenden Knoten und Pod gekürzt haben.

Könnten Sie die geplanten Pods für diesen Knoten einschließen? Nur für den Fall, dass es einen Fehler bei der Berechnung der Ressourcennutzung gibt.

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

Das AllowedPodNumber: 0 scheint seltsam.

Hier sind die anderen Pods auf diesem Knoten:
` 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:

Bei allen Knoten ist allowPodNumber in den angeforderten Ressourcen im Speicherauszug auf 0 gesetzt, die anderen Knoten sind jedoch planbar

Der Knoten 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

und die Kapsel:

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

Vielen Dank für alle Informationen. @nodo kannst du es nehmen?

Wir versuchen jetzt auch mit https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc , um weitere Informationen zu erhalten

/Hilfe

@maelk zögern Sie nicht, dies zu nehmen und eine PR einzureichen, wenn Sie den Fehler finden. Die von Ihnen hinzugefügten Protokollzeilen sind wahrscheinlich hilfreich. Ansonsten öffne ich mich für Mitwirkende.

@alculquicondor :
Diese Anfrage wurde als hilfsbedürftig von einem Mitwirkenden markiert.

Bitte stellen Sie sicher, dass die Anfrage die hier aufgeführten Anforderungen erfüllt.

Wenn diese Anforderung diese Anforderungen nicht mehr erfüllt, kann das Etikett entfernt werden
durch Kommentieren mit dem Befehl /remove-help .

/zuordnen

@maelk Gibt es etwas Spezielles für das Timing, wenn dieses Problem zum ersten Mal auftritt? Geschieht dies beispielsweise direkt nach dem Start des Knotens?

Nein, es gibt einige Pods, die dort geplant werden und gut laufen. Sobald das Problem auftritt, kann kein Termin mehr geplant werden.

Senkung der Priorität, bis ein reproduzierbarer Fall vorliegt.

Wir konnten den Fehler mit einem Scheduler reproduzieren, der die zusätzlichen Protokolleinträge enthielt. Was wir sehen ist, dass einer der Master vollständig aus der Liste der Knoten verschwindet, die durchlaufen werden. Wir können sehen, dass der Prozess mit den 6 Knoten beginnt (aus dem Schnappschuss):

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)}

aber danach können wir sehen, dass es nur über 5 Knoten iteriert, und dann bekommen wir:

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

Daher wird einer der Knoten aus der Liste der potenziellen Knoten entfernt. Leider hatten wir zu Beginn des Prozesses nicht genug Protokollierung, aber wir werden versuchen, mehr zu bekommen.

Code-Referenzen nach Protokollzeile:

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

@maelk
Haben Sie Zeilen für %v/%v on node %v, too many nodes fit ?

Andernfalls könnten Sie bei @pancernik nach Fehlern bei workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) suchen ?

Nein, dieses Protokoll wurde nicht angezeigt. Ich würde auch denken, dass es sein könnte, dass wir entweder ein Problem mit der Parallelisierung haben oder dass der Knoten früher herausgefiltert wird. Wenn es hier mit einem Fehler fehlschlug: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464 Funktion und die Parallelisierung.

Ich habe gerade festgestellt, dass ein Knoten die Filterung zweimal durchläuft!

Die Protokolle sind:

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)} 

Wie Sie sehen können, durchläuft der Knoten worker-pool1-60846k0y-scheduler die Filterung zweimal

Nein, dieses Protokoll wurde nicht angezeigt. Ich würde auch denken, dass es sein könnte, dass wir entweder ein Problem mit der Parallelisierung haben oder dass der Knoten früher herausgefiltert wird. Wenn es hier mit einem Fehler fehlschlug :

Ja, ein Fehler dort würde sich als Planungsfehler in den Pod-Ereignissen manifestieren.

Ich habe gerade festgestellt, dass ein Knoten die Filterung zweimal durchläuft!

Ich würde ehrlich gesagt nicht glauben, dass die Parallelisierung Fehler aufweist (die es immer noch wert sind, überprüft zu werden), aber dies könnte ein Zeichen dafür sein, dass wir den Snapshot nicht aus dem Cache erstellt haben (wie wir aus dem Cache-Dump gesehen haben, ist der Cache korrekt), indem wir a hinzugefügt haben Knoten zweimal. Da statuses eine Karte ist, ist es sinnvoll, dass wir nur 5 Knoten in der letzten Protokollzeile "sehen".

Dies ist der Code (Tipp von 1.18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

Ich werde versuchen, viele Protokolle im Cache-Teil des Schedulers hinzuzufügen, insbesondere in Bezug auf das Hinzufügen und Aktualisieren von Knoten und den Snapshot. In der letzten Zeile der Protokolle können Sie jedoch sehen, dass der Snapshot tatsächlich korrekt ist und alle Knoten enthält. Was auch immer später passiert, scheint bei der Bearbeitung dieses Snapshots zu passieren

Cache! = Schnappschuss

Cache ist das Lebewesen, das von Ereignissen aktualisiert wird. Der Snapshot wird vor jedem Planungszyklus (aus dem Cache) aktualisiert, um den Status zu "sperren". Wir haben Optimierungen hinzugefügt, um diesen letzten Prozess so schnell wie möglich zu gestalten. Es ist möglich, dass der Fehler vorhanden ist.

Danke @maelk! Das ist sehr nützlich. Ihre Protokolle zeigen an, dass (*nodeinfo.NodeInfo)(0xc000952000) in der Liste bereits unter https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca3807321 kopiert wurde. Das würde in der Tat bedeuten, dass es dupliziert wird, bevor der Snapshot aktualisiert wird.

Dies stammt aus dem Snapshot, der vor dieser Protokollnachricht erstellt wurde: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361. Es sieht also eher so aus, als hätte der Inhalt des Schnappschusses die Duplizierung, da er von https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca3807327d stammt

Stimmt. Ich meinte, es ist bereits dupliziert, bevor die Aktualisierung des Snapshots abgeschlossen ist.

Stimmt. Ich meinte, es ist bereits dupliziert, bevor die Aktualisierung des Snapshots abgeschlossen ist.

Nein, der Snapshot wird zu Beginn des Planungszyklus aktualisiert. Der Fehler tritt entweder während des Snapshot-Updates oder davor auf. Der Cache ist jedoch gemäß dem Speicherauszug in https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008 korrekt

EDIT: Ich habe es falsch gelesen, ich habe das Wort "beendet" nicht gesehen :)

Der Snapshot zur PR-Optimierung wurde in Version 1.18 erstellt: https://github.com/kubernetes/kubernetes/pull/85738 und https://github.com/kubernetes/kubernetes/pull/86919

Ich frage mich, ob der Knotenbaum auch doppelte Datensätze enthält

Ich frage mich, ob der Knotenbaum auch doppelte Datensätze enthält

@maelk Könnten Sie einen anzeigen ?

Wir fügen keine Elemente zu NodeInfoList hinzu oder entfernen sie. Wir erstellen entweder die vollständige Liste aus dem Baum oder nicht. Wenn also Duplikate vorhanden sind, stammen diese wahrscheinlich aus dem Baum, denke ich.

Nur um klarzustellen:
1) Der Cluster hat 6 Knoten (einschließlich der Master).
2) Der Knoten, der den Pod hosten soll, wurde überhaupt nicht untersucht (keine Protokollzeile zeigt dies an), was bedeuten kann, dass er überhaupt nicht in NodeInfoList enthalten ist
3) NodeInfoList hat 6 Knoten, von denen einer doppelt vorhanden ist

Ich frage mich, ob der Knotenbaum auch doppelte Datensätze enthält

@maelk Könnten Sie einen anzeigen ?

Ein Speicherauszug jedes Knotenbaums, jeder Liste und jeder Karte wäre großartig.

Ich werde daran arbeiten, diese zu bekommen. In der Zwischenzeit ein kleines Update. Wir können in den Protokollen sehen:

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

Und genau an diesem Punkt verschwindet der fehlende Knoten. Das letzte Vorkommen in den Protokollen ist um 13:37:24. In der nächsten Planung ist der fehlende Knoten weg. Es sieht also so aus, als ob der Fehler in der Aktualisierung des Knotenbaums liegt. Alle Knoten durchlaufen dieses Update. Es ist nur so, dass dieser Worker 608 der letzte ist, der es durchläuft.

Beim Speichern des Caches (mit SIGUSR2) werden dort alle sechs Knoten aufgelistet, wobei die Pods auf den Knoten ausgeführt werden, ohne dass Duplikate oder fehlende Knoten vorhanden sind.

Wir werden es mit einem zusätzlichen Debugging für die Snapshot-Funktionalität erneut versuchen: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Der Knoten "worker-pool1-60846k0y-scheduler" in der Gruppe "" wurde aus NodeTree entfernt

Interessant finde ich, dass das Entfernen / Hinzufügen durch einen updateNode-Aufruf ausgelöst wird. Der Zonenschlüssel fehlt beim Entfernen, ist aber beim Hinzufügen vorhanden, sodass beim Update im Grunde die Zonen- und Regionsbezeichnungen hinzugefügt wurden.

Haben Sie andere Scheduler-Protokolle, die sich auf diesen Knoten beziehen?

Wir versuchen, den Fehler mit der hinzugefügten Protokollierung zu reproduzieren. Ich komme wieder, wenn ich mehr Infos habe

Ich werde daran arbeiten, diese zu bekommen. In der Zwischenzeit ein kleines Update. Wir können in den Protokollen sehen:

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

Ich werde darauf hinweisen, dass ein solcher Knoten der Knoten ist, der wiederholt wird. @maelk , hast du ähnliche Nachrichten für andere Knoten gesehen oder überhaupt nicht? Als @ ahg-g sollte dies erwartet werden, wenn ein Knoten zum ersten Mal seine Topologiebezeichnungen erhält.

Ja, es ist für alle Knoten passiert und wird erwartet. Der Zufall ist, dass dieser Knoten speziell der zuletzt aktualisierte ist und genau zu diesem Zeitpunkt der andere Knoten verloren geht

Haben Sie Aktualisierungsprotokolle für den fehlenden Knoten erhalten?

Haben Sie Aktualisierungsprotokolle für den fehlenden Knoten erhalten?

lol, habe gerade diese Frage getippt.

Möglicherweise besteht der Fehler darin, dass die gesamte Zone aus dem Baum gelöscht wird, bevor alle Knoten entfernt werden.

Nur zur Klarstellung, ich schaue nicht persönlich auf den Code, ich versuche nur sicherzustellen, dass wir alle Informationen haben. Und ich denke, mit dem, was wir jetzt haben, sollten wir in der Lage sein, den Fehler zu erkennen. Sie können gerne PRs einreichen und viel besser, wenn Sie einen fehlgeschlagenen Komponententest bereitstellen können.

Haben Sie Aktualisierungsprotokolle für den fehlenden Knoten erhalten?

Ja, es wird angezeigt, dass die Zone für diesen fehlenden Knoten aktualisiert wurde. Es gibt einen Protokolleintrag für alle Knoten

Um ehrlich zu sein, habe ich immer noch keine Ahnung, warum der Fehler aufgetreten ist, aber wenn wir es fast herausfinden können, werde ich einen PR- oder Unit-Test einreichen.

Ja, es wird angezeigt, dass die Zone für diesen fehlenden Knoten aktualisiert wurde. Es gibt einen Protokolleintrag für alle Knoten

Wenn ja, dann denke ich, dass dies "der genaue Punkt ist, an dem der fehlende Knoten verschwindet". kann nicht korreliert werden. Warten wir auf die neuen Protokolle. Es wäre großartig, wenn Sie alle Scheduler-Protokolle, die Sie in einer Datei erhalten, freigeben könnten.

Ich werde tun, wenn wir mit der neuen Protokollierung reproduzieren. Anhand der vorhandenen können wir tatsächlich erkennen, dass die Pod-Planung unmittelbar nach diesem Update als erstes fehlschlägt. Aber es gibt nicht genug Informationen, um zu wissen, was dazwischen passiert ist, also bleiben Sie dran ...

@maelk Haben Sie eine Nachricht gesehen, die mit snapshot state is not consistent in den Scheduler-Protokollen beginnt?

Könnten Sie vollständige Scheduler-Protokolle bereitstellen?

Nein, diese Nachricht ist nicht vorhanden. Ich könnte eine abgespeckte Protokolldatei geben (um Wiederholungen zu vermeiden), aber warten wir zuerst, bis wir die Ausgabe mit mehr Protokollen um den Schnappschuss haben

Ich habe den Fehler gefunden. Das Problem liegt bei der Funktion nodeTree next (), die in einigen Fällen keine Liste aller Knoten zurückgibt. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

Es ist sichtbar, wenn Sie hier Folgendes hinzufügen: 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"},
},

Das Hauptproblem besteht darin, dass beim Hinzufügen eines Knotens die Indizes für einige Zonen nicht auf 0 stehen. Dazu müssen mindestens zwei Zonen vorhanden sein, von denen eine kürzer als die andere ist und die längere einen Index aufweist, der beim ersten Aufruf der nächsten Funktion nicht auf 0 gesetzt ist.

Die Lösung, die ich gewählt habe, besteht darin, den Index zurückzusetzen, bevor ich das erste Mal next () aufrufe. Ich habe eine PR geöffnet, um meinen Fix zu zeigen. Natürlich ist es gegen die Version 1.18, da ich daran gearbeitet habe, aber es dient hauptsächlich dazu zu diskutieren, wie man es repariert (oder vielleicht die next () - Funktion selbst repariert). Ich kann eine ordnungsgemäße PR gegenüber dem Master eröffnen und die Backports bei Bedarf später durchführen.

Ich habe das gleiche Problem mit der Iteration bemerkt. Aber ich konnte das nicht mit einem Duplikat im Schnappschuss verknüpfen. Haben Sie es geschafft, ein Szenario zu erstellen, in dem dies passieren würde, @maelk?

Ja, Sie können es in den Komponententests ausführen, indem Sie den kleinen Code hinzufügen, den ich eingegeben habe

Ich arbeite jetzt daran, einen Testfall für den Schnappschuss hinzuzufügen, um sicherzustellen, dass dieser ordnungsgemäß getestet wurde.

Daumen hoch an @igraecao für die Hilfe bei der Reproduktion des Problems und der Ausführung der Tests in seinem Setup

Vielen Dank an alle für das Debuggen dieses berüchtigten Problems. Das Zurücksetzen des Index vor dem Erstellen der Liste ist sicher. Ich denke, wir sollten dies für die Patches 1.18 und 1.19 tun und eine ordnungsgemäße Korrektur im Hauptzweig vornehmen.

Der Zweck der Funktion next hat sich mit der Einführung der NodeInfoList geändert. Daher können wir sie sicherlich vereinfachen und möglicherweise in toList ändern, eine Funktion, die eine Liste aus dem Baum erstellt und einfach startet jedes Mal von Anfang an.

Ich verstehe das Problem jetzt: Die Berechnung, ob eine Zone erschöpft ist oder nicht, ist falsch, da nicht berücksichtigt wird, wo in jeder Zone wir diesen "UpdateSnapshot" -Prozess gestartet haben. Und ja, es wäre nur bei unebenen Zonen sichtbar.

Großartige Arbeit beim Erkennen dieses @maelk!

Ich würde denken, wir haben das gleiche Problem in älteren Versionen. Es ist jedoch durch die Tatsache verborgen, dass wir jedes Mal einen Baumpass machen. Während wir in 1.18 das Ergebnis so lange aufnehmen, bis sich Änderungen im Baum ergeben.

Nachdem die Round-Robin-Strategie in generic_scheduler.go implementiert ist, können wir möglicherweise alle Zähler vor UpdateSnapshot zurücksetzen, wie dies Ihre PR tut.

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

Nur um @ ahg-g noch einmal zu überprüfen, sollte dies auch in einem Cluster in Ordnung sein, in dem ständig neue Knoten hinzugefügt / entfernt werden, oder?

Vielen Dank an @maelk für das

Der Zweck der nächsten Funktion änderte sich mit der Einführung der NodeInfoList, und so können wir sie sicherlich vereinfachen und möglicherweise in toList ändern, eine Funktion, die eine Liste aus dem Baum erstellt und jedes Mal einfach von vorne beginnt.

Angesichts der Tatsache, dass cache.nodeTree.next() nur beim Erstellen des Snapshots nodeInfoList aufgerufen wird, ist es meiner Meinung nach auch sicher, die Indizes (sowohl zoneIndex als auch nodeIndex) aus der nodeTree-Struktur zu entfernen. Überlegen Sie sich stattdessen eine einfache nodeIterator() -Funktion, um die Zone / den Knoten im Round-Robin-Verfahren zu durchlaufen.

Übrigens: Es gibt einen Tippfehler in https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090. Der Fall sollte sein:

{
    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]
},

Nur um @ ahg-g noch einmal zu überprüfen, sollte dies auch in einem Cluster in Ordnung sein, in dem ständig neue Knoten hinzugefügt / entfernt werden, oder?

Ich gehe davon aus, dass Sie über die Logik in generic_scheduler.go sprechen. Wenn ja, spielt es keine Rolle, ob Knoten hinzugefügt oder entfernt wurden. Die Hauptsache, die wir vermeiden müssen, ist, jedes Mal in derselben Reihenfolge über die Knoten zu iterieren Wenn wir einen Pod planen, brauchen wir nur eine gute Annäherung an die Iteration über die Knoten über Pods hinweg.

Angesichts der Tatsache, dass cache.nodeTree.next () nur beim Erstellen des Snapshots nodeInfoList aufgerufen wird, ist es meiner Meinung nach auch sicher, die Indizes (sowohl zoneIndex als auch nodeIndex) aus der nodeTree-Struktur zu entfernen. Überlegen Sie sich stattdessen eine einfache nodeIterator () -Funktion, mit der Sie die Zone / den Knoten im Round-Robin-Verfahren durchlaufen können.

Ja, wir müssen nur jedes Mal alle Zonen / Knoten in derselben Reihenfolge durchlaufen.

Ich habe die PR mit einem Komponententest für die Funktion aktualisiert, die die Snapshot-Liste aktualisiert, speziell für diesen Fehler. Ich kann mich auch darum kümmern, die next () - Funktion zu überarbeiten, um die Zonen und Knoten ohne Round-Robin zu durchlaufen, wodurch das Problem behoben wird.

Danke, hört sich gut an, aber wir sollten trotzdem zwischen den Zonen iterieren, so wie wir es jetzt tun, das ist beabsichtigt.

Ich verstehe nicht wirklich, was du hier meinst. Ist es so, dass die Reihenfolge der Knoten eine Rolle spielt und wir immer noch zwischen Zonen hin- und herwechseln müssen, oder können wir alle Knoten einer Zone auflisten, eine Zone nach der anderen? Nehmen wir an, Sie haben zwei Zonen mit jeweils zwei Knoten. In welcher Reihenfolge erwarten Sie sie, oder spielt das überhaupt eine Rolle?

Die Reihenfolge ist wichtig, wir müssen beim Erstellen der Liste zwischen den Zonen wechseln. Wenn Sie zwei Zonen mit jeweils zwei Knoten z1: {n11, n12} und z2: {n21, n22} , sollte die Liste {n11, n21, n12, n22}

ok, danke, ich werde es mir überlegen. Können wir in der Zwischenzeit mit der schnellen Lösung fortfahren? Übrigens schlagen einige Tests fehl, aber ich bin mir nicht sicher, wie das mit meiner PR zusammenhängt

Das sind Flocken. Bitte senden Sie auch einen Patch an 1.18.

OK mach ich. Vielen Dank

{
  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 , meinst du, dieser Test ignoriert den 'Node-5'?

Ich fand nach dem Fixieren des Anhangs in https://github.com/kubernetes/kubernetes/pull/93516 das Testergebnis, dass alle Knoten iteriert werden können:

{
            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"},
},

Der Knoten 5, 6, 7, 8, 3 kann iteriert werden.

Vergib mir, wenn ich hier etwas falsch verstehe.

Ja, es war absichtlich, basierend auf dem, was da war, aber ich kann sehen, wie kryptisch dies sein kann. Machen Sie es also besser, damit sich das Anhängen klarer verhält. Danke für den Patch.

Wie weit zurück glaubst du, war dieser Fehler vorhanden? 1,17? 1,16? Ich habe gerade genau das gleiche Problem in 1.17 unter AWS gesehen, und ein Neustart des außerplanmäßigen Knotens hat das Problem behoben.

@judgeaxl könnten Sie weitere Details zur Verfügung stellen? Protokollzeilen, Cache-Dumps usw. So können wir feststellen, ob das Problem dasselbe ist.

Wie ich in https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695 festgestellt habe, glaube ich, dass dieser Fehler in älteren Versionen vorhanden war, aber ich denke, dass er vorübergehend ist.

@maelk könnten Sie untersuchen?

Bitte teilen Sie auch die Verteilung der Knoten in den Zonen.

@alculquicondor kann ich leider noch nicht. Es tut uns leid.

@alculquicondor Entschuldigung, ich habe den Cluster aus anderen Gründen bereits neu erstellt, aber es war möglicherweise ein Netzwerkkonfigurationsproblem im Zusammenhang mit Multi-Az-Bereitstellungen und in welchem ​​Subnetz der fehlerhafte Knoten gestartet wurde, sodass ich mir vorerst keine Sorgen machen würde den Kontext dieser Ausgabe. Wenn ich es wieder bemerke, melde ich mich mit besseren Details zurück. Vielen Dank!

/ retitle Einige Knoten werden bei der Planung nicht berücksichtigt, wenn ein Zonenungleichgewicht vorliegt