Tigera: Your VM Moved but Its Load Balancer Didn't: Rebuilding the Application Edge on Kubernetes
An application in your estate today is published through a load balancer holding a VIP, terminating TLS with a certificate somebody renews, behind a web application firewall with a rule set tuned over years, on a segment with QoS so a noisy neighbour can’t starve it at month end. None of that is the VM. All of it is what makes the VM an application other people can use.
Move the VM onto a Kubernetes cluster and those four controls have to live somewhere. The tempting shortcut is to leave them where they are and hairpin traffic back out to the appliance, which works but quietly makes your new cluster a dependency of the platform you were migrating away from.
There is a Kubernetes-native home for each one: a Gateway API path for routing and TLS, a WAF on that path, per-workload QoS, and network policy underneath all of it.
The decisions that matter are about order and visibility. Where you terminate TLS determines whether the WAF can read the request at all. The WAF inspects what is being asked; network policy decides who is allowed to ask — and assuming either one covers the other’s ground is how gaps get built in.
This session puts the four controls on the traffic path in order, for a service whose backend is a VM rather than a pod.
What you will learn: What Your Load Balancer Was Actually Doing — The four jobs NSX Advanced Load Balancer held together — the VIP, the load-balancing decision, L7 routing and TLS termination — and which Kubernetes construct each one becomes. Publishing a Service Whose Backend Is a VM — A Gateway API route to a Service whose endpoints are KubeVirt VMs, and what the label selector matches when the workload isn’t a pod. Where TLS Ends, and What Happens After That — Terminating at the gateway versus passing through to the workload, how to pick the boundary from your trust zones, and who rotates the certificate. The WAF, and What It Is Not — What a WAF inspects that network policy cannot see, what policy enforces that a WAF never will, and why substituting one for the other leaves gaps. QoS Per Workload, Not Per Segment — Bandwidth, packet rate and connection limits on one workload, and DiffServ marking so priority survives onto the physical network. The noisy neighbour, per VM. The Whole Path, In Order — One request from external client to VM backend, every control it passes in sequence, and what each one can see at that point. Who should attend:- Application delivery and load balancer owners who need to know where the VIP, the routing, the certificate and the WAF rules go once the backend is a VM on a cluster.
- Platform engineers running KubeVirt whose VM-backed services are currently published by hairpinning back out to an appliance, and who want that dependency gone.
- Security engineers who own the WAF rule set and need to understand what it still covers, what network policy covers instead, and where the boundary between them now sits.
Join us to put ingress routing, TLS, web application firewalling, QoS and network policy in their correct places on the path to a VM-backed service, five controls, five distinct jobs, in the order traffic meets them. You’ll leave knowing which control to reach for when something breaks, and which one to point at when the security team asks what’s protecting this service. An educational session on the mechanics, not a product pitch. Bring your questions!