MongoDB und Kubernetes sind eine großartige Kombination, insbesondere im Hinblick auf die Komplexität. MongoDB (PSMDB) von Percona bietet jedoch mehr Flexibilität für die NoSQL-Datenbank und verfügt außerdem über Tools, die für die heutige Produktivität effizient sind. nicht nur lokal, sondern auch für Cloud-Natives verfügbar.
Die Adoptionsrate von Kubernetes nimmt stetig zu. Es ist vernünftig, dass eine Technologie einen Operator haben muss, um Folgendes zu tun:Erstellung, Änderung und Löschung von Elementen Percona Server für die MongoDB-Umgebung. Der Percona MongoDB Kubernetes Operator enthält die erforderlichen k8s-Einstellungen, um einen konsistenten Percona-Server für eine MongoDB-Instanz zu verwalten. Als alternative Option können Sie dies mit https://github.com/kubedb/mongodb vergleichen, aber KubeDB für MongoDB bietet nur sehr begrenzte Optionen, insbesondere auf Produktionssystemen.
Die Percona Kubernetes Operators, die sich ihrer Konfiguration rühmen, basieren und befolgen die Best Practices für die Konfiguration des PSMDB-Replikatsatzes. Am wichtigsten ist, dass der Operator für MongoDB selbst viele Vorteile bietet, aber Zeitersparnis und eine konsistente Umgebung sind am wichtigsten. In diesem Blog geben wir einen Überblick darüber, wie dies insbesondere in einer containerisierten Umgebung von Vorteil ist.
Was bietet dieser Betreiber?
Dieser Operator ist nützlich für die PSMDB, die einen Replikatsatz verwendet. Das bedeutet, dass Ihre Datenbankentwurfsarchitektur dem folgenden Diagramm entsprechen muss
Bild entliehen aus Perconas Documentation Design OverviewBild entlehnt aus Perconas Documentation Design Overview
Derzeit sind die für diesen Operator verfügbaren unterstützten Plattformen:
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15–1.17
- Amazon Elastic Container Service für Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
Andere Kubernetes-Plattformen können ebenfalls funktionieren, wurden aber nicht getestet.
Ressourcenlimits
Ein Cluster, auf dem eine offiziell unterstützte Plattform ausgeführt wird, enthält mindestens drei Knoten mit den folgenden Ressourcen:
- 2 GB RAM
- 2 CPU-Threads pro Knoten für Pods-Bereitstellung
- mindestens 60 GB verfügbarer Speicherplatz für die Bereitstellung privater Volumes
Sicherheits- und/oder Einschränkungen
Kubernetes funktioniert wie beim Erstellen von Pods, jeder Pod hat eine IP-Adresse im internen virtuellen Netzwerk des Clusters. Das Erstellen oder Zerstören von Pods sind beides dynamische Prozesse, daher ist es nicht empfehlenswert, Ihre Pods an bestimmte IP-Adressen zu binden, die für die Kommunikation zwischen Pods zugewiesen sind. Dies kann zu Problemen führen, wenn sich die Dinge im Laufe der Zeit aufgrund der Clusterskalierung, versehentlicher Fehler, Gleichstromausfällen oder -katastrophen oder regelmäßiger Wartung usw. ändern. In diesem Fall empfiehlt der Betreiber Ihnen dringend, sich über Kubernetes intern mit Percona Server für MongoDB zu verbinden DNS-Namen in URI (z. B. mongodb+srv://userAdmin:[email protected]
Dieser PSMDB-Kubernetes-Operator verwendet auch Affinität/Anti-Affinität, die Einschränkungen bereitstellt, für die Ihre Pods zur Ausführung geplant oder auf einem bestimmten Knoten initiiert werden können. Affinity definiert berechtigte Pods, die auf dem Knoten geplant werden können, der bereits Pods mit bestimmten Labels hat. Anti-Affinität definiert Pods, die nicht geeignet sind. Dieser Ansatz reduziert die Kosten, indem sichergestellt wird, dass mehrere Pods mit intensivem Datenaustausch dieselbe Verfügbarkeitszone oder sogar denselben Knoten belegen, oder im Gegenteil die Pods für Hochverfügbarkeits- und Ausgleichszwecke auf verschiedene Knoten oder sogar verschiedene Verfügbarkeitszonen verteilen. Obwohl der Operator Sie ermutigt, Affinität/Anti-Affinität festzulegen, hat dies bei der Verwendung von Minikube Einschränkungen.
Bei Verwendung von Minikube gelten die folgenden plattformspezifischen Einschränkungen. Minikube unterstützt aufgrund seiner lokalen Natur keine Multi-Node-Cluster-Konfigurationen, die mit den standardmäßigen Affinitätsanforderungen des Betreibers kollidieren. Um dies zu arrangieren, enthält die Anweisung zum Installieren von Percona Server für MongoDB auf Minikube einen zusätzlichen Schritt, der die Anforderung von nicht weniger als drei Knoten deaktiviert.
Im folgenden Abschnitt dieses Blogs werden wir PMSDB Kubernetes Operator mit Minikube einrichten und den Anti-Affinitäts-Ansatz verfolgen, damit es funktioniert. Wie unterscheidet sich dies von der Verwendung von Anti-Affinität? Wenn Sie Anti-Affinität ändern, erhöhen Sie die Risiken für die Cluster-Verfügbarkeit. Nehmen wir an, wenn Ihr Hauptzweck der Bereitstellung Ihrer PSMDB in einer containerisierten Umgebung darin besteht, sich zu verbreiten und eine höhere Verfügbarkeit bei gleichzeitiger Skalierbarkeit zu erreichen, dann könnte dies den Zweck verfehlen. Die Verwendung von Minikube, insbesondere vor Ort und zum Testen Ihres PSMDB-Setups, ist jedoch machbar, aber für Produktions-Workloads möchten Sie sicherlich Knoten auf separaten Hosts oder in einer Umgebung ausführen, die so eingerichtet ist, dass ein gleichzeitiger Ausfall mehrerer Pods unwahrscheinlich ist.
Daten unterwegs/Daten im Ruhezustand
Für die Datensicherheit mit PSMDB bietet der Betreiber TLS/SSL für die Übertragung an und bietet dann auch Verschlüsselung, wenn Daten ruhen. Für die Übertragung können Sie zwischen der Verwendung von cert-manager oder der manuellen Generierung Ihres eigenen Zertifikats wählen. Natürlich können Sie für diesen Operator auch PSMDB ohne TLS verwenden. Schauen Sie sich ihre Dokumentation in Bezug auf die Verwendung von TLS an.
Für ruhende Daten sind Änderungen in ihrem PSMDB-Kubernetes-Operator erforderlich, nachdem Sie den Github-Zweig heruntergeladen haben, und wenden Sie dann Änderungen auf die Datei deploy/cr.yaml an. Um dies zu aktivieren, gehen Sie wie in der Dokumentation vorgeschlagen wie folgt vor:
- Der key security.enableEncryption sollte auf true (den Standardwert) gesetzt werden.
- Der Schlüssel security.encryptionCipherMode sollte den richtigen Verschlüsselungsmodus für die Entschlüsselung angeben. Der Wert kann eine der beiden folgenden Varianten sein:
- AES256-CBC (der Standard für den Operator und 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-keyDas Geheimnis des Verschlüsselungsschlüssels wird automatisch erstellt, wenn es nicht existiert. Wenn Sie ihn selbst erstellen möchten, beachten Sie, dass der Schlüssel eine 32-stellige Zeichenfolge sein muss, die in Base64 codiert ist.
Speicherung sensibler Informationen
Der PSMDB Kubernetes Operator verwendet Kubernetes Secrets zum Speichern und Verwalten vertraulicher Informationen. Mit den Kubernetes Secrets können Sie vertrauliche Informationen wie Passwörter, OAuth-Token und SSH-Schlüssel speichern und verwalten. Das Speichern vertraulicher Informationen in einem Secret ist sicherer und flexibler, als sie wörtlich in eine Pod-Definition oder in ein Container-Image zu schreiben.
Für diesen Operator werden die für Ihre Pods generierten Benutzer und Passwörter gespeichert und können mit kubectl get secrets
Für diesen Blog erreicht mein Beispiel-Setup mit dem decodierten base64-Ergebnis Folgendes.
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
userAdminJeder Eintrag für Backup, Cluster-Benutzer, Cluster-Monitor-Benutzer und den Benutzer für die administrative Verwendung wird basierend auf dem obigen Ergebnis angezeigt.
Eine weitere Sache ist, dass PSMDB Kubernetes Operator auch den AWS S3-Zugriff und die geheimen Schlüssel über Kubernetes Secrets speichert.
Sicherungen
Dieser Operator unterstützt Backups, was eine sehr raffinierte Funktion ist. Es unterstützt On-Demand (manuelle) Backups und geplante Backups und verwendet das Backup-Tool Percona Backup for MongoDB. Beachten Sie, dass Sicherungen nur auf AWS S3 oder einem S3-kompatiblen Speicher gespeichert werden.
Geplante Sicherungen können über die Datei deploy/cr.yaml definiert werden, während eine manuelle Sicherung jederzeit durchgeführt werden kann, wann immer dies erforderlich ist. Für S3-Zugriff und geheime Schlüssel wird es in der Datei deploy/backup-s3.yaml definiert und verwendet Kubernetes Secrets, um die folgenden Informationen zu speichern, wie wir bereits erwähnt haben.
Alle Aktionen, die für diesen PSMDB-Kubernetes-Operator unterstützt werden, sind die folgenden:
- Geplante Backups erstellen
- On-Demand-Sicherung erstellen
- Stellen Sie den Cluster aus einer zuvor gespeicherten Sicherung wieder her
- Löschen Sie die nicht benötigte Sicherung
PSMDB-Kubernetes-Operator mit Minikube verwenden
In diesem Abschnitt behalten wir eine einfache Einrichtung mit Kubernetes mit Minikube bei, die Sie lokal verwenden können, ohne dass ein Cloud-Anbieter erforderlich ist. Für die Cloud-native Einrichtung, insbesondere für eine eher unternehmens- und produktionstaugliche Umgebung, können Sie sich die Dokumentation ansehen.
Bevor wir mit den Schritten fortfahren, denken Sie daran, dass es, wie oben erwähnt, eine bekannte Einschränkung bei Minikube gibt, da es keine Multi-Node-Clusterkonfiguration unterstützt, die mit den Standard-Affinitätsanforderungen des Betreibers kollidiert. Wir werden dies in den folgenden Schritten unten erwähnen, wie man damit umgeht.
Für diesen Blog ist das Host-Betriebssystem, auf dem unser Minikube installiert wird, Ubuntu 18.04 (Bionic Beaver).
Lassen Sie uns Minikube installieren
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.debOptional können Sie den Schritten hier folgen, wenn Sie auf unterschiedlichen Linux-Systemen arbeiten.
Lassen Sie uns den erforderlichen Schlüssel hinzufügen, um unsere Kubernetes-Pakete zu authentifizieren und das Repository einzurichten
$ 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
eofLassen Sie uns nun die erforderlichen Pakete installieren
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectlStarten Sie den Minikube, indem Sie den Speicher, die Anzahl der CPUs und die CIDR definieren, für die meine Knoten zugewiesen werden sollen,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16Die Beispielergebnisse zeigen wie,
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 defaultWie Sie bemerkt haben, werden auch die Dienstprogramme zum Verwalten und Verwalten Ihrer Knoten oder Pods installiert.
Lassen Sie uns nun die Knoten und Pods überprüfen, indem Sie die folgenden Befehle ausführen:
$ 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.8Laden Sie jetzt den PSMDB Kubernetes Operator herunter,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operatorWir sind jetzt bereit, den Operator einzusetzen,
$ kubectl apply -f deploy/bundle.yamlWie bereits erwähnt, erfordern die Einschränkungen von Minikube Anpassungen, damit die Dinge wie erwartet laufen. Gehen wir wie folgt vor:
- Abhängig von Ihrer aktuellen Hardwarekapazität können Sie Folgendes ändern, wie in der Dokumentation vorgeschlagen. Da Minikube lokal ausgeführt wird, sollte die Standarddatei deploy/cr.yaml bearbeitet werden, um den Operator für die lokale Installation mit begrenzten Ressourcen anzupassen. Ändern Sie die folgenden Schlüssel im Abschnitt replsets:
- Kommentieren Sie die Schlüssel resources.requests.memory und resources.requests.cpu (dies passt zu den Standardbeschränkungen von Operator in minikube)
- setzen Sie den Schlüssel affinity.antiAffinityTopologyKey auf "none" (der Operator kann den Cluster nicht auf mehrere Knoten verteilen)
- Stellen Sie außerdem den Schlüssel allowUnsafeConfigurations auf true (diese Option deaktiviert die Kontrolle des Operators über die Cluster-Konfiguration, sodass Percona Server für MongoDB als Ein-Knoten-Cluster bereitgestellt werden kann).
Nun können wir die an der Datei deploy/cr.yaml vorgenommenen Änderungen anwenden.
$ kubectl apply -f deploy/cr.yamlAn dieser Stelle können Sie möglicherweise den Status der Pods überprüfen und den folgenden Fortschritt wie unten sehen:
$ 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 33mJetzt wo wir fast da sind. Wir erhalten die generierten Geheimnisse vom Operator, damit wir eine Verbindung zu den erstellten PSMDB-Pods herstellen können. Dazu müssen Sie zuerst die geheimen Objekte auflisten und dann den Wert von yaml abrufen, damit Sie die Kombination aus Benutzer und Passwort erhalten. Andererseits können Sie den folgenden kombinierten Befehl mit dem Format Benutzername:Passwort verwenden. Siehe das Beispiel unten,
$ 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:TQBEV7rtE15quFl5Jetzt können Sie das Benutzername:Passwort-Format verwenden und es an einem sicheren Ort speichern.
Da wir keine direkte Verbindung zum Percona-Server für MongoDB-Knoten herstellen können, müssen wir einen neuen Pod erstellen, der den Mongodb-Client enthält,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -ilSchließlich sind wir jetzt bereit, uns jetzt mit unseren PSMDB-Knoten zu verbinden,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"Alternativ können Sie sich mit den einzelnen Knoten verbinden und deren Zustand überprüfen. Zum Beispiel
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 der Betreiber die Konsistenz des Clusters verwaltet, wenn ein Fehler auftritt oder sagen wir, ein Pod gelöscht wurde. Der Bediener wird automatisch eine neue einleiten. Zum Beispiel
$ 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 2d5hJetzt sind wir fertig. Natürlich müssen Sie möglicherweise den Port verfügbar machen, sodass Sie sich möglicherweise mit Anpassungen in deploy/cr.yaml befassen müssen. Sie können sich hier darauf beziehen, damit umzugehen.
Fazit
Der Percona Kubernetes Operator für PSMDB kann Ihre Komplettlösung sein, insbesondere für containerisierte Umgebungen für Ihr Percona Server für MongoDB-Setup. Es ist fast eine vollständige Lösung, da es Redundanz für Ihren Replikatsatz integriert hat, der Betreiber jedoch Backup, Skalierbarkeit, Hochverfügbarkeit und Sicherheit unterstützt.
