sql >> Databasteknik >  >> NoSQL >> MongoDB

En översikt över Percona MongoDB Kubernetes-operatören

MongoDB och Kubernetes är en fantastisk kombination, särskilt när det gäller komplexitet. Ändå erbjuder Perconas MongoDB (PSMDB) mer flexibilitet för NoSQL-databasen, och den kommer också med verktyg som är effektiva för dagens produktivitet; inte bara on-prem utan även tillgängligt för molninfödda.

Anpassningsgraden för Kubernetes ökar stadigt. Det är rimligt att en teknik måste ha en operatör för att göra följande:skapa, modifiera och ta bort objekt Percona Server för MongoDB-miljö. Percona MongoDB Kubernetes Operator innehåller de nödvändiga k8s-inställningarna för att upprätthålla en konsekvent Percona-server för en MongoDB-instans. Som ett alternativ kan du jämföra detta med https://github.com/kubedb/mongodb, men KubeDB för MongoDB erbjuder mycket begränsade alternativ att erbjuda, särskilt på produktionssystem.

Percona Kubernetes-operatörerna som skryter med sin konfiguration är baserade och följer de bästa metoderna för konfiguration av PSMDB-replikuppsättningen. Det som är viktigast är att operatören för MongoDB själv ger många fördelar men att spara tid, en konsekvent miljö är det viktigaste. I den här bloggen tar vi en översikt över hur detta är fördelaktigt, särskilt i en miljö med containers.

Vad kan den här operatören erbjuda?

Denna operator är användbar för PSMDB som använder en replikuppsättning. Detta betyder att din databasdesignarkitektur måste överensstämma med följande diagram nedan

Bild lånad från Perconas dokumentationsdesignöversikt

Bild lånad från Perconas översikt över dokumentationsdesign /P>

För närvarande är de plattformar som stöds tillgängliga för denna operatör:

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

Andra Kubernetes-plattformar kanske också fungerar men har inte testats.

Resursgränser

Ett kluster som kör en officiellt stödd plattform innehåller minst tre noder, med följande resurser:

  • 2 GB RAM
  • 2 CPU-trådar per nod för Pods-provisionering
  • minst 60 GB tillgängligt lagringsutrymme för provisionering av privata volymer

Säkerhets- och/eller begränsningar

Kubernetes fungerar som när man skapar Pods, varje Pod har en IP-adress i klustrets interna virtuella nätverk. Att skapa eller förstöra Pods är båda dynamiska processer, så det är inte att rekommendera att binda dina pods till specifika IP-adresser som tilldelats för kommunikation mellan Pods. Detta kan orsaka problem eftersom saker förändras över tiden som ett resultat av klusterskalning, oavsiktliga misstag, dc-avbrott eller katastrofer, eller periodiskt underhåll, etc. I så fall rekommenderar operatören dig strängt att ansluta till Percona Server för MongoDB via Kubernetes interna DNS-namn i URI (t.ex. mongodb+srv://userAdmin:[email protected]-rs0..svc.cluster.local/admin?replicaSet=rs0&ssl=false).

Denna PSMDB Kubernetes-operatör använder också affinitet/antiaffinitet som ger begränsningar för vilka dina pods kan schemaläggas att köras eller initieras på en specifik nod. Affinity definierar kvalificerade pods som kan schemaläggas på noden som redan har pods med specifika etiketter. Antiaffinitet definierar pods som inte är kvalificerade. Detta tillvägagångssätt minskar kostnaderna genom att se till att flera pods med intensivt datautbyte upptar samma tillgänglighetszon eller till och med samma nod eller tvärtom sprida podarna på olika noder eller till och med olika tillgänglighetszoner för hög tillgänglighet och balansering. Även om operatören uppmuntrar dig att ställa in affinitet/anti-affinitet, har detta begränsningar när du använder Minikube.

När du använder Minikube har den följande plattformsspecifika begränsningar. Minikube stöder inte klusterkonfigurationer med flera noder på grund av dess lokala karaktär, som är i kollision med operatörens standardkrav för affinitet. För att ordna detta inkluderar instruktionen Install Percona Server for MongoDB på Minikube ett extra steg som stänger av kravet på att ha inte mindre än tre noder.

I följande avsnitt av den här bloggen kommer vi att ställa in PMSDB Kubernetes Operator med Minikube och vi kommer att följa anti-affiniteten för att få det att fungera. Hur skiljer sig detta från att använda antiaffinitet, om du ändrar AntiAffinity ökar du riskerna för klustertillgänglighet. Låt oss säga att om ditt huvudsakliga syfte med att distribuera din PSMDB till en containermiljö är att sprida och ha högre tillgänglighet men ändå skalbarhet, då kan detta motverka syftet. Ändå är det möjligt att använda Minikube, speciellt on-prem och för att testa din PSMDB-installation, men för produktionsbelastningar vill du säkert köra noder på separata värdar, eller i en miljöinstallation så att det på ett sätt är osannolikt att flera pods samtidigt misslyckas.

Data under transport/Data i vila

För datasäkerhet med PSMDB erbjuder operatören TLS/SSL för överföring och erbjuder sedan även kryptering när data är i vila. För i transit, alternativ du kan välja är att använda cert-manager, eller generera ditt eget certifikat manuellt. Naturligtvis kan du valfritt använda PSMDB utan TLS för denna operatör. Kolla in deras dokumentation angående användning av TLS.

För data i vila kräver det ändringar inom deras PSMDB Kubernetes-operatör efter att du laddat ner github-grenen, och tillämpa sedan ändringar på filen deploy/cr.yaml. För att aktivera detta, gör följande enligt dokumentationen:

  • Security.enableEncryption-nyckeln ska vara inställd på true (standardvärdet).
  • Nyckeln security.encryptionCipherMode bör ange korrekt chifferläge för dekryptering. Värdet kan vara en av följande två varianter:
    • AES256-CBC (standard för Operator och Percona Server för MongoDB)
    • AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:

mongod:

  ...

  security:

    ...

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

Krypteringsnyckelhemlighet skapas automatiskt om den inte finns. Om du vill skapa den själv, tänk på att nyckeln måste vara en sträng på 32 tecken kodad i base64.

Lagra känslig information

PSMDB Kubernetes Operator använder Kubernetes Secrets för att lagra och hantera känslig information. Kubernetes Secrets låter dig lagra och hantera känslig information, såsom lösenord, OAuth-tokens och ssh-nycklar. Att lagra konfidentiell information i en hemlighet är säkrare och mer flexibelt än att sätta den ordagrant i en poddefinition eller i en containerbild.

För den här operatören lagras användaren och lösenorden som genereras för dina poddar och kan erhållas med kubectl get secrets -o yaml set i din deploy/cr.yaml .

För den här bloggen uppnår min exempelinställning följande med det avkodade base64-resultatet.

 kubectl get secrets mongodb-cluster-s9s-secrets -o yaml | egrep '^\s+MONGODB.*'|cut -d ':' -f2 | xargs -I% sh -c "echo % | base64 -d; echo "

WrDry6bexkCPOY5iQ

backup

gAWBKkmIQsovnImuKyl

clusterAdmin

qHskMMseNqU8DGbo4We

clusterMonitor

TQBEV7rtE15quFl5

userAdmin

Varje post för säkerhetskopiering, klusteranvändare, klusterövervakare och användaren för administrativ användning visas baserat på ovanstående resultat.

En annan sak är också att PSMDB Kubernetes Operator lagrar AWS S3-åtkomst och hemliga nycklar genom Kubernetes Secrets.

Säkerhetskopiering

Denna operatör stöder säkerhetskopiering, vilket är en mycket snygg funktion. Den stöder on-demand (manuell) säkerhetskopiering och schemalagd säkerhetskopiering och använder säkerhetskopieringsverktyget Percona Backup för MongoDB. Observera att säkerhetskopior endast lagras på AWS S3 eller någon S3-kompatibel lagring.

Säkerhetskopieringar som är schemalagda kan definieras via filen deploy/cr.yaml, medan en manuell säkerhetskopiering kan göras när som helst när efterfrågan är nödvändig. För S3-åtkomst och hemliga nycklar ska den definieras i filen deploy/backup-s3.yaml och använder Kubernetes Secrets för att lagra följande information som vi nämnde tidigare.

Alla åtgärder som stöds för denna PSMDB Kubernetes-operatör är följande:

  • Göra schemalagda säkerhetskopior
  • Göra säkerhetskopiering på begäran
  • Återställ klustret från en tidigare sparad säkerhetskopia
  • Ta bort den onödiga säkerhetskopian

Använda PSMDB Kubernetes Operator med Minikube

I det här avsnittet kommer vi att ha en enkel installation med Kubernetes med Minikube, som du kan använda på plats utan att behöva en molnleverantör. För molnbaserad konfiguration, särskilt för en miljö med mer företags- och produktionskvalitet, kan du gå och kolla in deras dokumentation.

Innan vi fortsätter med stegen, kom ihåg att som nämnts ovan har det funnits en känd begränsning med Minikube eftersom den inte stöder multi-nod klusterkonfiguration som är i kollision med standardkraven för affinitet hos operatören. Vi kommer att nämna detta om hur man hanterar det i följande steg nedan.

För den här bloggen är värdoperativsystemet där vår Minikube kommer att installeras på Ubuntu 18.04 (Bionic Beaver).

Låt oss installera Minikube

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

$ sudo dpkg -i minikube_latest_amd64.deb

Alternativt kan du följa stegen här om du använder olika Linux-system.

Låt oss lägga till den nödvändiga nyckeln för att autentisera våra Kubernetes-paket och ställa in förvaret

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

$ cat <<eof > /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

deb https://apt.kubernetes.io/ kubernetes-yakkety main

eof

Låt oss nu installera de nödvändiga paketen

$ sudo apt-get update

$ sudo apt-get install kubelet kubeadm kubectl

Starta Minikuben som definierar minnet, antalet CPU:er och CIDR för vilka mina noder ska tilldelas,

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

Exempelresultaten visar som,

minikube v1.14.2 on Ubuntu 18.04

Automatically selected the docker driver

docker is currently using the aufs storage driver, consider switching to overlay2 for better performance

Starting control plane node minikube in cluster minikube

Creating docker container (CPUs=3, Memory=4096MB) ...

Preparing Kubernetes v1.19.2 on Docker 19.03.8 ...

kubeadm.pod-network-cidr=192.168.0.0/16

 > kubeadm.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s

 > kubectl.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s

 > kubelet.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s

 > kubeadm: 37.30 MiB / 37.30 MiB [---------------] 100.00% 1.46 MiB p/s 26s

 > kubectl: 41.01 MiB / 41.01 MiB [---------------] 100.00% 1.37 MiB p/s 30s

 > kubelet: 104.88 MiB / 104.88 MiB [------------] 100.00% 1.53 MiB p/s 1m9s

Verifying Kubernetes components...

Enabled addons: default-storageclass, storage-provisioner

Done! kubectl is now configured to use "minikube" by default

Som du märkte installerar den lika bra verktygen för att hantera och administrera dina noder eller poddar.

Låt oss nu kontrollera noderna och poddarna genom att köra följande kommandon,

$ kubectl get pods -A

NAMESPACE     NAME                               READY   STATUS    RESTARTS   AGE

kube-system   coredns-f9fd979d6-gwngd            1/1     Running   0          45s

kube-system   etcd-minikube                      0/1     Running   0          53s

kube-system   kube-apiserver-minikube            1/1     Running   0          53s

kube-system   kube-controller-manager-minikube   0/1     Running   0          53s

kube-system   kube-proxy-m25hm                   1/1     Running   0          45s

kube-system   kube-scheduler-minikube            0/1     Running   0          53s

kube-system   storage-provisioner                1/1     Running   1          57s

$ kubectl get nodes -owide

NAME       STATUS   ROLES    AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE           KERNEL-VERSION      CONTAINER-RUNTIME

minikube   Ready    master   2d4h   v1.19.2   192.168.49.2   <none>        Ubuntu 20.04 LTS   4.15.0-20-generic   docker://19.3.8

Ladda nu ner PSMDB Kubernetes Operator,

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

$ cd percona-server-mongodb-operator

Vi är nu redo att distribuera operatören,

$ kubectl apply -f deploy/bundle.yaml

Som nämnts tidigare kräver Minikubes begränsningar justeringar för att få saker att fungera som förväntat. Låt oss göra följande:

  • Beroende på din nuvarande hårdvarukapacitet kan du ändra följande enligt dokumentationen. Eftersom minikube körs lokalt, bör standardfilen deploy/cr.yaml redigeras för att anpassa operatören för den lokala installationen med begränsade resurser. Ändra följande nycklar i repset-sektionen:
    • kommentar resources.requests.memory och resources.requests.cpu-nycklar (detta passar operatören i minikubes standardbegränsningar)
    • ställ affinity.antiAffinityTopologyKey-nyckeln till "ingen" (operatören kommer inte att kunna sprida klustret på flera noder)
  • Ändra även allowUnsafeConfigurations-nyckeln till true (det här alternativet stänger av operatörens kontroll över klusterkonfigurationen, vilket gör det möjligt att distribuera Percona Server för MongoDB som ett ennodskluster).

Nu är vi redo att tillämpa ändringarna som gjorts i filen deploy/cr.yaml.

$ kubectl apply -f deploy/cr.yaml

Vid det här laget kanske du kan kontrollera poddarnas status och du kommer att märka följande framsteg precis som nedan,

$ kubectl get pods

NAME                                              READY   STATUS              RESTARTS   AGE

percona-server-mongodb-operator-588db759d-qjv29   0/1     ContainerCreating   0          15s



$ kubectl get pods

NAME                                              READY   STATUS     RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         0/2     Init:0/1   0          4s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running    0          34s



$ kubectl get pods

NAME                                              READY   STATUS            RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         0/2     PodInitializing   0          119s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running           0          2m29s



kubectl get pods

NAME                                              READY   STATUS            RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         0/2     PodInitializing   0          2m1s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running           0          2m31s



kubectl get pods

NAME                                              READY   STATUS    RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         2/2     Running   0          33m

mongodb-cluster-s9s-rs0-1                         2/2     Running   1          31m

mongodb-cluster-s9s-rs0-2                         2/2     Running   0          30m

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running   0          33m

Nu när vi nästan är framme. Vi får de genererade hemligheterna av operatören så att vi kan ansluta till de skapade PSMDB-podarna. För att göra det måste du först lista de hemliga objekten och sedan hämta värdet på yaml så att du kan få användar/lösenordskombinationen. Å andra sidan kan du använda det kombinerade kommandot nedan med användarnamn:lösenordsformatet. Se exemplet nedan,

$ kubectl get secrets

NAME                                          TYPE                                  DATA   AGE

default-token-c8frr                           kubernetes.io/service-account-token   3      2d4h

internal-mongodb-cluster-s9s-users            Opaque                                8      2d4h

mongodb-cluster-s9s-mongodb-encryption-key    Opaque                                1      2d4h

mongodb-cluster-s9s-mongodb-keyfile           Opaque                                1      2d4h

mongodb-cluster-s9s-secrets                   Opaque                                8      2d4h

percona-server-mongodb-operator-token-rbzbc   kubernetes.io/service-account-token   3      2d4h



$ kubectl get secrets mongodb-cluster-s9s-secrets -o yaml | egrep '^\s+MONGODB.*'|cut -d ':' -f2 | xargs -I% sh -c "echo % | base64 -d; echo" |sed 'N; s/\(.*\)\n\(.*\)/

\2:\1/'

backup:WrDry6bexkCPOY5iQ

clusterAdmin:gAWBKkmIQsovnImuKyl

clusterMonitor:qHskMMseNqU8DGbo4We

userAdmin:TQBEV7rtE15quFl5

Nu kan du basera användarnamn:lösenordsformatet och spara det någonstans säkert.

Eftersom vi inte kan ansluta direkt till Percona Server för MongoDB-noder, måste vi skapa en ny pod som har mongodb-klienten,

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

Slutligen är vi nu redo att ansluta till våra PSMDB-noder nu,

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

Alternativt kan du ansluta till de enskilda noderna och kontrollera dess hälsa. Till exempel,

bash-4.2$ mongo --host "mongodb://clusterAdmin:[email protected]:27017/?authSource=admin&ssl=false"

Percona Server for MongoDB shell version v4.2.8-8

connecting to: mongodb://mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb&ssl=false

Implicit session: session { "id" : UUID("9b29b9b3-4f82-438d-9857-eff145be0ee6") }

Percona Server for MongoDB server version: v4.2.8-8

Welcome to the Percona Server for MongoDB shell.

For interactive help, type "help".

For more comprehensive documentation, see

        https://www.percona.com/doc/percona-server-for-mongodb

Questions? Try the support group

        https://www.percona.com/forums/questions-discussions/percona-server-for-mongodb

2020-11-09T07:41:59.172+0000 I  STORAGE  [main] In File::open(), ::open for '/home/mongodb/.mongorc.js' failed with No such file or directory

Server has startup warnings:

2020-11-09T06:41:16.838+0000 I  CONTROL  [initandlisten] ** WARNING: While invalid X509 certificates may be used to

2020-11-09T06:41:16.838+0000 I  CONTROL  [initandlisten] **          connect to this server, they will not be considered

2020-11-09T06:41:16.838+0000 I  CONTROL  [initandlisten] **          permissible for authentication.

2020-11-09T06:41:16.838+0000 I  CONTROL  [initandlisten]

rs0:SECONDARY> rs.status()

{

        "set" : "rs0",

        "date" : ISODate("2020-11-09T07:42:04.984Z"),

        "myState" : 2,

        "term" : NumberLong(5),

        "syncingTo" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

        "syncSourceHost" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

        "syncSourceId" : 0,

        "heartbeatIntervalMillis" : NumberLong(2000),

        "majorityVoteCount" : 2,

        "writeMajorityCount" : 2,

        "optimes" : {

                "lastCommittedOpTime" : {

                        "ts" : Timestamp(1604907723, 4),

                        "t" : NumberLong(5)

                },

                "lastCommittedWallTime" : ISODate("2020-11-09T07:42:03.395Z"),

                "readConcernMajorityOpTime" : {

                        "ts" : Timestamp(1604907723, 4),

                        "t" : NumberLong(5)

                },

                "readConcernMajorityWallTime" : ISODate("2020-11-09T07:42:03.395Z"),

                "appliedOpTime" : {

                        "ts" : Timestamp(1604907723, 4),

                        "t" : NumberLong(5)

                },

                "durableOpTime" : {

                        "ts" : Timestamp(1604907723, 4),

                        "t" : NumberLong(5)

                },

                "lastAppliedWallTime" : ISODate("2020-11-09T07:42:03.395Z"),

                "lastDurableWallTime" : ISODate("2020-11-09T07:42:03.395Z")

        },

        "lastStableRecoveryTimestamp" : Timestamp(1604907678, 3),

        "lastStableCheckpointTimestamp" : Timestamp(1604907678, 3),

        "members" : [

                {

                        "_id" : 0,

                        "name" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "health" : 1,

                        "state" : 1,

                        "stateStr" : "PRIMARY",

                        "uptime" : 3632,

                        "optime" : {

                                "ts" : Timestamp(1604907723, 4),

                                "t" : NumberLong(5)

                        },

                        "optimeDurable" : {

                                "ts" : Timestamp(1604907723, 4),

                                "t" : NumberLong(5)

                        },

                       "optimeDate" : ISODate("2020-11-09T07:42:03Z"),

                        "optimeDurableDate" : ISODate("2020-11-09T07:42:03Z"),

                        "lastHeartbeat" : ISODate("2020-11-09T07:42:04.246Z"),

                        "lastHeartbeatRecv" : ISODate("2020-11-09T07:42:03.162Z"),

                        "pingMs" : NumberLong(0),

                        "lastHeartbeatMessage" : "",

                        "syncingTo" : "",

                        "syncSourceHost" : "",

                        "syncSourceId" : -1,

                        "infoMessage" : "",

                        "electionTime" : Timestamp(1604904092, 1),

                        "electionDate" : ISODate("2020-11-09T06:41:32Z"),

                        "configVersion" : 3

                },

                {

                        "_id" : 1,

                        "name" : "mongodb-cluster-s9s-rs0-1.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "health" : 1,

                        "state" : 2,

                        "stateStr" : "SECONDARY",

                        "uptime" : 3632,

                        "optime" : {

                                "ts" : Timestamp(1604907723, 4),

                                "t" : NumberLong(5)

                        },

                        "optimeDurable" : {

                                "ts" : Timestamp(1604907723, 4),

                                "t" : NumberLong(5)

                        },

                        "optimeDate" : ISODate("2020-11-09T07:42:03Z"),

                        "optimeDurableDate" : ISODate("2020-11-09T07:42:03Z"),

                        "lastHeartbeat" : ISODate("2020-11-09T07:42:04.244Z"),

                        "lastHeartbeatRecv" : ISODate("2020-11-09T07:42:04.752Z"),

                        "pingMs" : NumberLong(0),

                        "lastHeartbeatMessage" : "",

                        "syncingTo" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "syncSourceHost" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "syncSourceId" : 2,

                        "infoMessage" : "",

                        "configVersion" : 3

                },

                {

                        "_id" : 2,

                        "name" : "mongodb-cluster-s9s-rs0-2.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "health" : 1,

                        "state" : 2,

                        "stateStr" : "SECONDARY",

                        "uptime" : 3651,

                        "optime" : {

                                "ts" : Timestamp(1604907723, 4),

                                "t" : NumberLong(5)

                        },

                        "optimeDate" : ISODate("2020-11-09T07:42:03Z"),

                        "syncingTo" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "syncSourceHost" : "mongodb-cluster-s9s-rs0-0.mongodb-cluster-s9s-rs0.default.svc.cluster.local:27017",

                        "syncSourceId" : 0,

                        "infoMessage" : "",

                        "configVersion" : 3,

                        "self" : true,

                        "lastHeartbeatMessage" : ""

                }

        ],

        "ok" : 1,

        "$clusterTime" : {

                "clusterTime" : Timestamp(1604907723, 4),

                "signature" : {

                        "hash" : BinData(0,"HYC0i49c+kYdC9M8KMHgBdQW1ac="),

                        "keyId" : NumberLong("6892206918371115011")

                }

        },

        "operationTime" : Timestamp(1604907723, 4)

}

Eftersom operatören hanterar konsistensen av klustret, när ett fel eller låt säga en pod har tagits bort. Operatören kommer automatiskt att initiera en ny. Till exempel,

$ kubectl get po

NAME                                              READY   STATUS    RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         2/2     Running   0          2d5h

mongodb-cluster-s9s-rs0-1                         2/2     Running   0          2d5h

mongodb-cluster-s9s-rs0-2                         2/2     Running   0          2d5h

percona-client                                    1/1     Running   0          3m7s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running   0          2d5h

$ kubectl delete po mongodb-cluster-s9s-rs0-1

pod "mongodb-cluster-s9s-rs0-1" deleted

$ kubectl get po

NAME                                              READY   STATUS     RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         2/2     Running    0          2d5h

mongodb-cluster-s9s-rs0-1                         0/2     Init:0/1   0          3s

mongodb-cluster-s9s-rs0-2                         2/2     Running    0          2d5h

percona-client                                    1/1     Running    0          3m29s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running    0          2d5h

$ kubectl get po

NAME                                              READY   STATUS            RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         2/2     Running           0          2d5h

mongodb-cluster-s9s-rs0-1                         0/2     PodInitializing   0          10s

mongodb-cluster-s9s-rs0-2                         2/2     Running           0          2d5h

percona-client                                    1/1     Running           0          3m36s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running           0          2d5h

$ kubectl get po

NAME                                              READY   STATUS    RESTARTS   AGE

mongodb-cluster-s9s-rs0-0                         2/2     Running   0          2d5h

mongodb-cluster-s9s-rs0-1                         2/2     Running   0          26s

mongodb-cluster-s9s-rs0-2                         2/2     Running   0          2d5h

percona-client                                    1/1     Running   0          3m52s

percona-server-mongodb-operator-588db759d-qjv29   1/1     Running   0          2d5h

Nu när vi är klara. Naturligtvis kan du behöva exponera porten så att du kan behöva ta itu med justeringar i deploy/cr.yaml. Du kan hänvisa hit för att hantera det.

Slutsats

Percona Kubernetes Operator för PSMDB kan vara din kompletta lösning speciellt för containeriserade miljöer för din Percona Server för MongoDB-installation. Det är nästan en komplett lösning eftersom den har inbyggd redundans för din replikuppsättning men operatören stöder säkerhetskopiering, skalbarhet, hög tillgänglighet och säkerhet.


  1. Redis tar inte upp Broadcast-evenemang i Laravel 5.1

  2. Varför Mongodb prestanda bättre på Linux än på Windows?

  3. Hur man genererar ett unikt objekt-id i mongodb

  4. Hantera långsamma frågor i MongoDB