Página inicial do Docs → Operador de Kubernetes do MongoDB Enterprise

Pré-requisitos

Nesta página

Revise as arquiteturas de hardware suportadas

Clone o repositório do MongoDB Enterprise Kubernetes Operator
Definir variáveis de ambiente e zonas GKE
Configurar clusters GKE
Obter credenciais de autenticação de usuário para clusters centrais e de membros
Instalar o Go e o Helm
Entender as funções e vinculações de funções do Kubernetes
Definir o escopo do sistema
Planejar a conectividade externa: Você deve usar uma malha de serviços?
Verificar a conectividade entre clusters
Revise os requisitos para implantar o Ops Manager
Prepare-se para conexões criptografadas por TLS
Escolha GitOps ou o plug-in kuberctl MongoDB
Instalar o plug-in kuberctl do MongoDB
Configurar recursos para GitOps

Antes de criar um sistema de vários clusters Kubernetes usando o início rápido ou um procedimento de sistema, conclua as seguintes tarefas:

Revise as arquiteturas de hardware suportadas

Consulte as arquiteturas de hardware suportadas.

Clone o repositório do MongoDB Enterprise Kubernetes Operator

Clone o repositório do MongoDB Enterprise Kubernetes Operator :

git clone https://github.com/mongodb/mongodb-enterprise-kubernetes.git

Definir variáveis de ambiente e zonas GKE

Defina as variáveis de ambiente com nomes de clusters e as zonas GKE disponíveis onde você distribui os clusters, como neste exemplo:

export MDB_GKE_PROJECT={GKE project name}
export MDB_CENTRAL_CLUSTER="mdb-central"
export MDB_CENTRAL_CLUSTER_ZONE="us-west1-a"
export MDB_CLUSTER_1="mdb-1"
export MDB_CLUSTER_1_ZONE="us-west1-b"
export MDB_CLUSTER_2="mdb-2"
export MDB_CLUSTER_2_ZONE="us-east1-b"
export MDB_CLUSTER_3="mdb-3"
export MDB_CLUSTER_3_ZONE="us-central1-a"
export MDB_CENTRAL_CLUSTER_FULL_NAME="gke_${MDB_GKE_PROJECT}_${MDB_CENTRAL_CLUSTER_ZONE}_${MDB_CENTRAL_CLUSTER}"
export MDB_CLUSTER_1_FULL_NAME="gke_${MDB_GKE_PROJECT}_${MDB_CLUSTER_1_ZONE}_${MDB_CLUSTER_1}"
export MDB_CLUSTER_2_FULL_NAME="gke_${MDB_GKE_PROJECT}_${MDB_CLUSTER_2_ZONE}_${MDB_CLUSTER_2}"
export MDB_CLUSTER_3_FULL_NAME="gke_${MDB_GKE_PROJECT}_${MDB_CLUSTER_3_ZONE}_${MDB_CLUSTER_3}"

Configurar clusters GKE

Configurar o GKE (Google Kubernetes Engine) clusters:

Configure sua conta do Google Cloud.

Se você ainda não tiver feito isso, crie um GCP projeto, habilite o faturamento no projeto, habilite o Arquivo de Trabalho e as API e inicie o shell seguindo os procedimentos relevantes no Início rápido do Kubernetes na documentação do GCP.

Crie um cluster central e clusters de membros.

Crie um cluster central e um ou mais clusters membros, especificando as zonas de GKE, o número de nós e os tipos de instância, como nestes exemplos:

gcloud container clusters create $MDB_CENTRAL_CLUSTER \
  --zone=$MDB_CENTRAL_CLUSTER_ZONE \
  --num-nodes=5 \
  --machine-type "e2-standard-2"

gcloud container clusters create $MDB_CLUSTER_1 \
  --zone=$MDB_CLUSTER_1_ZONE \
  --num-nodes=5 \
  --machine-type "e2-standard-2"

gcloud container clusters create $MDB_CLUSTER_2 \
  --zone=$MDB_CLUSTER_2_ZONE \
  --num-nodes=5 \
  --machine-type "e2-standard-2"

gcloud container clusters create $MDB_CLUSTER_3 \
  --zone=$MDB_CLUSTER_3_ZONE \
  --num-nodes=5 \
  --machine-type "e2-standard-2"

Obter credenciais de autenticação de usuário para clusters centrais e de membros

Obtenha credenciais de autenticação de usuário para os clusters Kubernetes centrais e de membros e salve as credenciais. Posteriormente, você utilizará estas credenciais para executar comandos do kubectl nestes agrupamentos.

Execute os seguintes comandos:

gcloud container clusters get-credentials $MDB_CENTRAL_CLUSTER \
  --zone=$MDB_CENTRAL_CLUSTER_ZONE
gcloud container clusters get-credentials $MDB_CLUSTER_1 \
  --zone=$MDB_CLUSTER_1_ZONE
gcloud container clusters get-credentials $MDB_CLUSTER_2 \
  --zone=$MDB_CLUSTER_2_ZONE
gcloud container clusters get-credentials $MDB_CLUSTER_3 \
  --zone=$MDB_CLUSTER_3_ZONE

Instalar o Go e o Helm

Instale as seguintes ferramentas:

Instalar Go v1.17 ou posterior.
Instalar o Helm.

Entender as funções e vinculações de funções do Kubernetes

Para usar um sistema de vários clusters Kubernetes, você deve ter um conjunto específico de funções do Kubernetes , ClusterRoles, RoleBindings, ClusterRoleBindings, e ServiceAccounts, que você pode configurar de qualquer uma das seguintes maneiras:

Siga o Início Rápido de Multi-Kubernetes-Cluster, que informa como usar o Plugin MongoDB para criar automaticamente os objetos necessários e aplicá-los aos clusters apropriados dentro de sua implantação de multi-Kubernetes-cluster.

Usar Helm para configurar as funções do Kubernetes e as contas de serviço necessárias para cada cluster de membros:

helm template --show-only \
  templates/database-roles.yaml \
  mongodb/enterprise-operator \
  --set namespace=mongodb | \
kubectl apply -f - \
  --context=$MDB_CLUSTER_1_FULL_NAME \
  --namespace mongodb

helm template --show-only \
  templates/database-roles.yaml \
  mongodb/enterprise-operator \
  --set namespace=mongodb | \
kubectl apply -f - \
  --context=$MDB_CLUSTER_2_FULL_NAME \
  --namespace mongodb

helm template --show-only \
  templates/database-roles.yaml \
  mongodb/enterprise-operator \
  --set namespace=mongodb | \
kubectl apply -f - \
  --context=$MDB_CLUSTER_3_FULL_NAME \
  --namespace mongodb

Crie manualmente arquivos de objeto do Kubernetes .yaml e adicione as funções do Kubernetes e as contas de serviço necessárias à sua implantação de vários clusters do Kubernetes com o comando kubectl apply . Isso pode ser necessário para determinados fluxos de trabalho altamente automatizados. O MongoDB fornece arquivos de configuração de amostra.
Para recursos personalizados com escopo para um subconjunto de namespaces:
- Roles, vinculações de role e contas de serviço para seu cluster central
- Roles, vinculações de role e contas de serviço para seus clusters de membros
Para recursos personalizados com escopo para um namespace em todo o cluster:
- ClusterRoles, ClusterRoleBindings e ServiceAccounts para seu cluster central
- ClusterRoles, ClusterRoleBindings e ServiceAccounts para o seu cluster de membros
Cada arquivo define vários recursos. Para suportar sua implantação, você deve substituir os valores de espaço reservado nos seguintes campos:
- subjects.namespace em cada recurso RoleBinding ou ClusterRoleBinding
- metadata.namespace em cada recurso ServiceAccount
Após modificar as definições, aplique-as executando o seguinte comando para cada arquivo:
```
kubectl apply -f <fileName>
```

Definir o escopo do sistema

Por padrão, o Kubernetes Operator de vários clusters tem como escopo o namespace no qual você o instala. O Operador Kubernetes reconcilia o recurso MongoDBMultiCluster implantado no mesmo namespace que o Operador Kubernetes.

Quando você executa o plug-in kubectl do MongoDB como parte do início rápido de vários clusters e não modifica as configurações kubectl mongodb do plug-in, o plug-in:

Cria um ConfigMap padrão denominado mongodb-enterprise-operator-member-list que contém todos os clusters de membros da implantação de vários clusters Kubernetes. Este nome está codificado e você não pode alterá-lo. Consulte Problemas conhecidos.
Cria contas de serviço , Roles, ClusterRoles, RoleBindings e ClusterRoleBindings no cluster central e em cada cluster de membros.
Aplica as permissões corretas para contas de serviço.
Usa as configurações anteriores para criar seu sistema de vários clusters Kubernetes.

Depois que o Operador do Kubernetes criar a implantação do cluster de vários Kubernetes, o Operador do Kubernetes começará a monitorar MongoDB os recursos do no mongodb namespace do .

Para configurar o Operador Kubernetes com as permissões corretas para implantar em um subconjunto ou em todos os namespaces, execute o comando a seguir e especifique os namespaces que você deseja que o Operador Kubernetes observe.

kubectl mongodb multicluster setup \
  --central-cluster="${MDB_CENTRAL_CLUSTER_FULL_NAME}" \
  --member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME},${MDB_CLUSTER_3_FULL_NAME}" \
  --member-cluster-namespace="mongodb2" \
  --central-cluster-namespace="mongodb2" \
  --cluster-scoped="true"

Ao instalar o sistema de vários clusters do Kubernetes em vários ou em todos os namespaces, você pode configurar o Operador Kubernetes para:

Assista a recursos em vários namespaces
Assista a recursos em todos os namespaces

Observação

Instale e configure uma única instância do Kubernetes Operator e configure-a para monitorar um, muitos ou todos os recursos personalizados em subconjuntos de namespaces diferentes e não sobrepostos. Consulte também O MongoDB suporta a execução de mais de uma instância do Kubernetes Operator?

Assista a recursos em vários namespaces

Se você definir o escopo da implantação de vários clusters Kubernetes para muitos namespaces, você pode configurar o Operador Kubernetes para observar MongoDB os recursos do nesses namespaces na implantação de vários clusters Kubernetes.

Assista a recursos em todos os namespaces

Se você definir o escopo do sistema de vários clusters Kubernetes para todos os namespaces em vez do mongodb namespace padrão, é possível configurar o Kubernetes Operator para observar MongoDB recursos em todos os namespaces no sistema de vários clusters Kubernetes.

Planejar a conectividade externa: Você deve usar uma malha de serviços?

Uma malha de serviço permite a comunicação entre clusters entre os membros do conjunto de réplicas distribuídos em diferentes clusters do Kubernetes. O uso de uma malha de serviço simplifica muito a criação de implantações de vários clusters Kubernetes e é a maneira recomendada de implantar o MongoDB em vários clusters Kubernetes. No entanto, se sua organização de T.I não usar uma malha de serviço, você poderá implantar um conjunto de réplicas em um sistema de vários clusters Kubernetes sem ela.

Dependendo do seu ambiente, faça o seguinte:

Se você puder usar uma malha de serviço, instale o Isstio.
Se você não puder usar uma malha de serviço:

Como o operador Kubernetes estabelece conectividade?

Independentemente do tipo de sistema, um MongoDB deployment no Kubernetes deve estabelecer as seguintes conexões:

Do Ops Manager MongoDB Agent no Pod ao seu processo mongod, para habilitar o gerenciamento e o monitoramento do ciclo de vida do MongoDB.
Do MongoDB Agent do Ops Manager no Pod para a instância do Ops Manager, para habilitar a automação.
Entre todos os processos do mongod , para permitir a replicação.

Quando o Kubernetes Operator implementa os recursos do MongoDB, ele trata esses requisitos de conectividade das seguintes maneiras, dependendo do tipo de implementação:

Em um único sistema de cluster do Kubernetes, o Operador do Kubernetes configura nomes de host no conjunto de réplicas como FQDNs de um Serviço Headless. Este é um serviço único que resolve o DNS de um endereço IP direto de cada Pod que hospeda uma instância MongoDB pelo FQDN do Pod, da seguinte forma: <pod-name>.<replica-set-name>-svc.<namespace>.svc.cluster.local.
Em um sistema de cluster multi-Kubernetes que usa uma malha de serviço, o Operador do Kubernetes cria um StatefulSet separado para cada membro do conjunto de réplicas MongoDB no cluster Kubernetes. Uma malha de serviço permite a comunicação entre processos do mongod em clusters Kubernetes distintos.
O uso de uma malha de serviço permite a implantação de vários clusters Kubernetes para:
- Obtenha uma resolução global de nome de host DNS para clusters Kubernetes e estabeleça conectividade entre eles. Para cada Pod de MongoDB deployment em cada cluster Kubernetes, o Kubernetes Operator cria um serviço ClusterIP por meio da configuração spec.duplicateServiceObjects: true no recurso MongoDBMultiCluster . Cada processo tem um nome de host definido para o FQDN deste serviço: <pod-name>-svc.<namespace>.svc.cluster.local. Esses nomes de host são resolvidos do DNS para o ClusterIP de um serviço em cada cluster de membros.
- Estabeleça comunicação entre Pods em diferentes clusters Kubernetes. Como resultado, os membros do conjunto de réplicas hospedados em clusters diferentes formam um único conjunto de réplicas nestes clusters.
Em um sistema de cluster multi-Kubernetes sem uma tela de serviço, o Operador do Kubernetes utiliza as seguintes configurações de recurso do MongoDBMultiCluster para expor todos os seus processos do mongod externamente. Isso permite a resolução de DNS de nomes de host entre clusters Kubernetes distintos e estabelece conectividade entre Pods roteados por meio das redes que conectam esses clusters.

Opcional: instale o Istion

Instalar o ISO em um modo multiprimário em diferentes redes, usando a documentação do Istion. O Isthio é uma malha de serviço que simplifica a resolução de DNS e ajuda a estabelecer comunicação entre clusters entre os clusters Kubernetes membros em um sistema de vários clusters Kubernetes. Se você optar por usar uma tela de serviço, será necessário instalá-la. Se você não puder utilizar uma malha de serviço, pule esta seção e use domínios externos e configure o DNS para habilitar a conectividade externa.

Além disso, oferecemos o script de exemplo install_istio_separate_network. Este script é baseado na documentação do Istion e fornece um exemplo de instalação que usa o modo multiprimário em diferentes redes. Não garantimos a manutenção do script com futuros lançamentos do Istion. Se você optar por usar o script, revise a documentação mais recente do Istion para instalar um multicluster e, se necessário, ajuste o script para corresponder à documentação e à sua implantação. Se você usar outra solução de malha de serviço, crie seu próprio script para configurar redes separadas para facilitar a resolução de DNS.

Habilitar conectividade externa por meio de domínios externos e zonas de DNS

Se você não utilizar uma malha de serviço, faça o seguinte para habilitar a conectividade externa para e entre os processos do mongod e o MongoDB Agent do Ops Manager:

Ao criar um sistema de vários clusters Kubernetes, use o comando spec.clusterSpecList.externalAccess.externalDomain configuração para especificar um domínio externo e instruir o Operador do Kubernetes a configurar nomes de host para processos do mongod no seguinte padrão:
```
<pod-name>.<externalDomain>
```
Observação
Você pode especificar domínios externos apenas para novos sistemas. Você não pode alterar os domínios externos depois de configurar um sistema de vários clusters Kubernetes.
Após configurar um domínio externo desta forma, os agente MongoDB do Ops Manager e os processos do mongod utilizam este domínio para se conectar uns aos outros.
Personalize serviços externos que o Kubernetes Operator cria para cada Pod no cluster do Kubernetes. Use a configuração global no spec.externalAccess configurações e substituições específicas do cluster do Kubernetes no spec.clusterSpecList.externalAccess.externalService configurações.
Configure os nomes de host do Pod em uma zona de DNS para garantir que cada Pod do Kubernetes que hospeda um processo do mongod permita estabelecer uma conexão externa com os outros processos do mongod em um sistema de multikubernetes-cluster. Um Pod é considerado "exposto externamente" quando você pode se conectar a um processo mongod usando o nome de host <pod-name>.<externalDomain> nas portas 27017 (esta é a porta do reconhecimento de data center padrão) e 27018 (esta é a porta do reconhecimento de data center + 1). Talvez você também precise configurar regras de firewall para permitir o tráfego TCP nas portas 27017 e 27018.

Após concluir estes pré-requisitos, você poderá distribuir um cluster multi-Kubernetes sem uma tela de serviço.

Verificar a conectividade entre clusters

Siga as etapas deste procedimento para verificar se os FQDN s de serviço podem ser acessados nos clusters do Kubernetes.

Neste exemplo, você implanta um aplicativo de amostra definido em sample-service.yaml em dois clusters Kubernetes.

Crie um namespace em cada cluster.

Crie um namespace em cada um dos clusters Kubernetes para distribuir o sample-service.yaml.

kubectl create --context="${CTX_CLUSTER_1}" namespace sample
kubectl create --context="${CTX_CLUSTER_2}" namespace sample

Observação

Em determinadas soluções de malha de serviço, talvez seja necessário anotar ou rotular o namespace.

Implemente `sample-service.yaml` em ambos os clusters do Kubernetes.

kubectl apply --context="${CTX_CLUSTER_1}" \
   -f sample-service.yaml \
   -l service=helloworld1 \
   -n sample
kubectl apply --context="${CTX_CLUSTER_2}" \
   -f sample-service.yaml \
   -l service=helloworld2 \
   -n sample

Implemente o aplicativo de amostra no `CLUSTER_1`.

kubectl apply --context="${CTX_CLUSTER_1}" \
   -f sample-service.yaml \
   -l version=v1 \
   -n sample

Verifique se o `CLUSTER_1` está em execução.

Verifique se o Pod de hospedagem do CLUSTER_1 está no estado Running .

kubectl get pod --context="${CTX_CLUSTER_1}" \
   -n sample \
   -l app=helloworld

Implemente o aplicativo de amostra no `CLUSTER_2`.

kubectl apply --context="${CTX_CLUSTER_2}" \
   -f sample-service.yaml \
   -l version=v2 \
   -n sample

Verifique se o `CLUSTER_2` está em execução.

Verifique se o Pod de hospedagem do CLUSTER_2 está no estado Running .

kubectl get pod --context="${CTX_CLUSTER_2}" \
   -n sample \
   -l app=helloworld

Verifique se `CLUSTER_1` pode se conectar a `CLUSTER_2`.

Implante o Pod em CLUSTER_1 e verifique se você pode acessar o aplicativo de amostra em CLUSTER_2.

kubectl run  --context="${CTX_CLUSTER_1}" \
   -n sample \
   curl --image=radial/busyboxplus:curl \
   -i --tty \
   curl -sS helloworld2.sample:5000/hello

Você deverá ver uma saída semelhante a este exemplo:

Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8

Verifique se `CLUSTER_2` pode se conectar a `CLUSTER_1`.

Implante o Pod em CLUSTER_2 e verifique se você pode acessar o aplicativo de amostra em CLUSTER_1.

kubectl run --context="${CTX_CLUSTER_2}" \
   -n sample \
   curl --image=radial/busyboxplus:curl \
   -i --tty \
   curl -sS helloworld1.sample:5000/hello

Você deverá ver uma saída semelhante a este exemplo:

Hello version: v1, instance: helloworld-v1-758dd55874-6x4t8

Revise os requisitos para implantar o Ops Manager

Como parte do Início Rápido, você implanta um recurso do Ops Manager no cluster central. Para saber mais, consulte Implantar um recurso do Ops Manager, implantar o banco de dados de aplicativos e conectar-se ao Ops Manager.

Prepare-se para conexões criptografadas por TLS

Se você planeja proteger seu sistema de vários clusters Kubernetes usando criptografia TLS , conclua as tarefas a seguir para habilitar a autenticação interna do cluster e gerar certificados TLS para os clusters de membros e o MongoDB Agent:

Observação

Você deve possuir o certificado CA e a chave que usou para assinar seus certificados TLS .

Importante

O Operador Kubernetes utiliza kubernetes.io/tls segredos para armazenar certificados TLS e chaves privadas para recursos do Ops Manager e MongoDB. A partir da versão 1.17.0 do Kubernetes Operator, o Kubernetes Operator não oferece suporte a arquivos PEM concatenados armazenados como segredos Opaque.

Escolha GitOps ou o plug-in kuberctl MongoDB

Você pode optar por criar e manter os arquivos de recursos necessários para o sistema de recursos do MongoDBMultiCluster em um ambiente GitOps.

Se você usar um fluxo de trabalho GitOps, não poderá usar o plugin kubectl MongoDB, que configura automaticamente o RBAC (controle de acesso baseado em role) e cria o arquivo kuberconfig que permite ao cluster central se comunicar com seus clusters de membros. Em vez disso, você deve configurar manualmente ou construir sua própria automação para configurar os arquivos RBAC e kubeconfig com base no procedimento e exemplos em Configurar Recursos para GitOps.

As seções de pré-requisitos a seguir descrevem como instalar o plugin kuberctl do MongoDB se você não usar o GitOps ou configurar recursos para o GitOps , se você usar.

Instalar o plug-in kuberctl do MongoDB

Use o plug-in kubectl mongodb para:

Observação

Se você usar o GitOps, não poderá usar o plug-in kubectl mongodb . Em vez disso, siga o procedimento em Configurar recursos para GitOps.

Para instalar o plug-in kubectl mongodb :

Baixe a versão desejada do pacote do Kubernetes Operator.

Baixe a versão desejada do pacote do Kubernetes Operator na página de versão do repositório do MongoDB Enterprise Kubernetes Operator.

O nome do pacote usa este padrão: kubectl-mongodb-multicluster_{{ .Version }}_{{ .Os }}_{{ .Arch }}.tar.gz.

Use um dos seguintes pacotes:

kubectl-mongodb-multicluster_{{ .Version }}_darwin_amd64.tar.gz
kubectl-mongodb-multicluster_{{ .Version }}_darwin_arm64.tar.gz
kubectl-mongodb-multicluster_{{ .Version }}_linux_amd64.tar.gz
kubectl-mongodb-multicluster_{{ .Version }}_linux_arm64.tar.gz

Desempacote o pacote do Kubernetes Operator.

Desempacote o pacote, como no exemplo a seguir:

tar -zxvf kubectl-mongodb_<version>_darwin_amd64.tar.gz

Localize o binário do plug-in `kubectl mongodb` e copie-o para o destino desejado.

Encontre o binário kubectl-mongodb no diretório descompactado e mova-o para o destino desejado, dentro do PATH para o usuário do Kubernetes Operator, conforme mostrado no exemplo a seguir:

mv kubectl-mongodb /usr/local/bin/kubectl-mongodb

Agora você pode executar o plug-in kubectl mongodb usando os seguintes comandos:

kubectl mongodb multicluster setup
kubectl mongodb multicluster recover

Para saber mais sobre os sinalizadores suportados, consulte a Referência do plugin Kubectl do MongoDB.

Configurar recursos para GitOps

Se você usar um fluxo de trabalho GitOps, não poderá usar o plug- in kubectl MongoDB para configurar automaticamente o RBAC (controle de acesso baseado em função) ou o arquivo kubeconfig que permite ao cluster central se comunicar com seus clusters de membros. Em vez disso, você deve configurar e aplicar manualmente os seguintes arquivos de recursos ou construir sua própria automação com base nas informações abaixo.

Observação

Para saber como o kubectl mongodb plug-in automatiza as seguintes etapas, visualize o código no Github.

Para configurar o RBAC e o kubeconfig para GitOps:

Crie e aplique recursos RBAC a cada cluster.

Use estes exemplos de recursos de RBAC para criar o seu próprio. Para saber mais sobre esses recursos do RBAC, consulte Entender funções do Kubernetes e vinculações de funções.

Para aplicá-los aos clusters centrais e de membros com o GitOps, você pode usar uma ferramenta como o Arou CD.

Crie e aplique o arquivo ConfigMap.

O Kubernetes Operator acompanha seus clusters de membros usando um ConfigMap arquivo. Copie, modifique e aplique o seguinte exemplo ConfigMap:

apiVersion: v1
kind: ConfigMap
data:
  cluster1: ""
  cluster2: ""
metadata:
  namespace: <namespace>
  name: mongodb-enterprise-operator-member-list
  labels:
    multi-cluster: "true"

Configure o segredo `kubeconfig` para o operador Kubernetes.

O Operador Kubernetes, que é executado no cluster central, comunica-se com os Pods nos clusters de membros por meio da API Kubernetes. Para que isso funcione, o Kubernetes Operator precisa de um kuberconfig que contém os tokens de conta de serviço dos clusters de membros. Crie este arquivo kubeconfig seguindo estas etapas:

Obter uma lista de contas de serviço configurado no namespace do Operador do Kubernetes. Por exemplo, se você optar por usar o namespace mongodb padrão, poderá obter as contas de serviço usando o seguinte comando:
```
kubectl get serviceaccounts -n mongodb
```
Obtenha o segredo de cada conta de serviço que pertence a um cluster de membros.
```
kubectl get secret <service-account-name> -n mongodb -o yaml
```
Em cada segredo da conta de serviço, copie o certificado e o token da CA. Por exemplo, copie <ca_certificate> e <token> do segredo, conforme mostrado no exemplo a seguir:
```
apiVersion: v1
kind: Secret
metadata:
  name: my-service-account
  namespace: mongodb
data:
  ca.crt: <ca_certificate>
  token: <token>
```

Copie o exemplo kubeconfig a seguir para o cluster central e substitua os placeholders pelos <ca_certificate> e <token> que você copiou dos segredos da conta de serviço.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <cluster-1-ca.crt>
    server: https://:
  name: kind-e2e-cluster-1
- cluster:
    certificate-authority-data: <cluster-2-ca.crt>
    server: https://:
  name: kind-e2e-cluster-2
contexts:
- context:
    cluster: kind-e2e-cluster-1
    namespace: mongodb
    user: kind-e2e-cluster-1
  name: kind-e2e-cluster-1
- context:
    cluster: kind-e2e-cluster-2
    namespace: mongodb
    user: kind-e2e-cluster-2
  name: kind-e2e-cluster-2
kind: Config
users:
- name: kind-e2e-cluster-1
  user:
    token: <cluster-1-token>
- name: kind-e2e-cluster-2
  user:
    token: <cluster-2-token>

Salve o arquivo kubeconfig.

Crie um segredo no cluster central que você monta no Operador Kubernetes, conforme ilustrado no gráfico Helm de referência. Por exemplo:

kubectl --context="${CTX_CENTRAL_CLUSTER}" -n <operator-namespace> create secret --from-file=kubeconfig=<path-to-kubeconfig-file> <kubeconfig-secret-name>

← Serviços e ferramentas Início rápido do Multi-Kubernetes-Cluster →

Pré-requisitos.css-134mg1q{-webkit-align-self:center;-ms-flex-item-align:center;align-self:center;padding:0 10px;visibility:hidden;}.css-6vrlzm{border-radius:0!important;display:initial!important;margin:initial!important;}.css-1l4s55v{margin-top:-175px;position:absolute;padding-bottom:2px;}

Revise as arquiteturas de hardware suportadas

Clone o repositório do MongoDB Enterprise Kubernetes Operator

Definir variáveis de ambiente e zonas GKE

Configurar clusters GKE

Configure sua conta do Google Cloud.

Crie um cluster central e clusters de membros.

Obter credenciais de autenticação de usuário para clusters centrais e de membros

Instalar o Go e o Helm

Entender as funções e vinculações de funções do Kubernetes

Definir o escopo do sistema

Observação

Assista a recursos em vários namespaces

Assista a recursos em todos os namespaces

Planejar a conectividade externa: Você deve usar uma malha de serviços?

Como o operador Kubernetes estabelece conectividade?

Opcional: instale o Istion

Habilitar conectividade externa por meio de domínios externos e zonas de DNS

Observação

Verificar a conectividade entre clusters

Crie um namespace em cada cluster.

Observação

Implemente sample-service.yaml em ambos os clusters do Kubernetes.

Implemente o aplicativo de amostra no CLUSTER_1.

Verifique se o CLUSTER_1 está em execução.

Implemente o aplicativo de amostra no CLUSTER_2.

Verifique se o CLUSTER_2 está em execução.

Verifique se CLUSTER_1 pode se conectar a CLUSTER_2.

Verifique se CLUSTER_2 pode se conectar a CLUSTER_1.

Revise os requisitos para implantar o Ops Manager

Prepare-se para conexões criptografadas por TLS

Observação

Importante

Escolha GitOps ou o plug-in kuberctl MongoDB

Instalar o plug-in kuberctl do MongoDB

Observação

Baixe a versão desejada do pacote do Kubernetes Operator.

Desempacote o pacote do Kubernetes Operator.

Localize o binário do plug-in kubectl mongodb e copie-o para o destino desejado.

Configurar recursos para GitOps

Observação

Crie e aplique recursos RBAC a cada cluster.

Crie e aplique o arquivo ConfigMap.

Configure o segredo kubeconfig para o operador Kubernetes.

Pré-requisitos

Implemente `sample-service.yaml` em ambos os clusters do Kubernetes.

Implemente o aplicativo de amostra no `CLUSTER_1`.

Verifique se o `CLUSTER_1` está em execução.

Implemente o aplicativo de amostra no `CLUSTER_2`.

Verifique se o `CLUSTER_2` está em execução.

Verifique se `CLUSTER_1` pode se conectar a `CLUSTER_2`.

Verifique se `CLUSTER_2` pode se conectar a `CLUSTER_1`.

Localize o binário do plug-in `kubectl mongodb` e copie-o para o destino desejado.

Configure o segredo `kubeconfig` para o operador Kubernetes.