1

この質問は、Kubernetes 内の PersistentVolume および PersistentVolumeClaim 構成の動作に関するものです。ドキュメントを読みましたが、いくつかの疑問が残りました。

Azure Kubernetes Service を使用してクラスターをホストしており、多くのポッドに共有永続ストレージ バックエンドを提供したいと考えています。これを実現するために PersistentVolumes を使用する予定です。

このシナリオでは、AzureFile ストレージ リソースに基づく PersistentVolume を発行します。Jenkins をクラスターにデプロイし、jenkins_home ディレクトリを PersistentVolume に保存して、インスタンスがポッドとノードの障害に耐えられるようにします。複数のマスター Jenkins ノードを実行し、すべて同様の展開 yaml で構成します。

必要なすべてのストレージ アカウントと適用可能な共有、および必要なシークレットを事前に作成しました。

まず、次の PersistentVolume 構成を発行しました。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-azure-file-share
  labels:
    usage: jenkins-azure-file-share
spec:
  capacity:
    storage: 100Gi
  accessModes:
   - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  azureFile:
    secretName: azure-file-secret
    shareName: jenkins
    readOnly: false
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=1000
    - gid=1000

その後、次の PersistentVolumeClaim 構成を発行しました。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-file-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: ""
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: "jenkins-azure-file-share"

次に、デプロイ内でこのクレームを次のように使用します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: jenkins-instance-name
spec:
  replicas: 1
  template:
    metadata:
      labels:
        role: jenkins
        app: jenkins-instance-name
    spec:
      containers:
      - name: jenkins-instance-name
        image: ContainerRegistry.azurecr.io/linux/jenkins_master:latest
        ports:
        - name: jenkins-port
          containerPort: 8080
        volumeMounts:
        - name: jenkins-home
          mountPath: /var/jenkins_home
          subPath: "jenkins-instance-name"
      volumes:
      - name: jenkins-home
        persistentVolumeClaim:
          claimName: "jenkins-file-claim"
      imagePullSecrets:
      - name: ImagePullSecret

これはすべて期待どおりに機能しています。複数の Jenkins マスターを Kubernetes クラスターにデプロイしており、それぞれが各マスター インスタンスに固有の共有に新しいフォルダーを正しく割り当てています。 ここに画像の説明を入力

今、私の質問のために

PersistentVolume は 100Gig のストレージで構成されています。これは、Kubernetes がこのボリュームで最大 100Gig の合計ストレージしか許可しないということですか?

PersistentVolumeClaim が PersistentVolume にバインドされている場合、PersistentVolumeClaim が 10Gig のストレージ用に構成されていても、PersistentVolumeClaim は合計で 100Gig のストレージを使用できることを示しているように見えます。

C:\ashley\scm\kubernetes>kubectl get pv
NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY  STATUS    CLAIM     STORAGECLASS   REASON    AGE
jenkins-azure-file-share    100Gi     RWX            Retain           Bound     default/jenkins-file-claim                          2d

C:\ashley\scm\kubernetes>kubectl get pvc
NAME                       STATUS    VOLUME                      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
jenkins-homes-file-claim   Bound     jenkins-azure-file-share    100Gi     RWX                           2d

これは get pvc コマンドからの出力が間違っているだけですか、それとも get pvc コマンドの出力を誤解していますか?

この方法で PersistentVolumeClaim を共有する場合。

  1. 各デプロイメントは、PersistentVolume の 100Gig 容量から構成された最大 10Gig のストレージにのみアクセスできますか?
  2. または、各デプロイメントは、PersistentVolume 用に構成された合計 100Gig のストレージの独自の 10Gig スライスにアクセスできますか?

この構成では、単一の PersistentVolumeClaim 容量が完全に使用されるとどうなりますか? この単一の PersistentVolumeClaim を使用しているすべての展開は機能しなくなりますか?

4

1 に答える 1

1

したがって、PVC の場合、この構成で利用できるのは 10Gig だけです。pvについては同じだと思いますが、この場合は確かではありませんが、一貫性のためにそうあるべきです。また、この制限のいずれかに達すると動作が停止するため、11 個の Jenkins を実行している場合、1 つの PVC で制限に達していなくても失敗します。

于 2018-05-25T15:54:39.373 に答える