MongoDB et Kubernetes forment une excellente combinaison, en particulier en ce qui concerne la complexité. Pourtant, MongoDB (PSMDB) de Percona offre plus de flexibilité pour la base de données NoSQL, et il est également livré avec des outils efficaces pour la productivité d'aujourd'hui; non seulement sur site, mais également disponible pour les natifs du cloud.
Le taux d'adoption de Kubernetes augmente régulièrement. Il est raisonnable qu'une technologie doive avoir un opérateur pour faire ce qui suit :création, modification et suppression d'éléments Percona Server pour l'environnement MongoDB. L'opérateur Percona MongoDB Kubernetes contient les paramètres k8s nécessaires pour maintenir un serveur Percona cohérent pour une instance MongoDB. Comme option alternative, vous pouvez comparer cela à https://github.com/kubedb/mongodb mais KubeDB pour MongoDB offre des options très limitées à offrir, en particulier sur les systèmes de niveau de production.
Les opérateurs Percona Kubernetes bénéficiant de sa configuration sont basés et suivent les meilleures pratiques pour la configuration du jeu de réplicas PSMDB. Ce qui compte le plus, l'opérateur pour MongoDB lui-même offre de nombreux avantages mais le gain de temps, un environnement cohérent sont les plus importants. Dans ce blog, nous allons donner un aperçu de la façon dont cela est bénéfique, en particulier dans un environnement conteneurisé.
Que peut offrir cet opérateur ?
Cet opérateur est utile pour PSMDB utilisant un jeu de répliques. Cela signifie que l'architecture de conception de votre base de données doit être conforme au schéma ci-dessous
Image empruntée à l'aperçu de la conception de la documentation de PerconaImage empruntée à l'aperçu de la conception de la documentation de Percona
Actuellement, les plates-formes prises en charge disponibles pour cet opérateur sont :
- OpenShift 3.11
- OpenShift 4.5
- Google Kubernetes Engine (GKE) 1.15 - 1.17
- Amazon Elastic Container Service pour Kubernetes (EKS) 1.15
- Minikube 1.10
- VMWare Tanzu
D'autres plates-formes Kubernetes peuvent également fonctionner mais n'ont pas été testées.
Limites des ressources
Un cluster exécutant une plate-forme officiellement prise en charge contient au moins trois nœuds, avec les ressources suivantes :
- 2 Go de RAM
- 2 threads CPU par nœud pour le provisionnement des pods
- au moins 60 Go de stockage disponible pour le provisionnement des volumes privés
Contraintes de sécurité et/ou restrictions
Le Kubernetes fonctionne comme lors de la création de Pods, chaque Pod a une adresse IP dans le réseau virtuel interne du cluster. La création ou la destruction de pods sont des processus dynamiques, il n'est donc pas recommandé de lier vos pods à des adresses IP spécifiques attribuées pour la communication entre les pods. Cela peut causer des problèmes à mesure que les choses changent avec le temps en raison de la mise à l'échelle du cluster, d'erreurs involontaires, de pannes de courant continu ou de catastrophes, ou d'une maintenance périodique, etc. Dans ce cas, l'opérateur vous recommande strictement de vous connecter à Percona Server pour MongoDB via Kubernetes interne Noms DNS dans l'URI (par exemple, mongodb+srv://userAdmin:[email protected]
Cet opérateur Kubernetes PSMDB utilise également l'affinité/anti-affinité qui fournit des contraintes selon lesquelles vos pods peuvent être programmés pour s'exécuter ou lancés sur un nœud spécifique. L'affinité définit les pods éligibles qui peuvent être planifiés sur le nœud qui a déjà des pods avec des étiquettes spécifiques. L'anti-affinité définit les pods qui ne sont pas éligibles. Cette approche permet de réduire les coûts en s'assurant que plusieurs pods avec des échanges de données intensifs occupent la même zone de disponibilité voire le même nœud ou, au contraire, de répartir les pods sur différents nœuds voire différentes zones de disponibilité à des fins de haute disponibilité et d'équilibrage. Bien que l'opérateur vous encourage à définir l'affinité/anti-affinité, cela a des limites lors de l'utilisation de Minikube.
Lorsque vous utilisez Minikube, il présente les limitations spécifiques à la plate-forme suivantes. Minikube ne prend pas en charge les configurations de cluster multi-nœuds en raison de sa nature locale, qui est en conflit avec les exigences d'affinité par défaut de l'opérateur. Pour organiser cela, l'instruction Installer Percona Server pour MongoDB sur Minikube comprend une étape supplémentaire qui désactive l'exigence d'avoir au moins trois nœuds.
Dans la section suivante de ce blog, nous allons configurer PMSDB Kubernetes Operator à l'aide de Minikube et nous suivrons l'anti-affinité définie pour le faire fonctionner. En quoi cela diffère-t-il de l'utilisation de l'anti-affinité, si vous modifiez AntiAffinity, vous augmentez les risques pour la disponibilité du cluster. Disons que si votre objectif principal de déploiement de votre PSMDB dans un environnement conteneurisé est de se propager et d'avoir une disponibilité plus élevée mais une évolutivité, cela pourrait aller à l'encontre de l'objectif. Pourtant, utiliser Minikube en particulier sur site et pour tester votre configuration PSMDB est faisable, mais pour les charges de travail de production, vous souhaitez sûrement exécuter des nœuds sur des hôtes séparés, ou dans une configuration d'environnement telle qu'une défaillance simultanée de plusieurs pods est peu susceptible de se produire. /P>
Données en transit/Données au repos
Pour la sécurité des données avec PSMDB, l'opérateur propose TLS/SSL pour le transit, puis propose également le chiffrement lorsque les données sont au repos. Pour en transit, les options que vous pouvez choisir sont d'utiliser cert-manager ou de générer votre propre certificat manuellement. Bien sûr, vous pouvez éventuellement utiliser PSMDB sans TLS pour cet opérateur. Consultez leur documentation concernant l'utilisation de TLS.
Pour les données au repos, cela nécessite des modifications dans leur opérateur Kubernetes PSMDB après avoir téléchargé la branche github, puis appliquez les modifications sur le fichier deploy/cr.yaml. Pour l'activer, procédez comme suggéré par la documentation :
- La clé security.enableEncryption doit être définie sur true (valeur par défaut).
- La clé security.encryptionCipherMode doit spécifier le mode de chiffrement approprié pour le déchiffrement. La valeur peut être l'une des deux variantes suivantes :
- AES256-CBC (celui par défaut pour l'opérateur et le serveur Percona pour MongoDB)
- AES256-GCM
security.encryptionKeySecret should specify a secret object with the encryption key:
mongod:
...
security:
...
encryptionKeySecret: my-cluster-name-mongodb-encryption-keyLa clé secrète de chiffrement sera créée automatiquement si elle n'existe pas. Si vous souhaitez le créer vous-même, tenez compte du fait que la clé doit être une chaîne de 32 caractères encodée en base64.
Stocker des informations sensibles
L'opérateur Kubernetes PSMDB utilise les secrets Kubernetes pour stocker et gérer les informations sensibles. Les secrets Kubernetes vous permettent de stocker et de gérer des informations sensibles, telles que des mots de passe, des jetons OAuth et des clés ssh. Stocker des informations confidentielles dans un secret est plus sûr et plus flexible que de les mettre textuellement dans une définition de pod ou dans une image de conteneur.
Pour cet opérateur, l'utilisateur et les mots de passe générés pour vos pods sont stockés et peuvent être obtenus à l'aide de kubectl get secrets
Pour ce blog, mon exemple de configuration réalise ce qui suit avec le résultat décodé en 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
userAdminChaque entrée pour la sauvegarde, l'utilisateur du cluster, l'utilisateur du moniteur de cluster et l'utilisateur pour l'utilisation administrative s'affiche en fonction du résultat ci-dessus.
Une autre chose est que PSMDB Kubernetes Operator stocke également l'accès AWS S3 et les clés secrètes via Kubernetes Secrets.
Sauvegardes
Cet opérateur prend en charge les sauvegardes, ce qui est une fonctionnalité très intéressante. Il prend en charge la sauvegarde à la demande (manuelle) et la sauvegarde planifiée et utilise l'outil de sauvegarde Percona Backup pour MongoDB. Notez que les sauvegardes ne sont stockées que sur AWS S3 ou tout stockage compatible S3.
Les sauvegardes planifiées peuvent être définies via le fichier deploy/cr.yaml, tandis qu'une sauvegarde manuelle peut être effectuée à tout moment chaque fois que la demande est nécessaire. Pour l'accès S3 et les clés secrètes, elles doivent être définies dans le fichier deploy/backup-s3.yaml et utilisent les secrets Kubernetes pour stocker les informations suivantes, comme nous l'avons mentionné précédemment.
Toutes les actions prises en charge pour cet opérateur Kubernetes PSMDB sont les suivantes :
- Effectuer des sauvegardes planifiées
- Effectuer une sauvegarde à la demande
- Restaurer le cluster à partir d'une sauvegarde précédemment enregistrée
- Supprimer la sauvegarde inutile
Utilisation de l'opérateur Kubernetes PSMDB avec Minikube
Dans cette section, nous conserverons une configuration simple utilisant Kubernetes avec Minikube, que vous pouvez utiliser sur site sans avoir besoin d'un fournisseur de cloud. Pour une configuration cloud native, en particulier pour un environnement de niveau entreprise et de production, vous pouvez consulter leur documentation.
Avant de poursuivre les étapes, gardez à l'esprit que, comme mentionné ci-dessus, il existe une limitation connue avec Minikube car il ne prend pas en charge la configuration de cluster multi-nœuds qui est en conflit avec les exigences d'affinité par défaut de l'opérateur. Nous le mentionnerons sur la façon de le gérer dans les étapes suivantes ci-dessous.
Pour ce blog, l'OS hôte sur lequel notre Minikube sera installé est sur Ubuntu 18.04 (Bionic Beaver).
Installons Minikube
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.debVous pouvez éventuellement suivre les étapes ici si vous utilisez différents systèmes Linux.
Ajoutons la clé requise pour authentifier nos packages Kubernetes et configurons le référentiel
$ 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
eofInstallons maintenant les packages requis
$ sudo apt-get update
$ sudo apt-get install kubelet kubeadm kubectlDémarrer le Minikube en définissant la mémoire, le nombre de CPU et le CIDR pour lesquels mes nœuds seront assignés,
$ minikube start --memory=4096 --cpus=3 --extra-config=kubeadm.pod-network-cidr=192.168.0.0/16Les résultats de l'exemple ressemblent à,
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 defaultComme vous l'avez remarqué, il installe également les outils utilitaires pour gérer et administrer vos nœuds ou pods.
Maintenant, vérifions les nœuds et les pods en exécutant les commandes suivantes,
$ 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.8Maintenant, téléchargez l'opérateur Kubernetes PSMDB,
$ git clone -b v1.5.0 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operatorNous sommes maintenant prêts à déployer l'opérateur,
$ kubectl apply -f deploy/bundle.yamlComme mentionné précédemment, les limitations de Minikube nécessitent des ajustements pour que les choses fonctionnent comme prévu. Procédons comme suit :
- En fonction de votre capacité matérielle actuelle, vous pouvez modifier les éléments suivants comme suggéré par la documentation. Étant donné que minikube s'exécute localement, le fichier deploy/cr.yaml par défaut doit être modifié pour adapter l'opérateur à l'installation locale avec des ressources limitées. Modifiez les clés suivantes dans la section replsets :
- commentez les clés resources.requests.memory et resources.requests.cpu (cela conviendra à l'opérateur dans les limitations par défaut de minikube)
- définir la clé affinity.antiAffinityTopologyKey sur "none" (l'Opérateur ne pourra pas répartir le cluster sur plusieurs nœuds)
- En outre, réglez la clé allowUnsafeConfigurations sur true (cette option désactive le contrôle de l'opérateur sur la configuration du cluster, ce qui permet de déployer Percona Server pour MongoDB en tant que cluster à un nœud).
Maintenant, nous sommes prêts à appliquer les modifications apportées au fichier deploy/cr.yaml.
$ kubectl apply -f deploy/cr.yamlÀ ce stade, vous pourrez peut-être vérifier l'état des pods et vous remarquerez la progression suivante, comme ci-dessous,
$ 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 33mMaintenant que nous y sommes presque. Nous obtiendrons les secrets générés par l'opérateur afin de pouvoir nous connecter aux pods PSMDB créés. Pour ce faire, vous devez d'abord lister les objets secrets, puis obtenir la valeur du yaml afin d'obtenir la combinaison utilisateur/mot de passe. D'autre part, vous pouvez utiliser la commande combinée ci-dessous avec le format nom d'utilisateur:mot de passe. Voir l'exemple ci-dessous,
$ 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:TQBEV7rtE15quFl5Maintenant, vous pouvez baser le format nom d'utilisateur :mot de passe et l'enregistrer quelque part en toute sécurité.
Comme nous ne pouvons pas nous connecter directement au serveur Percona pour les nœuds MongoDB, nous devons créer un nouveau pod qui a le client mongodb,
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.2.8-8 --restart=Never -- bash -ilEnfin, nous sommes maintenant prêts à nous connecter à nos nœuds PSMDB maintenant,
bash-4.2$ mongo "mongodb+srv://userAdmin:[email protected]/admin?replicaSet=rs0&ssl=false"Alternativement, vous pouvez vous connecter aux nœuds individuels et vérifier leur santé. Par exemple,
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)
}Puisque l'opérateur gère la cohérence du cluster, chaque fois qu'une panne ou disons qu'un pod a été supprimé. L'opérateur en lancera automatiquement un nouveau. Par exemple,
$ 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 2d5hMaintenant que nous sommes prêts. Bien sûr, vous devrez peut-être exposer le port afin de devoir gérer des ajustements dans deploy/cr.yaml. Vous pouvez vous référer ici pour vous en occuper.
Conclusion
L'opérateur Percona Kubernetes pour PSMDB peut être votre solution complète, en particulier pour les environnements conteneurisés pour votre configuration Percona Server pour MongoDB. Il s'agit d'une solution presque complète car elle intègre une redondance pour votre jeu de répliques, mais l'opérateur prend en charge la sauvegarde, l'évolutivité, la haute disponibilité et la sécurité.
