Understanding Avi Load Balancer and Its Role with VMware VKS

When deploying applications on VMware vSphere Kubernetes Service (VKS), one of the questions that often comes up is how applications are exposed outside the Kubernetes cluster.

Kubernetes provides the concepts needed to expose applications, such as Service and Ingress, but the underlying infrastructure still needs to handle traffic distribution, virtual IPs, health checks, and application delivery.

In the VMware ecosystem, this is where Avi Load Balancer comes into play.

Avi provides the application delivery and load-balancing layer that can integrate with VMware Kubernetes environments, including VKS.

Where Avi fits into the architecture

A simplified VKS architecture looks something like this:

                    Internet / Users
                           |
                           v
                  +------------------+
                  |  Avi Load        |
                  |    Balancer      |
                  +------------------+
                           |
                    Load Balancing
                           |
             +-------------+-------------+
             |                           |
             v                           v
        VKS Service                  VKS Service
             |                           |
          Pod/Ingress                 Pod/Ingress

The important thing to understand is that Avi and Kubernetes have different responsibilities.

Kubernetes manages the application workloads.

Avi manages application traffic and load balancing.

This separation allows Kubernetes to remain focused on scheduling and managing workloads while the infrastructure provides the networking and application-delivery capabilities needed to expose those workloads.

What is Avi Load Balancer?

Avi Load Balancer, originally developed by Avi Networks and subsequently acquired by VMware, is an application delivery and load-balancing platform.

It provides capabilities such as:

Layer 4 and Layer 7 load balancing
Virtual IP addresses
Application health checks
Traffic distribution
TLS/SSL termination
Application visibility and analytics
Ingress and application delivery capabilities
Global Server Load Balancing (GSLB) in supported architectures

For Kubernetes environments, this means Avi can provide the infrastructure layer responsible for receiving traffic and directing it toward the appropriate Kubernetes workloads.

How Kubernetes and Avi work together

Consider a simple Kubernetes application.

You might have a Deployment containing two application Pods:

Deployment
    |
    +-- Pod 1
    |
    +-- Pod 2

You then create a Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

The Kubernetes Service defines how the application should be exposed.

The underlying VMware integration can then work with the load-balancing infrastructure to provide the external connectivity required by that Service.

Conceptually:

Client
   |
   v
Avi Virtual IP
   |
   v
Kubernetes Service
   |
   +-------+-------+
   |               |
   v               v
 Pod 1           Pod 2

The application developer doesn’t necessarily need to understand all of the infrastructure details. They can work with familiar Kubernetes resources while the platform handles the underlying load-balancing configuration.

Avi isn’t Kubernetes

It’s important not to confuse Avi with the Kubernetes networking layer.

Avi does not replace Kubernetes.

Kubernetes remains responsible for things such as:

Deployments
Pods
Services
Scheduling
Scaling
Rolling updates
Container lifecycle

Avi provides the application-delivery functionality around those workloads.

This distinction becomes particularly useful when troubleshooting.

For example, if a Pod is crashing, the problem is likely inside the Kubernetes workload.

If the Pods are healthy but external clients cannot reach the application, the problem could instead involve the Service, networking, load-balancer configuration, DNS, firewall rules, or Avi.

Avi and NSX

VMware networking terminology can be confusing because Avi and NSX are complementary technologies rather than competing products.

A simplified view is:

VMware Cloud Foundation
│
├── NSX
│    └── Networking / Security
│
├── Avi Load Balancer
│    └── Application Load Balancing
│
└── VKS
     └── Kubernetes Workloads

NSX provides networking and security capabilities.

Avi Load Balancer focuses on application delivery and load balancing.

VKS provides the Kubernetes environment where the containerized applications run.

Together, these components can form an integrated infrastructure stack for Kubernetes applications.

Why this integration matters

One of the advantages of using VKS within a VMware environment is that Kubernetes doesn’t have to exist as an isolated platform.

Instead, application workloads can be connected to infrastructure services that are already part of the VMware environment.

For an enterprise, this can provide a consistent approach to:

Networking
Load balancing
Security
Application delivery
Infrastructure operations
Kubernetes workloads

This can be especially useful for organizations that already have established VMware operational practices and want to extend those practices to Kubernetes.

A typical traffic flow

Consider an application called orders.example.com.

A user requests:

https://orders.example.com

The request might follow a path similar to:

User
  |
  v
DNS
  |
  v
Avi Virtual IP
  |
  v
VKS / Kubernetes Service
  |
  v
Application Pod

Avi receives the request and determines where the traffic should go based on its configuration and health information.

Kubernetes then provides the application endpoint represented by the Service and ultimately routes the traffic toward the appropriate Pod.

If multiple Pods are available, traffic can be distributed across them.

If one Pod becomes unhealthy, Kubernetes can replace it, while the load-balancing layer can ensure that traffic is directed only toward healthy endpoints.

The bigger picture

The value of this architecture isn’t simply that it provides a load balancer.

The larger benefit is the integration between the application platform and the infrastructure platform.

Developers can continue using standard Kubernetes APIs:

kubectl apply -f deployment.yaml
kubectl get pods
kubectl get services

Meanwhile, infrastructure teams can manage the networking and application-delivery components using the VMware platform.

This creates a separation of responsibilities:

Application Team
       |
       v
   Kubernetes
       |
       v
Infrastructure Team
       |
       +-- NSX
       |
       +-- Avi
       |
       +-- VMware Cloud Foundation

Conclusion

Avi Load Balancer is an important component to understand when working with VKS and VMware Cloud Foundation.

Rather than replacing Kubernetes networking, Avi complements it by providing application-delivery and load-balancing capabilities for workloads running on Kubernetes.

The simplest way to think about the relationship is:

VKS runs the applications.

Kubernetes manages the workloads.

NSX provides networking and security capabilities.

Avi provides application load balancing and delivery.

Together, these technologies allow organizations to build a Kubernetes platform that is integrated with their existing VMware infrastructure rather than operating Kubernetes as a completely separate environment.

Share on Social Media