MongoDB en Kubernetes is een geweldige combinatie, vooral wat betreft complexiteit. Toch biedt Percona's MongoDB (PSMDB) meer flexibiliteit voor de NoSQL-database, en het wordt ook geleverd met tools die efficiënt zijn voor de hedendaagse productiviteit; niet alleen on-premise maar ook beschikbaar voor cloud natives.
De acceptatiegraad van Kubernetes neemt gestaag toe. Het is redelijk dat een technologie een operator moet hebben om het volgende te doen:creatie, wijziging en verwijdering van items Percona Server voor MongoDB-omgeving. De Percona MongoDB Kubernetes-operator bevat de benodigde k8s-instellingen om een consistente Percona-server voor een MongoDB-instantie te behouden. Als alternatieve optie kun je dit vergelijken met https://github.com/kubedb/mongoDB, maar de KubeDB voor MongoDB biedt zeer beperkte opties, vooral op productiesystemen.
De Percona Kubernetes-operators die trots zijn op hun configuratie, zijn gebaseerd en volgen de best practices voor de configuratie van de PSMDB-replicaset. Het belangrijkste is dat de operator voor MongoDB zelf veel voordelen biedt, maar tijdwinst en een consistente omgeving zijn het belangrijkste. In deze blog zullen we een overzicht geven van hoe dit voordelig is, vooral in een gecontaineriseerde omgeving.
Wat kan deze operator bieden?
Deze operator is handig voor PSMDB met een replicaset. Dit betekent dat uw database-ontwerparchitectuur moet voldoen aan het onderstaande diagram
Afbeelding geleend van Percona's Documentation Design OverviewAfbeelding geleend van Percona's Documentation Design Overview
Momenteel zijn de ondersteunde platforms die beschikbaar zijn voor deze operator:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1,15 - 1,17
- Amazon Elastic Container Service voor Kubernetes (EKS) 1,15
- Minikube 1.10
- VMWare Tanzu
Andere Kubernetes-platforms werken mogelijk ook, maar zijn niet getest.
Bronlimieten
Een cluster met een officieel ondersteund platform bevat ten minste drie Nodes, met de volgende bronnen:
- 2 GB RAM
- 2 CPU-threads per Node voor Pods-voorziening
- ten minste 60 GB beschikbare opslagruimte voor het inrichten van privévolumes
Beveiliging en/of beperkingen Beperkingen
De Kubernetes werkt als bij het maken van Pods, elke Pod heeft een IP-adres in het interne virtuele netwerk van het cluster. Het maken of vernietigen van pods zijn beide dynamische processen, dus het is niet aan te raden om uw pods te binden aan specifieke IP-adressen die zijn toegewezen voor communicatie tussen pods. Dit kan problemen veroorzaken als dingen in de loop van de tijd veranderen als gevolg van de clusterschaling, onopzettelijke fouten, dc-storingen of rampen, of periodiek onderhoud, enz. In dat geval raadt de operator u ten zeerste aan om verbinding te maken met Percona Server for MongoDB via Kubernetes internal DNS-namen in URI (bijv. mongodb+srv://userAdmin:[email protected]
Deze PSMDB Kubernetes-operator maakt ook gebruik van affiniteit/anti-affiniteit die beperkingen biedt waaraan uw pods kunnen worden gepland om te worden uitgevoerd of gestart op een specifiek knooppunt. Affiniteit definieert geschikte pods die kunnen worden gepland op het knooppunt dat al pods met specifieke labels heeft. Anti-affiniteit definieert pods die niet in aanmerking komen. Deze aanpak verlaagt de kosten door ervoor te zorgen dat meerdere pods met intensieve gegevensuitwisseling dezelfde beschikbaarheidszone of zelfs hetzelfde knooppunt bezetten of, integendeel, de pods over verschillende knooppunten of zelfs verschillende beschikbaarheidszones te spreiden voor hoge beschikbaarheid en balanceringsdoeleinden. Hoewel de operator u aanmoedigt om affiniteit/anti-affiniteit in te stellen, heeft dit beperkingen bij het gebruik van Minikube.
Bij gebruik van Minikube heeft het de volgende platformspecifieke beperkingen. Minikube ondersteunt geen clusterconfiguraties met meerdere knooppunten vanwege het lokale karakter, wat in strijd is met de standaardaffiniteitsvereisten van de operator. Om dit te regelen, bevat de instructie Percona Server voor MongoDB op Minikube installeren een extra stap die de vereiste van niet minder dan drie knooppunten uitschakelt.
In het volgende gedeelte van deze blog zullen we PMSDB Kubernetes Operator instellen met Minikube en we zullen de anti-affiniteitsregeling volgen om het te laten werken. Hoe verschilt dit van het gebruik van anti-affiniteit? Als u AntiAffinity wijzigt, verhoogt u de risico's voor de beschikbaarheid van clusters. Laten we zeggen dat als uw belangrijkste doel van het implementeren van uw PSMDB in een gecontaineriseerde omgeving is om zich te verspreiden en een hogere beschikbaarheid maar schaalbaarheid te hebben, dan zou dit het doel teniet kunnen doen. Maar Minikube gebruiken, vooral on-prem en voor het testen van je PSMDB-setup is goed te doen, maar voor productieworkloads wil je zeker nodes op afzonderlijke hosts laten draaien, of in een omgevingsconfiguratie zodanig dat het onwaarschijnlijk is dat gelijktijdige storing van meerdere pods optreedt.
Gegevens in transit/Gegevens in rust
Voor gegevensbeveiliging met PSMDB biedt de operator TLS/SSL voor in transit en biedt vervolgens ook codering wanneer gegevens in rust zijn. Voor onderweg kunt u kiezen voor het gebruik van cert-manager, of het handmatig genereren van uw eigen certificaat. Natuurlijk kunt u optioneel PSMDB gebruiken zonder TLS voor deze operator. Bekijk hun documentatie met betrekking tot het gebruik van TLS.
Voor data in rust zijn er wijzigingen nodig binnen hun PSMDB Kubernetes-operator nadat je de github-branch hebt gedownload en vervolgens wijzigingen hebt toegepast op het bestand deploy/cr.yaml. Om dit in te schakelen, doet u het volgende zoals voorgesteld in de documentatie:
- De security.enableEncryption-sleutel moet worden ingesteld op true (de standaardwaarde).
- De security.encryptionCipherMode-sleutel moet de juiste coderingsmodus voor decodering specificeren. De waarde kan een van de volgende twee varianten zijn:
- AES256-CBC (de standaardversie voor de Operator en Percona Server voor MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-key
Versleutelingssleutelgeheim wordt automatisch aangemaakt als het niet bestaat. Als u het zelf wilt maken, houd er dan rekening mee dat de sleutel een tekenreeks van 32 tekens moet zijn die is gecodeerd in base64.
Gevoelige informatie opslaan
De PSMDB Kubernetes Operator gebruikt Kubernetes Secrets om gevoelige informatie op te slaan en te beheren. Met de Kubernetes-geheimen kunt u gevoelige informatie opslaan en beheren, zoals wachtwoorden, OAuth-tokens en ssh-sleutels. Het opslaan van vertrouwelijke informatie in een geheim is veiliger en flexibeler dan het woordelijk in een poddefinitie of in een containerafbeelding te plaatsen.
Voor deze operator worden de gebruiker en wachtwoorden die zijn gegenereerd voor uw pods opgeslagen en kunnen worden verkregen met kubectl get secrets
Voor deze blog bereikt mijn voorbeeldconfiguratie het volgende met het gedecodeerde base64-resultaat.
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
Elke vermelding voor back-up, clustergebruiker, clustermonitorgebruiker en de gebruiker voor administratief gebruik wordt weergegeven op basis van het bovenstaande resultaat.
Een ander ding is dat PSMDB Kubernetes Operator ook de AWS S3-toegang en geheime sleutels opslaat via Kubernetes Secrets.
Back-ups
Deze operator ondersteunt back-ups, wat een erg handige functie is. Het ondersteunt on-demand (handmatige) back-up en geplande back-up en maakt gebruik van de back-uptool Percona Backup voor MongoDB. Houd er rekening mee dat back-ups alleen worden opgeslagen op AWS S3 of een S3-compatibele opslag.
Geplande back-ups kunnen worden gedefinieerd via het bestand deploy/cr.yaml, terwijl het maken van een handmatige back-up op elk moment kan worden gedaan wanneer dat nodig is. Voor S3-toegang en geheime sleutels wordt deze gedefinieerd in het bestand deploy/backup-s3.yaml en gebruikt Kubernetes Secrets om de volgende informatie op te slaan, zoals we eerder vermeldden.
Alle acties die worden ondersteund voor deze PSMDB Kubernetes-operator zijn de volgende:
- Geplande back-ups maken
- On-demand back-up maken
- Herstel het cluster vanaf een eerder opgeslagen back-up
- Verwijder de onnodige back-up
PSMDB Kubernetes-operator gebruiken met Minikube
In dit gedeelte houden we een eenvoudige installatie met Kubernetes met Minikube, die je op locatie kunt gebruiken zonder dat je een cloudprovider nodig hebt. Voor cloud-native setup, vooral voor een meer enterprise en productie-grade omgeving, kun je hun documentatie gaan bekijken.
Voordat we verder gaan met de stappen, moet u er rekening mee houden dat, zoals hierboven vermeld, er een bekende beperking is met Minikube omdat het geen clusterconfiguratie met meerdere knooppunten ondersteunt, wat in strijd is met de standaardaffiniteitsvereisten van de operator. We zullen dit in de volgende stappen hieronder vermelden over hoe u ermee om moet gaan.
Voor deze blog is het host-besturingssysteem waarop onze Minikube wordt geïnstalleerd Ubuntu 18.04 (Bionic Beaver).
Laten we Minikube installeren
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb
Optioneel kun je de stappen hier volgen als je op verschillende Linux-systemen werkt.
Laten we de vereiste sleutel toevoegen om onze Kubernetes-pakketten te verifiëren en de repository in te stellen
$ 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
Laten we nu de vereiste pakketten installeren
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectl
Start de Minikube en definieer het geheugen, het aantal CPU's en de CIDR waaraan mijn nodes moeten worden toegewezen,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16
De voorbeeldresultaten tonen als,
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
Zoals je hebt opgemerkt, installeert het net zo goed de hulpprogramma's om je nodes of pods te beheren en te beheren.
Laten we nu de knooppunten en pods controleren door de volgende opdrachten uit te voeren,
$ 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
Download nu de PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operator
We zijn nu klaar om de operator in te zetten,
$ kubectl apply -f deploy/bundle.yaml
Zoals eerder vermeld, vereisen de beperkingen van Minikube aanpassingen om alles te laten werken zoals verwacht. Laten we het volgende doen:
- Afhankelijk van uw huidige hardwarecapaciteit, kunt u het volgende wijzigen zoals voorgesteld in de documentatie. Aangezien minikube lokaal wordt uitgevoerd, moet het standaard deploy/cr.yaml-bestand worden bewerkt om de Operator aan te passen voor de lokale installatie met beperkte middelen. Wijzig de volgende sleutels in de sectie replsets:
- commentaar resources.requests.memory en resources.requests.cpu-sleutels (dit past bij de operator in de standaardbeperkingen van minikube)
- stel de sleutel affinity.antiAffinityTopologyKey in op "none" (de operator kan het cluster niet over meerdere nodes verspreiden)
- Schakel ook allowUnsafeConfigurations-sleutel in op true (deze optie schakelt de controle van de operator over de clusterconfiguratie uit, waardoor het mogelijk wordt om Percona Server voor MongoDB te implementeren als een cluster met één knooppunt).
Nu zijn we klaar om de aangebrachte wijzigingen aan het bestand deploy/cr.yaml toe te passen.
$ kubectl apply -f deploy/cr.yaml
Op dit punt kunt u mogelijk de status van de pods controleren en ziet u de volgende voortgang, zoals hieronder,
$ 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
Nu we er bijna zijn. We krijgen de gegenereerde geheimen van de operator zodat we verbinding kunnen maken met de gemaakte PSMDB-pods. Om dat te doen, moet u eerst de geheime objecten weergeven en vervolgens de waarde van de yaml ophalen, zodat u de combinatie gebruiker/wachtwoord kunt krijgen. Aan de andere kant kunt u de onderstaande gecombineerde opdracht gebruiken met de indeling gebruikersnaam:wachtwoord. Zie onderstaand voorbeeld,
$ 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
Nu kunt u de indeling gebruikersnaam:wachtwoord baseren en deze ergens veilig opslaan.
Aangezien we niet rechtstreeks verbinding kunnen maken met de Percona Server voor MongoDB-knooppunten, moeten we een nieuwe pod maken met de mongodb-client,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -il
Ten slotte zijn we nu klaar om verbinding te maken met onze PSMDB-knooppunten,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"
Als alternatief kunt u verbinding maken met de afzonderlijke knooppunten en de status ervan controleren. Bijvoorbeeld,
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)
}
Omdat de operator de consistentie van het cluster beheert, wanneer een storing of, laten we zeggen, een pod is verwijderd. De operator start automatisch een nieuwe. Bijvoorbeeld,
$ 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
Nu we er helemaal klaar voor zijn. Het kan natuurlijk zijn dat u de poort moet vrijgeven, zodat u mogelijk te maken krijgt met aanpassingen in deploy/cr.yaml. U kunt hier verwijzen om ermee om te gaan.
Conclusie
De Percona Kubernetes Operator voor PSMDB kan uw complete oplossing zijn, speciaal voor gecontaineriseerde omgevingen voor uw Percona Server voor MongoDB-installatie. Het is bijna een complete oplossing omdat er redundantie is ingebouwd voor uw replicaset, maar de operator ondersteunt back-up, schaalbaarheid, hoge beschikbaarheid en beveiliging.