Implantando o MongoDB em vários clusters do Kubernetes com o MongoDBMulti
Avalie esse Tutorial
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.
- Implantando o MongoDB em vários clusters do Kubernetes com o MongoDBMulti
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.
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.
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.
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 namespace
mongodb
, 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.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-central1
e us-east1
. Esses clusters hospedarão membros do conjunto de réplicas MongoDB.1 CLUSTER_NAMES=(mdb-cluster-1 mdb-cluster-2 mdb-cluster-3) 2 ZONES=(us-west2-a us-central1-a us-east1-b) 3 4 for ((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 9 done
Os clusters foram criados e precisamos obter as credenciais para eles.
1 for ((i=0; i<${#CLUSTER_NAMES[@]:0:1}; i++)); do 2 gcloud container clusters get-credentials "${CLUSTER_NAMES[$i]}" \ 3 --zone "${ZONES[$i]}" 4 done
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)
.1 kubectx
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.1 gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2 2 gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3 3 gke_lustrous-spirit-371620_us-south1-a_master-operator 4 gke_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_2
e 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.1 KUBECTX_OUTPUT=($(kubectx)) 2 CLUSTER_NUMBER=0 3 for 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 10 done
Seus clusters agora estão configurados e prontos para hospedar o MongoDB Kubernetes Operator.
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 script
install_istio_separate_network.sh
para as atualmente necessárias, como os nomes de cluster completos do K8e a versão do Istipo.1 REPO_URL="https://github.com/mongodb/mongodb-enterprise-kubernetes.git" 2 SUBDIR_PATH="mongodb-enterprise-kubernetes/tools/multicluster" 3 SCRIPT_NAME="install_istio_separate_network.sh" 4 ISTIO_VERSION="1.16.1" 5 git clone "$REPO_URL" 6 for ((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" 10 done 11 sed -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.
1 yes | "$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 namespace
mongodb
, 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
.1 CLUSTERS=$MDB_1,$MDB_2,$MDB_3 2 cd "$SUBDIR_PATH" 3 go run main.go setup \ 4 -central-cluster="${MASTER}" \ 5 -member-clusters="${CLUSTERS}" \ 6 -member-cluster-namespace="mongodb" \ 7 -central-cluster-namespace="mongodb"
Vamos verificar as configurações que fizemos até agora. Mudarei o contexto para o cluster n.º2.
1 kubectx $MDB_2
Você deverá ver algo assim em seu terminal.
1 Switched to context "gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2"
Podemos ver os namespaces
istio-system
e mongodb
criados pelos scripts1 kubectl get ns 2 3 NAME STATUS AGE 4 default Active 62m 5 istio-system Active 7m45s 6 kube-node-lease Active 62m 7 kube-public Active 62m 8 kube-system Active 62m 9 mongodb Active 41s
e a conta de serviço do operador MongoDB Kubernetes está pronta.
1 kubectl -n mongodb get sa 2 3 default 1 55s 4 mongodb-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 'mongodb
em 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.1 CLUSTER_ARRAY=($MDB_1 $MDB_2 $MDB_3) 2 for CLUSTER in "${CLUSTER_ARRAY[@]}"; do 3 kubectl label --context=$CLUSTER namespace mongodb istio-injection=enabled 4 done
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.
1 kubectx $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
.1 helm 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.
1 kubectl -n mongodb get pods
1 NAME READY STATUS RESTARTS AGE 2 mongodb-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
.1 kubectl -n mongodb get crd | grep multi
1 mongodbmulti.mongodb.com
Você também deve revisar os registros de instalação e garantir que não haja problemas ou erros.
1 POD=$(kubectl -n mongodb get po|grep operator|awk '{ print $1 }') 2 kubectl -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.
1 for 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; 3 done
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.
1 kubectx $MASTER 2 URL=http://$(kubectl -n "${NAMESPACE}" get svc ops-manager-svc-ext -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}') 3 echo $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.Clique em
Access Manager
no lado esquerdo e escolha Acesso à organização e depois escolha Create API KEY
no canto superior direito.A chave deve ter um nome (eu uso
mongodb-blog
) e as permissões devem ser definidas como Organization Owner
.Ao clicar em Avançar, você verá seu
Public Key
e 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.Obtenha as chaves públicas e privadas geradas pelo criador de chaves API e cole-as no segredo do Kubernetes.
1 kubectl apply -f - <<EOF 2 apiVersion: v1 3 kind: Secret 4 metadata: 5 name: multi-organization-secret 6 namespace: mongodb 7 stringData: 8 publicKey: <PUBLIC KEY> 9 privateKey: <PRIVATE_KEY> 10 EOF
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.Copie o
Organization ID
e cole no mapa de configuração do Kubernetes abaixo.1 kubectl apply -f - <<EOF 2 apiVersion: v1 3 kind: ConfigMap 4 metadata: 5 name: multi-project 6 namespace: mongodb 7 data: 8 baseUrl: "${URL}" 9 orgId: <YOUR_ORG_ID> 10 EOF
A instância do Ops Manager foi configurada e você tem tudo o que é necessário para adicionar o MongoDBMultiCRD ao seu cluster.
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!
1 MDB_VERSION=6.0.2-ent 2 kubectl apply -f - <<EOF 3 apiVersion: mongodb.com/v1 4 kind: MongoDBMulti 5 metadata: 6 name: multi-replica-set 7 namespace: mongodb 8 spec: 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 25 EOF
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.
1 POD=$(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.
1 kubectl -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'.
1 kubectl -n mongodb get mdbm
1 NAME PHASE AGE 2 multi-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.
1 for CLUSTER in "${CLUSTER_ARRAY[@]}"; do 2 kubectl -n mongodb --context=${CLUSTER} get pods 3 done
Saída do loop:
1 gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2 2 NAME READY STATUS RESTARTS AGE 3 multi-cluster-0-0 2/2 Running 1 (13m ago) 13m 4 5 gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3 6 NAME READY STATUS RESTARTS AGE 7 multi-cluster-1-0 2/2 Running 1 (12m ago) 12m 8 9 gke_lustrous-spirit-371620_us-west2-a_mdb-cluster-1 10 NAME READY STATUS RESTARTS AGE 11 multi-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.
1 for CLUSTER in "${CLUSTER_ARRAY[@]}"; do 2 kubectl -n mongodb --context=${CLUSTER} get sts 3 done
Saída do loop:
1 gke_lustrous-spirit-371620_us-central1-a_mdb-cluster-2 2 NAME READY AGE 3 multi-cluster-0 1/1 16m 4 5 gke_lustrous-spirit-371620_us-east1-b_mdb-cluster-3 6 NAME READY AGE 7 multi-cluster-1 1/1 15m 8 9 gke_lustrous-spirit-371620_us-west2-a_mdb-cluster-1 10 NAME READY AGE 11 multi-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.
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.
1 POD=$(kubectl -n mongodb get po|grep operator-multi|awk '{ print $1 }') 2 kubectl -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:
1 kubectl 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).
1 kubectl exec -it $POD -n mongodb -- /bin/bash
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.
{Parte de uma série