スタンドアロンの MongoDB インスタンスの配置

MongoDB Enterprise Kubernetes演算子は非推奨です。新しい MongoDB Controls for Kubernetes Operator が、 MongoDB Enterprise Kubernetes Operator に置き換わります。 Kubernetes Operator 用のドライバーの最初のバージョンは、1.33 Enterprise Kubernetes Operatorの v と機能的に同等です。この変更の詳細と、新しい演算子への移行に関するガイダンスについては、最初の新しいバージョンのリリースノートを参照してください。 MongoDB Enterprise Kubernetes Operator の今後のリリースは予定されません。各バージョンは、既存の 1 年間のサポートポリシーに従ってサポートが終了します。継続的なサポートについては、 Kubernetes Operator 用のコントロールに移行してください。

注意

このページのMongoDB Ops Managerが表示されている場所では、 Cloud Managerを置き換えることができます。

重要

Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよびバージョン6.0 .x 以降でリソースを配置できます。
Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。

用にスタンドアロンのMongoDB MongoDB Ops Managerインスタンスを配置して管理できます。テストと開発にはスタンドアロンインスタンスを使用します。これらの配置は、レプリケーションが機能せず、可用性が低いため、実稼働システムでは使用しないでください。すべての配置ではレプリカセットを使用します。レプリカセットの詳細については、「レプリカセットを配置する」を参照してください。

前提条件

オブジェクトを使用してスタンドアロンを配置するにはに設定されている場合は、以下を行う必要があります。

注意

単一クラスターの Kubernetes 配置でシークレットが保存されないようにするには、すべてのシークレットを移行しますシークレットストレージツールに渡す追加オプション。複数の Kubernetes クラスターでの配置では、 HashiCorp Vault などのシークレットストレージツールへのシークレットの保存はサポートされていません。。

手順

`kubectl`を名前空間にデフォルトします。

まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべてのkubectlコマンドを実行します。

注意

MongoDB Ops Manager リソースを複数の Kubernetes クラスター MongoDB 配置に配置している場合、次の手順に従います。

contextを中央クラスターの名前に設定します（例: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME" 。
MongoDB のマルチ配置に使用したのと同じスコープ（例: kubectl config --namespace "mongodb"に--namespaceを設定します。

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

次の例のスタンドアロン Kubernetes オブジェクトをコピーします。

これは、必要な構成に合わせて変更できる YAMLファイルです。強調表示された設定を、必要なスタンドアロン構成に合わせて変更します。

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
spec:
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true
...

お好みのテキストエディタを開いて、オブジェクト仕様を新しいテキストファイルに貼り付けます。

前の手順で強調表示されている設定を次のように構成します。

キー	タイプ	説明	例
`metadata.name`	string	この Kubernetes スタンドアロンオブジェクトのラベル。リソース名は 44 文字以下にする必要があります。詳しくは、`metadata.name` 名前に関すると Kubernetes のドキュメントを参照してください。	`my-project`
`spec.version`	string	このスタンドアロンにインストールされている MongoDB のバージョン。形式は、 MongoDB Community Editionでは `X.Y.Z`、Enterprise エディションでは `X.Y.Z-ent` です。重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。 MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理」を参照してください。	最良の結果を得るには、利用可能な最新のエンタープライズ MongoDB バージョンを使用してください MongoDB Ops Manager のバージョンと互換性のある。
`spec.opsManager` `.configMapRef.name`	string	ConfigMap MongoDB Ops Managerの名前接続構成の場合`spec.cloudManager.configMapRef.name`設定はこの設定のエイリアスであり、代わりに使用できます。この値は、作成するリソースと同じ名前空間に存在する必要があります。	`<myproject>`
`spec.credentials`	string	Operator がと通信するための MongoDB Ops ManagerAPI認証情報として作成KubernetesMongoDB Ops Manager したシークレットの名前。認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。重要: Kubernetes Operator は、シークレットへの変更を追跡し、`MongoDB` リソースの状態を調整します。	`<mycredentials>`
`spec.type`	string	作成する`MongoDB`リソースのタイプ。	`Standalone`
`spec.persistent`	string	任意。この値が`true`の場合、 `spec.podSpec.persistence.single`はデフォルト値の`16Gi`に設定されます。永続的なボリュームクレームを変更するには構成では、配置の要件を満たすように次のコレクションを構成します。 1 つの永続ボリュームが必要な場合各ポッド `spec.podSpec.persistence.single`は、コレクションを構成します。個別の永続ボリュームが必要な場合各ポッドのデータ、ジャーナル、およびログ用では、次のコレクションを構成します。 `spec.podSpec.persistence.multiple.data` `spec.podSpec.persistence.multiple.journal` `spec.podSpec.persistence.multiple.logs` 警告: コンテナに永続ボリュームへの書込み (write) 権限を付与。Kubernetes 演算子は、 `securityContext`で`fsGroup = 2000` 、 `runAsUser = 2000` 、 `runAsNonRoot = true`を設定します。 Kubernetes Operator は、 `fsgroup`を`runAsUser`と等しく設定して、コンテナでメインプロセスを実行するユーザーがボリュームを書込み可能にします。詳細については、「ポッドまたはコンテナのセキュリティコンテキストの構成」を参照してくださいおよび関連するディスカッション（Kubernetes ドキュメント）。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDB サポートにお問い合わせください。永続的なボリュームを使用しない場合 Disk UsageDisk IOPSProcesses、Deployment 、Metrics チャートは、この配置のデータを確認するときに、ページのタブまたはページのいずれにも表示できません。	`true`

スタンドアロン配置に許容されている設定を追加します。

また、次の任意設定のいずれかをオブジェクトに追加できます。スタンドアロン配置用の仕様ファイル

このファイルを `.yaml` という拡張子で保存します。

スタンドアロン配置を開始します。

次の Kubernetes コマンドを呼び出して、スタンドアロンを作成します。

kubectl apply -f <standalone-conf>.yaml

スタンドアロン配置のステータスを追跡します。

MongoDBリソースのステータスを確認するには、次のコマンドを使用します。

kubectl get mdb <resource-name> -o yaml -w

-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。リソース配置ステータスの詳細については、「 Kubernetes 演算子のトラブルシューティング」を参照してください。

シャーディングされたクラスターのトラブルシューティングを行うには、以下を参照してください。

戻る

配置

レプリカセット

注意

重要