Explore o novo chatbot do Developer Center! O MongoDB AI chatbot pode ser acessado na parte superior da sua navegação para responder a todas as suas perguntas sobre o MongoDB .

Learn why MongoDB was selected as a leader in the 2024 Gartner® Magic Quadrant™
Desenvolvedor do MongoDB
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
Conectoreschevron-right

Implantando o MongoDB em vários clusters do Kubernetes com o MongoDBMulti

Arek Borucki11 min read • Published Jan 13, 2023 • Updated Sep 05, 2023
KubernetesConectores
Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Este artigo faz parte de uma série de três partes sobre a implantação do MongoDB em vários clusters Kubernetes usando os operadores.
Com a versão mais recente do MongoDB Enterprise Kubernetes Operator, você pode implantar recursos do MongoDB em vários clusters Kubernetes! Ao executar seu conjunto de réplicas do MongoDB em diferentes clusters, você pode garantir que sua implantação permaneça disponível mesmo no caso de falha ou interrupção em um deles. A definição de recurso personalizado (CRD) do MongoDB Enterprise Kubernetes Operator, MongoDBMulti, facilita a execução de conjuntos de réplicas do MongoDB em diferentes ambientes Kubernetes e fornece uma abordagem declarativa para distribuir o MongoDB, permitindo que você especifique o estado desejado de sua implantação e permitindo que o operador lide com os detalhes de alcançar esse estado.
⚠️ O suporte para implantações de vários clusters do Kubernetes do MongoDB é um recurso de visualização e ainda não está pronto para uso em produção. O conteúdo deste artigo destina-se a fornecer uma maneira de experimentar esse recurso futuro, mas não deve ser usado na produção, pois ainda podem ocorrer alterações significativas. O suporte para esse recurso durante a versão prévia é direto com a equipe de engenharia e com base nos melhores esforços, portanto, informe-nos se estiver experimentando isso em kubernetes-product@mongodb.com. Sinta-se também à vontade para entrar em contato com qualquer dúvida, ou se isso for algo que possa ser de interesse quando totalmente lançado.

Visão geral do MongoDBMulti CRD

Desenvolvido pelo MongoDB, o MongoDBMulti Custom Resource permite a personalização dos níveis de resiliência com base nas necessidades do aplicativo empresarial.
  • Região única (Multi AZ) consiste em um ou mais clusters Kubernetes onde cada cluster tem nós implantados em diferentes zonas de disponibilidade na mesma região. Esse tipo de implantação protege as instâncias do MongoDB, apoiando seus aplicativos corporativos contra falhas de zona e cluster Kubernetes.
  • A multiregião consiste em um ou mais clusters Kubernetes nos quais você implanta cada cluster em uma região diferente e, em cada região, implanta nós de cluster em diferentes zonas de disponibilidade. Isso dá a resiliência do seu banco de dados contra a perda de um Kubernetes, de uma zona ou de uma região de cloud inteira.
Ao aproveitar os recursos nativos do Kubernetes, o MongoDB Enterprise Kubernetes Operator executa as seguintes tarefas para implantar e operar um conjunto de réplicas do MongoDB de vários clusters:
  • Cria os recursos necessários, como Configmaps, segredos, objetos de serviço e objetos StatefulSet, em cada cluster de membros. Esses recursos estão alinhados com o número de membros do conjunto de réplicas no cluster MongoDB, garantindo que o cluster esteja configurado corretamente e possa funcionar.
  • Identifica os clusters em que o conjunto de réplicas do MongoDB deve ser implantado usando a especificação de recurso personalizado MongoDBMulti correspondente. Em seguida, ele implanta o conjunto de réplicas nos clusters identificados.
  • Observa a criação da especificação do recurso personalizado MongoDBMulti no cluster central.
  • Usa um arquivo kubeconfig montado para se comunicar com clusters de membros. Isso permite ao operador acessar as informações e recursos necessários nos clusters de membros para gerenciar e configurar adequadamente o cluster MongoDB.
  • Monitora eventos relacionados ao CentralCluster e ao MemberCluster para confirmar se a implantação de vários clusters Kubernetes está no estado desejado.
Você deve começar construindo um cluster central. Esse cluster central hospedará a especificação do Kubernetes Operator, MongoDBMulti Custom Resource e atuará como o plano de controle para a implantação de vários clusters. Se você implantar o Ops Manager com o Kubernetes Operator, o cluster central também poderá hospedar o Ops Manager.
Uma arquitetura de alto nível de um sistema de vários clusters Kubernetes em regiões e zonas de disponibilidade
Você também precisará de uma malha de serviços. Eu usarei o Istio, mas qualquer service mesh que forneça uma resolução de nome de domínio totalmente qualificada entre pods em clusters deve funcionar .
A comunicação entre os membros do conjunto de réplicas ocorre por meio do service mesh, o que significa que seu conjunto de réplicas do MongoDB não precisa do cluster central para funcionar. Lembre-se de que, se o cluster central ficar inativo, você não poderá usar o Operador Kubernetes para modificar seu sistema até recuperar o acesso a esse cluster.  

Como usar o CRD do MongoDBMulti

Tudo bem, vamos começar a usar o operador e construir algo! Para este tutorial, precisaremos das seguintes ferramentas: 
Precisamos configurar um cluster mestre do Kubernetes para hospedar o MongoDB Enterprise Multi-Cluster Kubernetes Operator e o Ops Manager. Você precisará criar um cluster do GKE Kubernetes seguindo as instruções na parte 1 desta série. Em seguida, devemos instalar o MongoDB Multi-Cluster Kubernetes Operator no namespacemongodb, junto com os CRDs necessários. Isso nos permitirá utilizar o operador para gerenciar e operar efetivamente nosso conjunto de réplicas de vários clusters do MongoDB. Para obter instruções sobre como fazer isso, consulte a seção relevante da Parte 1. Além disso, precisaremos instalar o Ops Manager, conforme descrito na parte 2 desta série.

Criando os clusters

Após a criação e configuração do cluster principal, precisamos de três clusters GKE adicionais, distribuídos em três regiões diferentes: us-west2, us-central1e us-east1. Esses clusters hospedarão membros do conjunto de réplicas MongoDB.
1CLUSTER_NAMES=(mdb-cluster-1 mdb-cluster-2 mdb-cluster-3)
2ZONES=(us-west2-a us-central1-a us-east1-b)
3
4for ((i=0; i<${#CLUSTER_NAMES[@]:0:1}; i++)); do
5 gcloud container clusters create "${CLUSTER_NAMES[$i]}" \
6 --zone "${ZONES[$i]}" \
7 --machine-type n2-standard-2 --cluster-version="${K8S_VERSION}" \
8 --disk-type=pd-standard --num-nodes 1
9done
Os clusters foram criados e precisamos obter as credenciais para eles.
1for ((i=0; i<${#CLUSTER_NAMES[@]:0:1}; i++)); do
2 gcloud container clusters get-credentials "${CLUSTER_NAMES[$i]}" \
3 --zone "${ZONES[$i]}"
4done
Depois de criar com sucesso os clusters do Kubernetes master e do conjunto de réplicas do MongoDB, instalar o Ops Manager e todos os softwares necessários, podemos verificá-los usando [kubectx](https://github.com/ahmetb/kubectx).
1kubectx
Você deverá ver todos os seus clusters do Kubernetes listados aqui. Certifique-se de que você tenha apenas os clusters que acabou de criar e remova todos os outros clusters desnecessários usando kubectx -d <cluster_name> para que o próximo script funcione.
1gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2
2gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3
3gke_lustrous-spirit-371620_us-south1-a_master-operator
4gke_lustrous-spirit-371620_us-west2-a_mdb-cluster-1
Precisamos criar as variáveis necessárias: MASTER para um cluster mestre do Kubernetes e MDB_1, MDB_2e MDB_3 para clusters que hospedarão membros do conjunto de réplicas do MongoDB. Observação importante: essas variáveis devem conter os nomes completos dos clusters Kubernetes.
1KUBECTX_OUTPUT=($(kubectx))
2CLUSTER_NUMBER=0
3for context in "${KUBECTX_OUTPUT[@]}"; do
4 if [[ $context == *"master"* ]]; then
5 MASTER="$context"
6 else
7 CLUSTER_NUMBER=$((CLUSTER_NUMBER+1))
8 eval "MDB_$CLUSTER_NUMBER=$context"
9 fi
10done
Seus clusters agora estão configurados e prontos para hospedar o MongoDB Kubernetes Operator.

Instalando o Istio

Instale o Istipo (estou usando v 1.16.1) em um modo multi-primary em redes diferentes, usando o scriptinstall_istio_separate_network . Para saber mais sobre isso, consulte a documentação doMulticluster Istion. Preparei um código que baixa e atualiza as variáveis de scriptinstall_istio_separate_network.sh para as atualmente necessárias, como os nomes de cluster completos do K8e a versão do Istipo.
1REPO_URL="https://github.com/mongodb/mongodb-enterprise-kubernetes.git"
2SUBDIR_PATH="mongodb-enterprise-kubernetes/tools/multicluster"
3SCRIPT_NAME="install_istio_separate_network.sh"
4ISTIO_VERSION="1.16.1"
5git clone "$REPO_URL"
6for ((i = 1; i <= ${#CLUSTER_NAMES[@]}; i++)); do
7 eval mdb="\$MDB_${i}"
8 eval k8s="CTX_CLUSTER${i}"
9 sed -i'' -e "s/export ${k8s}=.*/export CTX_CLUSTER${i}=${mdb}/" "$SUBDIR_PATH/$SCRIPT_NAME"
10done
11sed -i'' -e "s/export VERSION=.*/export VERSION=${ISTIO_VERSION}/" "$SUBDIR_PATH/$SCRIPT_NAME"
Instale o Isthio em um modo multi-primary em diferentes clusters do Kubernetes por meio do comando a seguir.
1yes | "$SUBDIR_PATH/$SCRIPT_NAME"
Execute a ferramenta de criação de kubeconfig de vários clusters. Por padrão, o Kubernetes Operator tem como escopo o namespacemongodb, embora ele também possa ser instalado em um namespace diferente. Navegue até o diretório onde você clonou o repositório do Kubernetes Operator em uma etapa anterior e execute a ferramenta. Acesse a documentação daCLI de vários clusters para saber mais sobre multi cluster cli.
1CLUSTERS=$MDB_1,$MDB_2,$MDB_3
2cd "$SUBDIR_PATH"
3go run main.go setup \
4 -central-cluster="${MASTER}" \
5 -member-clusters="${CLUSTERS}" \
6 -member-cluster-namespace="mongodb" \
7 -central-cluster-namespace="mongodb"

Verificando configurações do cluster

Vamos verificar as configurações que fizemos até agora. Mudarei o contexto para o cluster n.º2.
1kubectx $MDB_2
Você deverá ver algo assim em seu terminal.
1Switched to context "gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2"
Podemos ver os namespacesistio-system e mongodb criados pelos scripts
1kubectl get ns
2
3NAME              STATUS   AGE
4default           Active   62m
5istio-system      Active   7m45s
6kube-node-lease   Active   62m
7kube-public       Active   62m
8kube-system       Active   62m
9mongodb           Active   41s
e a conta de serviço do operador MongoDB Kubernetes está pronta.
1kubectl -n mongodb get sa
2
3default                                     1         55s
4mongodb-enterprise-operator-multi-cluster   1         52s
Em seguida, execute o seguinte comando nos clusters, especificando o contexto de cada um dos clusters de membros no sistema. O comando adiciona o rótulo istio-injection=enabled' ao namespace 'mongodbem cada cluster de membros. Esse rótuloativa o webhook de injeção do Istipo, que permite que um sidecar seja adicionado a qualquer pod criado nesse namespace.
1CLUSTER_ARRAY=($MDB_1 $MDB_2 $MDB_3)
2for CLUSTER in "${CLUSTER_ARRAY[@]}"; do
3 kubectl label --context=$CLUSTER namespace mongodb istio-injection=enabled
4done

Instalando o operador do Kubernetes de vários clusters do MongoDB

Agora, o operador MongoDB Multi Cluster Kubernetes deve ser instalado no cluster do operador mestre e estar ciente de todos os clusters Kubernetes que fazem parte do Multi Cluster. Esta etapa adicionará o operador Kubernetes de vários clusters a cada um de nossos clusters.
Primeiro, mude o contexto para o cluster mestre.
1kubectx $MASTER
O mongodb-operator-multi-cluster operador precisa ser alertado sobre os clusters Kubernetes recém-criados, atualizando a configuração do operador por meio do Helm. Este procedimento foi testado com a mongodb-operator-multi-cluster versão 1.16.3.
1helm upgrade --install mongodb-enterprise-operator-multi-cluster mongodb/enterprise-operator \
2 --namespace mongodb \
3 --set namespace=mongodb \
4 --version="${HELM_CHART_VERSION}" \
5 --set operator.name=mongodb-enterprise-operator-multi-cluster \
6 --set "multiCluster.clusters={${CLUSTERS}}" \
7 --set operator.createOperatorServiceAccount=false \
8 --set multiCluster.performFailover=false
Verifique se o pod de vários clusters do MongoDB Enterprise Operator no cluster mestre está em execução.
1kubectl -n mongodb get pods
1NAME                                                   READY STATUS    RESTARTS   AGE
2mongodb-enterprise-operator-multi-cluster-688d48dfc6    1/1  Running 0  8s
Agora é hora de vincular todos esses clusters usando o MongoDB Multi CRD. A API do Kubernetes já foi estendida com um objeto específico do MongoDB - mongodbmulti.
1kubectl -n mongodb get crd | grep multi
1mongodbmulti.mongodb.com                         
Você também deve revisar os registros de instalação e garantir que não haja problemas ou erros.
1POD=$(kubectl -n mongodb get po|grep operator|awk '{ print $1 }')
2kubectl -n mongodb logs -f po/$POD
Estamos quase prontos para criar um conjunto de réplicas do Kubernetes do MongoDB com vários clusters! Precisamos configurar as contas de serviço necessárias para cada cluster membro.
1for CLUSTER in "${CLUSTER_ARRAY[@]}"; do
2 helm template --show-only templates/database-roles.yaml mongodb/enterprise-operator --namespace "mongodb" | kubectl apply -f - --context=${CLUSTER} --namespace mongodb;
3done
Além disso, vamos gerar chaves de API do Ops Manager e adicionar nossos endereços IP à lista de acesso do Ops Manager. Obtenha o URL do Ops Manager (criado conforme descrito na parte 2). Certifique-se de mudar o contexto para mestre. 
1kubectx $MASTER
2URL=http://$(kubectl -n "${NAMESPACE}" get svc ops-manager-svc-ext -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}')
3echo $URL
Faça login no Ops Manager e gere chaves de API públicas e privadas. Ao criar chaves de API, não se lembre de adicionar seu endereço IP atual à lista de acesso da API.
Para fazer isso, faça login no MongoDB Ops Manager e acesse ops-manager-db organização.
O Ops Manager fornece uma hierarquia de organizações e projetos para ajudá-lo a gerenciar suas implantações do Ops Manager. Na hierarquia de organizações e projetos, uma organização pode conter vários projetos.
Clique em Access Manager no lado esquerdo e escolha Acesso à organização e depois escolha Create API KEY  no canto superior direito.
Crie uma chave pública e uma chave privada.
A chave deve ter um nome (eu uso mongodb-blog) e as permissões devem ser definidas como Organization Owner .
Definir direitos do proprietário da organização
Ao clicar em Avançar, você verá seu Public Keye Private Key. Copie esses valores e salve-os — você não poderá ver a chave privada novamente. Além disso, adicione seu endereço IP atual à lista de acesso à API.
Para conceder acesso programático a uma organização ou projeto usando somente a API, você pode criar um par de chaves de API.
Obtenha as chaves públicas e privadas geradas pelo criador de chaves API e cole-as no segredo do Kubernetes.
1kubectl apply -f - <<EOF
2apiVersion: v1
3kind: Secret
4metadata:
5 name: multi-organization-secret
6 namespace: mongodb
7stringData:
8 publicKey: <PUBLIC KEY>
9 privateKey: <PRIVATE_KEY>
10EOF
Você também precisa de um  Organization ID. Você pode ver o ID da organização clicando no ícone de engrenagem no canto superior esquerdo.
Obtenha o ID da organização
Copie o Organization ID e cole no mapa de configuração do Kubernetes abaixo.
1kubectl apply -f - <<EOF
2apiVersion: v1
3kind: ConfigMap
4metadata:
5 name: multi-project
6 namespace: mongodb
7data:
8 baseUrl: "${URL}"
9 orgId: <YOUR_ORG_ID>
10EOF
A instância do Ops Manager foi configurada e você tem tudo o que é necessário para adicionar o MongoDBMultiCRD ao seu cluster.

Usando o MongoDBMultiCRD

Por fim, podemos criar um conjunto de réplicas do MongoDB distribuído em três clusters Kubernetes em regiões diferentes. Atualizei o manifesto do Kubernetes com os nomes completos dos clusters do Kubernetes. Vamos aplicá-lo agora!
1MDB_VERSION=6.0.2-ent
2kubectl apply -f - <<EOF
3apiVersion: mongodb.com/v1
4kind: MongoDBMulti
5metadata:
6 name: multi-replica-set
7 namespace: mongodb
8spec:
9 version: "${MDB_VERSION}"
10 type: ReplicaSet
11 persistent: true
12 duplicateServiceObjects: true
13 credentials: multi-organization-secret
14 opsManager:
15 configMapRef:
16 name: multi-project
17 clusterSpecList:
18 clusterSpecs:
19 - clusterName: ${MDB_1}
20 members: 1
21 - clusterName: ${MDB_2}
22 members: 1
23 - clusterName: ${MDB_3}
24 members: 1
25EOF
Devemos verificar os logs do pod do operador. Há a possibilidade de termos que atualizar a lista de acesso à API do Ops Manager com endereços IP adicionais. Crie uma variável com o pod do operador.
1POD=$(kubectl -n mongodb get po|grep operator|awk '{ print $1 }')
Verifique se o pod do operador tem permissão para acessar a REST API do MongoDB Ops Manager.
1kubectl -n mongodb logs -f po/$POD|grep IP_ADDRESS_NOT_ON_ACCESS_LIST
Se recebermos uma saída de erro semelhante à seguinte, devemos adicionar o endereço IP adicional exibido à lista de acesso da API do Ops Manager, como fizemos na etapa anterior.
Status: 403 (Forbidden), ErrorCode: IP_ADDRESS_NOT_ON_ACCESS_LIST, Detail: IP address 10.206.15.226 is not allowed to access this resource.","MultiReplicaSet":"mongodb/multi-cluster"
Após alguns minutos, devemos ter nosso multi cluster pronto para uso! Podemos verificar isso exibindo o objeto 'MongoDB multi'.
1kubectl -n mongodb get mdbm
1NAME            PHASE     AGE
2multi-cluster   Running   4m25s
Podemos verificar se o conjunto de réplicas do MongoDB está sendo executado em diferentes ambientes Kubernetes em diferentes regiões! O operador executou todas as configurações e alterações necessárias para atingir o estado desejado do multicluster. O operador também monitorará nosso multicluster e responderá em caso de problema.
1for CLUSTER in "${CLUSTER_ARRAY[@]}"; do
2  kubectl -n mongodb --context=${CLUSTER}  get pods
3done
Saída do loop:
1gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2
2NAME                READY   STATUS    RESTARTS      AGE
3multi-cluster-0-0   2/2     Running   1 (13m ago)   13m
4
5gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3
6NAME                READY   STATUS    RESTARTS      AGE
7multi-cluster-1-0   2/2     Running   1 (12m ago)   12m
8
9gke_lustrous-spirit-371620_us-west2-a_mdb-cluster-1
10NAME                READY   STATUS    RESTARTS      AGE
11multi-cluster-2-0   2/2     Running   1 (12m ago)   12m
Também podemos ver que o MongoDB Kubernetes Operator lidou com a parte de armazenamento e criou um StatefulSet e objetos associados.
1for CLUSTER in "${CLUSTER_ARRAY[@]}"; do
2  kubectl -n mongodb --context=${CLUSTER}  get sts
3done
Saída do loop:
1gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2
2NAME              READY   AGE
3multi-cluster-0   1/1     16m
4
5gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3
6NAME              READY   AGE
7multi-cluster-1   1/1     15m
8
9gke_lustrous-spirit-371620_us-west2-a_mdb-cluster-1
10NAME              READY   AGE
11multi-cluster-2   1/1     15m
O conjunto de réplicas de vários clusters também é visível no Ops Manager. O Ops Manager agora será responsável por backup, alertas, monitoramento, atualizações contínuas e automação.
Visualização do sistema Ops Manager Multi-Kubernetes-Cluster no Ops Manager

Solução de problemas básicos

Se algo der errado, você poderá iniciar uma Investigação verificando os registros do MongoDB Kubernetes Operator no cluster mestre. O problema mais comum não é incluir endereços IP na lista de endereços IP para a chave de API. Você pode ver os detalhes do erro encontrando o nome do pod do operador e listando os registros mais recentes.
1POD=$(kubectl -n mongodb get po|grep operator-multi|awk '{ print $1 }'
2kubectl -n mongodb logs -f po/$POD
Você pode usar o comando kubectl para visualizar os registros dos pods do banco de dados. Os principais processos de contêiner seguem continuamente os logs do Automation Agent e do MongoDB e podem ser visualizados usando o seguinte comando:
1kubectl logs $POD -n mongodb
Uma técnica comum para solucionar problemas é usar o ssh para se conectar a um dos container que executam o MongoDB. Uma vez conectado, você pode usar várias ferramentas Linux para visualizar os processos, solucionar problemas e até mesmo verificar as conexões de shell do MongoDB (o que pode ser útil no diagnóstico de problemas de rede).
1kubectl exec -it $POD -n mongodb -- /bin/bash

Conclusão

A versão mais recente do MongoDB Enterprise Kubernetes Operator permite que os usuários implementem recursos do MongoDB em vários clusters Kubernetes, melhorando a confiabilidade e reduzindo o tempo de inatividade. Desenvolvido pelo MongoDB, o MongoDBMulti Custom Resource definition (CRD) facilita a execução de conjuntos de réplicas do MongoDB em vários ambientes Kubernetes e fornece uma abordagem declarativa para a implantação do MongoDB, permitindo que os usuários especifiquem o estado desejado de sua implantação e permitindo que o operador lide com os detalhes.
Em combinação com o Ops Manager, um cluster de várias regiões cria um sistema de banco de dados altamente disponível com ferramentas de classe empresarial para backup, monitoramento, alertas, upgrades e configuração.
À medida que o Kubernetes se torna cada vez mais popular, é importante começar a aproveitar seus recursos em sua organização. Você deseja manter-se atualizado sobre os últimos desenvolvimentos do MongoDB no Kubernetes? Não deixe de conferir o MongoDB Community para ver as discussões e recursos mais recentes.

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
{Parte de uma série
Implantação do MongoDB em vários clusters do Kubernetes
Mais nesta série
Relacionado
Tutorial

Ative seu MongoDB e BigQuery usando procedimentos armazenados do BigQuery Spark


Aug 12, 2024 | 5 min read
Podcast

Pesquisa do Podcast do MongoDB com a equipe de conectores e tradutores


Sep 11, 2024 | 16 min
Tutorial

Como começar a usar o MongoDB Atlas Stream Processing e o provedor HashiCorp Terraform MongoDB Atlas


May 20, 2024 | 5 min read
Tutorial

Implementando o MongoDB Enterprise Kubernetes Operator no Google Cloud


Jan 13, 2023 | 6 min read
Sumário