Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子

よくある質問

項目一覧

  • 演算子とは
  • Kubernetes で MongoDB Enterprise Advanced を実行する理由
  • Kubernetes での MongoDB のスケーラビリティ
  • Kubernetes 内で MongoDB を実行する際のダウングレードはありますか。
  • MongoDB Server 配置ではどの Kubernetes プラットフォームがサポートされていますか。
  • MongoDB Enterprise Kubernetes Operator は、配置の数をサポートできますか?
  • MongoDB Server は、それを使用しているアプリケーションと同じクラスターで Kubernetes で実行する必要がありますか。
  • MongoDB Server を複数の Kubernetes クラスターに配置できますか。
  • Kubernetes Operator を使用して複数の Kubernetes クラスター MongoDB 配置を管理する方法と、単一の Kubernetes クラスターを管理する方法の違いは何ですか。
  • MongoDB は複数の Kubernetes Operator インスタンスの実行をサポートしていますか。

演算子は、Kubernetes のコントロール プレーンをカスタム Kubernetes リソースの管理に拡張する標準メカニズムです。 各演算子は独自のカスタム リソース(CR)用に構築されているため、演算子が構築されるサービスの種類に対処するロジックを含めることができます。 Kubernetes Operator の場合、 演算子にはMongoDB ServerおよびMongoDB Ops Managerインスタンスの配置用ロジックが含まれています。

Kubernetes Operator によって使用される各 CR は、Kubernetes の MongoDB Server 配置の要素を表し、配置のその部分をカスタマイズするオプションがあります。 Kubernetes 配置でこれらのオブジェクトを構成すると、 演算子は MongoDB Server に指定された要件に従ってポッドを作成するために必要なステートメント セットなど、ネイティブ Kubernetes オブジェクトを構築します。 KubernetesOperatorMongoDB Server は、MongoDB Cloud Manager または との相互作用により、データベースバックアップなどのMongoDB Ops Manager 機能の構成も容易にします。

Kubernetes で MongoDB を実行すると、セルフホスト型 MongoDB の設定と管理が簡素化されます。

Kubernetes Operator はMongoDBおよび MongoDB Ops Managerと連携し、セットアップを定義するために作成するカスタム リソース ファイルを使用して構成を自動化します。 これにより、Git リポジトリで構成が管理される GitOps ワークフローを有効にするツールなど、Kubernetes のアプリケーションを管理するためにすでに使用しているツールを使用して構成を管理できます。 高度なオートメーションと複雑さからの抽象化により、Kubernetes と Kubernetes Operator は、内部ユーザーまたは外部カスタマーに対して MongoDB をサービスとして実行するのに特に適しています。

Kubernetes を使用すると、MongoDB は Kubernetes が提供するスケーラビリティと自動回復力を活用できます。たとえば、レプリカセットやシャーディングされたクラスターが作成される、失われたポッドの自動置換などです。 これにより、Kubernetes で実行する際に MongoDB は高いスケーラビリティと回復力を持つことができます。

Kubernetes 内の MongoDB は、必要に応じてプライマリまたは VM 上の MongoDB と同等にスケーリングできます。 多くのカスタマーにとって、Kubernetes 内でのスケーラビリティの実現が簡単です。 Kubernetes Operator と Kubernetes がシームレスに連携することで、簡単な水平スケーリングが可能になります。たとえば、MongoDB の配置を複数の Kubernetes クラスターにまたがって使用し、マルチクラスターとマルチサイトの回復力を実現します。

垂直スケーリングは、配置を定義するカスタム リソース内の配置のリソースを変更するのと簡単に対応できます。

これらにより、MongoDB はあらゆる需要に合わせてスケーリングすることができます。

技術的な観点から見ると、ダウンサイドはありません。 Kubernetes 内の MongoDB は、任意のハードウェアまたはインフラストラクチャ上で実行される MongoDB と同等のパフォーマンスとスケーラビリティがあります。

ただし、他のインフラストラクチャと同様に、この場合は Kubernetes の場合、カスタマーがテクノロジーに関する知識と専門知識を持っていることが本質的に必要です。 Kubernetes Operator は Kubernetes 内での MongoDB のセットアップを簡素化および自動化しますが、ステートフル ストレージ、ネットワーク、セキュリティ、コンピュートなど、Kubernetes クラスターの構成要素である基礎のリソースと機能には依然として依存関係があります。 つまり、カスタマーは、これらのサービスとリソースが利用可能で、MongoDB をサポートするために正しく構成されていることを確認する必要があります。これは、必要最低限のマシンまたは仮想マシンで実行する場合と同様です。

MongoDB Server は、デフォルトのロジックや動作を変更することなく、ネイティブ Kubernetes 上に構築される任意のプラットフォームをサポートします。 実際には、MongoDB Server は Cloud Native compute Community によって認証された すべての Kubernetes プラットフォームをサポートしています。 。詳細については、「 MongoDB Kubernetes 演算子の互換性 」を参照してください。

Kubernetes Operator は数百の配置をサポートできます。 並列調整操作を容易に行い、長時間調整時間を回避するには、Kubernetes Operator インスタンスのスレッド数を増やします。

レイテンシを最小限に抑えるために、配置アーキテクチャで許可されている場合は、同じ Kubernetes クラスターにデータベースとアプリケーションをコロケーションすることを検討してください。

はい。 詳細については、「複数の Kubernetes クラスターに MongoDB リソースを配置する」を参照してください。 サポートが必要な場合は、 MongoDB サポートにお問い合わせください。

Kubernetes Operator を使用して複数の Kubernetes クラスター MongoDB 配置を管理するには、Kubernetes ロール、 ClusterRoles の特定のセットを設定する必要があります 、 RoleBindings、ClusterRoleBindings 、 、および ServiceAccounts 。

MongoDB の複数の Kubernetes クラスター配置に使用される Kubernetes 演算子 は、単一の Kubernetes クラスター リソースを調整することもできます。 詳細については、 「 MongoDB は複数の Kubernetes Operator インスタンスの実行をサポートしていますか 」を参照してください。

可能であれば、単一の Kubernetes Operator インスタンスを設定して、Kubernetes クラスター内の 1 つまたは複数、またはすべての名前空間を監視することをお勧めします。 デフォルトでは、Kubernetes Operator はすべての カスタム リソース を監視します 配置します。特定のリソース タイプを監視するために構成する必要はありません。

ただし、1 つの Kubernetes Operator インスタンスがサポートできる配置数のパフォーマンス制限に達した場合は、追加の Kubernetes Operator インスタンスを設定できます。 この時点で、Kubernetes クラスター内のリソースの管理をどのように分割するかについて考えてみましょう。 優先順位の順にリストされている次の推奨事項を使用してください。

  • 各 Kubernetes Operator インスタンスが、Kubernetes クラスター内の異なる名前空間と重複しない名前空間を監視していることを確認します。

  • あるいは、Kubernetes Operator の異なるインスタンスを構成して、異なる名前空間または重複する名前空間のいずれかの異なるリソースタイプを監視します。

    重複する名前空間を使用する場合は、各 Kubernetes Operator インスタンスが異なるタイプのリソースを監視していることを確認して、Kubernetes Operator の 2 つのインスタンスが同じリソースを管理しようとする競合を回避してください。

注意

別の Kubernetes Operator インスタンスを構成する前に、その名前空間のいずれもが既存の Kubernetes Operator インスタンスの名前空間のサブセットに含まれていないことを確認してください。

戻る

サードパーティライセンス