web-dev-qa-db-ja.com

永続ボリュームのサイズを変更できますか？

私はKubernetesでMySQLデプロイメントを実行していますが、割り当てられたスペースが十分ではないようです。最初に50GBの永続的なボリュームを追加し、それを100GBに拡張したいと思います。

永続ボリュームの主張が作成後に不変であることをすでに見ましたが、どういうわけか永続ボリュームのサイズを変更してから主張を再作成できますか？

kubernetesgoogle-kubernetes-engine
20
perrohunter

はい、1.11の時点で 永続的なボリュームはサイズ変更可能 特定のクラウドプロバイダーで。ボリュームサイズを増やすには：

  1. kubectl edit pvc $your_pvcを使用してPVCサイズを編集します
  2. ボリュームを使用してポッドを終了します。

ボリュームを使用するポッドが終了すると、ファイルシステムが拡張され、PVのサイズが増加します。詳細については、上記のリンクを参照してください。

12
Dmitry Minkovsky

Kubernetes 1.9（1.8のアルファ版）では、一部のボリュームタイプが可能です：gcePersistentDisk、awsElasticBlockStore、Cinder、glusterfs、rbd

PersistentVolumeClaimResizeフィールドがtrueに設定されているallowVolumeExpansion入場プラグインとストレージクラスを有効にする必要があります。

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims の公式ドキュメントを参照してください

15
csanchez

いいえ、Kubernetesはまだ自動ボリュームサイズ変更をサポートしていません。

ディスクのサイズ変更は、現時点では完全に手動のプロセスです。

所定の容量でKubernetes PVオブジェクトを作成し、PVをPVCにバインドし、ポッドで使用するためにノードに接続/マウントすると仮定します。ボリュームサイズを大きくすると、ポッドは引き続き問題なくディスクを使用できますが、追加のスペースにアクセスできなくなります。

ボリュームの追加スペースを有効にするには、パーティションのサイズを手動で変更する必要があります。それは here の指示に従って行うことができます。ボリュームを参照しているポッドを最初に削除し、デタッチするのを待ってから、ボリュームを手動でアタッチ/マウントしてからVMアクセス権のあるインスタンスに移動し、必要な手順を実行する必要がありますサイズを変更します。

機能リクエストを追跡するための未解決の問題 ＃35941 .

7
Saad Ali

特定の実験的機能がクラスターで有効になっている場合、1.8以上の場合、gcePersistentDiskやawsBlockStoreを含む一部のボリュームタイプで サポート があります。

他のボリュームタイプの場合は、今のところ手動で行う必要があります。さらに、ポッドがオンラインのときにこれを自動的に実行するサポート（ニース！）が近づいています 将来のバージョン（現在1.11で予定） ：

今のところ、これらは永続ディスクのサイズ変更を現在サポートしていないAzureDiskボリュームタイプ（管理対象ディスクの場合）でこれを手動で行うための手順です（ただし、 これもサポートされています =）：

  1. Ensure PVには再生ポリシー「保持」が設定されています。
  2. ステートフルセットと関連するポッドを削除します。 PVおよびPVCのステータスはBoundのままですが、KubernetesはPVを解放する必要があります。 Prometheusなど、オペレーターによって管理されるステートフルセットには特に注意してください。オペレーターは一時的に無効にする必要がある場合があります。 Scaleを使用して、一度に1つのポッドを実行することもできます。これには数分かかる場合があります。しばらくお待ちください。
  3. Azure APIまたはポータルを使用して、PVの基盤となるストレージのサイズを変更します。
  4. 基盤となるストレージをVM（Kubernetesマスターなど）にVM設定で「ディスク」として追加してマウントします。VMでは、 e2fsckおよびresize2fsは、PV上のファイルシステムのサイズを変更します（ext3/4 FSを想定）ディスクをアンマウントします。
  5. 関連するPVCのJSON/YAML構成を保存します。
  6. 関連するPVCを削除します。 PVはステータスReleasedに変わるはずです。
  7. PVのYAML設定を編集します。その後、PVステータスはAvailable：になります。
    1. spec.capacity.storageで新しいボリュームサイズを指定します。
    2. spec.claimrefuidおよびresourceVersionフィールドを削除し、
    3. status.phaseを削除します。
  8. 保存したPVC構成を編集します：
    1. metadata.resourceVersionフィールドを削除し、
    2. メタデータpv.kubernetes.io/bind-completedおよびpv.kubernetes.io/bound-by-controller注釈を削除し、
    3. spec.resources.requests.storageフィールドを更新されたPVサイズに変更します。
    4. status内のすべてのフィールドを削除します。
  9. 編集したPVC構成を使用して新しいリソースを作成します。 PVCはPending状態で開始する必要がありますが、PVとPVCの両方はBoundに比較的迅速に移行する必要があります。
  10. StatefulSetを再作成するか、ステートフルセット構成を変更して、ポッドを再起動します。
4
Raman

PVC/PVの「サイズ変更」に関しては、k8ではまだサポートされていませんが、1.9で届く可能性があると思います

PVC/PVと（例）GCE PD= ..を処理することにより、同じ最終結果を達成することが可能です。

たとえば、PVCとStorageClassリソースを介して動的にプロビジョニングされたPVを備えたgitlab展開がありました。ここに私が実行した手順があります：

  1. PD（データに関心がある場合）のスナップショットを撮ります）
  2. PVのReclaimPolicyが「Retain」であることを確認し、必要に応じてパッチをここで詳細に説明します。 https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/
  3. kubectl describe pv <name-of-pv>（後でPVマニフェストを作成するときに役立ちます）
  4. 展開/ポッドを削除します（おそらく必須ではありませんが、よりクリーンに見えます）
  5. PVCとPVを削除する
  6. PDが、何も使用していないものとして認識されていることを確認します（例：Googleコンソール、compute/disksページ）
  7. Resize PDクラウドプロバイダーで（たとえば、GCEを使用すると、ディスクが使用中であっても、これは実際にはより早い段階で実行できます）
  8. K8s PersistentVolumeマニフェストを作成します（これは以前にStorageClassリソースを使用して動的に行われていました）。 PersistentVolume yaml仕様では、"gcePersistentDisk: pdName: <name-of-pd>"を定義し、ステップ3で取得した他の詳細とともに、PVに必要な新しい容量にspec.capacity.storageを更新することを確認します（必須ではなく、ここでは効果はありませんが、後世のためにPVCマニフェストのストレージ容量/値を更新することをお勧めします）
  9. kubectl apply（または同等のもの）を使用して展開/ポッド、PVC、およびPVを再作成します。

注：既存のデプロイメント/ポッドの一部を削除するなど、一部の手順は必須ではない場合があります。個人的には削除することを好みますが、ReclaimPolicyが保持されていることを確認し、スナップショットを持っています。

4
eversMcc