Przegląd operatora Percona MongoDB Kubernetes

MongoDB i Kubernetes to świetna kombinacja, szczególnie pod względem złożoności. Jednak MongoDB (PSMDB) firmy Percona oferuje większą elastyczność dla bazy danych NoSQL, a także zawiera narzędzia, które są wydajne dla dzisiejszej produktywności; nie tylko on-prem, ale także dostępny dla natywnych użytkowników chmury.

Wskaźnik adopcji Kubernetes stale rośnie. Rozsądne jest, że technologia musi mieć operatora do wykonywania następujących czynności:tworzenie, modyfikowanie i usuwanie elementów Percona Server dla środowiska MongoDB. Operator Percona MongoDB Kubernetes zawiera niezbędne ustawienia k8s do utrzymania spójnego serwera Percona dla instancji MongoDB. Jako alternatywną opcję możesz porównać to z https://github.com/kubedb/mongodb, ale KubeDB dla MongoDB oferuje bardzo ograniczone opcje, szczególnie w systemach klasy produkcyjnej.

Operatorzy Percona Kubernetes chwalący się swoją konfiguracją bazują na najlepszych praktykach konfiguracji zestawu replik PSMDB. Co najważniejsze, sam operator dla MongoDB zapewnia wiele korzyści, ale najważniejsza jest oszczędność czasu, spójne środowisko. Na tym blogu przyjrzymy się, jak jest to korzystne, szczególnie w środowisku kontenerowym.

Co może zaoferować ten operator?

Ten operator jest przydatny w przypadku PSMDB korzystającego z zestawu replik. Oznacza to, że architektura Twojej bazy danych musi być zgodna z poniższym diagramem

Obraz zapożyczony z Przeglądu projektowania dokumentacji firmy Percona

Obecnie obsługiwane platformy dostępne dla tego operatora to:

OpenShift 3.11
OpenShift 4.5
Google Kubernetes Engine (GKE) 1.15 - 1.17
Amazon Elastic Container Service dla Kubernetes (EKS) 1.15
Minikube 1.10
VMWare Tanzu

Inne platformy Kubernetes również mogą działać, ale nie zostały przetestowane.

Limity zasobów

Klaster z oficjalnie obsługiwaną platformą zawiera co najmniej trzy węzły z następującymi zasobami:

2 GB pamięci RAM
2 wątki procesora na węzeł dla obsługi administracyjnej podów
co najmniej 60 GB dostępnej przestrzeni dyskowej do obsługi woluminów prywatnych

Bezpieczeństwo i/lub ograniczenia

Kubernetes działa tak, jak podczas tworzenia podów, każdy pod ma adres IP w wewnętrznej sieci wirtualnej klastra. Tworzenie lub niszczenie podów to procesy dynamiczne, więc nie zaleca się wiązania swoich podów z określonymi adresami IP przypisanymi do komunikacji między podami. Może to powodować problemy, ponieważ rzeczy zmieniają się w czasie w wyniku skalowania klastra, nieumyślnych błędów, awarii lub awarii zasilania DC, okresowej konserwacji itp. W takim przypadku operator surowo zaleca połączenie się z serwerem Percona Server dla MongoDB przez wewnętrzny Kubernetes Nazwy DNS w identyfikatorze URI (np. mongodb+srv://userAdmin:[email protected]-rs0..svc.cluster.local/admin?replicaSet=rs0&ssl=false).

Ten operator Kubernetes PSMDB używa również powinowactwa/antypowinowactwa, które zapewnia ograniczenia, do których można zaplanować uruchomienie lub zainicjowanie podów w określonym węźle. Powinowactwo definiuje kwalifikujące się zasobniki, które można zaplanować w węźle, który ma już zasobniki z określonymi etykietami. Anti-powinowactwo definiuje strąki, które nie kwalifikują się. Takie podejście zmniejsza koszty, zapewniając, że kilka zasobników z intensywną wymianą danych zajmuje tę samą strefę dostępności lub nawet ten sam węzeł, lub wręcz przeciwnie, rozkłada zasobniki na różne węzły lub nawet różne strefy dostępności w celu zapewnienia wysokiej dostępności i równoważenia. Chociaż operator zachęca do ustawienia koligacji/anty-powinowactwa, ma to jednak ograniczenia podczas korzystania z Minikube.

Podczas korzystania z Minikube obowiązują następujące ograniczenia specyficzne dla platformy. Minikube nie obsługuje konfiguracji wielowęzłowych klastrów ze względu na swój lokalny charakter, który koliduje z domyślnymi wymaganiami koligacji Operatora. Aby to zorganizować, instrukcja Zainstaluj Percona Server dla MongoDB na Minikube zawiera dodatkowy krok, który wyłącza wymóg posiadania nie mniej niż trzech węzłów.

W poniższej sekcji tego bloga skonfigurujemy PMSDB Kubernetes Operator przy użyciu Minikube i będziemy śledzić uruchomioną funkcję anty-powinowactwa, aby to zadziałało. Czym się to różni od korzystania z funkcji antypowinowactwa, jeśli zmienisz funkcję AntiAffinity, zwiększasz ryzyko dostępności klastra. Załóżmy, że jeśli głównym celem wdrożenia PSMDB w środowisku kontenerowym jest rozprzestrzenianie się i zapewnianie wyższej dostępności, a jednocześnie skalowalności, może to zniweczyć ten cel. Jednak korzystanie z Minikube, szczególnie w środowisku lokalnym i do testowania konfiguracji PSMDB, jest wykonalne, ale w przypadku obciążeń produkcyjnych z pewnością chcesz uruchamiać węzły na osobnych hostach lub w konfiguracji środowiska, w której współbieżna awaria wielu podów jest mało prawdopodobna.

Dane w drodze/dane w spoczynku

W celu zapewnienia bezpieczeństwa danych za pomocą PSMDB, operator oferuje TLS/SSL podczas przesyłania, a następnie oferuje szyfrowanie, gdy dane są w spoczynku. W przypadku transportu opcjami, które możesz wybrać, jest użycie menedżera certyfikatów lub ręczne wygenerowanie własnego certyfikatu. Oczywiście możesz opcjonalnie użyć PSMDB bez TLS dla tego operatora. Sprawdź ich dokumentację dotyczącą korzystania z TLS.

Dla danych w spoczynku wymaga zmian w ich operatorze Kubernetes PSMDB po pobraniu gałęzi github, a następnie zastosuj zmiany w pliku deploy/cr.yaml. Aby to włączyć, wykonaj następujące czynności zgodnie z sugestią w dokumentacji:

Klucz security.enableEncryption powinien być ustawiony na true (wartość domyślna).
Klucz security.encryptionCipherMode powinien określać odpowiedni tryb szyfrowania do odszyfrowania. Wartość może być jednym z dwóch następujących wariantów:
- AES256-CBC (domyślny dla Operatora i Percona Server dla MongoDB)
- AES256-GCM

security.encryptionKeySecret should specify a secret object with the encryption key:

mongod:

  ...

  security:

    ...

    encryptionKeySecret: my-cluster-name-mongodb-encryption-key

Tajny klucz szyfrowania zostanie utworzony automatycznie, jeśli nie istnieje. Jeśli chcesz stworzyć go samodzielnie, weź pod uwagę, że klucz musi być 32-znakowym ciągiem zakodowanym w base64.

Przechowywanie poufnych informacji

Operator Kubernetes PSMDB używa Kubernetes Secrets do przechowywania poufnych informacji i zarządzania nimi. Klucze Kubernetes Secrets umożliwiają przechowywanie i zarządzanie poufnymi informacjami, takimi jak hasła, tokeny OAuth i klucze ssh. Przechowywanie poufnych informacji w Sekretie jest bezpieczniejsze i bardziej elastyczne niż umieszczanie ich dosłownie w definicji pod lub w obrazie kontenera.

Dla tego operatora użytkownik i hasła wygenerowane dla Twoich podów są przechowywane i można je uzyskać za pomocą kubectl get secrets -o yaml set w Twoim deploy/cr.yaml .

W tym blogu moja przykładowa konfiguracja osiąga następujące wyniki z dekodowanym wynikiem 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żdy wpis dotyczący kopii zapasowej, użytkownika klastra, użytkownika monitora klastra i użytkownika do użytku administracyjnego jest wyświetlany na podstawie powyższego wyniku.

Inną rzeczą jest również to, że PSMDB Kubernetes Operator przechowuje również klucze dostępu i tajne AWS S3 za pośrednictwem Kubernetes Secrets.

Kopie zapasowe

Ten operator obsługuje kopie zapasowe, co jest bardzo fajną funkcją. Obsługuje tworzenie kopii zapasowych na żądanie (ręczne) i zaplanowane kopie zapasowe oraz wykorzystuje narzędzie do tworzenia kopii zapasowych Percona Backup for MongoDB. Pamiętaj, że kopie zapasowe są przechowywane tylko w AWS S3 lub dowolnym magazynie zgodnym z S3.

Zaplanowane kopie zapasowe można zdefiniować za pomocą pliku deploy/cr.yaml, natomiast ręczne wykonanie kopii zapasowej można wykonać w dowolnym momencie, gdy jest to konieczne. W przypadku kluczy dostępu i kluczy tajnych S3 należy je zdefiniować w pliku deploy/backup-s3.yaml i użyć kluczy tajnych Kubernetes do przechowywania następujących informacji, jak wspomnieliśmy wcześniej.

Wszystkie działania obsługiwane dla tego operatora Kubernetes PSMDB są następujące:

Tworzenie zaplanowanych kopii zapasowych
Tworzenie kopii zapasowej na żądanie
Przywróć klaster z wcześniej zapisanej kopii zapasowej
Usuń niepotrzebną kopię zapasową

Korzystanie z PSMDB Kubernetes Operator z Minikube

W tej sekcji zachowamy prostą konfigurację przy użyciu Kubernetes z Minikube, z której można korzystać lokalnie bez konieczności korzystania z dostawcy chmury. W przypadku konfiguracji natywnej dla chmury, zwłaszcza dla środowiska bardziej korporacyjnego i produkcyjnego, możesz przejść do kasy ich dokumentacji.

Zanim przejdziemy do kolejnych kroków, pamiętaj, że jak wspomniano powyżej, istnieje znane ograniczenie dotyczące Minikube, ponieważ nie obsługuje on konfiguracji klastra wielowęzłowego, która koliduje z domyślnymi wymaganiami dotyczącymi koligacji operatora. Wspomnimy o tym, jak sobie z tym poradzić w poniższych krokach.

W tym blogu system operacyjny hosta, w którym zostanie zainstalowany nasz Minikube, to Ubuntu 18.04 (Bionic Beaver).

Zainstalujmy Minikube

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb

$ sudo dpkg -i minikube_latest_amd64.deb

Opcjonalnie możesz wykonać poniższe kroki, jeśli korzystasz z różnych systemów Linux.

Dodajmy wymagany klucz, aby uwierzytelnić nasze pakiety Kubernetes i skonfigurować repozytorium

$ 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

Teraz zainstalujmy wymagane pakiety

$ sudo apt-get update

$ sudo apt-get install kubelet kubeadm kubectl

Uruchom Minikube definiując pamięć, liczbę procesorów i CIDR, dla których mają być przypisane moje węzły,

$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16

Przykładowe wyniki pokazują,

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 zauważyłeś, równie dobrze instaluje narzędzia do zarządzania i administrowania węzłami lub podami.

Teraz sprawdźmy węzły i pody, uruchamiając następujące polecenia:

$ 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

Teraz pobierz PSMDB Kubernetes Operator,

$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator

$ cd percona-server-mongodb-operator

Jesteśmy teraz gotowi do wdrożenia operatora,

$ kubectl apply -f deploy/bundle.yaml

Jak wspomniano wcześniej, ograniczenia Minikube wymagają dostosowania, aby wszystko działało zgodnie z oczekiwaniami. Zróbmy co następuje:

W zależności od aktualnej pojemności sprzętu możesz zmienić następujące elementy zgodnie z sugestią w dokumentacji. Ponieważ minikube działa lokalnie, należy edytować domyślny plik deploy/cr.yaml, aby dostosować Operatora do instalacji lokalnej z ograniczonymi zasobami. Zmień następujące klucze w sekcji uzupełnień:
- komentuj klucze resources.requests.memory i resources.requests.cpu (dopasuje to Operatora do domyślnych ograniczeń minikube)
- ustaw klucz affinity.antiAffinityTopologyKey na „brak” (Operator nie będzie mógł rozłożyć klastra na kilka węzłów)
Ponadto przełącz klucz allowUnsafeConfigurations na true (ta opcja wyłącza kontrolę Operatora nad konfiguracją klastra, umożliwiając wdrożenie Percona Server dla MongoDB jako jednowęzłowego klastra).

Teraz jesteśmy gotowi do zastosowania zmian wprowadzonych do pliku deploy/cr.yaml.

$ kubectl apply -f deploy/cr.yaml

W tym momencie możesz sprawdzić stan strąków i zauważysz następujący postęp, tak jak poniżej,

$ 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

Teraz jesteśmy prawie na miejscu. Otrzymamy wygenerowane sekrety przez operatora, dzięki czemu będziemy mogli połączyć się z utworzonymi zasobnikami PSMDB. Aby to zrobić, musisz najpierw wyświetlić listę tajnych obiektów, a następnie uzyskać wartość yaml, aby uzyskać kombinację użytkownika/hasła. Z drugiej strony możesz użyć poniższego połączonego polecenia z formatem nazwa użytkownika:hasło. Zobacz przykład poniżej,

$ 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

Teraz możesz oprzeć format nazwa użytkownika:hasło i zapisać go w bezpiecznym miejscu.

Ponieważ nie możemy bezpośrednio połączyć się z serwerem Percona dla węzłów MongoDB, musimy utworzyć nowy pod, który ma klienta mongodb,

$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -il

Wreszcie, jesteśmy teraz gotowi do połączenia z naszymi węzłami PSMDB,

bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"

Alternatywnie możesz połączyć się z poszczególnymi węzłami i sprawdzić ich kondycję. Na przykład

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)

}

Ponieważ operator zarządza spójnością klastra, za każdym razem, gdy awaria lub powiedzmy, pod został usunięty. Operator automatycznie zainicjuje nowy. Na przykład

$ 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

Teraz wszystko gotowe. Oczywiście może być konieczne ujawnienie portu, więc być może będziesz musiał poradzić sobie z dostosowaniami w pliku deploy/cr.yaml. Możesz odnieść się tutaj, aby sobie z tym poradzić.

Wnioski

Operator Percona Kubernetes dla PSMDB może być Twoim kompletnym rozwiązaniem, szczególnie dla środowisk kontenerowych dla konfiguracji Percona Server dla MongoDB. Jest to prawie kompletne rozwiązanie, ponieważ ma wbudowaną redundancję dla zestawu replik, ale operator obsługuje tworzenie kopii zapasowych, skalowalność, wysoką dostępność i bezpieczeństwo.