The Standalone Egress Gateway allows you to route traffic from pods through dedicated external nodes without requiring them to be part of the Kubernetes cluster. This opens up new deployment designs in both cloud and on-prem environments. This feature was introduced in Isovalent Networking for Kubernetes 1.17. Introduction In this video, we're going to look at the Isovalent Networking for Kubernetes 1.17 feature release for the standalone egress gateway feature. That's the ability to deploy a virtual machine or a bare metal node that runs a cut-down version of Cilium and can participate in the egress gateway feature as a standalone node, meaning it's not part of the underlying Kubernetes cluster. This is particularly useful in a wide variety of environments, whether in your private data center or a public cloud, so that you can direct network traffic from your clusters through a known IP address into your various client networks wherever they may be. I'm going to take you through a very short demo showing that feature in use. Egress Gateway Overview First off, let's have a quick look at my Kubernetes cluster right now. I've got three nodes: one control plane and two worker nodes in my environment. However, with the standalone egress gateway feature, we now introduce a synthetic Cilium node that allows us to connect that cut-down version of Cilium running on an external node to our Cilium environment. So if I run the get CiliumNode command, we can see that we have a fourth node added. It's got an IP address ending in .9, which we're going to remember for later as part of our testing. Let's have a quick look at one of our existing Cilium nodes and see the information that's available. We can see there's quite a lot of metadata kept as part of a Cilium node when it's part of the Kubernetes cluster. However, if we now look at this synthetic node that has been created, we can see that it's very cut down. There are two very specific annotations that have been added, mainly to ensure garbage collection doesn't remove it, because it doesn't exist inside the Kubernetes cluster. Policy Configuration We're targeting it, so we have a label available. We can target it using an Isovalent egress gateway policy, and we know that it can be referenced on our network itself. Let's look at the policies that are available at the moment. I've already deployed an egress policy in my environment. At the moment it's set to go to two destinations: 1.1.1.1 and 172.18.0.10, which will be very important when we deploy a workload for this demo. We're matching the node label we saw earlier as our egress node to be used when this policy is activated, and we're defining which traffic it actually applies to. Inside our environment, the only traffic that will be matched and sent through that node is our net pod running in the default namespace. We can see here we've already connected, and it's a healthy gateway connected to that standalone egress node inside my environment. First, let's have a look at my pod. It's running on Cilium worker node 2. If we do kubectl get nodes -o wide, we can see that it's running on the .2 IP address. That'll be important soon as well. I'm just going to clear my terminal and make sure we can actually send some traffic. So we're going to ping the 1.1.1.1 destination, and that's successful. Then if I check in my VM terminal, we can also see that we've got the BPF map being built. The endpoint IP was my net pod, the tunnel endpoint was that Cilium worker 02 that I just showed you, and that's the security identity as it comes from Cilium itself. So that's now being held on that standalone gateway where I'm running this command. Configure Egress Traffic Handling We're going to move back across now. To make this a little bit more interesting from a connectivity point of view, we're going to deploy a new workload. That new workload sits outside my Kubernetes cluster today, and we're going to allow only traffic from our standalone node itself. If the traffic doesn't come from that standalone egress node, it's going to be denied. Deploy Egress Gateway So we've deployed that. I'm just going to clear that down, get the IP address of it, and it should still end in .10. Yep, so that's great. It's already going to match my existing policy that I put in place, just to make things a little quicker as part of this demo. Now we're going to try and connect to that, and we can see that it's granted. The reason is because the source IP that's being shown ends in .9, which matches my standalone gateway. However, we can also break that. If I edit this policy and remove this traffic, then the traffic is going to go through my Cilium worker node where the pod runs, and we can now see that it is denied. Configure Egress Gateway Policy Previously my policy was working correctly because the gateway node was being used, and that external service was only configured to accept traffic from that gateway node. At the end here, we've removed that policy, and now we can see it's not using the egress feature at all, so that service won't accept the traffic. That was a quick run-through of that new feature in Cilium 1.17. I hope you enjoyed it. Thank you very much.