MongoDB och Kubernetes är en fantastisk kombination, särskilt när det gäller komplexitet. Ändå erbjuder Perconas MongoDB (PSMDB) mer flexibilitet för NoSQL-databasen, och den kommer också med verktyg som är effektiva för dagens produktivitet; inte bara on-prem utan även tillgängligt för molninfödda.
Anpassningsgraden för Kubernetes ökar stadigt. Det är rimligt att en teknik måste ha en operatör för att göra följande:skapa, modifiera och ta bort objekt Percona Server för MongoDB-miljö. Percona MongoDB Kubernetes Operator innehåller de nödvändiga k8s-inställningarna för att upprätthålla en konsekvent Percona-server för en MongoDB-instans. Som ett alternativ kan du jämföra detta med https://github.com/kubedb/mongodb, men KubeDB för MongoDB erbjuder mycket begränsade alternativ att erbjuda, särskilt på produktionssystem.
Percona Kubernetes-operatörerna som skryter med sin konfiguration är baserade och följer de bästa metoderna för konfiguration av PSMDB-replikuppsättningen. Det som är viktigast är att operatören för MongoDB själv ger många fördelar men att spara tid, en konsekvent miljö är det viktigaste. I den här bloggen tar vi en översikt över hur detta är fördelaktigt, särskilt i en miljö med containers.
Vad kan den här operatören erbjuda?
Denna operator är användbar för PSMDB som använder en replikuppsättning. Detta betyder att din databasdesignarkitektur måste överensstämma med följande diagram nedan
Bild lånad från Perconas dokumentationsdesignöversiktBild lånad från Perconas översikt över dokumentationsdesign /P>
För närvarande är de plattformar som stöds tillgängliga för denna 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
Andra Kubernetes-plattformar kanske också fungerar men har inte testats.
Resursgränser
Ett kluster som kör en officiellt stödd plattform innehåller minst tre noder, med följande resurser:
- 2 GB RAM
- 2 CPU-trådar per nod för Pods-provisionering
- minst 60 GB tillgängligt lagringsutrymme för provisionering av privata volymer
Säkerhets- och/eller begränsningar
Kubernetes fungerar som när man skapar Pods, varje Pod har en IP-adress i klustrets interna virtuella nätverk. Att skapa eller förstöra Pods är båda dynamiska processer, så det är inte att rekommendera att binda dina pods till specifika IP-adresser som tilldelats för kommunikation mellan Pods. Detta kan orsaka problem eftersom saker förändras över tiden som ett resultat av klusterskalning, oavsiktliga misstag, dc-avbrott eller katastrofer, eller periodiskt underhåll, etc. I så fall rekommenderar operatören dig strängt att ansluta till Percona Server för MongoDB via Kubernetes interna DNS-namn i URI (t.ex. mongodb+srv://userAdmin:[email protected]
Denna PSMDB Kubernetes-operatör använder också affinitet/antiaffinitet som ger begränsningar för vilka dina pods kan schemaläggas att köras eller initieras på en specifik nod. Affinity definierar kvalificerade pods som kan schemaläggas på noden som redan har pods med specifika etiketter. Antiaffinitet definierar pods som inte är kvalificerade. Detta tillvägagångssätt minskar kostnaderna genom att se till att flera pods med intensivt datautbyte upptar samma tillgänglighetszon eller till och med samma nod eller tvärtom sprida podarna på olika noder eller till och med olika tillgänglighetszoner för hög tillgänglighet och balansering. Även om operatören uppmuntrar dig att ställa in affinitet/anti-affinitet, har detta begränsningar när du använder Minikube.
När du använder Minikube har den följande plattformsspecifika begränsningar. Minikube stöder inte klusterkonfigurationer med flera noder på grund av dess lokala karaktär, som är i kollision med operatörens standardkrav för affinitet. För att ordna detta inkluderar instruktionen Install Percona Server for MongoDB på Minikube ett extra steg som stänger av kravet på att ha inte mindre än tre noder.
I följande avsnitt av den här bloggen kommer vi att ställa in PMSDB Kubernetes Operator med Minikube och vi kommer att följa anti-affiniteten för att få det att fungera. Hur skiljer sig detta från att använda antiaffinitet, om du ändrar AntiAffinity ökar du riskerna för klustertillgänglighet. Låt oss säga att om ditt huvudsakliga syfte med att distribuera din PSMDB till en containermiljö är att sprida och ha högre tillgänglighet men ändå skalbarhet, då kan detta motverka syftet. Ändå är det möjligt att använda Minikube, speciellt on-prem och för att testa din PSMDB-installation, men för produktionsbelastningar vill du säkert köra noder på separata värdar, eller i en miljöinstallation så att det på ett sätt är osannolikt att flera pods samtidigt misslyckas.
Data under transport/Data i vila
För datasäkerhet med PSMDB erbjuder operatören TLS/SSL för överföring och erbjuder sedan även kryptering när data är i vila. För i transit, alternativ du kan välja är att använda cert-manager, eller generera ditt eget certifikat manuellt. Naturligtvis kan du valfritt använda PSMDB utan TLS för denna operatör. Kolla in deras dokumentation angående användning av TLS.
För data i vila kräver det ändringar inom deras PSMDB Kubernetes-operatör efter att du laddat ner github-grenen, och tillämpa sedan ändringar på filen deploy/cr.yaml. För att aktivera detta, gör följande enligt dokumentationen:
- Security.enableEncryption-nyckeln ska vara inställd på true (standardvärdet).
- Nyckeln security.encryptionCipherMode bör ange korrekt chifferläge för dekryptering. Värdet kan vara en av följande två varianter:
- AES256-CBC (standard för Operator och Percona Server för MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-key
Krypteringsnyckelhemlighet skapas automatiskt om den inte finns. Om du vill skapa den själv, tänk på att nyckeln måste vara en sträng på 32 tecken kodad i base64.
Lagra känslig information
PSMDB Kubernetes Operator använder Kubernetes Secrets för att lagra och hantera känslig information. Kubernetes Secrets låter dig lagra och hantera känslig information, såsom lösenord, OAuth-tokens och ssh-nycklar. Att lagra konfidentiell information i en hemlighet är säkrare och mer flexibelt än att sätta den ordagrant i en poddefinition eller i en containerbild.
För den här operatören lagras användaren och lösenorden som genereras för dina poddar och kan erhållas med kubectl get secrets
För den här bloggen uppnår min exempelinställning följande med det avkodade base64-resultatet.
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
Varje post för säkerhetskopiering, klusteranvändare, klusterövervakare och användaren för administrativ användning visas baserat på ovanstående resultat.
En annan sak är också att PSMDB Kubernetes Operator lagrar AWS S3-åtkomst och hemliga nycklar genom Kubernetes Secrets.
Säkerhetskopiering
Denna operatör stöder säkerhetskopiering, vilket är en mycket snygg funktion. Den stöder on-demand (manuell) säkerhetskopiering och schemalagd säkerhetskopiering och använder säkerhetskopieringsverktyget Percona Backup för MongoDB. Observera att säkerhetskopior endast lagras på AWS S3 eller någon S3-kompatibel lagring.
Säkerhetskopieringar som är schemalagda kan definieras via filen deploy/cr.yaml, medan en manuell säkerhetskopiering kan göras när som helst när efterfrågan är nödvändig. För S3-åtkomst och hemliga nycklar ska den definieras i filen deploy/backup-s3.yaml och använder Kubernetes Secrets för att lagra följande information som vi nämnde tidigare.
Alla åtgärder som stöds för denna PSMDB Kubernetes-operatör är följande:
- Göra schemalagda säkerhetskopior
- Göra säkerhetskopiering på begäran
- Återställ klustret från en tidigare sparad säkerhetskopia
- Ta bort den onödiga säkerhetskopian
Använda PSMDB Kubernetes Operator med Minikube
I det här avsnittet kommer vi att ha en enkel installation med Kubernetes med Minikube, som du kan använda på plats utan att behöva en molnleverantör. För molnbaserad konfiguration, särskilt för en miljö med mer företags- och produktionskvalitet, kan du gå och kolla in deras dokumentation.
Innan vi fortsätter med stegen, kom ihåg att som nämnts ovan har det funnits en känd begränsning med Minikube eftersom den inte stöder multi-nod klusterkonfiguration som är i kollision med standardkraven för affinitet hos operatören. Vi kommer att nämna detta om hur man hanterar det i följande steg nedan.
För den här bloggen är värdoperativsystemet där vår Minikube kommer att installeras på Ubuntu 18.04 (Bionic Beaver).
Låt oss installera Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb
Alternativt kan du följa stegen här om du använder olika Linux-system.
Låt oss lägga till den nödvändiga nyckeln för att autentisera våra Kubernetes-paket och ställa in förvaret
$ 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
Låt oss nu installera de nödvändiga paketen
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectl
Starta Minikuben som definierar minnet, antalet CPU:er och CIDR för vilka mina noder ska tilldelas,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16
Exempelresultaten visar 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 default
Som du märkte installerar den lika bra verktygen för att hantera och administrera dina noder eller poddar.
Låt oss nu kontrollera noderna och poddarna genom att köra följande kommandon,
$ 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
Ladda nu ner PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operator
Vi är nu redo att distribuera operatören,
$ kubectl apply -f deploy/bundle.yaml
Som nämnts tidigare kräver Minikubes begränsningar justeringar för att få saker att fungera som förväntat. Låt oss göra följande:
- Beroende på din nuvarande hårdvarukapacitet kan du ändra följande enligt dokumentationen. Eftersom minikube körs lokalt, bör standardfilen deploy/cr.yaml redigeras för att anpassa operatören för den lokala installationen med begränsade resurser. Ändra följande nycklar i repset-sektionen:
- kommentar resources.requests.memory och resources.requests.cpu-nycklar (detta passar operatören i minikubes standardbegränsningar)
- ställ affinity.antiAffinityTopologyKey-nyckeln till "ingen" (operatören kommer inte att kunna sprida klustret på flera noder)
- Ändra även allowUnsafeConfigurations-nyckeln till true (det här alternativet stänger av operatörens kontroll över klusterkonfigurationen, vilket gör det möjligt att distribuera Percona Server för MongoDB som ett ennodskluster).
Nu är vi redo att tillämpa ändringarna som gjorts i filen deploy/cr.yaml.
$ kubectl apply -f deploy/cr.yaml
Vid det här laget kanske du kan kontrollera poddarnas status och du kommer att märka följande framsteg precis som nedan,
$ 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 när vi nästan är framme. Vi får de genererade hemligheterna av operatören så att vi kan ansluta till de skapade PSMDB-podarna. För att göra det måste du först lista de hemliga objekten och sedan hämta värdet på yaml så att du kan få användar/lösenordskombinationen. Å andra sidan kan du använda det kombinerade kommandot nedan med användarnamn:lösenordsformatet. Se exemplet nedan,
$ 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 kan du basera användarnamn:lösenordsformatet och spara det någonstans säkert.
Eftersom vi inte kan ansluta direkt till Percona Server för MongoDB-noder, måste vi skapa 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 -il
Slutligen är vi nu redo att ansluta till våra PSMDB-noder nu,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"
Alternativt kan du ansluta till de enskilda noderna och kontrollera dess hälsa. Till exempel,
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)
}
Eftersom operatören hanterar konsistensen av klustret, när ett fel eller låt säga en pod har tagits bort. Operatören kommer automatiskt att initiera en ny. Till exempel,
$ 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 när vi är klara. Naturligtvis kan du behöva exponera porten så att du kan behöva ta itu med justeringar i deploy/cr.yaml. Du kan hänvisa hit för att hantera det.
Slutsats
Percona Kubernetes Operator för PSMDB kan vara din kompletta lösning speciellt för containeriserade miljöer för din Percona Server för MongoDB-installation. Det är nästan en komplett lösning eftersom den har inbyggd redundans för din replikuppsättning men operatören stöder säkerhetskopiering, skalbarhet, hög tillgänglighet och säkerhet.