External Access to K8s Applications with Thunder ADC and TKC

Transcription

This video shows how you can use Thunder ADC along with Thunder Kubernetes Connector (TKC) to provide access to applications running in your Kubernetes K8s cluster in an easy and automated manner.

AI Transcription:

Hello everyone. My name is Siddhartha Aggarwal and in today’s video we will see how you can use Thunder ADC along with Thunder Kubernetes Connector (TKC) to provide access to applications running in your Kubernetes cluster in an easy and automated manner.

Here is an example deployment scenario. We have a web application running within our Kubernetes cluster and it is exposed to the outside world using a service type of NodePort.

However, we want our web service should be accessible to the end users using a single IP address and the well known port number 80, and this type of access can be provided using our Thunder ADC, sitting outside the Kubernetes cluster, as shown.

Additionally, we have the Thunder Kubernetes Connector running as a port within the Kubernetes cluster. The TKC determines the node port value allocated to the web service and dynamically configures the Thunder ADC to load balance traffic to the Kubernetes nodes.

Here is a high level overview of the steps we will follow. We will first deploy our web app with a service type of NodePort.

We will then enable HTTPS management access on a Thunder ADC interface. The TKC will connect with the Thunder ADC on this interface.

Finally, we will deploy various Kubernetes resources as shown. We will go into the details of these resources during the Demo. Now let us look at the demo.

First, we will deploy a web service within the Kubernetes cluster with a service type of NodePort. For this, run the following commands.

Next we will enable HTTPS management access on the Thunder ADC.

Here is the configuration on our Thunder ADC device.

Interface Internet 1 is the interface to which the TKC will connect. For this, we will enable HTTPS management access on this interface. For TKC to be able to connect and configure the Thunder ADC, it needs to know the username, password of the Thunder device.

For this, we create a Kubernetes secret object with base 64 encoding of the defer username admin and password A10.

Additionally, we create the object’s ServiceAccount ClusterRole and ClusterRoleBinding.

Now we create an Ingress Resource with an Ingress class of A10-ext

Later on we will configure the Thunder Kubernetes Connector to pass Ingress resources with this value.

Here is the yaml file for the Thunder Kubernetes Connector. Some key points to note over here are the TKC version being used is 1.11.0.0.

Under controller URL, we have the interface IP of the Thunder device for which we had enabled HTTPS management access.

The use Ingress class-only flag is set to true, and the corresponding Ingress class value is same as the one we had said earlier for the Ingress Resource. To deploy the TKC, run the following commands.

Now we will install A10’s custom resource definitions or CRDs for the TKC. Starting from version 1.11, TKC allows you to define your own CRDs for SLB objects in the Kubernetes API.

Now we will deploy the HealthMonitor object. You can verify the status using the command ‘kubectl get a10hm’.

The status should be active. Next, deploy the service group. The service group resource binds to a specific Service Reserve. In this case, web01.

Now create the web object. Within this object we specify the IP address that will be used by the end user to access the web service running within the Kubernetes cluster.

Finally we will create a vport object. The virtual port resource binds to a specific Ingress Resource as shown.

If we now go to the Thunder device, we can see that the corresponding configuration has been added on the device.

To verify that the configuration is working, here we have a client machine with the DNS entry mapping to the whip on the Thunder device.

On doing a curl to this host name we get a response back from our web service running within the Kubernetes cluster.

This shows that the Thunder ADC was successfully able to process the client request and forward it to the nodes in the Kubernetes cluster.

With this, we conclude the demo. Thank you for watching.