Continuing with the series of guides for application protectionones about services Kubernetes in public clouds, now it's Microsoft Azure's turn Kubernetes Service or Azure AKS, where we will review step by step the installation, configuration and execution of backup policies with Kasten K10, integrating the console with K10 Multi-Cluster Manager for centralized application management and protectionones in AKS.
First steps
We should always review the official documentation of Kasten, for the installation we must review the following links and of course never forget the execution of the "Pre-Flight Checks":
- https://docs.kasten.io/latest/install/requirements.html
- https://docs.kasten.io/latest/install/azure/azure.html
Now we will passoneContact us via “cli” to our cluster AKS from the console interface in the Azure portal or from your computer where you manage your clusters kubernetes. In case you don't have the kubeconfig file configured yet, just run the following command in the Azure shell:
az aks get-credentials -g 24xsiempre -n demoaks
Where after "-g" you must enter the name of the associated "Resource Group" and after "-n" you must enter the name of the cluster AKS, with the previous command the “config” file will be created inside the “.kube” folder in the user's home. And to validate, you can list the cluster nodes AKS running:
kubectl get nodes -o wide
Install Kasten K10 on Azure AKS
Since we are coneconnected to the Azure cluster AKS, we will execute the pre-requisites command that the documentation of Kasten, therefore we will proceed to create the namespace “kasten-io” to then run the script:
helm repo add kasten https://charts.kasten.io/
kubectl create namespace kasten-io
curl https://docs.kasten.io/tools/k10_primer.sh | bash
It is very important to record the messages delivered by the pre-check script, since it will indicate that a "VolumeSnapshotClass" is needed for the StorageClass that is being used by default in AKS, which we will review later. Before proceeding with the installation via "helm", we must register an application in Azure to obtain the necessary variables, therefore in the Azure portal, in the default directory, we will create a new application:
Then we will create the key in "Certificates and Secrets", we will assign the name and create:
After the creation of the application in Azure, we will take the following data:
- azureTenantId
- azureClientId
- azureClientSecret
You will find the first two IDs in the "General Information" of the created application and the third or secret you copy from the previous creation, to generate the following command:
helm install k10 kasten/k10 --namespace=kasten-io \
--set secrets.azureTenantId=9afedb96-a2f5-4e9c-a78a-123456789012 \
--set secrets.azureClientId=849b0886-5fa1-4464-863d-123456789012 \
--set secrets.azureClientSecret=iJ57Q~KGK5euTOLkIS1duXDx~123456789012 \
--set externalGateway.create=true \
--set auth.tokenAuth.enabled=true
With the above, we install Kasten K10 on Azure AKS including the creation of the "LoadBalancer" and token Authentikation, which we have reviewed many timesoneyes To validate the correct operation of Kasten K10, you must execute the command:
kubectl get pods -n kasten-io
As all the pods are in "Running" we will proceed to check which is the IP address to access the web interface of Kasten K10 with the following command:
kubectl get svc -n kasten-io
So the console access in this case is http://20.98.177.166/k10/ where we can Authentikate via token:
If you still don't know how to extract the token
sa_secret=$(kubectl get serviceaccount k10-k10 -o jsonpath="{.secrets[0].name}" --namespace kasten-io)
kubectl get secret $sa_secret --namespace kasten-io -ojsonpath="{.data.token}{'\n'}" | base64 --decode
Integration with K10 Multi Cluster Manager
If you don't have installed yet K10 Multi-Cluster Manager, check:
And in this case for Microsoft AKS we must copy the kubeconfig of the cluster AKS, within the Azure shell we will execute:
cat .kube/config
We copy the kubeconfig and paste it in our K10 Multi-Cluster Manager, after clicking “Add Cluster”:
An important fact, in this case, it is not necessary to prepare the kubeconfig file with the executable k10multicluster, as if other providers need it, therefore, the configuration is direct, you enter the name of the cluster that will appear, the address of the "Ingress URL" and finally disabling the TLS verification. In case you have TLS activated, just leave it by default and you will be able to see the cluster AKS in the Multi-Cluster console:
Azure Blob Storage
Now we will configure a repository to host our backups in “Location Profiles”, enter the name, select “Azure Storage” and enter the credentials, location and container
When saving the "Profile" we will have our repository to host backups and it will be seen:
Azure Backup Policy AKS
We will create a basic backup policy by selecting “Snapshot” and using the previously created repository to then execute the policy:
When the policy runs and tries to take a snapshot of the persistent volume it is using, in this case, MongoDB, it will display the following error:
...
Failed to run CSI prechecks for PVC
Failed to get K10 VolumeSnapshotClass
...
And this is where it is shown that it is very important to run the script that checks the "Pre-Flight Checks", since when it is run for the first time it will indicate that the "VolumeSnapshotClass" does not exist as we saw earlier. Therefore, we will proceed to create the VSC with the following command:
cat <<EOF | kubectl apply -f -
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
annotations:
k10.kasten.io/is-snapshot-class: "true"
name: csi-azure-vsc
driver: disk.csi.azure.com
deletionPolicy: Delete
parameters:
incremental: "true"
EOF
And then we run the “Pre-Flight Checks” script again:
curl https://docs.kasten.io/tools/k10_primer.sh | bash
And we will see the successful message of the correct configuration of this VSC with the default StorageClass. Then run the backup policy again and it will finish successfully:
Backups in Azure Blob
For the backup, we can see the files generated by Kasten K10 in the Azure Blob container that we configured earlier in “Location Profiles”, by entering the Storage explorer of the Microsoft Azure portal:
Recommendations
As always, security comes first, applying access only by address.ones of trust as well as applying RBAC to access via Multi-Cluster Manager and of course if it is necessary to apply permissions to service accounts with the minimum access for operation.