私はk8sにデプロイメント（dep1）をセットアップしており、アクセスモードReadWriteOnceに関連付けられた永続的なボリュームがあります。私は、CPU使用量が特定のしきい値を超えている場合、デプロイメントを自動的にスケーリングするdep1を持つHorizontalPodAutoscaleリソースを持っています。デプロイメントが複数のノードに分散されているとどうなりますか？自動スケーリングは機能しますか？ 一般に、ReadWriteOnceモードでPVを使用する場合、自動スケーリングに関する懸念はありますか？ReadWriteOnceアクセスモードでは、関連するポッドの自動スケーリングが可能ですか？
私はまだ自分自身を試していませんでしたが、私はそれがtype of volumeと仕事をすることに依存していると思います。 ebsをPVとして使用している場合、同時に複数のノードにまたがるマウントは不可能で、異なるノードでスケジュールされていると、ポッドは失敗します。一方、ボリュームのタイプがnfsの場合は、複数のノードでのマウントが可能です。
あなたのアクセスモードポリシーを忘れてはいけないと言われています。定義ごとにReadWriteOnceは、単一ノードによるマウントのみを許可します。あなたのシナリオではReadWriteManyに変更する必要があると思います。
このアクセスモード
ReadWriteOnceの定義である - ボリュームは、単一のノードによって読み書きとして実装することができる
ReadOnlyMany - ボリュームが読み取り専用でマウントすることができます多くのノード
ReadWriteMany - ボリュームは、多くのノードによって読み書きとして実装することができる
一部のボリュームタイプは、一度に1つのノード（たとえばEBS）にのみReadWriteOnceをマウントすることができます。したがって、ボリュームが別のノードのpodによって既に要求されている場合はノードによる自動拡張が許可されません。 ReadWriteMany（例えばNFS）であり、ノードごとの自動スケーリングが可能です。
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
下記の表を参照してください。