標準の Operator 配置を構成する MongoDB Ops Manager、MongoDB Database、AppDB およびバックアップデーモンのカスタム リソースは、それぞれKubernetesKubernetesstatefulSets として配置されます。Kubernetes Operator は、基礎となるKubernetes storageClassがKubernetes persistentVolumeの拡張をサポートしている場合に、それぞれのKubernetes persistentVolumeClaimsのキャパシティーを増やすことで、これらの特定のリソースに関連付けられたストレージの増加をサポートしています。
特定のリソースの種類に応じて、2 つの方法のいずれかでストレージを増やすことができます。 ストレージを手動で増やす か、 Kubernetes Operator の簡単なストレージ拡張機能を活用してください。 次の表は、これら 2 つの手順のうちどの手順が特定のカスタムリソースタイプでサポートされているかを示しています。
カスタム リソース タイプ | 手動ストレージ拡張 | 簡単なストレージ拡張 |
|---|---|---|
AppDB | ||
バックアップデーモン | ||
MongoDB データベース | ||
MongoDBマルチクラスター | ||
Ops Manager |
MongoDB Searchのインデックスストレージは、これらの手順の対象外です。増やす方法を学ぶには、「MongoDB Searchインデックスストレージの拡張」を参照してください。
前提条件
ストレージ クラスはサイズ変更をサポートする必要があります
永続ボリュームが使用する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カスタムリソースがローリング再起動されます。
永続的なカスタムリソースを作成または識別します。
既存のデータベースリソースを使用するか、 永続的ストレージを使用して新しいデータベース リソースを作成します。 永続的なボリュームがRunning状態になるまで待ちます。
例
永続的ストレージを持つデータベース リソースには、次が含まれます。
apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: <my-replica-set>spec: members: 3 version: "8.0.0" project: my-project credentials: my-credentials type: ReplicaSet podSpec: persistence: single: storage: "1Gi"リソースが提供するデータベースにデータを挿入します。
Kubernetes クラスターで
mongoを起動します。$kubectl exec -it <my-replica-set>-0 \ /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-8.0.0/bin/mongotestデータベースにデータを挿入します。<my-replica-set>:PRIMARY> use test switched to db test <my-replica-set>:PRIMARY> db.tmp.insertOne({"foo":"bar"}) { "acknowledged" : true, "insertedId" : ObjectId("61128cb4a783c3c57ae5142d")}
新しいストレージ値でデータベース リソースを更新します。
重要
既存のストレージリソースのディスク サイズは増やすことのみができ、減らすことはできません。 ストレージサイズを減らすと、調整ステージでエラーが発生します。
ディスク サイズを更新します。 希望のテキスト エディターを開き、次の例のような変更を加えます。
例
レプリカセットのディスク サイズを2 GBに更新するには、データベースリソース仕様の
storageの値を変更します。apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: <my-replica-set>spec: members: 3 version: "8.0.0" project: my-project credentials: my-credentials type: ReplicaSet podSpec: persistence: single: storage: "2Gi"MongoDBカスタムリソースを新しいボリューム サイズで更新します。
kubectl apply -f my-updated-replica-set-vol.yamlこの 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-8.0.0/bin/mongo<my-replica-set>:PRIMARY> use testswitched to db test
<my-replica-set>:PRIMARY> db.tmp.count()1ストレージの手動拡張
永続的なカスタムリソースを作成または識別します。
既存のデータベース リソースを使用するか、永続ストレージを持つ新しいデータベース リソースを作成します。 永続的なボリュームがRunningの状態になるまで待ちます。
例
永続的ストレージを持つデータベース リソースには、次が含まれます。
apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: <my-replica-set>spec: members: 3 version: "8.0.0" project: my-project credentials: my-credentials type: ReplicaSet podSpec: persistence: single: storage: "1Gi"リソースが提供するデータベースにデータを挿入します。
Kubernetes クラスターで
mongoを起動します。$kubectl exec -it <my-replica-set>-0 \ /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-8.0.0/bin/mongotestデータベースにデータを挿入します。<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 が手動更新されたリソースの状態をリソースの元の定義と一致するように復元しようとする競合状態を回避できます。
apiVersion: apps/v1kind: Deploymentmetadata: name: mongodb-kubernetes-operator namespace: mongodbspec: replicas: 0StateftSets を削除します。
注意
この手順では、StatulSet のみが削除されます。ポッドは変更されず、を実行中になります。
StateftSetリソースを削除します。
kubectl delete sts --cascade=false <my-replica-set>新しいストレージ値でデータベース リソースを更新します。
ディスク サイズを更新します。 希望のテキスト エディターを開き、次の例のような変更を加えます。
例
レプリカセットのディスク サイズを2 GBに更新するには、データベースリソース仕様の
storageの値を変更します。apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: <my-replica-set>spec: members: 3 version: "8.0.0" project: my-project credentials: my-credentials type: ReplicaSet podSpec: persistence: single: storage: "2Gi"新しいボリューム サイズでステートフルセットリソースを再作成します。
kubectl apply -f my-replica-set-vol.yamlMongoDBカスタムリソースが
Running状態になるまで待ちます。
更新された 永続ボリューム要求 にデータが存在することを検証します。
永続ボリュームが再利用された場合、ステップ で挿入したデータは、2 永続ボリュームが に保存されているデータベースに表示されます。
$ kubectl exec -it <my-replica-set>-1 \ /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-8.0.0/bin/mongo<my-replica-set>:PRIMARY> use testswitched to db test
<my-replica-set>:PRIMARY> db.tmp.count()1