Overview

This document describes how to configure metrics collection and forwarding for a VKS guest cluster into VCF Operations, using Prometheus as the in-cluster metrics collector and Telegraf as the delivery agent.

The VCF Operations monitoring integration for VKS uses a push-based model. This is a deliberate architectural departure from the legacy Kubernetes Management Pack, which used a pull-based model where VCF Operations scraped Prometheus endpoints directly. The push model is better suited to the VKS network topology: guest clusters run on workload or tenant networks that are frequently NATed or firewalled from the VCF management plane. Rather than requiring inbound connectivity from VCF Operations into the cluster, Telegraf inside the cluster establishes an outbound connection through the Supervisor Management Proxy — a platform service that provides a secure, authenticated bridge between the workload network and VCF Operations.

The monitoring stack has five components:

All five are installed from the VKS Standard Packages bundle using the VCF CLI package manager.

Prerequisite: The Supervisor Management Proxy requires the Supervisor control plane to be sized at Medium or larger. On a Small profile, the proxy deployment will fail due to insufficient CPU and memory on the control plane nodes.

Reference Environment

The procedures and configurations in this document were validated against the following platform versions:

Architecture

┌────────────────────────────────────────────────────────────────────────┐
│  vSphere Supervisor                                                    │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │  svc-supervisor-management-proxy-domain-c10                      │  │
│  │                                                                  │  │
│  │  supervisor-management-proxy (Deployment)                        │  │
│  │    proxy-loadbalancer            192.168.230.14  10091/10092     │  │
│  │    vksm-loadbalancer             192.168.230.15  10094           │  │
│  │    workload-metrics-loadbalancer 192.168.230.16  10093           │  │
│  └──────────────────────────────────────────────────────────────────┘  │
│             ▲                          │                               │
└─────────────┼──────────────────────────┼───────────────────────────────┘
              │  outbound HTTPS          │  metrics forwarded
              │                          ▼
┌─────────────────────────────┐   ┌──────────────────────────────────────┐
│ VKS Cluster: dev-cluster-04 │   │  VCF Operations                      │
│                             │   │  discovered VKS inventory object     │
│  vks-system-monitoring      │   │  dashboards, alerts, capacity        │
│    prometheus-server        │   └──────────────────────────────────────┘
│    kube-state-metrics       │
│    prometheus-node-exporter │
│    alertmanager             │
│    prometheus-pushgateway   │
│          │                  │
│          │  scrape          │
│          ▼                  │
│  vks-system-telegraf        │
│    telegraf (DaemonSet)  ───┼──► outbound → Supervisor Mgmt Proxy
│    telegraf (Deployment) ───┼──► outbound → Supervisor Mgmt Proxy
│                             │
│  vks-cert-manager           │
│    cert-manager             │
│                             │
│  vks-system-ingress         │
│    contour + envoy (LB)     │
└─────────────────────────────┘

Metric flow:

Prometheus (in-cluster scrape)
   └─ prometheus-server        scrapes pods, nodes, API server
   └─ kube-state-metrics       exposes API object metrics (Deployments, Pods)
   └─ prometheus-node-exporter exposes OS/hardware metrics per node

Telegraf
   └─ reads Prometheus metrics endpoint
   └─ sends to Supervisor Management Proxy (10093)
      └─ forwarded to VCF Operations metric ingestion endpoint

Prerequisites

• VCF CLI installed with the package plugin
• Active VCF CLI context for the target VKS guest cluster
• VKS Standard Packages bundle accessible from the cluster
• Supervisor control plane sized at Medium or larger
• VCF Operations instance configured with the vSphere Supervisor adapter
• VCFA (VCF Automation) endpoint accessible from the Supervisor for VKSM registration: vcfa01.vcf.nicolescu.org:443
• NSX Manager reachable from the Supervisor: 192.168.200.30

Set the following environment variables before running any commands:

export CLUSTER_NAMESPACE='lab-poc-namespace-dev'
export CLUSTER_NAME='dev-cluster-04'
export SUPERVISOR_IP='10.77.68.3'
export VCF_CLI_VSPHERE_USERNAME='administrator@vsphere.local'
export VCF_CLI_VSPHERE_PASSWORD='<password>'

Step 1 — Connect to the VKS Cluster

vcf context delete ${CLUSTER_NAME} -y

vcf context create ${CLUSTER_NAME} \
  --endpoint ${SUPERVISOR_IP} \
  --username ${VCF_CLI_VSPHERE_USERNAME} \
  --workload-cluster-namespace ${CLUSTER_NAMESPACE} \
  --workload-cluster-name ${CLUSTER_NAME} \
  --insecure-skip-tls-verify

vcf context list
vcf context use ${CLUSTER_NAME}:${CLUSTER_NAME}

Step 2 — Deploy the Supervisor Management Proxy

The Supervisor Management Proxy is a vSphere Supervisor Service — it is not a Kubernetes package installed via the VCF CLI. It is registered and managed through the vCenter Server UI and runs on the Supervisor control plane, not inside the VKS guest cluster.

Its purpose is to act as a network bridge: VKS clusters on workload networks establish outbound connections to the proxy, and the proxy forwards the metric stream to VCF Operations. This design means VKS clusters never need direct inbound or outbound access to the VCF Operations management endpoint.

Important: The Supervisor Management Proxy must be deployed and verified before Telegraf is installed. If isMetricProxyConfigured: true is set in the Telegraf data values but the proxy is not yet running, Telegraf will fail to establish its output connection.

2.1 Upload the Service Definition

In vCenter Server, navigate to:

Supervisor Management → Services → Add

Upload the supervisor-management-proxy.yml service definition file. After upload, the service record shows:

2.2 Configure and Enable the Service

In the Supervisor Management Proxy service card, select Actions → Manage Service. Set the install version to 0.4.0 and upload the service data values file.

Prepare the data values file:

cat << EOF > supervisor-management-proxy-data-values.yaml
nsxManagers:
  - "192.168.200.30"
vksmHTTPRemoteEndpoint:
  host: vcfa01.vcf.nicolescu.org
  port: 443
vksmAPIPort: 10094
EOF

2.3 Verify the Supervisor Management Proxy

Switch to the Supervisor context and inspect the proxy namespace:

vcf context use supervisor

kubectl get all -n svc-supervisor-management-proxy-domain-c10

Expected output:

NAME                                               READY   STATUS    RESTARTS   AGE
pod/supervisor-management-proxy-58fd6cd886-q2j8f   1/1     Running   0          26s

NAME                                    TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)
service/proxy-loadbalancer              LoadBalancer   10.96.1.116   192.168.230.14   10091:32355/TCP,10092:30857/TCP
service/vksm-loadbalancer               LoadBalancer   10.96.1.188   192.168.230.15   10094:32543/TCP
service/workload-metrics-loadbalancer   LoadBalancer   10.96.1.176   192.168.230.16   10093:31836/TCP

NAME                                          READY   UP-TO-DATE   AVAILABLE
deployment.apps/supervisor-management-proxy   1/1     1            1

Three LoadBalancer services are created automatically:

Once all three services have external IPs assigned, the proxy is ready. Switch back to the VKS cluster context to continue:

vcf context use ${CLUSTER_NAME}:${CLUSTER_NAME}

Step 3 — Add the VKS Standard Packages Repository

Install the VCF CLI package plugin if not already present, then add the VKS Standard Packages repository to the tkg-system namespace on the cluster:

vcf plugin install package

vcf package repository add standard-repo \
  --url projects.packages.broadcom.com/vsphere/supervisor/vks-standard-packages/3.6.0-20260416/vks-standard-packages:3.6.0-20260416 \
  -n tkg-system

Verify the repository reconciles successfully:

vcf package repository list -n tkg-system

Expected output:

  NAME           SOURCE                                                                                                                       STATUS
  standard-repo  (imgpkg)                                                                                                                     Reconcile succeeded
                 projects.packages.broadcom.com/vsphere/supervisor/vks-standard-packages/3.6.0-20260416/vks-standard-packages:3.6.0-20260416

Step 4 — Install cert-manager

cert-manager is a prerequisite for Prometheus. The Prometheus package provisions TLS certificates for its admission webhook and internal component communication using cert-manager Certificate and Issuer resources. Without cert-manager running, the Prometheus installation fails when its CRD-based resources cannot be reconciled.

List available versions:

vcf package available get cert-manager.kubernetes.vmware.com -n tkg-system

Expected output:

  VERSION                RELEASED-AT
  1.18.2+vmware.2-vks.2  2025-10-22 08:00:00 -0400 EDT
  1.18.3+vmware.1-vks.1  2025-12-18 07:00:00 -0500 EST
  1.19.1+vmware.1-vks.1  2025-12-18 07:00:00 -0500 EST
  1.19.2+vmware.1-vks.1  2026-02-11 07:00:00 -0500 EST
  1.19.4+vmware.1-vks.1  2026-04-16 08:00:00 -0400 EDT

cert-manager requires no data values customisation for this use case. Install it directly:

kubectl create ns vks-cert-manager

vcf package install cert-manager \
  -p cert-manager.kubernetes.vmware.com \
  --version 1.19.4+vmware.1-vks.1 \
  --namespace vks-cert-manager \
  --verbose 9

Verify the installation:

kubectl get packageinstall -n vks-cert-manager
kubectl get all -n vks-cert-manager

Expected packageinstall status: Reconcile succeeded.

Step 5 — Install Contour

Contour is the ingress controller required by the Prometheus package. Prometheus deploys an Ingress resource targeting the contour IngressClass to expose the Prometheus server web UI. Without a running Contour instance, the Ingress object is created but never resolved, and the Prometheus package health check reports degraded status.

List available versions:

vcf package available get contour.kubernetes.vmware.com -n tkg-system

Expected output:

  VERSION                RELEASED-AT
  1.32.0+vmware.1-vks.1  2025-08-18 20:00:00 -0400 EDT
  1.33.0+vmware.1-vks.1  2025-10-21 20:00:00 -0400 EDT
  1.33.0+vmware.2-vks.1  2025-12-17 19:00:00 -0500 EST
  1.33.1+vmware.1-vks.1  2026-02-10 19:00:00 -0500 EST
  1.33.2+vmware.1-vks.1  2026-04-15 20:00:00 -0400 EDT

Prepare the data values file:

cat << 'EOF' > ${CLUSTER_NAME}-contour-data-values.yaml
contour:
  configFileContents: {}
  useProxyProtocol: false
  replicas: 2
  pspNames: ""
  logLevel: info
  listenIPFamily: IPv4
envoy:
  workload:
    type: Deployment
    replicas: 2
  service:
    type: LoadBalancer
    externalTrafficPolicy: Cluster
    disableWait: false
  hostPorts:
    enable: false
    http: 80
    https: 443
  hostNetwork: false
  terminationGracePeriodSeconds: 300
  logLevel: info
  pspNames: ""
  listenIPFamily: IPv4
certificates:
  duration: 8760h
  renewBefore: 360h
enableSupervisorServiceRbac: true
namespace: vks-system-ingress
EOF

Key settings:

Install Contour:

kubectl create ns vks-system-ingress

vcf package install contour \
  -p contour.kubernetes.vmware.com \
  --version 1.33.2+vmware.1-vks.1 \
  --values-file ${CLUSTER_NAME}-contour-data-values.yaml \
  -n vks-system-ingress \
  --verbose 9

Verify the installation and confirm that Envoy received an external IP:

kubectl get packageinstall -n vks-system-ingress
kubectl get svc -n vks-system-ingress

Expected service output:

NAME      TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)
contour   ClusterIP      10.96.10.19      <none>        8001/TCP
envoy     LoadBalancer   10.102.106.139   10.77.68.5    80:30701/TCP,443:31224/TCP

The envoy service must have an external IP before proceeding. This IP is the ingress entry point for all HTTP/HTTPS traffic into the cluster.

Step 6 — Install Prometheus

The Prometheus package deploys the full Prometheus monitoring stack:

6.1 Inspect Available Versions

vcf package available list prometheus.kubernetes.vmware.com -n tkg-system

Expected output:

  NAME                              VERSION               RELEASED-AT
  prometheus.kubernetes.vmware.com  3.5.0+vmware.1-vks.2  2025-10-22 14:00:00 -0400 EDT
  prometheus.kubernetes.vmware.com  3.5.0+vmware.2-vks.1  2025-12-18 13:00:00 -0500 EST
  prometheus.kubernetes.vmware.com  3.5.0+vmware.3-vks.1  2026-02-11 13:00:00 -0500 EST
  prometheus.kubernetes.vmware.com  3.5.1+vmware.1-vks.1  2026-04-16 14:00:00 -0400 EDT

6.2 Extract and Customise Data Values

Extract the default values file for the target version:

vcf package available get prometheus.kubernetes.vmware.com/3.5.0+vmware.3-vks.1 \
  --default-values-file-output ${CLUSTER_NAME}-prometheus-data-values.yaml \
  -n tkg-system

Three modifications are required before installation:

# Remove leading comment markers from lines that must be active
sed -i 's/^..//' ${CLUSTER_NAME}-prometheus-data-values.yaml

# Set the storage class for the prometheus-server PersistentVolumeClaim
# The default is an empty string, which fails on VKS — there is no default StorageClass
sed -i 's/storageClassName: ""/storageClassName: vks-storage-policy/' \
  ${CLUSTER_NAME}-prometheus-data-values.yaml

# Set the deployment namespace
sed -i 's/^# namespace: tanzu-system-monitoring/namespace: vks-system-monitoring/' \
  ${CLUSTER_NAME}-prometheus-data-values.yaml
sed -i 's/namespace: tanzu-system-monitoring/namespace: vks-system-monitoring/' \
  ${CLUSTER_NAME}-prometheus-data-values.yaml

Storage class note: The prometheus-server pod uses a PersistentVolumeClaim for its time-series database (TSDB). If storageClassName is left empty, Kubernetes looks for a default StorageClass. VKS clusters do not define a default; the claim remains Pending and the server pod never starts. vks-storage-policy must be set explicitly.

6.3 Deploy Prometheus

kubectl create ns vks-system-monitoring

vcf package install prometheus \
  -p prometheus.kubernetes.vmware.com \
  --version 3.5.0+vmware.3-vks.1 \
  --values-file ${CLUSTER_NAME}-prometheus-data-values.yaml \
  -n vks-system-monitoring \
  --verbose 9

6.4 Verify the Prometheus Installation

kubectl get packageinstall -n vks-system-monitoring
kubectl get apps -n vks-system-monitoring
kubectl get all -n vks-system-monitoring

Expected kubectl get all output on a six-node cluster:

NAME                                                 READY   STATUS    RESTARTS   AGE
pod/alertmanager-57c5944846-fvbbx                    2/2     Running   0          15m
pod/prometheus-kube-state-metrics-6bfb4f6588-nm4pp   1/1     Running   0          15m
pod/prometheus-node-exporter-27fvw                   1/1     Running   0          15m
pod/prometheus-node-exporter-4p2l6                   1/1     Running   0          15m
pod/prometheus-node-exporter-9kj5v                   1/1     Running   0          15m
pod/prometheus-node-exporter-c9b9g                   1/1     Running   0          15m
pod/prometheus-node-exporter-p6cvb                   1/1     Running   0          15m
pod/prometheus-node-exporter-r9xdn                   1/1     Running   0          15m
pod/prometheus-pushgateway-76f98dbd69-2wmx8          1/1     Running   0          15m
pod/prometheus-server-8bb6647b5-dtzh4                2/2     Running   0          7m43s

NAME                                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)
service/alertmanager                    ClusterIP   10.111.126.36    <none>        80/TCP
service/prometheus-kube-state-metrics   ClusterIP   None             <none>        80/TCP,81/TCP
service/prometheus-node-exporter        ClusterIP   10.104.2.250     <none>        9100/TCP
service/prometheus-server               ClusterIP   10.111.139.126   <none>        80/TCP

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
daemonset.apps/prometheus-node-exporter   6         6         6       6            6

Key indicators of a healthy deployment: - prometheus-server shows 2/2 — the server container and the configmap-reload sidecar are both running - prometheus-node-exporter DaemonSet: DESIRED equals READY, one pod per node - prometheus-server pod may take 5–10 minutes to reach Running while the TSDB initialises on the persistent volume

Step 7 — Install Telegraf

Telegraf is the metric delivery agent. It reads the Prometheus metrics endpoints inside the cluster and forwards them to VCF Operations via the Supervisor Management Proxy.

The Telegraf package deploys two distinct workloads:

The Deployment pod handles the outbound proxy connection. Without it, no metrics reach VCF Operations even if the DaemonSet pods are healthy.

7.1 Inspect Available Versions

vcf package available list telegraf.kubernetes.vmware.com -n tkg-system

Expected output:

  NAME                            VERSION                RELEASED-AT
  telegraf.kubernetes.vmware.com  1.35.4+vmware.1-vks.1  2025-10-22 06:00:00 -0400 EDT
  telegraf.kubernetes.vmware.com  1.35.4+vmware.2-vks.1  2025-12-18 05:00:00 -0500 EST
  telegraf.kubernetes.vmware.com  1.36.4+vmware.1-vks.1  2025-12-18 05:00:00 -0500 EST
  telegraf.kubernetes.vmware.com  1.37.1+vmware.1-vks.1  2026-02-11 05:00:00 -0500 EST
  telegraf.kubernetes.vmware.com  1.37.3+vmware.1-vks.1  2026-04-16 06:00:00 -0400 EDT

7.2 Extract and Customise Data Values

Extract the default values file:

vcf package available get telegraf.kubernetes.vmware.com/1.37.3+vmware.1-vks.1 \
  --default-values-file-output ${CLUSTER_NAME}-telegraf-data-values.yaml \
  -n tkg-system

Apply three modifications:

# Uncomment the cluster DNS domain
sed -i 's/^# domainName: cluster\.local/domainName: cluster.local/' \
  ${CLUSTER_NAME}-telegraf-data-values.yaml

# Set the deployment namespace
sed -i 's/^# namespace: tanzu-system-telegraf/namespace: vks-system-telegraf/' \
  ${CLUSTER_NAME}-telegraf-data-values.yaml

# Enable the Supervisor Management Proxy for metric forwarding
cat << EOF >> ${CLUSTER_NAME}-telegraf-data-values.yaml
isMetricProxyConfigured: true
EOF

The isMetricProxyConfigured: true flag is the critical setting that enables VCF Operations integration. When set to true, Telegraf routes its metric output through the workload-metrics-loadbalancer service on the Supervisor Management Proxy (port 10093) rather than attempting a direct connection to the VCF Operations endpoint. Without this flag, Telegraf attempts a direct connection that will fail on any cluster that is not on the same network segment as VCF Operations.

7.3 Deploy Telegraf

kubectl create ns vks-system-telegraf

vcf package install telegraf \
  -p telegraf.kubernetes.vmware.com \
  --version 1.37.3+vmware.1-vks.1 \
  --values-file ${CLUSTER_NAME}-telegraf-data-values.yaml \
  -n vks-system-telegraf \
  --verbose 9

7.4 Verify the Telegraf Installation

kubectl get packageinstall -n vks-system-telegraf
kubectl get apps -n vks-system-telegraf
kubectl get all -n vks-system-telegraf

Expected kubectl get all output on a six-node cluster:

NAME                            READY   STATUS    RESTARTS   AGE
pod/telegraf-494m2              1/1     Running   0          3m22s
pod/telegraf-6d69447b6c-8txs7   1/1     Running   0          3m22s
pod/telegraf-8v4kc              1/1     Running   0          3m22s
pod/telegraf-hxv4p              1/1     Running   0          3m22s
pod/telegraf-skp6m              1/1     Running   0          3m22s
pod/telegraf-wnk7j              1/1     Running   0          3m22s
pod/telegraf-xjcss              1/1     Running   0          3m22s

NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
daemonset.apps/telegraf   6         6         6       6            6

NAME                       READY   UP-TO-DATE   AVAILABLE
deployment.apps/telegraf   1/1     1            1

Seven pods total: six DaemonSet pods (one per node) plus one Deployment pod. The Deployment pod (telegraf-6d69447b6c-*) is identified by its ReplicaSet name — it is the proxy connection manager. All six DaemonSet pods plus the Deployment pod must be in Running state.

Inspect the Telegraf logs to confirm successful metric proxy connectivity:

# Deployment pod logs (proxy connection and cluster-level metrics)
kubectl -n vks-system-telegraf logs \
  -l app.kubernetes.io/name=telegraf-dep \
  --all-containers=true \
  --tail=200

# DaemonSet pod logs (per-node metrics)
kubectl -n vks-system-telegraf logs \
  -l app.kubernetes.io/name=telegraf-ds \
  --all-containers=true \
  --tail=200

Look for output confirming that the metric proxy connection is established and metrics are being written successfully. Error messages referencing connection refused or no route to host indicate the Supervisor Management Proxy is unreachable from the cluster nodes.

Step 8 — Enable Pod and Container Monitoring in VCF Operations

Once Prometheus and Telegraf are installed and running, VCF Operations automatically begins receiving cluster-level, node-level, and namespace-level metrics. The VKS cluster object appears in the VCF Operations inventory under the vSphere Supervisor adapter within the first metric collection cycle, typically 1–5 minutes after Telegraf establishes its proxy connection.

However, pod and container monitoring is disabled by default and must be explicitly enabled per cluster. This is a deliberate design choice — enabling pod and container metric collection across all clusters simultaneously increases the volume of ingested time-series data significantly. Administrators opt in cluster by cluster based on their observability requirements and capacity planning considerations.

8.1 Locate the VKS Cluster in VCF Operations Inventory

Navigate to the vSphere Supervisor inventory in VCF Operations:

VCF Operations → Inventory → All Objects → vSphere Supervisor → lab-supervisor → Environment

In the Environment tab, use the search field to locate the VKS cluster object. Search by cluster name (e.g., dev-cluster-04) to filter the object list. The result shows the cluster with:

• Adapter: vSphere Supervisor
• Object Type: VKS Cluster

8.2 Enable Pod and Container Monitoring

Select the cluster object and click the edit icon to open the Edit Object dialog. Under Advanced Settings, configure the following two settings:

Click OK to apply. The configuration change takes effect within the next collection cycle.

After enabling, pod- and container-level metrics begin populating in VCF Operations dashboards. Initial data population typically takes 3–5 minutes as Telegraf delivers the first pod-level metric batch through the Supervisor Management Proxy pipeline.

Step 9 — Validate in VCF Operations

With the monitoring stack operational and pod and container monitoring enabled, use the Kubernetes VKS Cluster dashboard in VCF Operations to verify that metrics are flowing correctly and to explore cluster health at every level of the resource hierarchy.

9.1 VKS Cluster Dashboard

Navigate to the Kubernetes VKS Cluster dashboard:

VCF Operations → Infrastructure Operations → Dashboard and Reports → All → vSphere Supervisor → Kubernetes VKS Cluster

The dashboard provides a consolidated view of cluster health and resource utilisation across all monitored VKS clusters. The following objects and metrics should be present once the monitoring stack is fully operational:

9.2 Cluster Topology View

To examine the resource hierarchy of a specific VKS cluster, navigate to the topology view:

VCF Operations → Inventory → All Objects → VKS Cluster → dev-cluster-04 → Topology → dev-cluster-04

The topology view renders the cluster’s resource relationships as a connected graph. The Supervisor, VKS cluster, nodes, namespaces, deployments, pods, and containers appear as linked objects, allowing you to trace a metric anomaly from a container back to its owning namespace and deployment. This view is particularly useful for identifying resource-intensive workloads at a glance and for validating that the full inventory hierarchy has been discovered correctly.

Note: VCF Operations correlates the Telegraf metric stream with the VKS inventory object discovered through the vSphere Supervisor adapter. If the cluster does not appear in inventory, verify that the Supervisor adapter is configured in VCF Operations and that the Supervisor has been added as a monitored data source. Metrics are not associated with the cluster object until inventory discovery has completed.

Updating Packages

To update the configuration of any installed package, edit the data values file and apply the update:

# Update Telegraf (e.g., to change isMetricProxyConfigured or domainName)
vcf package installed update telegraf \
  -n vks-system-telegraf \
  --values-file ${CLUSTER_NAME}-telegraf-data-values.yaml

# Update Prometheus (e.g., to change storageClass or retention settings)
vcf package installed update prometheus \
  -n vks-system-monitoring \
  --values-file ${CLUSTER_NAME}-prometheus-data-values.yaml

kapp-controller reconciles the change and performs a rolling update of the affected workloads.

Removing Packages

Remove packages in reverse dependency order: Telegraf first, then Prometheus, then Contour, then cert-manager.

vcf package installed delete telegraf   -n vks-system-telegraf
vcf package installed delete prometheus -n vks-system-monitoring -y
vcf package installed delete contour    -n vks-system-ingress
vcf package installed delete cert-manager -n vks-cert-manager

If a deletion stalls due to kapp-controller finalizers not clearing automatically, remove them manually:

# Example for Telegraf — repeat the pattern for other packages
kubectl patch packageinstall telegraf -n vks-system-telegraf \
  --type=merge --patch '{"metadata":{"finalizers":[]}}'

kubectl patch app telegraf -n vks-system-telegraf \
  --type=merge --patch '{"metadata":{"finalizers":[]}}'

Verify all resources are removed:

kubectl get packageinstall -A
kubectl get app -A
kubectl get all -n vks-system-telegraf
kubectl get all -n vks-system-monitoring

Troubleshooting

Reference