現在、私はReadWriteOnceとPod #1とPod #2の2つのPVCを持っています。どちらもNode #1で実行されています。ポッドリスケジュール時にReadWriteOnce PVCをAWS EBS/GCP PersistentDiskが拒否できますか？
次に、Pod #2が新しいDockerイメージで更新されます。ただし、同時にPod #3が実行され、Node #1に割り当てられます。 Node #1が満杯になったので、Pod #2はKubernetesによってNode #2に割り当てられました。
AWS EBSとGoogle PersistentDiskは1つのノードにしかマウントできないため、Pod #2は先に請求されたPVCに接続できなくなりますか？
「はい」の場合、この問題の回避方法を教えてください。
はい、これは現在のAWSとGCEのストレージ配信によるpv/pvcの欠点です。
これを回避するには、この制限がない別のストレージインフラストラクチャを使用する必要があります。可能性は、CEPH、Gluster、scaleIO（およびその他）です。これらのソリューションは、ストレージをディスクから抽象化し、ノードに依存しないストレージレイヤーを提供します。
これは問題ではありません。 Pod #2がNode #2にスケジュールされている場合、Kubernetesは自動的にボリュームをNode #1から切り離し、Node #2に添付してPod #2に接続して使用する必要があります。
私はそれが起こるべきではないと思います。ボリュームは、 'Node＃1'の' Pod＃1'でも必要です。したがって、K8Sはそれをノード＃1から切り離すべきではありません。 K8Sが 'Pod＃1'を' Node＃2'に再割り当てしない限り... –
2つのPVCがあるので、2つの対応するPVがあると仮定しました。 1つのPVだけがあれば、別のノードでスケジュールされたポッドに問題が発生します。 – coreypobrien
PVとPVCの間に1対1のマッピングが必要な場合は、PVCを使用する目的を破るのですか？その場合、動作はダイナミックPVC（Podが削除されたときに終了しない）と同じであり、 –
この種のユースケースは非常に一般的であるため、PDとEBSにとっては残念です。私は自分自身を維持するのではなく、管理されたストレージを使うことを好むまだPDとEBSを安全に使用したい場合、他の解決方法はありますか？おそらく動的PVを使用しますか？ –