Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/ /

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

項目一覧

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

標準の Operator 配置を構成する MongoDB Ops Manager、MongoDB Database、AppDB およびバックアップデーモンのカスタム リソースはそれぞれ {4KubernetesKubernetesstatefulSets として配置されます。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 が必要です。 具体的には、 のgetlistwatchpatchupdate 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

注意

この手順では、 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

戻る

大規模な配置