Tigera: Your Switches Don't Need to Know That Your VM Has Moved: Extending an Existing VLAN into Your Kubernetes Cluster

A VM in your estate today sits on a VLAN, and that VLAN does more work than its configuration suggests. The VM’s address comes from that subnet. Its default gateway is the SVI on that VLAN. The firewall rules that permit its traffic reference the subnet, not the machine. And if your segmentation zones are drawn on VLAN boundaries, as they are in most enterprises, then the VLAN is the thing putting that VM inside its zone.

Run the same VM on a Kubernetes cluster in the default configuration and it draws an address from an overlay, NATed on the way out, in a subnet nothing else in your estate has heard of. It still works, technically. But that VM is now a different kind of citizen than every other machine in its tier, and the zone it used to sit inside no longer contains it.

There is another option: extend the VLAN into the cluster and let the VM keep its IP, its MAC, and its subnet membership, so nothing upstream has to change.

Join us for a technical walk-through of how L2 bridge networking does this, with a demo of a VM on a cluster answering on its original address, on its original VLAN, with the switches upstream none the wiser.