永続的なボリュームのストレージを増やす

永続的な カスタムリソース を作成または識別する 。

既存のデータベースリソースを使用するか、 永続的ストレージを使用して新しいデータベース リソースを作成します。 永続的なボリュームがRunning状態になるまで待ちます。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: <my-replica-set>
5
spec:
6
  members: 3
7
  version: "4.4.0"
8
  project: my-project
9
  credentials: my-credentials
10
  type: ReplicaSet
11
  podSpec:
12
    persistence:
13
      single:
14
        storage: "1Gi"

リソースが提供するデータベースにデータを挿入します。

1. Kubernetes クラスターでmongoを起動します。

   $kubectl exec -it <my-replica-set>-0 \
            /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.0/bin/mongo

2. testデータベースにデータを挿入します。

   <my-replica-set>:PRIMARY> use test
   switched to db test
   <my-replica-set>:PRIMARY> db.tmp.insertOne({"foo":"bar"})
   {
     "acknowledged" : true,
     "insertedId" : ObjectId("61128cb4a783c3c57ae5142d")
   }

新しいストレージ値でデータベース リソースを更新します。

1. ディスク サイズを更新します。 希望のテキスト エディターを開き、次の例のような変更を加えます。

   例

   レプリカセットのディスク サイズを2 GBに更新するには、データベースリソース仕様のstorageの値を変更します。

   1
   apiVersion: mongodb.com/v1
   2
   kind: MongoDB
   3
   metadata:
   4
     name: <my-replica-set>
   5
   spec:
   6
     members: 3
   7
     version: "4.4.0"
   8
     project: my-project
   9
     credentials: my-credentials
   10
     type: ReplicaSet
   11
     podSpec:
   12
       persistence:
   13
         single:
   14
           storage: "2Gi"

2. MongoDBカスタムリソースを新しいボリューム サイズで更新します。

   kubectl apply -f my-updated-replica-set-vol.yaml

3. この StateftSet がRunning状態になるまで待ちます。

永続ボリューム クレームのサイズが変更されていることを検証します。

永続的なボリューム を再利用する場合 、 永続的なボリューム に保存されているデータベースで ステップ2 で挿入したデータを見つけることができます:

$ kubectl describe mongodb/<my-replica-set> -n mongodb

次の出力は、IPv サイズリクエストが処理されたことを示しています。

status:
  clusterStatusList: {}
  lastTransition: "2024-08-21T11:03:52+02:00"
  message: StatefulSet not ready
  observedGeneration: 2
  phase: Pending
  pvc:
    - phase: PVC Resize - STS has been orphaned
      statefulsetName: multi-replica-set-pvc-resize-0
  resourcesNotReady:
    - kind: StatefulSet
      message: 'Not all the Pods are ready (wanted: 2, updated: 1, ready: 1, current:2)'
      name: multi-replica-set-pvc-resize-0
  version: ""

更新された 永続ボリューム要求 にデータが存在することを検証します。

永続的なボリューム を再利用する場合 、 永続的なボリューム に保存されているデータベースで ステップ2 で挿入したデータを見つけることができます:

$ kubectl exec -it <my-replica-set>-1 \
          /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.0/bin/mongo

<my-replica-set>:PRIMARY> use test
switched to db test
<my-replica-set>:PRIMARY> db.tmp.count()
1

永続的な カスタムリソース を作成または識別する 。

既存のデータベース リソースを使用するか、永続ストレージを持つ新しいデータベース リソースを作成します。 永続的なボリュームがRunningの状態になるまで待ちます。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: <my-replica-set>
5
spec:
6
  members: 3
7
  version: "4.4.0"
8
  project: my-project
9
  credentials: my-credentials
10
  type: ReplicaSet
11
  podSpec:
12
    persistence:
13
      single:
14
        storage: "1Gi"

リソースが提供するデータベースにデータを挿入します。

1. Kubernetes クラスターでmongoを起動します。

   $kubectl exec -it <my-replica-set>-0 \
            /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.0/bin/mongo

2. testデータベースにデータを挿入します。

   <my-replica-set>:PRIMARY> use test
   switched to db test
   <my-replica-set>:PRIMARY> db.tmp.insertOne({"foo":"bar"})
   {
     "acknowledged" : true,
     "insertedId" : ObjectId("61128cb4a783c3c57ae5142d")
   }

各永続性ボリュームをパッチします。

レプリカセット全体に対して次のコマンドを呼び出します。

kubectl patch pvc/"data-<my-replica-set>-0" -p='{"spec": {"resources": {"requests": {"storage": "2Gi"}}}}'
kubectl patch pvc/"data-<my-replica-set>-1" -p='{"spec": {"resources": {"requests": {"storage": "2Gi"}}}}'
kubectl patch pvc/"data-<my-replica-set>-2" -p='{"spec": {"resources": {"requests": {"storage": "2Gi"}}}}'

各 永続ボリューム要求 まで待機 は、次の条件になります。

- lastProbeTime: null
  lastTransitionTime: "2019-08-01T12:11:39Z"
  message: Waiting for user to (re-)start a pod to finish file
           system resize of volume on node.
  status: "True"
  type: FileSystemResizePending

演算子を停止します。

Kubernetes Operator の配置定義を更新し、 Kubernetesクラスターに変更を適用して、 Kubernetes Operator を0レプリカに増やすダウンします。 Kubernetes Operator を0レプリカにスケールダウンすると、 Kubernetes Operator が手動更新されたリソースの状態をリソースの元の定義と一致するように復元しようとする競合状態を回避できます。

# Source: enterprise-operator/templates/operator.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-enterprise-operator
  namespace: mongodb
spec:
  replicas: 0

StateftSets を削除します。

Atlas App Services の削除 リソース。

kubectl delete sts --cascade=false <my-replica-set>

新しいストレージ値でデータベース リソースを更新します。

1. ディスク サイズを更新します。 希望のテキスト エディターを開き、次の例のような変更を加えます。

   例

   レプリカセットのディスク サイズを2 GBに更新するには、データベースリソース仕様のstorageの値を変更します。

   1
   apiVersion: mongodb.com/v1
   2
   kind: MongoDB
   3
   metadata:
   4
     name: <my-replica-set>
   5
   spec:
   6
     members: 3
   7
     version: "4.4.0"
   8
     project: my-project
   9
     credentials: my-credentials
   10
     type: ReplicaSet
   11
     podSpec:
   12
       persistence:
   13
         single:
   14
           storage: "2Gi"

2. StateftSet の再作成 リソース（新しいボリューム サイズ）に設定します。

   kubectl apply -f my-replica-set-vol.yaml

3. MongoDBカスタムリソースがRunning状態になるまで待ちます。

ポッドを順次更新します。

次のコマンドを呼び出します。

kubectl rollout restart sts <my-replica-set>

新しいポッドはサイズ変更されたボリュームをマウントします。

更新された 永続ボリューム要求 にデータが存在することを検証します。

永続的なボリューム が は再利用された場合、 ステップ2 で挿入したデータは 永続的なボリューム に保存されているデータベースにある可能性があります :

$ kubectl exec -it <my-replica-set>-1 \
          /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.0/bin/mongo

<my-replica-set>:PRIMARY> use test
switched to db test
<my-replica-set>:PRIMARY> db.tmp.count()
1