Setup Public Access to Tanzu Kubernetes Clusters in VMware Cloud on AWS

Setup Public Access to Tanzu Kubernetes Clusters in VMware Cloud on AWS

You’ve been busy setting up Tanzu Kubernetes Clusters on VMware Cloud on AWS and have gotten to the point where you’re ready to make your Kubernetes applications available to users over the Internet. You need a way to provide this public access into your VMware Cloud instance and down into the Tanzu Kubernetes Cluster where your application is deployed. This blog post will walk through the steps needed to deploy a web application in a Tanzu Kubernetes Cluster running on VMware Cloud on AWS and have it available over the internet.

Publish a Service in Kubernetes

Before we can make our service available over the public Internet, it should be accessible from within the VMware Cloud on AWS instance. Platform operators can publish applications through a Kubernetes Service of type LoadBalancer. This ability is made possible through the NSX-T Container Plugin (NCP) functionality built into Tanzu Kubernetes Grid. You can read more about how NCP works from the blog article here on Techzone.

To publish our service, we will need to deploy a service of type LoadBalancer in our Tanzu Kubernetes Cluster. Here is the example service I’m using for my application.

---
apiVersion: v1
kind: Service
metadata:
  name: loyalty-svc
  namespace: loyalty
  labels:
    app: hardtop-loyalty
spec:
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer
  selector:
    app: hardtop-loyalty

When deploying this service, NCP creates a new NSX-T load balancer with a virtual IP (VIP) and connects it to the node ports used in the Kubernetes Cluster. The screenshot below shows the service deployed in the cluster. The external-ip information listed is the VIP address added to the NSX-T load balancer. The service itself is accepting traffic on port 80, but the node port exposed on the VMs is port 31552.

If we were to zoom out on this setup, you’d see a diagram like the one below where we have an NSX-T load balancer targeting the node ports of our TKC, and within the cluster we have a service that is exposing a set of pods.

 image 13

 

We would then need to add a Compute Gateway firewall rule to allow access to the VIP on port 80 from our source. An example of this is below.

 

Graphical user interface, application</p>
<p>Description automatically generated

Expose the Service Publicly

Now that our service is exposed internally, we can shift our attention to exposing this service to the Internet, where our customers can access it. To make it publicly available, we must assign a public IP address, and configure a Destination NAT (DNAT) rule. A simplified network diagram looks like this:

image 14

Create a Public IP Address

To create a public IP address, we just request one from the pool of public IP addresses held by Amazon Web Services. If you navigate to the Networking & Security section of the SDDC, you’ll find a page for public IPs. Click the “REQUEST NEW IP” button to obtain a new Elastic IP Address.

 

Graphical user interface, text, application</p>
<p>Description automatically generated

 

Once you’ve requested the new IP Address, it will be visible in the Public IPs list.

Graphical user interface, text, application</p>
<p>Description automatically generated

The next step is to create a Network Address Translation (NAT) rule that translate this public IP address to our desired private IP address which is the VIP for our service. While still in the Networking & Security tab, navigate to the NAT screen in the Internet menu. Click the “ADD NAT RULE” button.

On the NAT screen, you’ll give the NAT rule a descriptive name and you’ll select the available Public IP address from a drop down. You can specify which ports are being translated, but for my case I’m going to allow all traffic to be translated. Then in the Internal IP address field, you must enter the VIP for the service that was created. In the last field, you must select whether the firewall rules should be applied based on the internal or external addresses.

 

Graphical user interface, text, application</p>
<p>Description automatically generated

Match Internal Address – If you selected the “Match Internal Address” your work is probably done. You already created a firewall rule to allow access for all addresses to our private VIP.

Match External Address – If you select this option, you must create a firewall rule to allow access to the Public IP Address that was assigned and the port for the firewall rule should be the Internet Interface.

An example of both types of rules can be seen below.

Graphical user interface, application</p>
<p>Description automatically generated

Once the firewall rules are submitted, you should be able to access your application over the Public IP Address.

A picture containing graphical user interface</p>
<p>Description automatically generated

 

Summary and Additional Resources

Exposing a Kubernetes service to the Internet takes a couple of more steps to complete than exposing it to your internal networks, but the VMware Cloud Console makes those steps simple enough. After exposing the Kubernetes service using an NSX-T Load Balancer, you can request a new Public IP Address and then configure a NAT rule to send that traffic to the virtual IP address of the load balancer.

Additional Resources

VMware Cloud on AWS Internet Access and Design Deep Dive

Request or Release a Public IP Address

Kubernetes Service Networking

 

Changelog

The following updates were made to this guide.

Date 

Description of Changes

2021-11-4

Initial publication

About the Author and Contributors

Eric Shanks has spent two decades working with VMware and cloud technologies focusing on hybrid cloud and automation. Eric has obtained some of the industry’s highest distinctions, including two VMware Certified Design Expert (VCDX #195) certifications and many others across various solutions, including Kubernetes, Microsoft, Cisco, and Amazon Web Services.

Eric’s acted as a community contributor through work as a Chicago VMUG Users Group leader, blogger at theITHollow.com, and Tech Field Day delegate.

  • Eric Shanks, Sr. Technical Marketing Architect, Cloud Infrastructure Business Group - VMware

 

 

 

 

 

Filter Tags

App Modernization Tanzu Kubernetes Networking VMware Cloud on AWS Document Technical Walkthrough Intermediate Manage