MongoDB a Kubernetes je skvělá kombinace, zejména pokud jde o složitost. Přesto MongoDB (PSMDB) společnosti Percona nabízí větší flexibilitu pro databázi NoSQL a přichází také s nástroji, které jsou efektivní pro dnešní produktivitu; nejen on-prem, ale také dostupné pro cloudové domorodce.
Míra přijetí Kubernetes neustále roste. Je rozumné, že technologie musí mít operátora, který bude provádět následující:vytváření, úpravy a mazání položek Percona Server pro prostředí MongoDB. Percona MongoDB Kubernetes Operator obsahuje nezbytná nastavení k8s pro udržení konzistentního serveru Percona pro instanci MongoDB. Jako alternativní možnost to můžete porovnat s https://github.com/kubedb/mongodb, ale KubeDB pro MongoDB nabízí velmi omezené možnosti, zejména na systémech produkční třídy.
Operátoři Percona Kubernetes, kteří se mohou pochlubit svou konfigurací, jsou založeni a dodržují osvědčené postupy pro konfiguraci sady replik PSMDB. Na čem nejvíce záleží, samotný operátor MongoDB poskytuje mnoho výhod, ale nejdůležitější je úspora času a konzistentní prostředí. V tomto blogu si uděláme přehled toho, jak je to výhodné zejména v kontejnerovém prostředí.
Co může tento operátor nabídnout?
Tento operátor je užitečný pro PSMDB používající sadu replik. To znamená, že architektura návrhu vaší databáze musí odpovídat následujícímu schématu
Obrázek vypůjčený z Přehledu návrhu dokumentace společnosti PerconaObrázek vypůjčený z Přehledu návrhu dokumentace společnosti Percona
V současné době jsou pro tohoto operátora dostupné tyto podporované platformy:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15 – 1.17
- Amazon Elastic Container Service pro Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
Jiné platformy Kubernetes mohou také fungovat, ale nebyly testovány.
Omezení zdrojů
Cluster s oficiálně podporovanou platformou obsahuje alespoň tři uzly s následujícími prostředky:
- 2 GB paměti RAM
- 2 vlákna CPU na uzel pro poskytování podů
- nejméně 60 GB dostupného úložiště pro poskytování soukromých svazků
Omezení zabezpečení a/nebo omezení
Kubernetes funguje jako při vytváření Podů, každý Pod má IP adresu v interní virtuální síti clusteru. Vytváření nebo ničení modulů jsou dynamické procesy, proto se nedoporučuje vázat moduly na konkrétní IP adresy přiřazené pro komunikaci mezi moduly. To může způsobit problémy, protože se věci v průběhu času mění v důsledku škálování clusteru, neúmyslných chyb, výpadku stejnosměrného proudu nebo katastrof, nebo pravidelné údržby atd. V takovém případě operátor důrazně doporučuje připojit se k serveru Percona pro MongoDB prostřednictvím interního serveru Kubernetes Názvy DNS v URI (např. mongodb+srv://userAdmin:[email protected]
Tento PSMDB Kubernetes Operator také používá afinitu/anti-afinitu, která poskytuje omezení, podle kterých lze naplánovat spuštění nebo spuštění vašich podů na konkrétním uzlu. Afinita definuje vhodné pody, které lze naplánovat v uzlu, který již má pody se specifickými štítky. Anti-afinita definuje pody, které nejsou vhodné. Tento přístup snižuje náklady tím, že několik modulů s intenzivní výměnou dat zabírá stejnou zónu dostupnosti nebo dokonce stejný uzel, nebo naopak rozmístí moduly na různé uzly nebo dokonce různé zóny dostupnosti pro účely vysoké dostupnosti a vyvažování. I když vám operátor doporučuje nastavit afinitu/anti-afinitu, při používání Minikube to má svá omezení.
Při používání Minikube má následující omezení platná pro konkrétní platformu. Minikube nepodporuje konfigurace clusteru s více uzly kvůli své lokální povaze, která je v rozporu s výchozími požadavky na afinitu operátora. Aby to bylo možné zařídit, instrukce Install Percona Server for MongoDB on Minikube obsahuje další krok, který vypíná požadavek na minimálně tři uzly.
V následující části tohoto blogu nastavíme PMSDB Kubernetes Operator pomocí Minikube a budeme sledovat anti-afinitní nastavení, aby to fungovalo. Jak se to liší od použití anti-afinity, pokud změníte AntiAffinity, zvyšujete rizika pro dostupnost clusteru. Řekněme, že pokud je vaším hlavním účelem nasazení vašeho PSMDB do kontejnerového prostředí rozšířit se a mít vyšší dostupnost a zároveň škálovatelnost, pak to může zmařit účel. Přesto je použití Minikube zejména on-prem a pro testování vašeho nastavení PSMDB proveditelné, ale pro produkční zátěž jistě chcete provozovat uzly na samostatných hostitelích nebo v nastavení prostředí, kde je nepravděpodobné, že by došlo k souběžnému selhání více modulů.
Data v přenosu/Data v klidu
Pro zabezpečení dat pomocí PSMDB nabízí operátor TLS/SSL pro přenos a poté nabízí také šifrování, když jsou data v klidu. Při přenosu si můžete vybrat, zda použijete správce certifikátů nebo si svůj vlastní certifikát vygenerujete ručně. Samozřejmě můžete pro tohoto operátora volitelně použít PSMDB bez TLS. Prohlédněte si jejich dokumentaci ohledně používání TLS.
U klidových dat to vyžaduje změny v jejich PSMDB Kubernetes Operator poté, co si stáhnete větev github, a poté použijete změny v souboru deploy/cr.yaml. Chcete-li to povolit, proveďte následující podle pokynů v dokumentaci:
- Klíč security.enableEncryption by měl být nastaven na hodnotu true (výchozí hodnota).
- Klíč security.encryptionCipherMode by měl určovat správný režim šifry pro dešifrování. Hodnota může být jedna z následujících dvou variant:
- AES256-CBC (výchozí pro operátora a server Percona pro MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-key
Pokud neexistuje tajný klíč šifrovacího klíče, bude automaticky vytvořen. Pokud byste jej chtěli vytvořit sami, počítejte s tím, že klíč musí být 32znakový řetězec zakódovaný v base64.
Ukládání citlivých informací
PSMDB Kubernetes Operator používá Kubernetes Secrets k ukládání a správě citlivých informací. Tajemství Kubernetes vám umožní ukládat a spravovat citlivé informace, jako jsou hesla, tokeny OAuth a klíče ssh. Ukládání důvěrných informací do tajných informací je bezpečnější a flexibilnější než jejich doslovné vkládání do definice modulu nebo do obrázku kontejneru.
U tohoto operátora se ukládají uživatelé a hesla vygenerovaná pro vaše pody a lze je získat pomocí kubectl get secrets
Pro tento blog můj příklad nastavení dosahuje následujícího s dekódovaným výsledkem base64.
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
Každá položka pro zálohování, uživatel clusteru, uživatel monitoru clusteru a uživatel pro administrativní použití se zobrazuje na základě výše uvedeného výsledku.
Další věcí také je, že PSMDB Kubernetes Operator ukládá také přístupové a tajné klíče AWS S3 prostřednictvím Kubernetes Secrets.
Zálohy
Tento operátor podporuje zálohování, což je velmi šikovná funkce. Podporuje on-demand (ruční) zálohování a plánované zálohování a používá zálohovací nástroj Percona Backup pro MongoDB. Vezměte na vědomí, že zálohy se ukládají pouze na AWS S3 nebo jakékoli úložiště kompatibilní s S3.
Naplánované zálohy lze definovat prostřednictvím souboru deploy/cr.yaml, zatímco ruční zálohování lze provést kdykoli, když je potřeba. Pro přístupové a tajné klíče S3 by měly být definovány v souboru deploy/backup-s3.yaml a používá Kubernetes Secrets k ukládání následujících informací, jak jsme zmínili dříve.
Všechny akce podporované pro tento PSMDB Kubernetes Operator jsou následující:
- Provádění naplánovaných záloh
- Zálohování na vyžádání
- Obnovte cluster z dříve uložené zálohy
- Smažte nepotřebnou zálohu
Použití PSMDB Kubernetes Operator s Minikube
V této části si ponecháme jednoduché nastavení pomocí Kubernetes s Minikube, které můžete používat on-prem, aniž byste potřebovali poskytovatele cloudu. Pro cloudové nativní nastavení, zejména pro podnikové a produkční prostředí, si můžete prohlédnout jejich dokumentaci.
Než budeme pokračovat v těchto krocích, mějte na paměti, že jak je uvedeno výše, u Minikube existuje známé omezení, protože nepodporuje konfiguraci clusteru s více uzly, což je v rozporu s výchozími požadavky operátora na afinitu. O tom, jak s tím zacházet, se zmíníme v následujících krocích níže.
Pro tento blog je hostitelský operační systém, kde bude náš Minikube nainstalován, na Ubuntu 18.04 (Bionic Beaver).
Pojďme nainstalovat Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb
Volitelně můžete postupovat podle kroků zde, pokud používáte různé systémy Linux.
Pojďme přidat požadovaný klíč k ověření našich balíčků Kubernetes a nastavení úložiště
$ 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
Nyní nainstalujme požadované balíčky
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectl
Spusťte Minikube definováním paměti, počtu CPU a CIDR, pro které budou mé uzly přiřazeny,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16
Příklady výsledků vypadají jako,
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
Jak jste si všimli, instaluje také nástroje pro správu a správu vašich uzlů nebo modulů.
Nyní zkontrolujme uzly a pody spuštěním následujících příkazů
$ 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
Nyní si stáhněte PSMDB Kubernetes Operator,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operator
Nyní jsme připraveni nasadit operátora,
$ kubectl apply -f deploy/bundle.yaml
Jak již bylo zmíněno, omezení Minikube vyžadují úpravy, aby vše fungovalo podle očekávání. Udělejme následující:
- V závislosti na aktuální kapacitě hardwaru můžete změnit následující, jak je navrženo v dokumentaci. Protože minikube běží lokálně, měl by být upraven výchozí soubor deploy/cr.yaml, aby se operátor přizpůsobil místní instalaci s omezenými prostředky. Změňte následující klíče v sekci replsets:
- komentujte klíče resources.requests.memory a resources.requests.cpu (toto bude vyhovovat operátorovi ve výchozích omezeních minikube)
- nastavte klíč affinity.antiAffinityTopologyKey na hodnotu "none" (operátor nebude moci rozšířit cluster na několik uzlů)
- Přepněte také klíč allowUnsafeConfigurations na hodnotu true (tato možnost vypne operátorovu kontrolu nad konfigurací clusteru, což umožňuje nasadit Percona Server pro MongoDB jako cluster s jedním uzlem).
Nyní jsme připraveni použít změny provedené v souboru deploy/cr.yaml.
$ kubectl apply -f deploy/cr.yaml
V tuto chvíli možná budete moci zkontrolovat stav modulů a zaznamenáte následující pokrok, jak je uvedeno níže,
$ 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
Teď, když už jsme skoro tam. Vygenerovaná tajemství získáme od operátora, abychom se mohli připojit k vytvořeným PSMDB podům. Chcete-li to provést, musíte nejprve uvést tajné objekty a poté získat hodnotu yaml, abyste mohli získat kombinaci uživatele a hesla. Na druhou stranu můžete použít kombinovaný příkaz níže ve formátu uživatelské jméno:heslo. Viz příklad níže,
$ 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
Nyní můžete založit formát uživatelské jméno:heslo a uložit jej někam bezpečně.
Protože se nemůžeme přímo připojit k serveru Percona pro uzly MongoDB, musíme vytvořit nový modul, který bude mít klienta mongodb,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -il
Konečně jsme nyní připraveni připojit se k našim uzlům PSMDB,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"
Případně se můžete připojit k jednotlivým uzlům a zkontrolovat jejich zdraví. Například,
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)
}
Protože operátor spravuje konzistenci clusteru, kdykoli dojde k odstranění selhání nebo řekněme pod. Operátor automaticky spustí nový. Například,
$ 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
Teď, když jsme připraveni. Samozřejmě možná budete muset odhalit port, takže se možná budete muset vypořádat s úpravami v deploy/cr.yaml. Můžete se s tím vypořádat zde.
Závěr
Operátor Percona Kubernetes pro PSMDB může být vaším kompletním řešením zejména pro kontejnerová prostředí pro nastavení vašeho serveru Percona pro MongoDB. Je to téměř kompletní řešení, protože má vestavěnou redundanci pro vaši sadu replik, přesto operátor podporuje zálohování, škálovatelnost, vysokou dostupnost a zabezpečení.