Customers are demanding multi-cloud solutions to solve problems such as resource constraints, application mobility, and flexible architectures. VMware is positioning new products to meet this demand and provide a unified experience across infrastructures. In this latest look at the hybridized data center, VMware meets the customer where they are to demonstrate the efficacy of VMware Tanzu Kubernetes Grid in a public cloud deployment.
Many Tanzu Kubernetes Grid customers are looking to the clouds to extend their on-premises data centers for their growing scalability needs. Cloud-based service organizations often include their own packaging of Kubernetes, but it may lack the features that Tanzu Kubernetes Grid customers depend on, such as on-premises provisioning, hybrid/multi-cloud support, and supported by Spring Runtime. Additionally, the packaging of Kubernetes can require education and mastery in another platform that businesses do not have the time or money to support. Using a prominent public Kubernetes sub-project called Cluster API, Tanzu can overlay itself on major public cloud platforms such as Azure and Amazon Web Services. This extends the business's investment in support and lifecycle management as they venture into the hyper-scaling data center. Notably, Tanzu Kubernetes Grid must adhere to the customer's stronger data center requirements for network and security communications. This article highlights the architecture used for recent Tanzu Kubernetes Grid implementations on Azure IaaS utilizing cloud native services while maintaining tight integration with the on-premises data center.
The solution is a mixture of both Azure native services such as virtual machines, load balancers, and virtual networks, combined with VMware and open source components like Tanzu Kubernetes Grid with Pinniped, and even Tanzu Mission Control integration.
Enterprise customers often encounter data center or security requirements which a default installation of Tanzu Kubernetes Grid in the public cloud cannot anticipate. The following list details these items:
- Communication with the cluster must use internal (RFC 1918) IP addresses only.
- Access from the internet must be explicitly restricted.
- Access to the internet should use a managed, on-premises proxy (no authentication).
- Consumers of the solution may exist on-premises or in the cloud.
The bootstrap initiator was chosen as the primary solution for Tanzu Kubernetes Grid deployment, putting it directly into the cloud network for simplicity and flexibility. This solution provides the deployment team self-service capabilities of the cloud, while also keeping them within the platform design considerations of central IT. Further, deployment automation was developed which simplifies the execution of this architecture for validation and/or integration within a customer's own deployment toolset and processes.
Bootstrap in-cloud; network cross-cloud
The solution shows a virtual machine at the center of the deployment activity, sitting within an Admin environment where it orchestrates the Tanzu cluster creations. Though the machine is critical to kick off operations, it is built with a very economical SKU (Standard_B2ms), which Microsoft defines as: B-series virtual machines are "burstable," meaning that credits are banked during non-use to allow bursting to maximum CPU performance. As such, they are some of the most economical solutions one can pick, especially effective for administrative machines such as the Tanzu Kubernetes Grid bootstrap workload.
With the bootstrap machine being located within Azure, it is convenient for a resource team to manage the relationship and capabilities of this object within the greater Azure/Tanzu environment. This allows for the design to use private IP address ranges. Between the Tanzu command-line interface, Cluster API Provider for Azure (CAPZ), and infrastructure deployment automation, the solution depicted above deploys robust security controls that integrate with existing network and security platform requirements easily. The bootstrap in-cloud solution is designed to configure the environment and deploy Tanzu clusters to their respective configured network segments within your cloud environment. VMware recognizes that their customers enjoy the flexibility of building smaller clusters to manage distinct workload units for better scalability and fault-domain planning. Tanzu Kubernetes Grid in Azure can make use of your existing network environment and will scale appropriately to put workloads into the correctly sized subnets to make the most of the space provided!
New to Tanzu Kubernetes Grid 1.5, private cluster support configures Azure to allow private IP load balancers while restricting unauthorized outbound access (e.g., internet access). Instead, Tanzu Kubernetes Grid leverages existing enterprise network access controls such as those seen in designs comprising ExpressRoute or virtual private network routing.
While egress controls can be redirected to the most optimum perimeter devices of an enterprise's choosing, data center access must still be allowed between physical data centers and cloud data centers. A hybrid-cloud Tanzu Kubernetes Grid implementation can take advantage of your company's routing and security rules in the cloud, but also evident in this architecture are the pieces necessary to integrate DNS systems. Tying privatized DNS solutions together can be challenging, but with this verifiable design, this is made simple, and most importantly, remains dynamic.
Tanzu Kubernetes Grid: Part of a solution
It’s worth noting that Tanzu Kubernetes Grid in Azure is one piece of the puzzle that VMware Tanzu for Kubernetes Operations solves. Multi-cloud Kubernetes management, enterprise observability, and end-to-end security are all features that come together under one solution, regardless of the cloud or data center. This proposed architecture, recently exercised with key customers, allows for the entire solution to operate as drawn for the entirety of Tanzu Kubernetes Operations.
It is hard not to oversimplify hybrid-cloud architectures—they certainly have their intricacies and all environments are not the same. However, we believe that the approach outlined in the diagram above provides the best possible success to navigating enterprise requirements while enabling the features that empower businesses.
About the AuthorMore Content by Olaf Gradin