MongoDB og Kubernetes er en fantastisk kombination, især med hensyn til kompleksitet. Alligevel tilbyder Perconas MongoDB (PSMDB) mere fleksibilitet til NoSQL-databasen, og den kommer også med værktøjer, der er effektive til nutidens produktivitet; ikke kun on-prem, men også tilgængelig for cloud natives.
Anvendelsesraten for Kubernetes er støt stigende. Det er rimeligt, at en teknologi skal have en operatør til at gøre følgende:oprettelse, ændring og sletning af elementer Percona Server til MongoDB-miljø. Percona MongoDB Kubernetes Operator indeholder de nødvendige k8s-indstillinger for at opretholde en konsistent Percona-server for en MongoDB-instans. Som en alternativ mulighed kan du sammenligne dette med https://github.com/kubedb/mongodb, men KubeDB for MongoDB tilbyder meget begrænsede muligheder, især på produktionssystemer.
Percona Kubernetes-operatørerne, der kan prale af sin konfiguration, er baseret og følger de bedste praksisser for konfiguration af PSMDB-replikasæt. Det, der betyder mest, giver selve operatøren for MongoDB mange fordele, men tidsbesparelse og et konsistent miljø er det vigtigste. I denne blog tager vi et overblik over, hvordan dette er gavnligt, især i et containeriseret miljø.
Hvad kan denne operatør tilbyde?
Denne operator er nyttig til PSMDB ved brug af et replikasæt. Det betyder, at din databasedesignarkitektur skal være i overensstemmelse med nedenstående diagram
Billede lånt fra Perconas Documentation Design OverviewBillede lånt fra Percona<'s Documentation Design Overview /P>
I øjeblikket er de tilgængelige understøttede platforme for denne operatør:
- 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
Andre Kubernetes-platforme fungerer muligvis også, men er ikke blevet testet.
Ressourcegrænser
En klynge, der kører en officielt understøttet platform, indeholder mindst tre noder med følgende ressourcer:
- 2 GB RAM
- 2 CPU-tråde pr. Node for Pods-klargøring
- mindst 60 GB tilgængelig lagerplads til levering af Private Volumes
Sikkerheds- og/eller begrænsninger
Kubernetes fungerer som, når der oprettes Pods, hver Pod har en IP-adresse i klyngens interne virtuelle netværk. Oprettelse eller ødelæggelse af pods er begge dynamiske processer, så det kan ikke anbefales at binde dine pods til specifikke IP-adresser, der er tildelt til kommunikation mellem pods. Dette kan forårsage problemer, da tingene ændrer sig over tid som følge af klyngeskalering, utilsigtede fejl, dc-udfald eller katastrofer, eller periodisk vedligeholdelse osv. I så fald anbefaler operatøren dig strengt at oprette forbindelse til Percona Server til MongoDB via Kubernetes internt DNS-navne i URI (f.eks. mongodb+srv://userAdmin:[email protected]
Denne PSMDB Kubernetes-operatør bruger også affinitet/anti-affinitet, som giver begrænsninger, som dine pods kan planlægges til at køre eller initieret på en specifik node. Affinitet definerer kvalificerede pods, der kan planlægges på den node, som allerede har pods med specifikke etiketter. Anti-affinitet definerer pods, der ikke er kvalificerede. Denne tilgang reducerer omkostningerne ved at sikre, at flere pods med intensiv dataudveksling optager den samme tilgængelighedszone eller endda den samme node, eller tværtimod at sprede pods på forskellige noder eller endda forskellige tilgængelighedszoner med henblik på høj tilgængelighed og balancering. Selvom operatøren opfordrer dig til at indstille affinitet/anti-affinitet, har dette dog begrænsninger, når du bruger Minikube.
Når du bruger Minikube, har den følgende platformspecifikke begrænsninger. Minikube understøtter ikke multi-node klyngekonfigurationer på grund af dens lokale karakter, som er i kollision med standardkravene til affinitet for operatøren. For at arrangere dette inkluderer instruktionen Installer Percona Server til MongoDB på Minikube et ekstra trin, som deaktiverer kravet om at have ikke mindre end tre noder.
I den følgende sektion af denne blog vil vi konfigurere PMSDB Kubernetes Operator ved hjælp af Minikube, og vi følger anti-affiniteten for at få det til at fungere. Hvordan adskiller dette sig fra at bruge anti-affinitet, hvis du ændrer AntiAffinity, øger du risikoen for klyngens tilgængelighed. Lad os sige, at hvis dit hovedformål med at implementere din PSMDB til et containeriseret miljø er at sprede sig og have højere tilgængelighed og skalerbarhed, så kan dette besejre formålet. Alligevel er det muligt at bruge Minikube, især on-prem og til at teste din PSMDB-opsætning, men for produktions-arbejdsbelastninger vil du helt sikkert gerne køre noder på separate værter eller i en miljøopsætning, så det på en måde er usandsynligt, at der vil ske samtidige fejl i flere pods.
Data i transit/data i hvile
Til datasikkerhed med PSMDB tilbyder operatøren TLS/SSL til under transport, og tilbyder derefter også kryptering, når data er i ro. For i transit kan du vælge at bruge cert-manager eller generere dit eget certifikat manuelt. Selvfølgelig kan du valgfrit bruge PSMDB uden TLS til denne operatør. Tjek deres dokumentation med hensyn til brug af TLS.
For data i hvile kræver det ændringer i deres PSMDB Kubernetes-operatør, efter du har downloadet github-grenen, og anvend derefter ændringer på deploy/cr.yaml-filen. For at aktivere dette skal du gøre følgende som foreslået i dokumentationen:
- nøglen security.enableEncryption skal indstilles til sand (standardværdien).
- nøglen security.encryptionCipherMode skal angive den korrekte chiffertilstand til dekryptering. Værdien kan være en af følgende to varianter:
- AES256-CBC (standarden for Operator og Percona Server til MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-keyHemmeligheden for krypteringsnøgle oprettes automatisk, hvis den ikke eksisterer. Hvis du gerne vil oprette det selv, skal du tage højde for, at nøglen skal være en streng på 32 tegn kodet i base64.
Lagring af følsomme oplysninger
PSMDB Kubernetes Operator bruger Kubernetes Secrets til at gemme og administrere følsomme oplysninger. Kubernetes Secrets lader dig gemme og administrere følsomme oplysninger, såsom adgangskoder, OAuth-tokens og ssh-nøgler. Lagring af fortrolige oplysninger i en hemmelighed er sikrere og mere fleksibel end at sætte dem ordret i en pod-definition eller i et containerbillede.
For denne operatør er brugeren og adgangskoder, der er genereret til dine pods, gemt og kan hentes ved hjælp af kubectl get secrets
For denne blog opnår mit eksempelopsætning følgende med det afkodede base64-resultat.
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
userAdminHver post for backup, klyngebruger, klyngemonitorbruger og brugeren til administrativ brug viser baseret på ovenstående resultat.
En anden ting er også, at PSMDB Kubernetes Operator også gemmer AWS S3-adgang og hemmelige nøgler gennem Kubernetes Secrets.
Sikkerhedskopier
Denne operatør understøtter sikkerhedskopiering, hvilket er en meget smart funktion. Det understøtter on-demand (manuel) backup og planlagt backup og bruger backupværktøjet Percona Backup for MongoDB. Vær opmærksom på, at sikkerhedskopier kun gemmes på AWS S3 eller et andet S3-kompatibelt lager.
Sikkerhedskopier, der er planlagt, kan defineres gennem filen deploy/cr.yaml, hvorimod man kan tage en manuel sikkerhedskopiering når som helst, når efterspørgslen er nødvendig. For S3-adgang og hemmelige nøgler skal det defineres i filen deploy/backup-s3.yaml og bruger Kubernetes Secrets til at gemme følgende information, som vi nævnte tidligere.
Alle handlinger, der understøttes for denne PSMDB Kubernetes Operator, er følgende:
- Lage planlagte sikkerhedskopier
- Sikkerhedskopiering efter behov
- Gendan klyngen fra en tidligere gemt sikkerhedskopi
- Slet den unødvendige sikkerhedskopi
Brug af PSMDB Kubernetes Operator med Minikube
I dette afsnit holder vi en enkel opsætning ved hjælp af Kubernetes med Minikube, som du kan bruge on-prem uden behov for en cloud-udbyder. For cloud-native opsætning, især for et mere virksomheds- og produktionsmiljø, kan du gå til kassen af deres dokumentation.
Før vi fortsætter med trinene, skal du huske på, at der som nævnt ovenfor har været en kendt begrænsning med Minikube, da den ikke understøtter multi-node klyngekonfiguration, som er i kollision med operatørens standard affinitetskrav. Vi vil nævne dette om, hvordan du håndterer det i de følgende trin nedenfor.
For denne blog er værts-operativsystemet, hvor vores Minikube vil blive installeret, på Ubuntu 18.04 (Bionic Beaver).
Lad os installere Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.debDu kan eventuelt følge trinene her, hvis du er på forskellige Linux-systemer.
Lad os tilføje den nødvendige nøgle for at godkende vores Kubernetes-pakker og konfigurere lageret
$ 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
eofLad os nu installere de nødvendige pakker
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectlStart Minikuben, der definerer hukommelsen, antallet af CPU'er og CIDR'en, som mine noder skal tildeles til,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16Eksempelresultaterne viser som,
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 defaultSom du har bemærket, installerer den også hjælpeværktøjerne til at administrere og administrere dine noder eller pods.
Lad os nu tjekke noderne og pods ved at køre følgende kommandoer,
$ 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.8Download nu PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operatorVi er nu klar til at implementere operatøren,
$ kubectl apply -f deploy/bundle.yamlSom tidligere nævnt kræver Minikubes begrænsninger justeringer for at få tingene til at køre som forventet. Lad os gøre følgende:
- Afhængigt af din nuværende hardwarekapacitet kan du ændre følgende som foreslået i dokumentationen. Da minikube kører lokalt, bør standardfilen deploy/cr.yaml redigeres for at tilpasse operatøren til den lokale installation med begrænsede ressourcer. Skift følgende nøgler i replset-sektionen:
- kommentar resources.requests.memory og resources.requests.cpu-nøgler (dette passer til operatøren i minikubes standardbegrænsninger)
- indstil affinity.antiAffinityTopologyKey nøglen til "ingen" (operatøren vil ikke være i stand til at sprede klyngen på flere noder)
- Skift også allowUnsafeConfigurations-nøglen til sand (denne mulighed slår operatørens kontrol over klyngekonfigurationen fra, hvilket gør det muligt at implementere Percona Server til MongoDB som en én-node-klynge).
Nu er vi klar til at anvende ændringerne i filen deploy/cr.yaml.
$ kubectl apply -f deploy/cr.yamlPå dette tidspunkt er du muligvis i stand til at tjekke status for pods, og du vil bemærke følgende fremskridt ligesom nedenfor,
$ 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 33mNu hvor vi næsten er der. Vi får de genererede hemmeligheder af operatøren, så vi kan oprette forbindelse til de oprettede PSMDB-pods. For at gøre det skal du først liste de hemmelige objekter og derefter få værdien af yaml, så du kan få bruger/adgangskode-kombinationen. På den anden side kan du bruge den kombinerede kommando nedenfor med formatet brugernavn:adgangskode. Se eksemplet nedenfor,
$ 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:TQBEV7rtE15quFl5Nu kan du basere brugernavn:adgangskode-formatet og gemme det et sikkert sted.
Da vi ikke kan oprette direkte forbindelse til Percona-serveren til MongoDB-noder, skal vi oprette en ny pod, som har mongodb-klienten,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -ilEndelig er vi nu klar til at oprette forbindelse til vores PSMDB-noder nu,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"Alternativt kan du oprette forbindelse til de enkelte noder og tjekke deres helbred. For eksempel
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)
}Da operatøren styrer konsistensen af klyngen, når en fejl eller lad sige en pod er blevet slettet. Operatøren vil automatisk starte en ny. For eksempel
$ 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 2d5hNu hvor vi er klar. Selvfølgelig skal du muligvis blotlægge porten, så du måske skal håndtere justeringer i deploy/cr.yaml. Du kan henvise her til at håndtere det.
Konklusion
Percona Kubernetes Operator til PSMDB kan være din komplette løsning, specielt til containeriserede miljøer til din Percona Server til MongoDB-opsætning. Det er næsten en komplet løsning, da den har indbygget redundans til dit replikasæt, men operatøren understøtter backup, skalerbarhed, høj tilgængelighed og sikkerhed.