Kubernetes: Algunos nodos no se consideran en la programación cuando existe un desequilibrio de zona

/ sig programación

¿Puede proporcionar el yaml completo del nodo, el conjunto de demonios, un pod de ejemplo y el espacio de nombres que lo contiene tal como se recupera del servidor?

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

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

pod de ejemplo (en funcionamiento):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

pod de ejemplo (sin programación):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

espacio de nombres:
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

Los pods de DaemonSet programan con un selector nodeAffinity que solo coincide con un único nodo, por lo que se espera el mensaje "12 de 13 no coinciden".

No veo una razón por la que el programador no esté satisfecho con el combo pod / nodo ... no hay puertos que puedan entrar en conflicto en la especificación del pod, el nodo no es no programable o contaminado, y tiene recursos suficientes

Bien, reinicié los 3 programadores (cambié el nivel de registro a 4 si podemos ver algo interesante allí). Sin embargo, solucionó el problema.

% 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

ahora todos los conjuntos de demonios están aprovisionados correctamente. Extraño, de todos modos, parece que hay algo mal con el programador

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

Vemos el mismo problema similar en v1.18.3, un nodo no se puede programar para los pods de daemonset.
reiniciar el programador ayuda.

[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

Difícil de depurar sin saber cómo repreducir. ¿Tiene los registros del programador por casualidad para el pod no programado?

Bien, reinicié los 3 programadores

Supongo que solo uno de ellos se llama default-scheduler , ¿correcto?

cambió el nivel de registro a 4 si podemos ver algo interesante allí

¿Puedes compartir lo que notaste?

establezca loglevel en 9, pero parece que no hay nada más interesante, los registros a continuación se repiten.

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)

sí, no pude ver nada más que la misma línea

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

lo extraño es que el mensaje de registro muestra el resultado solo para 7 nodos, como el problema informado en https://github.com/kubernetes/kubernetes/issues/91340

/ cc @damemi

@ ahg-g, esto parece el mismo problema que informé allí, parece que tenemos un complemento de filtro que no siempre informa su error o alguna otra condición que falla silenciosamente si tuviera que adivinar

Tenga en cuenta que en mi problema, reiniciar el programador también lo solucionó (como se menciona en este hilo también https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

El mío también era sobre un daemonset, así que creo que es un duplicado. Si ese es el caso, podemos cerrar esto y continuar la discusión en https://github.com/kubernetes/kubernetes/issues/91340

De todos modos, el programador necesita una opción de registro más detallada, es imposible depurar estos problemas si no hay registros sobre lo que hace

@zetaab +1, el programador podría utilizar mejoras significativas en sus capacidades de registro actuales. Esa es una actualización que he querido abordar durante un tiempo y finalmente abrí un problema aquí: https://github.com/kubernetes/kubernetes/issues/91633

/asignar

Estoy investigando esto. Algunas preguntas para ayudarme a acotar el caso. Todavía no he podido reproducirme.

• ¿Qué se creó primero: el daemonset o el nodo?
• ¿Estás usando el perfil predeterminado?

• ¿Tienes extensores?

Los nodos se crearon antes que el daemonset.
supongamos que usamos el perfil predeterminado, ¿a qué perfil te refieres y cómo verificar?
sin extensores.

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

Otra cosa que puede afectar es que el rendimiento del disco no es muy bueno para etcd, etcd se queja de operaciones lentas.

Sí, esos indicadores harían que el programador se ejecutara con el perfil predeterminado. Seguiré buscando. Todavía no pude reproducirme.

Todavía nada ... ¿Hay algo más que estés usando que creas que podría estar impactando? contaminaciones, puertos, otros recursos?

Hice algunos intentos relacionados con esto. Cuando el problema está activado, los pods aún se pueden programar en el nodo (sin definición o con el selector "nodeName").

Si intenta utilizar Affinity / Antiaffinity, los pods no se programan en el nodo.

Trabajando cuando el problema está activado:

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

No funciona al mismo tiempo:

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

Además, cuando se verificaron estos últimos, incluso aquellos fueron bastante interesantes:

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.

• El primer evento es cuando se acaba de aplicar el manifiesto (no se hace nada en el nodo no programable).
• El segundo y el tercero fueron cuando el nodo se eliminó con kubectl y luego se reinició.
• El cuarto vino cuando el nodo volvió a subir. El nodo que tenía un problema era el maestro, por lo que el nodo no iba allí (pero muestra que el nodo no se encontró en 3 eventos anteriores). Lo interesante del cuarto evento es que todavía falta información de un nodo. El evento dice que hay 0/9 nodos disponibles, pero la descripción se proporciona solo de 8.

"nodeName" no es un selector. El uso de nodeName evitaría la programación.

El cuarto vino cuando el nodo volvió a subir. El nodo que tenía un problema era el maestro, por lo que el nodo no iba allí (pero muestra que el nodo no se encontró en 3 eventos anteriores). Lo interesante del cuarto evento es que todavía falta información de un nodo. El evento dice que hay 0/9 nodos disponibles, pero la descripción se proporciona solo de 8.

¿Está diciendo que la razón por la que el pod no debería haberse programado en el nodo faltante es porque era un maestro?

Estamos viendo 8 node(s) didn't match node selector yendo a 7. Supongo que no se eliminaron nodos en este punto, ¿correcto?

"nodeName" no es un selector. El uso de nodeName evitaría la programación.

El intento de "NodeName" fue resaltar, ese nodo es utilizable y el pod llega allí si se desea. Entonces, la cuestión no es la incapacidad del nodo para iniciar pods.

El cuarto vino cuando el nodo volvió a subir. El nodo que tenía un problema era el maestro, por lo que el nodo no iba allí (pero muestra que el nodo no se encontró en 3 eventos anteriores). Lo interesante del cuarto evento es que todavía falta información de un nodo. El evento dice que hay 0/9 nodos disponibles, pero la descripción se proporciona solo de 8.

¿Está diciendo que la razón por la que el pod no debería haberse programado en el nodo faltante es porque era un maestro?

Estamos viendo 8 node(s) didn't match node selector yendo a 7. Supongo que no se eliminaron nodos en este punto, ¿correcto?

El grupo de prueba tiene 9 nodos; 3 maestros y 6 trabajadores. Antes de que el nodo que no funcionaba se iniciara con éxito, los eventos ofrecían información sobre todos los nodos disponibles: 0/8 nodes are available: 8 node(s) didn't match node selector. . Pero cuando apareció ese nodo que coincidiría con el selector de nodo, el evento dijo 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. explicación dice que hay 8 que no coinciden, pero no dice nada sobre el noveno (que se reconoció en el evento anterior).

Entonces el estado del evento:

• 1er evento: 9 nodos disponibles, el error se notó con daemonset
• 2do y 3er evento: 8 nodos disponibles. El que no estaba recibiendo pod se estaba reiniciando
• 4to evento: 9 nodos disponibles (por lo que el que se inició se reinició).

Al final, la cápsula de prueba no se inició en el nodo correspondiente debido a las manchas, pero esa es otra historia (y debería haber sido el caso ya en el primer evento).

El intento de "NodeName" fue resaltar, ese nodo es utilizable y el pod llega allí si se desea. Entonces, la cuestión no es la incapacidad del nodo para iniciar pods.

Tenga en cuenta que nada protege contra el compromiso excesivo de un nodo, excepto el planificador. Entonces esto realmente no muestra mucho.

Al final, la cápsula de prueba no se inició en el nodo correspondiente debido a las manchas, pero esa es otra historia (y debería haber sido el caso ya en el primer evento).

Mi pregunta es: ¿el noveno nodo estaba contaminado desde el principio? Estoy tratando de buscar (1) pasos reproducibles para alcanzar el estado o (2) donde podría estar el error.

Mi pregunta es: ¿el noveno nodo estaba contaminado desde el principio? Estoy tratando de buscar (1) pasos reproducibles para alcanzar el estado o (2) donde podría estar el error.

Sí, la mancha estuvo allí todo el tiempo en este caso, ya que el nodo no receptor era el maestro. Pero hemos visto el mismo problema tanto en los amos como en los trabajadores.

Todavía no tengo idea de dónde proviene el problema, solo que al menos la recreación del nodo y el reinicio del nodo parecen estar solucionando el problema. Pero esas son formas un poco "difíciles" de arreglar las cosas.

Es una posibilidad remota, pero si te encuentras con él nuevamente ... ¿podrías verificar si hay alguna cápsula nominada en el nodo que no aparece?

Estoy publicando preguntas mientras pienso en posibles escenarios:

• ¿Tiene otros nodos maestros en su clúster?
• ¿Tienes extensores?

* Do you have other master nodes in your cluster?

Todos los clústeres tienen 3 maestros (por lo que reiniciarlos es fácil)

* Do you have extenders?

No.

Hoy noté algo interesante: tenía un clúster en el que un maestro no recibía el pod de DaemonSet. Tenemos ChaosMonkey en uso, que finalizó uno de los nodos de trabajo. Eso es interesante, esto hizo que la cápsula fuera al maestro que no la estaba recibiendo antes. Entonces, de alguna manera, la eliminación de otro nodo que no sea el problemático parecía estar solucionando el problema en ese punto.

Debido a ese "arreglo", tengo que esperar a que el problema vuelva a ocurrir para poder responder sobre los grupos nominados.

Estoy confundido ahora ... ¿Tu daemonset tolera la contaminación para los nodos maestros? En otras palabras ... ¿el error para usted es solo el evento de programación o también el hecho de que los pods deberían haber sido programados?

El problema es que el programador no encuentra ese nodo, incluso si hay al menos una configuración de afinidad (o antiafinidad) coincidente.

Es por eso que dije que se esperaba el error de taint y que ya debería haber estado allí en el primer evento (ya que la taint no es parte de los criterios de afinidad)

Entendido. Estaba intentando confirmar tu configuración para asegurarme de que no me falta nada.

No creo que el planificador "no vea" el nodo. Dado que vemos 0/9 nodes are available , podemos concluir que el nodo está en la caché. Es más como si el motivo no programable se perdiera en algún lugar, por lo que no lo incluimos en el evento.

Es cierto que el recuento total coincide siempre con el recuento real de nodos. No se proporciona un texto de evento más descriptivo en todos los nodos, pero ese puede ser un problema separado como mencionó.

¿Puede ver los registros de su programador de kube? ¿Algo que parezca relevante?

Creo que @zetaab intentó buscar eso sin éxito. Puedo intentarlo cuando el problema vuelva a ocurrir (así como la cosa de la cápsula nominada que se preguntó anteriormente)

Si es posible, ejecute también 1.18.5, en caso de que solucionemos el problema sin darnos cuenta.

Puedo reproducir esto de manera confiable en mi grupo de prueba si necesita más registros

@dilyevsky Comparte los pasos de reproducción. ¿Puede identificar de alguna manera cuál es el filtro que está fallando?

Parece ser solo el metadata.name del nodo para el pod ds ... raro. Aquí está el pod yaml:

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

La forma en que reproduzco esto es girando un nuevo clúster con 3 maestros y 3 nodos de trabajo (usando Cluster API) y aplicando Cilium 1.7.6:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aquí está el registro del programador:
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

Después de reiniciar los pods del programador, el pod pendiente se programa inmediatamente.

¿Qué eventos de pod obtienes? ¿Sabes si hay taints en el nodo?
¿Dónde no está programado? ¿Solo falla para los nodos maestros o cualquier
nodos? ¿Hay suficiente espacio en el nodo?

El jueves 9 de julio de 2020 a las 7:49 pm dilyevsky, [email protected]
escribió:

Parece ser solo el metadata.name del nodo para el pod ds ...
extraño. Aquí está el pod yaml:

apiVersion: v1kind: Podmetadata:
anotaciones:
Scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: cilium-
etiquetas:
controlador-revisión-hash: 6c94db8bb8
k8s-app: cilium
pod-template-generation: "1"
managedFields:
# basura de campos gestionados
nombre: cilium-d5n4f
espacio de nombres: kube-system
propietarioReferencias:

• apiVersion: aplicaciones / v1
  blockOwnerDeletion: verdadero
  controlador: verdadero
  tipo: DaemonSet
  nombre: cilio
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: / api / v1 / namespaces / kube-system / pods / cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  afinidad:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - clave: metadata.name
  operador: En
  valores:
  - us-central1-dilyevsky-master-qmwnl
  contenedores:
• argumentos:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    mando:
  
  
  • agente de cilio
    
    env:
  
  
  • nombre: K8S_NODE_NAME
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: spec.nodeName
  
  
  • nombre: CILIUM_K8S_NAMESPACE
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: metadata.namespace
  
  
  • nombre: CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: franela-dispositivo-maestro
    
    nombre: cilium-config
    
    opcional: verdadero
  
  
  • nombre: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: franela-desinstalar-al-salir
    
    nombre: cilium-config
    
    opcional: verdadero
  
  
  • nombre: CILIUM_CLUSTERMESH_CONFIG
    
    valor: / var / lib / cilium / clustermesh /
  
  
  • nombre: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: modo de encadenamiento cni
    
    nombre: cilium-config
    
    opcional: verdadero
  
  
  • nombre: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: custom-cni-conf
    
    nombre: cilium-config
    
    opcional: verdadero
    
    imagen: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    ciclo vital:
    
    postStart:
    
    ejecutivo:
    
    mando:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = falso
      
      
      preStop:
      
      
      ejecutivo:
      
      
      mando:
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe:
      
      
      ejecutivo:
      
      
      mando:
      
      
      
      
      
      
      
      • cilio
      
      
      
      
      • estado
      
      
      
      
      • --breve
        
        
        
        FailThreshold: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        nombre: cilio-agente
        
        
        
        readinessProbe:
        
        
        
        ejecutivo:
        
        
        
        mando:
      
      
      
      
      • cilio
      
      
      
      
      • estado
      
      
      
      
      • --breve
        
        
        
        falla Umbral: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        recursos: {}
        
        
        
        securityContext:
        
        
        
        capacidades:
        
        
        
        añadir:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        privilegiado: verdadero
        
        
        
        terminationMessagePath: / dev / termination-log
        
        
        
        terminationMessagePolicy: Archivo
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nombre: cilium-run
  
  
  • mountPath: / host / opt / cni / bin
    
    nombre: cni-path
  
  
  • mountPath: /host/etc/cni/net.d
    
    nombre: etc-cni-netd
  
  
  • mountPath: / var / lib / cilium / clustermesh
    
    nombre: clustermesh-secrets
    
    readOnly: verdadero
  
  
  • mountPath: / tmp / cilium / config-map
    
    nombre: cilium-config-path
    
    readOnly: verdadero
  
  
  • mountPath: / lib / modules
    
    nombre: lib-modules
    
    readOnly: verdadero
  
  
  • mountPath: /run/xtables.lock
    
    nombre: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nombre: cilium-token-j74lr
    
    readOnly: verdadero
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: verdadero
    
    hostNetwork: verdadero
    
    initContainers:
  
  
• mando:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • nombre: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: estado de cilio limpio
    
    nombre: cilium-config
    
    opcional: verdadero
  
  
  • nombre: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: clean-cilium-bpf-state
    
    nombre: cilium-config
    
    opcional: verdadero
  
  
  • nombre: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    clave: espera-bpf-mount
    
    nombre: cilium-config
    
    opcional: verdadero
    
    imagen: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    nombre: estado de cilio limpio
    
    recursos: {}
    
    securityContext:
    
    capacidades:
    
    añadir:
    
    
    
    
    
    • NET_ADMIN
      
      
      privilegiado: verdadero
      
      
      terminationMessagePath: / dev / termination-log
      
      
      terminationMessagePolicy: Archivo
      
      
      volumeMounts:
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nombre: cilium-run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nombre: cilium-token-j74lr
    
    readOnly: verdadero
    
    prioridad: 2000001000
    
    PriorityClassName: sistema-nodo-crítico
    
    reiniciarPolítica: Siempre
    
    SchedulerName: planificador predeterminado
    
    securityContext: {}
    
    serviceAccount: cilium
    
    serviceAccountName: cilium
    
    terminationGracePeriodSeconds: 1
    
    tolerancias:
  
  
• operador: existe
• efecto: NoExecute
  clave: node.kubernetes.io/not-ready
  operador: existe
• efecto: NoExecute
  clave: node.kubernetes.io/unreachable
  operador: existe
• efecto: NoSchedule
  clave: node.kubernetes.io/disk-pressure
  operador: existe
• efecto: NoSchedule
  clave: node.kubernetes.io/memory-pressure
  operador: existe
• efecto: NoSchedule
  clave: node.kubernetes.io/pid-pressure
  operador: existe
• efecto: NoSchedule
  clave: node.kubernetes.io/unschedulable
  operador: existe
• efecto: NoSchedule
  clave: node.kubernetes.io/network-unavailable
  operador: existe
  volúmenes:
• hostPath:
  ruta: / var / run / cilium
  tipo: DirectoryOrCreate
  nombre: cilium-run
• hostPath:
  ruta: / opt / cni / bin
  tipo: DirectoryOrCreate
  nombre: cni-path
• hostPath:
  ruta: /etc/cni/net.d
  tipo: DirectoryOrCreate
  nombre: etc-cni-netd
• hostPath:
  ruta: / lib / modules
  tipo: ""
  nombre: lib-modules
• hostPath:
  ruta: /run/xtables.lock
  tipo: FileOrCreate
  nombre: xtables-lock
• nombre: clustermesh-secrets
  secreto:
  defaultMode: 420
  opcional: verdadero
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  nombre: cilium-config
  nombre: cilium-config-path
• nombre: cilium-token-j74lr
  secreto:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  condiciones:
• lastProbeTime: nulo
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  mensaje: '0/6 nodos están disponibles: 5 nodos no coinciden con el selector de nodos'.
  motivo: no programable
  estado: "Falso"
  tipo: PodScheduled
  fase: Pendiente
  qosClass: BestEffort

La forma en que reproduzco esto es girando un nuevo clúster con 2 maestros y
3 nodos de trabajo (usando Cluster API) y aplicando Cilium 1.7.6:

--- # Fuente: cilium / charts / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nombre: cilio
espacio de nombres: kube-system
--- # Fuente: cilium / charts / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nombre: cilio-operador
espacio de nombres: kube-system
--- # Fuente: cilium / charts / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
nombre: cilium-config
espacio de nombres: kube-systemdata:

# El modo de asignación de identidad selecciona cómo se comparten las identidades entre el cilio
# nodos configurando cómo se almacenan. Las opciones son "crd" o "kvstore".
# - "crd" almacena identidades en kubernetes como CRD (definición de recurso personalizado).
# Estos se pueden consultar con:
# kubectl obtener ciliumid
# - "kvstore" almacena identidades en un kvstore, etcd o cónsul, es decir
# configurado a continuación. Las versiones de Cilium anteriores a 1.6 solo admitían kvstore
# backend. Las actualizaciones de estas versiones anteriores de cilium deberían seguir usando
# el kvstore comentando el modo de asignación de identidad a continuación, o
# configurándolo en "kvstore".
modo de asignación de identidad: crd

# Si desea ejecutar cilium en modo de depuración, cambie este valor a verdadero
debug: "falso"

# Habilite el direccionamiento IPv4. Si está habilitado, a todos los puntos finales se les asigna un IPv4
# habla a.
enable-ipv4: "verdadero"

# Habilite el direccionamiento IPv6. Si está habilitado, a todos los puntos finales se les asigna un IPv6
# habla a.
enable-ipv6: "falso"

# Si desea que el monitor de cilio agregue el seguimiento de los paquetes, establezca este nivel
# a "bajo", "medio" o "máximo". Cuanto mayor sea el nivel, menos paquetes
# que se verá en la salida del monitor.
monitorización-agregación: media

# El intervalo de agregación del monitor rige el tiempo típico entre monitorización
# eventos de notificación para cada conexión permitida.
#
# Solo es efectivo cuando la agregación de monitores se establece en "media" o superior.
intervalo de agregación del monitor: 5 s

# Los indicadores de agregación de monitores determinan qué indicadores de TCP
# primera observación, hace que se generen notificaciones del monitor.
#
# Solo es efectivo cuando la agregación de monitores se establece en "media" o superior.
indicadores-de-agregación-monitor: todos

# ct-global-max-entries- * especifica el número máximo de conexiones
# admitido en todos los puntos finales, dividido por protocolo: tcp u otro. Un par
# de mapas usa estos valores para conexiones IPv4 y otro par de mapas
# use estos valores para conexiones IPv6.
#
# Si estos valores se modifican, durante el próximo inicio de Cilium el
# el seguimiento de las conexiones en curso puede verse interrumpido. Esto puede conducir a breves
# caídas de políticas o cambios en las decisiones de equilibrio de carga para una conexión.
#
# Para usuarios que actualizan desde Cilium 1.2 o anterior, para minimizar las interrupciones
# durante el proceso de actualización, comente estas opciones.
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max especificó el número máximo de entradas en el punto final
# mapa de políticas (por punto final)
bpf-policy-map-max: "16384"

# La preasignación de entradas de mapa permite reducir la latencia por paquete, en
# el gasto de la asignación de memoria inicial para las entradas en los mapas. los
# El valor predeterminado a continuación minimizará el uso de memoria en la instalación predeterminada;
# usuarios que son sensibles a la latencia pueden considerar establecer esto en "verdadero".
#
# Esta opción se introdujo en Cilium 1.4. Cilium 1.3 y anteriores ignoran
# esta opción y se comporta como si estuviera configurada como "verdadera".
#
# Si se modifica este valor, durante el próximo inicio de Cilium, la restauración
Es posible que se interrumpa el número de puntos finales existentes y el seguimiento de las conexiones en curso.
# Esto puede dar lugar a caídas de políticas o un cambio en las decisiones de equilibrio de carga para un
# conexión durante algún tiempo. Es posible que sea necesario volver a crear los puntos finales para restaurarlos
# conectividad.
#
# Si esta opción se establece en "falso" durante una actualización de 1.3 o anterior a
# 1.4 o posterior, entonces puede causar interrupciones únicas durante la actualización.
preallocate-bpf-maps: "falso"

# Expresiones regulares que coinciden con Istio sidecar istio-proxy compatibles
# nombres de imágenes de contenedores
sidecar-istio-proxy-image: "cilium / istio_proxy"

# Modo de encapsulación para comunicación entre nodos
# Valores posibles:
# - discapacitado
# - vxlan (predeterminado)
# - geneve
túnel: vxlan

# Nombre del clúster. Solo es relevante cuando se construye una malla de clústeres.
nombre-clúster: predeterminado

# DNS Polling emite periódicamente una búsqueda de DNS para cada matchName de
# agente de cilio. El resultado se utiliza para regenerar la política de punto final.
# Las búsquedas de DNS se repiten con un intervalo de 5 segundos y están hechas para
# Direcciones A (IPv4) y AAAA (IPv6). Si falla una búsqueda, la IP más reciente
En su lugar, se utilizan # datos. Un cambio de IP desencadenará una regeneración del Cilium
# política para cada punto final e incrementar la política de agente por cilio
# revisión del repositorio.
#
# Esta opción está deshabilitada por defecto a partir de la versión 1.4.x a favor
N.º de una implementación basada en proxy DNS más potente, consulte [0] para obtener más detalles.
# Habilite esta opción si desea usar políticas FQDN pero no desea usar
# el proxy DNS.
#
# Para facilitar la actualización, los usuarios pueden optar por establecer esta opción en "verdadero".
# De lo contrario, consulte la Guía de actualización [1] que explica cómo
# preparar reglas de política para la actualización.
#
# [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: "falso"

# wait-bpf-mount hace que el contenedor init espere hasta que se monte el sistema de archivos bpf
wait-bpf-mount: "falso"

mascarada: "verdadero"
enable-xt-socket-fallback: "verdadero"
install-iptables-rules: "verdadero"
rutas-de-nodo-directo-automático: "falso"
kube-proxy-replacement: "sonda"
enable-host-reachable-services: "falso"
enable-external-ips: "falso"
enable-node-port: "falso"
protección de enlace de puerto de nodo: "verdadero"
enable-auto-protect-node-port-range: "verdadero"
enable-endpoint-health-check: "verdadero"
enable-well-known-identities: "false"
enable-remote-node-identity: "verdadero"
--- # Fuente: cilium / charts / agent / templates / clusterrole.yamlapi Versión: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
nombre: ciliumrules:

• apiGroups:
  
  
  
  • networking.k8s.io
    
    recursos:
  
  
  • políticas de red
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    recursos:
  
  
  • rebanadas
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
• apiGroups:
  
  
  
  • ""
    
    recursos:
  
  
  • espacios de nombres
  
  
  • servicios
  
  
  • nodos
  
  
  • puntos finales
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
• apiGroups:
  
  
  
  • ""
    
    recursos:
  
  
  • vainas
  
  
  • nodos
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
  • actualizar
  
  
• apiGroups:
  
  
  
  • ""
    
    recursos:
  
  
  • nodos
  
  
  • nodos / estado
    
    verbos:
  
  
  • parche
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    recursos:
  
  
  • definiciones de recursos personalizados
    
    verbos:
  
  
  • crear
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
  • actualizar
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    recursos:
  
  
  • políticas de red de cilios
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • ciliados
  
  
  • ciliumnodes / estado
  
  
  • cilioidentidades
  
  
  • ciliumidentities / estado
    
    verbos:
  
  
  • '*'
    
    --- # Fuente: cilium / charts / operator / templates / clusterrole.yamlapi Versión: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    nombre: cilium-operator reglas:
  
  
• apiGroups:
  
  
  
  • ""
    
    recursos:
    
    # para eliminar automáticamente los pods de dns de [core | kube] para que empiecen a ser
    
    # gestionado por Cilium
  
  
  • vainas
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
  • Eliminar
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    recursos:
  
  
  • rebanadas
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
• apiGroups:
  
  
  
  • ""
    
    recursos:
    
    # para leer automáticamente desde k8s e importar el CIDR de la vaina del nodo a cilium's
    
    # etcd para que todos los nodos sepan cómo llegar a otro pod que se ejecuta en una
    
    # nodo.
  
  
  • nodos
    
    # para realizar la traducción de un CNP que contiene ToGroup a sus puntos finales
  
  
  • servicios
  
  
  • puntos finales
    
    # para comprobar la conectividad de un servidor
  
  
  • espacios de nombres
    
    verbos:
  
  
  • obtener
  
  
  • lista
  
  
  • reloj
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    recursos:
  
  
  • políticas de red de cilios
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • ciliados
  
  
  • ciliumnodes / estado
  
  
  • cilioidentidades
  
  
  • ciliumidentities / estado
    
    verbos:
  
  
  • '*'
    
    --- # Fuente: cilium / charts / agent / templates / clusterrolebinding.yamlapi Versión: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    nombre: ciliumroleRef:
    
    apiGroup: rbac.authorization.k8s.io
    
    tipo: ClusterRole
    
    nombre: ciliumsubjects:
  
  
• tipo: ServiceAccount
  nombre: cilio
  espacio de nombres: kube-system
  --- # Fuente: cilium / charts / operator / templates / clusterrolebinding.yamlapi Versión: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  nombre: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  tipo: ClusterRole
  nombre: cilium-operatorubjects:
• tipo: ServiceAccount
  nombre: cilio-operador
  espacio de nombres: kube-system
  --- # Fuente: cilium / charts / agent / templates / daemonset.yamlapi Versión: apps / v1kind: DaemonSetmetadata:
  etiquetas:
  k8s-app: cilium
  nombre: cilio
  espacio de nombres: kube-systemspec:
  selector:
  matchLabels:
  k8s-app: cilium
  modelo:
  metadatos:
  anotaciones:
  # Esta anotación más la tolerancia CriticalAddonsOnly hace
  # cilio para ser una vaina crítica en el grupo, lo que asegura el cilio
  # obtiene programación prioritaria.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  Scheduler.alpha.kubernetes.io/critical-pod: ""
  etiquetas:
  k8s-app: cilium
  Especificaciones:
  contenedores:
  
  
  
  • argumentos:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      mando:
    
    
    
    • agente de cilio
      
      
      livenessProbe:
      
      
      ejecutivo:
      
      
      mando:
      
      
      
      
      
      
      
      • cilio
      
      
      
      
      • estado
      
      
      
      
      • --breve
        
        
        
        FailThreshold: 10
        
        
        
        # El retraso inicial para la sonda de actividad es intencionalmente grande para
        
        
        
        # evite un ciclo interminable de apagado y reinicio si en el caso de que el
        
        
        
        # bootstrapping tarda más de lo esperado.
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        readinessProbe:
        
        
        
        ejecutivo:
        
        
        
        mando:
      
      
      
      
      • cilio
      
      
      
      
      • estado
      
      
      
      
      • --breve
        
        
        
        falla Umbral: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • nombre: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nombre: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nombre: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: franela-dispositivo-maestro
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: franela-desinstalar-al-salir
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_CLUSTERMESH_CONFIG
      
      
      valor: / var / lib / cilium / clustermesh /
    
    
    
    • nombre: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: modo de encadenamiento cni
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: custom-cni-conf
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
      
      
      imagen: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      ciclo vital:
      
      
      postStart:
      
      
      ejecutivo:
      
      
      mando:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        ejecutivo:
        
        
        
        mando:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        nombre: cilio-agente
        
        
        
        securityContext:
        
        
        
        capacidades:
        
        
        
        añadir:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          privilegiado: verdadero
          
          
          
          
          volumeMounts:
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nombre: cilium-run
    
    
    
    • mountPath: / host / opt / cni / bin
      
      
      nombre: cni-path
    
    
    
    • mountPath: /host/etc/cni/net.d
      
      
      nombre: etc-cni-netd
    
    
    
    • mountPath: / var / lib / cilium / clustermesh
      
      
      nombre: clustermesh-secrets
      
      
      readOnly: verdadero
    
    
    
    • mountPath: / tmp / cilium / config-map
      
      
      nombre: cilium-config-path
      
      
      readOnly: verdadero
      
      
      # Necesario para poder cargar módulos del kernel
    
    
    
    • mountPath: / lib / modules
      
      
      nombre: lib-modules
      
      
      readOnly: verdadero
    
    
    
    • mountPath: /run/xtables.lock
      
      
      nombre: xtables-lock
      
      
      hostNetwork: verdadero
      
      
      initContainers:
    
    
    
  
  
  • mando:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • nombre: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: estado de cilio limpio
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: clean-cilium-bpf-state
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: espera-bpf-mount
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
      
      
      imagen: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nombre: estado de cilio limpio
      
      
      securityContext:
      
      
      capacidades:
      
      
      añadir:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        privilegiado: verdadero
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nombre: cilium-run
      
      
      reiniciarPolítica: Siempre
      
      
      PriorityClassName: sistema-nodo-crítico
      
      
      serviceAccount: cilium
      
      
      serviceAccountName: cilium
      
      
      terminationGracePeriodSeconds: 1
      
      
      tolerancias:
    
    
    
  
  
  • operador: existe
    
    volúmenes:
    
    # Para mantener el estado entre reinicios / actualizaciones
  
  
  • hostPath:
    
    ruta: / var / run / cilium
    
    tipo: DirectoryOrCreate
    
    nombre: cilium-run
    
    # Para instalar el complemento cilium cni en el host
  
  
  • hostPath:
    
    ruta: / opt / cni / bin
    
    tipo: DirectoryOrCreate
    
    nombre: cni-path
    
    # Para instalar la configuración cni de cilium en el host
  
  
  • hostPath:
    
    ruta: /etc/cni/net.d
    
    tipo: DirectoryOrCreate
    
    nombre: etc-cni-netd
    
    # Para poder cargar módulos del kernel
  
  
  • hostPath:
    
    ruta: / lib / modules
    
    nombre: lib-modules
    
    # Para acceder a iptables al mismo tiempo que otros procesos (por ejemplo, kube-proxy)
  
  
  • hostPath:
    
    ruta: /run/xtables.lock
    
    tipo: FileOrCreate
    
    nombre: xtables-lock
    
    # Para leer la configuración de clustermesh
  
  
  • nombre: clustermesh-secrets
    
    secreto:
    
    defaultMode: 420
    
    opcional: verdadero
    
    secretName: cilium-clustermesh
    
    # Para leer la configuración del mapa de configuración
  
  
  • configMap:
    
    nombre: cilium-config
    
    nombre: cilium-config-path
    
    updateStrategy:
    
    rollingUpdate:
    
    maxUnavailable: 2
    
    tipo: RollingUpdate
    
    --- # Fuente: cilium / charts / operator / templates / deployment.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    etiquetas:
    
    io.cilium / app: operador
    
    nombre: cilio-operador
    
    nombre: cilio-operador
    
    espacio de nombres: kube-systemspec:
    
    réplicas: 1
    
    selector:
    
    matchLabels:
    
    io.cilium / app: operador
    
    nombre: cilio-operador
    
    estrategia:
    
    rollingUpdate:
    
    maxSurge: 1
    
    maxUnavailable: 1
    
    tipo: RollingUpdate
    
    modelo:
    
    metadatos:
    
    anotaciones:
    
    etiquetas:
    
    io.cilium / app: operador
    
    nombre: cilio-operador
    
    Especificaciones:
    
    contenedores:
  
  
  • argumentos:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • - modo-asignación-identidad = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-nodes = verdadero
      
      
      mando:
    
    
    
    • operador de cilio
      
      
      env:
    
    
    
    • nombre: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nombre: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nombre: CILIUM_DEBUG
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: depurar
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: nombre-clúster
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: cluster-id
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: ipam
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: deshabilitar-endpoint-crd
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: kvstore
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: kvstore-opt
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
    
    
    
    • nombre: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      clave: AWS_ACCESS_KEY_ID
      
      
      nombre: cilium-aws
      
      
      opcional: verdadero
    
    
    
    • nombre: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      clave: AWS_SECRET_ACCESS_KEY
      
      
      nombre: cilium-aws
      
      
      opcional: verdadero
    
    
    
    • nombre: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      clave: AWS_DEFAULT_REGION
      
      
      nombre: cilium-aws
      
      
      opcional: verdadero
    
    
    
    • nombre: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      clave: modo de asignación de identidad
      
      
      nombre: cilium-config
      
      
      opcional: verdadero
      
      
      imagen: "docker.io/cilium/ operator: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nombre: cilio-operador
      
      
      livenessProbe:
      
      
      httpGet:
      
      
      anfitrión: '127.0.0.1'
      
      
      ruta: / healthz
      
      
      puerto: 9234
      
      
      esquema: HTTP
      
      
      initialDelaySeconds: 60
      
      
      periodSeconds: 10
      
      
      timeoutSeconds: 3
      
      
      hostNetwork: verdadero
      
      
      reiniciarPolítica: Siempre
      
      
      serviceAccount: cilium-operator
      
      
      serviceAccountName: cilium-operator
    
    
    
  
  

-
Está recibiendo esto porque fue asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

¿Podría intentar aumentar el nivel de registro y usar grep para filtrar el nodo?
o la vaina?

El jueves 9 de julio de 2020 a las 7:55 pm dilyevsky, [email protected]
escribió:

Aquí está el registro del programador:

I0709 23: 08: 22.056081 1 registry.go: 150] Registro de función de prioridad y predicado EvenPodsSpread
I0709 23: 08: 23.137451 1 serve.go: 313] Certificado en memoria autofirmado generado
W0709 23: 08: 33.843509 1 authentication.go: 297] Error al buscar la configuración de autenticación en el clúster: etcdserver: se agotó el tiempo de espera de la solicitud
W0709 23: 08: 33.843671 1 authentication.go: 298] Continuando sin configuración de autenticación. Esto puede tratar todas las solicitudes como anónimas.
W0709 23: 08: 33.843710 1 authentication.go: 299] Para requerir que la búsqueda de configuración de autenticación sea exitosa, establezca --authentication-tolerate-lookup-failure = false
I0709 23: 08: 33.911805 1 registry.go: 150] Registro de función de prioridad y predicado EvenPodsSpread
I0709 23: 08: 33.911989 1 registry.go: 150] Registro de función de prioridad y predicado EvenPodsSpread
W0709 23: 08: 33.917999 1 autorización.go: 47] La ​​autorización está deshabilitada
W0709 23: 08: 33.918162 1 authentication.go: 40] La autenticación está deshabilitada
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Sirviendo healthz de forma insegura en [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] Iniciando client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.926013 1 shared_informer.go: 223] Esperando que las cachés se sincronicen para client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Sirviendo de forma segura en 127.0.0.1:10259
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] Iniciando DynamicServingCertificateController
I0709 23: 08: 34.026382 1 shared_informer.go: 230] Los cachés se sincronizan para client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 34.036998 1 leaderelection.go: 242] intentando adquirir el arrendamiento líder kube-system / kube-Scheduler ...
I0709 23: 08: 50.597201 1 leaderelection.go: 252] arrendamiento adquirido con éxito kube-system / kube-planificador
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd ya está presente en la cola activa
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 ya está presente en la cola de retroceso
E0709 23: 12: 58.099432 1 leaderelection.go: 320] error al recuperar el bloqueo de recursos kube-system / kube-Scheduler: etcdserver: líder cambiado

Después de reiniciar los pods del programador, el pod pendiente se programa inmediatamente.

-
Está recibiendo esto porque fue asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Estos son eventos:
`` Eventos:
Escriba el motivo de la antigüedad del mensaje
---- ------ ---- ---- -------
Advertencia fallidaplanificador predeterminado 0/6 nodos están disponibles: 5 nodos no coinciden con el selector de nodos.
Advertencia fallidaplanificador predeterminado 0/6 nodos están disponibles: 5 nodos no coinciden con el selector de nodos.

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

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

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

Intentaré aumentar el nivel de registro del programador ahora ...

Su pod yaml en realidad no tiene tolerancia node-role.kubernetes.io/master . Entonces no debería haber sido programado en el maestro.

¡Hola! Nos enfrentamos al mismo problema. Sin embargo, vemos el mismo problema con las implementaciones, donde usamos antiafinidad para asegurarnos de que se programe un pod en cada nodo o un selector de pod que se dirija al nodo específico.
Simplemente crear un pod con un selector de nodo configurado para que coincida con el nombre de host del nodo que falla fue suficiente para hacer que la programación fallara. Decía que 5 nodos no coincidían con el selector, pero nada sobre el sexto. Reiniciar el programador resolvió el problema. Parece que algo se almacena en caché sobre ese nodo e impide la programación en el nodo.
Como dijeron otras personas antes, no tenemos nada en el registro sobre la falla.

Tratamos la implementación fallida al mínimo (habíamos eliminado la mancha en el maestro que falla):

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

Estábamos teniendo el mismo problema cuando el maestro tenía una mancha y el despliegue una tolerancia para la mancha. Por lo tanto, no parece estar relacionado específicamente con conjuntos de demonios, tolerancias o afinidad / antiafinidad. Cuando la falla comienza a ocurrir, no se puede programar nada que se dirija al nodo específico. Vemos el problema en 1.18.2 hasta 1.18.5 (no lo intenté con 1.18.0 o .1)

La simple creación de un pod con un selector de nodo configurado para que coincida con el nombre de host del nodo que falla fue suficiente para hacer que la programación fallara

¿Podría aclarar si comenzó a fallar después de que creó dicho pod o antes? Supongo que este nodo no tenía una mancha que la vaina no tolerara.

@nodo va a ayudar a reproducir. ¿Podrías mirar el código de NodeSelector? Es posible que deba agregar líneas de registro adicionales durante la prueba. También puede imprimir el caché.

• Obtenga el PID del programador de kube: $ pidof kube-scheduler
• Volcado de la cola de activación: $ sudo kill -SIGUSR2 <pid> . Tenga en cuenta que esto no matará el proceso del planificador.
• Luego, en el registro del programador, busque las cadenas "Volcado de NodeInfo en caché", "Volcado de cola de programación" y "Se inició el comparador de caché".

/ prioridad crítica-urgente

/ desasignar

Ya estábamos viendo algunos daemonset y la implementación atascados en "Pendiente" antes de intentar implementar esta implementación de prueba, por lo que ya estaba fallando. y las manchas se habían eliminado del nodo.
En este momento, perdimos el entorno donde estaba sucediendo esto porque tuvimos que reiniciar los nodos para que el problema ya no sea visible. Tan pronto como nos reproduzcamos, intentaremos volver con más información.

Por favor, hazlo. Intenté reproducir esto en el pasado sin éxito. Me interesa más la primera instancia de fracaso. Todavía podría estar relacionado con las corrupciones.

Hemos reproducido el problema. Ejecuté el comando que pediste, aquí está la información:

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: 

Desafortunadamente eso no parece ayudar

Vaciar la caché es para depurar, no cambiará nada. ¿Podría incluir el vertedero?

Además, suponiendo que este fue el primer error, ¿podría incluir el pod yaml y el nodo?

eso es prácticamente todo lo que se arrojó, simplemente eliminé los otros nodos. Este no fue el primer error, pero puede ver el pod de coredns en el volcado, ese fue el primero. No estoy seguro de qué más estás pidiendo en el basurero.
Voy a buscar los ñames

Gracias, no me di cuenta de que había recortado el nodo y la vaina correspondientes.

Sin embargo, ¿podría incluir los pods programados para ese nodo? Por si acaso hay un error en los cálculos de uso de recursos.

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

Ese AllowedPodNumber: 0 parece extraño.

Aquí están los otros pods en ese nodo:
` 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:

Todos los nodos tienen allowPodNumber establecido en 0 en los recursos solicitados en el volcado, pero los otros nodos son programables

El nodo 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

y la vaina:

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

Muchas gracias por toda la información. @nodo, ¿puedes tomarlo?

También estamos probando con https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc ahora, para obtener más información

/ayuda

@maelk no dude en tomar esto y enviar un PR si encuentra el error. Es probable que las líneas de registro que agregó sean útiles. De lo contrario, me estoy abriendo a los contribuyentes.

@alculquicondor :
Esta solicitud se ha marcado como que necesita ayuda de un colaborador.

Asegúrese de que la solicitud cumpla con los requisitos enumerados aquí .

Si esta solicitud ya no cumple con estos requisitos, la etiqueta se puede quitar
comentando con el comando /remove-help .

/asignar

@maelk ¿Hay algo específico sobre el momento en que se produce este problema por primera vez? Por ejemplo, ¿sucede justo después de que se inicia el nodo?

No, hay bastantes pods que se programan allí y funcionan bien. Pero una vez que ocurre el problema, ya no se puede programar.

Reduciendo la prioridad hasta que tengamos un caso reproducible.

Pudimos reproducir el error con un programador que tenía las entradas de registro adicionales. Lo que vemos es que uno de los maestros desaparece por completo de la lista de nodos por los que se itera. Podemos ver que el proceso comienza con los 6 nodos (de la instantánea):

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

pero después, podemos ver que itera solo sobre 5 nodos, y luego obtenemos:

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

Entonces uno de los nodos se elimina de la lista de nodos potenciales. Desafortunadamente, no teníamos suficientes registros al comienzo del proceso, pero intentaremos obtener más.

Referencias de código por línea de registro:

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

@maelk
¿Viste alguna línea para %v/%v on node %v, too many nodes fit ?

De lo contrario, @pancernik , workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) ?

No, ese registro no apareció. También creo que podría ser que tengamos un problema con la paralelización o que el nodo se haya filtrado antes. Si estaba fallando con un error aquí: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464 sería visible en los registros de depuración para agregar más entradas específicamente función y la paralelización.

¡Me acabo de dar cuenta de que un nodo está pasando por el filtrado dos veces!

Los registros son:

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

Como puede ver, el nodo worker-pool1-60846k0y-Scheduler pasa dos veces por el filtrado

No, ese registro no apareció. También creo que podría ser que tengamos un problema con la paralelización o que el nodo se haya filtrado antes. Si fallaba con un error aquí: Nordix @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464 sería visible en los registros afaik, así que intentaré agregar más entradas de depuración específicamente sobre la función y la paralelización.

Sí, un error allí se manifestaría como un Error de programación en los eventos del pod.

¡Me acabo de dar cuenta de que un nodo está pasando por el filtrado dos veces!

Honestamente, no pensaría que la paralelización tiene errores (aún vale la pena verificar), pero esto podría ser una señal de que no pudimos construir la instantánea desde el caché (como vimos en el volcado de caché, el caché es correcto), agregando un nodo dos veces. Dado que los estados son un mapa, entonces tiene sentido que solo "veamos" 5 nodos en la última línea de registro.

Este es el código (consejo de 1,18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

Intentaré agregar muchos registros en la parte de caché del programador, específicamente en torno a la adición y actualización de nodos, y alrededor de la instantánea. Sin embargo, desde la última línea de los registros, puede ver que la instantánea es realmente correcta y contiene todos los nodos, por lo que cualquier cosa que suceda parece suceder más adelante, cuando se trabaja en esa instantánea.

caché! = instantánea

La caché es el ser vivo que se actualiza a partir de los eventos. La instantánea se actualiza (desde la caché) antes de cada ciclo de programación para "bloquear" el estado. Agregamos optimizaciones para que este último proceso sea lo más rápido posible. Es posible que el error esté ahí.

¡Gracias @maelk! Esto es muy útil. Sus registros indican que (*nodeinfo.NodeInfo)(0xc000952000) está duplicado en la lista en https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361 código paralelo R441 antes de que se ejecute. De hecho, eso significaría que está duplicado antes de que se actualice la instantánea.

En realidad, eso proviene de la instantánea, que sucede antes de este mensaje de registro: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R161. Por lo tanto, parece que el contenido de la instantánea tiene la duplicación, ya que proviene de https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R436

Así es. Quiero decir que ya está duplicado antes de que finalice la actualización de la instantánea.

Así es. Quiero decir que ya está duplicado antes de que finalice la actualización de la instantánea.

No, la instantánea se actualiza al inicio del ciclo de programación. El error se produce durante la actualización de la instantánea o antes. Pero el caché es correcto, según el volcado en https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008

EDITAR: lo leí mal, no vi la palabra "termina" :)

La instantánea de actualización de optimización de relaciones públicas se realizó en 1.18: https://github.com/kubernetes/kubernetes/pull/85738 y https://github.com/kubernetes/kubernetes/pull/86919

Me pregunto si el árbol de nodos también tiene registros duplicados.

Me pregunto si el árbol de nodos también tiene registros duplicados.

@maelk, ¿ podría mostrar un volcado de la lista completa de nodos en el caché?

no agregamos / eliminamos elementos de NodeInfoList, creamos la lista completa del árbol o no, así que si hay duplicados, creo que probablemente provengan del árbol.

Solo para aclarar:
1) el clúster tiene 6 nodos (incluidos los maestros)
2) el nodo que se supone que aloja el pod no se examinó en absoluto (no hay una línea de registro que indique eso), lo que puede significar que no está en NodeInfoList en absoluto
3) NodeInfoList tiene 6 nodos, pero uno de ellos está duplicado

Me pregunto si el árbol de nodos también tiene registros duplicados.

@maelk, ¿ podría mostrar un volcado de la lista completa de nodos en el caché?

un volcado de cada árbol de nodos, lista y mapa sería genial.

Trabajaré para conseguirlos. Mientras tanto, una pequeña actualización. Podemos ver en los registros:

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

Y ese es el punto exacto en el que desaparece el nodo faltante. La última aparición en los registros es a las 13:37:24. En la siguiente programación, el nodo faltante desaparece. por lo que parece que el error está en / sigue a la actualización del node_tree. Todos los nodos pasan por esa actualización, es solo que este trabajador 608 es el último en pasar por ella.

Al descargar el caché (con SIGUSR2), los seis nodos se enumeran allí, con los pods ejecutándose en los nodos, sin duplicación ni falta de nodos.

Lo intentaremos de nuevo con una depuración adicional en torno a la funcionalidad de instantánea: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Se eliminó el nodo "worker-pool1-60846k0y-Scheduler" en el grupo "" de NodeTree

Interesante, creo que la eliminación / adición se activa mediante una llamada a updateNode. La clave de zona falta en la eliminación, pero existe en el complemento, por lo que la actualización básicamente agregó las etiquetas de zona y región.

¿Tiene otros registros del programador relacionados con este nodo?

Estamos intentando reproducir el error con el registro añadido. Volveré cuando tenga más información

Trabajaré para conseguirlos. Mientras tanto, una pequeña actualización. Podemos ver en los registros:

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

Señalaré que dicho nodo es el nodo que se repite. @maelk , ¿viste mensajes similares para otros nodos o no

sí, sucedió para todos los nodos, y se espera. la coincidencia es que este nodo en concreto es el último actualizado, y es en ese momento exacto cuando el otro nodo desaparece

¿Obtuviste registros de actualización para el nodo faltante?

¿Obtuviste registros de actualización para el nodo faltante?

lol, estaba escribiendo esta pregunta.

quizás el error es que toda la zona se elimina del árbol antes de eliminar todos los nodos.

Solo para aclarar, no estoy mirando personalmente el código, solo estoy tratando de asegurarme de que tengamos toda la información. Y creo que, con lo que tenemos ahora, deberíamos poder detectar el error. No dude en enviar PR y mucho mejor si puede proporcionar una prueba unitaria que falle.

¿Obtuviste registros de actualización para el nodo faltante?

sí, muestra que la zona está actualizada para ese nodo faltante. Hay una entrada de registro para todos los nodos.

Para ser honesto, todavía no tengo ni idea de la razón del error, pero si podemos acercarnos a averiguarlo, enviaré un PR o pruebas unitarias.

sí, muestra que la zona está actualizada para ese nodo faltante. Hay una entrada de registro para todos los nodos.

Si es así, creo que suponiendo que este "es el punto exacto en el que desaparece el nodo faltante". puede no estar correlacionado. Esperemos los nuevos registros. Sería genial si pudiera compartir todos los registros del programador que obtenga en un archivo.

Lo haré cuando nos reproduzcamos con el nuevo registro. De los existentes, podemos ver que la programación del pod inmediatamente después de esa actualización es la primera en fallar. Pero no da suficiente información para saber qué pasó en el medio, así que estad atentos ...

@maelk ¿Ha visto un mensaje que comienza con snapshot state is not consistent en los registros del programador?

¿Le sería posible proporcionar registros completos del programador?

no, ese mensaje no está presente. Podría dar un archivo de registro rayado (para evitar la repetición), pero primero esperemos hasta que tengamos la salida con más registros alrededor de la instantánea

Encontré el error. El problema es con la función nodeTree next (), que no devuelve una lista de todos los nodos en algunos casos. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

Es visible si agrega lo siguiente aquí: 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"},
},

El principal problema es que cuando agrega un nodo, los índices no están en 0 para algunas de las zonas. Para que esto suceda, debe tener al menos dos zonas, una más corta que la otra y la más larga con un índice no establecido en 0 al llamar a la siguiente función por primera vez.

La solución con la que fui es restablecer el índice antes de llamar a next () la primera vez. Abrí un PR para mostrar mi solución. Por supuesto, está en contra de la versión 1.18, ya que esto es en lo que he estado trabajando, pero es principalmente para discutir cómo solucionarlo (o tal vez arreglar la función next () en sí). Puedo abrir un PR adecuado hacia el maestro y hacer los backports si es necesario después.

Noté el mismo problema con la iteración. Pero no pude vincular eso a un duplicado en la instantánea. ¿Has logrado crear un escenario en el que eso suceda, @maelk?

sí, puedes ejecutarlo en las pruebas unitarias agregando el pequeño código que puse

Ahora estoy trabajando para agregar un caso de prueba para la instantánea, para asegurarme de que se haya probado correctamente.

felicitaciones a

Gracias a todos por depurar este notorio problema. Restablecer el índice antes de crear la lista es seguro, así que creo que deberíamos ir con eso para los parches 1.18 y 1.19, y tener una solución adecuada en la rama maestra.

El propósito de la función next cambió con la introducción de NodeInfoList, por lo que ciertamente podemos simplificarlo y quizás cambiarlo a toList , una función que crea una lista desde el árbol y simplemente desde el principio cada vez.

Ahora entiendo el problema: el cálculo de si una zona está agotada o no es incorrecto porque no considera en qué parte de cada zona comenzamos este proceso de "UpdateSnapshot". Y sí, solo sería visible con zonas irregulares.

¡Buen trabajo al detectar esto @maelk!

Creo que tenemos el mismo problema en versiones anteriores. Sin embargo, está oculto por el hecho de que hacemos un pase de árbol cada vez. Mientras que en 1.18 capturamos el resultado hasta que haya cambios en el árbol.

Ahora que la estrategia round-robin está implementada en generic_scheduler.go, podríamos estar bien con simplemente restablecer todos los contadores antes de UpdateSnapshot, como lo está haciendo su RP.

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

Solo para verificar dos veces @ ahg-g, esto debería estar bien incluso en un clúster donde se agregan / eliminan nuevos nodos todo el tiempo, ¿verdad?

¡Gracias @maelk por descubrir la causa raíz!

El propósito de la siguiente función cambió con la introducción de NodeInfoList, por lo que ciertamente podemos simplificarlo y quizás cambiarlo a toList, una función que crea una lista a partir del árbol y simplemente comienza desde el principio cada vez.

Dado que cache.nodeTree.next() solo se llama al compilar la instantánea nodeInfoList, creo que también es seguro eliminar los índices (zoneIndex y nodeIndex) de la estructura nodeTree. En su lugar, cree una función nodeIterator() simple para iterar a través de su zona / nodo de manera rotatoria.

Por cierto: hay un error tipográfico en https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090, el caso debería ser:

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

Solo para verificar dos veces @ ahg-g, esto debería estar bien incluso en un clúster donde se agregan / eliminan nuevos nodos todo el tiempo, ¿verdad?

Supongo que está hablando de la lógica en generic_scheduler.go, si es así, no importa mucho si se agregaron o eliminaron nodos, lo principal que debemos evitar es iterar sobre los nodos en el mismo orden cada vez programamos un pod, solo necesitamos una buena aproximación de iterar sobre los nodos en los pods.

Dado que cache.nodeTree.next () solo se llama al compilar la instantánea nodeInfoList, creo que también es seguro eliminar los índices (tanto zoneIndex como nodeIndex) de la estructura nodeTree. En su lugar, cree una función simple nodeIterator () para iterar a través de su zona / nodo de manera rotatoria.

sí, solo necesitamos iterar sobre todas las zonas / nodos en el mismo orden cada vez.

He actualizado el PR con una prueba unitaria para la función que actualiza la lista de instantáneas, específicamente para ese error. También puedo encargarme de refactorizar la función next () para iterar sobre las zonas y nodos sin round robin, eliminando así el problema.

Gracias, suena bien, pero aún deberíamos iterar entre zonas de la misma manera que lo hacemos ahora, es decir, por diseño.

Realmente no entiendo lo que quieres decir aquí. ¿Es así que el orden de los nodos es importante y todavía debemos ir por turnos entre zonas o podemos enumerar todos los nodos de una zona, una zona tras otra? Digamos que tiene dos zonas de dos nodos cada una, ¿en qué orden las espera, o incluso importa en absoluto?

El orden es importante, necesitamos alternar entre zonas al crear la lista. Si tiene dos zonas de dos nodos cada z1: {n11, n12} y z2: {n21, n22} , entonces la lista debería ser {n11, n21, n12, n22}

ok, gracias, lo pensaré. Mientras tanto, ¿podemos continuar con la solución rápida? por cierto, algunas pruebas fallan, pero no estoy seguro de cómo se relaciona eso con mi PR

Son copos. Envíe también un parche a la versión 1.18.

OK lo haré. Gracias

{
  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 , ¿quieres decir que esta prueba ignora el 'nodo-5'?

Encontré que después de arreglar el anexo en https://github.com/kubernetes/kubernetes/pull/93516 , el resultado de la prueba todos los nodos se pueden iterar:

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

El nodo 5, 6, 7, 8, 3 se puede iterar.

Perdóname si malinterpretas algo aquí.

sí, fue a propósito, basado en lo que había allí, pero puedo ver cómo esto puede ser críptico, así que es mejor que lo haga para que el anexo se comporte de una manera más clara. Gracias por el parche.

¿Cuánto tiempo atrás cree que estuvo presente este error? 1,17? 1,16? Acabo de ver exactamente el mismo problema en 1.17 en AWS y reiniciar el nodo no programado solucionó el problema.

@judgeaxl ¿ podría proporcionar más detalles? Líneas de registro, volcados de caché, etc. Para que podamos determinar si el problema es el mismo.

Como señalé en https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695, creo que este error estaba presente en versiones anteriores, pero mi opinión es que es transitorio.

@maelk, ¿podrías investigar?

Comparta también la distribución de nodos en las zonas.

@alculquicondor lamentablemente no puedo en este momento. Lo siento.

@alculquicondor lo siento, ya reconstruí el clúster por otras razones, pero puede haber sido un problema de configuración de red relacionado con implementaciones multi-az, y en qué subred se lanzó el nodo defectuoso, así que no me preocuparía por ahora en el contexto de este problema. Si lo vuelvo a notar, lo informaré con mejores detalles. ¡Gracias!

/ retitle Algunos nodos no se consideran en la programación cuando hay un desequilibrio de zona