Tanzu — VMware fleet management with the Tanzu Kubernetes Platform

Tanzu is VMware’s fleet management platform for Kubernetes. This lesson walks the Tanzu Kubernetes Platform (TKG) for cluster provisioning, Tanzu Mission Control (TMC) for fleet operations, the cluster kinds, policies, and the operational discipline.

The Tanzu architecture

flowchart LR
    A[Tanzu Mission Control] --> B["Cluster group: prod"]
    A --> C["Cluster group: staging"]
    A --> D["Cluster group: dev"]
    E[TKG management cluster] --> F[Workload cluster 1]
    E --> G[Workload cluster 2]
    E --> H[Workload cluster 3]
    I[Standalone cluster] --> A
    J["Policy: prod security"] --> F
    J --> G

The components:

• Tanzu Mission Control (TMC) — the SaaS-based fleet management plane. Manages clusters across clouds and on-prem.
• Tanzu Kubernetes Platform (TKG) — the cluster provisioning and lifecycle platform.
• Management cluster — the TKG control plane; runs in vSphere, AWS, Azure, or GCP.
• Workload cluster — the clusters that run application workloads; TKG provisions them from the management cluster.
• Standalone cluster — an imported cluster not provisioned by TKG.

The cluster kinds

flowchart TD
    A[Management cluster] --> B["Workload cluster: TKG"]
    A --> C["Workload cluster: TKG"]
    D["Standalone cluster: imported"] --> A
    E["Cluster group: prod"] --> B
    E --> D
    F["Cluster group: staging"] --> C

The cluster kinds:

• Management cluster — the TKG control plane. Provisions and manages workload clusters. One management cluster per cloud or vSphere instance.
• Workload cluster — production clusters managed by TKG. Can be class: production (HA, multi-node) or class: development (single-node).
• Standalone cluster — an existing Kubernetes cluster imported into TMC for fleet management. TKG does not manage its lifecycle.

Cluster groups and policies

flowchart LR
    A["Cluster group: prod"] --> B["Policy: image registry allowlist"]
    A --> C["Policy: network policy enforcement"]
    A --> D["Policy: Pod Security Standards"]
    B --> E[All clusters in group]
    C --> E
    D --> E

TMC uses cluster groups to apply policies across clusters. A cluster group is a logical grouping; policies attached to the group apply to all clusters in it.

Common policies:

• Image registry allowlist — restrict Pods to pulling from approved registries only.
• Network policy enforcement — require all workloads to have NetworkPolicies.
• Pod Security Standards — enforce restricted PSS across all workloads.
• Resource quotas — apply quotas across namespaces.

The Tanzu CLI

# Login to TMC
tanzu login --endpoint my-org.tmc.vmware.com

# Create a cluster group
tanzu cluster group create prod --description "Production clusters"

# Attach a cluster to a group
tanzu cluster attach --cluster prod-cluster-1 --group prod

# Apply a policy
tanzu policy create prod-security \
  --group prod \
  --template pss-restricted

The Tanzu CLI is the command-line tool for TMC. It mirrors the UI; both are usable for fleet operations.

The GitOps integration

TMC integrates with GitOps via the tanzu-package plugin and the kustomize-controller from Flux:

flowchart LR
    A[Git repository] --> B[TMC GitOps]
    B --> C[Workload cluster 1]
    B --> D[Workload cluster 2]
    B --> E[Workload cluster 3]

The GitOps flow:

1. A Git repository contains the application manifests.
2. TMC’s GitOps controller watches the repository.
3. TMC applies the manifests to the selected clusters.
4. The clusters reconcile to the desired state.

TMC’s GitOps is similar to Rancher Fleet and Argo CD. The choice between them is usually driven by existing platform commitment (VMware ecosystem vs Red Hat/Open Source ecosystem).

The operational failure modes

Tanzu fails in production for predictable reasons:

• TMC SaaS unavailable. TMC is SaaS; if VMware’s cloud has an outage, TMC is unavailable. Clusters continue to run; TMC cannot manage them centrally.
• TKG management cluster down. A management cluster failure prevents new workload clusters from being provisioned. Existing workload clusters continue to run.
• Policy translation failure. A Tanzu policy that does not translate correctly to a Kubernetes construct (e.g., a Kyverno policy with syntax errors) is silently rejected.
• Tanzu CLI version skew. A Tanzu CLI that does not match the TMC API version produces unexpected errors.
• vSphere / AWS dependency. TKG clusters depend on the underlying infrastructure. An infrastructure outage affects the workload clusters.

Quiz

Production discipline

Tanzu in production rests on five non-negotiable elements:

• HA TKG management cluster. The management cluster is the TKG control plane. A failure prevents new workload clusters from being provisioned.
• Test policies in staging. A Tanzu policy that is not enforced is worse than no policy — it gives a false sense of security.
• Monitor TMC connectivity. TMC is SaaS; disconnections prevent central management.
• Back up TKG state. The TKG management cluster state must be backed up. Losing it means re-provisioning.
• Document the cluster groups and policies. The Tanzu architecture must be documented with the cluster groups, policies, and underlying enforcement mechanisms.

Tanzu is a fleet management platform; its value is in the consistency it enforces across clusters. The discipline is to test the enforcement and to treat Tanzu as production infrastructure.