Преглед на оператора Percona MongoDB Kubernetes

MongoDB и Kubernetes е страхотна комбинация, особено по отношение на сложността. И все пак, MongoDB (PSMDB) на Percona предлага по-голяма гъвкавост за базата данни NoSQL и също така идва с инструменти, които са ефективни за днешната производителност; не само on-prem, но и достъпно за местни хора в облака.

Процентът на приемане на Kubernetes непрекъснато нараства. Разумно е една технология да има оператор, който да прави следното:създаване, модифициране и изтриване на елементи Percona Server за среда MongoDB. Операторът Percona MongoDB Kubernetes съдържа необходимите настройки на k8s за поддържане на последователен сървър на Percona за екземпляр на MongoDB. Като алтернативна опция можете да сравните това с https://github.com/kubedb/mongodb, но KubeDB за MongoDB предлага много ограничени опции, особено за системи от производствен клас.

Операторите на Percona Kubernetes, които могат да се похвалят с конфигурацията си, са базирани и следват най-добрите практики за конфигуриране на набор от реплики на PSMDB. Най-важното е, че самият оператор за MongoDB предоставя много предимства, но спестяването на време и последователната среда са най-важните. В този блог ще направим общ преглед на това как това е полезно, особено в контейнерна среда.

Какво може да предложи този оператор?

Този оператор е полезен за PSMDB, използвайки набор от реплики. Това означава, че архитектурата на дизайна на вашата база данни трябва да съответства на следната диаграма по-долу

Изображение, взето назаем от Преглед на дизайна на документацията на Percona

Изображение, взето назаем от Precument Design на Percona Общ преглед /P>

Понастоящем поддържаните платформи, налични за този оператор, са:

OpenShift 3.11
OpenShift 4.5
Google Kubernetes Engine (GKE) 1.15 – 1.17
Услуга за еластични контейнери на Amazon за Kubernetes (EKS) 1.15
Minikube 1.10
VMWare Tanzu

Други платформи на Kubernetes също може да работят, но не са тествани.

Ограничения на ресурсите

Клъстер, работещ с официално поддържана платформа, съдържа поне три възли със следните ресурси:

2 GB RAM
2 CPU нишки на възел за предоставяне на Pods
най-малко 60 GB налично хранилище за предоставяне на частни томове

Ограничения за сигурност и/или ограничения

Kubernetes работи така, че когато създава модули, всеки Pod има IP адрес във вътрешната виртуална мрежа на клъстера. Създаването или унищожаването на Pods са динамични процеси, така че не е препоръчително да обвързвате модулите си към конкретни IP адреси, назначени за комуникация между Pods. Това може да причини проблеми, тъй като нещата се променят с течение на времето в резултат на мащабиране на клъстера, неволни грешки, прекъсване на постоянен ток или бедствия, или периодична поддръжка и т.н. В този случай операторът строго препоръчва да се свържете с Percona Server за MongoDB чрез вътрешния Kubernetes DNS имена в URI (напр. mongodb+srv://userAdmin:[email protected]-rs0..svc.cluster.local/admin?replicaSet=rs0&ssl=false).

Този PSMDB Kubernetes оператор също използва афинитет/анти-афинитет, който осигурява ограничения, за които вашите модули могат да бъдат планирани да се изпълняват или инициират на конкретен възел. Афинитетът дефинира отговарящи на условията модули, които могат да бъдат планирани на възела, който вече има модули със специфични етикети. Антиафинитетът определя модулите, които не отговарят на условията. Този подход намалява разходите, като гарантира, че няколко модула с интензивен обмен на данни заемат една и съща зона на наличност или дори един и същ възел или, напротив, разпределя модулите на различни възли или дори различни зони на наличност с цел висока наличност и балансиране. Въпреки че операторът ви насърчава да зададете афинитет/антиафинитет, това има ограничения при използване на Minikube.

Когато използвате Minikube, той има следните специфични за платформата ограничения. Minikube не поддържа конфигурации на клъстер с множество възли поради местния си характер, който е в сблъсък с изискванията за афинитет по подразбиране на Оператора. За да се организира това, инструкцията за инсталиране на Percona Server за MongoDB на Minikube включва допълнителна стъпка, която изключва изискването да имате не по-малко от три възела.

В следващия раздел на този блог ще настроим PMSDB Kubernetes Operator с помощта на Minikube и ще следваме зададената анти-афинитетност, за да работи. Как това се различава от използването на анти-афинитет, ако промените AntiAffinity, увеличавате рисковете за наличност на клъстер. Да речем, ако основната ви цел на разгръщането на вашия PSMDB в контейнерна среда е да се разпространява и да има по-висока наличност, но мащабируемост, тогава това може да попречи на целта. И все пак използването на Minikube, особено on-prem и за тестване на вашата настройка на PSMDB, е възможно, но за производствени натоварвания със сигурност искате да стартирате възли на отделни хостове или в настройка на среда, така че по някакъв начин е малко вероятно да се случи едновременен отказ на множество модули.

Данни в пренос/Данни в покой

За сигурност на данните с PSMDB, операторът предлага TLS/SSL за транзит, след което предлага и криптиране, когато данните са в покой. За транспортиране опциите, които можете да изберете, е да използвате cert-manager или да генерирате свой собствен сертификат ръчно. Разбира се, можете по желание да използвате PSMDB без TLS за този оператор. Проверете тяхната документация по отношение на използването на TLS.

За данни в покой, изисква промени в техния PSMDB Kubernetes Operator, след като сте изтеглили клона на github, след което приложете промените във файла deploy/cr.yaml. За да активирате това, направете следното, както е предложено в документацията:

Ключът security.enableEncryption трябва да бъде зададен на true (стойността по подразбиране).
Ключът security.encryptionCipherMode трябва да посочва правилния режим на шифроване за декриптиране. Стойността може да бъде един от следните два варианта:
- AES256-CBC (по подразбиране за Operator и Percona Server за MongoDB)
- AES256-GCM

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

mongod:

  ...

  security:

    ...

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

Тайната на ключа за криптиране ще бъде създадена автоматично, ако не съществува. Ако искате да го създадете сами, имайте предвид, че ключът трябва да бъде низ от 32 знака, кодиран в base64.

Съхранение на чувствителна информация

PSMDB Kubernetes Operator използва Kubernetes Secrets за съхраняване и управление на чувствителна информация. Тайните на Kubernetes ви позволяват да съхранявате и управлявате чувствителна информация, като пароли, OAuth токени и ssh ключове. Съхраняването на поверителна информация в Secret е по-безопасно и по-гъвкаво от поставянето й дословно в дефиниция на капсула или в изображение на контейнер.

За този оператор потребителят и паролите, генерирани за вашите pods, се съхраняват и могат да бъдат получени с помощта на kubectl get secrets -o yaml, зададен във вашия deploy/cr.yaml .

За този блог моята примерна настройка постига следното с декодирания резултат 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

Всеки запис за архивиране, потребител на клъстер, потребител на монитор на клъстер и потребител за административно използване се показва въз основа на горния резултат.

Друго нещо е също, че PSMDB Kubernetes Operator съхранява също AWS S3 достъп и секретни ключове чрез Kubernetes Secrets.

Резервни копия

Този оператор поддържа архивиране, което е много изящна функция. Той поддържа архивиране при поискване (ръчно) и планирано архивиране и използва инструмента за архивиране Percona Backup за MongoDB. Обърнете внимание, че резервните копия се съхраняват само на AWS S3 или на всяко S3-съвместимо хранилище.

Планираните резервни копия могат да бъдат дефинирани чрез файла deploy/cr.yaml, докато вземането на ръчно архивиране може да се направи по всяко време, когато е необходимо. За S3 достъп и секретни ключове, той трябва да бъде дефиниран във файла deploy/backup-s3.yaml и използва Kubernetes Secrets за съхраняване на следната информация, както споменахме по-рано.

Всички действия, поддържани за този PSMDB Kubernetes оператор, са следните:

Правене на планирано архивиране
Създаване на резервно копие при поискване
Възстановете клъстера от предварително запазено резервно копие
Изтрийте ненужния архив

Използване на PSMDB Kubernetes оператор с Minikube

В този раздел ще поддържаме проста настройка, използвайки Kubernetes с Minikube, която можете да използвате локално, без да е необходим облачен доставчик. За настройка в облак, особено за по-сериозна и производствена среда, можете да разгледате тяхната документация.

Преди да продължим със стъпките, имайте предвид, че както беше споменато по-горе, има известно ограничение с Minikube, тъй като той не поддържа конфигурация на клъстер с множество възли, която е в сблъсък с изискванията за афинитет по подразбиране на оператора. Ще споменем това за това как да се справите в следните стъпки по-долу.

За този блог хост ОС, където ще бъде инсталиран нашия Minikube, е на Ubuntu 18.04 (Bionic Beaver).

Нека инсталираме Minikube

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

$ sudo dpkg -i minikube_latest_amd64.deb

По желание можете да следвате стъпките тук, ако сте на различни Linux системи.

Нека добавим необходимия ключ за удостоверяване на нашите Kubernetes пакети и да настроим хранилището

$ 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

Сега нека инсталираме необходимите пакети

$ sudo apt-get update

$ sudo apt-get install kubelet kubeadm kubectl

Стартирайте Minikube, определяйки паметта, броя на процесорите и CIDR, за които ще бъдат присвоени моите възли,

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

Примерните резултати показват като,

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

Както забелязахте, той също така инсталира помощните инструменти за управление и администриране на вашите възли или модули.

Сега нека проверим възлите и модулите, като изпълним следните команди,

$ 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

Сега изтеглете PSMDB Kubernetes Operator,

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

$ cd percona-server-mongodb-operator

Вече сме готови да разположим оператора,

$ kubectl apply -f deploy/bundle.yaml

Както споменахме по-рано, ограниченията на Minikube изискват корекции, за да могат нещата да работят според очакванията. Нека направим следното:

В зависимост от текущия ви хардуерен капацитет, може да промените следното, както е предложено в документацията. Тъй като minikube работи локално, файлът deploy/cr.yaml по подразбиране трябва да бъде редактиран, за да адаптира Оператора за локалната инсталация с ограничени ресурси. Променете следните ключове в секцията replsets:
- коментирайте ключовете за ресурси.requests.memory и resources.requests.cpu (това ще пасне на оператора в ограниченията по подразбиране на minikube)
- задайте ключа affinity.antiAffinityTopologyKey на „none“ (Операторът няма да може да разпространи клъстера на няколко възела)
Също така, превключете ключа allowUnsafeConfigurations на true (тази опция изключва контрола на оператора върху конфигурацията на клъстера, което прави възможно разгръщането на Percona Server за MongoDB като клъстер с един възел).

Сега сме готови да приложим промените, направени във файла deploy/cr.yaml.

$ kubectl apply -f deploy/cr.yaml

В този момент може да сте в състояние да проверите състоянието на шушулките и ще забележите следния напредък точно както по-долу,

$ 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

Сега, когато сме почти там. Ще получим генерираните тайни от оператора, за да можем да се свържем със създадените PSMDB модули. За да направите това, първо трябва да изброите секретните обекти, след това да получите стойността на yaml, за да можете да получите комбинацията потребител/парола. От друга страна, можете да използвате комбинираната команда по-долу с формат потребителско име:парола. Вижте примера по-долу,

$ 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

Сега можете да базирате формата на потребителско име:парола и да го запишете някъде на сигурно място.

Тъй като не можем директно да се свържем със сървъра Percona за възли MongoDB, трябва да създадем нова под, която има клиента mongodb,

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

И накрая, вече сме готови да се свържем с нашите PSMDB възли сега,

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

Като алтернатива можете да се свържете с отделните възли и да проверите здравето им. Например,

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)

}

Тъй като операторът управлява последователността на клъстера, всеки път, когато неизправност или да кажем модул е изтрит. Операторът автоматично ще започне нов. Например,

$ 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

Сега, когато сме готови. Разбира се, може да се наложи да разкриете порта, така че може да се наложи да се справите с корекциите в deploy/cr.yaml. Можете да направите справка тук, за да се справите с него.

Заключение

Percona Kubernetes Operator за PSMDB може да бъде вашето цялостно решение, особено за контейнерни среди за настройката на вашия Percona Server за MongoDB. Това е почти цялостно решение, тъй като има вградено резервиране за вашия комплект реплики, но операторът поддържа архивиране, мащабируемост, висока достъпност и сигурност.