MongoDB e Kubernetes sono un'ottima combinazione, soprattutto per quanto riguarda la complessità. Tuttavia, MongoDB (PSMDB) di Percona offre maggiore flessibilità per il database NoSQL e viene fornito anche con strumenti efficienti per la produttività odierna; non solo on-premise ma disponibile anche per i nativi cloud.
Il tasso di adozione di Kubernetes è in costante aumento. È ragionevole che una tecnologia debba avere un operatore per eseguire le seguenti operazioni:creazione, modifica ed eliminazione di elementi Percona Server per ambiente MongoDB. L'operatore Percona MongoDB Kubernetes contiene le impostazioni k8s necessarie per mantenere un server Percona coerente per un'istanza MongoDB. Come opzione alternativa, potresti confrontarlo con https://github.com/kubedb/mongodb ma KubeDB per MongoDB offre opzioni molto limitate da offrire soprattutto su sistemi di livello di produzione.
Gli operatori Percona Kubernetes che vantano la sua configurazione si basano e stanno seguendo le migliori pratiche per la configurazione del set di repliche PSMDB. Ciò che conta di più, l'operatore per MongoDB stesso offre molti vantaggi ma il risparmio di tempo, un ambiente coerente è il più importante. In questo blog faremo una panoramica di come ciò sia vantaggioso soprattutto in un ambiente containerizzato.
Cosa può offrire questo operatore?
Questo operatore è utile per PSMDB che utilizza un set di repliche. Ciò significa che l'architettura di progettazione del database deve essere conforme al diagramma seguente
Immagine presa in prestito dalla Panoramica della progettazione della documentazione di PerconaImmagine presa in prestito dalla Panoramica della progettazione della documentazione di Percona
Attualmente, le piattaforme supportate disponibili per questo operatore sono:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15 - 1.17
- Amazon Elastic Container Service per Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
Anche altre piattaforme Kubernetes potrebbero funzionare ma non sono state testate.
Limiti delle risorse
Un cluster che esegue una piattaforma supportata ufficialmente contiene almeno tre nodi, con le seguenti risorse:
- 2 GB di RAM
- 2 thread della CPU per nodo per il provisioning dei pod
- almeno 60 GB di spazio di archiviazione disponibile per il provisioning di volumi privati
Vincoli di sicurezza e/o restrizioni
Il Kubernetes funziona come quando si creano Pod, ogni Pod ha un indirizzo IP nella rete virtuale interna del cluster. La creazione o la distruzione dei pod sono entrambi processi dinamici, quindi non è consigliabile associare i tuoi pod a indirizzi IP specifici assegnati per la comunicazione tra i pod. Ciò può causare problemi poiché le cose cambiano nel tempo a causa del ridimensionamento del cluster, errori involontari, interruzione o disastri del DC o manutenzione periodica, ecc. In tal caso, l'operatore consiglia vivamente di connetterti a Percona Server per MongoDB tramite Kubernetes interno Nomi DNS nell'URI (ad es. mongodb+srv://userAdmin:[email protected]
Questo operatore Kubernetes PSMDB utilizza anche affinità/anti-affinità che fornisce vincoli a cui i tuoi pod possono essere pianificati per l'esecuzione o avviati su un nodo specifico. Affinity definisce i pod idonei che possono essere pianificati sul nodo che dispone già di pod con etichette specifiche. L'anti-affinità definisce i pod che non sono idonei. Questo approccio riduce i costi garantendo che più pod con scambio dati intensivo occupino la stessa zona di disponibilità o addirittura lo stesso nodo o, al contrario, per distribuire i pod su nodi diversi o anche zone di disponibilità diverse per scopi di alta disponibilità e bilanciamento. Sebbene l'operatore ti incoraggi a impostare affinità/anti-affinità, tuttavia ciò presenta dei limiti quando si utilizza Minikube.
Quando si utilizza Minikube, presenta le seguenti limitazioni specifiche della piattaforma. Minikube non supporta le configurazioni cluster multinodo a causa della sua natura locale, che è in conflitto con i requisiti di affinità predefiniti dell'operatore. Per organizzare ciò, l'istruzione Install Percona Server for MongoDB on Minikube include un passaggio aggiuntivo che disattiva il requisito di avere non meno di tre nodi.
Nella sezione seguente di questo blog, imposteremo PMSDB Kubernetes Operator utilizzando Minikube e seguiremo l'anti-affinità impostato per farlo funzionare. In che cosa differisce dall'utilizzo dell'anti-affinità, se modifichi AntiAffinity aumenti i rischi per la disponibilità del cluster. Diciamo che se il tuo scopo principale di distribuire il tuo PSMDB in un ambiente containerizzato è quello di diffondersi e avere una maggiore disponibilità ma scalabilità, allora questo potrebbe vanificare lo scopo. Tuttavia, l'utilizzo di Minikube soprattutto in locale e per testare la configurazione di PSMDB è fattibile, ma per i carichi di lavoro di produzione si desidera sicuramente eseguire nodi su host separati o in un ambiente configurato in modo tale che in un certo senso sia improbabile che si verifichino guasti simultanei di più pod.
Dati in transito/Dati inattivi
Per la sicurezza dei dati con PSMDB, l'operatore offre TLS/SSL in transito, quindi offre anche la crittografia quando i dati sono inattivi. Per il transito, le opzioni che puoi scegliere sono utilizzare cert-manager o generare il tuo certificato manualmente. Ovviamente, puoi utilizzare facoltativamente PSMDB senza TLS per questo operatore. Dai un'occhiata alla loro documentazione relativa all'utilizzo di TLS.
Per i dati inattivi, sono necessarie modifiche all'interno dell'operatore Kubernetes PSMDB dopo aver scaricato il ramo github, quindi applicare le modifiche al file deploy/cr.yaml. Per abilitarlo, procedi come suggerito dalla documentazione:
- La chiave security.enableEncryption deve essere impostata su true (il valore predefinito).
- La chiave security.encryptionCipherMode deve specificare la modalità di crittografia corretta per la decrittografia. Il valore può essere una delle seguenti due varianti:
- AES256-CBC (quello predefinito per Operator e Percona Server per MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-keyIl segreto della chiave di crittografia verrà creato automaticamente se non esiste. Se desideri crearla tu stesso, tieni presente che la chiave deve essere una stringa di 32 caratteri codificata in base64.
Memorizzazione di informazioni sensibili
L'operatore PSMDB Kubernetes utilizza Kubernetes Secrets per archiviare e gestire informazioni sensibili. I segreti di Kubernetes ti consentono di archiviare e gestire informazioni sensibili, come password, token OAuth e chiavi ssh. La memorizzazione di informazioni riservate in un segreto è più sicura e flessibile rispetto a inserirle testualmente in una definizione pod o in un'immagine contenitore.
Per questo operatore, l'utente e le password generate per i tuoi pod vengono archiviati e possono essere ottenuti utilizzando kubectl get secrets
Per questo blog, la mia configurazione di esempio ottiene quanto segue con il risultato base64 decodificato.
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
userAdminOgni voce per il backup, l'utente del cluster, l'utente del monitoraggio del cluster e l'utente per l'utilizzo amministrativo vengono visualizzati in base al risultato precedente.
Un'altra cosa è che, PSMDB Kubernetes Operator memorizza anche l'accesso AWS S3 e le chiavi segrete tramite Kubernetes Secrets.
Backup
Questo operatore supporta i backup che è una caratteristica molto ingegnosa. Supporta il backup su richiesta (manuale) e il backup pianificato e utilizza lo strumento di backup Percona Backup for MongoDB. Tieni presente che i backup vengono archiviati solo su AWS S3 o su qualsiasi storage compatibile con S3.
I backup pianificati possono essere definiti tramite il file deploy/cr.yaml, mentre è possibile eseguire un backup manuale in qualsiasi momento ogni volta che è necessario. Per l'accesso S3 e le chiavi segrete, deve essere definito nel file deploy/backup-s3.yaml e utilizza Kubernetes Secrets per archiviare le seguenti informazioni, come accennato in precedenza.
Tutte le azioni supportate per questo operatore Kubernetes PSMDB sono le seguenti:
- Effettuare backup pianificati
- Effettuare backup su richiesta
- Ripristina il cluster da un backup salvato in precedenza
- Elimina il backup non necessario
Utilizzo dell'operatore Kubernetes PSMDB con Minikube
In questa sezione, manterremo una semplice configurazione utilizzando Kubernetes con Minikube, che puoi utilizzare in locale senza la necessità di un provider cloud. Per la configurazione nativa del cloud, in particolare per un ambiente più aziendale e di livello produttivo, puoi consultare la loro documentazione.
Prima di procedere con i passaggi, tieni presente che, come accennato in precedenza, si è verificata una limitazione nota con Minikube in quanto non supporta la configurazione del cluster multi-nodo che è in conflitto con i requisiti di affinità predefiniti dell'operatore. Ne parleremo su come gestirlo nei seguenti passaggi.
Per questo blog, il sistema operativo host su cui verrà installato il nostro Minikube è Ubuntu 18.04 (Bionic Beaver).
Installiamo Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.debFacoltativamente, puoi seguire i passaggi qui se utilizzi diversi sistemi Linux.
Aggiungiamo la chiave richiesta per autenticare i nostri pacchetti Kubernetes e configurare il repository
$ 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
eofOra installiamo i pacchetti richiesti
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectlAvvia il Minikube definendo la memoria, il numero di CPU e il CIDR a cui assegnare i miei nodi,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16I risultati di esempio mostrano come,
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 defaultCome hai notato, installa anche gli strumenti di utilità per gestire e amministrare i tuoi nodi o pod.
Ora, controlliamo i nodi e i pod eseguendo i seguenti comandi,
$ 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.8Ora scarica PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operatorOra siamo pronti per distribuire l'operatore,
$ kubectl apply -f deploy/bundle.yamlCome accennato in precedenza, le limitazioni di Minikube richiedono aggiustamenti per far funzionare le cose come previsto. Procediamo come segue:
- A seconda della tua attuale capacità hardware, potresti modificare quanto segue come suggerito dalla documentazione. Poiché minikube viene eseguito localmente, il file deploy/cr.yaml predefinito deve essere modificato per adattare l'operatore all'installazione locale con risorse limitate. Modificare le seguenti chiavi nella sezione replset:
- Commenta le chiavi resources.requests.memory e resources.requests.cpu (questo si adatta all'operatore nelle limitazioni predefinite di minikube)
- impostare la chiave affinity.antiAffinityTopologyKey su "none" (l'Operatore non sarà in grado di diffondere il cluster su più nodi)
- Inoltre, imposta la chiave allowUnsafeConfigurations su true (questa opzione disattiva il controllo dell'operatore sulla configurazione del cluster, rendendo possibile l'implementazione di Percona Server per MongoDB come cluster a un nodo).
Ora siamo pronti per applicare le modifiche apportate al file deploy/cr.yaml.
$ kubectl apply -f deploy/cr.yamlA questo punto, potresti essere in grado di controllare lo stato dei pod e noterai i seguenti progressi proprio come di seguito,
$ 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 33mOra che ci siamo quasi. Otterremo i segreti generati dall'operatore in modo da poterci connettere ai pod PSMDB creati. Per fare ciò, devi prima elencare gli oggetti segreti, quindi ottenere il valore di yaml in modo da poter ottenere la combinazione utente/password. D'altra parte, puoi usare il comando combinato di seguito con il formato nome utente:password. Vedi l'esempio qui sotto,
$ 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:TQBEV7rtE15quFl5Ora puoi basare il formato nome utente:password e salvarlo da qualche parte in modo sicuro.
Poiché non possiamo connetterci direttamente al server Percona per i nodi MongoDB, dobbiamo creare un nuovo pod che abbia il client mongodb,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -ilInfine, ora siamo pronti per connetterci ai nostri nodi PSMDB,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"In alternativa, puoi connetterti ai singoli nodi e verificarne lo stato di salute. Ad esempio,
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)
}Poiché l'operatore gestisce la coerenza del cluster, ogni volta che un errore o diciamo che un pod è stato eliminato. L'operatore ne avvierà automaticamente uno nuovo. Ad esempio,
$ 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 2d5hOra che siamo tutti a posto. Ovviamente, potrebbe essere necessario esporre la porta in modo da dover gestire le modifiche in deploy/cr.yaml. Puoi fare riferimento qui per affrontarlo.
Conclusione
L'operatore Percona Kubernetes per PSMDB può essere la soluzione completa soprattutto per ambienti containerizzati per la configurazione di Percona Server per MongoDB. È quasi una soluzione completa in quanto ha la ridondanza integrata per il tuo set di repliche, ma l'operatore supporta backup, scalabilità, alta disponibilità e sicurezza.
