Kubernetes: Некоторые узлы не учитываются при планировании при разбалансе зон.

/ sig планирование

Можете ли вы предоставить полный yaml узла, набора демонов, примера модуля и содержащего пространства имен, полученного с сервера?

узел:
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

демонсет:
https://gist.github.com/zetaab/31bb406c8bd622b3017bf4f468d0154f

пример стручка (рабочий):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

пример модуля (не планирование):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

пространство имен:
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

Планирование модулей DaemonSet с селектором nodeAffinity, который соответствует только одному узлу, поэтому ожидается сообщение «12 из 13 не совпадают».

Я не вижу причин, по которым планировщик был бы недоволен комбинацией pod / node ... в podspec нет портов, которые могли бы конфликтовать, узел не является незапланированным или испорченным и имеет достаточно ресурсов

Хорошо, я перезапустил все 3 планировщика (изменил loglevel на 4, если мы увидим что-то интересное). Однако это устранило проблему

% 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

теперь все демоны настроены правильно. Странно, все равно что-то не так с планировщиком кажется

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

Мы видим ту же аналогичную проблему в версии 1.18.3, один узел не может быть запланирован для модулей демонов.
планировщик перезапуска помогает.

[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

Трудно отлаживать, не зная, как представить. У вас случайно есть журналы планировщика для модуля, который не удалось запланировать?

Хорошо, я перезапустил все 3 планировщика

Я предполагаю, что только один из них называется default-scheduler , верно?

изменил уровень логирования на 4, если мы увидим там что-то интересное

Можете поделиться тем, что заметили?

установите loglevel на 9, но вроде нет ничего интереснее, ниже логи зацикливаются.

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)

да, я не видел ничего, кроме той же строки

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

странно то, что сообщение журнала показывает результат только для 7 узлов, как и проблема, описанная в https://github.com/kubernetes/kubernetes/issues/91340

/ cc @damemi

@ ahg-g это похоже на ту же проблему, о которой я писал там, похоже, что у нас либо есть плагин фильтра, который не всегда сообщает о своей ошибке, либо какое-то другое условие, которое молча терпит неудачу, если мне нужно было угадать

Обратите внимание, что в моей проблеме перезапуск планировщика также исправил ее (как уже упоминалось в этой теме https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

Мой тоже был про демонсет, так что я думаю, что это дубликат. Если это так, мы можем закрыть это и продолжить обсуждение в https://github.com/kubernetes/kubernetes/issues/91340.

В любом случае планировщику требуется более подробная опция ведения журнала, невозможно отладить эти проблемы, если нет журналов о том, что он делает.

@zetaab +1, планировщик может значительно улучшить свои текущие возможности ведения журнала. Это обновление, которым я собирался заняться какое-то время, и я, наконец, открыл для него проблему здесь: https://github.com/kubernetes/kubernetes/issues/91633

/ назначить

Я занимаюсь этим. Несколько вопросов, которые помогут мне сузить дело. Мне пока не удалось воспроизвести.

• Что было создано первым: демонсет или узел?
• Вы используете профиль по умолчанию?

• У вас есть расширители?

узлы были созданы до демонсета.
Допустим, мы использовали профиль по умолчанию, какой профиль вы имеете в виду и как его проверить?
без расширителей.

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

Еще одна вещь, которая может повлиять на производительность диска - это не очень хорошая производительность для etcd, etcd жалуется на медленную работу.

Да, эти флаги заставят планировщик работать с профилем по умолчанию. Я продолжу поиски. Я все еще не мог воспроизвести.

По-прежнему ничего ... Что-нибудь еще, что, по вашему мнению, может повлиять на вас? портит, порты, прочие ресурсы?

Сделал несколько попыток, связанных с этим. Когда проблема возникла, модули все еще могут быть запланированы для узла (без определения или с помощью селектора «nodeName»).

Если вы пытаетесь использовать Affinity / Antiaffinity, модули не планируются для узла.

Работает при возникновении проблемы:

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

Не работают одновременно:

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

Также при проверке последних даже они были довольно интересными:

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.

• Первое событие - это когда был только что применен манифест (ничего не было сделано для незапланированного узла).
• Второй и третий - когда узел был удален с помощью kubectl, а затем перезапущен.
• Четвертая пришла, когда узел вернулся. Узел, на котором возникла проблема, был главным, поэтому узел не работал (но это показывает, что узел не был найден в трех предыдущих событиях). Что интересно, с четвертым событием все еще отсутствует информация от одного узла. Событие говорит, что доступно 0/9 узлов, но описание дано только от 8.

«nodeName» не является селектором. Использование nodeName позволит обойти планирование.

Четвертая пришла, когда узел вернулся. Узел, на котором возникла проблема, был главным, поэтому узел не работал (но это показывает, что узел не был найден в трех предыдущих событиях). Что интересно, с четвертым событием все еще отсутствует информация от одного узла. Событие говорит, что доступно 0/9 узлов, но описание дано только от 8.

Вы говорите, что причина, по которой модуль не должен был быть запланирован в отсутствующем узле, заключается в том, что он был главным?

Мы видим, что 8 node(s) didn't match node selector переходит к 7. Я предполагаю, что на этом этапе не было удалено ни одного узла, верно?

«nodeName» не является селектором. Использование nodeName позволит обойти планирование.

«NodeName» - это попытка выделить, этот узел можно использовать, и при желании модуль попадает туда. Так что дело не в неспособности узла запускать поды.

Четвертая пришла, когда узел вернулся. Узел, на котором возникла проблема, был главным, поэтому узел не работал (но это показывает, что узел не был найден в трех предыдущих событиях). Что интересно, с четвертым событием все еще отсутствует информация от одного узла. Событие говорит, что доступно 0/9 узлов, но описание дано только от 8.

Вы говорите, что причина, по которой модуль не должен был быть запланирован в отсутствующем узле, заключается в том, что он был главным?

Мы видим, что 8 node(s) didn't match node selector переходит к 7. Я предполагаю, что на этом этапе не было удалено ни одного узла, верно?

Тестовый кластер состоит из 9 узлов; 3 мастера и 6 рабочих. Перед тем, как нерабочий узел был успешно запущен, события сообщали информацию обо всех доступных узлах: 0/8 nodes are available: 8 node(s) didn't match node selector. . Но когда подошел этот узел, который соответствовал селектору узла, событие сообщило 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. Объяснение говорит, что есть 8, которые не совпадают, но ничего не говорит о девятом (что было подтверждено в предыдущем событии).

Итак, состояние события:

• 1-е событие: доступно 9 узлов, ошибка обнаружена с помощью daemonset
• 2-е и 3-е событие: доступно 8 узлов. Тот, который не получал pod, перезапускался
• 4-е событие: доступно 9 узлов (таким образом, тот, который был запущен, был перезапущен).

В конце тестовый модуль не был запущен в соответствующем узле из-за заражения, но это другая история (и должно было быть уже на первом мероприятии).

«NodeName» - это попытка выделить, этот узел можно использовать, и при желании модуль попадает туда. Так что дело не в неспособности узла запускать поды.

Обратите внимание, что ничто не защищает от чрезмерной фиксации узла, кроме планировщика. Так что на самом деле это мало что показывает.

В конце тестовый модуль не был запущен в соответствующем узле из-за заражения, но это другая история (и должно было быть уже на первом мероприятии).

Мой вопрос: был ли 9-й узел испорчен с самого начала? Я пытаюсь найти (1) воспроизводимые шаги для достижения состояния или (2) где может быть ошибка.

Мой вопрос: был ли 9-й узел испорчен с самого начала? Я пытаюсь найти (1) воспроизводимые шаги для достижения состояния или (2) где может быть ошибка.

Да, в этом случае заражение присутствовало все время, поскольку не принимающий узел был главным. Но мы видели одну и ту же проблему и у мастеров, и у рабочих.

По-прежнему не знаю, откуда взялась проблема, просто, по крайней мере, воссоздание узла и перезапуск узла, похоже, решают проблему. Но это немного «трудные» способы исправить ситуацию.

Долгая перспектива, но если вы снова столкнетесь с этим ... не могли бы вы проверить, есть ли какие-либо назначенные модули для узла, которые не отображаются?

Я задаю вопросы, поскольку думаю о возможных сценариях:

• У вас есть другие главные узлы в вашем кластере?
• У вас есть расширители?

* Do you have other master nodes in your cluster?

У всех clusers есть 3 мастера (так что их легко перезапустить)

* Do you have extenders?

Нет.

Сегодня заметил одну интересную вещь: у меня был кластер, в котором один мастер не получал pod от DaemonSet. У нас есть ChaosMonkey, который завершил работу одного из рабочих узлов. Что интересно, это заставило pod перейти к мастеру, который не получал его раньше. Таким образом, каким-то образом удаление другого узла, кроме проблемного, казалось, решало проблему на тот момент.

Из-за этого «исправления» я должен подождать, чтобы проблема повторилась, чтобы я мог ответить о назначенных модулях.

Теперь я в замешательстве ... Допускает ли ваш демонсет заражение для главных узлов? Другими словами ... является ли ошибка для вас просто событием планирования или также тем фактом, что модули должны быть запланированы?

Проблема в том, что этот узел не обнаруживается планировщиком, даже если есть хотя бы одна соответствующая настройка соответствия (или антиаффинности).

Вот почему я сказал, что ошибка заражения ожидаема, и она должна была быть там уже на первом мероприятии (поскольку заражение не является частью критерия сродства)

Понятно. Я пытался подтвердить вашу настройку, чтобы убедиться, что я что-то не упускаю.

Я не думаю, что этот узел «невидим» планировщику. Учитывая, что мы видим 0/9 nodes are available , мы можем сделать вывод, что узел действительно находится в кеше. Это больше похоже на то, что непредсказуемая причина где-то потеряна, поэтому мы не включаем ее в событие.

Верно, общее количество всегда совпадает с фактическим количеством узлов. Просто более описательный текст события не дается на всех узлах, но это может быть отдельной проблемой, как вы упомянули.

Можете ли вы посмотреть логи вашего kube-scheduler? Что-нибудь, что кажется актуальным?

Я думаю, что @zetaab безуспешно пытался это найти. Я могу попробовать, когда проблема возникнет снова (а также с указанным ранее назначенным модулем)

Если возможно, также запустите 1.18.5, на случай, если мы случайно устранили проблему.

Я могу надежно воспроизвести это на моем тестовом кластере, если вам понадобятся дополнительные журналы.

@dilyevsky Поделитесь, пожалуйста,

Похоже, это просто метаданные. Имя узла для модуля ds ... странно. Вот под ямл:

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

Я воспроизвожу это путем развертывания нового кластера с 3 мастерами и 3 рабочими узлами (с использованием Cluster API) и применением 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

Вот журнал планировщика:
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

После перезапуска модулей планировщика ожидающий модуль немедленно планирует.

Какие события в капсулах вы получаете? Вы знаете, есть ли в узле загрязнения
где это не запланировано? Это не работает только для главных узлов или любых
узлы? Достаточно ли места в узле?

Вт, 9 июля 2020 г., 19:49 Дильевский, [email protected]
написал:

Похоже, это просто имя узла метаданных для модуля ds ...
странно. Вот под ямл:

apiVersion: v1kind: Podmetadata:
аннотации:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: реснички-
ярлыки:
хэш-ревизии контроллера: 6c94db8bb8
k8s-app: реснички
pod-template-generation: "1"
managedFields:
# дерьмо управляемых полей
имя: ресничка-d5n4f
пространство имен: kube-system
Владелец

• apiVersion: apps / v1
  blockOwnerDeletion: true
  контроллер: правда
  вид: DaemonSet
  название: ресничка
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  SelfLink: / api / v1 / пространства имен / kube-system / pods / cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  близость:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - ключ: metadata.name
  оператор: In
  значения:
  - us-central1-dilyevsky-master-qmwnl
  контейнеры:
• аргументы:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    команда:
  
  
  • ресничный агент
    
    env:
  
  
  • имя: K8S_NODE_NAME
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: spec.nodeName
  
  
  • имя: CILIUM_K8S_NAMESPACE
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: metadata.namespace
  
  
  • имя: CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: фланель-мастер-устройство
    
    имя: cilium-config
    
    необязательно: правда
  
  
  • имя: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: flannel-uninstall-on-exit
    
    имя: cilium-config
    
    необязательно: правда
  
  
  • имя: CILIUM_CLUSTERMESH_CONFIG
    
    значение: / var / lib / cilium / clustermesh /
  
  
  • имя: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: cni-chaining-mode
    
    имя: cilium-config
    
    необязательно: правда
  
  
  • имя: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: custom-cni-conf
    
    имя: cilium-config
    
    необязательно: правда
    
    образ: docker.io/cilium/ cilium : v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    жизненный цикл:
    
    postStart:
    
    exec:
    
    команда:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = ложь
      
      
      preStop:
      
      
      exec:
      
      
      команда:
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe:
      
      
      exec:
      
      
      команда:
      
      
      
      
      
      
      
      • ресничка
      
      
      
      
      • положение дел
      
      
      
      
      • - краткое
        
        
        
        failureThreshold: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        имя: ресничный агент
        
        
        
        готовность
        
        
        
        exec:
        
        
        
        команда:
      
      
      
      
      • ресничка
      
      
      
      
      • положение дел
      
      
      
      
      • - краткое
        
        
        
        failureThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        Ресурсы: {}
        
        
        
        securityContext:
        
        
        
        возможности:
        
        
        
        Добавить:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        привилегированный: правда
        
        
        
        terminationMessagePath: / dev / termination-log
        
        
        
        terminationMessagePolicy: Файл
        
        
        
        объем
      
      
      
      
    
    
    
  
  
  • mountPath: / var / run / реснички
    
    имя: cilium-run
  
  
  • mountPath: / хост / opt / cni / bin
    
    имя: cni-path
  
  
  • mountPath: /host/etc/cni/net.d
    
    имя: etc-cni-netd
  
  
  • путь монтирования: / var / lib / cilium / clustermesh
    
    имя: clustermesh-secrets
    
    readOnly: правда
  
  
  • путь монтирования: / tmp / cilium / config-map
    
    имя: путь-cilium-config
    
    readOnly: правда
  
  
  • mountPath: / lib / модули
    
    имя: lib-модули
    
    readOnly: правда
  
  
  • mountPath: /run/xtables.lock
    
    имя: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    имя: cilium-token-j74lr
    
    readOnly: правда
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: true
    
    hostNetwork: true
    
    initContainers:
  
  
• команда:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • имя: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: чистое-ресничное состояние
    
    имя: cilium-config
    
    необязательно: правда
  
  
  • имя: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: чистые реснички-bpf-state
    
    имя: cilium-config
    
    необязательно: правда
  
  
  • имя: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    ключ: ждать-bpf-mount
    
    имя: cilium-config
    
    необязательно: правда
    
    образ: docker.io/cilium/ cilium : v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    имя: чистое-ресничное-состояние
    
    Ресурсы: {}
    
    securityContext:
    
    возможности:
    
    Добавить:
    
    
    
    
    
    • NET_ADMIN
      
      
      привилегированный: правда
      
      
      terminationMessagePath: / dev / termination-log
      
      
      terminationMessagePolicy: Файл
      
      
      объем
    
    
    
  
  
  • mountPath: / var / run / реснички
    
    имя: cilium-run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    имя: cilium-token-j74lr
    
    readOnly: правда
    
    приоритет: 2000001000
    
    priorityClassName: критически важный для системного узла
    
    restartPolicy: Всегда
    
    schedulerName: default-scheduler
    
    securityContext: {}
    
    serviceAccount: ресничка
    
    serviceAccountName: ресничка
    
    terminationGracePeriodSeconds: 1
    
    терпимости:
  
  
• оператор: существует
• эффект: NoExecute
  ключ: node.kubernetes.io/not-ready
  оператор: существует
• эффект: NoExecute
  ключ: node.kubernetes.io/unreachable
  оператор: существует
• эффект: NoSchedule
  ключ: node.kubernetes.io/disk-pressure
  оператор: существует
• эффект: NoSchedule
  ключ: node.kubernetes.io/memory-pressure
  оператор: существует
• эффект: NoSchedule
  ключ: node.kubernetes.io/pid-pressure
  оператор: существует
• эффект: NoSchedule
  ключ: node.kubernetes.io/unschedulable
  оператор: существует
• эффект: NoSchedule
  ключ: node.kubernetes.io/network-unavailable
  оператор: существует
  объемы:
• hostPath:
  путь: / var / run / cilium
  тип: DirectoryOrCreate
  имя: cilium-run
• hostPath:
  путь: / opt / cni / bin
  тип: DirectoryOrCreate
  имя: cni-path
• hostPath:
  путь: /etc/cni/net.d
  тип: DirectoryOrCreate
  имя: etc-cni-netd
• hostPath:
  путь: / lib / modules
  тип: ""
  имя: lib-модули
• hostPath:
  путь: /run/xtables.lock
  тип: FileOrCreate
  имя: xtables-lock
• имя: clustermesh-secrets
  секрет:
  defaultMode: 420
  необязательно: правда
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  имя: cilium-config
  имя: путь-cilium-config
• имя: cilium-token-j74lr
  секрет:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  условия:
• lastProbeTime: нуль
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  сообщение: «Доступно 0/6 узлов: 5 узлов не соответствуют селектору узлов».
  причина: не подлежит планированию
  статус: «Ложь»
  тип: PodScheduled
  фаза: Ожидается
  qosClass: BestEffort

Я воспроизвожу это, раскручивая новый кластер с двумя мастерами и
3 рабочих узла (с использованием Cluster API) и применение Cilium 1.7.6:

--- # Источник: cilium / charts / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
название: ресничка
пространство имен: kube-system
--- # Источник: cilium / charts / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
имя: ресничный-оператор
пространство имен: kube-system
--- # Источник: cilium / charts / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
имя: cilium-config
пространство имен: kube-systemdata:

# Режим выделения идентификаторов выбирает, как идентификаторы распределяются между ресничками
# узлов, указав способ их хранения. Возможные варианты: crd или kvstore.
# - «crd» хранит идентификаторы в кубернетах как CRD (настраиваемое определение ресурса).
# Их можно запросить с помощью:
# kubectl get ciliumid
# - "kvstore" хранит удостоверения в kvstore, etcd или консуле, то есть
# настроен ниже. Версии Cilium до 1.6 поддерживали только kvstore
# бэкэнд. При обновлении этих старых версий ресничек следует продолжать использовать
# kvstore, закомментировав режим выделения-идентификации ниже, или
# установив его на "квстор".
режим-распределения-идентичности: crd

# Если вы хотите запустить cilium в режиме отладки, измените это значение на true
отладка: "ложь"

# Включить адресацию IPv4. Если включено, всем конечным точкам назначается IPv4.
# адрес.
enable-ipv4: "правда"

# Включить адресацию IPv6. Если включено, всем конечным точкам назначается IPv6.
# адрес.
enable-ipv6: "ложь"

# Если вы хотите, чтобы cilium monitor агрегировал трассировку пакетов, установите этот уровень
# на "низкий", "средний" или "максимальный". Чем выше уровень, тем меньше пакетов
# что будет видно на выходе монитора.
агрегация монитора: средний

# Интервал агрегирования монитора определяет типичное время между мониторами.
# событий уведомления для каждого разрешенного соединения.
#
# Действует только в том случае, если для агрегирования монитора установлено значение «средний» или выше.
интервал агрегации монитора: 5 с

# Флаги агрегации монитора определяют, какие флаги TCP, при
# первое наблюдение, вызывает генерацию уведомлений монитора.
#
# Действует только в том случае, если для агрегирования монитора установлено значение «средний» или выше.
флаги-агрегации монитора: все

# ct-global-max-entries- * указывает максимальное количество подключений
# поддерживается на всех конечных точках, разделенных протоколом: tcp или другим. Одна пара
# of maps использует эти значения для соединений IPv4, а другая пара карт
# использовать эти значения для соединений IPv6.
#
# Если эти значения изменены, то при следующем запуске Cilium
# отслеживание текущих соединений может быть нарушено. Это может привести к краткому
# отбрасывание политики или изменение решений по балансировке нагрузки для соединения.
#
# Для пользователей, обновляющих Cilium 1.2 или ранее, чтобы свести к минимуму перебои
# в процессе обновления закомментируйте эти параметры.
bpf-ct-global-tcp-max: «524288»
bpf-ct-global-any-max: «262144»

# bpf-policy-map-max указывает максимальное количество записей в конечной точке
# карта политик (для каждой конечной точки)
bpf-policy-map-max: «16384»

# Предварительное распределение записей карты позволяет уменьшить задержку каждого пакета при
# расходы на предварительное выделение памяти для записей в картах. В
# значение по умолчанию, указанное ниже, минимизирует использование памяти при установке по умолчанию;
# пользователей, чувствительных к задержке, могут подумать о том, чтобы установить для него значение "true".
#
# Эта опция была введена в Cilium 1.4. Cilium 1.3 и ранее игнорировать
# этот параметр и вести себя так, как если бы он был установлен в значение "true".
#
# Если это значение изменено, то при следующем запуске Cilium восстановление
Количество существующих конечных точек и отслеживание текущих подключений может быть нарушено.
# Это может привести к отказу от политики или изменению решений по балансировке нагрузки для
# соединение на некоторое время. Для восстановления может потребоваться воссоздание конечных точек.
# подключение.
#
# Если для этой опции установлено значение "false" во время обновления с 1.3 или ранее до
# 1.4 или новее, то это может вызвать разовые сбои во время обновления.
preallocate-bpf-maps: "ложь"

# Соответствие регулярных выражений совместимому Istio sidecar istio-proxy
# имена образов контейнеров
sidecar-istio-proxy-image: "ресничка / istio_proxy"

# Режим инкапсуляции для связи между узлами
# Возможные значения:
# - отключен
# - vxlan (по умолчанию)
# - женева
туннель: vxlan

# Имя кластера. Актуально только при построении сетки кластеров.
имя-кластера: по умолчанию

# DNS Polling периодически выполняет поиск DNS для каждого matchName от
# ресничный агент. Результат используется для восстановления политики конечной точки.
# DNS-запросы повторяются с интервалом в 5 секунд и выполняются для
# Адреса A (IPv4) и AAAA (IPv6). Если поиск завершится неудачно, последний IP-адрес
# вместо них используются данные. Смена IP вызовет регенерацию реснички.
# policy для каждой конечной точки и увеличить политику для каждого cilium-agent
# ревизия репозитория.
#
# Эта опция отключена по умолчанию, начиная с версии 1.4.x в пользу
# более мощной реализации на основе DNS-прокси, подробности см. в [0].
# Включите эту опцию, если вы хотите использовать политики FQDN, но не хотите использовать
# DNS-прокси.
#
# Чтобы упростить обновление, пользователи могут выбрать для этого параметра значение «true».
# В противном случае обратитесь к Руководству по обновлению [1], в котором объясняется, как
# подготовить правила политики для обновления.
#
# [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: «ложь»

# wait-bpf-mount заставляет контейнер инициализации ждать, пока файловая система bpf смонтирована
wait-bpf-mount: "ложь"

маскарад: "правда"
enable-xt-socket-fallback: "истина"
install-iptables-rules: "правда"
auto-direct-node-routes: "false"
kube-proxy-replace: "зонд"
enable-host-reachable-services: "ложь"
enable-external-ips: "ложь"
enable-node-port: "ложь"
узел-порт-защита-привязки: "истина"
enable-auto-protect-node-port-range: "истина"
enable-endpoint-health-testing: "истина"
enable-well-known-identity: "false"
включить идентификацию удаленного узла: "истина"
--- # Источник: cilium / charts / agent / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
название: ciliumrules:

• apiGroups:
  
  
  
  • network.k8s.io
    
    Ресурсы:
  
  
  • сетевая политика
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Ресурсы:
  
  
  • конечные точки
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
• apiGroups:
  
  
  
  • ""
    
    Ресурсы:
  
  
  • пространства имен
  
  
  • Сервисы
  
  
  • узлы
  
  
  • конечные точки
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
• apiGroups:
  
  
  
  • ""
    
    Ресурсы:
  
  
  • стручки
  
  
  • узлы
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
  • Обновить
  
  
• apiGroups:
  
  
  
  • ""
    
    Ресурсы:
  
  
  • узлы
  
  
  • узлы / статус
    
    глаголы:
  
  
  • патч
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    Ресурсы:
  
  
  • customresourcedefinitions
    
    глаголы:
  
  
  • Создайте
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
  • Обновить
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ресурсы:
  
  
  • ресничка
  
  
  • ciliumnetworkpolicies / status
  
  
  • ресничный кластер
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • цилиум
  
  
  • ciliumendpoints / статус
  
  
  • ресничные узлы
  
  
  • ciliumnodes / статус
  
  
  • реснички
  
  
  • ciliumidentities / статус
    
    глаголы:
  
  
  • '*'
    
    --- # Источник: cilium / charts / operator / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    имя: cilium-operatorrules:
  
  
• apiGroups:
  
  
  
  • ""
    
    Ресурсы:
    
    # для автоматического удаления [core | kube] dns pod'ов, чтобы они
    
    # под управлением Cilium
  
  
  • стручки
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
  • удалять
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    Ресурсы:
  
  
  • конечные точки
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
• apiGroups:
  
  
  
  • ""
    
    Ресурсы:
    
    # для автоматического чтения из k8s и импорта пода CIDR узла в реснички
    
    # etcd, чтобы все узлы знали, как связаться с другим модулем, запущенным в другом
    
    # узел.
  
  
  • узлы
    
    # чтобы выполнить перевод CNP, который содержит ToGroup в его конечные точки
  
  
  • Сервисы
  
  
  • конечные точки
    
    # чтобы проверить подключение apiserver
  
  
  • пространства имен
    
    глаголы:
  
  
  • получить
  
  
  • список
  
  
  • часы
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    Ресурсы:
  
  
  • ресничка
  
  
  • ciliumnetworkpolicies / status
  
  
  • ресничный кластер
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • цилиум
  
  
  • ciliumendpoints / статус
  
  
  • ресничные узлы
  
  
  • ciliumnodes / статус
  
  
  • реснички
  
  
  • ciliumidentities / статус
    
    глаголы:
  
  
  • '*'
    
    --- # Источник: cilium / charts / agent / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    имя: ciliumroleRef:
    
    apiGroup: rbac.authorization.k8s.io
    
    вид: ClusterRole
    
    название: реснички
  
  
• вид: ServiceAccount
  название: ресничка
  пространство имен: kube-system
  --- # Источник: cilium / charts / operator / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  имя: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  вид: ClusterRole
  name: cilium-operatorubjects:
• вид: ServiceAccount
  имя: ресничный-оператор
  пространство имен: kube-system
  --- # Источник: cilium / charts / agent / templates / daemonset.yamlapiVersion: apps / v1kind: DaemonSetmetadata:
  ярлыки:
  k8s-app: реснички
  название: ресничка
  пространство имен: kube-systempec:
  селектор:
  matchLabels:
  k8s-app: реснички
  шаблон:
  метаданные:
  аннотации:
  # Эта аннотация плюс допуск CriticalAddonsOnly делает
  # ресничка должна быть критическим стручком в кластере, который обеспечивает ресничку
  # получает приоритетное планирование.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  scheduler.alpha.kubernetes.io/critical-pod: ""
  ярлыки:
  k8s-app: реснички
  спецификации:
  контейнеры:
  
  
  
  • аргументы:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      команда:
    
    
    
    • ресничный агент
      
      
      livenessProbe:
      
      
      exec:
      
      
      команда:
      
      
      
      
      
      
      
      • ресничка
      
      
      
      
      • положение дел
      
      
      
      
      • - краткое
        
        
        
        failureThreshold: 10
        
        
        
        # Начальная задержка для зонда живучести намеренно велика, чтобы
        
        
        
        # избегайте бесконечного цикла уничтожения и перезапуска, если начальный
        
        
        
        # начальная загрузка занимает больше времени, чем ожидалось.
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        готовность
        
        
        
        exec:
        
        
        
        команда:
      
      
      
      
      • ресничка
      
      
      
      
      • положение дел
      
      
      
      
      • - краткое
        
        
        
        failureThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        successThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • имя: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • имя: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • имя: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: фланель-мастер-устройство
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: flannel-uninstall-on-exit
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_CLUSTERMESH_CONFIG
      
      
      значение: / var / lib / cilium / clustermesh /
    
    
    
    • имя: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: cni-chaining-mode
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: custom-cni-conf
      
      
      имя: cilium-config
      
      
      необязательно: правда
      
      
      образ: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      жизненный цикл:
      
      
      postStart:
      
      
      exec:
      
      
      команда:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        exec:
        
        
        
        команда:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        имя: ресничный агент
        
        
        
        securityContext:
        
        
        
        возможности:
        
        
        
        Добавить:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          привилегированный: правда
          
          
          
          
          объем
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath: / var / run / реснички
      
      
      имя: cilium-run
    
    
    
    • mountPath: / хост / opt / cni / bin
      
      
      имя: cni-path
    
    
    
    • mountPath: /host/etc/cni/net.d
      
      
      имя: etc-cni-netd
    
    
    
    • путь монтирования: / var / lib / cilium / clustermesh
      
      
      имя: clustermesh-secrets
      
      
      readOnly: правда
    
    
    
    • путь монтирования: / tmp / cilium / config-map
      
      
      имя: путь-cilium-config
      
      
      readOnly: правда
      
      
      # Требуется для загрузки модулей ядра
    
    
    
    • mountPath: / lib / модули
      
      
      имя: lib-модули
      
      
      readOnly: правда
    
    
    
    • mountPath: /run/xtables.lock
      
      
      имя: xtables-lock
      
      
      hostNetwork: true
      
      
      initContainers:
    
    
    
  
  
  • команда:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • имя: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: чистое-ресничное состояние
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: чистые реснички-bpf-state
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: ждать-bpf-mount
      
      
      имя: cilium-config
      
      
      необязательно: правда
      
      
      образ: "docker.io/cilium/ cilium : v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      имя: чистое-ресничное состояние
      
      
      securityContext:
      
      
      возможности:
      
      
      Добавить:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        привилегированный: правда
        
        
        
        объем
      
      
      
      
    
    
    
    • mountPath: / var / run / реснички
      
      
      имя: cilium-run
      
      
      restartPolicy: Всегда
      
      
      priorityClassName: критически важный для системного узла
      
      
      serviceAccount: ресничка
      
      
      serviceAccountName: ресничка
      
      
      terminationGracePeriodSeconds: 1
      
      
      терпимости:
    
    
    
  
  
  • оператор: существует
    
    объемы:
    
    # Сохранять состояние между перезапусками / обновлениями
  
  
  • hostPath:
    
    путь: / var / run / cilium
    
    тип: DirectoryOrCreate
    
    имя: cilium-run
    
    # Чтобы установить плагин cilium cni на хост
  
  
  • hostPath:
    
    путь: / opt / cni / bin
    
    тип: DirectoryOrCreate
    
    имя: cni-path
    
    # Для установки конфигурации cilium cni на хост
  
  
  • hostPath:
    
    путь: /etc/cni/net.d
    
    тип: DirectoryOrCreate
    
    имя: etc-cni-netd
    
    # Чтобы иметь возможность загружать модули ядра
  
  
  • hostPath:
    
    путь: / lib / modules
    
    имя: lib-модули
    
    # Для доступа к iptables одновременно с другими процессами (например, kube-proxy)
  
  
  • hostPath:
    
    путь: /run/xtables.lock
    
    тип: FileOrCreate
    
    имя: xtables-lock
    
    # Чтобы прочитать конфигурацию кластерной сетки
  
  
  • имя: clustermesh-secrets
    
    секрет:
    
    defaultMode: 420
    
    необязательно: правда
    
    secretName: cilium-clustermesh
    
    # Чтобы прочитать конфигурацию из карты конфигурации
  
  
  • configMap:
    
    имя: cilium-config
    
    имя: путь-cilium-config
    
    updateStrategy:
    
    RollingUpdate:
    
    maxUnavailable: 2
    
    тип: RollingUpdate
    
    --- # Источник: cilium / charts / operator / templates / deployment.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    ярлыки:
    
    io.cilium / app: оператор
    
    имя: ресничный-оператор
    
    имя: ресничный-оператор
    
    пространство имен: kube-systempec:
    
    реплик: 1
    
    селектор:
    
    matchLabels:
    
    io.cilium / app: оператор
    
    имя: ресничный-оператор
    
    стратегия:
    
    RollingUpdate:
    
    maxSurge: 1
    
    maxUnavailable: 1
    
    тип: RollingUpdate
    
    шаблон:
    
    метаданные:
    
    аннотации:
    
    ярлыки:
    
    io.cilium / app: оператор
    
    имя: ресничный-оператор
    
    спецификации:
    
    контейнеры:
  
  
  • аргументы:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identity-allocation-mode = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-nodes = истина
      
      
      команда:
    
    
    
    • ресничный оператор
      
      
      env:
    
    
    
    • имя: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • имя: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • имя: CILIUM_DEBUG
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: отладка
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: имя-кластера
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: идентификатор кластера
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: ipam
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: отключить конечную точку-crd
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: kvstore
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: kvstore-opt
      
      
      имя: cilium-config
      
      
      необязательно: правда
    
    
    
    • имя: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      ключ: AWS_ACCESS_KEY_ID
      
      
      имя: cilium-aws
      
      
      необязательно: правда
    
    
    
    • имя: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      ключ: AWS_SECRET_ACCESS_KEY
      
      
      имя: cilium-aws
      
      
      необязательно: правда
    
    
    
    • имя: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      ключ: AWS_DEFAULT_REGION
      
      
      имя: cilium-aws
      
      
      необязательно: правда
    
    
    
    • имя: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      ключ: режим распределения идентификационных данных
      
      
      имя: cilium-config
      
      
      необязательно: правда
      
      
      изображение: "docker.io/cilium/ operator: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      имя: ресничный-оператор
      
      
      livenessProbe:
      
      
      httpGet:
      
      
      хост: '127.0.0.1'
      
      
      путь: / healthz
      
      
      порт: 9234
      
      
      схема: HTTP
      
      
      initialDelaySeconds: 60
      
      
      periodSeconds: 10
      
      
      timeoutSeconds: 3
      
      
      hostNetwork: true
      
      
      restartPolicy: Всегда
      
      
      serviceAccount: ресничка-оператор
      
      
      serviceAccountName: ресничный-оператор
    
    
    
  
  

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

Не могли бы вы попробовать увеличить уровень логирования и использовать grep для фильтрации узла
или стручок?

Вт., 9 июля 2020 г., 19:55 Дильевский, [email protected]
написал:

Вот журнал планировщика:

I0709 23: 08: 22.056081 1 registry.go: 150] Регистрация предиката и функции приоритета EvenPodsSpread
I0709 23: 08: 23.137451 1 serve.go: 313] Сгенерированный самоподписанный сертификат в памяти
W0709 23:08: 33.843509 1 authentication.go: 297] Ошибка поиска конфигурации аутентификации в кластере: etcdserver: истекло время ожидания запроса
W0709 23: 08: 33.843671 1 authentication.go: 298] Продолжение без настройки аутентификации. Это может рассматривать все запросы как анонимные.
W0709 23: 08: 33.843710 1 authentication.go: 299] Чтобы запросить поиск конфигурации аутентификации для успешного выполнения, установите --authentication-allowrate-lookup-failure = false
I0709 23: 08: 33.911805 1 registry.go: 150] Регистрация предиката и функции приоритета EvenPodsSpread
I0709 23: 08: 33.911989 1 registry.go: 150] Регистрация предиката и функции приоритета EvenPodsSpread
W0709 23:08: 33.917999 1 authorization.go: 47] Авторизация отключена
W0709 23: 08: 33.918162 1 authentication.go: 40] Аутентификация отключена
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Небезопасное обслуживание Healthz на [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] Запуск client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.926013 1 shared_informer.go: 223] Ожидание синхронизации кешей для client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Безопасное обслуживание на 127.0.0.1:10259
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] Запуск DynamicServingCertificateController
I0709 23: 08: 34.026382 1 shared_informer.go: 230] Кеши синхронизируются для client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 34.036998 1 leaderelection.go: 242] попытка приобретения лидера в аренду kube-system / kube-scheduler ...
I0709 23: 08: 50.597201 1 leaderelection.go: 252] успешно приобретена аренда kube-system / kube-scheduler
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd уже присутствует в активной очереди
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 уже присутствует в очереди отката.
E0709 23: 12: 58.099432 1 leaderelection.go: 320] ошибка при получении блокировки ресурса kube-system / kube-scheduler: etcdserver: лидер изменен

После перезапуска модулей планировщика ожидающий модуль немедленно планирует.

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Это события:
`` События:
Тип Причина Возраст из сообщения
---- ------ ---- ---- -------
Предупреждение FailedSchedulingДоступны узлы default-scheduler 0/6: 5 узлов не соответствуют селектору узлов.
Предупреждение FailedSchedulingДоступны узлы default-scheduler 0/6: 5 узлов не соответствуют селектору узлов.

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

Испорчены: node-role.kubernetes.io/ master: NoSchedule
node.kubernetes.io/network-un доступно: 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

Попробую сейчас увеличить уровень журнала планировщика ...

Ваш pod yaml на самом деле не допускает node-role.kubernetes.io/master . Так что это не должно было быть запланировано в мастере.

Привет! Мы сталкиваемся с той же проблемой. Однако мы видим ту же проблему с развертываниями, где мы используем анти-сродство, чтобы гарантировать, что модуль будет запланирован на каждом узле или селектор модуля, нацеленный на конкретный узел.
Простого создания пода с селектором узла, настроенным в соответствии с именем хоста отказавшего узла, было достаточно, чтобы вызвать сбой планирования. В нем говорилось, что 5 узлов не соответствуют селектору, но ничего о шестом. Перезапуск планировщика решил проблему. Похоже, что что-то кешируется об этом узле и предотвращает планирование на узле.
Как уже говорили другие люди, у нас нет ничего в журнале об ошибке.

Мы сократили количество неудачных развертываний до минимума (мы удалили дефект на ведущем сервере, который дает сбой):

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

У нас была такая же проблема, когда у мастера была заражение, а развертывание допускало заражение. Так что, похоже, это не связано конкретно с демонами, толерантностью или аффинностью / антиаффинностью. Когда начинается сбой, ничего, что нацелено на конкретный узел, нельзя запланировать. Мы видим проблему в 1.18.2 до 1.18.5 (не пробовал с 1.18.0 или .1)

Простого создания пода с селектором узла, настроенным в соответствии с именем хоста отказавшего узла, было достаточно, чтобы вызвать сбой планирования.

Не могли бы вы уточнить, начинал ли он давать сбой после того, как вы создали такой модуль или раньше? Я предполагаю, что этот узел не имел дефекта, который не переносил капсула.

@nodo поможет воспроизвести. Не могли бы вы взглянуть на код NodeSelector? Во время тестирования вам может потребоваться добавить дополнительные строки журнала. Вы также можете распечатать кеш.

• Получить PID kube-scheduler: $ pidof kube-scheduler
• Дамп триггерной очереди: $ sudo kill -SIGUSR2 <pid> . Обратите внимание, что это не убьет процесс планировщика.
• Затем в журнале планировщика найдите строки «Дамп кэшированной информации NodeInfo», «Дамп очереди планирования» и «Запущен компаратор кеша».

/ приоритет критический-срочный

/ отменить назначение

Мы уже видели, что какой-то набор демонов и развертывание застряли в состоянии «Ожидание», прежде чем мы попытались развернуть это тестовое развертывание, так что это уже не удалось. и пятна были удалены с узла.
Прямо сейчас мы потеряли среду, в которой это происходило, потому что нам пришлось перезагрузить узлы, чтобы проблема больше не была видна. Как только мы воспроизведем, мы постараемся вернуться с дополнительной информацией

Пожалуйста, сделай так. Раньше я безуспешно пытался воспроизвести это. Меня больше интересует первый случай отказа. Это все еще может быть связано с пороками.

Мы воспроизвели проблему. Я выполнил команду, которую вы просили, вот информация:

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: 

К сожалению, это не помогает

Дамп кеша для отладки, ничего не изменит. Не могли бы вы включить дамп?

Кроме того, если это была первая ошибка, не могли бы вы включить pod yaml и node?

это почти все, что было сброшено, я просто удалил другие узлы. Это была не первая ошибка, но в дампе можно увидеть pod coredns, это была первая ошибка. Не знаю, что еще вы просите на свалке.
Я принесу ямлы

Спасибо, я не понял, что вы обрезали соответствующий узел и контейнер.

Не могли бы вы включить запланированные модули для этого узла? На всякий случай есть ошибка в расчетах использования ресурсов.

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

Этот AllowedPodNumber: 0 кажется странным.

Вот другие модули на этом узле:
` 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:

Все узлы имеют значение allowedPodNumber, равное 0, в запрошенных ресурсах в дампе, но другие узлы могут быть запланированы.

Узел 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

и капсула:

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

Большое спасибо за всю информацию. @nodo ты можешь это принять?

Мы также пытаемся с https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc сейчас, чтобы получить дополнительную информацию

/Помогите

@maelk смело примите это и отправьте PR, если обнаружите ошибку. Добавленные вами строки журнала могут оказаться полезными. В противном случае я открываюсь для участников.

@alculquicondor :
Этот запрос был отмечен как требующий помощи со стороны автора.

Убедитесь, что запрос соответствует перечисленным здесь требованиям.

Если этот запрос больше не соответствует этим требованиям, метку можно удалить
путем комментирования с помощью команды /remove-help .

/ назначить

@maelk Есть ли что-нибудь конкретное относительно времени, когда эта проблема возникает в первый раз? Например, происходит ли это сразу после запуска узла?

Нет, есть несколько модулей, которые там планируются и работают нормально. Но как только проблема возникает, планировать ее больше нельзя.

Понижаем приоритет, пока не получим воспроизводимый случай.

Мы смогли воспроизвести ошибку с помощью планировщика, у которого были дополнительные записи журнала. Мы видим, что один из мастеров полностью исчезает из списка узлов, которые проходят итерацию. Мы видим, что процесс начинается с 6 узлов (из снимка):

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

но после этого мы видим, что он выполняет итерацию только по 5 узлам, и тогда мы получаем:

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

Таким образом, один из узлов удаляется из списка потенциальных узлов. К сожалению, в начале процесса у нас не было достаточного количества журналов, но мы постараемся получить больше.

Ссылки на код по строке журнала:

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

@maelk
Вы видели какие-нибудь строки для %v/%v on node %v, too many nodes fit ?

Иначе, @pancernik, не могли бы вы проверить наличие ошибок на workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) ?

Нет, этот журнал не появился. Я также думаю, что у нас либо проблема с распараллеливанием, либо этот узел отфильтрован раньше. Если здесь произошла ошибка с ошибкой: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464, я постараюсь добавить больше записей в журнал, чтобы было видно больше записей в журнале функция и распараллеливание.

Я только что понял, что один узел проходит фильтрацию дважды!

Журналы:

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

Как видите, узел worker-pool1-60846k0y-scheduler дважды проходит фильтрацию

Нет, этот журнал не появился. Я также думаю, что у нас либо проблема с распараллеливанием, либо этот узел отфильтрован раньше. Если здесь произошла ошибка с ошибкой: Nordix @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464, это было бы видно в журналах afaik, поэтому я постараюсь добавить больше отладочных записей, касающихся конкретно функции и распараллеливания.

Да, там ошибка будет проявляться как Ошибка планирования в событиях модуля.

Я только что понял, что один узел проходит фильтрацию дважды!

Честно говоря, я бы не подумал, что у распараллеливания есть ошибки (все же стоит проверить), но это может быть признаком того, что нам не удалось создать снимок из кеша (как мы видели из дампа кеша, кеш правильный), добавив узел дважды. Поскольку статусы - это карта, то имеет смысл, что мы «видим» только 5 узлов в последней строке журнала.

Это код (наконечник 1.18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

Я постараюсь добавить много журналов в кеш-часть планировщика, особенно вокруг добавления и обновления узлов, а также вокруг снимка. Однако из последней строки журналов вы можете видеть, что снимок действительно правильный и содержит все узлы, поэтому все, что происходит, кажется, происходит позже, при работе с этим снимком.

cache! = снимок

Кэш - это живое существо, которое обновляется в результате событий. Снимок обновляется (из кеша) перед каждым циклом планирования, чтобы «заблокировать» состояние. Мы добавили оптимизацию, чтобы сделать этот последний процесс как можно быстрее. Возможно, это ошибка.

Спасибо @maelk! Это очень полезно. В ваших журналах указано, что (*nodeinfo.NodeInfo)(0xc000952000) дублируется в списке, уже находящемся по адресу https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f до того, как любой код parallelR36 будет выполнен. Это действительно будет означать, что он будет продублирован до обновления снимка.

Фактически, это происходит из снимка, который происходит до этого сообщения журнала: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca38073216d7f361R Таким образом, похоже, что содержимое снимка имеет дублирование, поскольку оно взято с https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca3801R36d7f

Это правильно. Я имел в виду, что он уже продублирован до завершения обновления снимка.

Это правильно. Я имел в виду, что он уже продублирован до завершения обновления снимка.

Нет, снимок обновляется в начале цикла планирования. Ошибка либо во время обновления снимка, либо до этого. Но кеш правильный, судя по дампу в https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008

РЕДАКТИРОВАТЬ: Я прочитал неправильно, я не видел слова «заканчивается» :)

Снимок обновления для оптимизации PR был сделан в 1.18: https://github.com/kubernetes/kubernetes/pull/85738 и https://github.com/kubernetes/kubernetes/pull/86919.

Интересно, есть ли в дереве узлов повторяющиеся записи

Интересно, есть ли в дереве узлов повторяющиеся записи

@maelk не могли бы вы показать дамп полного списка узлов в кеше?

мы не добавляем / не удаляем элементы из NodeInfoList, мы либо создаем полный список из дерева, либо нет, поэтому, если есть дубликаты, я думаю, они, скорее всего, исходят из дерева.

Просто для уточнения:
1) в кластере 6 узлов (включая мастера)
2) узел, на котором предполагается разместить модуль, вообще не был проверен (нет строки журнала, указывающей на это), что может означать, что его вообще нет в NodeInfoList
3) NodeInfoList имеет 6 узлов, но один из них дублирован

Интересно, есть ли в дереве узлов повторяющиеся записи

@maelk не могли бы вы показать дамп полного списка узлов в кеше?

дамп каждого дерева узлов, списка и карты был бы отличным.

Я буду работать над их получением. А пока небольшое обновление. Мы видим в журналах:

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

И это именно тот момент, когда пропавший узел исчезает. Последнее появление в журналах - 13:37:24. В следующем расписании отсутствующий узел исчезнет. так что похоже, что ошибка находится в / после обновления node_tree. Все узлы проходят это обновление, просто этот рабочий 608 является последним, кто проходит это обновление.

При выгрузке кеша (с помощью SIGUSR2) все шесть узлов перечислены там, при этом модули работают на узлах, без дублирования или отсутствующих узлов.

Мы дадим ему новую попытку с добавленной отладкой функциональности моментальных снимков: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Удален узел worker-pool1-60846k0y-scheduler в группе "" из NodeTree.

Интересно, я думаю, что удаление / добавление запускается вызовом updateNode. Ключ зоны отсутствует при удалении, но существует при добавлении, поэтому обновление в основном добавляло метки зоны и региона?

Есть ли у вас другие журналы планировщика, связанные с этим узлом?

Мы пытаемся воспроизвести ошибку с добавленным логированием. Я вернусь, когда у меня будет больше информации

Я буду работать над их получением. А пока небольшое обновление. Мы видим в журналах:

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

Я укажу, что такой узел - это узел, который повторяется. @maelk , вы видели похожие сообщения для других узлов или нет? Как и @ ahg-g, этого следует ожидать, когда узел получает метки топологии в первый раз.

да, это произошло для всех узлов, и это ожидаемо. совпадение в том, что именно этот узел является последним обновленным, и именно в это время пропадает другой узел

Получили ли вы журналы обновлений для отсутствующего узла?

Получили ли вы журналы обновлений для отсутствующего узла?

лол, просто набирала этот вопрос.

возможно, ошибка в том, что вся зона удаляется из дерева до того, как будут удалены все узлы.

Чтобы прояснить, я лично не смотрю на код, я просто пытаюсь убедиться, что у нас есть вся информация. И я думаю, что с тем, что у нас есть сейчас, мы сможем обнаружить ошибку. Не стесняйтесь отправлять PR и гораздо лучше, если вы можете предоставить модульный тест, который не работает.

Получили ли вы журналы обновлений для отсутствующего узла?

да, это показывает, что зона обновлена ​​для этого отсутствующего узла. Есть запись в журнале для всех узлов

Честно говоря, я до сих пор не понимаю причину ошибки, но если мы сможем приблизиться к ее обнаружению, я отправлю PR или модульные тесты.

да, это показывает, что зона обновлена ​​для этого отсутствующего узла. Есть запись в журнале для всех узлов

Если так, то я полагаю, что это «точная точка, когда пропавший узел исчезает». не могут быть коррелированы. Подождем новых логов. Было бы здорово, если бы вы могли поделиться всеми журналами планировщика, которые вы получаете в файле.

Сделаю, когда воспроизведем с новым журналом. Из существующих мы действительно можем видеть, что планирование модуля сразу после этого обновления является первым, которое терпит неудачу. Но он не дает достаточно информации, чтобы знать, что произошло между ними, так что следите за обновлениями ...

@maelk Вы видели в журналах планировщика сообщение, начинающееся с snapshot state is not consistent ?

Можно ли предоставить полные журналы планировщика?

нет, этого сообщения нет. Я мог бы дать полосатый файл журнала (чтобы избежать повторения), но давайте сначала подождем, пока у нас не будет вывода с большим количеством журналов вокруг снимка

Я нашел ошибку. Проблема заключается в функции nodeTree next (), которая в некоторых случаях не возвращает список всех узлов. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

Это видно, если вы добавите сюда следующее: 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"},
},

Основная проблема заключается в том, что при добавлении узла индексы некоторых зон не равны 0. Чтобы это произошло, у вас должно быть как минимум две зоны, одна из которых короче другой, а у более длинной, индекс которой не установлен на 0 при первом вызове следующей функции.

Исправление, которое я выбрал, - это сбросить индекс перед первым вызовом next (). Я открыл PR, чтобы показать свое исправление. Конечно, это противоречит выпуску 1.18, поскольку это то, над чем я работаю, но в основном это касается обсуждения того, как это исправить (или, возможно, исправить саму функцию next ()). Я могу открыть правильный пиар для мастера и потом, если нужно, сделать бэкпорты.

Я заметил ту же проблему с итерацией. Но мне не удалось связать это с дубликатом на снимке. Вам удалось создать сценарий, при котором это произойдет, @maelk?

да, вы можете запустить его в модульных тестах, добавив небольшой код, который я поместил

Сейчас я работаю над добавлением тестового примера для снимка, чтобы убедиться, что он правильно протестирован.

Большое спасибо @igraecao за помощь в воспроизведении проблемы и проведении тестов в его настройках

Спасибо всем за устранение этой печально известной проблемы. Сброс индекса перед созданием списка безопасен, поэтому я думаю, что мы должны использовать это для патчей 1.18 и 1.19 и внести соответствующее исправление в главную ветку.

Назначение функции next изменилось с введением NodeInfoList, поэтому мы, безусловно, можем упростить ее и, возможно, изменить ее на toList , функцию, которая создает список из дерева и просто запускает с самого начала каждый раз.

Теперь я понимаю проблему: расчет того, исчерпана зона или нет, неверен, потому что не учитывается, где в каждой зоне мы запустили этот процесс «UpdateSnapshot». И да, это было бы видно только с неровными зонами.

Отличная работа по обнаружению этого @maelk!

Я думаю, что у нас такая же проблема в старых версиях. Однако это скрыто тем фактом, что мы каждый раз выполняем проход дерева. В то время как в 1.18 мы делаем снимок результата до тех пор, пока не появятся изменения в дереве.

Теперь, когда стратегия циклического перебора реализована в generic_scheduler.go, мы можем просто сбросить все счетчики перед UpdateSnapshot, как это делает ваш PR.

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

Просто чтобы дважды проверить @ ahg-g, это должно быть нормально даже в кластере, где все время добавляются / удаляются новые узлы, верно?

Спасибо @maelk за определение первопричины!

Назначение следующей функции изменилось с введением NodeInfoList, и поэтому мы, безусловно, можем упростить ее и, возможно, изменить ее на toList, функцию, которая создает список из дерева и просто начинает каждый раз с начала.

Учитывая, что cache.nodeTree.next() вызывается только при создании снимка nodeInfoList, я думаю, что также безопасно удалить индексы (как zoneIndex, так и nodeIndex) из структуры nodeTree. Вместо этого придумайте простую функцию nodeIterator() для циклического перебора его зоны / узла.

Кстати: в https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090 есть опечатка, случай должен быть таким:

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

Просто чтобы дважды проверить @ ahg-g, это должно быть нормально даже в кластере, где все время добавляются / удаляются новые узлы, верно?

Я предполагаю, что вы говорите о логике в generic_scheduler.go, если да, то не имеет большого значения, были ли узлы добавлены или удалены, главное, чего нам нужно избегать, это повторять узлы в одном и том же порядке каждый раз мы планируем поды, нам просто нужно хорошее приближение перебора узлов по подам.

Учитывая, что cache.nodeTree.next () вызывается только при создании снимка nodeInfoList, я думаю, что также безопасно удалить индексы (как zoneIndex, так и nodeIndex) из структуры nodeTree. Вместо этого придумайте простую функцию nodeIterator () для циклического перебора его зоны / узла.

да, нам просто нужно каждый раз перебирать все зоны / узлы в одном и том же порядке.

Я обновил PR с помощью модульного теста для функции обновления списка снимков специально для этой ошибки. Я также могу позаботиться о рефакторинге функции next () для перебора зон и узлов без циклического перебора, что устраняет проблему.

Спасибо, звучит хорошо, но мы все равно должны перемещаться между зонами так же, как и сейчас, то есть намеренно.

Я действительно не понимаю, что вы здесь имеете в виду. Так ли это, что порядок узлов имеет значение, и мы все равно должны идти по кругу между зонами, или мы можем перечислить все узлы зоны, одну зону за другой? Предположим, у вас есть две зоны по два узла в каждой, в каком порядке вы их ожидаете, или это вообще имеет значение?

Порядок имеет значение, нам нужно чередовать зоны при создании списка. Если у вас есть две зоны по два узла в каждой z1: {n11, n12} и z2: {n21, n22} , тогда список должен быть {n11, n21, n12, n22}

хорошо, спасибо, я подумаю. Можем ли мы тем временем приступить к быстрому исправлению? кстати, некоторые тесты терпят неудачу, но я не уверен, как это связано с моим PR

Это хлопья. Также пришлите патч для 1.18.

Нормально будет сделать. благодаря

{
  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 , вы имеете в виду, что этот тест игнорирует "узел-5"?

Я обнаружил, что после исправления добавления в https://github.com/kubernetes/kubernetes/pull/93516 результат теста может быть повторен для всех узлов:

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

Узел 5, 6, 7, 8, 3 может повторяться.

Простите, если здесь что-то не понял.

да, это было специально, исходя из того, что там было, но я понимаю, как это может быть загадочным, поэтому лучше сделайте так, чтобы приложение вело себя более четко. Спасибо за патч.

Как вы думаете, как давно существовала эта ошибка? 1.17? 1,16? Я только что видел точно такую ​​же проблему в версии 1.17 на AWS, и перезапуск незапланированного узла устранил проблему.

@judgeaxl не могли бы вы предоставить более подробную информацию? Строки журнала, дампы кеша и т. Д. Итак, мы можем определить, та же проблема.

Как я отмечал в https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695, я считаю, что эта ошибка присутствовала в более старых версиях, но я считаю, что она временная.

@maelk не

Также поделитесь распределением узлов по зонам.

@alculquicondor, к сожалению, сейчас не могу. Сожалею.

@alculquicondor, извините, я уже перестроил кластер по другим причинам, но, возможно, это была проблема конфигурации сети, связанная с развертыванием multi-az, и в какой подсети был запущен неисправный узел, поэтому я не буду беспокоиться об этом сейчас в контекст этого вопроса. Если я замечу это снова, я сообщу более подробную информацию. Благодаря!

/ retitle Некоторые узлы не учитываются при планировании при дисбалансе зон