Once you have deployed your management cluster, you can deploy additional CNCF conformant Kubernetes clusters and manage their full lifecycle. These clusters are designed to run your application workloads, managed via your management cluster. These clusters canrun different Kubernetes versions as required. These clusters use Antrea networking by default.
These types of clusters are also referred to as “workload” clusters, or “guest” clusters, with the latter typically referring to the Tanzu Kubernetes Grid Service running in vSphere.
Deploying a Guest Cluster
Login to your Tanzu environment Management Cluster with the following:
Alternatively, we can use the existing YAML file in our ~/.tanzu/tkg/clusterconfigs folder used for the management cluster deployment and change a few settings to make it ready for our workload guest cluster.
This was my preferred method as it contained all my Azure settings already.
#Find existing cluster config file
ls -lh ~/.tanzu/tkg/clusterconfigs/
#Copy file to a new config
cp ~/.tanzu/tkg/clusterconfigs/6x4hl1wy8o.yaml tanzu-veducate-guest-azure.yaml
# Edit file = CLUSTER_NAME
# Workload cluster names must be 42 characters or less.
This is the first architectural components to be deployed for creating a TKG instance. The management cluster is a dedicated cluster for management and operation of your whole TKG instance infrastructure. A management cluster will have Antrea networking enabled by default. This runs cluster API to create the additional clusters for your workloads to run, as well as the shared and in-cluster services for all clusters within the instance to use.
It is not recommended that the management cluster be used as a general-purpose compute environment for your application workloads.
Tanzu Kubernetes (Guest) Clusters
Once you have deployed your management cluster, you can deploy additional CNCF conformant Kubernetes clusters and manage their full lifecycle. These clusters are designed to run your application workloads, managed via your management cluster. These clusters can run different Kubernetes versions as required. These clusters use Antrea networking by default.
These clusters are referred to as Workload Clusters when working with the Tanzu CLI.
I sometimes use the term “Guest” for these clusters, as a cross-over with the vSphere with Tanzu architecture, which has similar concepts as above however uses the terms “Supervisor Cluster” and “Guest Cluster”.
For this blog post, I’ll be deploying everything from my local Mac OS X machine. You will need the following:
In this blog post we will cover the following topics;
- Adding your Azure Repository to Veeam Backup and Replication
- Viewing your protected data
- What can you do with your data?
- - Backup Copy to another repository
- - File Level Recovery
- - Veeam Explorer - Application Item restore
- - Instant Virtual Machine recovery to vSphere and Hyper-v
- - Restore to Amazon EC2 or Microsoft Azure
If you have an Veeam Backup and Replication install up and running, either on-premise to protect VMware or Hyper-V workloads, or even running in a Public cloud to provide resiliency to your infrastructure, then it’s simple enough to integrate that deployment with the data protected by Veeam Backup for Microsoft Azure.
By linking your Veeam Backup for Azure repository (Azure Storage Account) to your Veeam Backup and Replication environment, you then get access to a whole host of options.
File level recovery via Veeam Backup and Replication console
Instant VM recovery to vSphere/Hyper-V
Restore VM to Amazon EC2
Restore VM to Microsoft Azure
Perform a Backup Copy to another location such as a Cloud Connect Partner.
Adding your Azure Repository to Veeam Backup and Replication
Open your Veeam Backup and Replication console > Go to the “Backup Infrastructure” tab, and right click on External Repositories > Click “Add external repositories”, this will open up the wizard.
Once you have a successful backup policy run, you will find that by navigating to “Protected Data” in the left-hand navigation pane, you will find details of your protected workloads and the backups stored.
Highlighted in the purple box above, we are able to click on each of our protected virtual machines and see the details of the restore points held.
The available restore options are;
Restore a full virtual machine to the same or a different location. This restore uses both the VM configuration and VHD backups.
Restore only a virtual machines hard drive to the same or a different location, these will not be attached to any virtual machines when the restore is complete.
Restore of files and folders from protected instances, which are available to download to your local machine.
Below, we can see the available restore points for my “Ubuntu01” virtual machine. As the backup policy has only run once, I have a single snapshot held with the VM itself, and a single backup of the full virtual machine (VHDS and VM configuration, which are located in my configured Repository.
Backups – Both managed/unmanaged VHDs are saved to the configured Backup Repository.
Managed VHDs – snapshot saved to resource group of source VM,
Unmanaged VHDs – snapshots saved to Azure Storage Account of source VHD
From this view, we can select to restore the Full VM, the individual VHDs, under the Restore option, or we can perform a file-level Recovery under the second self-named option.
File Level Recovery
You can enter a file level recovery as per the above screenshot, or from the main screen by highlighting your protected VMs and clicking file level recovery.
By clicking “Change Restore Point” you will of course see the various points in time available.