kubedoom       192.168.144.20:5900   (VNC — yes, it kills pods)
kubeinvaders   192.168.144.21
kube-ops-view  192.168.144.22
pacman         192.168.144.23        (+ MongoDB on a PVC — persistent high scores)
podinfo        192.168.144.24
goldpinger     192.168.144.25        (DaemonSet incl. control plane)
prometheus     (in-cluster: KSM + node-exporter, 11/11 targets up)

Captured from the VIPs the platform handed out. KubeDoom is VNC-only and podinfo is an API, so they sit this one out; the Ops topology tile shows all seven by name.

The path that matters: tenanted, not shortcut

The first version of this stack was deployed against the supervisor — an admin kubeconfig, a vSphere namespace, kubectl apply. It worked and it was wrong, for the reason the previous post spells out: nothing about it was provided to anyone. So it was torn down (seven apps, cluster, VPC and VIPs gone in about seven minutes) and rebuilt the proper way:

dev-01 org → default-project → SupervisorNamespace (class large, region f06, VPC default-f06)
          → VKS cluster vks-demo01 → seven apps

All created through VCF Automation — the CCI API for the namespace and cluster, then the apps via the cluster’s own kubeconfig. Two auth facts worth writing down, because they cost a cycle each:

• A provider service account reaches the cloud API only. CCI (/cci/kubernetes/apis/...) rejects provider tokens with 401 — it needs an org-scoped service account.
• Device-flow login uses the service account’s own UUID as client_id (not its software ID), against the tenant endpoint /oauth/tenant/<org>/device_authorization.

What the platform does for free

Each app is an ordinary Deployment + Service of type LoadBalancer. The supervisor turns each service into an NSX VPC LB virtual server and hands back a VIP from the org’s external block. No ingress controller, no MetalLB, no port-forwarding — seven services, seven VIPs, done. Pac-Man’s MongoDB asks for a PVC and gets a vSAN-backed volume through the CSI the supervisor already installed. Goldpinger runs as a DaemonSet across every node including the control plane and draws the node-to-node mesh live.

That’s three platform services (LB, storage, networking) exercised by apps that know nothing about VCF.

The traps

Supervisor refuses cluster-scoped RBAC — even to admin. Demo apps that need ClusterRoles (kube-ops-view, Goldpinger, KubeDoom) must live on a guest cluster. You cannot run them as vSphere Pods on the supervisor.

PodSecurity restricted is the VKS 1.35 default. Half the demo set runs as root. Symptom: Deployment shows 0 UP-TO-DATE, ReplicaSet exists, zero pods, events say FailedCreate. Fix: label the namespace pod-security.kubernetes.io/enforce=privileged — and mention in the demo that you did, because it’s a teaching moment.

node-exporter without hostNetwork. The VPC fabric blocks pod → node IP scrapes, so the stock DaemonSet’s hostNetwork: true doesn’t help; run it as a normal pod and let Prometheus scrape it in-cluster.

Docker Hub is flaky from behind a proxy. TLS handshake timeouts put pods into kubelet’s image-pull backoff. Deleting the stuck pods bypasses the backoff; a Harbor proxy-cache project fixes it properly.

Pod CIDR shadowing. The stock 192.168.0.0/16 pod range hid the org’s 192.168.144.0/21 external block from inside the cluster — apps couldn’t reach their neighbours’ VIPs. Pod CIDR is now 172.16.0.0/16.

Automation notes

The whole stack is a checkbox on the lab’s catalog item that deploys a supervisor: installDemoApps creates the cluster (newest compatible Kubernetes release, newest built-in ClusterClass, auto-detected), applies the seven apps, and reports their URLs in the deployment summary. Run integrated on a fresh environment: 16.7 minutes to CREATE_SUCCESSFUL. An immediate re-run: 3.3 minutes, all steps idempotent — which is the number I actually care about, because it means a broken demo is a re-run, not a rebuild.

Why this matters outside the lab

A demo stack sounds like a toy. It’s actually the fastest way to make a platform legible to people who don’t read YAML: a customer watches a request become a cluster, watches seven services get their own addresses, opens one and plays it. Everything underneath — self-service Kubernetes, load balancing, persistent storage, isolation — is being exercised in a way a non-technical stakeholder can see working. The same stack is what we put in front of a new team on day one, and the same idempotent deploy is what makes it safe to demonstrate live: if it breaks on stage, it re-runs in three minutes.

Rules learned

• Demo apps that need cluster-scoped RBAC must run on a guest cluster; the supervisor won’t grant it, even to admin.
• Build the stack through the tenanted path (org SA → CCI → namespace → cluster → apps). Same apps, but now they’re provided, quota’d and visible in Ops.
• VKS 1.35: restricted PodSecurity by default. Label the namespace and say why.
• LoadBalancer per app = NSX VIP per app. No ingress needed for a demo.
• Pick a pod CIDR that doesn’t overlap the VPC external block.
• Make the deploy idempotent; a demo that re-runs in 3 minutes is one you can afford to break on stage.

Previously: one VKS cluster, two ways. The Pac-Man instance here is the one from What’s a VPC?.

Lab environment; opinions my own.

So: two clusters, one supervisor, one ClusterClass, two paths.

Path A: kubectl, the way we’ve always done it

kubectl vsphere login --server <supervisor> --tanzu-kubernetes-cluster-namespace demo
kubectl apply -f cluster.yaml

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
  clusterNetwork: { pods, services, serviceDomain }   # set all three — see below
  topology:
    class: builtin-generic-v3.6.0
    classNamespace: vmware-system-vks-public          # the gotcha
    version: v1.35.5+vmware.1
    controlPlane: {replicas: 1}
    workers: { one node pool, 2 replicas }
    variables: [ vmClass, storageClass ]

Fifteen minutes later: a cluster. Requires a vSphere namespace that somebody (an admin) created, with a content library attached, a VM class assigned and quota set — all in the vSphere Client, by hand.

Path B: the same manifest, as a catalog request

In All Apps the cluster is a CCI.Supervisor.Resource inside a blueprint, sitting next to a CCI.Supervisor.Namespace:

resources:
  namespace:
    type: CCI.Supervisor.Namespace
    properties:
      generateName: ${input.name}-
      className: large                      # quota comes from the class
      regionName: f06
      vpcName: ${input.vpc}
      contentSources: [{name: f06-vks-lib01, type: ContentLibrary}]
  cluster:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest: <the SAME Cluster object as above>

Publish it, and a tenant user requests it from a tile:

Fifteen minutes later: a cluster. Byte-identical Cluster object.

What path B adds for free

That last row is the one operations teams care about:

The VCFA-deployed cluster appears in Ops’ object model — supervisor → namespace → cluster → nodes → the workloads running on it — and its demo apps show up by name in the topology tab. The kubectl-built cluster is also visible to Ops (it’s the same supervisor, after all), but it has no deployment, no owner, no request history and no quota lineage. It’s a thing that exists, not a thing that was provided.

The four gotchas, in order of how much time they cost

Both paths share the same four traps on VKS 1.35 / VCF 9.1:

1. A VCFA-created namespace has no content library. Zero VirtualMachineImages → no cluster possible. contentSources in the blueprint, or attach by hand.
2. ClusterClass lives in vmware-system-vks-public. It 404s from the workload namespace unless the spec sets topology.classNamespace.
3. The default Quick Start namespace is 1000M CPU / 1000Mi. Unusable for a cluster. Use a real class: small 10000M/10000Mi, medium 20000M, large 40000M.
4. VKS 1.35 enforces PodSecurity restricted by default. Demo apps that run as root get a ReplicaSet and no pods; the events say FailedCreate. Label the app namespace pod-security.kubernetes.io/enforce=privileged (or fix the apps).

Plus one that only shows up later: set clusterNetwork.serviceDomain explicitly. It’s immutable after create, and a cluster without it produces a service DNS name that some add-ons build wrongly (....svc. with no domain). And pick a pod CIDR that doesn’t shadow your VPC’s external range — the stock 192.168.0.0/16 hid the org’s 192.168.144.0/21 from inside the cluster.

So which one?

Use kubectl when you’re the platform team proving something on a supervisor, or debugging. Use All Apps the moment a second person needs a cluster: the request form is the interface, the namespace class is the guardrail, the deployment is the audit trail, and Ops sees it as a provided service rather than a stray object.

The cluster’s the same either way. The service isn’t.

Why this matters outside the lab

The business case for the second path is governance without friction. Development teams get Kubernetes clusters on request; the platform team gets quotas, ownership, RBAC and a monitoring view of every cluster for free. That’s the difference between a managed Kubernetes service and a collection of clusters nobody can account for — and it’s typically the gap that stops organisations offering Kubernetes broadly at all. Everything the developers touch stays standard Kubernetes; the control lands around it, not on it.

Rules learned

• The Cluster object is identical across paths — All Apps wraps it, it doesn’t change it.
• What All Apps adds: catalog RBAC, class-based quota, library attach, VPC pinning, deployment history, and a place in the Ops object model.
• Four traps on 1.35: no default library, classNamespace, tiny default quota, PodSecurity restricted.
• Set serviceDomain and a non-shadowing pod CIDR at create; both are immutable.

Next in All Apps in Practice: the demo apps that live on this cluster.

Lab environment; opinions my own.