MongoDB e Kubernetes é uma ótima combinação, especialmente no que diz respeito à complexidade. Ainda assim, o MongoDB da Percona (PSMDB) oferece mais flexibilidade para o banco de dados NoSQL e também vem com ferramentas eficientes para a produtividade atual; não apenas no local, mas também disponível para nativos da nuvem.
A taxa de adoção do Kubernetes está aumentando constantemente. É razoável que uma tecnologia tenha um operador para fazer o seguinte:criação, modificação e exclusão de itens do ambiente Percona Server for MongoDB. O Operador Percona MongoDB Kubernetes contém as configurações k8s necessárias para manter um servidor Percona consistente para uma instância do MongoDB. Como uma opção alternativa, você pode comparar isso com https://github.com/kubedb/mongodb, mas o KubeDB para MongoDB oferece opções muito limitadas para oferecer especialmente em sistemas de nível de produção.
Os Operadores Percona Kubernetes que possuem sua configuração são baseados e estão seguindo as melhores práticas para configuração do conjunto de réplicas PSMDB. O que mais importa, o próprio operador do MongoDB oferece muitos benefícios, mas economizar tempo, um ambiente consistente são os mais importantes. Neste blog, teremos uma visão geral de como isso é benéfico, especialmente em um ambiente em contêiner.
O que este operador pode oferecer?
Este operador é útil para PSMDB usando um conjunto de réplicas. Isso significa que sua arquitetura de design de banco de dados deve estar em conformidade com o seguinte diagrama abaixo
Imagem emprestada do Documentation Design Overview da Percona
Imagem emprestada do Documentation Design Overview da Percona
Atualmente, as plataformas suportadas disponíveis para este operador são:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15 - 1.17
- Amazon Elastic Container Service for Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
Outras plataformas Kubernetes também podem funcionar, mas não foram testadas.
Limites de recursos
Um cluster que executa uma plataforma com suporte oficial contém pelo menos três nós, com os seguintes recursos:
- 2 GB de RAM
- 2 threads de CPU por provisionamento do Node for Pods
- pelo menos 60 GB de armazenamento disponível para provisionamento de volumes privados
Restrições de segurança e/ou restrições
O Kubernetes funciona como ao criar Pods, cada Pod possui um endereço IP na rede virtual interna do cluster. Criar ou destruir pods são processos dinâmicos, portanto, não é recomendável vincular seus pods a endereços IP específicos atribuídos para comunicação entre pods. Isso pode causar problemas à medida que as coisas mudam ao longo do tempo como resultado do dimensionamento do cluster, erros inadvertidos, interrupção ou desastres de CC, ou manutenção periódica etc. Nesse caso, o operador recomenda estritamente que você se conecte ao Percona Server para MongoDB por meio do Kubernetes interno Nomes DNS em URI (por exemplo, mongodb+srv://userAdmin:[email protected] Este operador PSMDB Kubernetes também usa afinidade/antiafinidade que fornece restrições para que seus pods possam ser agendados para execução ou iniciados em um nó específico. A afinidade define pods qualificados que podem ser agendados no nó que já possui pods com rótulos específicos. A antiafinidade define os pods que não são qualificados. Essa abordagem reduz custos, garantindo que vários pods com troca intensiva de dados ocupem a mesma zona de disponibilidade ou mesmo o mesmo nó ou, pelo contrário, distribuam os pods em diferentes nós ou até diferentes zonas de disponibilidade para fins de alta disponibilidade e balanceamento. Embora o operador encoraje você a definir afinidade/anti-afinidade, isso tem limitações ao usar o Minikube. Ao usar o Minikube, ele tem as seguintes limitações específicas da plataforma. O Minikube não oferece suporte a configurações de cluster de vários nós devido à sua natureza local, que está em conflito com os requisitos de afinidade padrão do Operador. Para fazer isso, a instrução Instalar Servidor Percona para MongoDB no Minikube inclui uma etapa adicional que desativa o requisito de não ter menos de três nós. Na seção a seguir deste blog, configuraremos o PMSDB Kubernetes Operator usando o Minikube e seguiremos a antiafinidade definida para fazê-lo funcionar. Como isso difere do uso de antiafinidade, se você alterar o AntiAffinity, estará aumentando os riscos de disponibilidade do cluster. Digamos que, se seu objetivo principal de implantar seu PSMDB em um ambiente em contêiner é espalhar e ter maior disponibilidade e escalabilidade, isso pode anular o objetivo. No entanto, é possível usar o Minikube especialmente no local e testar sua configuração do PSMDB, mas para cargas de trabalho de produção, você certamente deseja executar nós em hosts separados ou em uma configuração de ambiente que, de certa forma, seja improvável que ocorra uma falha simultânea de vários pods. Para segurança de dados com PSMDB, a operadora oferece TLS/SSL para trânsito e também oferece criptografia quando os dados estão em repouso. Para em trânsito, as opções que você pode escolher são usar o cert-manager ou gerar seu próprio certificado manualmente. Claro, você pode usar opcionalmente o PSMDB sem TLS para este operador. Confira a documentação deles com relação ao uso do TLS. Para dados em repouso, ele requer alterações em seu PSMDB Kubernetes Operator após o download da ramificação do github e, em seguida, aplique as alterações no arquivo deploy/cr.yaml. Para habilitar isso, faça o seguinte, conforme sugerido pela documentação: O segredo da chave de criptografia será criado automaticamente se não existir. Se você quiser criá-lo você mesmo, leve em consideração que a chave deve ser uma string de 32 caracteres codificada em base64. O PSMDB Kubernetes Operator usa Kubernetes Secrets para armazenar e gerenciar informações confidenciais. Os segredos do Kubernetes permitem armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves ssh. Armazenar informações confidenciais em um segredo é mais seguro e flexível do que colocá-las literalmente em uma definição de pod ou em uma imagem de contêiner. Para este operador, o usuário e as senhas geradas para seus pods são armazenados e podem ser obtidos usando kubectl get secrets Para este blog, minha configuração de exemplo atinge o seguinte com o resultado base64 decodificado. Cada entrada para backup, usuário de cluster, usuário de monitor de cluster e usuário para uso administrativo mostra com base no resultado acima. Outra coisa também é que, o PSMDB Kubernetes Operator armazena também o acesso AWS S3 e as chaves secretas através do Kubernetes Secrets. Este operador suporta backups, que é um recurso muito bacana. Ele suporta backup sob demanda (manual) e backup agendado e usa a ferramenta de backup Percona Backup for MongoDB. Observe que os backups são armazenados apenas no AWS S3 ou em qualquer armazenamento compatível com S3. Os backups agendados podem ser definidos por meio do arquivo deploy/cr.yaml, enquanto o backup manual pode ser feito a qualquer momento, sempre que a demanda for necessária. Para acesso S3 e chaves secretas, ele deve ser definido no arquivo deploy/backup-s3.yaml e usa Kubernetes Secrets para armazenar as informações a seguir, conforme mencionamos anteriormente. Todas as ações com suporte para este PSMDB Kubernetes Operator são as seguintes: Nesta seção, manteremos uma configuração simples usando Kubernetes com Minikube, que você pode usar no local sem a necessidade de um provedor de nuvem. Para configuração nativa da nuvem, especialmente para um ambiente mais corporativo e de nível de produção, você pode fazer o check-out da documentação. Para este blog, o sistema operacional host onde nosso Minikube será instalado é o Ubuntu 18.04 (Bionic Beaver). Como mencionado anteriormente, as limitações do Minikube requerem ajustes para que as coisas funcionem conforme o esperado. Vamos fazer o seguinte: Agora, estamos prontos para aplicar as alterações feitas no arquivo deploy/cr.yaml. O Operador Percona Kubernetes para PSMDB pode ser sua solução completa especialmente para ambientes em contêiner para sua configuração do Percona Server para MongoDB. É uma solução quase completa, pois possui redundância integrada para seu conjunto de réplicas, mas o operador oferece suporte a backup, escalabilidade, alta disponibilidade e segurança.
Dados em trânsito/dados em repouso
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-key
Armazenando informações confidenciais
kubectl get secrets mongodb-cluster-s9s-secrets -o yaml | egrep '^\s+MONGODB.*'|cut -d ':' -f2 | xargs -I% sh -c "echo % | base64 -d; echo "
WrDry6bexkCPOY5iQ
backup
gAWBKkmIQsovnImuKyl
clusterAdmin
qHskMMseNqU8DGbo4We
clusterMonitor
TQBEV7rtE15quFl5
userAdmin
Backups
Usando o operador PSMDB Kubernetes com o Minikube
Antes de prosseguirmos com as etapas, lembre-se de que, conforme mencionado acima, houve uma limitação conhecida com o Minikube, pois ele não suporta configuração de cluster de vários nós que está em conflito com os requisitos de afinidade padrão do operador. Vamos mencionar isso sobre como lidar com isso nas etapas a seguir.
Vamos instalar o Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb
Opcionalmente, você pode seguir as etapas aqui se estiver em sistemas Linux diferentes.
Vamos adicionar a chave necessária para autenticar nossos pacotes Kubernetes e configurar o repositório
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ cat <<eof > /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
deb https://apt.kubernetes.io/ kubernetes-yakkety main
eof
Agora vamos instalar os pacotes necessários
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectl
Inicie o Minikube definindo a memória, o número de CPUs e o CIDR para os quais meus nós devem ser atribuídos,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16
Os resultados do exemplo mostram como,
minikube v1.14.2 on Ubuntu 18.04
Automatically selected the docker driver
docker is currently using the aufs storage driver, consider switching to overlay2 for better performance
Starting control plane node minikube in cluster minikube
Creating docker container (CPUs=3, Memory=4096MB) ...
Preparing Kubernetes v1.19.2 on Docker 19.03.8 ...
kubeadm.pod-network-cidr=192.168.0.0/16
> kubeadm.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
> kubectl.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
> kubelet.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
> kubeadm: 37.30 MiB / 37.30 MiB [---------------] 100.00% 1.46 MiB p/s 26s
> kubectl: 41.01 MiB / 41.01 MiB [---------------] 100.00% 1.37 MiB p/s 30s
> kubelet: 104.88 MiB / 104.88 MiB [------------] 100.00% 1.53 MiB p/s 1m9s
Verifying Kubernetes components...
Enabled addons: default-storageclass, storage-provisioner
Done! kubectl is now configured to use "minikube" by default
Como você notou, ele também instala as ferramentas utilitárias para gerenciar e administrar seus nós ou pods.
Agora, vamos verificar os nós e pods executando os seguintes comandos,
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-f9fd979d6-gwngd 1/1 Running 0 45s
kube-system etcd-minikube 0/1 Running 0 53s
kube-system kube-apiserver-minikube 1/1 Running 0 53s
kube-system kube-controller-manager-minikube 0/1 Running 0 53s
kube-system kube-proxy-m25hm 1/1 Running 0 45s
kube-system kube-scheduler-minikube 0/1 Running 0 53s
kube-system storage-provisioner 1/1 Running 1 57s
$ kubectl get nodes -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
minikube Ready master 2d4h v1.19.2 192.168.49.2 <none> Ubuntu 20.04 LTS 4.15.0-20-generic docker://19.3.8
Agora, baixe o PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operator
Agora estamos prontos para implantar o operador,
$ kubectl apply -f deploy/bundle.yaml
$ kubectl apply -f deploy/cr.yaml
Neste ponto, você poderá verificar o status dos pods e observará o seguinte progresso, como abaixo,
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
percona-server-mongodb-operator-588db759d-qjv29 0/1 ContainerCreating 0 15s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 0/2 Init:0/1 0 4s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 34s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 0/2 PodInitializing 0 119s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2m29s
kubectl get pods
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 0/2 PodInitializing 0 2m1s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2m31s
kubectl get pods
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 2/2 Running 0 33m
mongodb-cluster-s9s-rs0-1 2/2 Running 1 31m
mongodb-cluster-s9s-rs0-2 2/2 Running 0 30m
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 33m
Agora que estamos quase lá. Obteremos os segredos gerados pelo operador para que possamos nos conectar aos pods PSMDB criados. Para fazer isso, você precisa listar os objetos secretos primeiro e, em seguida, obter o valor do yaml para obter a combinação de usuário/senha. Por outro lado, você pode usar o comando combinado abaixo com o formato nome de usuário:senha. Veja o exemplo abaixo,
$ kubectl get secrets
NAME TYPE DATA AGE
default-token-c8frr kubernetes.io/service-account-token 3 2d4h
internal-mongodb-cluster-s9s-users Opaque 8 2d4h
mongodb-cluster-s9s-mongodb-encryption-key Opaque 1 2d4h
mongodb-cluster-s9s-mongodb-keyfile Opaque 1 2d4h
mongodb-cluster-s9s-secrets Opaque 8 2d4h
percona-server-mongodb-operator-token-rbzbc kubernetes.io/service-account-token 3 2d4h
$ kubectl get secrets mongodb-cluster-s9s-secrets -o yaml | egrep '^\s+MONGODB.*'|cut -d ':' -f2 | xargs -I% sh -c "echo % | base64 -d; echo" |sed 'N; s/\(.*\)\n\(.*\)/
\2:\1/'
backup:WrDry6bexkCPOY5iQ
clusterAdmin:gAWBKkmIQsovnImuKyl
clusterMonitor:qHskMMseNqU8DGbo4We
userAdmin:TQBEV7rtE15quFl5
Agora, você pode basear o formato nome de usuário:senha e salvá-lo em algum lugar seguro.
Como não podemos nos conectar diretamente aos nós do Percona Server for MongoDB, precisamos criar um novo pod que tenha o cliente mongodb,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -il
Por fim, agora estamos prontos para nos conectar aos nossos nós PSMDB agora,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"
Como alternativa, você pode se conectar aos nós individuais e verificar sua integridade. Por exemplo,
bash-4.2$ mongo --host "mongodb://clusterAdmin:[email protected]:27017/?authSource=admin&ssl=false"
Percona Server for MongoDB shell version v4.2.8-8
connecting to: mongodb://mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb&ssl=false
Implicit session: session { "id" : UUID("9b29b9b3-4f82-438d-9857-eff145be0ee6") }
Percona Server for MongoDB server version: v4.2.8-8
Welcome to the Percona Server for MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
https://www.percona.com/doc/percona-server-for-mongodb
Questions? Try the support group
https://www.percona.com/forums/questions-discussions/percona-server-for-mongodb
2020-11-09T07:41:59.172+0000 I STORAGE [main] In File::open(), ::open for '/home/mongodb/.mongorc.js' failed with No such file or directory
Server has startup warnings:
2020-11-09T06:41:16.838+0000 I CONTROL [initandlisten] ** WARNING: While invalid X509 certificates may be used to
2020-11-09T06:41:16.838+0000 I CONTROL [initandlisten] ** connect to this server, they will not be considered
2020-11-09T06:41:16.838+0000 I CONTROL [initandlisten] ** permissible for authentication.
2020-11-09T06:41:16.838+0000 I CONTROL [initandlisten]
rs0:SECONDARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2020-11-09T07:42:04.984Z"),
"myState" : 2,
"term" : NumberLong(5),
"syncingTo" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceHost" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceId" : 0,
"heartbeatIntervalMillis" : NumberLong(2000),
"majorityVoteCount" : 2,
"writeMajorityCount" : 2,
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"lastCommittedWallTime" : ISODate("2020-11-09T07:42:03.395Z"),
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"readConcernMajorityWallTime" : ISODate("2020-11-09T07:42:03.395Z"),
"appliedOpTime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"durableOpTime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"lastAppliedWallTime" : ISODate("2020-11-09T07:42:03.395Z"),
"lastDurableWallTime" : ISODate("2020-11-09T07:42:03.395Z")
},
"lastStableRecoveryTimestamp" : Timestamp(1604907678, 3),
"lastStableCheckpointTimestamp" : Timestamp(1604907678, 3),
"members" : [
{
"_id" : 0,
"name" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 3632,
"optime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"optimeDurable" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"optimeDate" : ISODate("2020-11-09T07:42:03Z"),
"optimeDurableDate" : ISODate("2020-11-09T07:42:03Z"),
"lastHeartbeat" : ISODate("2020-11-09T07:42:04.246Z"),
"lastHeartbeatRecv" : ISODate("2020-11-09T07:42:03.162Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1604904092, 1),
"electionDate" : ISODate("2020-11-09T06:41:32Z"),
"configVersion" : 3
},
{
"_id" : 1,
"name" : "mongodb-cluster-s9s-rs0-1.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 3632,
"optime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"optimeDurable" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"optimeDate" : ISODate("2020-11-09T07:42:03Z"),
"optimeDurableDate" : ISODate("2020-11-09T07:42:03Z"),
"lastHeartbeat" : ISODate("2020-11-09T07:42:04.244Z"),
"lastHeartbeatRecv" : ISODate("2020-11-09T07:42:04.752Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceHost" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 3
},
{
"_id" : 2,
"name" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 3651,
"optime" : {
"ts" : Timestamp(1604907723, 4),
"t" : NumberLong(5)
},
"optimeDate" : ISODate("2020-11-09T07:42:03Z"),
"syncingTo" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceHost" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 3,
"self" : true,
"lastHeartbeatMessage" : ""
}
],
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1604907723, 4),
"signature" : {
"hash" : BinData(0,"HYC0i49c+kYdC9M8KMHgBdQW1ac="),
"keyId" : NumberLong("6892206918371115011")
}
},
"operationTime" : Timestamp(1604907723, 4)
}
Uma vez que o operador gerencia a consistência do cluster, sempre que uma falha ou digamos que um pod foi excluído. O operador iniciará automaticamente um novo. Por exemplo,
$ kubectl get po
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 2/2 Running 0 2d5h
mongodb-cluster-s9s-rs0-1 2/2 Running 0 2d5h
mongodb-cluster-s9s-rs0-2 2/2 Running 0 2d5h
percona-client 1/1 Running 0 3m7s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2d5h
$ kubectl delete po mongodb-cluster-s9s-rs0-1
pod "mongodb-cluster-s9s-rs0-1" deleted
$ kubectl get po
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 2/2 Running 0 2d5h
mongodb-cluster-s9s-rs0-1 0/2 Init:0/1 0 3s
mongodb-cluster-s9s-rs0-2 2/2 Running 0 2d5h
percona-client 1/1 Running 0 3m29s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2d5h
$ kubectl get po
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 2/2 Running 0 2d5h
mongodb-cluster-s9s-rs0-1 0/2 PodInitializing 0 10s
mongodb-cluster-s9s-rs0-2 2/2 Running 0 2d5h
percona-client 1/1 Running 0 3m36s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2d5h
$ kubectl get po
NAME READY STATUS RESTARTS AGE
mongodb-cluster-s9s-rs0-0 2/2 Running 0 2d5h
mongodb-cluster-s9s-rs0-1 2/2 Running 0 26s
mongodb-cluster-s9s-rs0-2 2/2 Running 0 2d5h
percona-client 1/1 Running 0 3m52s
percona-server-mongodb-operator-588db759d-qjv29 1/1 Running 0 2d5h
Agora que estamos todos prontos. Claro, pode ser necessário expor a porta para que você precise lidar com ajustes em deploy/cr.yaml. Você pode consultar aqui para lidar com isso.
Conclusão
