Kubernetes: Alguns nós não são considerados na programação quando há desequilíbrio de zona

/ sig agendamento

Você pode fornecer o yaml completo do nó, daemonset, um pod de exemplo e o namespace que o contém conforme recuperado do servidor?

nó:
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

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

pod de exemplo (funcionando):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

pod de exemplo (sem programação):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

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

Os pods do DaemonSet são programados com um seletor nodeAffinity que corresponde apenas a um único nó, portanto, é esperada a mensagem "12 de 13 não correspondem".

Não vejo uma razão para o agendador ficar insatisfeito com a combinação pod / nó ... não há portas que possam entrar em conflito no podspec, o nó não é não programável ou contaminado e tem recursos suficientes

Ok, reiniciei todos os 3 planejadores (alterei o nível de log para 4 se pudermos ver algo interessante lá). No entanto, corrigiu o 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

agora todos os daemonsets estão provisionados corretamente. Estranho, de qualquer forma, algo errado com o programador parece

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

Vemos o mesmo problema semelhante na v1.18.3, um nó não pode ser agendado para pods de daemonset.
reiniciar o agendador ajuda.

[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 sem saber como repreduzir. Você tem os logs do programador por acaso para o pod com falha de programação?

Ok, reiniciei todos os 3 agendadores

Presumo que apenas um deles se chame default-scheduler , correto?

mudou o nível de log para 4 se pudermos ver algo interessante lá

Você pode compartilhar o que você notou?

defina loglevel como 9, mas parece que não há nada mais interessante, abaixo os logs estão em loop.

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)

sim, eu não conseguia ver nada mais do que a mesma linha

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

o estranho é que a mensagem de log está mostrando o resultado de apenas 7 nós, como o problema relatado em https://github.com/kubernetes/kubernetes/issues/91340

/ cc @damemi

@ ahg-g este se parece com o mesmo problema que relatei lá, parece que temos um plugin de filtro que nem sempre relata seu erro ou alguma outra condição que está falhando silenciosamente se eu tivesse que adivinhar

Observe que, no meu problema, reiniciar o agendador também corrigiu (conforme mencionado neste tópico também https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

O meu também era sobre um daemonset, então acho que é uma duplicata. Se for esse o caso, podemos fechar isso e continuar a discussão em https://github.com/kubernetes/kubernetes/issues/91340

De qualquer forma, o planejador precisa de uma opção de registro mais detalhado, é impossível depurar esses problemas se não houver registros sobre o que ele faz

@zetaab +1, o planejador poderia usar melhorias significativas em suas habilidades de registro atuais. Essa é uma atualização que pretendo resolver há um tempo e finalmente abri um problema para ela aqui: https://github.com/kubernetes/kubernetes/issues/91633

/atribuir

Estou investigando isso. Algumas perguntas para me ajudar a estreitar o caso. Ainda não consegui reproduzir.

• O que foi criado primeiro: o daemonset ou o nó?
• Você está usando o perfil padrão?

• Você tem extensores?

nós foram criados antes do daemonset.
suponha que usamos o perfil padrão, qual perfil você quer dizer e como verificar?
sem extensores.

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

Outra coisa que pode impactar é que o desempenho do disco não é muito bom para o etcd, pois o etcd reclama de operações lentas.

Sim, esses sinalizadores fariam com que o planejador fosse executado com o perfil padrão. Vou continuar procurando. Eu ainda não conseguia reproduzir.

Ainda nada ... Mais alguma coisa que você está usando que acha que pode ter um impacto? manchas, portas, outros recursos?

Fiz algumas tentativas relacionadas a isso. Quando o problema está ativado, os pods ainda podem ser programados para o nó (sem definição ou com o seletor "nodeName").

Se tentar usar Affinity / Antiaffinity, os pods não serão programados para o nó.

Trabalhando quando o problema está ligado:

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

Não trabalhando ao mesmo tempo:

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

Além disso, quando verificado o último, mesmo aqueles foram bastante interessantes:

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.

• O primeiro evento é quando o manifesto acaba de ser aplicado (nada feito para o nó não programável).
• O segundo e o terceiro foram quando o nó foi removido com kubectl e reiniciado.
• O quarto veio quando o nó voltou a funcionar. O nó que teve um problema era o mestre, então o nó não estava indo para lá (mas mostra que o nó não foi encontrado nos 3 eventos anteriores). O interessante com o quarto evento é que ainda há informações de um nó faltando. O evento diz que há 0/9 nós disponíveis, mas a descrição é fornecida apenas a partir de 8.

"nodeName" não é um seletor. Usar nodeName ignoraria o agendamento.

O quarto veio quando o nó voltou a funcionar. O nó que teve um problema era o mestre, então o nó não estava indo para lá (mas mostra que o nó não foi encontrado nos 3 eventos anteriores). O interessante com o quarto evento é que ainda há informações de um nó faltando. O evento diz que há 0/9 nós disponíveis, mas a descrição é fornecida apenas a partir de 8.

Você está dizendo que o motivo pelo qual o pod não deveria ter sido programado no nó ausente é porque era um mestre?

Estamos vendo 8 node(s) didn't match node selector indo para 7. Presumo que nenhum nó foi removido neste ponto, correto?

"nodeName" não é um seletor. Usar nodeName ignoraria o agendamento.

A tentativa de "NodeName" foi destacar, que o nó é utilizável e o pod chega lá se desejado. Portanto, a questão não é a incapacidade do nó de iniciar pods.

O quarto veio quando o nó voltou a funcionar. O nó que teve um problema era o mestre, então o nó não estava indo para lá (mas mostra que o nó não foi encontrado nos 3 eventos anteriores). O interessante com o quarto evento é que ainda há informações de um nó faltando. O evento diz que há 0/9 nós disponíveis, mas a descrição é fornecida apenas a partir de 8.

Você está dizendo que o motivo pelo qual o pod não deveria ter sido programado no nó ausente é porque era um mestre?

Estamos vendo 8 node(s) didn't match node selector indo para 7. Presumo que nenhum nó foi removido neste ponto, correto?

O cluster de teste tem 9 nós; 3 mestres e 6 operários. Antes de o nó não funcional ser iniciado com sucesso, os eventos contaram informações sobre todos os nós disponíveis: 0/8 nodes are available: 8 node(s) didn't match node selector. . Mas quando aquele nó que corresponderia ao seletor de nó apareceu, o evento disse 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. Explicação diz que há 8 que não são correspondentes, mas não diz nada sobre o nono (que foi reconhecido no evento anterior).

Portanto, o estado do evento:

• 1º evento: 9 nós disponíveis, o erro observado com o daemonset
• 2º e 3º eventos: 8 nós disponíveis. Aquele que não estava recebendo pod estava reiniciando
• 4º evento: 9 nós disponíveis (então o que foi iniciado foi reiniciado).

No final, o pod de teste não foi iniciado no nó correspondente por causa de manchas, mas isso é outra história (e deveria ter sido o caso já no primeiro evento).

A tentativa de "NodeName" foi destacar, que o nó é utilizável e o pod chega lá se desejado. Portanto, a questão não é a incapacidade do nó de iniciar pods.

Observe que nada protege contra o over-commit de um nó, exceto o planejador. Então isso realmente não mostra muito.

No final, o pod de teste não foi iniciado no nó correspondente por causa de manchas, mas isso é outra história (e deveria ter sido o caso já no primeiro evento).

Minha pergunta é: o 9º nó foi contaminado desde o início? Estou tentando procurar (1) etapas reproduzíveis para atingir o estado ou (2) onde o bug pode estar.

Minha pergunta é: o 9º nó foi contaminado desde o início? Estou tentando procurar (1) etapas reproduzíveis para atingir o estado ou (2) onde o bug pode estar.

Sim, a contaminação estava lá o tempo todo neste caso, pois o nó não receptor era o mestre. Mas vimos o mesmo problema em mestres e trabalhadores.

Ainda não tenho ideia de onde vem o problema, apenas que pelo menos a recriação do nó e a reinicialização do nó parecem estar corrigindo o problema. Mas essas são maneiras um pouco "difíceis" de consertar as coisas.

Longo tiro, mas se você topar com isso novamente ... você poderia verificar se há algum pod nomeado para o nó que não aparece?

Estou postando perguntas enquanto penso em possíveis cenários:

• Você tem outros nós mestres em seu cluster?
• Você tem extensores?

* Do you have other master nodes in your cluster?

Todos os clusers têm 3 mestres (então reiniciá-los é fácil)

* Do you have extenders?

Não.

Uma coisa interessante percebida hoje: eu tinha um cluster onde um mestre não estava recebendo pod do DaemonSet. Temos ChaosMonkey em uso, que encerrou um dos nós de trabalho. É interessante, isso fez com que o pod fosse para o mestre que não estava recebendo antes. Portanto, de alguma forma, a remoção de outro nó que não o problemático parecia estar corrigindo o problema naquele ponto.

Por causa dessa "correção", tenho que esperar que o problema volte a ocorrer para poder responder sobre os pods nomeados.

Estou confuso agora ... Seu daemonset tolera a contaminação para nós mestres? Em outras palavras ... o bug para você é apenas o evento de agendamento ou também o fato de que os pods deveriam ter sido agendados?

O problema é que esse nó não é encontrado pelo planejador, mesmo que haja pelo menos uma configuração de afinidade (ou antiaffinidade) correspondente.

É por isso que eu disse que o erro de contaminação é esperado e deveria estar lá já no primeiro evento (pois contaminação não faz parte dos critérios de afinidade)

Entendido. Eu estava tentando confirmar sua configuração para ter certeza de que não estou perdendo nada.

Não acho que o nó seja "invisível" pelo agendador. Dado que vemos 0/9 nodes are available , podemos concluir que o nó está de fato no cache. É mais como se o motivo não programado estivesse perdido em algum lugar, então não o incluímos no evento.

Verdadeiro, a contagem total sempre corresponde à contagem real de nós. Apenas um texto de evento mais descritivo não é fornecido em todos os nós, mas pode ser um problema separado, conforme você mencionou.

Você consegue ver os logs do agendador do kube? Algo que parece relevante?

Acho que @zetaab tentou procurar isso sem sucesso. Posso tentar quando o problema ocorrer novamente (bem como aquele pod nomeado que foi perguntado anteriormente)

Se possível, execute também 1.18.5, caso tenhamos corrigido o problema inadvertidamente.

Consigo reproduzir isso de forma confiável no meu cluster de teste se você precisar de mais registros

@dilyevsky Compartilhe as etapas de reprodução. Você pode de alguma forma identificar qual é o filtro que está falhando?

Parece ser apenas o metadata.name do nó para o pod ds ... estranho. Aqui está o 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

A maneira de reproduzir isso é gerando um novo cluster com 3 mestres e 3 nós de trabalho (usando a API de cluster) e aplicando o 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

Aqui está o log do agendador:
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

Depois de reiniciar os pods do planejador, o pod pendente é programado imediatamente.

Quais eventos de pod você recebe? Você sabe se há manchas no nó
onde não é agendado? Ele só falha para nós mestres ou qualquer
nós? Existe espaço suficiente no nó?

Em quinta-feira, 9 de julho de 2020, 19h49 dilyevsky, notificaçõ[email protected]
escrevi:

Parece ser apenas o metadata.name do nó do pod ds ...
esquisito. Aqui está o pod yaml:

apiVersion: v1kind: Podmetadata:
anotações:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: cilium-
etiquetas:
hash de revisão do controlador: 6c94db8bb8
k8s-app: cílio
geração de modelo de pod: "1"
managedFields:
# porcaria de campos gerenciados
nome: cílio-d5n4f
namespace: kube-system
proprietárioReferências:

• apiVersion: apps / v1
  blockOwnerDeletion: true
  controlador: verdadeiro
  tipo: DaemonSet
  nome: cílio
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: / api / v1 / namespaces / kube-system / pods / cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  afinidade:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - chave: metadata.name
  operador: em
  valores:
  - us-central1-dilyevsky-master-qmwnl
  recipientes:
• args:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    comando:
  
  
  • agente cílio
    
    env:
  
  
  • nome: K8S_NODE_NAME
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: spec.nodeName
  
  
  • nome: CILIUM_K8S_NAMESPACE
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: metadata.namespace
  
  
  • nome: CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: flannel-master-device
    
    nome: cilium-config
    
    opcional: verdadeiro
  
  
  • nome: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: flannel-uninstall-on-exit
    
    nome: cilium-config
    
    opcional: verdadeiro
  
  
  • nome: CILIUM_CLUSTERMESH_CONFIG
    
    valor: / var / lib / cilium / clustermesh /
  
  
  • nome: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: cni-chaining-mode
    
    nome: cilium-config
    
    opcional: verdadeiro
  
  
  • nome: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: custom-cni-conf
    
    nome: cilium-config
    
    opcional: verdadeiro
    
    imagem: docker.io/cilium/ cilium : v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    ciclo da vida:
    
    postStart:
    
    exec:
    
    comando:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = false
      
      
      preStop:
      
      
      exec:
      
      
      comando:
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe:
      
      
      exec:
      
      
      comando:
      
      
      
      
      
      
      
      • cílio
      
      
      
      
      • status
      
      
      
      
      • --breve
        
        
        
        failThreshold: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        períodoSegundos: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        nome: agente cílio
        
        
        
        readinessProbe:
        
        
        
        exec:
        
        
        
        comando:
      
      
      
      
      • cílio
      
      
      
      
      • status
      
      
      
      
      • --breve
        
        
        
        failThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        períodoSegundos: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        Recursos: {}
        
        
        
        securityContext:
        
        
        
        capacidades:
        
        
        
        adicionar:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        privilegiado: verdadeiro
        
        
        
        terminationMessagePath: / dev / termination-log
        
        
        
        terminationMessagePolicy: Arquivo
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nome: cilium-run
  
  
  • mountPath: / host / opt / cni / bin
    
    nome: cni-path
  
  
  • mountPath: /host/etc/cni/net.d
    
    nome: etc-cni-netd
  
  
  • mountPath: / var / lib / cilium / clustermesh
    
    nome: clustermesh-secrets
    
    readOnly: true
  
  
  • mountPath: / tmp / cilium / config-map
    
    nome: cilium-config-path
    
    readOnly: true
  
  
  • mountPath: / lib / modules
    
    nome: lib-modules
    
    readOnly: true
  
  
  • mountPath: /run/xtables.lock
    
    nome: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nome: cilium-token-j74lr
    
    readOnly: true
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: true
    
    hostNetwork: true
    
    initContainers:
  
  
• comando:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • nome: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: estado de cílio limpo
    
    nome: cilium-config
    
    opcional: verdadeiro
  
  
  • nome: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: clean-cilium-bpf-state
    
    nome: cilium-config
    
    opcional: verdadeiro
  
  
  • nome: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    chave: wait-bpf-mount
    
    nome: cilium-config
    
    opcional: verdadeiro
    
    imagem: docker.io/cilium/ cilium : v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    nome: estado de cílio limpo
    
    Recursos: {}
    
    securityContext:
    
    capacidades:
    
    adicionar:
    
    
    
    
    
    • NET_ADMIN
      
      
      privilegiado: verdadeiro
      
      
      terminationMessagePath: / dev / termination-log
      
      
      terminationMessagePolicy: Arquivo
      
      
      volumeMounts:
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nome: cilium-run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nome: cilium-token-j74lr
    
    readOnly: true
    
    prioridade: 2000001000
    
    priorityClassName: system-node-critical
    
    restartPolicy: Sempre
    
    schedulerName: default-scheduler
    
    securityContext: {}
    
    serviceAccount: cilium
    
    serviceAccountName: cilium
    
    terminationGracePeriodSeconds: 1
    
    tolerâncias:
  
  
• operador: existe
• efeito: NoExecute
  chave: node.kubernetes.io/not-ready
  operador: existe
• efeito: NoExecute
  chave: node.kubernetes.io/unreachable
  operador: existe
• efeito: NoSchedule
  chave: node.kubernetes.io/disk-pressure
  operador: existe
• efeito: NoSchedule
  chave: node.kubernetes.io/memory-pressure
  operador: existe
• efeito: NoSchedule
  chave: node.kubernetes.io/pid-pressure
  operador: existe
• efeito: NoSchedule
  chave: node.kubernetes.io/unschedulable
  operador: existe
• efeito: NoSchedule
  chave: node.kubernetes.io/network-unavailable
  operador: existe
  volumes:
• hostPath:
  caminho: / var / run / cilium
  tipo: DirectoryOrCreate
  nome: cilium-run
• hostPath:
  caminho: / opt / cni / bin
  tipo: DirectoryOrCreate
  nome: cni-path
• hostPath:
  caminho: /etc/cni/net.d
  tipo: DirectoryOrCreate
  nome: etc-cni-netd
• hostPath:
  caminho: / lib / modules
  tipo: ""
  nome: lib-modules
• hostPath:
  caminho: /run/xtables.lock
  tipo: FileOrCreate
  nome: xtables-lock
• nome: clustermesh-secrets
  segredo:
  defaultMode: 420
  opcional: verdadeiro
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  nome: cilium-config
  nome: cilium-config-path
• nome: cilium-token-j74lr
  segredo:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  condições:
• lastProbeTime: null
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  mensagem: '0/6 nós estão disponíveis: 5 nó (s) não combinam com o seletor de nó.'
  motivo: não programável
  status: "Falso"
  tipo: PodScheduled
  fase: pendente
  qosClass: BestEffort

A maneira de reproduzir isso é girando um novo cluster com 2 mestres e
3 nós de trabalho (usando Cluster API) e aplicando Cilium 1.7.6:

--- # Fonte: cilium / charts / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nome: cílio
namespace: kube-system
--- # Fonte: cilium / charts / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nome: operador de cílio
namespace: kube-system
--- # Fonte: cilium / charts / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
nome: cilium-config
namespace: kube-systemdata:

# O modo de alocação de identidade seleciona como as identidades são compartilhadas entre os cílios
# nós definindo como eles são armazenados. As opções são "crd" ou "kvstore".
# - "crd" armazena identidades em kubernetes como CRDs (definição de recurso personalizado).
# Eles podem ser consultados com:
# kubectl get ciliumid
# - "kvstore" armazena identidades em um kvstore, etcd ou cônsul, ou seja
# configurado abaixo. As versões do Cilium anteriores a 1.6 suportavam apenas o kvstore
# Processo interno. As atualizações dessas versões mais antigas do cílio devem continuar usando
# o kvstore comentando o modo de alocação de identidade abaixo, ou
# configurando para "kvstore".
modo de alocação de identidade: crd

# Se você deseja executar cilium no modo de depuração, altere este valor para verdadeiro
depurar: "falso"

# Ative o endereçamento IPv4. Se habilitado, todos os endpoints são alocados um IPv4
# endereço.
enable-ipv4: "true"

# Ative o endereçamento IPv6. Se habilitado, todos os endpoints são alocados em um IPv6
# endereço.
enable-ipv6: "false"

# Se você deseja que o monitor de cílio agregue rastreamento para pacotes, defina este nível
# para "baixo", "médio" ou "máximo". Quanto mais alto o nível, menos pacotes
# que será visto na saída do monitor.
monitor-agregação: meio

# O intervalo de agregação do monitor governa o tempo típico entre o monitor
# eventos de notificação para cada conexão permitida.
#
# Efetivo apenas quando a agregação do monitor é definida como "média" ou superior.
intervalo de agregação do monitor: 5s

# Os sinalizadores de agregação do monitor determinam quais sinalizadores TCP quais, no
# primeira observação, faz com que as notificações do monitor sejam geradas.
#
# Efetivo apenas quando a agregação do monitor é definida como "média" ou superior.
sinalizadores de agregação de monitor: todos

# ct-global-max-entries- * especifica o número máximo de conexões
# suportado em todos os endpoints, dividido por protocolo: tcp ou outro. Um par
# de mapas usa esses valores para conexões IPv4 e outro par de mapas
# use esses valores para conexões IPv6.
#
# Se esses valores forem modificados, durante a próxima inicialização do Cilium, o
# rastreamento de conexões em andamento pode ser interrompido. Isso pode levar a um breve
# quedas de política ou uma mudança nas decisões de balanceamento de carga para uma conexão.
#
# Para usuários atualizando do Cilium 1.2 ou anterior, para minimizar a interrupção
# durante o processo de atualização, comente essas opções.
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max especificou o número máximo de entradas no endpoint
# mapa de política (por endpoint)
bpf-policy-map-max: "16384"

# A pré-alocação de entradas de mapa permite que a latência por pacote seja reduzida, em
# a despesa de alocação de memória inicial para as entradas nos mapas. o
# valor padrão abaixo irá minimizar o uso de memória na instalação padrão;
# usuários que são sensíveis à latência podem considerar definir isso como "verdadeiro".
#
# Esta opção foi introduzida no Cilium 1.4. Cilium 1.3 e anteriores ignoram
# esta opção e se comporte como se estivesse definida como "true".
#
# Se este valor for modificado, durante a próxima inicialização do Cilium a restauração
O número de endpoints existentes e o rastreamento de conexões em andamento podem ser interrompidos.
# Isso pode levar a quedas de política ou uma mudança nas decisões de balanceamento de carga para um
# conexão por algum tempo. Os endpoints podem precisar ser recriados para restaurar
# conectividade.
#
# Se esta opção for definida como "falsa" durante uma atualização de 1.3 ou anterior para
# 1.4 ou posterior, pode causar interrupções únicas durante a atualização.
preallocate-bpf-maps: "false"

# Expressão regular que corresponde ao sidecar istio-proxy do Istio compatível
# nomes de imagem de contêiner
sidecar-istio-proxy-image: "cilium / istio_proxy"

# Modo de encapsulamento para comunicação entre nós
# Valores possíveis:
# - Desativado
# - vxlan (padrão)
# - geneve
túnel: vxlan

# Nome do cluster. Relevante apenas ao construir uma malha de clusters.
nome do cluster: padrão

# DNS Polling periodicamente emite uma busca DNS para cada matchName de
# cílio-agente. O resultado é usado para regenerar a política do terminal.
# As pesquisas DNS são repetidas com um intervalo de 5 segundos e são feitas por
Endereços # A (IPv4) e AAAA (IPv6). Se uma pesquisa falhar, o IP mais recente
# dados são usados ​​em seu lugar. Uma mudança de IP irá desencadear uma regeneração do Cilium
# política para cada ponto de extremidade e incrementar a política por agente do cílio
# revisão do repositório.
#
# Esta opção está desabilitada por padrão a partir da versão 1.4.x em favor
# de uma implementação mais poderosa baseada em proxy DNS, consulte [0] para detalhes.
# Habilite esta opção se quiser usar políticas FQDN, mas não quiser usar
# o proxy DNS.
#
# Para facilitar a atualização, os usuários podem optar por definir esta opção como "verdadeiro".
# Caso contrário, consulte o Guia de atualização [1] que explica como
# preparar regras de política para atualização.
#
# [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 faz com que o container init espere até que o sistema de arquivos bpf seja montado
wait-bpf-mount: "false"

mascarada: "verdadeiro"
enable-xt-socket-fallback: "true"
install-iptables-rules: "true"
auto-direct-node-routes: "false"
Substituição de proxy de kube: "sonda"
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"
--- # Fonte: cilium / charts / agent / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
nome: cílios:

• apiGroups:
  
  
  
  • networking.k8s.io
    
    Recursos:
  
  
  • políticas de rede
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Recursos:
  
  
  • endpointslices
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
• apiGroups:
  
  
  
  • ""
    
    Recursos:
  
  
  • namespaces
  
  
  • Serviços
  
  
  • nós
  
  
  • pontos finais
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
• apiGroups:
  
  
  
  • ""
    
    Recursos:
  
  
  • vagens
  
  
  • nós
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
  • atualizar
  
  
• apiGroups:
  
  
  
  • ""
    
    Recursos:
  
  
  • nós
  
  
  • nós / status
    
    verbos:
  
  
  • fragmento
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    Recursos:
  
  
  • definições de recursos personalizados
    
    verbos:
  
  
  • crio
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
  • atualizar
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Recursos:
  
  
  • políticas de rede ciliar
  
  
  • políticas / status da rede ciliar
  
  
  • cíliocluster alarga políticas de rede
  
  
  • clusters de cílio ampliam políticas / status de rede
  
  
  • pontos finais do cílio
  
  
  • pontos finais / status do cílio
  
  
  • cílios
  
  
  • ciliumnodes / status
  
  
  • identidades ciliares
  
  
  • identidades / status do cílio
    
    verbos:
  
  
  • '*'
    
    --- # Fonte: cilium / charts / operator / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    nome: cílio-operatorrules:
  
  
• apiGroups:
  
  
  
  • ""
    
    Recursos:
    
    # para excluir automaticamente pods dns [core | kube] para que comecem a ser
    
    # gerenciado por Cilium
  
  
  • vagens
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
  • excluir
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Recursos:
  
  
  • endpointslices
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
• apiGroups:
  
  
  
  • ""
    
    Recursos:
    
    # para ler automaticamente do k8s e importar o pod CIDR do nó para o cílio
    
    # etcd para que todos os nós saibam como alcançar outro pod rodando em um diferente
    
    # nó.
  
  
  • nós
    
    # para realizar a tradução de um CNP que contém ToGroup para seus endpoints
  
  
  • Serviços
  
  
  • pontos finais
    
    # para verificar a conectividade do apiserver
  
  
  • namespaces
    
    verbos:
  
  
  • pegue
  
  
  • Lista
  
  
  • Assistir
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Recursos:
  
  
  • políticas de rede ciliar
  
  
  • políticas / status da rede ciliar
  
  
  • cíliocluster alarga políticas de rede
  
  
  • clusters de cílio ampliam políticas / status de rede
  
  
  • pontos finais do cílio
  
  
  • pontos finais / status do cílio
  
  
  • cílios
  
  
  • ciliumnodes / status
  
  
  • identidades ciliares
  
  
  • identidades / status do cílio
    
    verbos:
  
  
  • '*'
    
    --- # Fonte: cilium / charts / agent / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    nome: ciliumroleRef:
    
    apiGroup: rbac.authorization.k8s.io
    
    tipo: ClusterRole
    
    nome: cíliosujeitos:
  
  
• tipo: ServiceAccount
  nome: cílio
  namespace: kube-system
  --- # Fonte: cilium / charts / operator / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  nome: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  tipo: ClusterRole
  nome: operadores de cílio sujeitos:
• tipo: ServiceAccount
  nome: operador de cílio
  namespace: kube-system
  --- # Fonte: cilium / charts / agent / templates / daemonset.yamlapiVersion: apps / v1kind: DaemonSetmetadata:
  etiquetas:
  k8s-app: cílio
  nome: cílio
  namespace: kube-systemspec:
  seletor:
  matchLabels:
  k8s-app: cílio
  modelo:
  metadados:
  anotações:
  # Esta anotação mais a tolerância CriticalAddonsOnly torna
  # cílio para ser um pod crítico no cluster, o que garante cílio
  # obtém agendamento prioritário.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  scheduler.alpha.kubernetes.io/critical-pod: ""
  etiquetas:
  k8s-app: cílio
  especificação:
  recipientes:
  
  
  
  • args:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      comando:
    
    
    
    • agente cílio
      
      
      livenessProbe:
      
      
      exec:
      
      
      comando:
      
      
      
      
      
      
      
      • cílio
      
      
      
      
      • status
      
      
      
      
      • --breve
        
        
        
        failThreshold: 10
        
        
        
        # O atraso inicial para a detecção de vivacidade é intencionalmente grande para
        
        
        
        # evitar um ciclo infinito de matar e reiniciar se o
        
        
        
        # a inicialização leva mais tempo do que o esperado.
        
        
        
        initialDelaySeconds: 120
        
        
        
        períodoSegundos: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        readinessProbe:
        
        
        
        exec:
        
        
        
        comando:
      
      
      
      
      • cílio
      
      
      
      
      • status
      
      
      
      
      • --breve
        
        
        
        failThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        períodoSegundos: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • nome: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nome: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nome: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: flannel-master-device
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: flannel-uninstall-on-exit
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_CLUSTERMESH_CONFIG
      
      
      valor: / var / lib / cilium / clustermesh /
    
    
    
    • nome: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: cni-chaining-mode
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: custom-cni-conf
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
      
      
      imagem: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      ciclo da vida:
      
      
      postStart:
      
      
      exec:
      
      
      comando:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        exec:
        
        
        
        comando:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        nome: agente cílio
        
        
        
        securityContext:
        
        
        
        capacidades:
        
        
        
        adicionar:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          privilegiado: verdadeiro
          
          
          
          
          volumeMounts:
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nome: cilium-run
    
    
    
    • mountPath: / host / opt / cni / bin
      
      
      nome: cni-path
    
    
    
    • mountPath: /host/etc/cni/net.d
      
      
      nome: etc-cni-netd
    
    
    
    • mountPath: / var / lib / cilium / clustermesh
      
      
      nome: clustermesh-secrets
      
      
      readOnly: true
    
    
    
    • mountPath: / tmp / cilium / config-map
      
      
      nome: cilium-config-path
      
      
      readOnly: true
      
      
      # Necessário para carregar os módulos do kernel
    
    
    
    • mountPath: / lib / modules
      
      
      nome: lib-modules
      
      
      readOnly: true
    
    
    
    • mountPath: /run/xtables.lock
      
      
      nome: xtables-lock
      
      
      hostNetwork: true
      
      
      initContainers:
    
    
    
  
  
  • comando:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • nome: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: estado de cílio limpo
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: clean-cilium-bpf-state
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: wait-bpf-mount
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
      
      
      imagem: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nome: estado de cílio limpo
      
      
      securityContext:
      
      
      capacidades:
      
      
      adicionar:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        privilegiado: verdadeiro
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nome: cilium-run
      
      
      restartPolicy: Sempre
      
      
      priorityClassName: system-node-critical
      
      
      serviceAccount: cilium
      
      
      serviceAccountName: cilium
      
      
      terminationGracePeriodSeconds: 1
      
      
      tolerâncias:
    
    
    
  
  
  • operador: existe
    
    volumes:
    
    # Para manter o estado entre reinicializações / atualizações
  
  
  • hostPath:
    
    caminho: / var / run / cilium
    
    tipo: DirectoryOrCreate
    
    nome: cilium-run
    
    # Para instalar o plugin cilium cni no host
  
  
  • hostPath:
    
    caminho: / opt / cni / bin
    
    tipo: DirectoryOrCreate
    
    nome: cni-path
    
    # Para instalar a configuração cilium cni no host
  
  
  • hostPath:
    
    caminho: /etc/cni/net.d
    
    tipo: DirectoryOrCreate
    
    nome: etc-cni-netd
    
    # Para ser capaz de carregar módulos do kernel
  
  
  • hostPath:
    
    caminho: / lib / modules
    
    nome: lib-modules
    
    # Para acessar iptables simultaneamente com outros processos (por exemplo, kube-proxy)
  
  
  • hostPath:
    
    caminho: /run/xtables.lock
    
    tipo: FileOrCreate
    
    nome: xtables-lock
    
    # Para ler a configuração do clustermesh
  
  
  • nome: clustermesh-secrets
    
    segredo:
    
    defaultMode: 420
    
    opcional: verdadeiro
    
    secretName: cilium-clustermesh
    
    # Para ler a configuração do mapa de configuração
  
  
  • configMap:
    
    nome: cilium-config
    
    nome: cilium-config-path
    
    updateStrategy:
    
    rollingUpdate:
    
    maxUnavailable: 2
    
    tipo: RollingUpdate
    
    --- # Fonte: cilium / charts / operator / templates / deployment.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    etiquetas:
    
    io.cilium / app: operator
    
    nome: operador de cílio
    
    nome: operador de cílio
    
    namespace: kube-systemspec:
    
    réplicas: 1
    
    seletor:
    
    matchLabels:
    
    io.cilium / app: operator
    
    nome: operador de cílio
    
    estratégia:
    
    rollingUpdate:
    
    maxSurge: 1
    
    maxUnavailable: 1
    
    tipo: RollingUpdate
    
    modelo:
    
    metadados:
    
    anotações:
    
    etiquetas:
    
    io.cilium / app: operator
    
    nome: operador de cílio
    
    especificação:
    
    recipientes:
  
  
  • args:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identity-alocação-modo = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-nodes = true
      
      
      comando:
    
    
    
    • operador de cílio
      
      
      env:
    
    
    
    • nome: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nome: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nome: CILIUM_DEBUG
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: debug
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: nome do cluster
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: cluster-id
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: ipam
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: disable-endpoint-crd
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: kvstore
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: kvstore-opt
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
    
    
    
    • nome: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      chave: AWS_ACCESS_KEY_ID
      
      
      nome: cílio-aws
      
      
      opcional: verdadeiro
    
    
    
    • nome: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      chave: AWS_SECRET_ACCESS_KEY
      
      
      nome: cílio-aws
      
      
      opcional: verdadeiro
    
    
    
    • nome: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      chave: AWS_DEFAULT_REGION
      
      
      nome: cílio-aws
      
      
      opcional: verdadeiro
    
    
    
    • nome: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      chave: modo de alocação de identidade
      
      
      nome: cilium-config
      
      
      opcional: verdadeiro
      
      
      imagem: "docker.io/cilium/ operator: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nome: operador de cílio
      
      
      livenessProbe:
      
      
      httpGet:
      
      
      host: '127.0.0.1'
      
      
      caminho: / healthz
      
      
      porta: 9234
      
      
      esquema: HTTP
      
      
      initialDelaySeconds: 60
      
      
      períodoSegundos: 10
      
      
      timeoutSeconds: 3
      
      
      hostNetwork: true
      
      
      restartPolicy: Sempre
      
      
      serviceAccount: cilium-operator
      
      
      serviceAccountName: cilium-operator
    
    
    
  
  

-
Você está recebendo isso porque foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

Você poderia tentar aumentar o nível de log e usar grep para filtrar o nó
ou o pod?

Em quinta-feira, 9 de julho de 2020, 19h55 dilyevsky, notificaçõ[email protected]
escrevi:

Aqui está o log do agendador:

I0709 23: 08: 22.056081 1 registry.go: 150] Registrando predicado EvenPodsSpread e função de prioridade
I0709 23: 08: 23.137451 1 serving.go: 313] Certificado autoassinado gerado na memória
W0709 23: 08: 33.843509 1 authentication.go: 297] Erro ao pesquisar a configuração de autenticação no cluster: etcdserver: a solicitação expirou
W0709 23: 08: 33.843671 1 authentication.go: 298] Continuando sem configuração de autenticação. Isso pode tratar todas as solicitações como anônimas.
W0709 23: 08: 33.843710 1 authentication.go: 299] Para exigir que a pesquisa de configuração de autenticação seja bem-sucedida, defina --authentication-tolerate-lookup-failure = false
I0709 23: 08: 33.911805 1 registry.go: 150] Registrando predicado EvenPodsSpread e função de prioridade
I0709 23: 08: 33.911989 1 registry.go: 150] Registrando predicado EvenPodsSpread e função de prioridade
W0709 23: 08: 33.917999 1 autorização.go: 47] A autorização está desativada
W0709 23: 08: 33.918162 1 authentication.go: 40] A autenticação está desativada
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Serviço de saúde de forma insegura em [::]: 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 os caches sincronizem para client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Servindo com segurança em 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] Os caches são sincronizados para client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 34.036998 1 leaderelection.go: 242] tentando adquirir a locação líder kube-system / kube-scheduler ...
I0709 23: 08: 50.597201 1 leaderelection.go: 252] adquiriu com sucesso o lease kube-system / kube-scheduler
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd já está presente na fila ativa
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 já está presente na fila de espera
E0709 23: 12: 58.099432 1 leaderelection.go: 320] erro ao recuperar bloqueio de recurso kube-system / kube-scheduler: etcdserver: líder alterado

Depois de reiniciar os pods do planejador, o pod pendente é programado imediatamente.

-
Você está recebendo isso porque foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Estes são eventos:
`` `Eventos:
Digite Razão Idade da Mensagem
---- ------ ---- ---- -------
Warning FailedSchedulingdefault-scheduler 0/6 nodes estão disponíveis: 5 node (s) não combinam com o seletor de node.
Warning FailedSchedulingdefault-scheduler 0/6 nodes estão disponíveis: 5 node (s) não combinam com o seletor de node.

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 disponível: 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

Vou tentar aumentar o nível de log do planejador agora ...

Seu pod yaml não tem realmente node-role.kubernetes.io/master tolerância. Portanto, não deveria ter sido programado no mestre.

Oi! Estamos enfrentando o mesmo problema. No entanto, vemos o mesmo problema com as implantações, em que usamos antiafinidade para garantir que um pod seja agendado em cada nó ou um seletor de pod direcionado ao nó específico.
A simples criação de um pod com um seletor de nó definido para corresponder ao nome do host do nó com falha foi suficiente para causar a falha do agendamento. Estava dizendo que 5 nós não correspondiam ao seletor, mas nada sobre o sexto. Reiniciar o agendador resolveu o problema. Parece que algo é armazenado em cache sobre esse nó e impede o agendamento no nó.
Como outras pessoas disseram antes, não temos nada no log sobre a falha.

Reduzimos a implantação com falha ao mínimo (removemos a mancha no mestre que está falhando):

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ávamos tendo o mesmo problema quando o mestre tinha uma contaminação e a implantação uma tolerância para a contaminação. Portanto, não parece relacionado a conjuntos de daemons, tolerâncias ou afinidade / antiafinidade especificamente. Quando a falha começa a acontecer, nada que vise o nó específico pode ser agendado. Vemos o problema em 1.18.2 até 1.18.5 (não tentei com 1.18.0 ou .1)

A simples criação de um pod com um seletor de nó definido para corresponder ao nome do host do nó com falha foi suficiente para causar a falha do agendamento

Você poderia esclarecer se ele começou a falhar após a criação do pod ou antes? Presumo que este nó não tenha uma contaminação que o pod não tolerasse.

@nodo vai ajudar na reprodução. Você poderia olhar o código para NodeSelector? Pode ser necessário adicionar linhas de registro extras durante o teste. Você também pode imprimir o cache.

• Obtenha o PID do programador kube: $ pidof kube-scheduler
• Despejo da fila de disparo: $ sudo kill -SIGUSR2 <pid> . Observe que isso não encerrará o processo do planejador.
• Em seguida, no log do planejador, pesquise as strings "Dump of cached NodeInfo", "Dump of scheduler queue" e "cache comparer started".

/ prioridade crítico-urgente

/ desatribuir

Já víamos alguns daemonset e implantação travados em "Pendente" antes de tentarmos implantar esta implantação de teste, portanto, ela já estava falhando. e as impurezas foram removidas do nó.
No momento, perdemos o ambiente em que isso estava acontecendo porque tivemos que reiniciar os nós para que o problema não fosse mais visível. Assim que reproduzirmos, tentaremos voltar com mais informações

Por favor, faça isso. Tentei reproduzir isso no passado, sem sucesso. Estou mais interessado na primeira falha. Pode ainda estar relacionado a manchas.

Nós reproduzimos o problema. Executei o comando que você pediu, aqui estão as informações:

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: 

Infelizmente, isso não parece ajudar

O despejo do cache é para depuração, não mudará nada. Você poderia incluir o despejo?

Além disso, presumindo que este foi o primeiro erro, você poderia incluir o pod yaml e o nó?

isso é tudo que foi despejado, apenas removi os outros nós. Este não foi o primeiro erro, mas você pode ver o pod coredns no dump, que foi o primeiro. Não tenho certeza do que mais você está pedindo no lixo.
Vou buscar os yamls

Obrigado, não percebi que você havia aparado o nó e o pod relevante.

Você poderia incluir os pods programados para esse nó? Apenas no caso de haver um bug nos cálculos de uso de recursos.

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

Esse AllowedPodNumber: 0 parece estranho.

Aqui estão os outros pods nesse nó:
` 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 os nós têm allowedPodNumber definido como 0 nos recursos solicitados no dump, mas os outros nós são programáveis

O nó 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

e o pod:

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

Muito obrigado por todas as informações. @nodo, você aguenta?

Também estamos tentando https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc agora, para obter mais informações

/Socorro

@maelk sinta-se à vontade para fazer isso e enviar um PR se encontrar o bug. As linhas de registro que você adicionou provavelmente serão úteis. Caso contrário, estou abrindo para colaboradores.

@alculquicondor :
Este pedido foi marcado como precisando da ajuda de um colaborador.

Certifique-se de que a solicitação atenda aos requisitos listados aqui .

Se esta solicitação não atender mais a esses requisitos, o rótulo pode ser removido
comentando com o comando /remove-help .

/atribuir

@maelk Existe algo específico quanto ao momento em que esse problema ocorre pela primeira vez? Por exemplo, isso acontece logo após o nó iniciar?

Não, há alguns pods que são programados lá e funcionam bem. Mas uma vez que o problema aconteça, não será mais possível agendar.

Diminuindo a prioridade até termos um caso reproduzível.

Conseguimos reproduzir o bug com um planejador que tinha as entradas de log adicionais. O que vemos é que um dos mestres desaparece completamente da lista de nós que são iterados. Podemos ver que o processo começa com os 6 nós (do instantâneo):

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

mas depois disso, podemos ver que itera apenas mais de 5 nós, e então obtemos:

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

Portanto, um dos nós é removido da lista de nós potenciais. Infelizmente, não tínhamos registros suficientes no início do processo, mas tentaremos obter mais.

Referências de código por linha de registro:

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

@maelk
Você viu alguma linha para %v/%v on node %v, too many nodes fit ?

Caso contrário, @pancernik poderia verificar se há bugs em workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) ?

Não, esse log não apareceu. Eu também acho que pode ser que tenhamos um problema com a paralelização ou que o nó tenha sido filtrado anteriormente. Se estava falhando com um erro aqui: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464 ele ficaria mais visível nos registros, então tentarei adicionar especificamente o função e paralelização.

Acabei de perceber que um nó está passando pela filtragem duas vezes!

Os registros são:

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 você pode ver, o node worker-pool1-60846k0y-scheduler passa duas vezes por filtragem

Não, esse log não apareceu. Eu também acho que pode ser que tenhamos um problema com a paralelização ou que o nó tenha sido filtrado anteriormente. Se estava falhando com um erro aqui: Nordix @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464, estaria visível nos logs afaik, então tentarei adicionar mais entradas de depuração em torno especificamente da função e da paralelização.

Sim, um erro se manifestaria como um erro de agendamento nos eventos do pod.

Acabei de perceber que um nó está passando pela filtragem duas vezes!

Sinceramente, não acho que a paralelização tenha bugs (ainda vale a pena verificar), mas isso pode ser um sinal de que falhamos em construir o instantâneo do cache (como vimos no despejo do cache, o cache está correto), adicionando um nó duas vezes. Visto que status é um mapa, faz sentido que "vejamos" apenas 5 nós na última linha do log.

Este é o código (dica de 1.18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

Tentarei adicionar muitos logs na parte do cache do agendador, especificamente em torno da adição e atualização de nós e do instantâneo. No entanto, a partir da última linha dos logs, você pode ver que o instantâneo está realmente correto e contém todos os nós, então tudo o que acontece parece acontecer mais tarde, ao trabalhar sobre esse instantâneo

cache! = instantâneo

Cache é a coisa viva que é atualizada a partir dos eventos. O instantâneo é atualizado (do cache) antes de cada ciclo de agendamento para "bloquear" o estado. Adicionamos otimizações para tornar este último processo o mais rápido possível. É possível que o bug esteja lá.

Obrigado @maelk! Isso é muito útil. Seus registros indicam que (*nodeinfo.NodeInfo)(0xc000952000) está duplicado na lista já em https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R441 antes de qualquer código paralelo ser executado. Isso realmente significaria que ele é duplicado antes da atualização do instantâneo.

Na verdade, isso vem do instantâneo, que acontece antes desta mensagem de log: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R161. Portanto, parece que o conteúdo do instantâneo tem a duplicação, já que ele vem de https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R436

Está certo. Eu quis dizer que ele já está duplicado antes da conclusão da atualização do instantâneo.

Está certo. Eu quis dizer que ele já está duplicado antes da conclusão da atualização do instantâneo.

Não, o instantâneo é atualizado no início do ciclo de agendamento. O bug ocorre durante a atualização do instantâneo ou antes disso. Mas o cache está correto, de acordo com o dump em https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008

EDIT: Eu li errado, não vi a palavra "termina" :)

O instantâneo de atualização de otimização de PR foi feito em 1.18: https://github.com/kubernetes/kubernetes/pull/85738 e https://github.com/kubernetes/kubernetes/pull/86919

Eu me pergunto se a árvore de nós também tem registros duplicados

Eu me pergunto se a árvore de nós também tem registros duplicados

@maelk você poderia mostrar um despejo da lista completa de nós no cache?

não adicionamos / removemos itens de NodeInfoList, criamos ou não a lista completa da árvore, portanto, se houver duplicatas, elas provavelmente estão vindo da árvore, eu acho.

Só para esclarecer:
1) o cluster tem 6 nós (incluindo os mestres)
2) o nó que deveria hospedar o pod não foi examinado (nenhuma linha de registro indicando isso), o que pode significar que ele não está em NodeInfoList
3) NodeInfoList tem 6 nós, mas um deles é duplicado

Eu me pergunto se a árvore de nós também tem registros duplicados

@maelk você poderia mostrar um despejo da lista completa de nós no cache?

um despejo de cada árvore de nó, lista e mapa seria ótimo.

Vou trabalhar para conseguir isso. Enquanto isso, uma pequena atualização. Podemos ver nos logs:

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

E esse é o ponto exato em que o nó ausente desaparece. A última ocorrência nos registros é às 13:37:24. No próximo agendamento, o nó ausente desaparece. então parece que o bug está em / segue a atualização de node_tree. Todos os nós passam por essa atualização, só que este trabalhador 608 é o último a passar por ela.

Ao despejar o cache (com SIGUSR2), todos os seis nós são listados lá, com os pods em execução nos nós, sem duplicação ou nós ausentes.

Faremos uma nova tentativa com a depuração adicionada em torno da funcionalidade de instantâneo: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Nó "worker-pool1-60846k0y-scheduler" removido do grupo "" de NodeTree

Interessante, acho que remover / adicionar são acionados por uma chamada updateNode. A chave de zona está faltando na remoção, mas existe na adição, então a atualização foi basicamente adicionar os rótulos de zona e região?

Você tem outros logs do planejador relacionados a este nó?

Estamos tentando reproduzir o bug com o registro adicionado. Voltarei quando tiver mais informações

Vou trabalhar para conseguir isso. Enquanto isso, uma pequena atualização. Podemos ver nos logs:

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

Vou apontar que tal nó é o nó que se repete. @maelk , você viu mensagens semelhantes para outros nós ou não viu? Como @ ahg-g, isso deve ser esperado quando um nó recebe seus rótulos de topologia pela primeira vez.

sim, isso aconteceu para todos os nós, e é esperado. a coincidência é que este nó é especificamente o último atualizado, e é nesse exato momento que o outro nó desaparece

Você obteve logs de atualização para o nó ausente?

Você obteve logs de atualização para o nó ausente?

lol, estava apenas digitando essa pergunta.

talvez o bug seja que a zona inteira seja excluída da árvore antes que todos os nós sejam removidos.

Só para esclarecer, não estou olhando pessoalmente o código, estou apenas tentando ter certeza de que temos todas as informações. E acho que, com o que temos agora, devemos ser capazes de detectar o bug. Sinta-se à vontade para enviar PRs e muito melhor se você puder fornecer um teste de unidade que falhe.

Você obteve logs de atualização para o nó ausente?

sim, mostra que a zona está atualizada para esse nó ausente. Há uma entrada de registro para todos os nós

Para ser honesto, ainda não tenho ideia do motivo do bug, mas se pudermos chegar perto de descobrir, vou enviar um PR ou testes de unidade.

sim, mostra que a zona está atualizada para esse nó ausente. Há uma entrada de registro para todos os nós

Em caso afirmativo, suponho que este "seja o ponto exato em que o nó ausente desaparece". pode não ser correlacionado. Vamos esperar pelos novos logs. Seria ótimo se você pudesse compartilhar todos os logs do planejador obtidos em um arquivo.

Farei quando reproduzirmos com o novo registro. Pelos existentes, podemos ver que a programação do pod imediatamente após essa atualização é a primeira a falhar. Mas não dá informações suficientes para saber o que aconteceu no meio, portanto, fique atento ...

@maelk Você viu uma mensagem começando com snapshot state is not consistent nos logs do planejador?

Seria possível fornecer logs completos do agendador?

não, essa mensagem não está presente. Eu poderia fornecer um arquivo de log distribuído (para evitar a repetição), mas vamos primeiro esperar até termos a saída com mais logs ao redor do instantâneo

Eu encontrei o bug. O problema é com a função nodeTree next (), que não retorna uma lista de todos os nós em alguns casos. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

É visível se você adicionar o seguinte aqui: 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"},
},

O principal problema é que quando você adiciona um nó, os índices não estão em 0 para algumas das zonas. Para que isso aconteça, você deve ter pelo menos duas zonas, uma sendo mais curta do que a outra e a mais longa tendo um índice não definido como 0 ao chamar a próxima função pela primeira vez.

A correção que usei é redefinir o índice antes de chamar next () pela primeira vez. Abri um PR para mostrar minha correção. Claro que é contra a versão 1.18, pois é nisso que estou trabalhando, mas é principalmente para discutir como consertá-lo (ou talvez consertar a própria função next ()). Posso abrir um PR adequado para o master e fazer backports se necessário depois.

Notei o mesmo problema com a iteração. Mas não consegui vincular isso a uma duplicata no instantâneo. Você conseguiu criar um cenário onde isso aconteceria, @maelk?

sim, você pode executá-lo nos testes de unidade adicionando o pequeno código que coloquei

Agora estou trabalhando para adicionar um caso de teste para o instantâneo, para ter certeza de que foi testado corretamente.

grande sinal de @igraecao pela ajuda na reprodução do problema e na execução dos testes em sua configuração

Obrigado a todos por depurar este problema notório. Reinicializar o índice antes de criar a lista é seguro, então acho que devemos ir com isso para os patches 1.18 e 1.19, e ter uma correção adequada no branch master.

O propósito da função next mudou com a introdução da NodeInfoList, e então podemos certamente simplificá-la e talvez mudá-la para toList , uma função que cria uma lista da árvore e simplesmente inicia desde o início, todas as vezes.

Eu entendo o problema agora: o cálculo de se uma zona foi ou não esgotada está errado porque não considera onde em cada zona iniciamos este processo de "UpdateSnapshot". E sim, só seria visível com zonas desiguais.

Excelente trabalho em identificar este @maelk!

Eu acho que temos o mesmo problema em versões mais antigas. No entanto, está oculto pelo fato de que sempre fazemos uma passagem de árvore. Já no 1.18, capturamos o resultado até que haja mudanças na árvore.

Agora que a estratégia round-robin está implementada em generic_scheduler.go, podemos simplesmente redefinir todos os contadores antes de UpdateSnapshot, como seu PR está fazendo.

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

Apenas para verificar novamente @ ahg-g, isso deve funcionar mesmo em um cluster onde novos nós são adicionados / removidos o tempo todo, certo?

Obrigado @maelk por descobrir a causa raiz!

O propósito da próxima função mudou com a introdução do NodeInfoList, e então podemos certamente simplificá-lo e talvez alterá-lo para toList, uma função que cria uma lista da árvore e simplesmente começa do início todas as vezes.

Dado que cache.nodeTree.next() só é chamado na construção do snapshot nodeInfoList, acho que também é seguro remover os índices (zoneIndex e nodeIndex) da estrutura nodeTree. Em vez disso, crie uma função nodeIterator() simples para iterar por meio de sua zona / nó de maneira round-robin.

BTW: há um erro de digitação em https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090, o caso deveria 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]
},

Apenas para verificar novamente @ ahg-g, isso deve funcionar mesmo em um cluster onde novos nós são adicionados / removidos o tempo todo, certo?

Estou assumindo que você está falando sobre a lógica em generic_scheduler.go, se sim, não importa muito se os nós foram adicionados ou removidos, a principal coisa que precisamos evitar é iterar sobre os nós na mesma ordem todas as vezes nós agendamos um pod, só precisamos de uma boa aproximação da iteração dos nós entre os pods.

Dado que cache.nodeTree.next () é chamado apenas na construção do snapshot nodeInfoList, acho que também é seguro remover os índices (zoneIndex e nodeIndex) da estrutura nodeTree. Em vez disso, crie uma função nodeIterator () simples para iterar por meio de sua zona / nó de maneira round-robin.

sim, precisamos apenas iterar em todas as zonas / nós na mesma ordem sempre.

Eu atualizei o PR com um teste de unidade para a função de atualização da lista de instantâneos, especificamente para esse bug. Eu também posso cuidar da refatoração da função next () para iterar sobre as zonas e nós sem round-robin, removendo assim o problema.

Obrigado, parece bom, mas ainda devemos iterar entre as zonas da mesma maneira que fazemos agora, ou seja, por design.

Eu realmente não entendo o que você quer dizer aqui. É assim que a ordem dos nós importa e ainda devemos fazer rodízio entre as zonas ou podemos listar todos os nós de uma zona, uma zona após a outra? Digamos que você tenha duas zonas de dois nós cada, em que ordem você as espera, ou isso realmente importa?

A ordem é importante, precisamos alternar entre as zonas ao criar a lista. Se você tiver duas zonas de dois nós cada z1: {n11, n12} e z2: {n21, n22} , então a lista deve ser {n11, n21, n12, n22}

ok, obrigado, vou pensar nisso. Enquanto isso, podemos prosseguir com a solução rápida? A propósito, alguns testes estão falhando, mas não tenho certeza de como isso se relaciona com meu PR

Esses são flocos. Por favor, envie um patch para 1.18 também.

Ok, vou fazer. obrigado

{
  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 , você quer dizer que este teste ignora o 'node-5'?

Após corrigir o apêndice em https://github.com/kubernetes/kubernetes/pull/93516 , descobri que o resultado do teste em todos os nós pode ser iterado:

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

O nó 5, 6, 7, 8, 3 pode ser iterado.

Perdoe-me se entendi mal algo aqui.

sim, foi de propósito, com base no que estava lá, mas eu posso ver como isso pode ser enigmático, então é melhor fazer para que o append se comporte de maneira mais clara. Obrigado pelo patch.

Há quanto tempo você acredita que esse bug estava presente? 1,17? 1,16? Acabei de ver exatamente o mesmo problema no 1.17 na AWS e reiniciar o nó não programado corrigiu o problema.

@judgeaxl você poderia fornecer mais detalhes? Linhas de log, despejos de cache, etc. Assim, podemos determinar se o problema é o mesmo.

Como observei em https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695, acredito que esse bug estava presente em versões mais antigas, mas acho que é temporário.

@maelk , você poderia investigar?

Compartilhe também a distribuição de nós nas zonas.

@alculquicondor infelizmente não posso neste momento. Desculpa.

@alculquicondor desculpe, eu já reconstruí o cluster por outros motivos, mas pode ter sido um problema de configuração de rede relacionado a implantações multi-az, e em qual sub-rede o nó defeituoso foi lançado, então eu não me preocuparia com isso agora em o contexto desta questão. Se eu perceber de novo, farei um relatório com mais detalhes. Obrigado!

/ retitle Alguns nós não são considerados na programação quando há desequilíbrio de zona