Runtime Zero
ESC
Browse by topic
Articles  /  Tanzu

Tanzu Platform for Kubernetes: A Deep Dive

Tanzu Platform reframes how platform teams deliver developer experiences on Kubernetes. This post dissects its architecture, profiles, and spaces — and where it fits compared to rolling your own.

DC

VMware's Tanzu portfolio has gone through several naming iterations, but the current Tanzu Platform for Kubernetes (TP4K) represents the clearest product thinking yet. It's less a collection of tools and more an opinionated platform-as-a-product built on top of standard Kubernetes primitives. Let's dig into the architecture.

The Core Abstraction: Spaces

A Space is the unit of deployment for application teams. Think of it as a namespace with opinions baked in — networking policies, resource quotas, service bindings, and egress rules all come pre-configured based on a Profile.

apiVersion: spaces.tanzu.vmware.com/v1alpha1
kind: Space
metadata:
  name: team-payments-dev
spec:
  profileRef:
    name: standard-dev
  availabilityTargets:
    - name: on-prem-cluster-west
      replicas: 1

The platform team defines Profiles; application teams consume Spaces. This is exactly the contract that platform engineering advocates argue for — clear API boundaries between infra and dev.

Profiles: The Platform Team's Lever

Profiles are composable Carvel packages that define what capabilities are available in a Space. A typical profile bundles:

  • Ingress: Contour with TLS via cert-manager
  • Observability: OpenTelemetry collector sidecar injection
  • Service Mesh: Optional Istio integration
  • Build: Buildpacks-based image construction via kpack

Because profiles are just Kubernetes objects, you can version them in git, review changes through PRs, and promote them across environments with standard GitOps tooling.

Where It Beats Rolling Your Own

The honest answer is: abstractions at scale. For teams with fewer than five engineers managing fewer than ten clusters, Tanzu Platform's overhead is probably not worth it. You'd spend as much time learning the TP4K model as you would just writing Helm charts.

But at twenty-plus clusters with multiple application teams? The Space/Profile abstraction eliminates a whole class of Slack messages along the lines of "how do I configure TLS for my ingress?" — because the answer is built into the Space.

Integration with vSphere

TP4K integrates natively with vSphere-provisioned Kubernetes clusters (via Supervisor clusters or standalone TKG). Clusters provisioned through vSphere appear automatically as Availability Targets, and the platform can spread Spaces across them for resilience without developers needing to understand the underlying topology.

If you're already invested in vSphere and want to offer a polished developer experience without building a bespoke internal developer portal, Tanzu Platform deserves a serious evaluation.