GitLabチャートを永続ボリュームで構成する

含まれているサービスの一部では、クラスターがアクセスできるディスクを指定するPersistent Volumesを介して構成された、永続ストレージが必要です。このチャートをインストールするために必要なストレージ設定に関するドキュメントは、ストレージガイドにあります。

インストール後のストレージの変更は、クラスターの管理者が手動で処理する必要があります。インストール後のこれらのボリュームの自動管理は、GitLabチャートでは処理されません。

最初のインストール後に自動的に管理されない変更の例を次に示します:

異なるボリュームをポッドにマウントする
有効なaccessModesまたはStorage Classの変更
ボリュームのストレージサイズの展開。Kubernetes 1.11では、Storage ClassでallowVolumeExpansionがtrueに設定されている場合、ボリュームのストレージサイズの展開がサポートされます。

これらの変更の自動化が複雑になる理由は次のとおりです:

Kubernetesでは、既存のPersistentVolumeClaimのほとんどのフィールドへの変更は許可されていません
手動で構成されていない限り、PVCは動的にプロビジョニングされたPersistentVolumesへの唯一の参照です
Deleteは、動的にプロビジョニングされたPersistentVolumesのreclaimPolicyのデフォルトです

これは、変更を加えるには、PersistentVolumeClaimを削除し、変更を加えて新しいものを作成する必要があることを意味します。ただし、デフォルトのreclaimPolicyにより、PersistentVolumeClaimを削除すると、PersistentVolumesと基盤となるディスクが削除される可能性があります。また、適切なvolumeNamesやlabelSelectorsで構成されていない限り、チャートはアタッチするボリュームを認識しません。

このプロセスをより簡単にする方法を引き続き検討しますが、今のところ、ストレージを変更するには手動プロセスに従う必要があります。

GitLabボリュームの特定

使用されているボリューム/クレームを見つけます:

kubectl --namespace <namespace> get PersistentVolumeClaims -l release=<chart release name> -ojsonpath='{range .items[*]}{.spec.volumeName}{"\t"}{.metadata.labels.app}{"\n"}{end}'

<namespace>は、GitLabチャートをインストールしたネームスペースに置き換える必要があります。
<chart release name>は、GitLabチャートのインストールに使用した名前に置き換える必要があります。

コマンドは、ボリューム名のリストと、そのボリュームが対象とするサービスの名前を出力します。

例:

$ kubectl --namespace helm-charts-win get PersistentVolumeClaims -l release=review-update-app-h8qogp -ojsonpath='{range .items[*]}{.spec.volumeName}{"\t"}{.metadata.labels.app}{"\n"}{end}'
pvc-6247502b-8c2d-11e8-8267-42010a9a0113  gitaly
pvc-61bbc05e-8c2d-11e8-8267-42010a9a0113  minio
pvc-61bc6069-8c2d-11e8-8267-42010a9a0113  postgresql
pvc-61bcd6d2-8c2d-11e8-8267-42010a9a0113  prometheus
pvc-61bdf136-8c2d-11e8-8267-42010a9a0113  redis

ストレージを変更する前に

変更を行う担当者は、クラスターへの管理者アクセス権と、使用されているストレージソリューションへの適切なアクセス権を持っている必要があります。多くの場合、変更は最初にストレージソリューションに適用する必要があり、その後、結果をKubernetesで更新する必要があります。

変更を行う前に、PersistentVolumesがRetain reclaimPolicyを使用していることを確認して、変更中に削除されないようにする必要があります。

まず、使用されているボリューム/クレームを見つけます。

次に、各ボリュームを編集し、specフィールドのpersistentVolumeReclaimPolicyの値を、DeleteではなくRetainに変更します

例:

kubectl --namespace helm-charts-win edit PersistentVolume pvc-6247502b-8c2d-11e8-8267-42010a9a0113

出力の編集:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: gce-pd-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
  creationTimestamp: 2018-07-20T14:58:43Z
  labels:
    failure-domain.beta.kubernetes.io/region: europe-west2
    failure-domain.beta.kubernetes.io/zone: europe-west2-b
  name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  resourceVersion: "48362431"
  selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  uid: 650bd649-8c2d-11e8-8267-42010a9a0113
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 50Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: repo-data-review-update-app-h8qogp-gitaly-0
    namespace: helm-charts-win
    resourceVersion: "48362307"
    uid: 6247502b-8c2d-11e8-8267-42010a9a0113
  gcePersistentDisk:
    fsType: ext4
    pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113
# Changed the following line
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
status:
  phase: Bound

ストレージの変更

まず、クラスターの外部でディスクに必要な変更を加えます。(GKEでディスクのサイズを変更するか、スナップショットまたはクローンから新しいディスクを作成するなど)。

これを行う方法、およびダウンタイムなしでライブで実行できるかどうかは、使用しているストレージソリューションによって異なり、このドキュメントでは説明できません。

次に、これらの変更をKubernetesオブジェクトに反映させる必要があるかどうかを評価します。たとえば、ディスクストレージサイズの拡張では、PersistentVolumeClaimのストレージサイズの設定は、新しいボリュームリソースがリクエストされた場合にのみ使用されます。したがって、さらに多くのディスク（追加のGitalyポッドで使用するため）をスケールアップする場合は、PersistentVolumeClaimの値を増やすだけで済みます。

変更をKubernetesに反映させる必要がある場合は、ストレージを変更する前にセクションで説明されているように、ボリュームのreclaim policyを更新したことを確認してください。

ストレージの変更についてドキュメント化されているパスは次のとおりです:

既存のボリュームへの変更

まず、変更するボリューム名を探します。

kubectl editを使用して、必要な設定の変更をボリュームに加えます。(これらの変更は、アタッチされたディスクの実際の状態を反映するための更新のみである必要があります)

例:

kubectl --namespace helm-charts-win edit PersistentVolume pvc-6247502b-8c2d-11e8-8267-42010a9a0113

出力の編集:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: gce-pd-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
  creationTimestamp: 2018-07-20T14:58:43Z
  labels:
    failure-domain.beta.kubernetes.io/region: europe-west2
    failure-domain.beta.kubernetes.io/zone: europe-west2-b
  name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  resourceVersion: "48362431"
  selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  uid: 650bd649-8c2d-11e8-8267-42010a9a0113
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    # Updated the storage size
    storage: 100Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: repo-data-review-update-app-h8qogp-gitaly-0
    namespace: helm-charts-win
    resourceVersion: "48362307"
    uid: 6247502b-8c2d-11e8-8267-42010a9a0113
  gcePersistentDisk:
    fsType: ext4
    pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
status:
  phase: Bound

変更がvolumeに反映されたので、claimを更新する必要があります。

PersistentVolumeClaimを変更するセクションの手順に従います。

クレームにバインドするようにボリュームを更新する

別のターミナルで、claimのステータスがバインドに変更されるのを監視し始め、次のステップに進んで、新しいクレームで使用できるようにボリュームを作成します。

kubectl --namespace <namespace> get --watch PersistentVolumeClaim <claim name>

新しいクレームで使用できるようにボリュームを編集します。.spec.claimRefセクションを削除します。

kubectl --namespace <namespace> edit PersistentVolume <volume name>

出力の編集:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: gce-pd-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
  creationTimestamp: 2018-07-20T14:58:43Z
  labels:
    failure-domain.beta.kubernetes.io/region: europe-west2
    failure-domain.beta.kubernetes.io/zone: europe-west2-b
  name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  resourceVersion: "48362431"
  selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  uid: 650bd649-8c2d-11e8-8267-42010a9a0113
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 100Gi
  gcePersistentDisk:
    fsType: ext4
    pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
status:
  phase: Released

Volumeへの変更後まもなく、クレームステータスを監視しているターミナルにBoundが表示されるはずです。

最後に、GitLabチャートに変更を適用します

別のボリュームへの切り替え

新しいボリュームに切り替えたい場合は、古いボリュームから適切なデータのコピーを含むディスクを使用して、最初にKubernetesに新しいPersistent Volumeを作成する必要があります。

ディスクのPersistent Volumeを作成するには、ストレージタイプのドライバー固有のドキュメントを見つける必要があります。同じStorage Classの既存のPersistent Volumeを開始点として使用することもできます:

kubectl --namespace <namespace> get PersistentVolume <volume name> -o yaml > <volume name>.bak.yaml

ドライバーのドキュメントに従う際に留意すべき点がいくつかあります:

ドライバーを使用してPersistent Volumeを作成する必要があります。多くのドキュメントに示されているように、ボリュームを持つPodオブジェクトではありません。
ボリュームのPersistentVolumeClaimを作成する必要はありません。代わりに既存のクレームを編集します。

ドライバーのドキュメントには、多くの場合、Podでドライバーを使用する例が含まれています。次に例を示します:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # This GCE PD must already exist.
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4

実際に必要なのは、次のようにPersistent Volumeを作成することです:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-volume
spec:
  capacity:
    storage: 400Gi
  accessModes:
  - ReadWriteOnce
  gcePersistentDisk:
    pdName: my-data-disk
    fsType: ext4

通常、PersistentVolume情報を含むローカルyamlファイルを作成し、次にKubernetesにcreateコマンドを発行して、ファイルを使用してオブジェクトを作成します。

kubectl --namespace <your namespace> create -f <local-pv-file>.yaml

ボリュームが作成されたら、PersistentVolumeClaimの変更に進むことができます

PersistentVolumeClaimを変更する

変更するPersistentVolumeClaimを見つけます。

kubectl --namespace <namespace> get PersistentVolumeClaims -l release=<chart release name> -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.app}{"\n"}{end}'

<namespace>は、GitLabチャートをインストールしたネームスペースに置き換える必要があります。
<chart release name>は、GitLabチャートのインストールに使用した名前に置き換える必要があります。

コマンドは、PersistentVolumeClaim名のリストと、そのボリュームが対象とするサービスの名前を出力します。

次に、claimのコピーをローカルファイルシステムに保存します:

kubectl --namespace <namespace> get PersistentVolumeClaim <claim name> -o yaml > <claim name>.bak.yaml

出力例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd
  creationTimestamp: 2018-07-20T14:58:38Z
  labels:
    app: gitaly
    release: review-update-app-h8qogp
  name: repo-data-review-update-app-h8qogp-gitaly-0
  namespace: helm-charts-win
  resourceVersion: "48362433"
  selfLink: /api/v1/namespaces/helm-charts-win/persistentvolumeclaims/repo-data-review-update-app-h8qogp-gitaly-0
  uid: 6247502b-8c2d-11e8-8267-42010a9a0113
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: standard
  volumeName: pvc-6247502b-8c2d-11e8-8267-42010a9a0113
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 50Gi
  phase: Bound

新しいPVCオブジェクトの新しいYAMLファイルを作成します。同じmetadata.name、metadata.labels、metadata.namespace、およびspecフィールド（更新を適用）を使用し、他の設定をドロップします:

例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: gitaly
    release: review-update-app-h8qogp
  name: repo-data-review-update-app-h8qogp-gitaly-0
  namespace: helm-charts-win
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      # This is our updated field
      storage: 100Gi
  storageClassName: standard
  volumeName: pvc-6247502b-8c2d-11e8-8267-42010a9a0113

次に、古いclaimを削除します:

kubectl --namespace <namespace> delete PersistentVolumeClaim <claim name>

削除を完了するには、finalizersをクリアする必要がある場合があります:

kubectl --namespace <namespace> patch PersistentVolumeClaim <claim name> -p '{"metadata":{"finalizers":null}}'

新しいクレームを作成します:

kubectl --namespace <namespace> create -f <new claim yaml file>

以前にクレームにバインドされていた同じPersistentVolumeにバインドしている場合は、クレームにバインドするようにボリュームを更新するに進みます

それ以外の場合は、クレームを新しいボリュームにバインドした場合は、GitLabチャートに変更を適用するに進みます

GitLabチャートに変更を適用する

PersistentVolumesとPersistentVolumeClaimsに変更を加えた後、変更がチャートの設定にも適用された状態でHelmアップデートも発行する必要があります。

オプションについては、インストールのストレージガイドを参照してください。

Gitaly ボリュームクレームに変更を加えた場合は、Helmアップデートを発行できるようにする前に、Gitaly StatefulSetを削除する必要があります。これは、StatefulSetのVolume Templateがイミュータブルであり、変更できないためです。

Gitalyポッドを削除せずにStatefulSetを削除できます:

kubectl --namespace <namespace> delete --cascade=orphan StatefulSet <release-name>-gitaly

HelmアップデートコマンドはStatefulSetを再作成し、Gitalyポッドを採用して更新します。

チャートを更新し、更新された設定を含めます:

例:

helm upgrade --install review-update-app-h8qogp gitlab/gitlab \
  --set gitlab.gitaly.persistence.size=100Gi \
  <your other config settings>