Kubernetes: Beberapa node tidak dipertimbangkan dalam penjadwalan jika ada ketidakseimbangan zona

/ sig penjadwalan

Dapatkah Anda memberikan yaml lengkap dari node, daemonset, contoh pod, dan namespace yang berisi seperti yang diambil dari server?

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

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

contoh pod (berfungsi):
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

contoh pod (bukan penjadwalan):
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

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

Pod DaemonSet menjadwalkan dengan pemilih nodeAffinity yang hanya cocok dengan satu node, sehingga diharapkan pesan "12 dari 13 tidak cocok".

Saya tidak melihat alasan mengapa penjadwal tidak akan senang dengan pod / node combo… tidak ada port yang dapat mengalami konflik di podspec, node tersebut tidak dapat terjadwal atau tercemar, dan memiliki sumber daya yang cukup

Oke saya restart semua 3 penjadwal (mengubah loglevel menjadi 4 jika kita dapat melihat sesuatu yang menarik di sana). Namun, itu memperbaiki masalah

% 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

sekarang semua daemonset disediakan dengan benar. Aneh, sepertinya ada yang salah dengan penjadwal

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

Kami melihat masalah serupa yang sama di v1.18.3, satu node tidak dapat dijadwalkan untuk pod daemonset.
restart penjadwal membantu.

[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

Sulit untuk melakukan debug tanpa mengetahui cara mereduksi ulang. Apakah Anda kebetulan memiliki log penjadwal untuk pod yang gagal menjadwalkan?

Oke saya restart semua 3 penjadwal

Saya berasumsi hanya satu dari mereka yang bernama default-scheduler , benar?

ubah loglevel menjadi 4 jika kita dapat melihat sesuatu yang menarik di sana

Bisakah Anda membagikan apa yang Anda perhatikan?

set loglevel ke 9, tapi sepertinya tidak ada yang lebih menarik, di bawah ini log yang perulangan.

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)

ya saya tidak bisa melihat lebih dari baris yang sama

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

Yang aneh adalah log message menunjukkan hasil hanya untuk 7 node, seperti masalah yang dilaporkan di https://github.com/kubernetes/kubernetes/issues/91340

/ cc @damemi

@ ahg-g ini memang terlihat seperti masalah yang sama dengan yang saya laporkan di sana, sepertinya kami memiliki plugin filter yang tidak selalu melaporkan kesalahannya atau beberapa kondisi lain yang gagal secara diam-diam jika saya harus menebaknya

Perhatikan bahwa dalam masalah saya, memulai ulang penjadwal juga memperbaikinya (seperti yang disebutkan di utas ini juga https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092)

Milik saya juga tentang daemonset, jadi menurut saya ini adalah duplikat. Jika demikian, kita dapat menutupnya dan melanjutkan diskusi di https://github.com/kubernetes/kubernetes/issues/91340

Anyways scheduler membutuhkan lebih banyak opsi pencatatan verbose, tidak mungkin untuk men-debug masalah ini jika tidak ada log tentang apa yang dilakukannya

@zetaab +1, penjadwal dapat menggunakan peningkatan signifikan pada kemampuan pencatatannya saat ini. Itu adalah peningkatan yang ingin saya tangani untuk sementara waktu dan akhirnya saya membuka masalah untuk itu di sini: https://github.com/kubernetes/kubernetes/issues/91633

/menetapkan

Saya sedang menyelidiki ini. Beberapa pertanyaan untuk membantu saya mempersempit kasus ini. Saya belum bisa mereproduksi.

• Apa yang pertama kali dibuat: daemonset atau node?
• Apakah Anda menggunakan profil default?

• Apakah Anda punya extender?

node dibuat sebelum daemonset.
misalkan kita menggunakan profil default, profil mana yang Anda maksud dan bagaimana cara memeriksanya?
tidak ada extender.

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

Hal lain yang mungkin berdampak adalah kinerja disk tidak terlalu baik untuk etcd, dlld mengeluh tentang operasi yang lambat.

Ya, bendera tersebut akan membuat penjadwal berjalan dengan profil default. Saya akan terus mencari. Saya masih tidak bisa mereproduksi.

Masih tidak ada ... Adakah hal lain yang Anda gunakan yang menurut Anda dapat berdampak? noda, port, sumber daya lainnya?

Melakukan beberapa percobaan terkait dengan ini. Saat masalah aktif, pod masih dapat dijadwalkan ke node (tanpa definisi atau dengan pemilih "nodeName").

Jika mencoba menggunakan Afinitas / Antiaffinity, pod tidak akan dijadwalkan ke node.

Bekerja saat masalah aktif:

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

Tidak bekerja pada saat yang sama:

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

Juga ketika diperiksa yang terakhir bahkan itu cukup menarik:

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.

• Peristiwa pertama adalah ketika manifes baru saja diterapkan (tidak ada yang dilakukan pada node yang tidak dapat dijadwalkan).
• Kedua dan ketiga adalah ketika node dihapus dengan kubectl dan kemudian direstart.
• Keempat datang ketika node muncul kembali. Node yang bermasalah adalah master, jadi node tidak menuju ke sana (tapi menunjukkan bahwa node tidak ditemukan pada 3 kejadian sebelumnya). Hal yang menarik dengan kejadian keempat adalah masih ada informasi dari satu node yang hilang. Acara mengatakan ada 0/9 node yang tersedia, tetapi deskripsi diberikan hanya dari 8.

"nodeName" bukan pemilih. Menggunakan nodeName akan melewati penjadwalan.

Keempat datang ketika node muncul kembali. Node yang bermasalah adalah master, jadi node tidak menuju ke sana (tapi menunjukkan bahwa node tidak ditemukan pada 3 kejadian sebelumnya). Hal yang menarik dengan kejadian keempat adalah masih ada informasi dari satu node yang hilang. Acara mengatakan ada 0/9 node yang tersedia, tetapi deskripsi diberikan hanya dari 8.

Anda mengatakan bahwa alasan mengapa pod seharusnya tidak dijadwalkan di node yang hilang adalah karena ia adalah master?

Kami melihat 8 node(s) didn't match node selector akan 7. Saya berasumsi tidak ada node yang dihapus pada saat ini, benar?

"nodeName" bukan pemilih. Menggunakan nodeName akan melewati penjadwalan.

"NodeName" mencoba menyoroti, node itu dapat digunakan dan pod sampai di sana jika diinginkan. Jadi masalahnya bukan ketidakmampuan node untuk memulai pod.

Keempat datang ketika node muncul kembali. Node yang bermasalah adalah master, jadi node tidak menuju ke sana (tapi menunjukkan bahwa node tidak ditemukan pada 3 kejadian sebelumnya). Hal yang menarik dengan kejadian keempat adalah masih ada informasi dari satu node yang hilang. Acara mengatakan ada 0/9 node yang tersedia, tetapi deskripsi diberikan hanya dari 8.

Anda mengatakan bahwa alasan mengapa pod seharusnya tidak dijadwalkan di node yang hilang adalah karena ia adalah master?

Kami melihat 8 node(s) didn't match node selector akan 7. Saya berasumsi tidak ada node yang dihapus pada saat ini, benar?

Kluster pengujian memiliki 9 node; 3 master dan 6 pekerja. Sebelum node yang tidak berfungsi berhasil dimulai, peristiwa memberi tahu informasi tentang semua node yang tersedia: 0/8 nodes are available: 8 node(s) didn't match node selector. . Tetapi ketika node yang akan cocok dengan pemilih node muncul, acara mengatakan 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. Penjelasan mengatakan bahwa ada 8 yang tidak cocok, tetapi tidak memberi tahu apa-apa tentang yang kesembilan (yang diakui pada acara sebelumnya).

Jadi acara menyatakan:

• Peristiwa pertama: 9 node tersedia, kesalahan diperhatikan dengan daemonset
• Acara ke-2 dan ke-3: 8 node tersedia. Yang tidak menerima pod sedang memulai ulang
• Acara ke-4: 9 node tersedia (jadi yang dimulai yang dimulai ulang).

Pada akhirnya test pod tidak dimulai pada node yang cocok karena taint, tapi itu cerita lain (dan seharusnya sudah menjadi kasus pada event pertama).

"NodeName" mencoba menyoroti, node itu dapat digunakan dan pod sampai di sana jika diinginkan. Jadi masalahnya bukan ketidakmampuan node untuk memulai pod.

Perhatikan bahwa tidak ada perlindungan terhadap node yang melakukan over-commit, kecuali penjadwal. Jadi ini tidak terlalu menunjukkan banyak.

Pada akhirnya test pod tidak dimulai pada node yang cocok karena taint, tapi itu cerita lain (dan seharusnya sudah menjadi kasus pada event pertama).

Pertanyaan saya adalah: apakah node ke-9 tercemar sejak awal? Saya mencoba mencari (1) langkah yang dapat direproduksi untuk mencapai status atau (2) tempat bug berada.

Pertanyaan saya adalah: apakah node ke-9 tercemar sejak awal? Saya mencoba mencari (1) langkah yang dapat direproduksi untuk mencapai status atau (2) tempat bug berada.

Ya, noda ada di sana sepanjang waktu pada kasus ini, karena simpul yang tidak menerima adalah master. Tapi kami telah melihat masalah yang sama baik pada majikan maupun pekerja.

Masih tidak tahu dari mana masalah itu berasal, hanya saja setidaknya pembuatan ulang node dan restart node tampaknya memperbaiki masalah. Tapi itu adalah cara yang agak "sulit" untuk memperbaiki keadaan.

Long shot, tetapi jika Anda bertemu lagi ... dapatkah Anda memeriksa apakah ada pod yang dinominasikan ke node yang tidak muncul?

Saya memposting pertanyaan karena saya memikirkan kemungkinan skenario:

• Apakah Anda memiliki node master lain di cluster Anda?
• Apakah Anda punya extender?

* Do you have other master nodes in your cluster?

Semua pengguna memiliki 3 master (jadi memulai kembali itu mudah)

* Do you have extenders?

Tidak.

Satu hal menarik yang diperhatikan hari ini: Saya memiliki cluster di mana satu master tidak menerima pod dari DaemonSet. Kami menggunakan ChaosMonkey, yang menghentikan salah satu node pekerja. Menariknya, ini membuat pod menuju ke master yang sebelumnya tidak menerimanya. Jadi, entah bagaimana penghapusan node selain yang bermasalah tampaknya memperbaiki masalah pada saat itu.

Karena itu "perbaikan" saya harus menunggu masalah terulang kembali untuk dapat menjawab tentang pod yang dinominasikan.

Saya bingung sekarang ... Apakah daemonset Anda mentolerir noda untuk node master? Dengan kata lain ... apakah bug untuk Anda hanyalah acara penjadwalan atau fakta bahwa pod seharusnya sudah dijadwalkan?

Masalahnya adalah, node itu tidak ditemukan oleh penjadwal meskipun setidaknya ada satu setelan afinitas (atau antiaffinity) yang cocok.

Itu sebabnya saya mengatakan bahwa kesalahan taint diharapkan, dan seharusnya sudah ada di acara pertama (karena taint bukan bagian dari kriteria afinitas)

Dimengerti. Saya mencoba mengonfirmasi penyiapan Anda untuk memastikan saya tidak melewatkan sesuatu.

Saya tidak berpikir node "tak terlihat" oleh penjadwal. Mengingat bahwa kita melihat 0/9 nodes are available , kita dapat menyimpulkan bahwa node tersebut memang ada di cache. Ini lebih seperti alasan yang tidak terjadwal hilang di suatu tempat, jadi kami tidak memasukkannya dalam acara tersebut.

Benar, jumlah total selalu cocok dengan jumlah node sebenarnya. Hanya teks peristiwa yang lebih deskriptif tidak diberikan pada semua node, tetapi itu dapat menjadi masalah terpisah seperti yang Anda sebutkan.

Apakah Anda dapat melihat log kube-scheduler Anda? Apa saja yang tampaknya relevan?

Saya pikir @zetaab mencoba mencari itu tanpa hasil. Saya dapat mencoba ketika masalah terjadi lagi (serta pod yang dinominasikan hal yang ditanyakan sebelumnya)

Jika memungkinkan, jalankan juga 1.18.5, jika kami tidak sengaja memperbaiki masalah.

Saya dapat mereproduksi ini dengan andal di cluster pengujian saya jika Anda memerlukan log lagi

@dilyevsky Silakan bagikan langkah-langkah repro. Dapatkah Anda entah bagaimana mengidentifikasi filter apa yang gagal?

Tampaknya hanya metadata.name dari node untuk ds pod ... aneh. Inilah pod yaml:

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

Cara saya mereproduksi ini adalah dengan memutar cluster baru dengan 3 master dan 3 node pekerja (menggunakan Cluster API) dan menerapkan 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

Berikut log penjadwal:
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

Setelah pod penjadwal dimulai ulang, pod yang tertunda akan segera dijadwalkan.

Acara pod apa yang kamu dapatkan? Tahukah Anda jika ada noda di node
dimana tidak terjadwal? Apakah itu hanya gagal untuk node master atau lainnya
node? Apakah ada cukup ruang di node?

Pada Kamis, 9 Juli 2020, 19.49 dilyevsky, [email protected]
menulis:

Tampaknya hanya metadata.name dari node untuk ds pod ...
aneh. Inilah pod yaml:

apiVersion: v1kind: Podmetadata:
penjelasan:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: "2020-07-09T23: 17: 53Z"
generateName: cilium-
label:
controller-revisi-hash: 6c94db8bb8
k8s-app: cilium
pod-template-generation: "1"
managedFields:
# bidang yang dikelola omong kosong
nama: cilium-d5n4f
namespace: sistem kube
pemilik Referensi:

• apiVersion: apps / v1
  blockOwnerDeletion: benar
  controller: benar
  jenis: DaemonSet
  nama: cilium
  uid: 0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion: "2840"
  selfLink: / api / v1 / namespaces / kube-system / pods / cilium-d5n4f
  uid: e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec:
  afinitas:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchFields:
  - key: metadata.name
  operator: Masuk
  nilai:
  - us-central1-dilyevsky-master-qmwnl
  wadah:
• args:
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    perintah:
  
  
  • cilium-agent
    
    env:
  
  
  • nama: K8S_NODE_NAME
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: spec.nodeName
  
  
  • nama: CILIUM_K8S_NAMESPACE
    
    valueFrom:
    
    fieldRef:
    
    apiVersion: v1
    
    fieldPath: metadata.namespace
  
  
  • nama: CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: flanel-master-device
    
    nama: cilium-config
    
    opsional: benar
  
  
  • nama: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: flannel-uninstall-on-exit
    
    nama: cilium-config
    
    opsional: benar
  
  
  • nama: CILIUM_CLUSTERMESH_CONFIG
    
    nilai: / var / lib / cilium / clustermesh /
  
  
  • nama: CILIUM_CNI_CHAINING_MODE
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: cni-chaining-mode
    
    nama: cilium-config
    
    opsional: benar
  
  
  • nama: CILIUM_CUSTOM_CNI_CONF
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: custom-cni-conf
    
    nama: cilium-config
    
    opsional: benar
    
    gambar: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    lingkaran kehidupan:
    
    postStart:
    
    eksekutif:
    
    perintah:
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = false
      
      
      preStop:
      
      
      eksekutif:
      
      
      perintah:
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe:
      
      
      eksekutif:
      
      
      perintah:
      
      
      
      
      
      
      
      • silia
      
      
      
      
      • status
      
      
      
      
      • --singkat
        
        
        
        KegagalanThreshold: 10
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        SuccessThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        Nama: cilium-agent
        
        
        
        readinessProbe:
        
        
        
        eksekutif:
        
        
        
        perintah:
      
      
      
      
      • silia
      
      
      
      
      • status
      
      
      
      
      • --singkat
        
        
        
        KegagalanThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        SuccessThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        sumber daya: {}
        
        
        
        konteks keamanan:
        
        
        
        kemampuan:
        
        
        
        Menambahkan:
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        hak istimewa: benar
        
        
        
        terminationMessagePath: / dev / termination-log
        
        
        
        terminationMessagePolicy: File
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nama: cilium-run
  
  
  • mountPath: / host / opt / cni / bin
    
    nama: cni-path
  
  
  • mountPath: /host/etc/cni/net.d
    
    nama: etc-cni-netd
  
  
  • mountPath: / var / lib / cilium / clustermesh
    
    nama: rahasia-clustermesh
    
    readOnly: benar
  
  
  • mountPath: / tmp / cilium / config-map
    
    nama: cilium-config-path
    
    readOnly: benar
  
  
  • mountPath: / lib / modules
    
    nama: lib-modules
    
    readOnly: benar
  
  
  • mountPath: /run/xtables.lock
    
    nama: xtables-lock
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nama: cilium-token-j74lr
    
    readOnly: benar
    
    dnsPolicy: ClusterFirst
    
    enableServiceLinks: true
    
    hostNetwork: benar
    
    initContainers:
  
  
• perintah:
  
  
  
  • /init-container.sh
    
    env:
  
  
  • nama: CILIUM_ALL_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: clean-cilium-state
    
    nama: cilium-config
    
    opsional: benar
  
  
  • nama: CILIUM_BPF_STATE
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: clean-cilium-bpf-state
    
    nama: cilium-config
    
    opsional: benar
  
  
  • nama: CILIUM_WAIT_BPF_MOUNT
    
    valueFrom:
    
    configMapKeyRef:
    
    kunci: tunggu-bpf-mount
    
    nama: cilium-config
    
    opsional: benar
    
    gambar: docker.io/cilium/ cilium: v1.7.6
    
    imagePullPolicy: IfNotPresent
    
    nama: clean-cilium-state
    
    sumber daya: {}
    
    konteks keamanan:
    
    kemampuan:
    
    Menambahkan:
    
    
    
    
    
    • NET_ADMIN
      
      
      hak istimewa: benar
      
      
      terminationMessagePath: / dev / termination-log
      
      
      terminationMessagePolicy: File
      
      
      volumeMounts:
    
    
    
  
  
  • mountPath: / var / run / cilium
    
    nama: cilium-run
  
  
  • mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    
    nama: cilium-token-j74lr
    
    readOnly: benar
    
    Prioritas: 2000001000
    
    priorityClassName: system-node-critical
    
    restartPolicy: Selalu
    
    schedulerName: penjadwal-default
    
    securityContext: {}
    
    serviceAccount: cilium
    
    serviceAccountName: cilium
    
    terminationGracePeriodSeconds: 1
    
    toleransi:
  
  
• operator: Ada
• efek: NoExecute
  kunci: node.kubernetes.io/not-ready
  operator: Ada
• efek: NoExecute
  key: node.kubernetes.io/unreachable
  operator: Ada
• efek: NoSchedule
  kunci: node.kubernetes.io/disk-pressure
  operator: Ada
• efek: NoSchedule
  kunci: node.kubernetes.io/memory-pressure
  operator: Ada
• efek: NoSchedule
  kunci: node.kubernetes.io/pid-pressure
  operator: Ada
• efek: NoSchedule
  key: node.kubernetes.io/unschedulable
  operator: Ada
• efek: NoSchedule
  kunci: node.kubernetes.io/network-unavailable
  operator: Ada
  volume:
• hostPath:
  jalur: / var / run / cilium
  ketik: DirectoryOrCreate
  nama: cilium-run
• hostPath:
  jalur: / opt / cni / bin
  ketik: DirectoryOrCreate
  nama: cni-path
• hostPath:
  jalur: /etc/cni/net.d
  ketik: DirectoryOrCreate
  nama: etc-cni-netd
• hostPath:
  jalur: / lib / modules
  Tipe: ""
  nama: lib-modules
• hostPath:
  jalur: /run/xtables.lock
  ketik: FileOrCreate
  nama: xtables-lock
• nama: rahasia-clustermesh
  rahasia:
  defaultMode: 420
  opsional: benar
  secretName: cilium-clustermesh
• configMap:
  defaultMode: 420
  nama: cilium-config
  nama: cilium-config-path
• nama: cilium-token-j74lr
  rahasia:
  defaultMode: 420
  secretName: cilium-token-j74lrstatus:
  kondisi:
• lastProbeTime: null
  lastTransitionTime: "2020-07-09T23: 17: 53Z"
  pesan: '0/6 node tersedia: 5 node (s) tidak cocok dengan pemilih node.'
  alasan: Tidak dapat dijadwalkan
  status: "False"
  type: PodScheduled
  fase: Menunggu keputusan
  qosClass: BestEffort

Cara saya mereproduksi ini adalah dengan memutar kluster baru dengan 2 master dan
3 node pekerja (menggunakan Cluster API) dan menerapkan Cilium 1.7.6:

--- # Sumber: cilium / charts / agent / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nama: cilium
namespace: sistem kube
--- # Sumber: cilium / charts / operator / templates / serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata:
nama: cilium-operator
namespace: sistem kube
--- # Sumber: cilium / charts / config / templates / configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
nama: cilium-config
namespace: kube-systemdata:

# Mode alokasi identitas memilih bagaimana identitas dibagi antara silia
# node dengan mengatur bagaimana mereka disimpan. Opsinya adalah "crd" atau "kvstore".
# - "crd" menyimpan identitas dalam kubernetes sebagai CRD (definisi sumber daya kustom).
# Ini dapat dipertanyakan dengan:
# kubectl mendapatkan ciliumid
# - "kvstore" menyimpan identitas di kvstore, etcd atau konsul
# dikonfigurasi di bawah. Versi Cilium sebelum 1.6 hanya mendukung kvstore
# backend. Upgrade dari versi cilium yang lebih lama ini harus terus digunakan
# kvstore dengan mengomentari mode alokasi-identitas di bawah, atau
# menyetelnya ke "kvstore".
identitas-alokasi-mode: crd

# Jika Anda ingin menjalankan cilium dalam mode debug, ubah nilai ini menjadi true
debug: "false"

# Aktifkan pengalamatan IPv4. Jika diaktifkan, semua titik akhir dialokasikan IPv4
# alamat.
aktifkan-ipv4: "true"

# Aktifkan pengalamatan IPv6. Jika diaktifkan, semua titik akhir dialokasikan IPv6
# alamat.
enable-ipv6: "false"

# Jika Anda ingin monitor cilium untuk mengumpulkan penelusuran paket, setel level ini
# ke "rendah", "sedang", atau "maksimum". Semakin tinggi levelnya, semakin sedikit paketnya
# yang akan terlihat di keluaran monitor.
monitor-agregasi: media

# Interval agregasi monitor mengatur waktu tipikal antara monitor
# peristiwa pemberitahuan untuk setiap koneksi yang diizinkan.
#
# Hanya efektif jika agregasi monitor disetel ke "sedang" atau lebih tinggi.
monitor-agregasi-interval: 5s

# Flag agregasi monitor menentukan flag TCP mana yang, pada
# Pengamatan pertama, menyebabkan pemberitahuan monitor dibuat.
#
# Hanya efektif jika agregasi monitor disetel ke "sedang" atau lebih tinggi.
monitor-aggregation-flags: semua

# ct-global-max-entries- * menentukan jumlah koneksi maksimum
# didukung di semua titik akhir, dipisahkan oleh protokol: tcp atau lainnya. Satu pasang
# peta menggunakan nilai ini untuk koneksi IPv4, dan sepasang peta lainnya
# gunakan nilai-nilai ini untuk koneksi IPv6.
#
# Jika nilai ini diubah, maka selama startup Cilium berikutnya, file
# pelacakan koneksi yang sedang berlangsung mungkin terganggu. Ini mungkin mengarah pada singkat
# penurunan kebijakan atau perubahan dalam keputusan keseimbangan muatan untuk sambungan.
#
# Untuk pengguna yang meningkatkan dari Cilium 1.2 atau sebelumnya, untuk meminimalkan gangguan
# selama proses peningkatan, komentari opsi ini.
bpf-ct-global-tcp-max: "524288"
bpf-ct-global-any-max: "262144"

# bpf-policy-map-max menentukan jumlah entri maksimum di titik akhir
# peta kebijakan (per titik akhir)
bpf-policy-map-max: "16384"

# Pra-alokasi entri peta memungkinkan latensi per paket dikurangi, pada
# biaya alokasi memori di muka untuk entri dalam peta. Itu
# nilai default di bawah ini akan meminimalkan penggunaan memori dalam instalasi default;
# pengguna yang sensitif terhadap latensi dapat mempertimbangkan untuk menyetel ini ke "benar".
#
# Opsi ini diperkenalkan di Cilium 1.4. Cilium 1.3 dan sebelumnya abaikan
# opsi ini dan berperilaku seolah-olah ini disetel ke "benar".
#
# Jika nilai ini diubah, maka selama startup Cilium berikutnya lakukan pemulihan
# dari titik akhir yang ada dan pelacakan koneksi yang sedang berjalan dapat terganggu.
# Ini dapat menyebabkan penurunan kebijakan atau perubahan dalam keputusan keseimbangan beban untuk a
# koneksi untuk beberapa waktu. Endpoint mungkin perlu dibuat ulang untuk memulihkan
# konektivitas.
#
# Jika opsi ini disetel ke "false" selama peningkatan dari 1.3 atau sebelumnya ke
# 1.4 atau yang lebih baru, maka itu dapat menyebabkan gangguan satu kali selama peningkatan.
preallocate-bpf-maps: "false"

# Pencocokan ekspresi reguler yang kompatibel dengan Istio sidecar istio-proxy
# nama gambar container
sidecar-istio-proxy-image: "cilium / istio_proxy"

# Mode enkapsulasi untuk komunikasi antar node
# Nilai yang memungkinkan:
# - dengan disabilitas
# - vxlan (default)
# - geneve
tunnel: vxlan

# Nama cluster. Hanya relevan saat membangun mesh cluster.
nama-cluster: default

# DNS Polling secara berkala mengeluarkan pencarian DNS untuk setiap matchName dari
# cilium-agent. Hasilnya digunakan untuk membuat ulang kebijakan titik akhir.
# Pencarian DNS diulang dengan interval 5 detik, dan dibuat untuk
# A (IPv4) dan alamat AAAA (IPv6). Jika pencarian gagal, IP terbaru
# data digunakan sebagai gantinya. Perubahan IP akan memicu regenerasi Cilium
# kebijakan untuk setiap titik akhir dan menaikkan kebijakan per agen silium
# revisi repositori.
#
# Opsi ini dinonaktifkan secara default mulai dari versi 1.4.x yang mendukung
# implementasi berbasis proxy DNS yang lebih kuat, lihat [0] untuk detailnya.
# Aktifkan opsi ini jika Anda ingin menggunakan kebijakan FQDN tetapi tidak ingin menggunakan
# proxy DNS.
#
# Untuk memudahkan peningkatan, pengguna dapat memilih untuk menyetel opsi ini ke "benar".
# Jika tidak, harap merujuk ke Panduan Peningkatan [1] yang menjelaskan caranya
# persiapkan aturan kebijakan untuk peningkatan.
#
# [0] http://docs.cilium.io/en/stable/policy/language/#dns -based
# [1] http://docs.cilium.io/en/stable/install/upgrade/#changes -yang-mungkin-memerlukan-tindakan
tofqdns-enable-poller: "false"

# wait-bpf-mount membuat kontainer init menunggu hingga sistem file bpf dipasang
tunggu-bpf-mount: "false"

penyamaran: "benar"
aktifkan-xt-socket-fallback: "true"
install-iptables-rules: "true"
auto-direct-node-routes: "false"
kube-proxy-replacement: "probe"
aktifkan-host-layanan-terjangkau: "false"
aktifkan-eksternal-ips: "false"
aktifkan-node-port: "false"
node-port-bind-protection: "true"
aktifkan-auto-protect-node-port-range: "true"
aktifkan-endpoint-health-check: "benar"
aktifkan-identitas-terkenal: "salah"
aktifkan-remote-node-identity: "true"
--- # Sumber: cilium / charts / agent / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
Nama: ciliumrules:

• apiGroups:
  
  
  
  • networking.k8s.io
    
    sumber daya:
  
  
  • networkpolicies
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    sumber daya:
  
  
  • irisan titik akhir
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
• apiGroups:
  
  
  
  • ""
    
    sumber daya:
  
  
  • ruang nama
  
  
  • jasa
  
  
  • node
  
  
  • titik akhir
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
• apiGroups:
  
  
  
  • ""
    
    sumber daya:
  
  
  • polong
  
  
  • node
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
  • memperbarui
  
  
• apiGroups:
  
  
  
  • ""
    
    sumber daya:
  
  
  • node
  
  
  • node / status
    
    kata kerja:
  
  
  • tambalan
  
  
• apiGroups:
  
  
  
  • apiextensions.k8s.io
    
    sumber daya:
  
  
  • customresourcedefinitions
    
    kata kerja:
  
  
  • membuat
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
  • memperbarui
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    sumber daya:
  
  
  • ciliumnetworkpolicies
  
  
  • kebijakan / status ciliumnetwork
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • kebijakan / status ciliumclusterwidenetwork
  
  
  • titik ujung silia
  
  
  • ciliumendpoints / status
  
  
  • ciliumnodes
  
  
  • ciliumnodes / status
  
  
  • ciliumidentities
  
  
  • ciliumidentities / status
    
    kata kerja:
  
  
  • '*'
    
    --- # Sumber: cilium / charts / operator / templates / clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:
    
    nama: cilium-operatorrules:
  
  
• apiGroups:
  
  
  
  • ""
    
    sumber daya:
    
    # untuk secara otomatis menghapus pod dns [core | kube] dns sehingga mulai ada
    
    # dikelola oleh Cilium
  
  
  • polong
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
  • menghapus
  
  
• apiGroups:
  
  
  
  • discovery.k8s.io
    
    sumber daya:
  
  
  • endpointslices
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
• apiGroups:
  
  
  
  • ""
    
    sumber daya:
    
    # untuk secara otomatis membaca dari k8s dan mengimpor CIDR pod node ke cilium
    
    # etcd sehingga semua node tahu bagaimana menjangkau pod lain yang berjalan di pod berbeda
    
    # node.
  
  
  • node
    
    # untuk melakukan penerjemahan CNP yang berisi ToGroup ke titik akhirnya
  
  
  • jasa
  
  
  • titik akhir
    
    # untuk memeriksa konektivitas apiserver
  
  
  • ruang nama
    
    kata kerja:
  
  
  • Dapatkan
  
  
  • daftar
  
  
  • menonton
  
  
• apiGroups:
  
  
  
  • cilium.io
    
    sumber daya:
  
  
  • ciliumnetworkpolicies
  
  
  • kebijakan / status ciliumnetwork
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • kebijakan / status ciliumclusterwidenetwork
  
  
  • titik ujung silia
  
  
  • ciliumendpoints / status
  
  
  • ciliumnodes
  
  
  • ciliumnodes / status
  
  
  • ciliumidentities
  
  
  • ciliumidentities / status
    
    kata kerja:
  
  
  • '*'
    
    --- # Sumber: cilium / charts / agent / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
    
    Nama: ciliumroleRef:
    
    apiGroup: rbac.authorization.k8s.io
    
    Jenis: Peran Gugus
    
    nama: ciliumsubjects:
  
  
• jenis: ServiceAccount
  nama: cilium
  namespace: sistem kube
  --- # Sumber: cilium / charts / operator / templates / clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:
  Nama: cilium-operatorroleRef:
  apiGroup: rbac.authorization.k8s.io
  Jenis: Peran Gugus
  nama: cilium-operatorubjects:
• jenis: ServiceAccount
  nama: cilium-operator
  namespace: sistem kube
  --- # Sumber: cilium / charts / agent / templates / daemonset.yamlapiVersion: apps / v1kind: DaemonSetmetadata:
  label:
  k8s-app: cilium
  nama: cilium
  namespace: kube-systemspec:
  pemilih:
  matchLabels:
  k8s-app: cilium
  template:
  metadata:
  penjelasan:
  # Anotasi ini ditambah dengan toleransi CriticalAddonsOnly
  # cilium menjadi pod penting dalam cluster, yang memastikan cilium
  # mendapat penjadwalan prioritas.
  # https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  scheduler.alpha.kubernetes.io/critical-pod: ""
  label:
  k8s-app: cilium
  spesifikasi:
  wadah:
  
  
  
  • args:
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      perintah:
    
    
    
    • cilium-agent
      
      
      livenessProbe:
      
      
      eksekutif:
      
      
      perintah:
      
      
      
      
      
      
      
      • silia
      
      
      
      
      • status
      
      
      
      
      • --singkat
        
        
        
        KegagalanThreshold: 10
        
        
        
        # Penundaan awal untuk probe keaktifan sengaja dibuat besar
        
        
        
        # Hindari siklus kill & restart yang tak ada habisnya jika jika yang pertama
        
        
        
        # bootstrap membutuhkan waktu lebih lama dari yang diharapkan.
        
        
        
        initialDelaySeconds: 120
        
        
        
        periodSeconds: 30
        
        
        
        SuccessThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        readinessProbe:
        
        
        
        eksekutif:
        
        
        
        perintah:
      
      
      
      
      • silia
      
      
      
      
      • status
      
      
      
      
      • --singkat
        
        
        
        KegagalanThreshold: 3
        
        
        
        initialDelaySeconds: 5
        
        
        
        periodSeconds: 30
        
        
        
        SuccessThreshold: 1
        
        
        
        timeoutSeconds: 5
        
        
        
        env:
      
      
      
      
    
    
    
    • nama: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nama: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nama: CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: flanel-master-device
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: flannel-uninstall-on-exit
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_CLUSTERMESH_CONFIG
      
      
      nilai: / var / lib / cilium / clustermesh /
    
    
    
    • nama: CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: cni-chaining-mode
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: custom-cni-conf
      
      
      nama: cilium-config
      
      
      opsional: benar
      
      
      gambar: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      lingkaran kehidupan:
      
      
      postStart:
      
      
      eksekutif:
      
      
      perintah:
      
      
      
      
      
      
      
      • "/cni-install.sh"
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop:
        
        
        
        eksekutif:
        
        
        
        perintah:
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        Nama: cilium-agent
        
        
        
        konteks keamanan:
        
        
        
        kemampuan:
        
        
        
        Menambahkan:
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          hak istimewa: benar
          
          
          
          
          volumeMounts:
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nama: cilium-run
    
    
    
    • mountPath: / host / opt / cni / bin
      
      
      nama: cni-path
    
    
    
    • mountPath: /host/etc/cni/net.d
      
      
      nama: etc-cni-netd
    
    
    
    • mountPath: / var / lib / cilium / clustermesh
      
      
      nama: rahasia-clustermesh
      
      
      readOnly: benar
    
    
    
    • mountPath: / tmp / cilium / config-map
      
      
      nama: cilium-config-path
      
      
      readOnly: benar
      
      
      # Diperlukan untuk dapat memuat modul kernel
    
    
    
    • mountPath: / lib / modules
      
      
      nama: lib-modules
      
      
      readOnly: benar
    
    
    
    • mountPath: /run/xtables.lock
      
      
      nama: xtables-lock
      
      
      hostNetwork: benar
      
      
      initContainers:
    
    
    
  
  
  • perintah:
    
    
    
    
    
    • /init-container.sh
      
      
      env:
    
    
    
    • nama: CILIUM_ALL_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: clean-cilium-state
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_BPF_STATE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: clean-cilium-bpf-state
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: tunggu-bpf-mount
      
      
      nama: cilium-config
      
      
      opsional: benar
      
      
      gambar: "docker.io/cilium/ cilium: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nama: clean-cilium-state
      
      
      konteks keamanan:
      
      
      kemampuan:
      
      
      Menambahkan:
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        hak istimewa: benar
        
        
        
        volumeMounts:
      
      
      
      
    
    
    
    • mountPath: / var / run / cilium
      
      
      nama: cilium-run
      
      
      restartPolicy: Selalu
      
      
      priorityClassName: system-node-critical
      
      
      serviceAccount: cilium
      
      
      serviceAccountName: cilium
      
      
      terminationGracePeriodSeconds: 1
      
      
      toleransi:
    
    
    
  
  
  • operator: Ada
    
    volume:
    
    # Untuk menjaga status antara restart / upgrade
  
  
  • hostPath:
    
    jalur: / var / run / cilium
    
    ketik: DirectoryOrCreate
    
    nama: cilium-run
    
    # Untuk menginstal plugin cilium cni di host
  
  
  • hostPath:
    
    jalur: / opt / cni / bin
    
    ketik: DirectoryOrCreate
    
    nama: cni-path
    
    # Untuk menginstal konfigurasi cilium cni di host
  
  
  • hostPath:
    
    jalur: /etc/cni/net.d
    
    ketik: DirectoryOrCreate
    
    nama: etc-cni-netd
    
    # Untuk dapat memuat modul kernel
  
  
  • hostPath:
    
    jalur: / lib / modules
    
    nama: lib-modules
    
    # Untuk mengakses iptables secara bersamaan dengan proses lain (misalnya kube-proxy)
  
  
  • hostPath:
    
    jalur: /run/xtables.lock
    
    ketik: FileOrCreate
    
    nama: xtables-lock
    
    # Untuk membaca konfigurasi clustermesh
  
  
  • nama: rahasia-clustermesh
    
    rahasia:
    
    defaultMode: 420
    
    opsional: benar
    
    secretName: cilium-clustermesh
    
    # Untuk membaca konfigurasi dari config map
  
  
  • configMap:
    
    nama: cilium-config
    
    nama: cilium-config-path
    
    updateStrategy:
    
    rollingUpdate:
    
    maxTidak tersedia: 2
    
    jenis: RollingUpdate
    
    --- # Sumber: cilium / charts / operator / templates / deployment.yamlapiVersion: apps / v1kind: Deploymentmetadata:
    
    label:
    
    io.cilium / app: operator
    
    nama: cilium-operator
    
    nama: cilium-operator
    
    namespace: kube-systemspec:
    
    replika: 1
    
    pemilih:
    
    matchLabels:
    
    io.cilium / app: operator
    
    nama: cilium-operator
    
    strategi:
    
    rollingUpdate:
    
    maxSurge: 1
    
    maxTidak tersedia: 1
    
    jenis: RollingUpdate
    
    template:
    
    metadata:
    
    penjelasan:
    
    label:
    
    io.cilium / app: operator
    
    nama: cilium-operator
    
    spesifikasi:
    
    wadah:
  
  
  • args:
    
    
    
    
    
    • --debug = $ (CILIUM_DEBUG)
    
    
    
    • --identitas-alokasi-mode = $ (CILIUM_IDENTITY_ALLOCATION_MODE)
    
    
    
    • --synchronize-k8s-nodes = true
      
      
      perintah:
    
    
    
    • cilium-operator
      
      
      env:
    
    
    
    • nama: CILIUM_K8S_NAMESPACE
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: metadata.namespace
    
    
    
    • nama: K8S_NODE_NAME
      
      
      valueFrom:
      
      
      fieldRef:
      
      
      apiVersion: v1
      
      
      fieldPath: spec.nodeName
    
    
    
    • nama: CILIUM_DEBUG
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: debug
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_CLUSTER_NAME
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: nama-cluster
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_CLUSTER_ID
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: cluster-id
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_IPAM
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: ipam
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: nonaktifkan-endpoint-crd
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_KVSTORE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: kvstore
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_KVSTORE_OPT
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: kvstore-opt
      
      
      nama: cilium-config
      
      
      opsional: benar
    
    
    
    • nama: AWS_ACCESS_KEY_ID
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      kunci: AWS_ACCESS_KEY_ID
      
      
      nama: cilium-aws
      
      
      opsional: benar
    
    
    
    • nama: AWS_SECRET_ACCESS_KEY
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      kunci: AWS_SECRET_ACCESS_KEY
      
      
      nama: cilium-aws
      
      
      opsional: benar
    
    
    
    • nama: AWS_DEFAULT_REGION
      
      
      valueFrom:
      
      
      secretKeyRef:
      
      
      kunci: AWS_DEFAULT_REGION
      
      
      nama: cilium-aws
      
      
      opsional: benar
    
    
    
    • nama: CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom:
      
      
      configMapKeyRef:
      
      
      kunci: identitas-alokasi-mode
      
      
      nama: cilium-config
      
      
      opsional: benar
      
      
      image: "docker.io/cilium/ operator: v1.7.6 "
      
      
      imagePullPolicy: IfNotPresent
      
      
      nama: cilium-operator
      
      
      livenessProbe:
      
      
      httpGet:
      
      
      host: '127.0.0.1'
      
      
      path: / healthz
      
      
      port: 9234
      
      
      skema: HTTP
      
      
      initialDelaySeconds: 60
      
      
      periodSeconds: 10
      
      
      timeoutSeconds: 3
      
      
      hostNetwork: benar
      
      
      restartPolicy: Selalu
      
      
      serviceAccount: cilium-operator
      
      
      serviceAccountName: cilium-operator
    
    
    
  
  

-
Anda menerima ini karena Anda ditugaskan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
.

Bisakah Anda mencoba meningkatkan loglevel dan menggunakan grep untuk memfilter node
atau podnya?

Pada Kamis, 9 Juli 2020, 19:55 dilyevsky, [email protected]
menulis:

Berikut log penjadwal:

I0709 23: 08: 22.056081 1 registry.go: 150] Mendaftarkan predikat EvenPodsSpread dan fungsi prioritas
I0709 23: 08: 23.137451 1 serving.go: 313] Membuat sertifikat yang ditandatangani sendiri di dalam memori
W0709 23: 08: 33.843509 1 otentikasi.go: 297] Kesalahan saat mencari konfigurasi otentikasi dalam cluster: etcdserver: permintaan waktu habis
W0709 23: 08: 33.843671 1 otentikasi.go: 298] Melanjutkan tanpa konfigurasi otentikasi. Ini mungkin memperlakukan semua permintaan sebagai anonim.
W0709 23: 08: 33.843710 1 otentikasi.go: 299] Agar pencarian konfigurasi otentikasi berhasil, setel --authentication-tolerate-lookup-failure = false
I0709 23: 08: 33.911805 1 registry.go: 150] Mendaftarkan predikat EvenPodsSpread dan fungsi prioritas
I0709 23: 08: 33.911989 1 registry.go: 150] Mendaftarkan predikat EvenPodsSpread dan fungsi prioritas
W0709 23: 08: 33.917999 1 otorisasi.go: 47] Otorisasi dinonaktifkan
W0709 23: 08: 33.918162 1 otentikasi.go: 40] Otentikasi dinonaktifkan
I0709 23: 08: 33.918238 1 deprecated_insecure_serving.go: 51] Melayani kesehatan dengan tidak aman di [::]: 10251
I0709 23: 08: 33.925860 1 configmap_cafile_content.go: 202] Memulai client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.926013 1 shared_informer.go: 223] Menunggu cache disinkronkan untuk client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 33.930685 1 secure_serving.go: 178] Melayani dengan aman di 127.0.0.1:10259
I0709 23: 08: 33.936198 1 tlsconfig.go: 240] Memulai DynamicServingCertificateController
I0709 23: 08: 34.026382 1 shared_informer.go: 230] Cache disinkronkan untuk client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-file
I0709 23: 08: 34.036998 1 leaderelection.go: 242] mencoba untuk mendapatkan lease kube-system / kube-scheduler ...
I0709 23: 08: 50.597201 1 leaderelection.go: 252] berhasil memperoleh sewa kube-system / kube-scheduler
E0709 23: 08: 50.658551 1 factory.go: 503] pod: kube-system / coredns-66bff467f8-9rjvd sudah ada dalam antrian aktif
E0709 23: 12: 27.673854 1 factory.go: 503] pod kube-system / cilium-vv466 sudah ada di antrian backoff
E0709 23: 12: 58.099432 1 leaderelection.go: 320] kesalahan saat mengambil kunci sumber daya kube-system / kube-scheduler: etcdserver: leader berubah

Setelah pod penjadwal dimulai ulang, pod yang tertunda akan segera dijadwalkan.

-
Anda menerima ini karena Anda ditugaskan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
.

Ini adalah acara-acara:
Acara:
Ketik Alasan Usia Dari Pesan
---- ------ ---- ---- -------
Peringatan Gagal Penjadwalandefault-scheduler 0/6 node tersedia: 5 node (s) tidak cocok dengan pemilih node.
Peringatan Gagal Penjadwalandefault-scheduler 0/6 node tersedia: 5 node (s) tidak cocok dengan pemilih node.

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

Taints: node-role.kubernetes.io/ master: NoSchedule
node.kubernetes.io/network-un tersedia: 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

Saya akan mencoba meningkatkan level log penjadwal sekarang ...

Pod Anda yaml sebenarnya tidak memiliki toleransi node-role.kubernetes.io/master . Jadi seharusnya tidak dijadwalkan di master.

Hai! Kami mengalami masalah yang sama. Namun, kami melihat masalah yang sama dengan penerapan, di mana kami menggunakan anti-afinitas untuk memastikan sebuah pod dijadwalkan pada setiap node atau pemilih pod yang menargetkan node tertentu.
Cukup membuat sebuah pod dengan pemilih node yang disetel agar sesuai dengan nama host dari node yang gagal sudah cukup untuk menyebabkan kegagalan penjadwalan. Dikatakan bahwa 5 node tidak cocok dengan pemilih, tetapi tidak ada tentang yang keenam. Memulai ulang penjadwal menyelesaikan masalah. Sepertinya ada sesuatu yang di-cache tentang node itu dan mencegah penjadwalan pada node.
Seperti yang dikatakan orang lain sebelumnya, kami tidak memiliki catatan tentang kegagalan tersebut.

Kami menghapus penerapan yang gagal hingga seminimal mungkin (kami telah menghapus noda pada master yang gagal):

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

Kami mengalami masalah yang sama ketika master memiliki noda, dan penerapan toleransi untuk noda. Jadi sepertinya tidak terkait dengan daemonsets, tolerations atau affinity / anti-affinity secara khusus. Ketika kegagalan mulai terjadi, tidak ada yang menargetkan node tertentu yang dapat dijadwalkan. Kami melihat masalah di 1.18.2 hingga 1.18.5 (tidak mencoba dengan 1.18.0 atau .1)

Hanya membuat sebuah pod dengan pemilih node yang disetel agar sesuai dengan nama host dari node yang gagal sudah cukup untuk menyebabkan penjadwalan gagal

Bisakah Anda menjelaskan apakah itu mulai gagal setelah Anda membuat pod seperti itu atau sebelumnya? Saya berasumsi bahwa node ini tidak memiliki noda yang tidak dapat ditoleransi oleh pod.

@nodo akan membantu mereproduksi. Bisakah Anda melihat kode untuk NodeSelector? Anda mungkin perlu menambahkan baris log tambahan saat menguji. Anda juga dapat mencetak cache.

• Dapatkan PID dari kube-scheduler: $ pidof kube-scheduler
• Trigger queue dump: $ sudo kill -SIGUSR2 <pid> . Perhatikan ini tidak akan menghentikan proses penjadwal.
• Kemudian di log penjadwal, cari string "Buang NodeInfo yang di-cache", "Buang antrean penjadwalan" dan "pembanding cache dimulai".

/ prioritas kritis-mendesak

/ unassign

Kami sudah melihat beberapa daemonset dan penerapan terhenti di "Tertunda" sebelum kami mencoba menerapkan penerapan uji ini, jadi itu sudah gagal. dan noda telah dihapus dari node.
Saat ini kami kehilangan lingkungan tempat terjadinya hal ini karena kami harus mereboot node sehingga masalah tidak terlihat lagi. Segera setelah kami mereproduksi, kami akan mencoba kembali dengan info lebih lanjut

Tolong lakukan itu. Saya telah mencoba mereproduksi ini di masa lalu tanpa hasil. Saya lebih tertarik pada contoh kegagalan pertama. Mungkin masih terkait dengan noda.

Kami telah mereproduksi masalah tersebut. Saya menjalankan perintah yang Anda minta, berikut infonya:

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: 

Sayangnya itu sepertinya tidak membantu

Membuang cache untuk debugging, itu tidak akan mengubah apapun. Bisakah Anda memasukkan tempat sampah?

Juga, dengan asumsi ini adalah kesalahan pertama, dapatkah Anda menyertakan pod yaml dan node?

itu hampir semua yang dibuang, saya baru saja menghapus node lainnya. Ini bukan error pertama, tetapi Anda dapat melihat pod coredns di dump, itu yang pertama. Saya tidak yakin apa lagi yang Anda minta di tempat pembuangan sampah.
Aku akan mengambil ubi

Terima kasih, saya tidak menyadari bahwa Anda telah memangkas node dan pod yang relevan.

Bisakah Anda menyertakan pod yang dijadwalkan untuk node itu? Untuk berjaga-jaga jika ada bug dalam penghitungan penggunaan sumber daya.

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

AllowedPodNumber: 0 tampak aneh.

Berikut adalah pod lain di node tersebut:
` 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:

Semua node telah allowPodNumber disetel ke 0 di sumber daya yang diminta di dump, tetapi node lain dapat dijadwalkan

Node 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

dan podnya:

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

Terima kasih banyak atas semua informasinya. @nodo bisakah kau menerimanya?

Kami juga mencoba dengan https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc sekarang, untuk mendapatkan info lebih lanjut

/Tolong

@maelk jangan ragu untuk mengambil ini dan mengirimkan PR jika Anda menemukan bug. Baris log yang Anda tambahkan kemungkinan akan membantu. Jika tidak, saya membuka diri untuk kontributor.

@alculine
Permintaan ini telah ditandai membutuhkan bantuan dari seorang kontributor.

Harap pastikan permintaan tersebut memenuhi persyaratan yang tercantum di sini .

Jika permintaan ini tidak lagi memenuhi persyaratan tersebut, label dapat dihapus
dengan berkomentar menggunakan perintah /remove-help .

/menetapkan

@maelk Apakah ada informasi khusus tentang pengaturan waktu saat masalah ini terjadi pertama kali? Misalnya, apakah itu terjadi tepat setelah node dimulai?

Tidak, ada beberapa pod yang dijadwalkan di sana dan berfungsi dengan baik. Tapi begitu masalah terjadi tidak ada yang bisa dijadwalkan lagi.

Menurunkan prioritas hingga kami memiliki kasus yang dapat direproduksi.

Kami dapat mereproduksi bug dengan penjadwal yang memiliki entri log tambahan. Apa yang kami lihat adalah salah satu master benar-benar menghilang dari daftar node yang diiterasi. Kita dapat melihat bahwa prosesnya dimulai dengan 6 node (dari snapshot):

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

tetapi setelah itu, kita dapat melihat bahwa iterasi hanya lebih dari 5 node, dan kemudian kita mendapatkan:

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

Jadi salah satu node dihapus dari daftar node potensial. Sayangnya kami tidak memiliki cukup pencatatan pada awal proses, tetapi kami akan mencoba untuk mendapatkan lebih banyak.

Referensi kode dengan baris log:

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

@mael
Apakah Anda melihat baris untuk %v/%v on node %v, too many nodes fit ?

Jika tidak, @pancernik dapatkah Anda memeriksa bug di workqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode) ?

Tidak, log itu tidak muncul. Saya juga akan berpikir bisa jadi kita memiliki masalah dengan paralelisasi atau simpul itu disaring sebelumnya. Jika gagal dengan kesalahan di sini: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R464 secara khusus akan terlihat di log sekitar afaik, jadi saya akan mencoba menambahkan entri debug secara khusus fungsi dan paralelisasi.

Saya baru menyadari bahwa satu node akan melalui penyaringan dua kali!

Lognya adalah:

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

Seperti yang Anda lihat, node worker-pool1-60846k0y-scheduler menjalani dua kali pemfilteran

Tidak, log itu tidak muncul. Saya juga akan berpikir bisa jadi kita memiliki masalah dengan paralelisasi atau simpul itu disaring sebelumnya. Jika gagal dengan kesalahan di sini: Nordix @ 5c00cdf # diff -c237cdd9e4cb201118ca380732d7f361R464 itu akan terlihat di log afaik, jadi saya akan mencoba menambahkan lebih banyak entri debug di sekitar fungsi dan paralelisasi secara khusus.

Ya, kesalahan di sana akan bermanifestasi sebagai Kesalahan Penjadwalan dalam acara pod.

Saya baru menyadari bahwa satu node akan melalui penyaringan dua kali!

Sejujurnya saya tidak akan berpikir bahwa paralelisasi memiliki bug (masih perlu diperiksa), tetapi ini bisa menjadi tanda bahwa kami gagal membangun snapshot dari cache (seperti yang kita lihat dari cache dump, cache sudah benar), dengan menambahkan simpul dua kali. Karena status adalah peta, maka masuk akal jika kita hanya "melihat" 5 node pada baris log terakhir.

Ini adalah kode (tip 1.18) https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

Saya akan mencoba menambahkan banyak log pada bagian cache penjadwal, khususnya di sekitar penambahan dan pembaruan node, dan di sekitar snapshot. Namun, dari baris terakhir log, Anda dapat melihat bahwa snapshot sebenarnya benar, dan berisi semua node, jadi apa pun yang terjadi tampaknya akan terjadi nanti, saat mengerjakan snapshot itu

cache! = snapshot

Cache adalah makhluk hidup yang diperbarui dari acara. Snapshot diperbarui (dari cache) sebelum setiap siklus penjadwalan untuk "mengunci" status. Kami menambahkan pengoptimalan untuk membuat proses terakhir ini secepat mungkin. Mungkin saja bug itu ada.

Terima kasih @maelk! Ini sangat berguna. Log Anda menunjukkan bahwa (*nodeinfo.NodeInfo)(0xc000952000) sudah digandakan dalam daftar di https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R441 sebelum kode paralel apa pun dieksekusi. Itu memang berarti bahwa itu diduplikasi sebelum snapshot diperbarui.

Sebenarnya, itu berasal dari snapshot, yang terjadi sebelum pesan log ini: https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R161. Jadi sepertinya konten snapshot memiliki duplikasi, karena berasal dari https://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff -c237cdd9e4cb201118ca380732d7f361R436

Tepat sekali. Maksud saya, itu sudah digandakan sebelum pembaruan snapshot selesai.

Tepat sekali. Maksud saya, itu sudah digandakan sebelum pembaruan snapshot selesai.

Tidak, Snapshot diperbarui di awal siklus penjadwalan. Bug terjadi selama pembaruan snapshot atau sebelum itu. Tetapi cache sudah benar, menurut dump di https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008

EDIT: Saya salah membacanya, saya tidak melihat kata "selesai" :)

Cuplikan update pengoptimalan PR dilakukan di 1.18: https://github.com/kubernetes/kubernetes/pull/85738 dan https://github.com/kubernetes/kubernetes/pull/86919

Saya ingin tahu apakah pohon simpul juga memiliki catatan duplikat

Saya ingin tahu apakah pohon simpul juga memiliki catatan duplikat

@maelk dapatkah Anda menunjukkan dump dari daftar lengkap node di cache?

kami tidak menambah / menghapus item dari NodeInfoList, kami membuat daftar lengkap dari pohon atau tidak, jadi jika ada duplikat, kemungkinan besar itu berasal dari pohon, saya kira.

Hanya untuk mengklarifikasi:
1) cluster memiliki 6 node (termasuk master)
2) node yang seharusnya menjadi host pod tidak diperiksa sama sekali (tidak ada baris log yang menunjukkan itu), yang berarti tidak ada sama sekali di NodeInfoList
3) NodeInfoList memiliki 6 node, tetapi salah satunya merupakan node duplikat

Saya ingin tahu apakah pohon simpul juga memiliki catatan duplikat

@maelk dapatkah Anda menunjukkan dump dari daftar lengkap node di cache?

sebuah dump dari setiap node tree, list dan map akan sangat bagus.

Aku akan berusaha mendapatkannya. Sementara itu, pembaruan kecil. Kita bisa lihat di log:

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

Dan itulah titik yang tepat ketika node yang hilang menghilang. Kemunculan terakhir di log adalah pada 13:37:24. Dalam penjadwalan berikutnya, node yang hilang hilang. jadi sepertinya bug tersebut ada di / mengikuti update node_tree. Semua node melalui pembaruan itu, hanya saja pekerja 608 ini adalah yang terakhir melewatinya.

Saat membuang cache (dengan SIGUSR2) keenam node terdaftar di sana, dengan pod yang berjalan di node, tanpa duplikasi atau node hilang.

Kami akan mencobanya baru dengan menambahkan debug seputar fungsionalitas snapshot: https://github.com/Nordix/kubernetes/commit/53279fb06536558f9a91836c771b182791153791

Node "worker-pool1-60846k0y-scheduler" dalam grup "" dihapus dari NodeTree

Menarik, menurut saya penghapusan / penambahan dipicu oleh panggilan updateNode. Kunci zona hilang saat dihapus, tetapi ada di add, jadi pembaruan pada dasarnya menambahkan label zona dan wilayah?

Apakah Anda memiliki log penjadwal lain yang terkait dengan node ini?

Kami mencoba mereproduksi bug dengan logging yang ditambahkan. Saya akan kembali lagi jika ada info lebih lanjut

Aku akan berusaha mendapatkannya. Sementara itu, pembaruan kecil. Kita bisa lihat di log:

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

Saya akan menunjukkan bahwa simpul tersebut adalah simpul yang diulang. @maelk , apakah Anda melihat pesan serupa untuk node lain atau tidak sama sekali? Seperti @ ahg-g, ini diharapkan saat node menerima label topologinya untuk pertama kalinya.

ya, itu terjadi untuk semua node, dan memang diharapkan. Kebetulan simpul ini secara khusus adalah yang terakhir diperbarui, dan pada saat itulah simpul lainnya hilang

Apakah Anda mendapatkan log pembaruan untuk node yang hilang?

Apakah Anda mendapatkan log pembaruan untuk node yang hilang?

lol, baru saja mengetik pertanyaan ini.

mungkin bugnya adalah seluruh zona dihapus dari pohon sebelum semua node dihapus.

Hanya untuk memperjelas, saya tidak secara pribadi melihat kodenya, saya hanya mencoba memastikan kami memiliki semua informasi. Dan menurut saya, dengan apa yang kita miliki sekarang, kita harus bisa menemukan bugnya. Jangan ragu untuk mengirimkan PR dan jauh lebih baik jika Anda dapat memberikan tes unit yang gagal.

Apakah Anda mendapatkan log pembaruan untuk node yang hilang?

ya, ini menunjukkan bahwa zona diperbarui untuk node yang hilang tersebut. Ada entri log untuk semua node

Sejujurnya, saya masih belum tahu alasan bug tersebut, tetapi jika kami hampir dapat mengetahuinya, saya akan mengirimkan PR atau unit test.

ya, ini menunjukkan bahwa zona diperbarui untuk node yang hilang tersebut. Ada entri log untuk semua node

Jika demikian, maka saya pikir dengan asumsi bahwa ini "adalah titik yang tepat ketika node yang hilang menghilang." mungkin tidak berkorelasi. Mari kita tunggu log baru. Akan lebih bagus jika Anda dapat membagikan semua log penjadwal yang Anda dapatkan dalam sebuah file.

Saya akan lakukan saat kami mereproduksi dengan logging baru. Dari yang sudah ada, kita benar-benar dapat melihat bahwa penjadwalan pod segera setelah update tersebut adalah yang pertama gagal. Tetapi tidak memberikan informasi yang cukup untuk mengetahui apa yang terjadi di antaranya, jadi pantau terus ...

@maelk Pernahkah Anda melihat pesan yang dimulai dengan snapshot state is not consistent di log penjadwal?

Apakah mungkin bagi Anda untuk memberikan log penjadwal lengkap?

tidak, pesan itu tidak ada. Saya bisa memberikan file log bergaris-garis (untuk menghindari pengulangan), tetapi mari kita tunggu dulu sampai kita memiliki output dengan lebih banyak log di sekitar snapshot

Saya telah menemukan bugnya. Masalahnya adalah dengan fungsi nodeTree next (), yang tidak mengembalikan daftar semua node dalam beberapa kasus. https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

Ini terlihat jika Anda menambahkan yang berikut ini di sini: 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"},
},

Masalah utamanya adalah ketika Anda menambahkan node, indeks tidak berada di 0 untuk beberapa zona. Agar ini terjadi, Anda harus memiliki setidaknya dua zona, yang satu lebih pendek dari yang lain, dan zona yang lebih panjang memiliki indeks yang tidak disetel ke 0 saat memanggil fungsi berikutnya untuk pertama kalinya.

Perbaikan yang saya lakukan adalah mengatur ulang indeks sebelum memanggil next () untuk pertama kalinya. Saya membuka PR untuk menunjukkan perbaikan saya. Tentu saja ini bertentangan dengan rilis 1,18 karena inilah yang sedang saya kerjakan, tetapi sebagian besar untuk membahas cara memperbaikinya (atau mungkin memperbaiki fungsi next () itu sendiri). Saya bisa membuka PR yang tepat untuk master dan melakukan backports jika diperlukan setelahnya.

Saya melihat masalah yang sama dengan iterasi. Tapi saya gagal menautkannya ke duplikat di snapshot. Sudahkah Anda berhasil membuat skenario di mana itu akan terjadi, @maelk?

ya, Anda dapat menjalankannya di unit test dengan menambahkan kode kecil yang saya masukkan

Sekarang saya sedang bekerja menambahkan kasus uji untuk snapshot, untuk memastikan ini diuji dengan benar.

jempol ke @igraecao atas bantuannya dalam mereproduksi masalah dan menjalankan pengujian dalam penyiapannya

Terima kasih semua telah men-debug masalah terkenal ini. Menyetel ulang indeks sebelum membuat daftar aman, jadi saya pikir kita harus menggunakan itu untuk tambalan 1,18 dan 1,19, dan memiliki perbaikan yang tepat di cabang utama.

Tujuan dari fungsi next diubah dengan diperkenalkannya NodeInfoList, sehingga kita dapat menyederhanakannya dan mungkin mengubahnya menjadi toList , sebuah fungsi yang membuat daftar dari pohon dan langsung memulai dari awal setiap saat.

Saya memahami masalahnya sekarang: Perhitungan apakah zona habis atau tidak salah karena tidak mempertimbangkan di mana di setiap zona kami memulai proses "UpdateSnapshot" ini. Dan ya, itu hanya akan terlihat dengan zona yang tidak rata.

Kerja bagus melihat @maelk ini!

Saya akan berpikir kami memiliki masalah yang sama di versi yang lebih lama. Namun, itu tersembunyi oleh fakta bahwa kami melakukan peralihan pohon setiap saat. Sedangkan di 1.18 kita snapshot hasilnya sampai ada perubahan pada tree.

Sekarang strategi round-robin diimplementasikan di generic_scheduler.go, kita mungkin baik-baik saja dengan hanya mengatur ulang semua penghitung sebelum UpdateSnapshot, seperti yang dilakukan PR Anda.

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

Hanya untuk memeriksa ulang @ ahg-g, ini akan baik-baik saja bahkan dalam sebuah cluster dimana node baru ditambahkan / dihapus sepanjang waktu, bukan?

Terima kasih @maelk karena telah menemukan akar masalahnya!

Tujuan dari fungsi selanjutnya berubah dengan diperkenalkannya NodeInfoList, sehingga kita dapat menyederhanakannya dan mungkin mengubahnya menjadi toList, sebuah fungsi yang membuat daftar dari pohon dan hanya memulai dari awal setiap saat.

Mengingat bahwa cache.nodeTree.next() hanya dipanggil dalam membangun snapshot nodeInfoList, saya rasa juga aman untuk menghapus indeks (baik zoneIndex dan nodeIndex) dari struct nodeTree. Sebagai gantinya, buat fungsi nodeIterator() untuk beralih melalui zona / node secara round-robin.

BTW: ada kesalahan ketik di https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090, kasusnya harus:

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

Hanya untuk memeriksa ulang @ ahg-g, ini akan baik-baik saja bahkan dalam sebuah cluster dimana node baru ditambahkan / dihapus sepanjang waktu, bukan?

Saya berasumsi Anda berbicara tentang logika di generic_scheduler.go, jika demikian ya, tidak masalah jika node ditambahkan atau dihapus, hal utama yang perlu kita hindari adalah mengulang node dalam urutan yang sama setiap saat kami menjadwalkan sebuah pod, kami hanya membutuhkan perkiraan yang baik untuk melakukan iterasi terhadap node di seluruh pod.

Mengingat bahwa cache.nodeTree.next () hanya dipanggil dalam membangun snapshot nodeInfoList, saya rasa juga aman untuk menghapus indeks (baik zoneIndex dan nodeIndex) dari struct nodeTree. Sebagai gantinya, buat fungsi nodeIterator () sederhana untuk melakukan iterasi melalui zona / node secara round-robin.

ya, kita hanya perlu melakukan iterasi ke semua zona / node dalam urutan yang sama setiap saat.

Saya telah memperbarui PR dengan pengujian unit untuk fungsi yang memperbarui daftar snapshot, khusus untuk bug itu. Saya juga dapat menangani refactoring fungsi next () untuk mengulangi zona dan node tanpa round-robin, sehingga menghilangkan masalah.

Terima kasih, kedengarannya bagus, tapi kita tetap harus beralih antar zona seperti yang kita lakukan sekarang, yaitu dengan desain.

Saya tidak begitu mengerti apa yang Anda maksud di sini. Apakah agar urutan node penting dan kita masih harus berputar-putar antar zona atau dapatkah kita membuat daftar semua node dari suatu zona, satu zona setelah zona lainnya? Katakanlah Anda memiliki dua zona dengan masing-masing dua node, dalam urutan apa Anda mengharapkannya, atau apakah itu penting sama sekali?

Urutannya penting, kita perlu bergantian antar zona saat membuat daftar. Jika Anda memiliki dua zona dari dua node masing-masing z1: {n11, n12} dan z2: {n21, n22} , maka daftarnya harus {n11, n21, n12, n22}

ok, terima kasih, saya akan memikirkannya. Sementara itu, bisakah kita melanjutkan dengan perbaikan cepat? btw, beberapa tes gagal, tapi saya tidak yakin bagaimana hubungannya dengan PR saya

Itu adalah serpihan. Silakan kirim tambalan ke 1,18 juga.

OK akan ku lakukan. Terima kasih

{
  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 , maksud Anda pengujian ini mengabaikan 'node-5'?

Saya menemukan setelah memperbaiki append di https://github.com/kubernetes/kubernetes/pull/93516 , hasil tes semua node dapat diiterasi:

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

Node-5, 6, 7, 8, 3 dapat diiterasi.

Maafkan saya jika salah paham di sini.

ya, itu sengaja, berdasarkan apa yang ada di sana, tapi saya bisa melihat bagaimana ini bisa menjadi samar, jadi lebih baik buatlah sehingga lampiran berperilaku dengan cara yang lebih jelas. Terima kasih untuk tambalannya.

Seberapa jauh Anda yakin bug ini ada? 1,17? 1,16? Saya baru saja melihat masalah yang sama persis di 1.17 di AWS dan memulai ulang node yang tidak terjadwal memperbaiki masalah.

@judgeaxl dapatkah Anda memberikan detail selengkapnya? Baris log, cache dump, dll. Jadi kami dapat menentukan apakah masalahnya sama.

Seperti yang saya catat di https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695, saya yakin bug ini ada di versi yang lebih lama, tetapi menurut saya bug ini bersifat sementara.

@maelk, apakah Anda dapat menyelidikinya?

Silakan juga bagikan distribusi node di zona.

@alculquicondor sayangnya saya tidak bisa saat ini. Maaf.

@alculquicondor maaf, saya sudah membangun kembali cluster karena alasan lain, tetapi mungkin ini adalah masalah konfigurasi jaringan yang terkait dengan penerapan multi-az, dan dalam subnet apa node yang salah diluncurkan, jadi saya tidak akan mengkhawatirkannya untuk saat ini di konteks masalah ini. Jika saya menyadarinya lagi, saya akan melaporkan kembali dengan detail yang lebih baik. Terima kasih!

/ retitle Beberapa node tidak dipertimbangkan dalam penjadwalan jika ada ketidakseimbangan zona