Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/
MongoDB Database リソースの配置
/
データベース リソースの編集

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

項目一覧

  • 前提条件
  • ストレージを簡単に拡張する
  • ストレージの手動拡張

標準のKubernetes Operator 配置を構成する Ops Manager 、 MongoDB Database、AppDB およびバックアップデーモンのカスタム リソースはそれぞれKubernetes statefulSetsとして配置されます。 Kubernetes Operator は、基礎となるKubernetes storageClassがKubernetes persistentVolumeの拡張をサポートしている場合に、それぞれのKubernetes persistentVolumeClaimsのキャパシティーを増やすことで、これらの特定のリソースに関連付けられたストレージを増やすことをサポートしています。

特定のリソースの種類に応じて、2 つの方法のいずれかでストレージを増やすことができます。ストレージを手動で増やす か、 Kubernetes Operator の簡単なストレージ拡張機能を活用してください。次の表は、これら 2 つの手順のうちどの手順が特定のカスタムリソースタイプでサポートされているかを示しています。

カスタム リソース タイプ
手動ストレージ拡張
簡単なストレージ拡張
AppDB
X
バックアップデーモン
X
MongoDB データベース
X
X
MongoDBマルチクラスター
X
X
Ops Manager
X

前提条件

ストレージ クラスはサイズ変更をサポートする必要があります

StorageClass が および ボリューム プラグイン プロバイダー は、次のサイズをサポートします。

kubectl patch storageclass/<my-storageclass> --type='json' \
        -p='[{"op": "add", "path": "/allowVolumeExpansion", "value": true }]'

サイズ変更をサポートするstorageClassがない場合は、 Kubernetes管理者に問い合わせてください。

ストレージを簡単に拡張する

注意

簡単に展開できるメカニズムには、 Kubernetes Operator に含まれるデフォルトの RBAC が必要です。具体的には、get の 、list 、watch 、patch 、update persistantVolumeClaims権限が必要です。 Kubernetes Operator RBAC リソースをカスタマイズした場合は、 Kubernetes Operator がKubernetesクラスター内のストレージリソースのサイズを変更できるようにするために権限を調整する必要がある場合があります。

このプロセスにより、 Kubernetesクラスター内のMongoDBカスタムリソースがローリング再起動されます。

1

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

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

例

永続的ストレージを持つデータベース リソースには、次が含まれます。

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4  name: <my-replica-set>
5spec:
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"
2

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

  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")
    }
3

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

重要

既存のストレージリソースのディスク サイズは増やすことのみができ、減らすことはできません。ストレージサイズを減らすと、調整ステージでエラーが発生します。

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

    例

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

    1apiVersion: mongodb.com/v1
    2kind: MongoDB
    3metadata:
    4  name: <my-replica-set>
    5spec:
    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状態になるまで待ちます。

4

永続的なボリューム要求 を検証する サイズが変更されました。

永続的なボリューム を再利用する場合 、 永続的なボリューム に保存されているデータベースで ステップ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: ""
5

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

永続的なボリューム を再利用する場合 、 永続的なボリューム に保存されているデータベースで ステップ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

ストレージの手動拡張

1

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

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

例

永続的ストレージを持つデータベース リソースには、次が含まれます。

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4  name: <my-replica-set>
5spec:
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"
2

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

  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")
    }
3

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

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

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
4

演算子を停止します。

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
5

StateftSets を削除します。

注意

この手順では、 State fullSet が削除されます のみ。ポッドは変更されずに実行されます。

Atlas App Services の削除 リソース。

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

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

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

    例

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

    1apiVersion: mongodb.com/v1
    2kind: MongoDB
    3metadata:
    4  name: <my-replica-set>
    5spec:
    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状態になるまで待ちます。

7

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

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

kubectl rollout restart sts <my-replica-set>

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

8

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

永続的なボリューム が は再利用された場合、 ステップ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

戻る

配置の拡張