Ok, so if your new to the #Kubernetes space you will notice one thing - everyone does their demo on the command-line!
Arrgghh - didn't we stop using command-line tools 10 years ago? Well yes, but command-line and system to system automation is what is now driving our major cloud providers, and development of containerized or modern applications.
So what does all that mean? It means it's time to get comfortable with the command-line again don't worry Kubernetes and it's command-line tool - kubectl is literally one of the easiest CLI tools I have ever learnt.
Let's walk through the basics of what we normally check on a Metallic or Commvault Backup & Recovery protected system.
Table of Content so we don't get lost....
First things first - you are going to need kubectl.
Next your going to need some login details to place in your kubeconfig file, which is just a fancy name for the file that contains your credentials to the Kubernetes cluster you want to admin.
See Organizing Cluster Access Using kubeconfig Files for the details of managing at scale - but for now let's just take a look at an example file (below)
- name: clusterUser_KubeCon2021_KubeConEU
The important bits are server: which is the server (kube-apiserver) you want to connect to.
And the user and token sections.
Let's actually create a Commvault backup user as our next step.
Creating a backup user
Creating a Metallic backup user is the first thing you will do to start protecting your stateful K8s apps.
Create a new serviceaccount
kubectl create serviceaccount cvbackup
You can list your new account with kubectl get sa
kubectl get sa
Output will look something like this (yours will likely differ)
NAME SECRETS AGE
cvbackup 1 21h
default 1 21h
You can list your new account secret, which contains the token (i.e. the password) using kubectl describe
kubectl describe sa cvbackup
Again, your output will differ, but the important thing is the Tokens line
Image pull secrets: <none>
Mountable secrets: cvbackup-token-2l26v
Let's now describe our secret with kubectl describe secret
kubectl describe secret cvbackup-token-2l26v
Output will show something like this.
Annotations: kubernetes.io/service-account.name: cvbackup
ca.crt: 1761 bytes
namespace: 7 bytes
The token provides authenticated access to your cluster - ensure you store it safely.
Now you have:
- Username: cvbackup
- Token: SNIPPED_TO_KEEP_MY_CLUSTER_SAFE
All you need now is your Server URL or kube-apiserver endpoint.
Let's extract that in the next step.
Obtaining your kube-apiserver address
Depending on whether you are using an on-prem, cloud-hosted, or cloud-BYO Kubernetes cluster - you will need to determine your kube-apiserver address.
kube-apiserver is the single entry point for kubectl, Metallic and all any/or automation systems used within your business.
See kube-apiserver for more information
Let's use kubectl config view to view our current kube-apiserver details
kubectl config view
You will see something like this:
- name: clusterUser_KubeCon2021_KubeConEU
The server: line is the kube-apiserver.
Determining which version of Kubernetes is being used
If you manage a large number of clusters, or deploy apps to a large number of clusters - it may get hard to keep track which system you are operating on.
kubectl get nodes will provide details of the active nodes in your environment
kubectl get nodes
This is an example output from a Microsoft Azure AKS cluster (your output may differ)
NAME STATUS ROLES AGE VERSION
aks-nodepool1-85424502-vmss000000 Ready agent 21h v1.19.9
aks-nodepool1-85424502-vmss000001 Ready agent 21h v1.19.9
aks-nodepool1-85424502-vmss000002 Ready agent 21h v1.19.9
Metallic supportability is listed in the following Requirements page
Commvault Backup & Recovery supportability is listed in the following Supported Kubernetes Distributions page
Determining which storage classes are available
It is key to understand what type of storage is used on a cluster, and whether that storage is supported by one of the Production CSI Drivers Drivers - Kubernetes CSI Developer Documentation
Let's use kubectl get storageclasses or kubectl get sc to list the available storage classes:
kubectl get sc
Output will look something like this:
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
azurefile kubernetes.io/azure-file Delete Immediate true 22h
azurefile-csi file.csi.azure.com Delete Immediate true 22h
azurefile-csi-premium file.csi.azure.com Delete Immediate true 22h
azurefile-premium kubernetes.io/azure-file Delete Immediate true 22h
default (default) kubernetes.io/azure-disk Delete WaitForFirstConsumer true 22h
managed-csi disk.csi.azure.com Delete WaitForFirstConsumer true 22h
managed-csi-premium disk.csi.azure.com Delete WaitForFirstConsumer true 22h
managed-premium kubernetes.io/azure-disk Delete WaitForFirstConsumer true 22h
Now what does this tell us?
Well we have a mixture of CSI-based StorageClasses and a number of in-tree StorageClasses (currently being phased out in favour of CSI implementations)
Metallic / Commvault will protect data stored in CSI-based StorageClasses (Out-of-Tree) and Non-CSI / In-Tree StorageClasses.
The following storage classes are CSI based, these are the recommended best practice for snapshot based protection:
The following storage classes are non-CSI based, they predate the release of the CSI framework and are referred to as in-tree storage drivers.
- default (actually azure-disk)
We will continue the storage discovery in our next post...