A short walkthrough of how BGP Maintenance Mode ensures smooth, interruption free routing when draining or updating Kubernetes nodes. Introduction In this short video, we're going to look at the BGP Maintenance Mode feature available in Isovalent Networking for Kubernetes 1.18 and later. This feature helps manage traffic disruption during normal day-to-day maintenance operations in your cluster. It's quite easy to get set up and started, so I'm going to dive straight in. First, if we look at the values file I used to install the environment, you'll notice that under the enterprise configuration we're enabling node maintenance together with the graceful shutdown community. I'm also enabling the withdraw timer, which controls how long a Service IP address continues to be advertised to the network once the maintenance window begins. In this demo, it's set to 60 seconds so traffic has time to move to another node if needed and any active connections have a chance to complete cleanly. In my environment, I've already prepared the BGP peerings. The Kubernetes nodes are already peered with an upstream router, and the initial state shows the expected routes being advertised. Validate route advertisement Because this is a demo environment, I'm advertising Service IPs, LoadBalancer IPs, and ClusterIPs, although you can also do the same thing with Pod IPs. If we look at the BGP advertisement manifest deployed into the cluster, we can see that the advertisement is configured for Services and that the selector is intentionally broad so everything gets advertised rather than only a subset of addresses. The address types being announced here are ClusterIP and LoadBalancer. From the upstream router, I can look up route information for one of the Kubernetes Service addresses. The router shows two available paths, which correspond to the two Kubernetes nodes, and one path is currently preferred. If we inspect the route entry more closely, we can also see that the route is being learned via BGP. Deploy BGP maintenance mode Next, I'm going to cordon one of the worker nodes. This adds the graceful shutdown community so the upstream router knows the node is being prepared for maintenance. At the same time, we expect the associated routes to stop being advertised. Back on the upstream router, the change is visible almost immediately. The graceful shutdown community appears on the route, the last-update timestamp changes, and the route to the node being maintained is no longer preferred. In the routing table, traffic is already being moved away from that node. On the Cilium side, the BGP peers are still up because the node is still online. It has only been cordoned, not shut down. The routes stay visible briefly during the withdraw interval, and after roughly 30 seconds in the demo, the routes from that node disappear from the advertised set. I then uncordon the node. Once it returns to the Ready state, Cilium starts advertising the routes again. On the upstream router and the top-of-rack switch, the route is added back, and the routing table returns to the expected two-path state. Drain a node without traffic loss That is the core value of BGP Maintenance Mode in Isovalent Networking for Kubernetes 1.18: we can prepare a node for maintenance, signal the change to upstream routers, and shift traffic away cleanly before taking the node fully offline. In practice, that means draining or updating nodes with far less risk of interrupting traffic. For more information, you can head to the Isovalent website and labs to explore BGP, egress gateway, network policy, and other features in more detail.