3

3 つのノードで構成される GCE コンテナ クラスタがあります。すべてのノードで、次のような POD を実行します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: test-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: none
        track: stable
    spec:
      containers:
        - name: hello
          image: gcr.io/persistent-volumes-test/alpine:v1.2
          resources:
            limits:
              cpu: 0.2
              memory: "10Mi"
          volumeMounts:
          - mountPath: "/persistentDisk"
            name: persistent-disk
          ports:
          - containerPort: 65535
            name: anti-affinity
            hostPort: 65535
      volumes:
        - name: persistent-disk
          persistentVolumeClaim:
            claimName: myclaim

「アンチアフィニティ」ポートを定義するトリックにより、すべての POD が異なるノードで実行されることが保証されます。次のように定義された 3 つの PersistentVolume を作成しました。

 kind: PersistentVolume
 apiVersion: v1
 metadata:
    name: persistent-volume-1
    annotations:
      volume.beta.kubernetes.io/storage-class: "slow"
    labels:
      release: "dev"
 spec:
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    gcePersistentDisk:
      pdName: persistent-disk-1
      fsType: ext4

そしてそれらはうまく展開されています

NAME                  CAPACITY   ACCESSMODES   STATUS      CLAIM             REASON    AGE
persistent-volume-1   10Gi       RWO           Released    default/myclaim             13h
persistent-volume-2   10Gi       RWO           Released    default/myclaim             5h
persistent-volume-3   10Gi       RWO           Available                               5h

クレームの定義は次のとおりです。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
  annotations:
    volume.beta.kubernetes.io/storage-class: "slow"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  selector:
    matchLabels:
      release: "dev"

私が気付いたのは、クレームが作成したボリュームの 1 つにのみバインドされているため、PODS の 1 つだけが正常にデプロイされるということです。私が予想していたのは、クレームが POD によって使用された場合、バインド先の利用可能なボリュームが 1 つ見つかり、セレクター ルールに一致することでした。言い換えれば、PersistentVolumeClaims について私が解釈したのは、POD は、PVC 仕様に一致する PersistentVolumes セット内の使用可能なボリュームを検索するためにクレームを使用するということです。それが私の質問です:

同じ POD の異なるインスタンスで同じ PersistentVolumeClaim を使用して、異なる PersistentVolume に接続できますか? または、クレームが作成されると、1 つのボリュームのみにバインドされ、他のボリュームにバインドできなくなりますか?

正しい答えが 2 番目の場合、POD ごとに要求を作成せずに展開するときに、POD を PersistentVolume (セットから選択) に動的にバインドする方法を作成して、接続する必要があるすべてのボリュームに対して特定の POD を作成することを回避するにはどうすればよいですか?に?

4

1 に答える 1