MongoDB Search インデックスのストレージを拡張する

mongot StatefulSet とデータ要求を特定します。

MongoDBSearch リソースの mongot statefulSets を一覧表示します。

kubectl --context <member-context> -n <namespace> \
  get sts -l mongodb.com/search-name=<search-name>

デフォルトの data クレームテンプレートでは、各レプリカは data-<statefulset-name>-<ordinal> という名前のクレームを使用します。シャーディングされたクラスターソースの場合、各クラスターには各シャードに対して 1 つの StatefulSet があります。クレームテンプレートまたはボリュームマウントをカスタマイズした場合は、代わりに各 Pod がマウントするクレームを確認してください。

各データクレームを詳しく説明してください。

前のステップで特定した各クレームについて、次のコマンドを実行します。

kubectl --context <member-context> -n <namespace> \
  patch pvc <pvc-name> --type=merge \
  -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'

各クレームがstatus.capacity.storageまたはFileSystemResizePending条件で少なくとも要求されたサイズ（この例では2Gi）を報告するまで待機します。

kubectl --context <member-context> -n <namespace> \
  get pvc <pvc-name> -o yaml

展開にストレージバックエンドのドキュメントに記載されているタイムアウトよりも時間がかかる場合は、続行する前にCSIイベントを調査してください。

kubectl --context <member-context> -n <namespace> \
  describe pvc <pvc-name>

担当するKubernetes 演算子の配置を停止します。

各演算子の元のレプリカ数を記録します。

kubectl --context <operator-context> -n <operator-namespace> \
  get deployment <operator-name> \
  -o jsonpath='{.spec.replicas}{"\n"}'

演算子をゼロに増やすし、その Pods が削除されるのを待ちます。

kubectl --context <operator-context> -n <operator-namespace> \
  scale deployment <operator-name> --replicas=0
kubectl --context <operator-context> -n <operator-namespace> \
  wait --for=delete pod --timeout=300s \
  -l app.kubernetes.io/name=<operator-name>

mongotではなく、演算子を増やす。Helm チャートは、演算子の配置に mongodb-kubernetes-operator という名前を付け、その Pods に app.kubernetes.io/name: mongodb-kubernetes-operator を設定します。インストールがカスタマイズされている場合は、この例に示すチャートラベルの代わりに、配置の実際のポッドセレクターを使用してください。続行する前に、終了中の Pods を含め、すべての責任ある演算子 Pods を停止します。個別のソースデータベース演算子を停止しても、ノード検索演算子は一時停止されません。

StatefulSet定義のみを除く。

ステップ 1 で特定した各 StatefulSet に対して、次のコマンドを実行します。

kubectl --context <member-context> -n <namespace> \
  delete sts <statefulset-name> --cascade=orphan \
  --timeout=300s

各StatefulSetが存在しないことを確認します。その一方で、既存のmongot PodsとPersistent Volume Claimsは、削除タイムスタンプなしでそのまま残ります。MongoDBSearchリソースを削除したり、mongotを縮小したりしないでください。

既存のSearchリソースを更新します。

kubectl --context <search-resource-context> -n <namespace> \
  edit mongodbsearch <search-name>

影響を受けるクラスターエントリの persistence.single.storage 値を変更します。

persistence:
  single:
    storage: 2Gi

Kubernetes演算子をノードクラスターごとに配置する構成では、対応する設定をすべてのローカルSearchリソースで更新してください。

既存のストレージクラス、クラスターエントリ、インデックス、レプリカ、およびその他の設定は保持されます。クラスターエントリを削除すると、そのクラスターのSearchリソースと要求が削除される可能性があります。

Searchリソースを読み戻し、新しい有効サイズが保持されていることを確認します。ターゲットの statefulSets は、演算子を再開するまで存在しない状態である必要があります。

演算子を再開します。

各演算子自身の記録されたレプリカ数を復元します。

kubectl --context <operator-context> -n <operator-namespace> \
  scale deployment <operator-name> \
  --replicas=<original-replicas>
kubectl --context <operator-context> -n <operator-namespace> \
  rollout status deployment/<operator-name> --timeout=600s

各 StatefulSet が拡張された data クレームテンプレートで再表示されるのを待ちます。新しい StatefulSet は、既存の Pods とクレームを採用します。

ファイルシステムで必要な場合は、mongot ポッドを再起動します。

FileSystemResizePendingの状態が続く場合は、影響を受けるmongot Podsを1つずつ削除してください：

kubectl --context <member-context> -n <namespace> \
  delete pod <mongot-pod-name> --timeout=300s
kubectl --context <member-context> -n <namespace> \
  wait --for=condition=Ready pod/<mongot-pod-name> \
  --timeout=600s

準備完了コマンドを実行する前に、置換 Pod が存在することを確認してください。置換が準備完了し、条件がクリアされた後にのみ、次の Pod を再起動します。展開がオンラインで完了した場合は、この手順をスキップします。

ストレージとSearchの準備状況を確認します。

各 Persistent Volume Claim が少なくとも要求されたキャパシティーを報告していること、期待されるすべての mongot Pods が準備完了状態であること、および各 Search リソースが調整後に Running フェーズに達していることを確認します。