MongoDB y Kubernetes es una gran combinación, especialmente en lo que respecta a la complejidad. Sin embargo, MongoDB (PSMDB) de Percona ofrece más flexibilidad para la base de datos NoSQL y también viene con herramientas que son eficientes para la productividad actual; no solo local, sino también disponible para nativos de la nube.
La tasa de adopción de Kubernetes aumenta constantemente. Es razonable que una tecnología deba tener un operador para hacer lo siguiente:creación, modificación y eliminación de elementos Percona Server para ambiente MongoDB. El operador Kubernetes de Percona MongoDB contiene la configuración necesaria de k8s para mantener un servidor Percona coherente para una instancia de MongoDB. Como opción alternativa, puede comparar esto con https://github.com/kubedb/mongodb, pero KubeDB para MongoDB ofrece opciones muy limitadas para ofrecer, especialmente en sistemas de grado de producción.
Los operadores de Percona Kubernetes que cuentan con su configuración se basan y siguen las mejores prácticas para la configuración del conjunto de réplicas de PSMDB. Lo que más importa, el propio operador de MongoDB proporciona muchos beneficios, pero el ahorro de tiempo y un entorno coherente son los más importantes. En este blog, veremos una descripción general de cómo esto es beneficioso, especialmente en un entorno en contenedores.
¿Qué puede ofrecer este operador?
Este operador es útil para PSMDB que utiliza un conjunto de réplicas. Esto significa que la arquitectura de diseño de su base de datos debe cumplir con el siguiente diagrama a continuación
Imagen tomada de Percona's Documentation Design OverviewImagen tomada de Percona's Documentation Design Overview
Actualmente, las plataformas compatibles disponibles para este operador son:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15 - 1.17
- Amazon Elastic Container Service para Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
Otras plataformas de Kubernetes también pueden funcionar, pero no se han probado.
Límites de recursos
Un clúster que ejecuta una plataforma compatible oficialmente contiene al menos tres nodos, con los siguientes recursos:
- 2 GB de RAM
- 2 subprocesos de CPU por nodo para el aprovisionamiento de pods
- al menos 60 GB de almacenamiento disponible para el aprovisionamiento de volúmenes privados
Seguridad y/o Restricciones Restricciones
El Kubernetes funciona como al crear Pods, cada Pod tiene una dirección IP en la red virtual interna del clúster. Tanto la creación como la destrucción de pods son procesos dinámicos, por lo que no es recomendable vincular sus pods a direcciones IP específicas asignadas para la comunicación entre pods. Esto puede causar problemas a medida que las cosas cambian con el tiempo como resultado de la escala del clúster, errores involuntarios, cortes de CC o desastres, o mantenimiento periódico, etc. En ese caso, el operador recomienda estrictamente que se conecte a Percona Server para MongoDB a través de Kubernetes interno. Nombres DNS en URI (por ejemplo, mongodb+srv://userAdmin:[email protected]
Este operador de Kubernetes de PSMDB también utiliza afinidad/antiafinidad, lo que proporciona restricciones según las cuales sus pods pueden programarse para ejecutarse o iniciarse en un nodo específico. Affinity define pods elegibles que se pueden programar en el nodo que ya tiene pods con etiquetas específicas. La antiafinidad define los pods que no son elegibles. Este enfoque reduce los costos al garantizar que varios pods con un intercambio intensivo de datos ocupen la misma zona de disponibilidad o incluso el mismo nodo o, por el contrario, distribuir los pods en diferentes nodos o incluso en diferentes zonas de disponibilidad para fines de alta disponibilidad y equilibrio. Aunque el operador lo alienta a establecer afinidad/antiafinidad, esto tiene limitaciones cuando se usa Minikube.
Al usar Minikube, tiene las siguientes limitaciones específicas de la plataforma. Minikube no admite configuraciones de clúster de varios nodos debido a su naturaleza local, que choca con los requisitos de afinidad predeterminados del operador. Para arreglar esto, la instrucción Install Percona Server for MongoDB on Minikube incluye un paso adicional que desactiva el requisito de tener no menos de tres nodos.
En la siguiente sección de este blog, configuraremos el operador Kubernetes de PMSDB usando Minikube y seguiremos la configuración anti-afinidad para que funcione. ¿En qué se diferencia esto del uso de antiafinidad? Si cambia AntiAffinity, aumenta los riesgos para la disponibilidad del clúster. Digamos que si su propósito principal de implementar su PSMDB en un entorno en contenedores es expandirse y tener una mayor disponibilidad pero escalabilidad, entonces esto podría frustrar el propósito. Sin embargo, usar Minikube especialmente en las instalaciones y para probar su configuración de PSMDB es factible, pero para las cargas de trabajo de producción seguramente querrá ejecutar nodos en hosts separados, o en una configuración de entorno tal que, de alguna manera, es poco probable que ocurra una falla simultánea de varios pods.
Datos en tránsito/Datos en reposo
Para la seguridad de los datos con PSMDB, el operador ofrece TLS/SSL en tránsito, luego también ofrece cifrado cuando los datos están en reposo. En tránsito, las opciones que puede elegir son usar cert-manager o generar su propio certificado manualmente. Por supuesto, opcionalmente puede usar PSMDB sin TLS para este operador. Consulte su documentación con respecto al uso de TLS.
Para los datos en reposo, requiere cambios dentro de su Operador de Kubernetes de PSMDB después de descargar la rama de github y luego aplicar los cambios en el archivo deployment/cr.yaml. Para habilitar esto, haga lo siguiente como se sugiere en la documentación:
- La clave security.enableEncryption debe establecerse en verdadero (el valor predeterminado).
- La clave security.encryptionCipherMode debe especificar el modo de cifrado adecuado para el descifrado. El valor puede ser una de las siguientes dos variantes:
- AES256-CBC (el predeterminado para el Operador y el Servidor Percona para MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-keyEl secreto de la clave de cifrado se creará automáticamente si no existe. Si quieres crearlo tú mismo, ten en cuenta que la clave debe ser una cadena de 32 caracteres codificada en base64.
Almacenamiento de información confidencial
El operador de Kubernetes de PSMDB utiliza secretos de Kubernetes para almacenar y administrar información confidencial. Los secretos de Kubernetes le permiten almacenar y administrar información confidencial, como contraseñas, tokens de OAuth y claves ssh. Almacenar información confidencial en un secreto es más seguro y más flexible que ponerla palabra por palabra en una definición de pod o en una imagen de contenedor.
Para este operador, el usuario y las contraseñas generadas para sus pods se almacenan y se pueden obtener utilizando kubectl get secrets
Para este blog, mi configuración de ejemplo logra lo siguiente con el resultado base64 decodificado.
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
userAdminCada entrada para copia de seguridad, usuario de clúster, usuario de monitor de clúster y usuario para uso administrativo se muestra según el resultado anterior.
Otra cosa también es que, PSMDB Kubernetes Operator almacena también las claves secretas y de acceso de AWS S3 a través de Kubernetes Secrets.
Copias de seguridad
Este operador admite copias de seguridad, lo cual es una característica muy ingeniosa. Admite copias de seguridad bajo demanda (manuales) y copias de seguridad programadas y utiliza la herramienta de copia de seguridad Percona Backup para MongoDB. Tenga en cuenta que las copias de seguridad solo se almacenan en AWS S3 o en cualquier almacenamiento compatible con S3.
Las copias de seguridad programadas se pueden definir a través del archivo deployment/cr.yaml, mientras que se puede realizar una copia de seguridad manual en cualquier momento cuando sea necesario. Para las claves secretas y de acceso de S3, debe definirse en el archivo deployment/backup-s3.yaml y utiliza Kubernetes Secrets para almacenar la siguiente información, como mencionamos anteriormente.
Todas las acciones compatibles con este operador de Kubernetes de PSMDB son las siguientes:
- Realización de copias de seguridad programadas
- Realización de copias de seguridad a pedido
- Restaurar el clúster a partir de una copia de seguridad guardada previamente
- Eliminar la copia de seguridad innecesaria
Uso del operador Kubernetes de PSMDB con Minikube
En esta sección, mantendremos una configuración simple usando Kubernetes con Minikube, que puede usar localmente sin necesidad de un proveedor de nube. Para la configuración nativa de la nube, especialmente para un entorno más empresarial y de grado de producción, puede consultar su documentación.
Antes de continuar con los pasos, tenga en cuenta que, como se mencionó anteriormente, ha habido una limitación conocida con Minikube, ya que no es compatible con la configuración de clúster de varios nodos, lo que choca con los requisitos de afinidad predeterminados del operador. Mencionaremos esto sobre cómo manejarlo en los siguientes pasos a continuación.
Para este blog, el sistema operativo host donde se instalará nuestro Minikube es Ubuntu 18.04 (Bionic Beaver).
Instalemos Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.debOpcionalmente, puede seguir los pasos aquí si está en diferentes sistemas Linux.
Agreguemos la clave requerida para autenticar nuestros paquetes de Kubernetes y configurar el repositorio
$ 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
eofAhora instalemos los paquetes necesarios
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectlInicie el Minikube definiendo la memoria, el número de CPU y el CIDR para el que se asignarán mis nodos,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16Los resultados del ejemplo muestran 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 defaultComo notó, también instala las herramientas de utilidad para administrar y administrar sus nodos o pods.
Ahora, verifiquemos los nodos y los pods ejecutando los siguientes 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.8Ahora, descargue el operador PSMDB Kubernetes,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operatorAhora estamos listos para implementar el operador,
$ kubectl apply -f deploy/bundle.yamlComo se mencionó anteriormente, las limitaciones de Minikube requieren ajustes para que las cosas funcionen como se espera. Hagamos lo siguiente:
- Dependiendo de la capacidad de su hardware actual, puede cambiar lo siguiente como se sugiere en la documentación. Dado que minikube se ejecuta localmente, el archivo deployment/cr.yaml predeterminado debe editarse para adaptar el Operador para la instalación local con recursos limitados. Cambie las siguientes claves en la sección replsets:
- comente las claves resources.requests.memory y resources.requests.cpu (esto se ajustará al operador en las limitaciones predeterminadas de minikube)
- establezca la clave affinity.antiAffinityTopologyKey en "ninguno" (el operador no podrá distribuir el clúster en varios nodos)
- Además, cambie la clave allowUnsafeConfigurations a verdadero (esta opción desactiva el control del operador sobre la configuración del clúster, lo que hace posible implementar Percona Server para MongoDB como un clúster de un nodo).
Ahora, estamos listos para aplicar los cambios realizados en el archivo deployment/cr.yaml.
$ kubectl apply -f deploy/cr.yamlEn este punto, es posible que pueda verificar el estado de los pods y notará el siguiente progreso como se muestra a continuación:
$ 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 33mAhora que ya casi llegamos. Obtendremos los secretos generados por el operador para que podamos conectarnos a los pods de PSMDB creados. Para hacer eso, primero debe enumerar los objetos secretos, luego obtener el valor del yaml para que pueda obtener la combinación de usuario/contraseña. Por otro lado, puede usar el comando combinado a continuación con el formato de nombre de usuario:contraseña. Vea el ejemplo a continuación,
$ 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:TQBEV7rtE15quFl5Ahora, puede basar el nombre de usuario:formato de contraseña y guardarlo en algún lugar seguro.
Dado que no podemos conectarnos directamente al servidor Percona para los nodos MongoDB, necesitamos crear un nuevo pod que tenga el cliente mongodb,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -ilPor último, ahora estamos listos para conectarnos a nuestros nodos PSMDB ahora,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"Alternativamente, puede conectarse a los nodos individuales y verificar su salud. Por ejemplo,
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)
}Dado que el operador administra la consistencia del clúster, cada vez que se elimina una falla o, digamos, un pod. El operador iniciará automáticamente uno nuevo. Por ejemplo,
$ 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 2d5hAhora que estamos listos. Por supuesto, es posible que deba exponer el puerto, por lo que es posible que tenga que lidiar con los ajustes en deployment/cr.yaml. Puede consultar aquí para solucionarlo.
Conclusión
Percona Kubernetes Operator para PSMDB puede ser su solución completa, especialmente para entornos en contenedores para su configuración de Percona Server para MongoDB. Es casi una solución completa, ya que tiene redundancia integrada para su conjunto de réplicas, pero el operador admite copias de seguridad, escalabilidad, alta disponibilidad y seguridad.
