Custom serviceDomain in TCA 3.4 is not propagated to CaaS clusters during bootstrap

Products

• VMware Telco Cloud Automation
• VMware Telco Cloud Platform

Issue/Introduction

When attempting to deploy a CaaS (TKGm) workload cluster  with a customized cluster/service domain (e.g., changing cluster.local to custom.value), the following behavior is observed:

• The TCA Cluster Lifecycle Manager API call includes the serviceDomain attribute with the custom value.
• The Cluster object within the TKGm Management Cluster correctly reflects the custom value in .spec.clusterNetwork.serviceDomain.
• However, the resulting workload cluster's kubeadm-config and coredns ConfigMaps continue to use the default cluster.local value.

Environment

TCA 3.4

TCP 5.1

Cause

The serviceDomain property in the TCA API schema is currently a legacy stub and structural placeholder aligned with upstream Kubernetes Cluster API (CAPI) specifications.

While the TCA API accepts the string, the underlying TKGm/CAPI provider bootstrapper for VMware does not possess the translation mechanism to inject this variable into the KubeadmControlPlane template or CoreDNS generators during the workload cluster initialization process. The bootstrapper relies on hardcoded defaults for these internal node-bootstrap manifests.

Resolution

Changing the default internal DNS domain from cluster.local to a custom value is not supported at the cluster bootstrap level in the standard TCA 3.4 / TCP 5.1 orchestration flow.

There is currently no supported workaround to override the dnsDomain property via the TCA API for "Day-0" deployments in these versions. The attribute is retained in the API for future structural alignment with multi-cluster service mesh integrations (such as VMware Tanzu Service Mesh).