Configuring Liveness and Readiness Probes for non-Spring Workloads in Tanzu Application Platform (TAP)

Products

• VMware Tanzu Platform - Kubernetes

Issue/Introduction

In Tanzu Application Platform (TAP), pod-level configuration such as Kubernetes liveness and readiness probes is applied through Cartographer Conventions.

TAP provides an out-of-the-box convention only for Spring Boot applications. For non-Spring workloads (for example, .NET), probes are not configured automatically and must be added using custom conventions.

This behavior is expected and by design.

Details

Spring Boot workloads

TAP includes a built-in convention (spring-boot-convention) that:

• Detects Spring Boot workloads

• Mutates the generated pod specification

• Injects Kubernetes health probes automatically

As a result, Spring Boot applications receive liveness and readiness probes without additional configuration.

 

Non-Spring workloads (for example .NET)

TAP does not ship runtime-specific conventions for non-Spring frameworks. Therefore:

• No probes are injected by default

• This is expected platform behavior

• TAP remains runtime-agnostic by design

Pod-level customization for these workloads must be implemented by the platform operator.

Environment

Tanzu Application Platform 

Workloads deployed using Cartographer (Workload custom resource)

Non-Spring runtimes (for example .NET / ASP.NET Core)

Resolution

The supported mechanism to add probes for non-Spring workloads is to create custom Cartographer Conventions.

Broadcom provides official documentation describing this process:

• Creating custom conventions
  https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-application-platform/1-12/tap/cartographer-conventions-creating-conventions.html

Additionally, reference implementations of convention servers are available:

• Cartographer Conventions – Sample Convention Servers
  https://github.com/vmware-tanzu/cartographer-conventions/tree/main/samples

Using this approach, a platform team can:

• Match workloads using labels

• Mutate the generated pod specification

• Inject Kubernetes liveness and readiness probes (and other pod-level settings)

This is functionally equivalent to the built-in Spring Boot convention, applied to other runtimes.

Additional Information

Custom Cartographer conventions are additive and non-destructive by design. Introducing a new convention does not replace or disable the existing default conventions shipped with TAP. Each convention receives the current pod template and only mutates the specific fields it explicitly targets.

As a result:

• Existing conventions (including Spring Boot or other default conventions) continue to apply

• Environment variables and configuration injected by default conventions are preserved

• No existing behavior is changed unless a custom convention intentionally overwrites the same pod fields

In practice, adding a custom convention to inject liveness/readiness probes is safe, provided it only patches those probe fields and does not replace broader container or pod specifications.

This behavior is consistent with the Cartographer Conventions design and the examples provided in the official documentation.