web-dev-qa-db-ja.com

保留状態のKubernetes永続ボリュームクレームが無期限に

Google Compute Engineの永続ディスクをソースとするPersistentVolumeを作成しました。このディスクは既にフォーマットし、データでプロビジョニングしています。 Kubernetesは、PersistentVolumeが利用可能であると言います。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true

次に、PersistentVolumeClaimを作成して、このボリュームを複数のノードの複数のポッドに接続できるようにしました。ただし、kubernetesは無期限に保留状態にあると言います。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0

洞察はありますか？セレクタに何か問題があるかもしれません...

永続ディスクにデータを事前設定し、複数のノードにまたがるポッドがすべてそこから読み取れるようにすることは可能ですか？

kubernetespersistent-volumespersistent-volume-claims
28
Akash Krishnan

PersistentVolumeClaimは、指定されていない場合、storageClassNameフィールドをstandardにデフォルト設定することにすぐに気付きました。ただし、PersistentVolumeを作成するとき、storageClassNameにはデフォルトがないため、セレクターは一致を見つけません。

次は私のために働いた：

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  storageClassName: standard
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0
40
Akash Krishnan

動的プロビジョニングでは、PVとPVCを別々に作成する必要はありません。 Kubernetes 1.6+には、GKEおよびその他のクラウド環境用のデフォルトのプロビジョニング機能があります。PVCを作成するだけで、PVおよび基盤となる永続ディスクを自動的にプロビジョニングできます。

動的プロビジョニングの詳細については、以下を参照してください。

https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes/

12
Anirudh Ramanathan

VMにも十分なディスク容量があることを確認してください。

0
William Loch

PersistentVolumeClaimが無期限に保留フェーズにあるという同じ問題に直面しました。PersistentVolumeClaimで行ったように、PersistentVolumeでstorageClassNameを 'default'として提供しようとしましたが、この問題は修正されませんでした。

Persistentvolume.ymlに1つの変更を加え、PersistentVolumeClaim構成をファイルの上に移動してから、ymlファイルの2番目の構成としてPersistentVolumeを移動しました。この問題は修正されました。

この「保留」フェーズの問題を解決するには、最初にPersistentVolumeClaimが作成され、その後PersistentVolumeが作成されることを確認する必要があります。

私はこの答えを何度かテストした後に投稿しています。

0
Adnan Raza

2つのPersistentVolumeがmicrok8sに対して同じ値を持っている場合、spec/hostPath/path 1.14.1でこの動作を確認しました。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-name
  labels:
    type: local
    app: app
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/k8s-app-data"

Microk8はイベントベース（1ノードクラスターでは不要）であり、失敗した操作に関する情報を破棄するため、ほとんどすべての失敗に対して不必要な恐ろしいフィードバックが発生します。

0
Karl Richter