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 を作成することを回避するにはどうすればよいですか?に?