バグを説明する
1つのノードのTridentCSIノードプラグイン( csi.trident.netapp.io
)は、Kubernetesバージョンがv1.18.9からv1.19.4に更新された後、登録が解除されるようになりました。 このノードのポッドは、Tridentボリュームをマウントおよびアンマウントできなくなりました。
kubeletログに次のメッセージが表示されます。
csi.trident.netapp.io
は、登録ソケット( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock
)が削除されたため、登録が解除されました。
I1119 05:47:54.246972 6550plugin_watcher.go:212]ソケットパス/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sockを目的の状態キャッシュから削除します
I1119 05:47:53.162305 6550 reconciler.go:139] operationExecutor.UnregisterPluginがプラグインの「/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock」で開始されました(プラグインの詳細:&{/ var /lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock 2020-11-04 05:08:19.553684094 +0000 UTC m = + 38.893901704 0x704c200 csi.trident.netapp.io})
I1119 05:47:53.163390 6550 csi_plugin.go:177] kubernetes.io/csi:プラグインcsi.trident.netapp.ioのregistrationHandler.DeRegisterPluginリクエスト
csi.trident.netapp.io
が見つからなかったため、ポッドはボリュームをアンマウントできませんでした。
E1119 09:02:52.819122 6550nestedpendingoperations.go:301] "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^ pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e podName:ad18a7d1-4090の操作
このノード上の2つのtrident-csi
(ノードプラグイン)ポッドが非常に短時間同時に実行されており、新しい$#$ 1 $#$が開始された後に古いdriver-registrar
が停止していることがわかりました。
driver-registrar
は、SIGTERM( node_register.go#L113-L116 )を受信すると、登録ソケット( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock
)を削除します。 ソケットを削除すると、kubeletはTridentプラグインの登録を解除します。 これが問題の原因だと思います。
Trident-csi(ノードプラグイン)ポッドはDaemonSetによって管理されます。 通常、すべてのノードで実行されるポッドは1つだけです。 ただし、Kubernetesが更新された後、trident-csiデーモンセットがtrident-operator
によって再作成されました。 DaemonSetを削除すると、2つのポッド(古いものと新しいもの)を同時に実行できます。
これはtrident-operator
ログで確認しました。
ここで、 trident-csi
デーモンセットが削除されました。
time = "2020-11-19T05:47:45Z" level = debug msg = "KubernetesDaemonSetを削除しました。" DaemonSet = trident-csi名前空間=トライデント
その後すぐにtrident-csi
デーモンセットが作成されました。
time = "2020-11-19T05:47:45Z" level = debug msg = "オブジェクトを作成しています。" kind = DaemonSet name = trident-csi namespace = trident
Kubernetesが更新された後、 shouldUpdate
フラグがtrueに設定されました( controller.go#L1110 )。 shouldUpdate
フラグにより、 trident-csi
デーモンセットが削除されたようです( installer.go#L1489-L1494 )。
環境
silenceAutosupport: true
(トライデントオペレーター)再現するには
Kubernetesバージョンを更新すると、この問題が再現される場合があります。 Kubernetesの更新には時間がかかり、常に発生するとは限らないため、さまざまなデモンストレーションを通じて、この問題の原因となる次の動作を確認しました。
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
Drivers:
csi.trident.netapp.io:
Node ID: <NODE_NAME>
Topology Keys: [topology.kubernetes.io/zone]
trident-csi
DaemonSetをコピーして、各ノードで2つのtrident-csiポッドを実行します。$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -
trident-csi-2
DaemonSetを削除します。$ kubectl delete ds -n trident trident-csi-2
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:
trident-csi
DaemonSetを削除します。 DaemonSetは、トライデントオペレーターによってすぐに再作成されます。$ kubectl delete ds -n trident trident-csi
trident-csi
ポッドが表示されます。$ kubectl get pods -n trident -o wide
予想される行動
Kubernetesバージョンが更新された後、ポッドはTridentボリュームをマウントおよびアンマウントできます。
追加のコンテキスト
なし
こんにちは@tksm
この問題の詳細を提供し、根本的な原因を詳しく調べていただきありがとうございます。分析は非常に役立ちます。 デーモンセットポッドの終了とレクリエーションの取得の間のウィンドウは重要であり、後者は前者が完了した場合にのみ発生する必要があります。 したがって、オペレーターは、デーモンセットを作成する前に、前のデーモンセットに属するポッドがすべて削除されてから、新しいデーモンセットのみが作成されることを確認する必要があります。
好奇心から、アップグレード中にこの問題が発生したクラスターの数を聞いてもよろしいですか?
ありがとう!
こんにちは、@ ntap-arorar
ご確認、ありがとうございます。 あなたのアイデアでこの問題は解決すると思います。
テストとして少数のクラスターのみをアップグレードしたため、これまでに1つのクラスターでこの問題が発生しました。
この修正は、Tridentv21.01リリースに含まれます。
この問題は、 commit820579dで修正されました。
最も参考になるコメント
この修正は、Tridentv21.01リリースに含まれます。