Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/ /

Kubernetes の外部からマルチクラスター リソースへの接続

項目一覧

  • 前提条件
  • Considerations
  • 手順

次の手順では、Kubernetes クラスターの外部から Kubernetes に配置された MongoDBMultiClusterリソースに接続する方法について説明します。

MongoDB 4.2.3 以降を実行するデータベースでは、Kubernetes クラスターの外部でそれらにアクセスできます。

Kubernetes Operator によって配置された MongoDB カスタム リソースへの外部アクセスを必要とするカスタム サービスを作成し、Kubernetes で準備状況検証を使用する場合は、Kubernetes のpublishNotReadyAddresses設定をtrueに設定します。

publishNotReadyAddresses設定は、このサービスのエンドポイントを操作するエージェントが、サービスの ready 状態を無視する必要があることを示します。publishNotReadyAddressestrue に設定すると、サービスをホストしているポッド用に構成された準備状況の動作が上書きされます。

デフォルトでは、 publishNotReadyAddresses設定はfalseに設定されています。 この場合、MongoDB KubernetesOperator で カスタム リソースをホストするポッドがCloud Manager またはMongoDB Ops Manager への接続を失うと、これらのポッドに構成された準備状況は失敗します。ただし、 publishNotReadyAddressesの設定をtrueに設定すると、次の効果が生じます。

  • Kubernetes は、準備状況調査に失敗したサービスをシャットダウンしません。

  • Kubernetes はすべてのエンドポイントを 準備完了 と見なします これらのエンドポイントのサービスをホストしているポッドの検証が、準備ができていないことを示していても。

  • MongoDB のカスタム リソースは、読み取りおよび書込み操作で引き続き使用できます。

Tip

以下も参照してください。

Kubernetes Operator が配置したレプリカセットに、Kubernetes クラスターの外部からMongoDBMultiClusterリソースを使用して接続するには、次の手順に従います。

1
2

次の値を指定します。

  • spec.security.certsSecretPrefix TLSシークレット

  • のカスタム CA spec.security.tls.ca証明書。

3

外部リソースからマルチ Kubernetes クラスター配置に接続するには、 spec.externalAccessを構成します 設定:

externalAccess: {}

この設定は、Kubernetes Operator に外部 LoadBalancer を作成するように指示します マルチ Kubernetes クラスター配置での MongoDB ポッドのサービス外部サービスは、外部接続のエントリポイントを提供します。 値なしでこの設定を追加すると、次のデフォルト値を持つ外部サービスが作成されます。

フィールド
説明
Name
<pod-name>-svc-external
外部サービスの名前。 この値は変更できません。
Type
LoadBalancer
Port
<Port Number>
mongodのポート。
publishNotReadyAddress
true
DNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでもfalseに設定しないでください。

オプションとして、サービスに値を追加したり、デフォルト値を上書きしたりする必要がある場合は、次を指定します。

たとえば、次の設定は外部サービスのデフォルト値を上書きし、複数の Kubernetes クラスターの配置を構成して NodePort サービス を作成します MongoDB ポッドを公開する:

externalAccess:
externalService:
annotations:
# cloud-specific annotations for the service
spec:
type: NodePort # default is LoadBalancer
port: 27017
# you can specify other spec overrides if necessary

Tip

詳細については、 注釈 を参照してください および ServiceSpec (Kubernetes ドキュメント)。

4

ノードを別のクラウドプロバイダーでホストしている場合など、特定のクラスター ノードの設定を構成する必要がある場合は、グローバルspec.externalAccessを上書きできます spec.clusterSpecList.externalAccess.externalServiceを使用した、特定のノードの設定 設定。

サービスに値を追加したり、クラスター ノードのデフォルト値を上書きしたりするには、次を指定します。

たとえば、次のファイルは、複数のKubernetes MongoDBKubernetesクラスター の配置を構成して、MongoDB GKE(GoogleKubernetes Engine) に配置されたクラスター ノード向けに複数の クラスター 配置を公開するロード バランサー サービスを作成します。 とAmazon Web Services EKS 。

注意

次の例ではオーバーライドを構成していないため、外部サービスはspec.externalAccessのデフォルト値を使用します。 設定。

clusterSpecList:
- clusterName: gke-cluster-0.mongokubernetes.com
members: 2
externalAccess:
externalService:
annotations:
"cloud.google.com/l4-rbs": "enabled"
- clusterName: eks-cluster-1.mongokubernetes.com
members: 2
externalAccess:
externalService:
annotations:
"service.beta.kubernetes.io/aws-load-balancer-type": "external",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "instance",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing"
5

各外部DNS名を証明書SANに追加します。

6

各クラスターで次のコマンドを実行して、Kubernetes Operator が配置用の外部サービスを作成したことを確認します。

$ kubectl get services

このコマンドは、次の出力のようなサービスのリストを返します。 Kubernetes Operator は、クラスター内の各データベース<pod-name> <cluster-idx><pod-idx>ポッドに対して、[pod-name]-[cluster-idx]-[pod-idx]-svc-external という名前の外部サービスを作成します。このサービスは、外部サービス仕様で指定した値とオーバーライドに従って構成されます。

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
<my-replica-set>-0-0-svc-external LoadBalancer 10.102.27.116 <lb-ip-or-fqdn> 27017:27017/TCP 8m30s

クラスター構成またはクラウドプロバイダーによっては、LoadBalancer サービスの IP アドレスは外部からアクセス可能な IP アドレスまたはFQDNになります。 IP アドレスまたはFQDNを使用して、外部ドメインからのトラフィックをルーティングできます。

7

spec.connectivity.replicaSetHorizonsのホスト名とポートを、前のステップで作成した外部サービス値に設定します。

正しい外部ホスト名を指定したことを確認します。 外部ホスト名は、Kubernetes ワーカー ノードのDNS名と一致する必要があります。 これらは、Kubernetes クラスター内の任意のノードになります。 ポッドが別のノードで実行される場合、Kubernetes ノードは内部ルーティングを使用します。

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
name: multi-cluster-replica-set
namespace: mongodb
spec:
clusterSpecList:
- clusterName: e2e.cluster1.example.com
members: 1
- clusterName: e2e.cluster2.example.com
members: 1
- clusterName: e2e.cluster3.example.com
members: 1
connectivity:
replicaSetHorizons:
- sample-horizon: web1.example.com:30907
- sample-horizon: web2.example.com:30907
- sample-horizon: web3.example.com:30907
credentials: my-credentials
duplicateServiceObjects: false
opsManager:
configMapRef:
name: my-project
persistent: true
security:
certsSecretPrefix: clustercert
tls:
ca: ca-issuer
type: ReplicaSet
version: 6.0.0-ent"
8

各クラスターで次のコマンドを実行して、更新されたレプリカセット ファイルを適用します。

$ Kubectl apply -f <file_name.yaml>
9

開発環境では、レプリカセット内の各ホストに対して、次のコマンドを実行します。

mongosh --host <my-replica-set>/web1.example.com \
--port 30907
--ssl \
--sslAllowInvalidCertificates

注意

本番環境では--sslAllowInvalidCertificatesフラグを使用しないでください。

本番環境では、レプリカセット内の各ホストに対して、クライアント ツールまたはアプリケーションに安全に接続するためのTLS証明書とCAを指定します。

mongosh --host <my-replica-set>/web1.example.com \
--port 30907 \
--tls \
--tlsCertificateKeyFile server.pem \
--tlsCAFile ca-pem

接続が成功すると、次の内容が表示されます。

Enterprise <my-replica-set> [primary]

戻る

リソースにアクセスする