MongoDB Ops Managerアプリケーションを複数のKubernetesクラスターに配置する場合は、次の追加要件を考慮してください。
ネットワーキングの概要
次の表では、次の内容について説明しています。
MongoDB Ops Manager アプリケーション インスタンスへの接続の原因
MongoDB Ops Managerアプリケーションが接続後に実行するタスク
各接続タイプが使用する MongoDB Ops Manager への URL とその構成方法。
接続の元 | 目的またはアクション | MongoDB Ops Manager への URL |
|---|---|---|
Kubernetes 演算子 | MongoDB Ops Managerインスタンスを構成し、アプリケーション データベースが実行状態になった後のモニタリングを有効にします。 | デフォルトの MongoDB Ops Manager FQDN の形式で: |
Kubernetes 演算子 | 特定の | プロジェクトを作成するときに構成されるプロジェクトの ConfigMap を通じて |
アプリケーション データベース ポッド内のMongoDB Agent | オートメーション構成を受信します | MongoDB Ops Managerインスタンスに接続する必要はありません。 MongoDB Agent は ヘッドレス モードで実行されています。 |
アプリケーション データベース ポッドでのモニタリングエージェント | モニタリング データを送信します | デフォルトの MongoDB Ops Manager FQDN の形式で: |
| オートメーション構成、バックアップ、復元のプロセスを受け取ります | プロジェクトを作成するときに構成されるプロジェクトの ConfigMap を通じて |
| モニタリング データを送信します | プロジェクトを作成するときに構成されるプロジェクトの ConfigMap を通じて |
user | MongoDB Ops Manager UI またはAPIを使用する | 次のように構成された外部に公開されたMongoDB Ops Managerインスタンスのパブリック 外部ドメインを介して: |
サービスメッシュ
アプリケーションデータベース インスタンスとMongoDB Ops Managerアプリケーション インスタンスをホストしているノードを同じサービス キャッシュに追加して、次のことを可能にします。
配置されたコンポーネント間のネットワーク接続。
クロスクラスターの DNS 解決。
Kubernetes 演算子とMongoDB Ops Managerインスタンス間のネットワーク構成を簡素化するには、Kubernetes 演算子をインストールするKubernetesクラスターであるセントラルクラスターを同じサービスメッシュに追加します。これは厳密な要件ではありません。セントラルクラスターを同じサービスメッシュに含めると、MongoDB Ops Managerアプリケーションとアプリケーションデータベースインスタンスをホストするために使用できます。
次の Kubernetes クラスターのサービス メトリクスを構成し、メッシュ構成に含めます。
Kubernetes 演算子自体を配置する中央クラスター。
アプリケーション インスタンスをホストする "Kubernetes クラスター" 。MongoDB Ops Manager
追加のメンバーKubernetesクラスター、またはMongoDB Ops Managerに使用されるのと同じメンバーのクラスターは、アプリケーション データベース インスタンスをホストします。
すべてのKubernetesクラスターに同じサービス メトリクスが構成されている場合、各MongoDB Ops Managerインスタンスは、複数のKubernetesクラスターに配置された任意のアプリケーションデータベースインスタンスへの安全な接続を確立できます。
アプリケーションKubernetes APIMongoDB Ops ManagerKubernetesデータベース インスタンスをメンバーの クラスターに配置した後、メンバーの クラスターに配置する各 インスタンスの エンドポイントが、各アプリケーション データベースのインスタンスに直接接続できる必要があります。これにより、 Kubernetes Operator は、管理ユーザーの作成やバックアップの構成など、ノードクラスターにMongoDB Ops Managerインスタンスを配置するために必要なステージを完了できます。
ロード バランシング
ほとんどの場合、ユーザーがMongoDB Ops Manager UI にアクセスできるようにするには、 MongoDB Ops Managerアプリケーションへの外部アクセスを提供する必要があります。
MongoDB Ops Manager Application のマルチクラスター配置の場合、各クラスターは サービス の LoadBalancer タイプを使用して、 MongoDB Ops Manager Application をホストしている POD を個別に公開できます。
spec.externalConnectivityを使用してLoadBalancerサービスを作成し、外部ドメインをそのサービスの外部 IP アドレスに向けます。 MongoDB Ops Managerアプリケーションの複数のインスタンスを構成する場合でも、 KubernetesサービスはMongoDB Ops Managerアプリケーションをホストしているすべての利用可能なポッドにラウンドロギングする方法でトラフィックを送信します。
Kubernetes Operator は、すべての Kubernetes クラスターにわたるすべての ポッドへのトラフィックの負荷分散をサポートしていないため、Kubernetes Operator 構成の外部で負荷分散を構成する必要があります。
次の例と図は、複数の Kubernetes クラスターにわたって負荷分散を構成する多くの方法のうちの一部を示しています。
図の例1 : 外部ロード バランサー
アプリケーションとアプリケーション データベースをホストしているすべての クラスターに対して外部ネットワーク ロード バランサー（パス経由 プロキシ）を構成します。KubernetesMongoDB Ops ManagerMongoDB Ops Managerアプリケーションはステートレスです。 ロード バランサーは、1 つのクラスターがアクティブな間、他のクラスターがアクティブである間は、ロード バランサーを一度に 1 つのクラスターにトラフィックを転送することができLoadBalancer 。 次の図は、このアプローチを示しています。
この図では、次のことが行われます。
Kubernetes Operator は、各ノードクラスターに割り当てられた外部 IP アドレスを持つ、
<om_resource_name>-svc-extという名前のLoadBalancerの外部サービスを作成します。 このサービスは、spec.externalConnectivityを使用して、すべてのノード クラスターに対してグローバルに構成できます。 または、このサービスが各メンバー クラスターに固有である場合は、spec.clusterSpecList.externalConnectivityを使用して構成できます。Kubernetes Operator がMongoDB Ops Managerアプリケーション用に作成する各サービスには、現在のクラスターからMongoDB Ops Managerアプリケーションをホストしているすべてのポッドが常に含まれます。
図の例2 : プロキシを使用した、サービス メッシュによるロード バランシング
サービス メトリクスが提供するクラスター間での負荷分散機能を使用します。
各Kubernetesクラスターでは、 Kubernetes Operator は サービス、<om_resource_name>-svc という名前のサービスを作成します。このサービスを使用すると、すべてのノードクラスターで MongoDB Ops Manager アプリケーション インスタンスをホストしているすべての利用可能なポッドにトラフィックを分散できます。
Nginx や HAProxy などのプロキシ コンポーネントをクラスターの 1 つに配置し、パブリックな FQDN を介してインターネット経由で外部に公開し、プロキシを構成して、TCP パススルーを介してすべてのネットワーク トラフィックを <om_resource_name>-svc.<namespace>.svc.cluster.local という名前のサービスに転送できます。
次の図は、このアプローチを示しています。
この図では、次のことが行われます。
Kubernetes Operator は各ノードクラスターで、 を使用してアクセスできるタイプ
ClusterIP<om_resource_name>-svc.<namespace>.svc.cluster.localのサービスを作成します。これは、このノード クラスターに配置されたすべての ポッド をエンドポイントに含むサービスです。Kubernetes クラスター間のトラフィックは サービス メトリクスによって処理されます。 Kubernetes Operator がMongoDB Ops Manager Application の各ノード クラスターにサービスを作成する場合、 Kubernetes Operator はこれらのサービスの名前にクラスター インデックス サフィックスを割り当て ません 。 そのため、サービス メトリクスは、すべてのクラスターでMongoDB Ops Managerアプリケーションをホストしているすべてのポッドに対してトラフィック負荷分散を実行できます。
各ノード クラスターに、Kubernetes Operator は
<om_resource_name>-<cluster-index>という名前のStateulSet を配置します。 たとえば、om-0は、インデックス0を持つノードクラスターの Atlas App Services の名前です。各クラスターには
<om_resource_name>-svcClusterIPサービスが配置されていますが、このサービスはユーザー トラフィックを処理しません。 ユーザーがMember Cluster 1のサービスにアクセスすると、サービス キャッシュはトラフィックを処理します。MongoDB Ops Managerアプリケーションをホストする各ポッドは、ステートメント名にちなんで命名されます。 たとえば、
om-1-2は、インデックス1を持つクラスター内のポッド番号2の名前です。