Kubernetes: ゾーンの不均衡がある場合、一部のノードはスケジューリングで考慮されません

/ sigスケジューリング

ノード、デーモンセット、サンプルポッド、およびサーバーから取得した名前空間の完全なyamlを提供できますか？

ノード：
https://gist.github.com/zetaab/2a7e8d3fe6cb42a617e17abc0fa375f7

デーモンセット：
https://gist.github.com/zetaab/31bb406c8bd622b3017bf4f468d0154f

ポッドの例（動作中）：
https://gist.github.com/zetaab/814871bec6f2879e371f5bbdc6f2e978

ポッドの例（スケジューリングではありません）：
https://gist.github.com/zetaab/f3488d65486c745af78dbe2e6173fd42

名前空間：
https://gist.github.com/zetaab/4625b759f4e21b50757c79e5072cd7d9

DaemonSetポッドは、単一のノードにのみ一致するnodeAffinityセレクターでスケジュールされるため、「13のうち12が一致しませんでした」というメッセージが表示されます。

スケジューラーがポッド/ノードの組み合わせに不満を抱く理由がわかりません…podspecで競合する可能性のあるポートがなく、ノードがスケジュール不能または汚染されておらず、十分なリソースがあります

さて、3つすべてのスケジューラーを再起動しました（そこに何か面白いものが見られる場合は、ログレベルを4に変更しました）。 ただし、問題は修正されました

% kubectl get ds --all-namespaces
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
falco         falco-daemonset            13        13        13      13           13          <none>                            338d
kube-system   audit-webhook-deployment   3         3         3       3            3           node-role.kubernetes.io/master=   175d
kube-system   calico-node                13        13        13      13           13          kubernetes.io/os=linux            36d
kube-system   kops-controller            3         3         3       3            3           node-role.kubernetes.io/master=   194d
kube-system   metricbeat                 6         6         6       6            6           <none>                            36d
kube-system   openstack-cloud-provider   3         3         3       3            3           node-role.kubernetes.io/master=   338d
logging       fluent-bit                 13        13        13      13           13          <none>                            338d
monitoring    node-exporter              13        13        13      13           13          kubernetes.io/os=linux            59d
volume        csi-cinder-nodeplugin      6         6         6       6            6           <none>                            239d
weave         weave-scope-agent          13        13        13      13           13          <none>                            194d
weave         weavescope-iowait-plugin   6         6         6       6            6           <none>                            194d

これで、すべてのデーモンセットが正しくプロビジョニングされます。 奇妙な、とにかくスケジューラーに何か問題があるようです

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

v1.18.3でも同様の問題が発生し、デーモンセットポッドに対して1つのノードをスケジュールできません。
再起動スケジューラが役立ちます。

[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get pod -A|grep Pending
kube-system   coredns-vc5ws                                                 0/1     Pending   0          2d16h
kube-system   local-volume-provisioner-mwk88                                0/1     Pending   0          2d16h
kube-system   svcwatcher-ltqb6                                              0/1     Pending   0          2d16h
ncms          bcmt-api-hfzl6                                                0/1     Pending   0          2d16h
ncms          bcmt-yum-repo-589d8bb756-5zbvh                                0/1     Pending   0          2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get ds -A
NAMESPACE     NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
kube-system   coredns                    3         3         2       3            2           is_control=true                 2d16h
kube-system   danmep-cleaner             0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   kube-proxy                 8         8         8       8            8           <none>                          2d16h
kube-system   local-volume-provisioner   8         8         7       8            7           <none>                          2d16h
kube-system   netwatcher                 0         0         0       0            0           cbcs.nokia.com/danm_node=true   2d16h
kube-system   sriov-device-plugin        0         0         0       0            0           sriov=enabled                   2d16h
kube-system   svcwatcher                 3         3         2       3            2           is_control=true                 2d16h
ncms          bcmt-api                   3         3         0       3            0           is_control=true                 2d16h
[root@tesla-cb0434-csfp1-csfp1-control-03 ~]# kubectl get node
NAME                                  STATUS   ROLES    AGE     VERSION
tesla-cb0434-csfp1-csfp1-control-01   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-02   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-control-03   Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-01      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-edge-02      Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-01    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-02    Ready    <none>   2d16h   v1.18.3
tesla-cb0434-csfp1-csfp1-worker-03    Ready    <none>   2d16h   v1.18.3

再現する方法を知らずにデバッグするのは難しい。 ポッドのスケジュールに失敗した場合に備えて、スケジューラログがありますか？

さて、3つすべてのスケジューラーを再起動しました

そのうちの1つだけがdefault-schedulerという名前だと思いますよね？

何か面白いものが見られる場合は、ログレベルを4に変更しました

あなたが気づいたことを共有できますか？

loglevelを9に設定しますが、これ以上興味深いものはないようです。以下のログはループしています。

I0601 01:45:05.039373       1 generic_scheduler.go:290] Preemption will not help schedule pod kube-system/coredns-vc5ws on any node.
I0601 01:45:05.039437       1 factory.go:462] Unable to schedule kube-system/coredns-vc5ws: no fit: 0/8 nodes are available: 7 node(s) didn't match node selector.; waiting
I0601 01:45:05.039494       1 scheduler.go:776] Updating pod condition for kube-system/coredns-vc5ws to (PodScheduled==False, Reason=Unschedulable)

ええ、私は同じ行以上のものを見ることができませんでした

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

奇妙なことに、 https：//github.com/kubernetes/kubernetes/issues/91340で報告されている問題のように、ログメッセージには7つのノードの結果のみが表示され

/ cc @damemi

@ ahg-gこれは私がそこで報告したのと同じ問題のように見えます、エラーを常に報告するとは限らないフィルタープラグインがあるか、推測しなければならない場合にサイレントに失敗する他の条件があるようです

私の問題では、スケジューラーを再起動するとそれも修正されたことに注意してください（このスレッドでも言及されているようにhttps://github.com/kubernetes/kubernetes/issues/91601#issuecomment-636360092）

私もデーモンセットに関するものだったので、これは重複していると思います。 その場合は、これを閉じてhttps://github.com/kubernetes/kubernetes/issues/91340でディスカッションを続けることができ

とにかく、スケジューラーはより詳細なログオプションを必要とします。それが何をするかについてのログがない場合、これらの問題をデバッグすることは不可能です。

@zetaab +1の場合、スケジューラーは現在のロギング機能を大幅に改善することができます。 これは私がしばらく取り組むつもりだったアップグレードであり、ついにここで問題を開きました： https ：

/割当

私はこれを調べています。 ケースを絞り込むのに役立ついくつかの質問。 まだ再現できていません。

• 最初に作成されたもの：デーモンセットまたはノード？
• デフォルトのプロファイルを使用していますか？

• エクステンダーはありますか？

ノードはデーモンセットの前に作成されました。
デフォルトのプロファイルを使用したとしましょう。どのプロファイルを意味し、どのように確認するのですか？
エクステンダーはありません。

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

影響を与える可能性のあるもう1つのことは、ディスクのパフォーマンスがetcdにとってあまり良くないことです。また、etcdは動作が遅いと不平を言います。

はい、これらのフラグにより​​、スケジューラーはデフォルトのプロファイルで実行されます。 探し続けます。 まだ再現できませんでした。

まだ何もありません...あなたが使用している他に影響を与える可能性があると思うものはありますか？ 汚染、ポート、その他のリソース？

これに関連していくつかの試みをしました。 問題が発生している場合でも、ポッドをノードにスケジュールできます（定義なしまたは「nodeName」セレクターを使用）。

Affinity / Antiaffinityを使用しようとすると、ポッドはノードにスケジュールされません。

問題が発生しているときに機能する：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  nodeName: master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

同時に機能しない：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - master-zone-3-1-1-test-cluster-k8s-local
  containers:
    - image: nginx
      name: nginx
      resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

また、後者をチェックすると、それらも非常に興味深いものでした。

Warning  FailedScheduling  4m37s (x17 over 26m)  default-scheduler  0/9 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  97s (x6 over 3m39s)   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  53s                   default-scheduler  0/8 nodes are available: 8 node(s) didn't match node selector.
Warning  FailedScheduling  7s (x5 over 32s)      default-scheduler  0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector.

• 最初のイベントは、マニフェストが適用されたときです（スケジュール不可能なノードには何も行われません）。
• 2番目と3番目は、ノードがkubectlで削除され、再起動されたときです。
• 4番目は、ノードが復旧したときに発生しました。 問題が発生したノードはマスターであったため、ノードはそこに移動しませんでした（ただし、以前の3つのイベントでノードが見つからなかったことを示しています）。 4番目のイベントで興味深いのは、1つのノードからの情報がまだ欠落していることです。 イベントでは、0/9ノードが使用可能であると示されていますが、説明は8からのみです。

「nodeName」はセレクターではありません。 nodeNameを使用すると、スケジューリングがバイパスされます。

4番目は、ノードが復旧したときに発生しました。 問題が発生したノードはマスターであったため、ノードはそこに移動しませんでした（ただし、以前の3つのイベントでノードが見つからなかったことを示しています）。 4番目のイベントで興味深いのは、1つのノードからの情報がまだ欠落していることです。 イベントでは、0/9ノードが使用可能であると示されていますが、説明は8からのみです。

ポッドが欠落しているノードでスケジュールされるべきではなかった理由は、それがマスターであったためだと言っていますか？

8 node(s) didn't match node selectorが7になっているのがわかります。この時点で削除されたノードはないと思いますよね？

「nodeName」はセレクターではありません。 nodeNameを使用すると、スケジューリングがバイパスされます。

「NodeName」の試みはhighlighでした。そのノードは使用可能であり、必要に応じてポッドがそこに到達します。 つまり、ノードがポッドを起動できないことではありません。

4番目は、ノードが復旧したときに発生しました。 問題が発生したノードはマスターであったため、ノードはそこに移動しませんでした（ただし、以前の3つのイベントでノードが見つからなかったことを示しています）。 4番目のイベントで興味深いのは、1つのノードからの情報がまだ欠落していることです。 イベントでは、0/9ノードが使用可能であると示されていますが、説明は8からのみです。

ポッドが欠落しているノードでスケジュールされるべきではなかった理由は、それがマスターであったためだと言っていますか？

8 node(s) didn't match node selectorが7になっているのがわかります。この時点で削除されたノードはないと思いますよね？

テストクラスターには9つのノードがあります。 3人のマスターと6人の労働者。 動作していないノードが正常に開始される前に、イベントは使用可能なすべてのノードに関する情報を通知しました： 0/8 nodes are available: 8 node(s) didn't match node selector. 。 しかし、ノードセレクターと一致するノードが起動すると、イベントは0/9 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 7 node(s) didn't match node selector.を通知しました。説明は、一致しない8つがあることを示していますが、9番目（前のイベントで確認済み）については何も通知していません。

したがって、イベントの状態：

• 最初のイベント：9ノードが使用可能、daemonsetでエラーが通知されました
• 2番目と3番目のイベント：8ノードが使用可能です。 ポッドを受信して​​いなかったものが再起動していました
• 4番目のイベント：9つのノードが使用可能です（したがって、1つが開始され、再起動されました）。

最後に、テストポッドは汚染のために一致するノードで開始されませんでしたが、それは別の話です（そして、最初のイベントですでにそうであったはずです）。

「NodeName」の試みはhighlighでした。そのノードは使用可能であり、必要に応じてポッドがそこに到達します。 つまり、ノードがポッドを起動できないことではありません。

ノードのオーバーコミットを防ぐものは何もありませんが、スケジューラーであることに注意してください。 したがって、これは実際にはあまり表示されません。

最後に、テストポッドは汚染のために一致するノードで開始されませんでしたが、それは別の話です（そして、最初のイベントですでにそうであったはずです）。

私の質問は、9番目のノードが最初から汚染されていたのかということです。 （1）状態に到達するための再現可能な手順、または（2）バグが発生する可能性のある場所を探しています。

私の質問は、9番目のノードが最初から汚染されていたのかということです。 （1）状態に到達するための再現可能な手順、または（2）バグが発生する可能性のある場所を探しています。

はい、この場合、非受信ノードがマスターであったため、汚染が常に存在していました。 しかし、マスターとワーカーの両方で同じ問題が発生しています。

問題がどこから来ているのかはまだわかりません。少なくともノードの再作成とノードの再起動によって問題が修正されているようです。 しかし、それらは物事を修正するための少し「難しい」方法です。

ロングショットですが、もう一度遭遇した場合は...ノードに指定されたポッドが表示されないかどうかを確認できますか？

考えられるシナリオを考えて、質問を投稿しています。

• クラスター内に他のマスターノードがありますか？
• エクステンダーはありますか？

* Do you have other master nodes in your cluster?

すべてのclusersには3つのマスターがあります（したがって、それらの再起動は簡単です）

* Do you have extenders?

番号。

今日気付いた興味深い点の1つは、1つのマスターがDaemonSetからポッドを受信して​​いないクラスターがあったことです。 ChaosMonkeyが使用されており、ワーカーノードの1つが終了しました。 これは興味深いことです。これにより、ポッドは以前に受信していなかったマスターに移動しました。 したがって、問題のあるノード以外のノードを削除することで、その時点で問題が修正されているように見えました。

その「修正」のために、指定されたポッドについて回答できるようになるには、問題が再発するのを待つ必要があります。

私は今混乱しています...あなたのデーモンセットはマスターノードの汚染を許容しますか？ 言い換えれば...あなたにとってのバグは単なるスケジュールイベントですか、それともポッドがスケジュールされるべきだったという事実ですか？

問題は、一致するアフィニティ（またはアンチアフィニティ）設定が少なくとも1つある場合でも、そのノードがスケジューラによって検出されないことです。

そのため、汚染エラーが予想され、最初のイベントですでに存在しているはずだと言いました（汚染は親和性基準の一部ではないため）

理解しました。 私はあなたのセットアップを確認して、何かが足りないことを確認しようとしていました。

ノードがスケジューラーによって「見えない」とは思わない。 0/9 nodes are availableが表示されている場合、ノードは実際にキャッシュ内にあると結論付けることができます。 予定外の理由がどこかで失われたようなものなので、イベントには含めません。

確かに、合計数は常に実際のノード数と一致します。 より説明的なイベントテキストがすべてのノードに表示されるわけではありませんが、前述のように別の問題になる可能性があります。

kube-schedulerのログを見ることができますか？ 関連すると思われるものはありますか？

@zetaabはそれをなかったと思います。 問題が再び発生したときに試すことができます（および以前に尋ねられた指名されたポッドのこと）

可能であれば、誤って問題を修正した場合に備えて、1.18.5も実行してください。

これ以上ログが必要な場合は、テストクラスターでこれを確実に再現できます。

@dilyevsky再現手順を共有してください。 何とかして、失敗しているフィルターを特定できますか？

これは、dsポッドのノードのmetadata.nameにすぎないようです...奇妙です。 これがポッド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

これを再現する方法は、3つのマスターと3つのワーカーノードで新しいクラスターを起動し（クラスターAPIを使用）、Cilium1.7.6を適用することです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スケジューラログは次のとおりです。
I0709 23:08:22.055830 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:22.056081 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:23.137451 1 serving.go:313] Generated self-signed cert in-memory W0709 23:08:33.843509 1 authentication.go:297] Error looking up in-cluster authentication configuration: etcdserver: request timed out W0709 23:08:33.843671 1 authentication.go:298] Continuing without authentication configuration. This may treat all requests as anonymous. W0709 23:08:33.843710 1 authentication.go:299] To require authentication configuration lookup to succeed, set --authentication-tolerate-lookup-failure=false I0709 23:08:33.911805 1 registry.go:150] Registering EvenPodsSpread predicate and priority function I0709 23:08:33.911989 1 registry.go:150] Registering EvenPodsSpread predicate and priority function W0709 23:08:33.917999 1 authorization.go:47] Authorization is disabled W0709 23:08:33.918162 1 authentication.go:40] Authentication is disabled I0709 23:08:33.918238 1 deprecated_insecure_serving.go:51] Serving healthz insecurely on [::]:10251 I0709 23:08:33.925860 1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.926013 1 shared_informer.go:223] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:33.930685 1 secure_serving.go:178] Serving securely on 127.0.0.1:10259 I0709 23:08:33.936198 1 tlsconfig.go:240] Starting DynamicServingCertificateController I0709 23:08:34.026382 1 shared_informer.go:230] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0709 23:08:34.036998 1 leaderelection.go:242] attempting to acquire leader lease kube-system/kube-scheduler... I0709 23:08:50.597201 1 leaderelection.go:252] successfully acquired lease kube-system/kube-scheduler E0709 23:08:50.658551 1 factory.go:503] pod: kube-system/coredns-66bff467f8-9rjvd is already present in the active queue E0709 23:12:27.673854 1 factory.go:503] pod kube-system/cilium-vv466 is already present in the backoff queue E0709 23:12:58.099432 1 leaderelection.go:320] error retrieving resource lock kube-system/kube-scheduler: etcdserver: leader changed

スケジューラポッドを再起動すると、保留中のポッドはすぐにスケジュールを設定します。

どのポッドイベントを取得しますか？ ノードに汚染があるかどうか知っていますか
スケジュールされていないところは？ マスターノードまたはいずれかでのみ失敗しますか
ノード？ ノードに十分なスペースがありますか？

2020年7月9日木曜日、午後7時49分dilyevsky、 notifications @ github.com
書きました：

これは、dsポッドのノードのmetadata.nameにすぎないようです...
変だ。 これがポッドyamlです：

apiVersion：v1kind：Podmetadata：
注釈：
Scheduler.alpha.kubernetes.io/critical-pod： ""
CreationTimestamp： "2020-07-09T23：17：53Z"
generateName：繊毛-
ラベル：
controller-revision-hash：6c94db8bb8
k8s-app：繊毛
pod-template-generation： "1"
managedFields：
＃管理フィールドがらくた
名前：繊毛-d5n4f
名前空間：kube-system
ownerReferences：

• apiVersion：apps / v1
  blockOwnerDeletion：true
  コントローラー：true
  種類：DaemonSet
  名前：繊毛
  uid：0f00e8af-eb19-4985-a940-a02fa84fcbc5
  resourceVersion： "2840"
  selfLink：/ api / v1 / namespaces / kube-system / pods / cilium-d5n4f
  uid：e3f7d566-ee5b-4557-8d1b-f0964cde2f22spec：
  親和性：
  nodeAffinity：
  requiredDuringSchedulingIgnoredDuringExecution：
  nodeSelectorTerms：
  --matchFields：
  -キー：metadata.name
  演算子：で
  値：
  --us-central1-dilyevsky-master-qmwnl
  コンテナ：
• 引数：
  
  
  
  • --config-dir = / tmp / cilium / config-map
    
    コマンド：
  
  
  • 繊毛剤
    
    env：
  
  
  • 名前：K8S_NODE_NAME
    
    valueFrom：
    
    fieldRef：
    
    apiVersion：v1
    
    fieldPath：spec.nodeName
  
  
  • 名前：CILIUM_K8S_NAMESPACE
    
    valueFrom：
    
    fieldRef：
    
    apiVersion：v1
    
    fieldPath：metadata.namespace
  
  
  • 名前：CILIUM_FLANNEL_MASTER_DEVICE
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：フランネル-マスター-デバイス
    
    名前：cilium-config
    
    オプション：true
  
  
  • 名前：CILIUM_FLANNEL_UNINSTALL_ON_EXIT
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：flannel-uninstall-on-exit
    
    名前：cilium-config
    
    オプション：true
  
  
  • 名前：CILIUM_CLUSTERMESH_CONFIG
    
    値：/ var / lib / cilium / clustermesh /
  
  
  • 名前：CILIUM_CNI_CHAINING_MODE
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：cni-chaining-mode
    
    名前：cilium-config
    
    オプション：true
  
  
  • 名前：CILIUM_CUSTOM_CNI_CONF
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：custom-cni-conf
    
    名前：cilium-config
    
    オプション：true
    
    画像：docker.io/cilium/ cilium ：v1.7.6
    
    imagePullPolicy：IfNotPresent
    
    ライフサイクル：
    
    postStart：
    
    exec：
    
    コマンド：
    
    
    
    
    
    • /cni-install.sh
    
    
    
    • --enable-debug = false
      
      
      preStop：
      
      
      exec：
      
      
      コマンド：
    
    
    
    • /cni-uninstall.sh
      
      
      livenessProbe：
      
      
      exec：
      
      
      コマンド：
      
      
      
      
      
      
      
      • 繊毛
      
      
      
      
      • 状態
      
      
      
      
      • -簡単な説明
        
        
        
        failureThreshold：10
        
        
        
        initialDelaySeconds：120
        
        
        
        periodSeconds：30
        
        
        
        successThreshold：1
        
        
        
        timeoutSeconds：5
        
        
        
        名前：繊毛剤
        
        
        
        readinessProbe：
        
        
        
        exec：
        
        
        
        コマンド：
      
      
      
      
      • 繊毛
      
      
      
      
      • 状態
      
      
      
      
      • -簡単な説明
        
        
        
        failureThreshold：3
        
        
        
        initialDelaySeconds：5
        
        
        
        periodSeconds：30
        
        
        
        successThreshold：1
        
        
        
        timeoutSeconds：5
        
        
        
        リソース：{}
        
        
        
        securityContext：
        
        
        
        機能：
        
        
        
        追加：
      
      
      
      
      • NET_ADMIN
      
      
      
      
      • SYS_MODULE
        
        
        
        特権：true
        
        
        
        ターミネーションメッセージパス：/ dev / termination-log
        
        
        
        terminalMessagePolicy：ファイル
        
        
        
        volumeMounts：
      
      
      
      
    
    
    
  
  
  • mountPath：/ var / run / cilium
    
    名前：繊毛-run
  
  
  • mountPath：/ host / opt / cni / bin
    
    名前：cni-path
  
  
  • mountPath：/host/etc/cni/net.d
    
    名前：etc-cni-netd
  
  
  • mountPath：/ var / lib / cilium / clustermesh
    
    名前：clustermesh-secrets
    
    readOnly：true
  
  
  • mountPath：/ tmp / cilium / config-map
    
    名前：cilium-config-path
    
    readOnly：true
  
  
  • mountPath：/ lib / modules
    
    名前：lib-modules
    
    readOnly：true
  
  
  • mountPath：/run/xtables.lock
    
    名前：xtables-lock
  
  
  • mountPath：/var/run/secrets/kubernetes.io/serviceaccount
    
    名前：繊毛トークン-j74lr
    
    readOnly：true
    
    dnsPolicy：ClusterFirst
    
    enableServiceLinks：true
    
    hostNetwork：true
    
    initContainers：
  
  
• コマンド：
  
  
  
  • /init-container.sh
    
    env：
  
  
  • 名前：CILIUM_ALL_STATE
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：clean-cilium-state
    
    名前：cilium-config
    
    オプション：true
  
  
  • 名前：CILIUM_BPF_STATE
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：clean-cilium-bpf-state
    
    名前：cilium-config
    
    オプション：true
  
  
  • 名前：CILIUM_WAIT_BPF_MOUNT
    
    valueFrom：
    
    configMapKeyRef：
    
    キー：wait-bpf-mount
    
    名前：cilium-config
    
    オプション：true
    
    画像：docker.io/cilium/ cilium ：v1.7.6
    
    imagePullPolicy：IfNotPresent
    
    名前：clean-cilium-state
    
    リソース：{}
    
    securityContext：
    
    機能：
    
    追加：
    
    
    
    
    
    • NET_ADMIN
      
      
      特権：true
      
      
      ターミネーションメッセージパス：/ dev / termination-log
      
      
      terminalMessagePolicy：ファイル
      
      
      volumeMounts：
    
    
    
  
  
  • mountPath：/ var / run / cilium
    
    名前：繊毛-run
  
  
  • mountPath：/var/run/secrets/kubernetes.io/serviceaccount
    
    名前：繊毛トークン-j74lr
    
    readOnly：true
    
    優先度：2000001000
    
    priorityClassName：システムノードクリティカル
    
    restartPolicy：常に
    
    スケジューラ名：デフォルト-スケジューラ
    
    securityContext：{}
    
    serviceAccount：繊毛
    
    serviceAccountName：繊毛
    
    終了GracePeriodSeconds：1
    
    許容範囲：
  
  
• オペレーター：存在します
• 効果：NoExecute
  キー：node.kubernetes.io/not-ready
  オペレーター：存在します
• 効果：NoExecute
  キー：node.kubernetes.io/unreachable
  オペレーター：存在します
• 効果：NoSchedule
  キー：node.kubernetes.io/disk-pressure
  オペレーター：存在します
• 効果：NoSchedule
  キー：node.kubernetes.io/memory-pressure
  オペレーター：存在します
• 効果：NoSchedule
  キー：node.kubernetes.io/pid-pressure
  オペレーター：存在します
• 効果：NoSchedule
  キー：node.kubernetes.io/unschedulable
  オペレーター：存在します
• 効果：NoSchedule
  キー：node.kubernetes.io/network-利用不可
  オペレーター：存在します
  ボリューム：
• hostPath：
  パス：/ var / run / cilium
  タイプ：DirectoryOrCreate
  名前：繊毛-run
• hostPath：
  パス：/ opt / cni / bin
  タイプ：DirectoryOrCreate
  名前：cni-path
• hostPath：
  パス：/etc/cni/net.d
  タイプ：DirectoryOrCreate
  名前：etc-cni-netd
• hostPath：
  パス：/ lib / modules
  タイプ： ""
  名前：lib-modules
• hostPath：
  パス：/run/xtables.lock
  タイプ：FileOrCreate
  名前：xtables-lock
• 名前：clustermesh-secrets
  秘密：
  defaultMode：420
  オプション：true
  secretName：cilium-clustermesh
• configMap：
  defaultMode：420
  名前：cilium-config
  名前：cilium-config-path
• 名前：繊毛トークン-j74lr
  秘密：
  defaultMode：420
  secretName：cilium-token-j74lrstatus：
  条件：
• lastProbeTime：null
  lastTransitionTime： "2020-07-09T23：17：53Z"
  メッセージ：「0/6ノードが使用可能です：5ノードがノードセレクターと一致しませんでした。」
  理由：予定外
  ステータス：「False」
  タイプ：PodScheduled
  フェーズ：保留中
  qosClass：BestEffort

私がこれを再現する方法は、2つのマスターと
3つのワーカーノード（クラスターAPIを使用）とCilium 1.7.6の適用：

---＃ソース：cilium / charts / agent / templates / serviceaccount.yamlapiVersion：v1kind：ServiceAccountmetadata：
名前：繊毛
名前空間：kube-system
---＃ソース：cilium / charts / operator / templates / serviceaccount.yamlapiVersion：v1kind：ServiceAccountmetadata：
名前：繊毛オペレーター
名前空間：kube-system
---＃ソース：cilium / charts / config / templates / configmap.yamlapiVersion：v1kind：ConfigMapmetadata：
名前：cilium-config
名前空間：kube-systemdata：

＃アイデンティティ割り当てモードは、繊毛間でアイデンティティを共有する方法を選択します
＃ノードの保存方法を設定します。 オプションは「crd」または「kvstore」です。
＃-「crd」は、アイデンティティをCRD（カスタムリソース定義）としてkubernetesに保存します。
＃これらは次のコマンドで照会できます。
＃kubectl get ciliumid
＃-「kvstore」は、kvstoreなどのetcdまたはconsulにIDを格納します。
＃以下で構成。 1.6より前のCiliumバージョンはkvstoreのみをサポートしていました
＃バックエンド。 これらの古い繊毛バージョンからのアップグレードは、引き続き使用する必要があります
＃以下のidentity-allocation-modeをコメントアウトして、kvstore、または
＃「kvstore」に設定します。
アイデンティティ割り当てモード：crd

＃ciliumをデバッグモードで実行する場合は、この値をtrueに変更します
デバッグ：「false」

＃IPv4アドレッシングを有効にします。 有効にすると、すべてのエンドポイントにIPv4が割り当てられます
＃ 住所。
enable-ipv4： "true"

＃IPv6アドレッシングを有効にします。 有効にすると、すべてのエンドポイントにIPv6が割り当てられます
＃ 住所。
enable-ipv6： "false"

＃繊毛モニターでパケットのトレースを集約する場合は、このレベルを設定します
＃から「低」、「中」、または「最大」。 レベルが高いほど、パケットは少なくなります。
＃モニター出力に表示されます。
モニター集約：中

＃モニターの集約間隔は、モニター間の一般的な時間を管理します
＃許可された接続ごとの通知イベント。
＃
＃モニターの集計が「中」以上に設定されている場合にのみ有効です。
モニター-集約-間隔：5秒

＃モニター集約フラグは、どのTCPフラグを決定します。
＃最初の観察、モニター通知を生成させます。
＃
＃モニターの集計が「中」以上に設定されている場合にのみ有効です。
monitor-aggregation-flags：すべて

＃ct-global-max-entries- *接続の最大数を指定します
＃すべてのエンドポイントでサポートされ、プロトコル（tcpまたはその他）で分割されます。 ワンペア
マップの数は、IPv4接続、および別のマップのペアにこれらの値を使用します
＃これらの値をIPv6接続に使用します。
＃
＃これらの値が変更された場合、次のCiliumの起動時に
＃進行中の接続の追跡が中断される可能性があります。 これは簡単につながる可能性があります
＃ポリシーの削除または接続の負荷分散の決定の変更。
＃
＃Cilium 1.2以前からアップグレードするユーザーの場合、中断を最小限に抑えるため
＃アップグレードプロセス中に、これらのオプションをコメントアウトします。
bpf-ct-global-tcp-max： "524288"
bpf-ct-global-any-max： "262144"

＃bpf-policy-map-maxは、エンドポイントのエントリの最大数を指定しました
＃ポリシーマップ（エンドポイントごと）
bpf-policy-map-max： "16384"

＃マップエントリの事前割り当てにより、パケットごとの遅延を減らすことができます。
＃マップ内のエントリの事前メモリ割り当ての費用。 ザ・
＃以下のデフォルト値は、デフォルトインストールでのメモリ使用量を最小限に抑えます。
＃レイテンシーに敏感なユーザーは、これを「true」に設定することを検討できます。
＃
＃このオプションはCilium1.4で導入されました。 Cilium1.3以前は無視します
＃このオプションは、「true」に設定されているかのように動作します。
＃
＃この値が変更された場合、次のCiliumの起動時に復元
既存のエンドポイントの数と進行中の接続の追跡が中断される可能性があります。
＃これにより、ポリシーが削除されたり、負荷分散の決定が変更されたりする可能性があります。
＃しばらくの間接続。 復元するには、エンドポイントの再作成が必要になる場合があります
＃接続。
＃
＃1.3以前からへのアップグレード中にこのオプションが「false」に設定されている場合
＃1.4以降の場合、アップグレード中に1回限りの中断が発生する可能性があります。
preallocate-bpf-maps： "false"

＃互換性のあるIstioサイドカーistio-proxyに一致する正規表現
＃コンテナイメージ名
sidecar-istio-proxy-image： "cilium / istio_proxy"

＃ノード間の通信のためのカプセル化モード
＃可能な値：
＃ - 無効
＃-vxlan（デフォルト）
＃-ジュネーブ
トンネル：vxlan

＃クラスターの名前。 クラスターのメッシュを構築する場合にのみ関係します。
クラスター名：デフォルト

＃DNSポーリングは、からのmatchNameごとにDNSルックアップを定期的に発行します
＃繊毛剤。 結果は、エンドポイントポリシーを再生成するために使用されます。
＃DNSルックアップは5秒間隔で繰り返され、
＃A（IPv4）およびAAAA（IPv6）アドレス。 ルックアップが失敗した場合、最新のIP
＃代わりにデータが使用されます。 IPの変更により、繊毛の再生がトリガーされます
＃各エンドポイントのポリシーとcilium-agentごとのポリシーをインクリメントします
＃リポジトリのリビジョン。
＃
＃このオプションは、バージョン1.4.x以降、デフォルトで無効になっています。
より強力なDNSプロキシベースの実装の＃。詳細については、[0]を参照してください。
＃FQDNポリシーを使用したいが、使用したくない場合は、このオプションを有効にします
＃DNSプロキシ。
＃
＃アップグレードを容易にするために、ユーザーはこのオプションを「true」に設定することを選択できます。
＃それ以外の場合は、アップグレードガイド[1]を参照してください。
＃アップグレード用のポリシールールを準備します。
＃
＃[0] http://docs.cilium.io/en/stable/policy/language/#dnsベース
＃[1] http://docs.cilium.io/en/stable/install/upgrade/#changes -that-may-require-action
tofqdns-enable-poller： "false"

＃wait-bpf-mountは、bpfファイルシステムがマウントされるまでinitコンテナを待機させます
wait-bpf-mount： "false"

マスカレード：「本当」
enable-xt-socket-fallback： "true"
install-iptables-rules： "true"
auto-direct-node-routes： "false"
kube-proxy-replacement： "プローブ"
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"
---＃ソース：cilium / charts / agent / templates / clusterrole.yamlapiVersion：rbac.authorization.k8s.io/v1kind：ClusterRolemetadata：
名前：ciliumrules：

• apiGroups：
  
  
  
  • network.k8s.io
    
    リソース：
  
  
  • ネットワークポリシー
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
• apiGroups：
  
  
  
  • Discovery.k8s.io
    
    リソース：
  
  
  • エンドポイントスライス
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
• apiGroups：
  
  
  
  • 「」
    
    リソース：
  
  
  • 名前空間
  
  
  • サービス
  
  
  • ノード
  
  
  • エンドポイント
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
• apiGroups：
  
  
  
  • 「」
    
    リソース：
  
  
  • ポッド
  
  
  • ノード
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
  • 更新
  
  
• apiGroups：
  
  
  
  • 「」
    
    リソース：
  
  
  • ノード
  
  
  • ノード/ステータス
    
    動詞：
  
  
  • パッチ
  
  
• apiGroups：
  
  
  
  • apiextensions.k8s.io
    
    リソース：
  
  
  • customresourcedefinitions
    
    動詞：
  
  
  • 作成する
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
  • 更新
  
  
• apiGroups：
  
  
  
  • cilium.io
    
    リソース：
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • ciliumnodes
  
  
  • ciliumnodes / status
  
  
  • ciliumidentities
  
  
  • ciliumidentities / status
    
    動詞：
  
  
  • '*'
    
    ---＃ソース：cilium / charts / operator / templates / clusterrole.yamlapiVersion：rbac.authorization.k8s.io/v1kind：ClusterRolemetadata：
    
    名前：繊毛-オペレータールール：
  
  
• apiGroups：
  
  
  
  • 「」
    
    リソース：
    
    ＃[core | kube] dnsポッドを自動的に削除して、
    
    ＃Ciliumが管理
  
  
  • ポッド
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
  • 削除
  
  
• apiGroups：
  
  
  
  • Discovery.k8s.io
    
    リソース：
  
  
  • エンドポイントスライス
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
• apiGroups：
  
  
  
  • 「」
    
    リソース：
    
    ＃k8sから自動的に読み取り、ノードのポッドCIDRを繊毛にインポートします
    
    ＃etcdで、すべてのノードが別のポッドで実行されている別のポッドに到達する方法を認識します
    
    ＃ノード。
  
  
  • ノード
    
    ＃ ToGroupを含むCNPのエンドポイントへの変換を実行します
  
  
  • サービス
  
  
  • エンドポイント
    
    ＃apiserverの接続を確認する
  
  
  • 名前空間
    
    動詞：
  
  
  • 取得する
  
  
  • リスト
  
  
  • 見る
  
  
• apiGroups：
  
  
  
  • cilium.io
    
    リソース：
  
  
  • ciliumnetworkpolicies
  
  
  • ciliumnetworkpolicies / status
  
  
  • ciliumclusterwidenetworkpolicies
  
  
  • ciliumclusterwidenetworkpolicies / status
  
  
  • ciliumendpoints
  
  
  • ciliumendpoints / status
  
  
  • ciliumnodes
  
  
  • ciliumnodes / status
  
  
  • ciliumidentities
  
  
  • ciliumidentities / status
    
    動詞：
  
  
  • '*'
    
    ---＃ソース：cilium / charts / agent / templates / clusterrolebinding.yamlapiVersion：rbac.authorization.k8s.io/v1kind：ClusterRoleBindingmetadata：
    
    名前：ciliumroleRef：
    
    apiGroup：rbac.authorization.k8s.io
    
    種類：ClusterRole
    
    名前：ciliumsubjects：
  
  
• 種類：ServiceAccount
  名前：繊毛
  名前空間：kube-system
  ---＃ソース：cilium / charts / operator / templates / clusterrolebinding.yamlapiVersion：rbac.authorization.k8s.io/v1kind：ClusterRoleBindingmetadata：
  名前：cilium-operatorroleRef：
  apiGroup：rbac.authorization.k8s.io
  種類：ClusterRole
  名前：繊毛-オペレーター被験者：
• 種類：ServiceAccount
  名前：繊毛オペレーター
  名前空間：kube-system
  ---＃ソース：cilium / charts / agent /テンプレート/daemonset.yamlapiバージョン：apps / v1kind：DaemonSetmetadata：
  ラベル：
  k8s-app：繊毛
  名前：繊毛
  名前空間：kube-systemspec：
  セレクタ：
  matchLabels：
  k8s-app：繊毛
  テンプレート：
  メタデータ：
  注釈：
  ＃このアノテーションとCriticalAddonsOnlyの許容範囲により
  ＃繊毛はクラスター内の重要なポッドであり、繊毛を確保します
  ＃優先スケジューリングを取得します。
  ＃https：//kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/
  Scheduler.alpha.kubernetes.io/critical-pod： ""
  ラベル：
  k8s-app：繊毛
  スペック：
  コンテナ：
  
  
  
  • 引数：
    
    
    
    
    
    • --config-dir = / tmp / cilium / config-map
      
      
      コマンド：
    
    
    
    • 繊毛剤
      
      
      livenessProbe：
      
      
      exec：
      
      
      コマンド：
      
      
      
      
      
      
      
      • 繊毛
      
      
      
      
      • 状態
      
      
      
      
      • -簡単な説明
        
        
        
        failureThreshold：10
        
        
        
        ＃活性プローブの初期遅延は意図的に大きくなります
        
        
        
        ＃最初の場合、無限のキル＆リスタートサイクルを回避する
        
        
        
        ＃ブートストラップに予想よりも時間がかかります。
        
        
        
        initialDelaySeconds：120
        
        
        
        periodSeconds：30
        
        
        
        successThreshold：1
        
        
        
        timeoutSeconds：5
        
        
        
        readinessProbe：
        
        
        
        exec：
        
        
        
        コマンド：
      
      
      
      
      • 繊毛
      
      
      
      
      • 状態
      
      
      
      
      • -簡単な説明
        
        
        
        failureThreshold：3
        
        
        
        initialDelaySeconds：5
        
        
        
        periodSeconds：30
        
        
        
        successThreshold：1
        
        
        
        timeoutSeconds：5
        
        
        
        env：
      
      
      
      
    
    
    
    • 名前：K8S_NODE_NAME
      
      
      valueFrom：
      
      
      fieldRef：
      
      
      apiVersion：v1
      
      
      fieldPath：spec.nodeName
    
    
    
    • 名前：CILIUM_K8S_NAMESPACE
      
      
      valueFrom：
      
      
      fieldRef：
      
      
      apiVersion：v1
      
      
      fieldPath：metadata.namespace
    
    
    
    • 名前：CILIUM_FLANNEL_MASTER_DEVICE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：フランネル-マスター-デバイス
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_FLANNEL_UNINSTALL_ON_EXIT
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：flannel-uninstall-on-exit
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_CLUSTERMESH_CONFIG
      
      
      値：/ var / lib / cilium / clustermesh /
    
    
    
    • 名前：CILIUM_CNI_CHAINING_MODE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：cni-chaining-mode
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_CUSTOM_CNI_CONF
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：custom-cni-conf
      
      
      名前：cilium-config
      
      
      オプション：true
      
      
      画像：「 docker.io/cilium/cilium:v1.7.6 」
      
      
      imagePullPolicy：IfNotPresent
      
      
      ライフサイクル：
      
      
      postStart：
      
      
      exec：
      
      
      コマンド：
      
      
      
      
      
      
      
      • 「/cni-install.sh」
      
      
      
      
      • "--enable-debug = false"
        
        
        
        preStop：
        
        
        
        exec：
        
        
        
        コマンド：
      
      
      
      
      • /cni-uninstall.sh
        
        
        
        名前：繊毛剤
        
        
        
        securityContext：
        
        
        
        機能：
        
        
        
        追加：
        
        
        
        
        
        
        
        
        
        • NET_ADMIN
        
        
        
        
        
        • SYS_MODULE
          
          
          
          
          特権：true
          
          
          
          
          volumeMounts：
        
        
        
        
        
      
      
      
      
    
    
    
    • mountPath：/ var / run / cilium
      
      
      名前：繊毛-run
    
    
    
    • mountPath：/ host / opt / cni / bin
      
      
      名前：cni-path
    
    
    
    • mountPath：/host/etc/cni/net.d
      
      
      名前：etc-cni-netd
    
    
    
    • mountPath：/ var / lib / cilium / clustermesh
      
      
      名前：clustermesh-secrets
      
      
      readOnly：true
    
    
    
    • mountPath：/ tmp / cilium / config-map
      
      
      名前：cilium-config-path
      
      
      readOnly：true
      
      
      ＃カーネルモジュールをロードできるようにする必要があります
    
    
    
    • mountPath：/ lib / modules
      
      
      名前：lib-modules
      
      
      readOnly：true
    
    
    
    • mountPath：/run/xtables.lock
      
      
      名前：xtables-lock
      
      
      hostNetwork：true
      
      
      initContainers：
    
    
    
  
  
  • コマンド：
    
    
    
    
    
    • /init-container.sh
      
      
      env：
    
    
    
    • 名前：CILIUM_ALL_STATE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：clean-cilium-state
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_BPF_STATE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：clean-cilium-bpf-state
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_WAIT_BPF_MOUNT
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：wait-bpf-mount
      
      
      名前：cilium-config
      
      
      オプション：true
      
      
      画像：「 docker.io/cilium/cilium:v1.7.6 」
      
      
      imagePullPolicy：IfNotPresent
      
      
      名前：clean-cilium-state
      
      
      securityContext：
      
      
      機能：
      
      
      追加：
      
      
      
      
      
      
      
      • NET_ADMIN
        
        
        
        特権：true
        
        
        
        volumeMounts：
      
      
      
      
    
    
    
    • mountPath：/ var / run / cilium
      
      
      名前：繊毛-run
      
      
      restartPolicy：常に
      
      
      priorityClassName：システムノードクリティカル
      
      
      serviceAccount：繊毛
      
      
      serviceAccountName：繊毛
      
      
      終了GracePeriodSeconds：1
      
      
      許容範囲：
    
    
    
  
  
  • オペレーター：存在します
    
    ボリューム：
    
    ＃再起動/アップグレード間で状態を維持するには
  
  
  • hostPath：
    
    パス：/ var / run / cilium
    
    タイプ：DirectoryOrCreate
    
    名前：繊毛-run
    
    ＃ホストに繊毛cniプラグインをインストールするには
  
  
  • hostPath：
    
    パス：/ opt / cni / bin
    
    タイプ：DirectoryOrCreate
    
    名前：cni-path
    
    ＃ホストに繊毛cni構成をインストールするには
  
  
  • hostPath：
    
    パス：/etc/cni/net.d
    
    タイプ：DirectoryOrCreate
    
    名前：etc-cni-netd
    
    ＃カーネルモジュールをロードできるようにする
  
  
  • hostPath：
    
    パス：/ lib / modules
    
    名前：lib-modules
    
    ＃他のプロセス（kube-proxyなど）と同時にiptablesにアクセスするには
  
  
  • hostPath：
    
    パス：/run/xtables.lock
    
    タイプ：FileOrCreate
    
    名前：xtables-lock
    
    ＃clustermesh構成を読み取るには
  
  
  • 名前：clustermesh-secrets
    
    秘密：
    
    defaultMode：420
    
    オプション：true
    
    secretName：cilium-clustermesh
    
    ＃構成マップから構成を読み取るには
  
  
  • configMap：
    
    名前：cilium-config
    
    名前：cilium-config-path
    
    updateStrategy：
    
    RollingUpdate：
    
    maxUnavailable：2
    
    タイプ：RollingUpdate
    
    ---＃ソース：cilium / charts / operator / templates / deployment.yamlapiVersion：apps / v1kind：Deploymentmetadata：
    
    ラベル：
    
    io.cilium / app：演算子
    
    名前：繊毛オペレーター
    
    名前：繊毛オペレーター
    
    名前空間：kube-systemspec：
    
    レプリカ：1
    
    セレクタ：
    
    matchLabels：
    
    io.cilium / app：演算子
    
    名前：繊毛オペレーター
    
    戦略：
    
    RollingUpdate：
    
    maxSurge：1
    
    maxUnavailable：1
    
    タイプ：RollingUpdate
    
    テンプレート：
    
    メタデータ：
    
    注釈：
    
    ラベル：
    
    io.cilium / app：演算子
    
    名前：繊毛オペレーター
    
    スペック：
    
    コンテナ：
  
  
  • 引数：
    
    
    
    
    
    • --debug = $（CILIUM_DEBUG）
    
    
    
    • --identity-allocation-mode = $（CILIUM_IDENTITY_ALLOCATION_MODE）
    
    
    
    • --synchronize-k8s-nodes = true
      
      
      コマンド：
    
    
    
    • 繊毛オペレーター
      
      
      env：
    
    
    
    • 名前：CILIUM_K8S_NAMESPACE
      
      
      valueFrom：
      
      
      fieldRef：
      
      
      apiVersion：v1
      
      
      fieldPath：metadata.namespace
    
    
    
    • 名前：K8S_NODE_NAME
      
      
      valueFrom：
      
      
      fieldRef：
      
      
      apiVersion：v1
      
      
      fieldPath：spec.nodeName
    
    
    
    • 名前：CILIUM_DEBUG
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：デバッグ
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_CLUSTER_NAME
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：クラスター名
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_CLUSTER_ID
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：cluster-id
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_IPAM
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：ipam
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_DISABLE_ENDPOINT_CRD
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：disable-endpoint-crd
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_KVSTORE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：kvstore
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_KVSTORE_OPT
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：kvstore-opt
      
      
      名前：cilium-config
      
      
      オプション：true
    
    
    
    • 名前：AWS_ACCESS_KEY_ID
      
      
      valueFrom：
      
      
      secretKeyRef：
      
      
      キー：AWS_ACCESS_KEY_ID
      
      
      名前：繊毛-aws
      
      
      オプション：true
    
    
    
    • 名前：AWS_SECRET_ACCESS_KEY
      
      
      valueFrom：
      
      
      secretKeyRef：
      
      
      キー：AWS_SECRET_ACCESS_KEY
      
      
      名前：繊毛-aws
      
      
      オプション：true
    
    
    
    • 名前：AWS_DEFAULT_REGION
      
      
      valueFrom：
      
      
      secretKeyRef：
      
      
      キー：AWS_DEFAULT_REGION
      
      
      名前：繊毛-aws
      
      
      オプション：true
    
    
    
    • 名前：CILIUM_IDENTITY_ALLOCATION_MODE
      
      
      valueFrom：
      
      
      configMapKeyRef：
      
      
      キー：アイデンティティ割り当てモード
      
      
      名前：cilium-config
      
      
      オプション：true
      
      
      画像：「 docker.io/cilium/operator:v1.7.6 」
      
      
      imagePullPolicy：IfNotPresent
      
      
      名前：繊毛オペレーター
      
      
      livenessProbe：
      
      
      httpGet：
      
      
      ホスト： '127.0.0.1'
      
      
      パス：/ healthz
      
      
      ポート：9234
      
      
      スキーム：HTTP
      
      
      initialDelaySeconds：60
      
      
      periodSeconds：10
      
      
      timeoutSeconds：3
      
      
      hostNetwork：true
      
      
      restartPolicy：常に
      
      
      serviceAccount：cilium-operator
      
      
      serviceAccountName：cilium-operator
    
    
    
  
  

—
あなたが割り当てられたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656404841 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAJ5E6BMTNCADT5K7D4PMF3R2ZJRVANCNFSM4NOTPEDA
。

ログレベルを上げ、grepを使用してノードをフィルタリングしてみてください
またはポッド？

2020年7月9日木曜日、午後7時55分dilyevsky、 notifications @ github.com
書きました：

スケジューラログは次のとおりです。

I0709 23：08：22.056081 1registry.go：150] EvenPodsSpread述語と優先度関数の登録
I0709 23：08：23.137451 1serving.go：313]メモリ内に生成された自己署名証明書
W0709 23：08：33.843509 1 authentication.go：297]クラスター内認証構成の検索中にエラーが発生しました：etcdserver：要求がタイムアウトしました
W0709 23：08：33.843671 1 authentication.go：298]認証構成なしで続行します。 これにより、すべてのリクエストが匿名として扱われる場合があります。
W0709 23：08：33.843710 1 authentication.go：299]認証構成のルックアップを成功させるには、-authentication-tolerate-lookup-failure = falseを設定します。
I0709 23：08：33.911805 1registry.go：150] EvenPodsSpread述語と優先度関数の登録
I0709 23：08：33.911989 1 Registry.go：150] EvenPodsSpread述語と優先度関数の登録
W0709 23：08：33.917999 1authorization.go：47]認証が無効になっています
W0709 23：08：33.918162 1 authentication.go：40]認証が無効になっています
I0709 23：08：33.918238 1 deprecated_insecure_serving.go：51] [::]：10251でhealthzを安全に提供していません
I0709 23：08：33.925860 1 configmap_cafile_content.go：202] client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-fileを起動しています
I0709 23：08：33.926013 1 shared_informer.go：223] client-ca :: kube-system :: extension-apiserver-authentication :: client-ca-fileのキャッシュが同期するのを待機しています
I0709 23：08：33.930685 1 secure_serving.go：178] 127.0.0.1:10259で安全にサービスを提供
I0709 23：08：33.936198 1 tlsconfig.go：240] DynamicServingCertificateControllerを開始しています
I0709 23：08：34.026382 1 shared_informer.go：230]キャッシュはclient-ca :: kube-system :: extension-apiserver-authentication :: client-ca-fileに対して同期されます
I0709 23：08：34.036998 1leaderelection.go：242]リーダーリースkube-system / kube-schedulerを取得しようとしています...
I0709 23：08：50.597201 1leaderelection.go：252]リースkube-system / kube-schedulerの取得に成功しました
E0709 23：08：50.658551 1 factory.go：503]ポッド：kube-system / coredns-66bff467f8-9rjvdはすでにアクティブキューに存在します
E0709 23：12：27.673854 1 factory.go：503]ポッドkube-system / cilium-vv466はすでにバックオフキューに存在します
E0709 23：12：58.099432 1leaderelection.go：320]リソースロックの取得中にエラーが発生しましたkube-system / kube-scheduler：etcdserver：リーダーが変更されました

スケジューラポッドを再起動すると、保留中のポッドはすぐにスケジュールを設定します。

—
あなたが割り当てられたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/91601#issuecomment-656406215 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAJ5E6E4QPGNNBFUYSZEJC3R2ZKHDANCNFSM4NOTPEDA
。

これらはイベントです：
`` `イベント：
メッセージから理由年齢を入力
---- ------ ---- ---- -------
警告FailedSchedulingdefault-scheduler 0/6ノードが使用可能です：5つのノードがノードセレクターと一致しませんでした。
警告FailedSchedulingdefault-scheduler 0/6ノードが使用可能です：5つのノードがノードセレクターと一致しませんでした。

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

汚染：node-role.kubernetes.io/ master：NoSchedule
node.kubernetes.io/network-利用不可：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

スケジューラのログレベルを上げてみます...

ポッドyamlには実際にはnode-role.kubernetes.io/master許容範囲がありません。 したがって、マスターでスケジュールされるべきではありませんでした。

こんにちは！ 私たちは同じ問題に直面しています。 ただし、展開でも同じ問題が発生します。この場合、非アフィニティを使用して、ポッドが各ノードまたは特定のノードをターゲットとするポッドセレクターでスケジュールされるようにします。
失敗したノードのホスト名に一致するように設定されたノードセレクターを使用してポッドを作成するだけで、スケジューリングが失敗しました。 5つのノードがセレクターと一致していないと言っていましたが、6番目のノードについては何もありませんでした。 スケジューラを再起動すると、問題が解決しました。 そのノードについて何かがキャッシュされ、ノードでのスケジューリングが妨げられているように見えます。
他の人が前に言ったように、私たちは失敗についてログに何もありません。

失敗した展開を最小限に抑えました（失敗しているマスターの汚染を削除しました）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
      restartPolicy: Always
      schedulerName: default-scheduler
      nodeSelector:
        kubernetes.io/hostname: master-2

マスターが汚れを持っていたときも同じ問題があり、展開は汚れに対する許容範囲でした。 したがって、デーモンセット、許容範囲、またはアフィニティ/非アフィニティに特に関連しているようには見えません。 障害が発生し始めると、特定のノードを対象とするものは何もスケジュールできません。 1.18.2から1.18.5までの問題が見られます（1.18.0または.1では試していない）

失敗したノードのホスト名に一致するように設定されたノードセレクターを使用してポッドを作成するだけで、スケジューリングが失敗する原因になりました。

そのようなポッドを作成した後、またはそれ以前に失敗し始めたかどうかを明確にできますか？ このノードには、ポッドが許容できない汚染がなかったと思います。

@nodoは再現に役立ちます。 NodeSelectorのコードを見ていただけますか？ テスト中にログ行を追加する必要がある場合があります。 キャッシュを印刷することもできます。

• kube-schedulerのPIDを取得します： $ pidof kube-scheduler
• トリガーキューダンプ： $ sudo kill -SIGUSR2 <pid> 。 これはスケジューラプロセスを強制終了しないことに注意してください。
• 次に、スケジューラログで、「キャッシュされたNodeInfoのダンプ」、「スケジューリングキューのダンプ」、「キャッシュ比較機能が開始されました」という文字列を検索します。

/優先度クリティカル-緊急

/ unassign

このテストデプロイメントをデプロイしようとする前に、デーモンセットとデプロイメントが「保留中」でスタックしているのをすでに確認していたため、すでに失敗していました。 汚染物質はノードから削除されていました。
現在、ノードを再起動する必要があり、問題が表示されなくなったため、これが発生していた環境が失われました。 再現次第、詳細をお知らせします

そうしてください。 私は過去にこれを再現しようとしましたが成功しませんでした。 私は失敗の最初の例にもっと興味があります。 それはまだ汚染に関連している可能性があります。

問題を再現しました。 私はあなたが要求したコマンドを実行しました、ここに情報があります：

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: 

残念ながら、それは役に立たないようです

キャッシュのダンプはデバッグ用であり、何も変更されません。 ダンプを含めていただけませんか？

また、これが最初のエラーであると仮定して、ポッドyamlとノードを含めることができますか？

ダンプされたものはほとんどすべてです。他のノードを削除しただけです。 これは最初のエラーではありませんでしたが、ダンプにcorednsポッドが表示されています。これが最初のエラーです。 ダンプで他に何を求めているのかわかりません。
yamlをフェッチします

おかげで、あなたが関連するノードとポッドをトリミングしたことに気づきませんでした。

ただし、そのノードのスケジュールされたポッドを含めることはできますか？ リソース使用量の計算にバグがある場合に備えて。

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

そのAllowedPodNumber: 0は奇妙に思えます。

そのノード上の他のポッドは次のとおりです。
` name: kube-controller-manager-master-0-bug, namespace: kube-system, uid: 095eebb0-4752-419b-aac7-245e5bc436b8, phase: Running, nominated node: name: kube-proxy-xwf6h, namespace: kube-system, uid: 16552eaf-9eb8-4584-ba3c-7dff6ce92592, phase: Running, nominated node: name: kube-apiserver-master-0-bug, namespace: kube-system, uid: 1d338e26-b0bc-4cef-9bad-86b7dd2b2385, phase: Running, nominated node: name: kube-multus-ds-amd64-tpkm8, namespace: kube-system, uid: d50c0c7f-599c-41d5-a029-b43352a4f5b8, phase: Running, nominated node: name: openstack-cloud-controller-manager-wrb8n, namespace: kube-system, uid: 17aeb589-84a1-4416-a701-db6d8ef60591, phase: Running, nominated node: name: kube-scheduler-master-0-bug, namespace: kube-system, uid: 52469084-3122-4e99-92f6-453e512b640f, phase: Running, nominated node: name: subport-controller-28j9v, namespace: kube-system, uid: a5a07ac8-763a-4ff2-bdae-91c6e9e95698, phase: Running, nominated node: name: csi-cinder-controllerplugin-0, namespace: kube-system, uid: 8b16d6c8-a871-454e-98a3-0aa545f9c9d0, phase: Running, nominated node: name: calico-node-d899t, namespace: kube-system, uid: e3672030-53b1-4356-a5df-0f4afd6b9237, phase: Running, nominated node:

すべてのノードで、ダンプ内の要求されたリソースでallowedPodNumberが0に設定されていますが、他のノードはスケジュール可能です

ノードyaml：

apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
  creationTimestamp: "2020-07-16T09:59:48Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    beta.kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/region: regionOne
    failure-domain.beta.kubernetes.io/zone: nova
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: master-0-bug
    kubernetes.io/os: linux
    node-role.kubernetes.io/master: ""
    node.kubernetes.io/instance-type: 54019dbc-10d7-409c-8338-5556f61a9371
    node.uuid: 00324054-405e-4fae-a3bf-d8509d511ded
    node.uuid_source: cloud-init
    topology.kubernetes.io/region: regionOne
    topology.kubernetes.io/zone: nova
  name: master-0-bug
  resourceVersion: "85697"
  selfLink: /api/v1/nodes/master-0-bug
  uid: 629b6ef3-3c76-455b-8b6b-196c4754fb0e
spec:
  podCIDR: 192.168.0.0/24
  podCIDRs:
  - 192.168.0.0/24
  providerID: openstack:///00324054-405e-4fae-a3bf-d8509d511ded
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
status:
  addresses:
  - address: 10.0.10.14
    type: InternalIP
  - address: master-0-bug
    type: Hostname
  allocatable:
    cpu: "2"
    ephemeral-storage: "19290208634"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 2962332Ki
    pods: "110"
  capacity:
    cpu: "2"
    ephemeral-storage: 20931216Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 3064732Ki
    pods: "110"
  conditions:
  - lastHeartbeatTime: "2020-07-16T10:02:20Z"
    lastTransitionTime: "2020-07-16T10:02:20Z"
    message: Calico is running on this node
    reason: CalicoIsUp
    status: "False"
    type: NetworkUnavailable
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient memory available
    reason: KubeletHasSufficientMemory
    status: "False"
    type: MemoryPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has no disk pressure
    reason: KubeletHasNoDiskPressure
    status: "False"
    type: DiskPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T09:59:43Z"
    message: kubelet has sufficient PID available
    reason: KubeletHasSufficientPID
    status: "False"
    type: PIDPressure
  - lastHeartbeatTime: "2020-07-16T15:46:11Z"
    lastTransitionTime: "2020-07-16T10:19:44Z"
    message: kubelet is posting ready status. AppArmor enabled
    reason: KubeletReady
    status: "True"
    type: Ready
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250
  nodeInfo:
    architecture: amd64
    bootID: fe410ed3-2825-4f94-a9f9-08dc5e6a955e
    containerRuntimeVersion: docker://19.3.11
    kernelVersion: 4.12.14-197.45-default
    kubeProxyVersion: v1.18.5
    kubeletVersion: v1.18.5
    machineID: 00324054405e4faea3bfd8509d511ded
    operatingSystem: linux
    systemUUID: 00324054-405e-4fae-a3bf-d8509d511ded

とポッド：

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

すべての情報をありがとう。 @nodoあなたはそれを取ることができますか？

また、 https：//github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdcを使用して、詳細情報を取得しようとしてい

/助けて

@maelkは、バグを見つけた場合は、これを

@alculquicondor ：
このリクエストは、寄稿者からの支援が必要であるとマークされています。

リクエストがここに記載されて

このリクエストがこれらの要件を満たさなくなった場合は、ラベルを削除できます
/remove-helpコマンドでコメントします。

/割当

@maelkこの問題が最初に発生するタイミングに固有の何かはありますか？ たとえば、ノードが起動した直後に発生しますか？

いいえ、そこでスケジュールされて正常に実行されるポッドがかなりあります。 ただし、問題が発生すると、スケジュールを設定できなくなります。

再現可能なケースが得られるまで優先度を下げます。

追加のログエントリを持つスケジューラを使用して、バグを再現することができました。 マスターの1つが、繰り返されるノードのリストから完全に消えていることがわかります。 プロセスが（スナップショットからの）6つのノードから始まることがわかります。

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}

しかしその後、5ノード以上しか反復しないことがわかり、次のようになります。

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

そのため、ノードの1つが潜在的なノードのリストから削除されます。 残念ながら、プロセスの開始時に十分なログがありませんでしたが、さらに多くのログを取得しようとします。

ログ行によるコード参照：

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

@maelk
%v/%v on node %v, too many nodes fit行を見ましたか？

それ以外の場合、 @ pancernikはworkqueue.ParallelizeUntil(ctx, 16, len(allNodes), checkNode)バグをチェックできますか？

いいえ、そのログは表示されませんでした。 また、並列化に問題があるか、ノードが以前にフィルターで除外されている可能性もあると思います。 ここでエラーが発生して失敗した場合： https ：

1つのノードが2回フィルタリングを通過していることに気づきました。

ログは次のとおりです。

I0720 13:58:28.246507       1 generic_scheduler.go:441] Looking for a node for kube-system/coredns-cd64c8d7c-tcxbq, going through []*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}
I0720 13:58:28.246793       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.246970       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.246819       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-0-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247019       1 taint_toleration.go:71] Checking taints for pod kube-system/coredns-cd64c8d7c-tcxbq for node master-2-scheduler : taints : []v1.Taint{v1.Taint{Key:"node-role.kubernetes.io/master", Value:"", Effect:"NoSchedule", TimeAdded:(*v1.Time)(nil)}} and tolerations: []v1.Toleration{v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"CriticalAddonsOnly", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/master", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node-role.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}, v1.Toleration{Key:"node.kubernetes.io/not-ready", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40d90)}, v1.Toleration{Key:"node.kubernetes.io/unreachable", Operator:"Exists", Value:"", Effect:"NoExecute", TolerationSeconds:(*int64)(0xc000d40db0)}}
I0720 13:58:28.247144       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247172       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-2-scheduler : status is not success
I0720 13:58:28.247210       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247231       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-7dt1xd4k-scheduler : status is not success
I0720 13:58:28.247206       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247297       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-60846k0y-scheduler : status is not success
I0720 13:58:28.247246       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler, fits: false, status: &v1alpha1.Status{code:3, reasons:[]string{"node(s) didn't match node selector"}}
I0720 13:58:28.247340       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node worker-pool1-hyk0hg7r-scheduler : status is not success
I0720 13:58:28.247147       1 generic_scheduler.go:469] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler, fits: false, status: &v1alpha1.Status{code:2, reasons:[]string{"node(s) didn't match pod affinity/anti-affinity", "node(s) didn't satisfy existing pods anti-affinity rules"}}
I0720 13:58:28.247375       1 generic_scheduler.go:483] pod kube-system/coredns-cd64c8d7c-tcxbq on node master-0-scheduler : status is not success
I0720 13:58:28.247420       1 generic_scheduler.go:505] pod kube-system/coredns-cd64c8d7c-tcxbq : processed 5 nodes, 0 fit
I0720 13:58:28.247461       1 generic_scheduler.go:430] pod kube-system/coredns-cd64c8d7c-tcxbq After scheduling, filtered: []*v1.Node{}, filtered nodes: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)}
I0720 13:58:28.247527       1 generic_scheduler.go:185] Pod kube-system/coredns-cd64c8d7c-tcxbq failed scheduling:
  nodes snapshot: &cache.Snapshot{nodeInfoMap:map[string]*nodeinfo.NodeInfo{"master-0-scheduler":(*nodeinfo.NodeInfo)(0xc000607040), "master-1-scheduler":(*nodeinfo.NodeInfo)(0xc0001071e0), "master-2-scheduler":(*nodeinfo.NodeInfo)(0xc000326a90), "worker-pool1-60846k0y-scheduler":(*nodeinfo.NodeInfo)(0xc000952000), "worker-pool1-7dt1xd4k-scheduler":(*nodeinfo.NodeInfo)(0xc0007d08f0), "worker-pool1-hyk0hg7r-scheduler":(*nodeinfo.NodeInfo)(0xc0004f35f0)}, nodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000952000), (*nodeinfo.NodeInfo)(0xc0007d08f0), (*nodeinfo.NodeInfo)(0xc0004f35f0), (*nodeinfo.NodeInfo)(0xc000607040), (*nodeinfo.NodeInfo)(0xc000952000)}, havePodsWithAffinityNodeInfoList:[]*nodeinfo.NodeInfo{(*nodeinfo.NodeInfo)(0xc000326a90), (*nodeinfo.NodeInfo)(0xc000607040)}, generation:857} 
  statuses: v1alpha1.NodeToStatusMap{"master-0-scheduler":(*v1alpha1.Status)(0xc000d824a0), "master-2-scheduler":(*v1alpha1.Status)(0xc000b736c0), "worker-pool1-60846k0y-scheduler":(*v1alpha1.Status)(0xc000d825a0), "worker-pool1-7dt1xd4k-scheduler":(*v1alpha1.Status)(0xc000b737e0), "worker-pool1-hyk0hg7r-scheduler":(*v1alpha1.Status)(0xc000b738c0)} 

ご覧のとおり、ノードworker-pool1-60846k0y-schedulerはフィルタリングを2回実行します

いいえ、そのログは表示されませんでした。 また、並列化に問題があるか、ノードが以前にフィルターで除外されている可能性もあると思います。 ここでエラーが発生して失敗した場合： Nordix @ 5c00cdf＃diff -c237cdd9e4cb201118ca380732d7f361R464ログafaikに表示されるので、特に関数と並列化の周りにデバッグエントリを追加してみます。

ええ、そこでのエラーはポッドイベントのスケジューリングエラーとして現れます。

1つのノードが2回フィルタリングを通過していることに気づきました。

正直なところ、並列化にバグがあるとは思いませんが（まだチェックする価値があります）、これは、キャッシュからスナップショットを作成できなかったことを示している可能性があります（キャッシュダンプからわかるように、キャッシュは正しいです）。ノードを2回。 ステータスはマップであるため、最後のログ行で5つのノードのみを「表示」することは理にかなっています。

これはコードです（1.18のヒント） https://github.com/kubernetes/kubernetes/blob/ec73e191f47b7992c2f40fadf1389446d6661d6d/pkg/scheduler/internal/cache/cache.go#L203

cc @ ahg-g

スケジューラーのキャッシュ部分、特にノードの追加と更新、およびスナップショットの周りに多くのログを追加しようとします。 ただし、ログの最後の行から、スナップショットが実際に正しく、すべてのノードが含まれていることがわかります。そのため、後でそのスナップショットを処理するときに、何が起こっても発生するように見えます。

キャッシュ！=スナップショット

キャッシュは、イベントから更新される生き物です。 スナップショットは、状態を「ロック」するために、各スケジューリングサイクルの前に（キャッシュから）更新されます。 この最後のプロセスをできるだけ速くするために最適化を追加しました。 バグが存在する可能性があります。

ありがとう@maelk！ これはとても便利です。 ログは、並列コードが実行される前に、 (*nodeinfo.NodeInfo)(0xc000952000)がすでにhttps://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff-c237cdd9e4cb201118ca380732d7f361R441にあるリストに複製されていることを示してい

実際には、これはスナップショットからのものであり、このログメッセージの前に発生します： https ：//github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff-c237cdd9e4cb201118ca380732d7f361R161。 スナップショットのコンテンツはhttps://github.com/Nordix/kubernetes/commit/5c00cdf195fa61316f963f59e73c6cafc2ad9bdc#diff-c237cdd9e4cb201118ca380732d7f361R436から取得されているため、重複しているように見え

そのとおり。 スナップショットの更新が完了する前に、すでに複製されていることを意味します。

そのとおり。 スナップショットの更新が完了する前に、すでに複製されていることを意味します。

いいえ、スナップショットはスケジューリングサイクルの開始時に更新されます。 バグは、スナップショットの更新中またはその前に発生します。 しかし、 https： //github.com/kubernetes/kubernetes/issues/91601#issuecomment -659465008のダンプによると、キャッシュは正しいです。

編集：私はそれを間違って読みました、私は「終わり」という言葉を見ませんでした:)

PR最適化更新スナップショットは1.18で実行されました： https ： https://github.com/kubernetes/kubernetes/pull/86919

ノードツリーにも重複レコードがあるのだろうか

ノードツリーにも重複レコードがあるのだろうか

@maelkキャッシュ内のノードの完全なリストのダンプを表示できますか？

NodeInfoListからアイテムを追加/削除するのではなく、ツリーから完全なリストを作成するかどうかにかかわらず、重複がある場合は、ツリーからのものである可能性が高いと思います。

明確にするために：
1）クラスターには6つのノード（マスターを含む）があります
2）ポッドをホストすることになっているノードがまったく調べられなかった（それを示すログ行がない）、つまり、NodeInfoListにまったく含まれていない可能性があります
3）NodeInfoListには6つのノードがありますが、そのうちの1つが重複しています

ノードツリーにも重複レコードがあるのだろうか

@maelkキャッシュ内のノードの完全なリストのダンプを表示できますか？

各ノードツリー、リスト、およびマップのダンプは素晴らしいでしょう。

それらの取得に取り組みます。 それまでの間、小さな更新があります。 ログで確認できます：

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

そして、それは欠落しているノードが消える正確なポイントです。 ログの最後の発生は13:37:24です。 次のスケジューリングでは、欠落しているノードはなくなります。 したがって、バグはnode_treeの更新にある/ followsにあるように見えます。 すべてのノードがその更新を通過します。このワーカー608が最後に更新を通過するだけです。

キャッシュを（SIGUSR2を使用して）ダンプすると、6つのノードすべてがリストされ、ポッドはノード上で実行され、重複したりノードが欠落したりすることはありません。

スナップショット機能に関するデバッグを追加して、新しい試行を行います： https ：

グループ ""のノード "worker-pool1-60846k0y-scheduler"をNodeTreeから削除しました

興味深いことに、remove / addはupdateNode呼び出しによってトリガーされると思います。 ゾーンキーは削除時に欠落していますが、追加には存在するため、更新では基本的にゾーンとリージョンのラベルが追加されていましたか？

このノードに関連する他のスケジューラログはありますか？

ロギングを追加してバグを再現しようとしています。 詳細がわかり次第、また戻ってきます

それらの取得に取り組みます。 それまでの間、小さな更新があります。 ログで確認できます：

I0720 13:37:30.530980       1 node_tree.go:100] Removed node "worker-pool1-60846k0y-scheduler" in group "" from NodeTree
I0720 13:37:30.531136       1 node_tree.go:86] Added node "worker-pool1-60846k0y-scheduler" in group "regionOne:\x00:nova" to NodeTree

そのようなノードが繰り返されるノードであることを指摘しておきます。 @maelk 、他のノードでも同様のメッセージが表示されましたか、それともまったく表示されませんでしたか？ @ ahg-gのように、これはノードがそのトポロジラベルを初めて受信するときに予期されるはずです。

はい、それはすべてのノードで発生しました、そしてそれは予想されます。 偶然の一致は、このノードが具体的に最後に更新されたノードであり、他のノードが失われるのはその正確な時間です。

欠落しているノードの更新ログを取得しましたか？

欠落しているノードの更新ログを取得しましたか？

笑、この質問を入力していました。

おそらくバグは、すべてのノードが削除される前に、ゾーン全体がツリーから削除されることです。

明確にするために、私は個人的にコードを見ているのではなく、すべての情報があることを確認しようとしているだけです。 そして、私たちが今持っているもので、私たちはバグを見つけることができるはずだと思います。 失敗した単体テストを提供できる場合は、PRを自由に送信してください。

欠落しているノードの更新ログを取得しましたか？

はい、その欠落しているノードのゾーンが更新されていることを示しています。 すべてのノードのログエントリがあります

正直なところ、バグの原因はまだわかりませんが、問題が判明した場合は、PRまたは単体テストを提出します。

はい、その欠落しているノードのゾーンが更新されていることを示しています。 すべてのノードのログエントリがあります

もしそうなら、これが「欠落しているノードが消える正確なポイント」であると仮定します。 相関していない可能性があります。 新しいログを待ちましょう。 ファイルで取得したすべてのスケジューラログを共有できると便利です。

新しいロギングで再現するときに行います。 既存のものから、実際には、その更新直後のポッドスケジューリングが最初に失敗したことがわかります。 しかし、その間に何が起こったのかを知るのに十分な情報が得られないので、しばらくお待ちください...

@maelkスケジューラログでsnapshot state is not consistentで始まるメッセージを見たことがありますか？

完全なスケジューラログを提供することは可能ですか？

いいえ、そのメッセージは存在しません。 （繰り返しを避けるために）ストライプダウンされたログファイルを提供することもできますが、最初に、スナップショットの周りにさらにログが含まれる出力が得られるまで待ちましょう。

バグを見つけました。 問題はnodeTreenext（）関数にあり、場合によってはすべてのノードのリストを返さないことがあります。 https://github.com/kubernetes/kubernetes/blob/release-1.18/pkg/scheduler/internal/cache/node_tree.go#L147

ここに以下を追加すると表示されます： https ：

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[5:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

主な問題は、ノードを追加すると、一部のゾーンのインデックスが0にならないことです。 これを行うには、少なくとも2つのゾーンが必要です。一方は他方よりも短く、長いゾーンは、次の関数を初めて呼び出すときにインデックスが0に設定されていません。

私が行った修正は、next（）を最初に呼び出す前にインデックスをリセットすることです。 修正を示すためにPRを開きました。 もちろん、これは私が取り組んできたものであるため、1.18リリースには反対ですが、それを修正する方法（またはnext（）関数自体を修正する方法）を議論するためのものです。 マスターに対して適切なPRを開き、後で必要に応じてバックポートを実行できます。

反復で同じ問題に気づきました。 しかし、それをスナップショットの重複にリンクできませんでした。 @maelk、それが起こるシナリオをなんとか作成できましたか？

はい、私が置いた小さなコードを追加することで、単体テストで実行できます

現在、スナップショットのテストケースを追加して、これが適切にテストされていることを確認しています。

問題を再現し、彼のセットアップでテストを実行するのに役立つ@igraecaoに大いに感謝します

この悪名高い問題をデバッグしてくれてありがとう。 リストを作成する前にインデックスをリセットするのは安全なので、1.18および1.19パッチでもインデックスをリセットし、マスターブランチで適切に修正する必要があると思います。

next関数の目的は、NodeInfoListの導入によって変更されたため、確実に簡略化して、ツリーからリストを作成して開始するだけの関数であるtoListに変更することができます。毎回最初から。

私は今問題を理解しています：ゾーンが使い果たされているかどうかの計算は、各ゾーンのどこでこの「UpdateSnapshot」プロセスを開始したかを考慮していないため、間違っています。 そして、ええ、それは不均一なゾーンでのみ表示されます。

この@maelkを見つけるのは素晴らしい仕事です！

古いバージョンでも同じ問題があると思います。 しかし、それは私たちが毎回ツリーパスを行うという事実によって隠されています。 一方、1.18では、ツリーに変更が加えられるまで結果のスナップショットを作成します。

ラウンドロビン戦略がgeneric_scheduler.goに実装されたので、PRが行っているように、UpdateSnapshotの前にすべてのカウンターをリセットするだけで問題ないかもしれません。

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

@ ahg-gを再確認するだけで、新しいノードが常に追加/削除されているクラスターでも問題ないはずですよね？

根本原因を見つけてくれた@maelkに感謝します！

次の関数の目的はNodeInfoListの導入によって変更されたため、確実に簡略化して、ツリーからリストを作成し、毎回最初から開始する関数であるtoListに変更することができます。

cache.nodeTree.next()はスナップショットnodeInfoListの構築時にのみ呼び出されることを考えると、nodeTree構造体からインデックス（zoneIndexとnodeIndexの両方）を削除することも安全だと思います。 代わりに、ラウンドロビン方式でゾーン/ノードを反復処理する単純なnodeIterator()関数を考え出します。

ところで： https： //github.com/kubernetes/kubernetes/issues/91601#issuecomment -662663090にタイプミスがあり、ケースは次のようになります。

{
    name:           "add nodes to a new and to an exhausted zone",
    nodesToAdd:     append(allNodes[6:9], allNodes[3]),
    nodesToRemove:  nil,
    operations:     []string{"add", "add", "next", "next", "add", "add", "next", "next", "next", "next"},
    expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
    // with codecase on master and 1.18, its output is [node-6 node-7 node-3 node-8 node-6 node-3]
},

@ ahg-gを再確認するだけで、新しいノードが常に追加/削除されているクラスターでも問題ないはずですよね？

generic_scheduler.goのロジックについて話していると仮定します。そうであれば、ノードが追加されたか削除されたかはそれほど重要ではありません。避ける必要がある主なことは、毎回同じ順序でノードを反復することです。ポッドをスケジュールします。ポッド間でノードを反復処理するための適切な概算が必要です。

cache.nodeTree.next（）はスナップショットnodeInfoListの構築時にのみ呼び出されるため、nodeTree構造体からインデックス（zoneIndexとnodeIndexの両方）を削除しても安全だと思います。 代わりに、ラウンドロビン方式でゾーン/ノードを反復処理する単純なnodeIterator（）関数を考え出します。

はい、毎回同じ順序ですべてのゾーン/ノードを反復する必要があります。

特にそのバグのために、スナップショットリストを更新する機能の単体テストでPRを更新しました。 また、next（）関数をリファクタリングして、ラウンドロビンなしでゾーンとノードを反復処理できるため、問題が解消されます。

おかげで、良さそうに聞こえますが、それでも現在と同じように、つまり設計上、ゾーン間を繰り返す必要があります。

私はあなたがここで意味することを本当に理解していません。 ノードの順序が重要であり、ゾーン間をラウンドロビンする必要があるためですか、それともゾーンのすべてのノードをゾーンごとに一覧表示できますか？ それぞれ2つのノードからなる2つのゾーンがあり、その順序でそれらを期待しているとしましょう。それともまったく問題ではありませんか？

順序は重要です。リストを作成するときにゾーンを切り替える必要があります。 それぞれz1: {n11, n12}とz2: {n21, n22}の2つのノードからなる2つのゾーンがある場合、リストは{n11, n21, n12, n22}

わかりました、ありがとう、私はそれに考えます。 その間、クイックフィックスを続行できますか？ ところで、いくつかのテストはそれに失敗していますが、それが私のPRにどのように関連しているかわかりません

それらはフレークです。 1.18にもパッチを送ってください。

わかりました。 ありがとう

{
  name:           "add nodes to a new and to an exhausted zone",
  nodesToAdd:     append(allNodes[5:9], allNodes[3]),
  nodesToRemove:  nil,
  operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
  expectedOutput: []string{"node-6", "node-7", "node-3", "node-8", "node-6", "node-7"},
},

@maelk 、このテストは「ノード5」を無視するという意味ですか？

https://github.com/kubernetes/kubernetes/pull/93516で追加を修正した後、すべてのノードを繰り返すことができるテスト結果を見つけました。

{
            name:           "add nodes to a new and to an exhausted zone",
            nodesToAdd:     append(append(make([]*v1.Node, 0), allNodes[5:9]...), allNodes[3]),
            nodesToRemove:  nil,
            operations:     []string{"add", "add", "next", "next", "add", "add", "add", "next", "next", "next", "next"},
            expectedOutput: []string{"node-5", "node-6", "node-3", "node-7", "node-8", "node-5"},
},

ノード-5、6、7、8、3を繰り返すことができます。

ここで何かを誤解した場合はご容赦ください。

はい、それはそこにあったものに基づいて意図的に行われましたが、これがどのように不可解であるかがわかります。したがって、追加がより明確に動作するように作成することをお勧めします。 パッチをありがとう。

このバグはどれくらい前に存在したと思いますか？ 1.17？ 1.16？ AWSの1.17でまったく同じ問題が発生し、スケジュールされていないノードを再起動すると問題が修正されました。

@judgeaxl詳細を

https://github.com/kubernetes/kubernetes/issues/91601#issuecomment -662746695で述べたように、このバグは古いバージョンに存在していたと思いますが、一時的なものだと思います。

@maelk調査できますか？

ゾーン内のノードの分布も共有してください。

@alculquicondor残念ながら、

@alculquicondor申し訳ありませんが、他の理由ですでにクラスターを再構築しましたが、

/ retitleゾーンの不均衡がある場合、一部のノードはスケジューリングで考慮されません