Deploying VMware vSphere with Tanzu for Containerized Workloads
Deploying VMware vSphere with Tanzu for Containerized Workloads lets infrastructure teams run Kubernetes clusters on virtualisation infrastructure while retaining centralised policy, workload isolation and self-service provisioning. The usual pattern is a Tanzu Kubernetes Grid supervisor cluster in vCenter, with workload clusters hosting Linux containers from OCI images.
Success depends on preparing hosts, storage, DNS and identity before cluster automation begins. Teams should also decide early whether Tanzu Mission Control will manage multiple clusters or whether a vCenter-integrated deployment is sufficient.
Australian organisations must account for engineers working in hybrid teams from Sydney, Melbourne, Brisbane and Perth, applicable privacy and security obligations, and remote operations when staff work away from the corporate data centre.
Prepare the vSphere foundation
Confirm the supported vSphere, vCenter and ESXi combination, CPU virtualisation features, datastore capacity and current Broadcom entitlements for the required vSphere and Tanzu products. Product packaging changes regularly, so validate editions and lifecycle support with the organisation’s VMware partner rather than relying on an outdated lab checklist.
The foundation needs redundant management and compute capacity, plus accessible NTP and DNS services. Select either supported vSphere networking or NSX, and define a container storage policy covering capacity, performance, encryption and snapshots. CSI drivers then expose this storage through Kubernetes persistent volume claims.
Reserve capacity for upgrades and node loss instead of converting a busy lab directly into production. Separate supervisor and workload-cluster networks where possible, and confirm that applications hosted in Melbourne or Sydney still meet latency targets for users in Perth and Brisbane.
Configure the Tanzu management layer
Enable Tanzu Kubernetes Grid through the Tanzu features in vCenter, assign the appropriate licences and create the supervisor cluster using the supported Cluster API workflow. Define management networks, workload networks, address ranges and storage policies before placing nodes, since DHCP, DNS or NTP errors often appear later as repeated node-not-ready conditions.
Create a workload cluster with a ClusterClass and separate node pools for system and application workloads. Specify the container network, ingress class and default StorageClass, then apply resource requests and limits before admitting business services. Teams operating smaller labs can use Mike Patt’s lab material for preparation ideas, although production environments still require redundant DNS, supported time sources and tested storage.
Validate the deployment with kubectl get clusters -A, kubectl get nodes and kubectl get pods -A. Record the versions of vCenter, the supervisor, Kubernetes, CSI drivers and CNI plugins because upgrade compatibility depends on the entire platform chain.
Deploy and operate workload clusters
Deploy a small OCI-based service before adding Helm charts and ingress. Keep image names and tags immutable in source control, supply configuration through ConfigMaps and use an approved secrets mechanism. A staging namespace should validate readiness probes, disruption budgets, horizontal pod autoscaling and application metrics before production traffic arrives.
For repeatable delivery, store manifests and Helm values in Git and promote the same tested artefact through development, test and production clusters. Admission policies can enforce signed images, required labels, resource limits and restricted privileges. Avoid placing registry credentials or customer data in YAML because these files often persist in repositories and CI logs.
Operate the platform as a product by monitoring API-server latency, etcd health, node pressure, pod restarts and ingress errors. Alert on certificate expiry and failed etcd backups, then test vSphere HA, datastore access and upgrades during maintenance windows. Document how workload clusters and persistent volumes will be recovered following a supervisor failure.
Connect networking and security controls
Network design requires explicit ingress and egress paths. Kubernetes NetworkPolicy can restrict traffic between namespaces, while ingress controllers and external load balancers route application traffic. Where internet access is necessary, use controlled egress through proxies or firewalls rather than broad node-level access, and confirm that cloud and Australian-hosted services resolve correctly from the cluster.
Place Radware DefensePro or another application delivery controller where it can inspect external and east-west traffic without exposing the management plane to the internet. The practical radware geo-blocking guidance shows how reputation and geography rules can complement Kubernetes ingress controls. Test every change against legitimate Australian and regional traffic to avoid blocking customers.
Treat identity as part of the cluster by integrating the corporate identity provider and requiring phishing-resistant multifactor authentication for administrators. The Privacy Act 1988 and Australian Privacy Principles apply when workloads process personal information, while contractual and state-sector requirements may influence data residency. Map these obligations to evidence operators can produce and use the ASD Essential Eight as a practical security baseline.
Operational recommendations for production readiness
Choose a management model that matches the team’s skills, operating scale and failure domains. The available approaches differ mainly in lifecycle automation and administrative overhead.
| Approach | Management layer | Best fit | Main trade-off |
|---|---|---|---|
| vCenter-integrated TKG supervisor | Supervisor managed through vCenter | One site or a focused cluster | Fewer moving parts, but narrower fleet-wide visibility |
| TKG with Tanzu Mission Control | TMC manages inventory and policy | Multiple clusters or hybrid operations | Central governance with additional platform overhead |
| Self-managed Kubernetes on vSphere | Separate control plane operated by the platform team | Specialist environments | Maximum control, but manual upgrades and integration |
For Australian mid-market organisations, a vCenter-integrated supervisor is a practical starting point, with Tanzu Mission Control added when multiple clusters or delegated teams require consistent policy. Assign ownership separately for the virtualisation layer, Kubernetes platform and applications so incidents do not stall while teams debate whether a failed virtual machine or pod is the actual fault domain.
- Validate product entitlements, support dates and renewal ownership with an Australian VMware ecosystem partner.
- Keep cluster definitions, configuration and Helm values under version control, excluding secrets and personal data.
- Monitor etcd, API-server health, node pressure, certificate expiry, CSI capacity and ingress errors through the Australian on-call rota.
- Rehearse node loss, datastore isolation, supervisor failure, backup restoration, planned upgrades and remote access from a home office.
- Record data classification and residency for every workload, then map audit evidence to the Privacy Act 1988, Australian Privacy Principles and Essential Eight controls.