ローカルPV を有効にして、ベアメタkubernetes 1.7に事前定義されたPostgreSQLクラスターをセットアップしたい。 3つの作業ノードがあります。各ノードでローカルPVを作成し、ステートフルセットを正常にデプロイします(Postgresレプリケーションをセットアップするためのいくつかの複雑なスクリプトを使用)。
ただし、volumeClaimTemplatesとPersistentVolumeClaimの間に一種の命名規則があることに気づきました。例えば
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: postgres
volumeClaimTemplates:
- metadata:
name: pgvolume
作成されたpvcはpgvolume-postgres-0
、pgvolume-postgres-1
、pgvolume-postgres-2
。
tricky をいくつか使用して、PVCを手動で作成し、セレクターによってターゲットPVにバインドします。ステートフルセットをもう一度テストします。ステートフルセットはこれらのPVCを使用して非常に満足しているようです。
テストは無事終了しましたが、まだこの質問があります。 volumeClaimTemplatesの命名規則に依存できますか?これは文書化されていない機能ですか?
ステートフルセットに基づく APIリファレンス
volumeClaimTemplatesは、ポッドが参照できるクレームのリストです。 StatefulSetコントローラーは、ポッドのIDを維持する方法で、ネットワークIDをクレームにマッピングします。このリスト内のすべてのクレームには、テンプレート内の1つのコンテナーに少なくとも1つの一致する(名前による)volumeMountが必要です。このリストの要求は、テンプレート内の同じ名前のボリュームよりも優先されます。
だからあなたはそれに頼ることができると思います。
さらに、永続ボリュームの動的プロビジョニングを活用するためにストレージクラスを定義できるため、手動で作成する必要はありません。
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: my-storage-class
resources:
requests:
storage: 1Gi
詳細については、 Kubernetesの動的プロビジョニングおよびストレージクラス を参照してください。