ネットワーキング、ロードバランシング、サービスメッシュ
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 は ヘッドレス モードで実行されています。 |
アプリケーション データベース ポッドでのモニタリングエージェント | モニタリング データを送信します | |
| オートメーション構成、バックアップ、復元のプロセスを受け取ります | プロジェクトを作成するときに構成されるプロジェクトの ConfigMap を通じて |
| モニタリング データを送信します | プロジェクトを作成するときに構成されるプロジェクトの ConfigMap を通じて |
user | MongoDB Ops Manager UI またはAPIを使用する | 次のように構成された外部に公開されたMongoDB Ops Managerインスタンスのパブリック 外部ドメインを介して: |
サービスメッシュ
アプリケーションデータベース インスタンスとMongoDB Ops Managerアプリケーション インスタンスをホストしているノードを同じサービス キャッシュに追加して、次のことを可能にします。
配置されたコンポーネント間のネットワーク接続。
クロスクラスターの DNS 解決。
Kubernetes Operator とMongoDB Ops Managerインスタンス間のネットワーク構成を簡素化するために、 Kubernetes Operator を同じサービス ノードにインストールするKubernetesクラスターである 演算子クラスターを追加することをお勧めしますが、これは厳密な要件ではありません。 演算子クラスターを同じサービス メトリクスに含めると、 MongoDB Ops Managerアプリケーションとアプリケーション データベース インスタンスのホストとして使用できます。
次の Kubernetes クラスターのサービス メトリクスを構成し、メッシュ構成に含めます。
Kubernetes Operator 自体を配置する「オペレーター クラスター」。
アプリケーション インスタンスをホストする "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 アプリケーションのマルチクラスター配置の場合、各クラスターは タイプ のサービス を使用して、MongoDB Ops ManagerLoadBalancer アプリケーションをホストするポッドを個別に公開できます。
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 アプリケーション インスタンスをホストしているすべての利用可能なポッドにトラフィックを分散できます。
<om_resource_name>-svc.<namespace>.svc.cluster.localや HAProxy などのプロキシ コンポーネントを クラスターの 1 つに配置し、パブリックFQDNを通じてインターネット経由で外部に公開する。
次の図は、このアプローチを示しています。
この図では、次のことが行われます。
各ノードクラスターで、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の名前です。