Introduction
If there is one advantage introduced by open-source to the virtualization community, it is that, vendor lock-in is a thing of the past now and vendors have come at last to embrace the new normal. VMware and Microsoft are no exception here and the reason for this post is to demonstrate how companies are moving from a proprietary world to an opinionated one which simply means: we feel this is the best combination of open source tools for an implementation but you are free to use whatever you see fit, No lock-in, No forcing, No monopoly, Just Innovation.
This new opinionated open-source approach in the market is not only going to drive innovation like crazy which is a good thing for everyone but also drive cost down for end consumers and mostly relieve this market from BS marketing feuds and statements promoting healthy competition or so I hope.
VMware Tanzu Kubernetes Grid Service introduced with vSphere 7 with Tanzu is an upstream-compliant fully conformant and compatible implementation of Kubernetes that is supported, validated, signed, and tested by VMware. The terms compliant and conformant are really important which is going to be demonstrated here, in which the claim is made that, yes this is a VMware implementation of open-source Kubernetes in which VMware has made the best choice of open-source tools for Container runtime, networking, security, registry, storage, and so on … yet this is still in fact a standard open-source implementation of Kubernetes compliant with the Cloud Native Computing Foundation (CNCF) that can work any where on any infrastructure using any combination of additional open source tools.
This innovation drive led VMware to add Kubelet in the form of Spherelet inside vSphere kernel (Huge Change on proprietary software) to enable direct Kubernetes API integration which enabled them not only to offer the upstream-compliant CNCF conformant version of Kubernetes in the form of TKG clusters but to also offer a unique solution to utilizing ESXi’s as Kubernetes worker nodes enabling the creation of pods and VMs directly on vSphere from vCenter. The point here is that, things are changing for the better in which the open-source now leads the flock and vendors are following.
Microsoft Azure Arc is a cloud service obviously by Microsoft hosted on Azure that allows for the management of Servers, Azure Stack, and/or any Kubernetes environment created outside of Azure on any type of infrastructure from the Azure Control Plane ARM (Azure Resource Manager). This, in concept, would not only allow for the central management of these components from a single management glass but also allows Azure to enable specific features to these added external services that can only be delivered to resources created directly on/within the Azure Cloud. “Azure Arc extends management and services from Azure to any infrastructure. Azure Arc functionality is offered at no additional cost and is applicable to both Arc enabled servers and Arc enabled Kubernetes.”
As of now, Azure Arc provides the following features for added Kubernetes environments:
- Connect Kubernetes running outside of Azure for inventory, grouping, and tagging.
- Deploy applications and apply configuration using GitOps-based configuration management.
- View and monitor your clusters using Azure Monitor for containers.
- Enforce threat protection using Azure Defender for Kubernetes.
- Apply policies using Azure Policy for Kubernetes.
-
Create custom locations as target locations for deploying Azure Arc enabled Data Services, App Services on Azure Arc (including web, function, and logic apps) and Event Grid on Kubernetes.
Configure
I have already created a TKG cluster within my VMware environment and will proceed in adding this cluster to Azure Arc. To do so, there are some requirements from Azure side that can be found here, which I will summarize below.
1- Install Azure CLI https://docs.microsoft.com/en-us/cli/azure/install-azure-cli . After the CLI is installed, run the command ” az login ” after which you are prompted to login to your Azure subscription.
2- Make sure that your kubeconfig file has the correct context pointing to your cluster. The file can be found %userprofile%\.kube\config or view it by using ” kubectl config view ” . To make it easy, I used kubectl config to set the context to my TKG cluster after logging in to the same before going further as I also run other namespaces inside the environment. The star on the left depicts the current context set. Make sure that you have Read and Write permissions which can be set from Workload Management in vCenter.
3- Install HELM which is a package manager for Kubernetes from https://helm.sh/docs/intro/install/ . Just extract helm.exe and add it to variables or just put it in your current working directory in cmd.
4- Run the following command from CLI ” az extension add –name connectedk8s ” . Make sure that your TKG cluster can reach outbound TCP 443 to *.azure.com .
5- Run the following commands from CLI then wait for around 5 minutes and check if the registration is complete via the commands below.
- az provider register –namespace Microsoft.Kubernetes
- az provider register –namespace Microsoft.KubernetesConfiguration
- az provider register –namespace Microsoft.ExtendedLocation
- –
- az provider show -n Microsoft.Kubernetes -o table
- az provider show -n Microsoft.KubernetesConfiguration -o table
- az provider show -n Microsoft.ExtendedLocation -o table
6- Create a Resource Group if you don’t already have one then connect the TKG cluster using HELM to the resource group. I had to specify a location because my current RG resides in UAE which Arc service does not reside in as of yet. Verify the connection after around 10 minutes using the command below:
- az connectedk8s connect –name TKGcluster –resource-group RG –location westeurope
- az connectedk8s list –resource-group RG–output table
7- View the created namespace, pods, and services by Azure Arc and verify all are in running state:
- kubectl get deployments,pods -n azure-arc
Verify
Now lets navigate to Azure Arc and verify the cluster has been added with all the data populated accordingly.
In order to get insights and logs, azure monitor must be configured which is a chargeable service.
A very important part of Policies is the ability to assign single compliance policies or initiatives which is very important for security regulation and other purposes.
GitOps integration allows for a fully automated CI/CD enablement of the TKG cluster directly from Azure Arc.
Extensions are going to be the most used part of this service as more extensions are added. This automation from Azure Arc allows for easier administration, installation, and management of extensions.
Security integration especially with Defender allows for increased protection and security visibility into the cluster. A Defender plan needs to be enabled for the same which is a chargeable service.
Conclusion
There you have it, vendor lock-in is a thing of the past, and VMware has embraced this approach going forward especially with the Tanzu portfolio. Tanzu Service Mesh and Tanzu Mission Control are going to offer much more features and functionality than Azure Arc but I wanted to demonstrate that fully-compliant and fully-conformant are not just terms but an actual thing.