Install Percona Server for MongoDB on Azure Kubernetes Service (AKS)¶
This guide shows you how to deploy Percona Operator for MongoDB on Microsoft Azure Kubernetes Service (AKS). The document assumes some experience with the platform. For more information on the AKS, see the Microsoft AKS official documentation .
Prerequisites¶
The following tools are used in this guide and therefore should be preinstalled:
-
Azure Command Line Interface (Azure CLI) for interacting with the different parts of AKS. You can install it following the official installation instructions for your system .
-
kubectl to manage and deploy applications on Kubernetes. Install it following the official installation instructions .
Also, you need to sign in with Azure CLI using your credentials according to the official guide .
Create and configure the AKS cluster¶
To create your cluster, you will need the following data:
- name of your AKS cluster,
- an Azure resource group , in which resources of your cluster will be deployed and managed.
- the amount of nodes you would like tho have.
You can create your cluster via command line using az aks create
command.
The following command will create a 3-node cluster named my-cluster-name
within some already existing resource group named my-resource-group
:
$ az aks create --resource-group my-resource-group --name my-cluster-name --enable-managed-identity --node-count 3 --node-vm-size Standard_B4ms --node-osdisk-size 30 --network-plugin kubenet --generate-ssh-keys --outbound-type loadbalancer
Other parameters in the above example specify that we are creating a cluster with x86_64 machine type of Standard_B4ms and OS disk size reduced to 30 GiB. If you need ARM64, use different machine type, for example, Standard_D4ps_v5. You can see detailed information about cluster creation options in the AKS official documentation .
You may wait a few minutes for the cluster to be generated.
Now you should configure the command-line access to your newly created cluster
to make kubectl
be able to use it.
az aks get-credentials --resource-group my-resource-group --name my-cluster-name
Install the Operator and deploy your MongoDB cluster¶
-
Deploy the Operator. By default deployment will be done in the
default
namespace. If that’s not the desired one, you can create a new namespace and/or set the context for the namespace as follows (replace the<namespace name>
placeholder with some descriptive name):$ kubectl create namespace <namespace name> $ kubectl config set-context $(kubectl config current-context) --namespace=<namespace name>
At success, you will see the message that
namespace/<namespace name>
was created, and the context (<cluster name>
) was modified.Deploy the Operator, using the following command:
$ kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.19.1/deploy/bundle.yaml
Expected output
customresourcedefinition.apiextensions.k8s.io/perconaservermongodbs.psmdb.percona.com serverside-applied customresourcedefinition.apiextensions.k8s.io/perconaservermongodbbackups.psmdb.percona.com serverside-applied customresourcedefinition.apiextensions.k8s.io/perconaservermongodbrestores.psmdb.percona.com serverside-applied role.rbac.authorization.k8s.io/percona-server-mongodb-operator serverside-applied serviceaccount/percona-server-mongodb-operator serverside-applied rolebinding.rbac.authorization.k8s.io/service-account-percona-server-mongodb-operator serverside-applied deployment.apps/percona-server-mongodb-operator serverside-applied
-
The Operator has been started, and you can deploy your MongoDB cluster:
$ kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.19.1/deploy/cr.yaml
Expected output
perconaservermongodb.psmdb.percona.com/my-cluster-name created
Note
This deploys default MongoDB cluster configuration, three mongod, three mongos, and three config server instances. Please see deploy/cr.yaml and Custom Resource Options for the configuration options. You can clone the repository with all manifests and source code by executing the following command:
$ git clone -b v1.19.1 https://github.com/percona/percona-server-mongodb-operator
After editing the needed options, apply your modified
deploy/cr.yaml
file as follows:$ kubectl apply -f deploy/cr.yaml
Clone the repository with all manifests and source code by executing the following command:
$ git clone -b v1.19.1 https://github.com/percona/percona-server-mongodb-operator
Edit the
deploy/cr.yaml
configuration file: setimage
andbackup.image
Custom Resource options to special multi-architecture image versions by adding a-multi
suffix to their tags:.... image: percona/percona-server-mongodb:7.0.14-8-multi ... backup: ... image: percona/percona-backup-mongodb:2.8.0-multi
Please note, that currently monitoring with PMM is not supported on ARM64 configurations.
After editing, apply your modified
deploy/cr.yaml
file as follows:$ kubectl apply -f deploy/cr.yaml
Expected output
perconaservermongodb.psmdb.percona.com/my-cluster-name created
The creation process may take some time. When the process is over your cluster will obtain the
ready
status. You can check it with the following command:$ kubectl get psmdb
Expected output
NAME ENDPOINT STATUS AGE my-cluster-name my-cluster-name-mongos.default.svc.cluster.local ready 5m26s
Verifying the cluster operation¶
It may take ten minutes to get the cluster started. When kubectl get psmdb
command finally shows you the cluster status as ready
, you can try to connect
to the cluster.
To connect to Percona Server for MongoDB you need to construct the MongoDB connection URI string. It includes the credentials of the admin user, which are stored in the Secrets object.
-
List the Secrets objects
$ kubectl get secrets -n <namespace>
The Secrets object you are interested in has the
my-cluster-name-secrets
name by default. -
View the Secret contents to retrive the admin user credentials.
The command returns the YAML file with generated Secrets, including the$ kubectl get secret my-cluster-name-secrets -o yaml
MONGODB_DATABASE_ADMIN_USER
andMONGODB_DATABASE_ADMIN_PASSWORD
strings, which should look as follows:Sample output
... data: ... MONGODB_DATABASE_ADMIN_PASSWORD: aDAzQ0pCY3NSWEZ2ZUIzS1I= MONGODB_DATABASE_ADMIN_USER: ZGF0YWJhc2VBZG1pbg==
The actual login name and password on the output are base64-encoded. To bring it back to a human-readable form, run:
$ echo 'MONGODB_DATABASE_ADMIN_USER' | base64 --decode $ echo 'MONGODB_DATABASE_ADMIN_PASSWORD' | base64 --decode
-
Run a container with a MongoDB client and connect its console output to your terminal. The following command does this, naming the new Pod
percona-client
:$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:7.0.14-8 --restart=Never -- bash -il
Executing it may require some time to deploy the corresponding Pod.
-
Now run
mongosh
tool inside thepercona-client
command shell using the admin user credentialds you obtained from the Secret, and a proper namespace name instead of the<namespace name>
placeholder. The command will look different depending on whether sharding is on (the default behavior) or off:$ mongosh "mongodb://databaseAdmin:databaseAdminPassword@my-cluster-name-mongos.<namespace name>.svc.cluster.local/admin?ssl=false"
$ mongosh "mongodb+srv://databaseAdmin:databaseAdminPassword@my-cluster-name-rs0.<namespace name>.svc.cluster.local/admin?replicaSet=rs0&ssl=false"
Note
If you are using MongoDB versions earler than 6.x (such as 5.0.29-25 instead of the default 7.0.14-8 variant), substitute
mongosh
command withmongo
in the above examples.
Troubleshooting¶
If kubectl get psmdb
command doesn’t show ready
status too long, you can
check the creation process with the kubectl get pods
command:
$ kubectl get pods
Expected output
NAME READY STATUS RESTARTS AGE
my-cluster-name-cfg-0 2/2 Running 0 11m
my-cluster-name-cfg-1 2/2 Running 1 10m
my-cluster-name-cfg-2 2/2 Running 1 9m
my-cluster-name-mongos-0 1/1 Running 0 11m
my-cluster-name-mongos-1 1/1 Running 0 11m
my-cluster-name-mongos-2 1/1 Running 0 11m
my-cluster-name-rs0-0 2/2 Running 0 11m
my-cluster-name-rs0-1 2/2 Running 0 10m
my-cluster-name-rs0-2 2/2 Running 0 9m
percona-server-mongodb-operator-665cd69f9b-xg5dl 1/1 Running 0 37m
If the command output had shown some errors, you can examine the problematic
Pod with the kubectl describe <pod name>
command as follows:
$ kubectl describe pod my-cluster-name-rs0-2
Review the detailed information for Warning
statements and then correct the
configuration. An example of a warning is as follows:
Warning FailedScheduling 68s (x4 over 2m22s) default-scheduler 0/1 nodes are available: 1 node(s) didn’t match pod affinity/anti-affinity, 1 node(s) didn’t satisfy existing pods anti-affinity rules.
Removing the AKS cluster¶
To delete your cluster, you will need the following data:
- name of your AKS cluster,
- AWS region in which you have deployed your cluster.
You can clean up the cluster with the az aks delete
command as follows (with
real names instead of <resource group>
and <cluster name>
placeholders):
$ az aks delete --name <cluster name> --resource-group <resource group> --yes --no-wait
It may take ten minutes to get the cluster actually deleted after executing this command.
Warning
After deleting the cluster, all data stored in it will be lost!