1:25 Introductions

1:28 Hello. Hello. Hello. Hello. Hey, Dan. How's it going? It's going very well at the moment. I I will start off by apologizing to the fact that I appear to be a circle that pulses as I speak. My machine is so unstable at the moment that webcams cause it to power cycle at the moment. Because computers. Yes. Maybe I'll I could do this this minor inconvenience, and we will just respect the the circle, I guess. Plus, we're not here to see your face. We're here to see your code and your demonstration. Fear not. Excellent. So today,

2:12 we're gonna take a look at one of your open source project. It's called kube VIP. So why don't you just give a quick thirty seconds intro about yourself and the project, and then we'll take it from there. Sure. So, yeah, I've I've been kind of involved a little bit in writing kind of software around bare metal for a little bit of time now. It mainly stemmed from a customer that we had when I was based in Hep Heptio. Traveled all the way to go see this customer in The Middle East, and I was basically left to my own devices

2:46 in that these people this customer was like, we want a Kubernetes cluster on bare metal, and we'll see you at the end of the week, which was nice. So I I kind of, you know, I spent the week writing a load of bash scripts to kind of automate the process and, you know, kind of the few things that they specified was they wanted it as cloud like as possible. And, you know, I kind of did with the best that I could within that that one week and kind of handed over to them this this cluster all running on

3:19 a bunch of Dell machines. But, you know, it's kinda quite clear that I'd handed something over to them that they still really weren't gonna be able to use once I'd left. But, you know, I kind of carried on working with them a little bit after that. And the more customers that I kind of worked with that were looking kinda doing more and more bare metal deployments, the more I kind of realized that there was kind of quite a sizable hole in terms of what there was in the ecosystem in order to kind of just do the deployment.

3:53 And then as we as I looked at kind of trying to automate that and scale those sorts of things up, dealing with the load balancing part in front of the in front of your control plane started to annoy me in terms of what was out there at the moment. So I ended up fiddling as I, I guess, I often do and kind of coming up with few ideas and how I could kind of make things a bit easier, especially in kind of conjunction things like cluster API, which Jason was talking about last week. And that's kind of led me to where

4:29 I am at the moment. Wow. Interesting. Really, really interesting. So this project is part of I'm still laughing at clouds like Kubernetes, but I'm gonna come back to that later. That's that's the QVIP project is is part of something broader called Plunder app. Do you wanna just cover that as well? Yeah. Sure. So Plunder is essentially a a bare metal provisioning tool. So it's it's effectively a a wrapper or or a load of code around a bunch of, like, super old technologies. So, like, mainly DHCP, TFTP, and HTTP, which are all 20 or 30 years old and are kinda

4:40 Introduction to Plunder (Bare metal provisioning tool)

5:20 quite hard to manage from a a static point of view. A lot of configuration files and things like that. So the main goal around all of this was to basically put an API on top of all of this, and that is effectively what Plunder does. It it it provides an API on top of DHCP and TFTP. And it it it actually has all of those technologies built in. So even though it's a single binary, it runs as, like, three or four different servers. And then exposes all of those in a way that we can I can kind of

5:54 automate and actually do then bare metal provisioning? So that's again, you know, I had an itch and this is kind of the the scratch to that itch, I suppose, on on bare metal provisioning. Yeah. I mean, tackling these kind of problems. I mean, would you say you have masochistic tendencies? Well, so, I mean, I I I did a talk about this at one of the Go meetups not so long ago where I had to apologize. Well, I I felt that I should apologize because I was developing a lot of this whilst I was kind of, you know, working with

6:00 Dan takes down a hotel network

6:29 customers. And at one point, I was in a a hotel in Germany, and I've been developing this on my laptop with a bunch of VMs and things. And I left my laptop kinda connected to the network. And when I came back from dinner, I noticed that one of the wall computers that they had, which advertised what was taking place in one of the conference rooms, actually had a Linux prompt being displayed on it. It turned out that all of those machines would DHCP boot on the same network as the Wi Fi. And I've been basically giving out leases to

7:04 various machines around the hotel which should start provisioning themselves from Plunder. So they yeah. I mean, it's it's dangerous technology in the wrong hands, I suppose. Please never work on this project when you're on a plane, at least if I'm on it, for sure. Yeah. Yeah. Okay. So we're gonna take a look at is it kube kube-vet or kube-vip? I I've called it kube-vip, but, I mean, it it's I I mean, I have no there's no kube cuddle, kube control arguments here on on that one. Well, that's a cloud native way. Like, we have to

7:41 we have to argue or debate the semantics of the pronunciation. So I'm gonna say kube-vip. You can continue to say vet, then we'll let other people make their own team or decisions. No problem. So let's let's look at the the GitHub page here. So it's a Kubernetes control plane, virtual IP, and load balancer. So what makes bare metal different from, you know, maybe Kubernetes customers that people are used to running on AWS, GCP, etcetera? The biggest thing that's kind of missing is the out of the box IP address and kind of load balancer. So with AWS

8:00 What makes bare metal Kubernetes different from managed services?

8:19 or Azure, etcetera, all of the bits that you kind of need to have another IP address that that can move around or you'd be used to point at a different member of the control plane is is already exists. When we look at bare metal, a lot of those technologies you have to implement yourself and manage them yourself as well. So Are we using something like KeepAliveD? Is that Yes. Is that doing something similar, like, is responsibility school? It is. Yes. So KeepAliveD, there there are a couple of others I think I mentioned at the bottom

8:59 on there. They do work in the in in a similar manner and that you would have a keep alive cluster as such. And that would do some level of voting or whatever cluster management and move an IP address around. The problem that I kind of found there is that I would then need to have to manage an an extra cluster, a keep alive cluster, and the configuration that goes within so you keepalive.conf and things like that. Ideally, I wanted something that was slightly easier to manage. And I suppose to a certain degree, something that was a bit more tightly coupled to

9:40 What are we going to demo today?

9:40 Kubernetes. Nice. Okay. So I believe that you are boldly gonna attempt to show us this project in action in two different ways. Right? Do wanna cover what those are gonna be? Sure. Yes. So the original plan for for kube-vip or whatever kind of wasn't its first guide was really just to be able to have basically a fourth IP address or or an IP address that I would hit, and then I would go to one of the control plane members underneath. And then as as often happens, I was like, oh, I've always wanted to work out how to

10:27 write a load balancer inside Kubernetes, so service type load balancer, which is a rabbit hole to a certain degree and and having to do various other things. But, you know, I kind of I quite happily I was very surprised even when I I finally managed to get that to work. So kube-vip is not only a a virtual IP and load balancer that sits in front of the control plane, but you can also deploy it within within Kubernetes and then use that as a load balancer for, you know, for deployment or for for pods and things like that.

11:07 Okay. You're just setting out with loads of sentences today that I never thought I'd hear anyone in my life say that I want to know how to write a service load balancer for Kubernetes. Like, surely, less than three people in the world have ever uttered those words. No. I actually I mean, I I luckily managed to find a load of work by, like, people like James Mondly, who'd kind of had to play with it years ago and and whatnot. And whilst the way that you write controllers has changed and, you know, there's a lot of kind

11:37 of frameworks around there and things like that, I I the docs still do suffer a little bit. You are kind of left in the dark in terms of why do I need to implement this and how does it work. But I did struggle for quite some time, but I was kind of, like, you know, kinda quite happy that I did actually manage to work out what was going on towards the end. Nice. So I'm looking forward to seeing it. So what I'm gonna do now is I'm gonna pop your screen. Wichita. Yep. And it is now being shared.

12:00 VIP for Kubernetes Control Plane High Availability (HA)

12:08 So I can see three terminals. So what's going on here? So we have three three bare metal nodes that are running on packet. And so they're they're all up and running. The only things that have happened to these is they're running basically Ubuntu 18 o four. I've done an app to get install of the various packages that are required. So we can now basically initialize a a Kubernetes cluster in a in a manner. So one thing I will do is I'm just gonna quickly pop open one more terminal and make that a little bit bigger.

12:57 Right. Okay. So what we're gonna do on on the on the bigger pane, this one here, is we will go through the two steps that are needed in order to initialize our first control plane node. And the method around this is kind of a bit important. A lot of this is tied to kube a d m. I know there are multiple different ways of initializing a Kubernetes cluster. I've always been kind of in the q a d m camp, I suppose. This always seemed like kind of the and given its kind of popularity and how you

13:34 use that with cluster API, it made sense for me at least to follow that method. There are a number of different ways that you could perhaps instantiate the the Vip side of things, but, yeah, I'll step through that. So okay. So on our first node, the first thing that we're going to do is to do a docker run. Oh, crap. I don't know how best one second. I will need to do something. I'll move this window over here a second so that I can take my key out of the history. It's always the way, isn't it? Yeah. It's

14:16 pretty I just moved the window. Nothing to see here. I'll come back and choose the moment. I lost track of the amount of times I've put access keys or tokens onto Yes. Yeah. So one second. If anyone has any questions about kube-vip, plunder, packet, anything like that, just feel free to drop them into the chat on YouTube, Periscope, Twitter, or Twitch. Cool. We will do our best to answer. So if we can pretend we didn't see that, what's actually happening here is that we're gonna do a docker run using the kube vip image. And passing it a number of flags. So there's

15:06 a number of kind of key important ones really here. The main one really is we're we're gonna be using BGP and we're gonna be binding to an internal interface and and whatnot. But the main thing here is that we're actually gonna be using kube-vip to generate a static pod manifest. So the reason why we're doing this really has been kind of a lot of work that's kind of get around the chicken and egg problem of running a VIP and load balancer inside a Kubernetes cluster. Now, the reason why this is a chicken and egg problem is that of the way

15:42 that kube-adm init actually works. So I'll generate this manifest and we'll kick off the kube-adm init. And, we'll leave this pinging. So, what's actually the the chicken and egg scenario here is essentially the kube-adm in it. If we want to use a control plane, we need to give it the IP address of the control plane the load balance that that we're wanting to make use of. Now, if we are in AWS or we have an appliance like an f five load balancer, that device already exists or we can build that functionality before we actually build up our Kubernetes cluster.

16:34 So we can see here we have successfully deployed the first node. And on the right hand window, we can now see that our EIP exists to actually access. So kind of coming back to that chicken and egg scenario, we need a way of bringing up the load balancer kind of at the same time that we bring up the Kubernetes cluster because kube-adm in it will start all of the manifests that exist within the manifests directory. Once it has basically told kubelet to start all of those, the kube-adm init's kind of final steps are to to basically

17:19 check that control plane endpoint and basically do a a get on health to make sure that things are up and running as expected. So we will add now in our additional nodes as you would do. Okay. So this is just the other two other bare metal machines which are now joining the cluster. So this will take a few seconds also. But there's another thing that we have to be aware of here. So we can generate the manifest first when we do a kube a d m in it. However, a kube a d m join will error if that static pod manifest exists

18:04 on join. So the manifest directory has to be empty on a join, but it can be pre populated on an in it, which I don't know. I mean, I'm waving my hands in the air, but my camera's not on, so such is life. So the final step really on the first node, we generate the static pod manifest. Kube adm init will then bring up all of the static pod manifests in that directory, including the kube vip manifest. So as everything all comes up, our vip is initiated and is substantiated. Kube a d m in it can speak

18:40 through that vip to the control plane, and we now have that up and running. On the additional nodes, we join them using the normal kube ADM join. The last step here One second. If we do the same docker run command, that will generate the same static pod manifest into the etcd manifest Kubernetes manifest directory. And now kube-vip will be running on all three of the control plane nodes as a static pod manifest. And the way that kube-vip works is that it uses the Kubernetes scheduler leader election. So if I grab our token here, we can kind of see this in action,

19:40 which is so we can see our three kube-vip pods that are actually running. And if we we can see here that we have the lock and we have assumed leadership of the cluster. And we're also using BGP to inform the routers that that exist within the packet network. The traffic for our external IP address should come to this node. Now this is important because we're gonna kill the first node. And we should see on the window on the right, we will lose a few packets as a leader election will take place in the cluster, and our EIP will move to one

20:34 of the other nodes in that cluster. So three, two, one. Sounds ambitious. Oh. Boom. So That was fast. Yeah. It it so it turns out we can actually do it faster than that. I've just not had the chance this weekend to implement that functionality, but I'm still learning a lot about BGP. It's a bit of a terrifying technology. There was another major outage this weekend that took place. And when I was implementing this for the first time inside the inside the packet network, I actually had to ask a number of network engineers to sit and monitor the switches for the

21:19 first time I actually did a failover to make sure I didn't break anything inside the packs. The last thing I wanna do is start breaking bits of the Internet and whatnot. But it's a You were responsible for the CenturyLink outage. Is that what you're saying? Luckily, I don't think it was me, but there was a Zoom outage when I actually tried this the first time. But I don't think I had anything to do with that. But, yeah, it it's a it is a bit of a terrifying technology. But it turns out in inside the packet now,

21:47 we have a lot of safeguards in place to prevent people doing anything anything kind of too silly with with BGP. Yeah. So so just for the, you know, the people that are watching. Right? That the high level of BGP is if you can speak to the router and say, want to register myself as the responder for this IP address or prefix, and then that router will send direct all the traffic that looking for that IP address or prefix to your machine. Is that Yep. Okay. Yep. So yes. Well done. That's better than I could have explained it, actually.

22:21 Yeah. So, I I mean, effectively, what's actually happening is when one of the kube-vip nodes gets the leader election and and is given the leader lease, that that particular pod will then start advertising an IP address in a number of different ways. Within packet or using just BGP generally, we will need to give it the peering details for a router in that network. So it can connect to that network and say traffic that wants to hit this particular IP address should be routed through me. I'm the leader. Alternatively, in a a layer two manner, we can use ARP. So I it's disabled

23:05 inside here because it it simply just won't work because it's blocked within packet. But on a different network, what would happen on leader election is that a a node that is allocated the leader lease will suddenly do an ARP broadcast to switches and network devices, which says that if you want to this IP address, which is our VIP, is accessible on this MAC address, which is the MAC address of the host that now has a leader election. So that's layer two updates, which says where traffic should actually go. Okay. Cool. Well, you get into the weeds in networking

23:49 here. It's been a it's been a learning experience for for me as well. So just to clarify then, this is this is very much a bare metal problem. Right? This is not something you would experience on GCP or AWS because of all the virtualization, and there's just something there reconfiguring the network and all the VMs. Right? This is but on bare metal, we we don't have that flexibility. And that's why this is needed. Is that correct? Yes. Within within, you know, kind of Azure and AWS, a lot of this functionality is provided through software. You won't you wouldn't need to implement any

24:24 of this yourself. There exists a myriad of services in all of these cloud providers. So, you know, you don't need to worry about any of these sorts of things. A simple API call to the AWS SDK and, you know, your your elastic IP will move anywhere it needs to go. And one final thing. There's there's nothing packet specific here. Right? This is using BGP, which would work in any bare metal cluster with a a root over there to handle the request. Right? Yes. The so the only thing that is packet specific, which is why I

24:58 accidentally flashed my API key to the to the world, I suppose, is that using that API key, kube-vip can look up all of the BGP configuration that we would normally have to specify manually. So with the API token, kube-vip can actually look up all of the pairing information so that it knows who to give the addresses to and things like that. So it was it's just another kind of ease easy easy step, well, for me at least, to skip out, you know, kind of having to do things manually and whatnot. Okay. They're right. This will work anywhere that

25:37 there are reasons that advertise on BGP. Right. So I think what we've covered there then is the VIP aspect of kube VIP. And we have a and I should have said that there just to kinda break that up. But we have a highly available Kubernetes control plane with relative ease. Yes. So I tried to make it follow as much of the kube a d m path steps, whatever you wanna call it, as much as possible, and to automate things as much as possible as well. So either dropping static pods either dropping static manifests into the manifest directory.

26:22 Another option is doing either kube a d m in it in phases or having a program that runs and watches for the API server coming up for the first time and immediately dropping a daemon set in there before the kube a d m in it process finishes. That daemon set comes up along with the vip. Kube a d m in it can hit that vip and verify that the cluster's up and running and things like that. It's very hacky, but there's no real nice options at the moment. Could we not? I don't I don't wanna,

26:56 you know, go into this too much. It's not really what we're trying to cover, but, like, this feels like something system d could solve using their triggers. Like, when this process comes up, then go and, you know, write this manifest as directory if it doesn't exist. Yes. Possibly. I mean so things like cluster API vSphere, that will they've added now some webhooks in there, I think, which will generate just static manifest YAML as part of the deployment of new cluster API vSphere VMs. So they've actually taken the instantiation part and added that into their provider themselves.

27:37 So there are a number of different ways to do it. It's just kube-vip needs to come up before kube-adm init finishes. But Kubernetes isn't up before kube- ADM and it starts and things like that. So you need to find your way into the middle of the process one way or another. Right. Okay. That sounds too complicated. I'm gonna just pretend and say, cool. Yeah. Good luck fixing that. So let's talk about the second part of give that plan. Okay. As as a load balancer. Right? Yes. So this largely works in the same way. So these are gonna be a little bit hard

28:22 to see. We really, really need to focus on the main window here. I have a a five node cluster that's up and running with two control two two worker nodes and and three control plane nodes. They've been brought up in the same same way. The only real difference here is these machines aren't on packet. So the control play notes are simply using ARP for that. However, the main part that we're gonna be looking at really is deploying an application and then using kube-vip to advertise it in the same manner. So relatively straightforward. I shouldn't have to use my own code,

29:07 but I'm actually having to get the docs up at this point. So if you go to kubevip.io actually, I can pop it here, I think. If we actually go to the main website itself Nice logo. We got to judge every project by its logo. Absolutely. So there is documentation for either doing the control plane load balancer, which as I mentioned is one additional step to kube-eighty m in it. And then actually doing a a Kubernetes service type load balancer. The load balancer part is a little bit more involved in that we need to deploy a couple of manifests.

29:50 And the reason being is, I guess, there's a few things that we need to kind of consider when doing service type load balancer. The main part really is the fact that we we basically need a a CCM, cloud controller, Because the cloud controller is the component inside the Kubernetes cluster that will sit and listen for things like service type load balances. And it's the cloud controller which would speak to something in order to actually set that load balancer up. So for instance, in AWS, the CCM will more than likely speak to, you know, your elastic IP service,

30:34 provision that elastic IP, you know, kind of do all of the plumbing to bring that traffic back into your Kubernetes cluster and whatnot. We need to do the same with kube-vip. So what I'm gonna do though so these are the two manifests that actually will just get you running out of the box. I've actually been working on some additional functionality which may break probably will break. Controller DHCP. So this is some this is a suggestion by a colleague when I was at VMware who wanted to be able to do service type load balancer, but for, like, home networks

31:25 where they didn't really want to have to worry about managing their own IPs and and whatnot. So this will we'll go through the normal steps, then hopefully, we'll be able to demo this as well. But what we've actually done here is we've created we've we've applied two manifests. The first manifest will deploy the plunder cloud provider. So this now will take this cluster. And when somebody wants to deploy a service type load balancer, that cloud controller will basically handle all of the bits that are actually required to do that. The second manifest is the manifest that deploys

32:09 kube-vip within within a cluster itself. And the architecture for this is a little bit funny. I've got a diagram of it somewhere. Here we go. I don't know if this will be visible or not. But the way that it kind of works is that you typically will deploy a kube vip cluster inside a a namespace. What this allows you to do is to specify a side arrange for that namespace. A file option? Oh. No. It's not here. I'm just I'm just reading this diagram and Okay. So, basically, this allows us to use a different network range

33:00 for each namespace. It it it also allows us to kind of have segregation based upon network configuration in a particular namespace as well. In the deployment that we've done here, we've just deployed kube-vip in the default namespace. We should be able to see this. So what's also happening here is the I I I can't remember why I did this, but the the manifest for kube-vip will always attempt to deploy three instances at least. But I've only got two nodes here, and there was logic in the manifest to stop to kube-vip instances sitting on the same node. That's

33:51 why we have a a a one that's left in pending. If I were to add an extra node an extra worker, then it would just deploy on that that additional worker. So we've got kube-vip up and running. What we will do now is we will let shrink it down a little bit. Do something quite obvious. We will we'll deploy we'll create a quick deployment. So we're doing an NGINX deployment, which shouldn't take long to come up. And finally, let me just check the namespace. So one of the other ways that this works as well is

34:42 it uses a config map in the cube system namespace, which is where the cloud controller lives. So that whoever is admin of the cluster defines the network ranges that kube-vip can run-in a particular namespace. We can see here. So the way that it works is the network range space and then the namespace. So in the default namespace, if I were to do a expose of service type load balancer, this is the network range that those IP addresses can actually come from. So in in this config map, you typically say that perhaps in my namespace finance,

35:00 Load balancing Kubernetes services using a LoadBalancer service (DHCP and BGP)

35:28 they get a side arrange of these 10 IP addresses. In in my debug or development environment, they may have a hundred IP addresses in this particular subnet and things like that. So the final step so we we we have kube-vip up and running. So now you're gonna load balance those two engine x pods. Right? Yes. There we go. So what we're gonna do, we will expose those And there we go. What's happened here is that the cloud provider will have looked up the the range in the in the config map. It will have found an available IP address.

36:21 So IPAM is also managed by the cloud controller. It will find a free IP address. All of them will have been free at this point, but it will have then selected the first IP address in that side arrange. And it will then use that IP address. Kube vip is told that that is the vip for the load balancer. So it will then take care of using up to broadcast that whichever is the leader vip instance now has this IP address. And if we hit this IP address, we should go through to one of the NGINX instances.

37:05 So that has basically used the same technologies that we talked about earlier. These are the layer two technologies to advertise an internal IP address that the rest of the network can access that will load balance back to those instances underneath. So some additional things I'm looking at are adding BGP into this part of it. It's a little bit more complicated in that we're not really gonna be in charge of the IP ranges in most places in most cases. So we'll I'll need to have some logic in there, but it's certainly doable. All of the code already exists.

37:47 And the other thing that I was hoping to demonstrate, if I can remember the right line for it, is because you mentioned some sort of DHCP stuff. Right? Or if that or is that already what's happening with the this load balancer IP address? No. The so the IP address that was allocated, that 201, that came from the the cloud controller. Here it is. So this I can't this might work. And let's give the name dash DHCP. Right. What was done there? Nope. I need to give it the that's the name of the deployment. Our load

38:48 balance will be called dash d h c p. Right there also. Right. Okay. So what I've done here is we've specified a load balancer IP of 0000, which obviously is a kind of a nonsensical IP address. And if I've gotten the right image downloaded, was in a bit of a rush. What will actually have happened is that instead of the cloud provider looking at the cider range and finding an IP address that is available, that the kube vip instance that was the leader will have actually done a DHCP request from the network that it's on,

39:34 which the the idea behind this is kind of edge environments where we don't wanna worry about IPAM. We basically may have a tiny Kubernetes cluster that sits under a small router somewhere. And we can basically just have the router use DHCP leases and apply those into our load balancer instance. Nice. Oh, it's not worked. Maybe I've got the wrong pods downloaded. If it had worked That'd be impressive. Yeah. If it had worked, we would have had the the DHCP IP address here, not the 000. Damn it. Live demos. Okay. That's okay. I should give the script to figure it

40:25 out. Oh, you're gonna try and fix it. Oh. Live live debugging. I've got the wrong interface. It's ends 160, and then my config is wrong. Oh. That's what's wrong. So it's it's basically if my config had have been right, what would have happened is that it would have done a DHCP request on that interface, and we wouldn't have had this issue. If we have time, I can probably try and fix it. If not, it's not really the end of the world. It's a config issue, not not my code apparently. But Yeah. Yeah. Yeah. There we go. Excellent.

41:09 So yeah. That's So that allows you to have kubernetes sorry. I'm kinda talking over there. That allows you to have services which register themselves on the the the physical network. Right? That's kind of what this is doing. Yeah. Absolutely. That service would be available to anything on my network whether it's part of the Kubernetes cluster or not. Yes. Absolutely. So the the the person who came up with this idea was, yeah, just for for, like, home lab usage. Instead of having to worry about, you know, kind of coming up with IP addresses and whatnot, the the plan was that

41:48 DHCP that already exists in the building of from his ADSL router, it basically, if I do an expose and pass the IP address, then, you know, my router will give me an IP address on the network. And I don't really have to care about it. I'll just get the IP address to get services. And that router supplied IP address is my load balancer IP address. Very, very cool. I like it. So I guess the the big scary question I've got there is everything you're showing so far is IPv four. Run. What's what's this the status of I p

42:31 v six? Is is that's still applicable? Is this still something that you want to support? Does this support you? Or it doesn't support already? I have not even tested I p v six at this point. As I mentioned, this is mainly been to kind of scratch an itch internally, and I I don't really have any I p v six in my house really to test this. And the people that are starting to use this, nobody has actually raised a requirement for I p v six at the moment. However, all of the things that it's actually doing,

43:09 there shouldn't be any real reason why it would be an issue to implement I p v six support. Okay. Maybe that's something I'll try and okay. Maybe spin up a cluster. Is that a hack and pack? We'll try to I p v six only. I think there is some some of the Go API. Some of the Go calls are maybe IPv four specific. I can't remember off the top of my head. And for the BGP stuff, it is specifically doing IPv four routes that it's adding. So that definitely will would result in an error off the top of my head. But as

43:51 I mentioned, I don't see I don't see why not. It's just not been done. That's all. Alright. That's awesome. There is a lot to take in there, but that is all very, very cool. What's coming next? What's next on the plunder head list? So there's a couple of things that have been suggested by a couple of colleagues that are are basically kind of half implemented and should be coming in in next release. One is UPnP. So what that means is that if we do a kube-ctl expose again, these are kind of like home or edge networks and things

44:28 like that. And we enable that. The the ports that we specify as part of the expose would also be specified on your router. So you could do a kube-ctl expose port one eighty eighty, and your router would port forward immediately to the kube-vip instance in your Kubernetes cluster. So you could expose a service at home to the Internet using UPnP. Okay. And finally I'd I'd I do. Does that that make sense? Yeah. I think I'm just catching up with you. I'm just I'm just thinking about it. So yeah. So it's it's basically normally, if you had

45:13 a service inside your house, you would need to go to your router and enable port forwarding. But the majority of home routers typically will support UPNP, which would allow us to basically broadcast one of the whichever kube-vip instances leader will broadcast this port. I wanna expose it via UPnP back to myself, and UPnP will take care of the port forwarding automatically. So a kube-ctl expose will automatically tell your home router, open this port on your firewall, and incoming traffic on that port should also come to this kube-vip instance. So Ah, I get it. I get it.

45:56 Okay. And what do you know? It just took a bit longer than most. A multicast DNS as well was something I was thinking about implementing. So we could expose a service and we would m DNS it. So a bit like Bonjour well, exactly like Bonjour services and things like that. A service would be advertised on the network. Your load balance service will be advertised through multicast DNS. Not entirely sure who or anybody would ever use that, but I don't know. I was I was coming up with a bunch of random ideas one night, that just seemed like something to implement

46:33 as well. Alright. Random ideas are the best ideas. Yeah. Absolutely. And then maybe IPv6. So Yeah. Definitely IPv6 because, you know, IPv4 is we're done with that. Right? The whole world is IPv6 now. That's what I hear. So we got two comments. So Bradley said sweet. I think that was on the u m p UPnP stuff. But he also asked a question. And I think we're just jumping back maybe five minutes now. But what he says is, am I right in thinking that your router would be able to handle a DHCP request from the controller

47:07 and assign your machine another IP address? So I guess this is the DHCP support that he's referencing here. So it it really does need a diagram because it's a little bit hard to explain. But what what would actually happen what should have happened is the when you specify an expose and you want to use DHCP, kube-vip will basically run a DHCP server requesting another IP address on the network. It will create an additional interface within the host that's the leader, and it will bind the lease, your DHCP IP address to to that additional interface. So

47:54 we have your eth 0. You can have ETH 0 colon zero, ETH zero colon one. These are additional stacks, TCP stacks that live on the same physical interface. So we can broadcast from the physical interface and then bind that configuration to a kind of pseudo adapter, which will take care of handling the traffic and passing it back to kube-vip and pass that then to the pods that sit underneath. So effectively, you know, kind of the same way a virtual machine would spin up a virtual Ethernet adapter and do a DHCP request. We're kinda doing something similar

48:30 with kube-vip, but we're basically just spinning up a it's a a Mac v tap that we're actually using in order to do a layer two. I want a DHCP address, and it will then take care of assigning that and doing what it needs to do. Okay. I understood some of that. Wonderful. Sorry. Have to. Documentation is solely lacking, unfortunately. Probably, I just asked one more question then. He's asking, can you use zero conf? I don't know what that is. For the DNS multicast. It's a good question. I I so I mean, zero conf normally is

49:12 when something boots up for the first time, it will do kind of some level of request on the network for configuration information. So some switches will do zero confident. You turn them on for the first time, and they will pull their config from somewhere. I'm not sure how that would. The the idea for the the the I was looking up for MDNS was basically I would do an expose of my NGINX and anything that uses an MDNS looker would be able to find that on the network, get its IP address, and suddenly start speaking to it. So it's

49:49 it's in my head, I was gonna use it as another way of kind of service discovery. Alright. Okay. Cool. I think that handles all of our questions. Do you have any closing thoughts that you'd like to finish up? No. Not so far. I'm if anybody has any suggestions or or things that they would like to see implemented, then feel free. I'm always kind of looking for new things to implement and kind of fiddle with. Yeah. You know, it's out there. If you wanna use it, go for it. If you've got any feedback, I'd love to hear it.

50:33 Alright. Well, thank you very much, pulsing circle, Dan. It's been an absolute pleasure. I have learned a ton. So thank you very much for joining me. That was it was really cool. I enjoyed that. Thank you. Alright. Have a nice day. I'll speak to you all soon. Thanks. Bye.