Access Org Network Services from TKC Guest Cluster in VMware Cloud Director with Tanzu

Many applications running in container platforms still require external resources like databases. In the last article, I've explained how to access TKC resources from VMware Cloud Director Tenant Org Networks. In This article, I'm going to explain how to access a database running on a Virtual Machine in VMware Cloud Director from a Tanzu Kubernetes Cluster that was deployed using the latest Cloud Service Extension (CSE) in VMware Cloud Director 10.2.

If you are not familiar with the vSphere with Tanzu integration in VMware Cloud Director, the following diagram shows the communication. I have a single Org VCD that has a MySQL Server running in an Org network. When leaving the Org Network, the private IP address is translated (SNAT) to an public IP from the VCD external network ( The Customer also has a Tanzu Kubernetes Cluster (TKC) deployed using VMware Cloud Director. This creates another Tier1 Gateway, which is connected to the same upstream Tier0 Router. When the TKC communicates, it is also translated on the Tier 1 using an address from the Egress Pool (

So, both Networks can not communicate with each other directly. As of VMware Cloud Director 10.2.2, communication is only implemented to work in one direction - Org Network -> TKC. This is done using automatically configuring a SNAT on the Org T1 to its primary public address. With this address, the Org Network can reach all Kubernetes services that are exposed using an address from the Ingress Pool, which is the default when exposing services in TKC.

Now I want my MySQL Server, running in the Org Network, to be available for Pods on the TKC. My MySQL Server is running on I create a DNAT rule using the primary address from my Tier 1 Gateway. To be able to configure multiple services without wasting public addresses, I translate a random external high port (31542).


To mitigate security concerns when having a MySQL Server exposed to the Internet, create a Firewall rule to only allow traffic from the TKCs Egress address ( This address is bound to the Kubernetes Namespace which is created when assigning a Kubernetes policy to an Organization VDC in Cloud Director. This address is not shared with other customers.

Now you should be able to access the MySQL DB from Pods using the address To give it a more Kubernetes-like behavior, create a Service and Endpoint using kubectl to map the external service to Kubernetes objects. This can be done by using the following YAML file:


kind: "Service"
apiVersion: "v1"
  name: "mysql-at-vcd"
    - name: "mysql"
      protocol: "TCP"
      port: 3306
      targetPort: 31542
      nodePort: 0
kind: "Endpoints"
apiVersion: "v1"
  name: "mysql-at-vcd" 
  - addresses:
    - ip: "" 
      - port: 31542 
        name: "mysql"

Apply the YAML file:

# kubectl apply -f mysql-at-vcd.yaml
service/mysql-at-vcd created
endpoints/mysql-at-vcd created

You should now have two Kubernetes Objects:

# kubectl get service mysql-at-vcd
mysql-at-vcd   ClusterIP           3306/TCP   11m

# kubectl get endpoints mysql-at-vcd
NAME           ENDPOINTS            AGE
mysql-at-vcd   12m

You can now access the MySQL Service by using the DNS Name mysql-at-vcd. The internal DNS will resolve to the Cluster-IP which is redirected to the endpoint You can easily test the connection by bringing up a mysql-client pod.

# kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql-at-vcd -u admin -p vmware 
If you don't see a command prompt, try pressing enter.

mysql> show databases;
| Database           |
| information_schema |
| mysql              |
| performance_schema |
| test               |
| vcd                |


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.