3

ポッドの再スケジュール後に新しいノードにボリュームをアタッチする際の Kubernetes の動作について質問があります。

クラスターでの一般的な動作は次のとおりです。

  1. ノード n1 が使用不可になる

  2. ボリューム v1 のポッド A は、ノード n2 で再スケジュールされます

  3. ボリューム v1 をノード n1 から切り離しています。これには数秒かかります

  4. ノード n2 の kubelet は、ボリューム v1 をポッド A にアタッチしようとします

  5. ボリューム v1 はノード n1 からまだ切り離されていないため、Attach 呼び出しは次のように失敗します。

    Sep 27 11:43:24 node n2 kubelet-wrapper[787]: E0927 11:43:24.794713     787 nestedpendingoperations.go:263] Operation for "\"kubernetes.io/cinder/volume_v1_id\"" failed. No retries permitted until 2018-09-27 11:43:25.294659022 +0000 UTC m=+1120541.835247469 (durationBeforeRetry 500ms). Error: "AttachVolume.Attach failed for volume \"volume v1\" (UniqueName: \"kubernetes.io/cinder/volume_2_id\") from node \"node n2\" : disk volume_v2_id path /dev/vdc is attached to a different instance (pod node n1)"

  6. この接続エラーの後、kubelet は永久にボリューム v1 をマウントしようとします (ボリュームが接続されていないため失敗します)。

    Sep 27 11:43:26 node n2 kubelet-wrapper[787]: E0927 11:43:26.870106     787 attacher.go:240] Error: could not find attached Cinder disk "volume_v1_id" (path: ""): <nil>

私の質問は: k8s がマウントを試みる前に再度接続を試みないのはなぜですか?

ここでの問題は、デタッチが十分に迅速に行われている場合は問題がないことですが、kubelet によって Attach が呼び出されたときにデタッチがまだ行われていない場合は、スタックします。

コードを掘り下げると、動作は WaitForAttachAndMount のようです。1/ Try Attach 2/ 接続の結果がどうであれ、Try Mount でループします。

予想される動作は 1/ Try Attach でループ 2/ ある時点で Attach が成功した場合、Try Mount でループ?

この質問はhttps://github.com/kubernetes/kubernetes/issues/69158に関連しています

4

1 に答える 1

1

私の見解は、次のとおりです。

  1. アタッチ API への応答をボリューム プロバイダー (EBS、Cinder、GCP、Ceph など) に任せたい場合は、失敗するよりも無期限にアタッチを試み続け、無期限にマウントを試みるのが理にかなっています。プロバイダーが何らかのメンテナンスを行っており、API が一時的に失敗している可能性があります。これは、システムをより自動化したい場合です。

  2. 何らかの理由でユーザーがボリュームを手動でアタッチし、その後のマウントを成功させたい場合は、アタッチ -> 失敗して無期限にマウントするのが理にかなっています。私の意見では、これはオプションにする必要があり、1. をデフォルトにする必要があります。

于 2018-10-23T22:49:04.447 に答える