サービスメッシュのないマルチクラスターシャードクラスタ

マルチクラスターのシャーディングされたクラスターの配置でリソース間の接続を容易にするために、サービスメトリクスを配置することをお勧めします。ただし、サービスメトリクスなしでマルチクラスターのシャーディングされたクラスターの配置をスタンドアロンする場合は、このガイドに従ってマルチクラスターリソース間の必要なネットワークを構成できます。

サービスメトリクスがない複数のKubernetesクラスターにわたるシャードクラスタの配置では、各プロセスが外部で公開され、外部で使用可能なホスト名でプロセス自体を識別するように構成されている必要があります。各ホスト名のネットワークが適切に構成されている場合（つまり、特定のホスト名に接続する際のトラフィックが特定のプロセス/ポッドにルーティングされる場合）、他のすべてのMongoDBプロセスとクライアントはクラスター内のすべてのプロセスに接続できます。クライアントは mongos プロセスにのみ接続しますが、シャーディングされたクラスターの配置ではすべてのプロセスがシャーシャーディングされたクラスターがあります。

手順

Prepare Kubernetes clusters.

各Kubernetesクラスターの名前空間を構成します。

必要な構成を実行するには、kubectl mongodbプラグインを使用することをお勧めします（RBAC、サービスアカウント、および他のKubernetesクラスターへの認証情報を含むKubernetes Operator のKubernetesシークレット）は、すべてのクラスターで自動的に起動します。詳しくは、「マルチクラスターのシャードクラスタ」を参照してください。

Kubernetes Operator をインストールして構成します。

この並列手順は、マルチクラスターMongoDB Ops Manager配置ガイドから実行できます。

MongoDBリソースの配置。

次の例に示すように、type と topology を type=ShardedCluster と topology=MultiCluster として構成します。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
annotations:
    mongodb.com/v1.architecture: non-static
name: mdb-sharded
namespace: ls
spec:
shardCount: 1
topology: MultiCluster
type: ShardedCluster
version: 8.0.4
credentials: my-credentials
opsManager:
    configMapRef:
    name: my-project
persistent: true
security:
    authentication:
    agents:
        mode: X509
    enabled: true
    internalCluster: X509
    modes:
        - X509
    certsSecretPrefix: prefix
    tls:
    ca: issuer-ca
    enabled: true
externalAccess: {}
configSrv:
    clusterSpecList:
    - clusterName: kind-e2e-cluster-1
        externalAccess:
        externalDomain: kind-e2e-cluster-1.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-2
        externalAccess:
        externalDomain: kind-e2e-cluster-2.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-3
        externalAccess:
        externalDomain: kind-e2e-cluster-3.interconnected
        externalService: {}
        members: 1
mongos:
    clusterSpecList:
    - clusterName: kind-e2e-cluster-1
        externalAccess:
        externalDomain: kind-e2e-cluster-1.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-2
        externalAccess:
        externalDomain: kind-e2e-cluster-2.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-3
        externalAccess:
        externalDomain: kind-e2e-cluster-3.interconnected
        externalService: {}
        members: 1
shard:
    clusterSpecList:
    - clusterName: kind-e2e-cluster-1
        externalAccess:
        externalDomain: kind-e2e-cluster-1.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-2
        externalAccess:
        externalDomain: kind-e2e-cluster-2.interconnected
        externalService: {}
        members: 1
    - clusterName: kind-e2e-cluster-3
        externalAccess:
        externalDomain: kind-e2e-cluster-3.interconnected
        externalService: {}
        members: 1

例の詳細と考慮事項

上記の例は本番環境への準備ができていません。以下の詳細と考慮事項に注意してください。

例のドメイン（kind-e2e-cluster-3.interconnected）は一時的なものであり、外部からアクセスできる適切なドメインに置き換える必要があります。
この構成では TLS（TLS を使用しないとMongoDBプロセスを外部で安全に公開することはできません）と x509認証を使用します。これは、ニーズに応じて任意に構成できます。詳細については、適切な暗号化と認証を参照してください。
次のコンポーネントに対して、シャーディングされたクラスター内の TLS 証明書を発行する必要があります。
- 各シャードレプリカセット
- コンフィギュレーションサーバーのレプリカセット
- mongos
各 TLS 証明書（手動または証明書マネージャーによって発行された TLS タイプの -cert シークレット）は、 Kubernetes Operator がを実行中Kubernetesクラスターで提供する必要があります。ここから、 Kubernetes Operator は必要なリソース（生成された -cert-pem シークレット）を他のKubernetesクラスターに自動的に複製します。
各コンポーネントの各 TLS 証明書には、そのコンポーネントのレプリカセットのすべてのプロセスのすべてのホスト名が含まれている必要があります。例、最初のシャード（インデックス0）に対して発行された証明書の SANフィールドには、次のホスト名（配置されるクラスターごとに、ポッド名は規則 mdb-sharded-<shardIdx>-<clusterIdx>-<podIdxInThisCluster> に従います）が含まれている必要があります。
- mdb-sharded-0-0-0.kind-e2e-cluster-1.interconnected
- mdb-sharded-0-1-0.kind-e2e-cluster-2.interconnected
- mdb-sharded-0-2-0.kind-e2e-cluster-3.interconnected

参照のため、提供された例で配置されたシャーディングされたクラスターのすべてのプロセスは、次のホスト名で構成されています。

mdb-sharded-0-0-0.kind-e2e-cluster-1.interconnected (shard-0)
mdb-sharded-0-1-0.kind-e2e-cluster-2.interconnected (shard-0)
mdb-sharded-0-2-0.kind-e2e-cluster-3.interconnected (shard-0)
mdb-sharded-config-0-0.kind-e2e-cluster-1.interconnected (cs)
mdb-sharded-config-1-0.kind-e2e-cluster-2.interconnected (cs)
mdb-sharded-config-2-0.kind-e2e-cluster-3.interconnected (cs)
mdb-sharded-mongos-0-0.kind-e2e-cluster-1.interconnected (mongos)
mdb-sharded-mongos-1-0.kind-e2e-cluster-2.interconnected (mongos)
mdb-sharded-mongos-2-0.kind-e2e-cluster-3.interconnected (mongos)

各 externalService: はデフォルトのオブジェクト{} で定義されます。
つまり、 Kubernetes Operator は、デフォルト値を持つ外部サービス（外部トラフィックをルーティングするために使用される各ポッド用に作成されたサービス）を作成します。
- type: LoadBalancer
- ports: 27017、バックアップ目的の場合は 27018
Kubernetesクラスター内のクラスター構成とロードバランサーコントローラーによっては、外部サービスに LoadBalancer タイプを使用すると、シャーディングされたクラスター内の各プロセスに対してロードバランサーリソースがプロビジョニングされます。これにより、大量の LoadBalancer リソースが割り当てられる可能性があります。最小配置（1 mongos、3-ノードコンフィギュレーションサーバーレプリカセット、3-ノードレプリカセットの 1 シャード）では、これにより、7 LoadBalancer サービスが作成されます。
作成される LoadBalancer リソースの数を最小限に抑えるには、次の例に示すように、ClusterIP サービスを使用して外部アクセスを構成することをお勧めします。
```
- clusterName: kind-e2e-cluster-3
  externalAccess:
    externalDomain: kind-e2e-cluster-3.interconnected
    externalService:
      type: ClusterIP
```
各プロセス（ポッド）に 1 つの ClusterIP 外部サービスが関連付けられている場合には、 Kubernetesクラスターへの 1 つの外部「エントリ点」プロキシコンポーネントを作成する必要があります。これは任意のプロキシ（例:HAProxy、Nginx）は、TLS パスオーバールーティングをサポートします。
- プロキシコンポーネントは各Kubernetesクラスターに配置され、各クラスター内のコンポーネントに対して定義されたホスト名で外部に公開する必要があります。
  - 上記の例では、kind-e2e-cluster-3 に定義された各コンポーネント（mongos、コンフィギュレーションサーバー、シャード）が externalDomain を使用しています。externalDomain: kind-e2e-cluster-3.interconnected
    つまり、プロキシコンポーネントは *.kind-e2e-cluster-3.interconnected へのすべての接続を受信するように構成する必要があります。
    各接続は、命名規則 <pod-name>.<externalDomain> に準拠したホスト名（例: ）です。
    シャードポッド: mdb-sharded-0-2-0.kind-e2e-cluster-2.interconnected (mdb-sharded-<shardIdx>-<clusterIdx>-<podIdx>
- プロキシコンポーネントは、すべてのトラフィック（ポート 27017 または 27018）がそれぞれの外部サービスにプロキシされるように構成する必要があります（トラフィックを再暗号化せずに TCP レベルで）。
  - 例、mdb-sharded-0-2-0-svc-external では、<pod-name>.kind-e2e-cluster-2.interconnected が <pod-name>-mdb-sharded-0-2-0-svc-external に転送されるようにディスパッチを構成するときに一般的なルールが使用されます。
例で使用されている externalDomain は合成値であることに注意してください。適切なドメイン名に置き換える必要があります。
演算子は、必要なすべての外部サービスとともに、 Kubernetesクラスター全体にすべてのプロセスを配置します。
各クラスター内の各外部サービスは、定義された外部ドメイン上の外部トラフィックを受信する必要があります。ネットワークが完全に設定されるまで、クラスターは正しく構成されません。レプリカセットを構成するには、 mongodプロセスがレプリケーション目的で相互に接続できる必要があるためです。
外部ドメインを使用する場合、すべてのネットワーク（レプリケーションおよびMongoDB Agent からMongoDBへの接続）はデフォルトで外部ドメインを介してルーティングされるため、効率が低い可能性があります。改善方法の 1 つは、同じKubernetesクラスターに配置されたポッドの外部ホスト名が外部サービスのクラスターローカルIPアドレスに解決されるように、クラスター内でネットワークまたは DNS 解決を構成することです。

戻る

シャーディングされたクラスター

レプリカセットの障害復旧