Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/

Implante recursos MongoDB Ops Manager em vários clusters Kubernetes

Nesta página

  • Visão geral
  • Pré-requisitos
  • Procedimento

Para tornar seu MongoDB Ops Manager e o sistema de banco de dados de aplicativos resilientes a falhas de data center ou zona inteiras, implemente o aplicativo MongoDB Ops Manager e o banco de dados de aplicativos em vários clusters do Kubernetes .

Para saber mais sobre a arquitetura, a rede, as limitações e o desempenho das implantações de clusters multi-Kubernetes para os recursos MongoDB Ops Manager , consulte:

  • Arquitetura MongoDB Ops Manager de vários clusters

  • Limitações

  • Diferenças entre sistemas do MongoDB Ops Manager de um e vários clusters

  • Diagrama de arquitetura

  • Redes, Balanceador de carga, Malha de serviço

  • Desempenho

Ao implementar o Aplicativo MongoDB Ops Manager e o Banco de Dados de Aplicativo utilizando o procedimento nesta seção, você:

  1. Usar GKE (Google Kubernetes Engine) e Ístolo Service Mesh como ferramentas que ajudam a demonstrar aKubernetes implantação de clusters .

  2. Instale o Operador Kubernetes em um dos clusters Kubernetes do membro conhecido como cluster do operador. O cluster de operador atua como um Hub no padrão "Hub and Spoke" usado pelo Operador Kubernetes para gerenciar implantações em vários clusters Kubernetes.

  3. Implemente o cluster do operador no $OPERATOR_NAMESPACE e configure este cluster para assistir $NAMESPACE e gerenciar todos os clusters de membros do Kubernetes.

  4. Implemente o Banco de Dados de Aplicativo e o Aplicativo de Ops Manager em um cluster Kubernetes de nó único para demonstrar similaridade de um sistema de vários clusters com um sistema de cluster único. Um único sistema de cluster com spec.topology e spec.applicationDatabase.topology definido como MultiCluster prepara o sistema para adicionar mais clusters Kubernetes a ele.

  5. Implemente um conjunto de réplicas adicional do aplicativo de banco de dados no segundo cluster Kubernetes para melhorar a resiliência do banco de dados de aplicativos. Você também implementa uma instância adicional do aplicativo MongoDB Ops Manager no cluster Kubernetes do segundo membro.

  6. Crie certificados válidos para criptografiaTLS e estabeleça conexões criptografadas TLSde e para o Aplicativo MongoDB Ops Manager e entre os membros do conjunto de réplicas do Banco de Dados do Aplicativo. Ao executar HTTPS, o MongoDB Ops Manager é executado na porta 8443 por padrão.

  7. Habilite o backup usando o armazenamento compatível com S3e implemente o Backup Daemon no cluster Kubernetes de terceiro membro. Para simplificar a configuração de buckets de armazenamento compatíveis com S ,3 você implementa o Operador MinIO. Você habilita o Backup Daemon somente em um cluster de membros em seu sistema. No entanto, você também pode configurar outros clusters de membros para hospedar os recursos do Backup Daemon. Somente backups S3 são suportados em sistemas do MongoDB Ops Manager de vários clusters.

Antes de iniciar a implementação, instale as seguintes ferramentas necessárias:

Instalar o CLI do gcloud e autorizar nele:

gcloud auth login

O plugin kubectl mongodb automatiza a configuração dos clusters Kubernetes. Isso permite que o Operador Kubernetes implemente recursos, roles necessários e serviços para contas para o Aplicativo Ops Manager, Banco de Dados de Aplicativo e recursos MongoDB nesses clusters.

Para instalar o plug-in kubectl mongodb :

1

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

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

Use um dos seguintes pacotes:

  • kubectl-mongodb_{{ .Version }}_darwin_amd64.tar.gz

  • kubectl-mongodb_{{ .Version }}_darwin_arm64.tar.gz

  • kubectl-mongodb_{{ .Version }}_linux_amd64.tar.gz

  • kubectl-mongodb_{{ .Version }}_linux_arm64.tar.gz

2

Desempacote o pacote, como no exemplo a seguir:

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

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.

Clone o repositório do MongoDB Enterprise Kubernetes Operator, altere para o mongodb-enterprise-kubernetes diretório e confira a versão atual.

git clone https://github.com/mongodb/mongodb-enterprise-kubernetes.git
cd mongodb-enterprise-kubernetes
git checkout master
cd public/samples/ops-manager-multi-cluster

Importante

Algumas etapas deste guia funcionam somente se você executá-las a partir do diretório public/samples/ops-manager-multi-cluster .

Todas as etapas deste guia referenciam as variáveis de ambiente definidas no env_variables.sh.

1export MDB_GKE_PROJECT="### Set your GKE project name here ###"
2
3export NAMESPACE="mongodb"
4export OPERATOR_NAMESPACE="mongodb-operator"
5
6# comma-separated key=value pairs
7# export OPERATOR_ADDITIONAL_HELM_VALUES=""
8
9# Adjust the values for each Kubernetes cluster in your deployment.
10# The deployment script references the following variables to get values for each cluster.
11export K8S_CLUSTER_0="k8s-mdb-0"
12export K8S_CLUSTER_0_ZONE="europe-central2-a"
13export K8S_CLUSTER_0_NUMBER_OF_NODES=3
14export K8S_CLUSTER_0_MACHINE_TYPE="e2-standard-4"
15export K8S_CLUSTER_0_CONTEXT_NAME="gke_${MDB_GKE_PROJECT}_${K8S_CLUSTER_0_ZONE}_${K8S_CLUSTER_0}"
16
17export K8S_CLUSTER_1="k8s-mdb-1"
18export K8S_CLUSTER_1_ZONE="europe-central2-b"
19export K8S_CLUSTER_1_NUMBER_OF_NODES=3
20export K8S_CLUSTER_1_MACHINE_TYPE="e2-standard-4"
21export K8S_CLUSTER_1_CONTEXT_NAME="gke_${MDB_GKE_PROJECT}_${K8S_CLUSTER_1_ZONE}_${K8S_CLUSTER_1}"
22
23export K8S_CLUSTER_2="k8s-mdb-2"
24export K8S_CLUSTER_2_ZONE="europe-central2-c"
25export K8S_CLUSTER_2_NUMBER_OF_NODES=1
26export K8S_CLUSTER_2_MACHINE_TYPE="e2-standard-4"
27export K8S_CLUSTER_2_CONTEXT_NAME="gke_${MDB_GKE_PROJECT}_${K8S_CLUSTER_2_ZONE}_${K8S_CLUSTER_2}"
28
29# Comment out the following line so that the script does not create preemptible nodes.
30# DO NOT USE preemptible nodes in production.
31export GKE_SPOT_INSTANCES_SWITCH="--preemptible"
32
33export S3_OPLOG_BUCKET_NAME=s3-oplog-store
34export S3_SNAPSHOT_BUCKET_NAME=s3-snapshot-store
35
36# minio defaults
37export S3_ENDPOINT="minio.tenant-tiny.svc.cluster.local"
38export S3_ACCESS_KEY="console"
39export S3_SECRET_KEY="console123"
40
41export OFFICIAL_OPERATOR_HELM_CHART="mongodb/enterprise-operator"
42export OPERATOR_HELM_CHART="${OFFICIAL_OPERATOR_HELM_CHART}"
43
44# (Optional) Change the following setting when using the external URL.
45# This env variable is used in OpenSSL configuration to generate
46# server certificates for Ops Manager Application.
47export OPS_MANAGER_EXTERNAL_DOMAIN="om-svc.${NAMESPACE}.svc.cluster.local"
48
49export OPS_MANAGER_VERSION="7.0.4"
50export APPDB_VERSION="7.0.9-ubi8"

Ajuste as configurações no exemplo anterior para suas necessidades, conforme instruído nos comentários, e insira-as em seu shell da seguinte maneira:

source env_variables.sh

Importante

Cada vez que você atualizar o env_variables.sh, execute o source env_variables.sh para garantir que os scripts nesta seção usem variáveis atualizadas.

Este procedimento se aplica à implantação de uma instância MongoDB Ops Manager em vários clusters Kubernetes .

1

Você pode pular esta etapa se já tiver instalado e configurado seus próprios clusters Kubernetes com uma malha de serviço.

  1. Criar três GKE (Google Kubernetes Engine) clusters:

    1gcloud container clusters create "${K8S_CLUSTER_0}" \
    2 --zone="${K8S_CLUSTER_0_ZONE}" \
    3 --num-nodes="${K8S_CLUSTER_0_NUMBER_OF_NODES}" \
    4 --machine-type "${K8S_CLUSTER_0_MACHINE_TYPE}" \
    5 ${GKE_SPOT_INSTANCES_SWITCH:-""}
    1gcloud container clusters create "${K8S_CLUSTER_1}" \
    2 --zone="${K8S_CLUSTER_1_ZONE}" \
    3 --num-nodes="${K8S_CLUSTER_1_NUMBER_OF_NODES}" \
    4 --machine-type "${K8S_CLUSTER_1_MACHINE_TYPE}" \
    5 ${GKE_SPOT_INSTANCES_SWITCH:-""}
    1gcloud container clusters create "${K8S_CLUSTER_2}" \
    2 --zone="${K8S_CLUSTER_2_ZONE}" \
    3 --num-nodes="${K8S_CLUSTER_2_NUMBER_OF_NODES}" \
    4 --machine-type "${K8S_CLUSTER_2_MACHINE_TYPE}" \
    5 ${GKE_SPOT_INSTANCES_SWITCH:-""}
  2. Defina seu projeto gcloud padrão:

    1gcloud config set project "${MDB_GKE_PROJECT}"
  3. Obtenha credenciais e salve contextos no arquivo kubeconfig atual. Por padrão, este arquivo está localizado no diretório ~/.kube/config e referenciado pela variável de ambiente $KUBECONFIG .

    1gcloud container clusters get-credentials "${K8S_CLUSTER_0}" --zone="${K8S_CLUSTER_0_ZONE}"
    2gcloud container clusters get-credentials "${K8S_CLUSTER_1}" --zone="${K8S_CLUSTER_1_ZONE}"
    3gcloud container clusters get-credentials "${K8S_CLUSTER_2}" --zone="${K8S_CLUSTER_2_ZONE}"

    Todos os comandos kubectl referenciam estes contextos utilizando as seguintes variáveis:

    • $K8S_CLUSTER_0_CONTEXT_NAME

    • $K8S_CLUSTER_1_CONTEXT_NAME

    • $K8S_CLUSTER_2_CONTEXT_NAME

  4. Verifique se kubectl tem acesso aos clusters Kubernetes:

    1echo "Nodes in cluster ${K8S_CLUSTER_0_CONTEXT_NAME}"
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" get nodes
    3echo; echo "Nodes in cluster ${K8S_CLUSTER_1_CONTEXT_NAME}"
    4kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" get nodes
    5echo; echo "Nodes in cluster ${K8S_CLUSTER_2_CONTEXT_NAME}"
    6kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" get nodes
  5. Instalar o Sistema malha de serviços para permitir resolução de DNS entre clusters e conectividade de rede entre clusters Kubernetes:

    1CTX_CLUSTER1=${K8S_CLUSTER_0_CONTEXT_NAME} \
    2CTX_CLUSTER2=${K8S_CLUSTER_1_CONTEXT_NAME} \
    3CTX_CLUSTER3=${K8S_CLUSTER_2_CONTEXT_NAME} \
    4ISTIO_VERSION="1.20.2" \
    5../multi-cluster/install_istio_separate_network.sh
2

Observação

Para habilitar a injeção de sidecar no Istion, os comandos a seguir adicionam os istio-injection=enabled rótulos aos $OPERATOR_NAMESPACE mongodb namespaces e em cada cluster de membros. Se você usar outra interface de serviço, configure-a para lidar com o tráfego de rede nos namespaces criados.

  • Crie um namespace separado, mongodb-operator, referenciado pela variável de ambiente $OPERATOR_NAMESPACE para o sistema do Kubernetes Operator.

  • Crie o mesmo $OPERATOR_NAMESPACE em cada cluster Kubernetes de membros. Isso é necessário para que o plug- in kubectl MongoDB possa criar uma conta de serviço para o Kubernetes Operator em cada cluster de membros. O Operador Kubernetes utiliza estas contas de serviço no cluster do operador para executar operações em cada cluster de membros.

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" create namespace "${OPERATOR_NAMESPACE}"
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" label namespace "${OPERATOR_NAMESPACE}" istio-injection=enabled --overwrite
    3
    4kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" create namespace "${OPERATOR_NAMESPACE}"
    5kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" label namespace "${OPERATOR_NAMESPACE}" istio-injection=enabled --overwrite
    6
    7kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" create namespace "${OPERATOR_NAMESPACE}"
    8kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" label namespace "${OPERATOR_NAMESPACE}" istio-injection=enabled --overwrite
  • Em cada cluster de membros, incluindo o cluster de membros que serve como cluster de operador, crie outro namespace separado, mongodb. O Kubernetes Operator usa este namespace para recursos e componentes do MongoDB Ops Manager .

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" create namespace "${NAMESPACE}"
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" label namespace "${NAMESPACE}" istio-injection=enabled --overwrite
    3
    4kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" create namespace "${NAMESPACE}"
    5kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" label namespace "${NAMESPACE}" istio-injection=enabled --overwrite
    6
    7kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" create namespace "${NAMESPACE}"
    8kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" label namespace "${NAMESPACE}" istio-injection=enabled --overwrite
3

Esta etapa é opcional se você usar os Atlas Charts do Quay registro.

1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${OPERATOR_NAMESPACE}" create secret generic "image-registries-secret" \
2 --from-file=.dockerconfigjson="${HOME}/.docker/config.json" --type=kubernetes.io/dockerconfigjson
3kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create secret generic "image-registries-secret" \
4 --from-file=.dockerconfigjson="${HOME}/.docker/config.json" --type=kubernetes.io/dockerconfigjson
5kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" create secret generic "image-registries-secret" \
6 --from-file=.dockerconfigjson="${HOME}/.docker/config.json" --type=kubernetes.io/dockerconfigjson
7kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" create secret generic "image-registries-secret" \
8 --from-file=.dockerconfigjson="${HOME}/.docker/config.json" --type=kubernetes.io/dockerconfigjson
4

Os scripts opcionais a seguir verificam se a interface de serviço está configurada corretamente para resolução e conectividade de DNS entre clusters.

  1. Execute este script no cluster 0:

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2 apiVersion: apps/v1
    3 kind: StatefulSet
    4 metadata:
    5 name: echoserver0
    6 spec:
    7 replicas: 1
    8 selector:
    9 matchLabels:
    10 app: echoserver0
    11 template:
    12 metadata:
    13 labels:
    14 app: echoserver0
    15 spec:
    16 containers:
    17 - image: k8s.gcr.io/echoserver:1.10
    18 imagePullPolicy: Always
    19 name: echoserver0
    20 ports:
    21 - containerPort: 8080
    22EOF
  2. Execute este script no cluster 1:

    1kubectl apply --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2 apiVersion: apps/v1
    3 kind: StatefulSet
    4 metadata:
    5 name: echoserver1
    6 spec:
    7 replicas: 1
    8 selector:
    9 matchLabels:
    10 app: echoserver1
    11 template:
    12 metadata:
    13 labels:
    14 app: echoserver1
    15 spec:
    16 containers:
    17 - image: k8s.gcr.io/echoserver:1.10
    18 imagePullPolicy: Always
    19 name: echoserver1
    20 ports:
    21 - containerPort: 8080
    22EOF
  3. Execute este script no cluster 2:

    1kubectl apply --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2 apiVersion: apps/v1
    3 kind: StatefulSet
    4 metadata:
    5 name: echoserver2
    6 spec:
    7 replicas: 1
    8 selector:
    9 matchLabels:
    10 app: echoserver2
    11 template:
    12 metadata:
    13 labels:
    14 app: echoserver2
    15 spec:
    16 containers:
    17 - image: k8s.gcr.io/echoserver:1.10
    18 imagePullPolicy: Always
    19 name: echoserver2
    20 ports:
    21 - containerPort: 8080
    22EOF
  4. Execute este script para aguardar a criação do StatefulSets:

    1kubectl wait --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" --for=condition=ready pod -l statefulset.kubernetes.io/pod-name=echoserver0-0 --timeout=60s
    2kubectl wait --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" --for=condition=ready pod -l statefulset.kubernetes.io/pod-name=echoserver1-0 --timeout=60s
    3kubectl wait --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" --for=condition=ready pod -l statefulset.kubernetes.io/pod-name=echoserver2-0 --timeout=60s
  5. Criar serviço de Pod no cluster 0:

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver0-0
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 statefulset.kubernetes.io/pod-name: "echoserver0-0"
    13EOF
  6. Criar serviço de Pod no cluster 1:

    1kubectl apply --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver1-0
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 statefulset.kubernetes.io/pod-name: "echoserver1-0"
    13EOF
  7. Criar serviço de Pod no cluster 2:

    1kubectl apply --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver2-0
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 statefulset.kubernetes.io/pod-name: "echoserver2-0"
    13EOF
  8. Criar serviço de round robin no cluster 0:

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 app: echoserver0
    13EOF
  9. Criar serviço de round robin no cluster 1:

    1kubectl apply --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 app: echoserver1
    13EOF
  10. Criar serviço de round robin no cluster 2:

    1kubectl apply --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: v1
    3kind: Service
    4metadata:
    5 name: echoserver
    6spec:
    7 ports:
    8 - port: 8080
    9 targetPort: 8080
    10 protocol: TCP
    11 selector:
    12 app: echoserver2
    13EOF
  11. Verifique o Pod 0 do cluster 1:

    1source_cluster=${K8S_CLUSTER_1_CONTEXT_NAME}
    2target_pod="echoserver0-0"
    3source_pod="echoserver1-0"
    4target_url="http://${target_pod}.${NAMESPACE}.svc.cluster.local:8080"
    5echo "Checking cross-cluster DNS resolution and connectivity from ${source_pod} in ${source_cluster} to ${target_pod}"
    6out=$(kubectl exec --context "${source_cluster}" -n "${NAMESPACE}" "${source_pod}" -- \
    7 /bin/bash -c "curl -v ${target_url}" 2>&1);
    8grep "Hostname: ${target_pod}" &>/dev/null <<< "${out}" && echo "SUCCESS" || (echo "ERROR: ${out}" && return 1)
  12. Verifique o Pod 1 do cluster 0:

    1source_cluster=${K8S_CLUSTER_0_CONTEXT_NAME}
    2target_pod="echoserver1-0"
    3source_pod="echoserver0-0"
    4target_url="http://${target_pod}.${NAMESPACE}.svc.cluster.local:8080"
    5echo "Checking cross-cluster DNS resolution and connectivity from ${source_pod} in ${source_cluster} to ${target_pod}"
    6out=$(kubectl exec --context "${source_cluster}" -n "${NAMESPACE}" "${source_pod}" -- \
    7 /bin/bash -c "curl -v ${target_url}" 2>&1);
    8grep "Hostname: ${target_pod}" &>/dev/null <<< "${out}" && echo "SUCCESS" || (echo "ERROR: ${out}" && return 1)
  13. Verifique o Pod 1 do cluster 2:

    1source_cluster=${K8S_CLUSTER_2_CONTEXT_NAME}
    2target_pod="echoserver1-0"
    3source_pod="echoserver2-0"
    4target_url="http://${target_pod}.${NAMESPACE}.svc.cluster.local:8080"
    5echo "Checking cross-cluster DNS resolution and connectivity from ${source_pod} in ${source_cluster} to ${target_pod}"
    6out=$(kubectl exec --context "${source_cluster}" -n "${NAMESPACE}" "${source_pod}" -- \
    7 /bin/bash -c "curl -v ${target_url}" 2>&1);
    8grep "Hostname: ${target_pod}" &>/dev/null <<< "${out}" && echo "SUCCESS" || (echo "ERROR: ${out}" && return 1)
  1. Verifique o Pod 2 do cluster 0:

    1source_cluster=${K8S_CLUSTER_0_CONTEXT_NAME}
    2target_pod="echoserver2-0"
    3source_pod="echoserver0-0"
    4target_url="http://${target_pod}.${NAMESPACE}.svc.cluster.local:8080"
    5echo "Checking cross-cluster DNS resolution and connectivity from ${source_pod} in ${source_cluster} to ${target_pod}"
    6out=$(kubectl exec --context "${source_cluster}" -n "${NAMESPACE}" "${source_pod}" -- \
    7 /bin/bash -c "curl -v ${target_url}" 2>&1);
    8grep "Hostname: ${target_pod}" &>/dev/null <<< "${out}" && echo "SUCCESS" || (echo "ERROR: ${out}" && return 1)
  2. Execute o script de limpeza:

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" delete statefulset echoserver0
    2kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" delete statefulset echoserver1
    3kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" delete statefulset echoserver2
    4kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver
    5kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver
    6kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver
    7kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver0-0
    8kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver1-0
    9kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" delete service echoserver2-0
5

Nesta etapa, você usa o plug-in kubectl mongodb para automatizar a configuração do cluster Kubernetes, necessária para que o operador Kubernetes gerencie cargas de trabalho em vários clusters Kubernetes.

Como você configura os clusters Kubernetes antes de instalar o Operador Kubernetes, quando você distribui o Operador Kubernetes para a operação de cluster multi-Kubernetes, toda a configuração multi-cluster necessária já está em vigor.

Conforme indicado na Visão geral, o Operador Kubernetes tem a configuração de três clusters de membros que você pode usar para implantar bancos de dados MongoDB Ops Manager MongoDB . O primeiro cluster também é usado como o cluster do operador, onde você instala o Kubernetes Operator e implementa os recursos personalizados.

1kubectl mongodb multicluster setup \
2 --central-cluster="${K8S_CLUSTER_0_CONTEXT_NAME}" \
3 --member-clusters="${K8S_CLUSTER_0_CONTEXT_NAME},${K8S_CLUSTER_1_CONTEXT_NAME},${K8S_CLUSTER_2_CONTEXT_NAME}" \
4 --member-cluster-namespace="${NAMESPACE}" \
5 --central-cluster-namespace="${OPERATOR_NAMESPACE}" \
6 --create-service-account-secrets \
7 --install-database-roles=true \
8 --image-pull-secrets=image-registries-secret
6
  1. Adicione e atualize o repositório MongoDB Helm. Verifique se o cache local do Helm se refere à versão correta do Kubernetes Operator:

    1helm repo add mongodb https://mongodb.github.io/helm-charts
    2helm repo update mongodb
    3helm search repo "${OFFICIAL_OPERATOR_HELM_CHART}"
  2. Instale o Operador Kubernetes no $OPERATOR_NAMESPACE, configurado para observar $NAMESPACE e gerenciar três clusters de membros do Kubernetes. Neste ponto do procedimento, ServiceAccounts e roles já estão implantados pelo kubectl mongodb plug-in . Portanto, os scripts a seguir ignoram a configuração e definem operator.createOperatorServiceAccount=false e operator.createResourcesServiceAccountsAndRoles=false. Os scripts especificam a configuração multiCluster.clusters para instruir o gráfico Helm a implantar o Operador Kubernetes no modo de vários clusters.

    1helm upgrade --install \
    2 --debug \
    3 --kube-context "${K8S_CLUSTER_0_CONTEXT_NAME}" \
    4 mongodb-enterprise-operator-multi-cluster \
    5 "${OPERATOR_HELM_CHART}" \
    6 --namespace="${OPERATOR_NAMESPACE}" \
    7 --set namespace="${OPERATOR_NAMESPACE}" \
    8 --set operator.namespace="${OPERATOR_NAMESPACE}" \
    9 --set operator.watchNamespace="${NAMESPACE}" \
    10 --set operator.name=mongodb-enterprise-operator-multi-cluster \
    11 --set operator.createOperatorServiceAccount=false \
    12 --set operator.createResourcesServiceAccountsAndRoles=false \
    13 --set "multiCluster.clusters={${K8S_CLUSTER_0_CONTEXT_NAME},${K8S_CLUSTER_1_CONTEXT_NAME},${K8S_CLUSTER_2_CONTEXT_NAME}}" \
    14 --set "${OPERATOR_ADDITIONAL_HELM_VALUES:-"dummy=value"}"
  3. Verifique o sistema do Kubernetes Operator:

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${OPERATOR_NAMESPACE}" rollout status deployment/mongodb-enterprise-operator-multi-cluster
    2echo "Operator deployment in ${OPERATOR_NAMESPACE} namespace"
    3kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${OPERATOR_NAMESPACE}" get deployments
    4echo; echo "Operator pod in ${OPERATOR_NAMESPACE} namespace"
    5kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${OPERATOR_NAMESPACE}" get pods
7

Nesta etapa, você habilita o TLS para o banco de dados do aplicativo e o aplicativo MongoDB Ops Manager . Se você não quiser usar o TLS, remova os seguintes campos dos recursos MongoDBOpsManager :

  1. Opcional. Gerar chaves e certificados:

    Utilize a ferramenta de linha de comando openssl para gerar CAs e certificados autoassinados para fins de teste.

    1mkdir certs || true
    2
    3cat <<EOF >certs/ca.cnf
    4[ req ]
    5default_bits = 2048
    6prompt = no
    7default_md = sha256
    8distinguished_name = dn
    9x509_extensions = v3_ca
    10
    11[ dn ]
    12C=US
    13ST=New York
    14L=New York
    15O=Example Company
    16OU=IT Department
    17CN=exampleCA
    18
    19[ v3_ca ]
    20basicConstraints = CA:TRUE
    21keyUsage = critical, keyCertSign, cRLSign
    22subjectKeyIdentifier = hash
    23authorityKeyIdentifier = keyid:always,issuer
    24EOF
    25
    26cat <<EOF >certs/om.cnf
    27[ req ]
    28default_bits = 2048
    29prompt = no
    30default_md = sha256
    31distinguished_name = dn
    32req_extensions = req_ext
    33
    34[ dn ]
    35C=US
    36ST=New York
    37L=New York
    38O=Example Company
    39OU=IT Department
    40CN=${OPS_MANAGER_EXTERNAL_DOMAIN}
    41
    42[ req_ext ]
    43subjectAltName = @alt_names
    44keyUsage = critical, digitalSignature, keyEncipherment
    45extendedKeyUsage = serverAuth, clientAuth
    46
    47[ alt_names ]
    48DNS.1 = ${OPS_MANAGER_EXTERNAL_DOMAIN}
    49DNS.2 = om-svc.${NAMESPACE}.svc.cluster.local
    50EOF
    51
    52cat <<EOF >certs/appdb.cnf
    53[ req ]
    54default_bits = 2048
    55prompt = no
    56default_md = sha256
    57distinguished_name = dn
    58req_extensions = req_ext
    59
    60[ dn ]
    61C=US
    62ST=New York
    63L=New York
    64O=Example Company
    65OU=IT Department
    66CN=AppDB
    67
    68[ req_ext ]
    69subjectAltName = @alt_names
    70keyUsage = critical, digitalSignature, keyEncipherment
    71extendedKeyUsage = serverAuth, clientAuth
    72
    73[ alt_names ]
    74# multi-cluster mongod hostnames from service for each pod
    75DNS.1 = *.${NAMESPACE}.svc.cluster.local
    76# single-cluster mongod hostnames from headless service
    77DNS.2 = *.om-db-svc.${NAMESPACE}.svc.cluster.local
    78EOF
    79
    80# generate CA keypair and certificate
    81openssl genrsa -out certs/ca.key 2048
    82openssl req -x509 -new -nodes -key certs/ca.key -days 1024 -out certs/ca.crt -config certs/ca.cnf
    83
    84# generate OpsManager's keypair and certificate
    85openssl genrsa -out certs/om.key 2048
    86openssl req -new -key certs/om.key -out certs/om.csr -config certs/om.cnf
    87
    88# generate AppDB's keypair and certificate
    89openssl genrsa -out certs/appdb.key 2048
    90openssl req -new -key certs/appdb.key -out certs/appdb.csr -config certs/appdb.cnf
    91
    92# generate certificates signed by CA for OpsManager and AppDB
    93openssl x509 -req -in certs/om.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/om.crt -days 365 -sha256 -extfile certs/om.cnf -extensions req_ext
    94openssl x509 -req -in certs/appdb.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/appdb.crt -days 365 -sha256 -extfile certs/appdb.cnf -extensions req_ext
  2. Crie segredos com chaves TLS:

    Se você preferir usar suas próprias chaves e certificados, pule a etapa de geração anterior e coloque as chaves e os certificados nos seguintes arquivos:

    • certs/ca.crt - Certificados CA. Eles não são necessários ao usar certificados confiáveis.

    • certs/appdb.key - chave privada para o banco de dados de aplicativos.

    • certs/appdb.crt - certificado para o banco de dados de aplicativos.

    • certs/om.key - chave privada para o MongoDB Ops Manager.

    • certs/om.crt - certificado para MongoDB Ops Manager.

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create secret tls cert-prefix-om-cert \
    2 --cert=certs/om.crt \
    3 --key=certs/om.key
    4
    5kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create secret tls cert-prefix-om-db-cert \
    6 --cert=certs/appdb.crt \
    7 --key=certs/appdb.key
    8
    9kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create configmap om-cert-ca --from-file="mms-ca.crt=certs/ca.crt"
    10kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create configmap appdb-cert-ca --from-file="ca-pem=certs/ca.crt"
8

Neste ponto, você preparou o ambiente e o Operador Kubernetes para implantar o recurso MongoDB Ops Manager .

  1. Crie as credenciais necessárias para o usuário administrador do MongoDB Ops Manager que o operador Kubernetes criará após implantar a instância do aplicativo MongoDB Ops Manager :

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" --namespace "${NAMESPACE}" create secret generic om-admin-user-credentials \
    2 --from-literal=Username="admin" \
    3 --from-literal=Password="Passw0rd@" \
    4 --from-literal=FirstName="Jane" \
    5 --from-literal=LastName="Doe"
  2. Implemente o recurso personalizado MongoDBOpsManager mais simples possível (com TLS habilitado) em um cluster de único membro, que também é conhecido como o cluster do operador.

    Essa implantação é quase a mesma que para o modo de cluster único, mas com spec.topology e spec.applicationDatabase.topology configurados para MultiCluster.

    A implantação dessa forma mostra que um único sistema de cluster Kubernetes é um caso especial de um sistema de cluster multi-Kubernetes em um único cluster de membro do Kubernetes. Você pode começar a implantar o Aplicativo MongoDB Ops Manager e o Banco de Dados de Aplicativos em quantos clusters Kubernetes necessários desde o início e não precisa começar com a implantação com apenas um cluster Kubernetes de nó único.

    Neste ponto, você preparou a implantação do MongoDB Ops Manager para abranger mais de um cluster Kubernetes , o que você fará mais tarde neste procedimento.

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: mongodb.com/v1
    3kind: MongoDBOpsManager
    4metadata:
    5 name: om
    6spec:
    7 topology: MultiCluster
    8 version: "${OPS_MANAGER_VERSION}"
    9 adminCredentials: om-admin-user-credentials
    10 security:
    11 certsSecretPrefix: cert-prefix
    12 tls:
    13 ca: om-cert-ca
    14 clusterSpecList:
    15 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    16 members: 1
    17 applicationDatabase:
    18 version: "${APPDB_VERSION}"
    19 topology: MultiCluster
    20 security:
    21 certsSecretPrefix: cert-prefix
    22 tls:
    23 ca: appdb-cert-ca
    24 clusterSpecList:
    25 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    26 members: 3
    27 backup:
    28 enabled: false
    29EOF
  3. Aguarde o operador Kubernetes pegar o trabalho e alcançar o estado status.applicationDatabase.phase=Pending . Aguarde a conclusão das implantações do banco de dados de aplicativos e do MongoDB Ops Manager .

    1echo "Waiting for Application Database to reach Pending phase..."
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Pending opsmanager/om --timeout=30s
  4. Implemente MongoDB Ops Manager. O Operador Kubernetes implementa o MongoDB Ops Manager executando as etapas a seguir. Ele:

    • Distribui os nós do conjunto de réplicas do banco de dados de aplicativos e aguarda que os processos do MongoDB no conjunto de réplicas comecem a ser executados.

    • Implementa a instância do Aplicativo MongoDB Ops Manager com a connection string do Banco de Dados do Aplicativo e aguarda que ela fique pronta.

    • Adiciona os containers do MongoDB Agent de monitoramento ao Pod de cada banco de dados de aplicativos.

    • Aguarde que o aplicativo MongoDB Ops Manager e os pods do banco de dados de aplicativos comecem a ser executados.

    1echo "Waiting for Application Database to reach Running phase..."
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running opsmanager/om --timeout=900s
    3echo; echo "Waiting for Ops Manager to reach Running phase..."
    4kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.opsManager.phase}'=Running opsmanager/om --timeout=900s
    5echo; echo "Waiting for Application Database to reach Pending phase (enabling monitoring)..."
    6kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running opsmanager/om --timeout=900s
    7echo "Waiting for Application Database to reach Running phase..."
    8kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running opsmanager/om --timeout=900s
    9echo; echo "Waiting for Ops Manager to reach Running phase..."
    10kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.opsManager.phase}'=Running opsmanager/om --timeout=900s
    11echo; echo "MongoDBOpsManager resource"
    12kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get opsmanager/om
    13echo; echo "Pods running in cluster ${K8S_CLUSTER_0_CONTEXT_NAME}"
    14kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
    15echo; echo "Pods running in cluster ${K8S_CLUSTER_1_CONTEXT_NAME}"
    16kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" get pods

    Agora que você distribuiu um cluster de um único membro em um modo de vários clusters, é possível reconfigurar o sistema para abranger mais de um cluster do Kubernetes.

  5. No segundo cluster de membros, implemente dois membros adicionais do conjunto de réplicas do Banco de Dados de Aplicativo e uma instância adicional do Aplicativo MongoDB Ops Manager :

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: mongodb.com/v1
    3kind: MongoDBOpsManager
    4metadata:
    5 name: om
    6spec:
    7 topology: MultiCluster
    8 version: "${OPS_MANAGER_VERSION}"
    9 adminCredentials: om-admin-user-credentials
    10 security:
    11 certsSecretPrefix: cert-prefix
    12 tls:
    13 ca: om-cert-ca
    14 clusterSpecList:
    15 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    16 members: 1
    17 - clusterName: "${K8S_CLUSTER_1_CONTEXT_NAME}"
    18 members: 1
    19 applicationDatabase:
    20 version: "${APPDB_VERSION}"
    21 topology: MultiCluster
    22 security:
    23 certsSecretPrefix: cert-prefix
    24 tls:
    25 ca: appdb-cert-ca
    26 clusterSpecList:
    27 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    28 members: 3
    29 - clusterName: "${K8S_CLUSTER_1_CONTEXT_NAME}"
    30 members: 2
    31 backup:
    32 enabled: false
    33EOF
  6. Aguarde o Operador Kubernetes pegar o trabalho (fase pendente):

    1echo "Waiting for Application Database to reach Pending phase..."
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Pending opsmanager/om --timeout=30s
  7. Aguarde o operador Kubernetes terminar de implantar todos os componentes:

    1echo "Waiting for Application Database to reach Running phase..."
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running opsmanager/om --timeout=600s
    3echo; echo "Waiting for Ops Manager to reach Running phase..."
    4kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.opsManager.phase}'=Running opsmanager/om --timeout=600s
    5echo; echo "MongoDBOpsManager resource"
    6kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get opsmanager/om
    7echo; echo "Pods running in cluster ${K8S_CLUSTER_0_CONTEXT_NAME}"
    8kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
    9echo; echo "Pods running in cluster ${K8S_CLUSTER_1_CONTEXT_NAME}"
    10kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
9

Em um sistema de cluster multi-Kubernetes do Aplicativo de MongoDB Ops Manager , você pode configurar somente o armazenamento de backup baseado em S3 . Este procedimento refere-se ao S3_* definido em env_variables.sh.

  1. Opcional. Instalar o operador MinIO.

    Este procedimento implementa armazenamento compatível com S para3 seus backups usando o Operador MinIO. Você pode pular esta etapa se tiver o Amazon Web Services S3 ou outros buckets compatíveis com o S3disponíveis. Ajuste as variáveis S3_* adequadamente em env_variables.sh neste caso.

    1kubectl kustomize "github.com/minio/operator/resources/?timeout=120&ref=v5.0.12" | \
    2 kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" apply -f -
    3
    4kubectl kustomize "github.com/minio/operator/examples/kustomization/tenant-tiny?timeout=120&ref=v5.0.12" | \
    5 kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" apply -f -
    6
    7# add two buckets to the tenant config
    8kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "tenant-tiny" patch tenant/myminio \
    9 --type='json' \
    10 -p="[{\"op\": \"add\", \"path\": \"/spec/buckets\", \"value\": [{\"name\": \"${S3_OPLOG_BUCKET_NAME}\"}, {\"name\": \"${S3_SNAPSHOT_BUCKET_NAME}\"}]}]"
  2. Antes de configurar e ativar o backup, crie segredos:

    • s3-access-secret - contém credenciais S3 .

    • s3-ca-cert - contém um certificado CA que emitiu o certificado do servidor do bucket. No caso da implantação do MinIO de amostra usada neste procedimento, o certificado padrão da Kubernetes Root CA é usado para assinar o certificado. Como não é um certificado de CA confiável publicamente, você deve fornecê-lo para que o MongoDB Ops Manager possa confiar na conexão.

    Se você utilizar certificados publicamente confiáveis, você poderá pular esta etapa e remover os valores das configurações do spec.backup.s3Stores.customCertificateSecretRefs e spec.backup.s3OpLogStores.customCertificateSecretRefs .

    1kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create secret generic s3-access-secret \
    2 --from-literal=accessKey="${S3_ACCESS_KEY}" \
    3 --from-literal=secretKey="${S3_SECRET_KEY}"
    4
    5# minio TLS secrets are signed with the default k8s root CA
    6kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" create secret generic s3-ca-cert \
    7 --from-literal=ca.crt="$(kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n kube-system get configmap kube-root-ca.crt -o jsonpath="{.data.ca\.crt}")"
10
  1. O Kubernetes Operator pode configurar e distribuir todos os componentes, o aplicativo MongoDB Ops Manager , as instâncias do Backup Daemon e os nós do conjunto de réplicas do aplicativo de banco de dados em qualquer combinação em qualquer cluster de membros para os quais você configure o Kubernetes Operator.

    Para ilustrar a flexibilidade da configuração de implantação de cluster multi-Kubernetes, implemente apenas uma instância do Backup Daemon no cluster do terceiro membro e especifique zero membros do Backup Daemon para o primeiro e o segundo cluster.

    1kubectl apply --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" -f - <<EOF
    2apiVersion: mongodb.com/v1
    3kind: MongoDBOpsManager
    4metadata:
    5 name: om
    6spec:
    7 topology: MultiCluster
    8 version: "${OPS_MANAGER_VERSION}"
    9 adminCredentials: om-admin-user-credentials
    10 security:
    11 certsSecretPrefix: cert-prefix
    12 tls:
    13 ca: om-cert-ca
    14 clusterSpecList:
    15 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    16 members: 1
    17 backup:
    18 members: 0
    19 - clusterName: "${K8S_CLUSTER_1_CONTEXT_NAME}"
    20 members: 1
    21 backup:
    22 members: 0
    23 - clusterName: "${K8S_CLUSTER_2_CONTEXT_NAME}"
    24 members: 0
    25 backup:
    26 members: 1
    27 configuration: # to avoid configuration wizard on first login
    28 mms.adminEmailAddr: email@example.com
    29 mms.fromEmailAddr: email@example.com
    30 mms.ignoreInitialUiSetup: "true"
    31 mms.mail.hostname: smtp@example.com
    32 mms.mail.port: "465"
    33 mms.mail.ssl: "true"
    34 mms.mail.transport: smtp
    35 mms.minimumTLSVersion: TLSv1.2
    36 mms.replyToEmailAddr: email@example.com
    37 applicationDatabase:
    38 version: "${APPDB_VERSION}"
    39 topology: MultiCluster
    40 security:
    41 certsSecretPrefix: cert-prefix
    42 tls:
    43 ca: appdb-cert-ca
    44 clusterSpecList:
    45 - clusterName: "${K8S_CLUSTER_0_CONTEXT_NAME}"
    46 members: 3
    47 - clusterName: "${K8S_CLUSTER_1_CONTEXT_NAME}"
    48 members: 2
    49 backup:
    50 enabled: true
    51 s3Stores:
    52 - name: my-s3-block-store
    53 s3SecretRef:
    54 name: "s3-access-secret"
    55 pathStyleAccessEnabled: true
    56 s3BucketEndpoint: "${S3_ENDPOINT}"
    57 s3BucketName: "${S3_SNAPSHOT_BUCKET_NAME}"
    58 customCertificateSecretRefs:
    59 - name: s3-ca-cert
    60 key: ca.crt
    61 s3OpLogStores:
    62 - name: my-s3-oplog-store
    63 s3SecretRef:
    64 name: "s3-access-secret"
    65 s3BucketEndpoint: "${S3_ENDPOINT}"
    66 s3BucketName: "${S3_OPLOG_BUCKET_NAME}"
    67 pathStyleAccessEnabled: true
    68 customCertificateSecretRefs:
    69 - name: s3-ca-cert
    70 key: ca.crt
    71EOF
  2. Aguarde até que o operador Kubernetes termine sua configuração:

    1echo; echo "Waiting for Backup to reach Running phase..."
    2kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.backup.phase}'=Running opsmanager/om --timeout=1200s
    3echo "Waiting for Application Database to reach Running phase..."
    4kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running opsmanager/om --timeout=600s
    5echo; echo "Waiting for Ops Manager to reach Running phase..."
    6kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" wait --for=jsonpath='{.status.opsManager.phase}'=Running opsmanager/om --timeout=600s
    7echo; echo "MongoDBOpsManager resource"
    8kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get opsmanager/om
    9echo; echo "Pods running in cluster ${K8S_CLUSTER_0_CONTEXT_NAME}"
    10kubectl --context "${K8S_CLUSTER_0_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
    11echo; echo "Pods running in cluster ${K8S_CLUSTER_1_CONTEXT_NAME}"
    12kubectl --context "${K8S_CLUSTER_1_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
    13echo; echo "Pods running in cluster ${K8S_CLUSTER_2_CONTEXT_NAME}"
    14kubectl --context "${K8S_CLUSTER_2_CONTEXT_NAME}" -n "${NAMESPACE}" get pods
11

Execute o roteiro a seguir para excluir os clusters GKE e limpar seu ambiente.

Importante

Os seguintes comandos não são reversíveis. Eles excluem todos os clusters referenciados em env_variables.sh. Não execute esses comandos se quiser manter os clusters GKE, por exemplo, se você não criou os clusters GKE como parte desse procedimento.

1yes | gcloud container clusters delete "${K8S_CLUSTER_0}" --zone="${K8S_CLUSTER_0_ZONE}" &
2yes | gcloud container clusters delete "${K8S_CLUSTER_1}" --zone="${K8S_CLUSTER_1_ZONE}" &
3yes | gcloud container clusters delete "${K8S_CLUSTER_2}" --zone="${K8S_CLUSTER_2_ZONE}" &
4wait