vegarde
I run K3s, and it's not supported to change the internal ranges after creating the cluster.
On the ingress, i.e. with metalLB, it's different, of course. And that is what my solution is for.
I'm going to improve it in the coming weeks. It's not going to be any easier, though, it will just be more fun for me :) (I like to learn new stuff).
It's probably going to be a bit more robust and logical, though, not look as hacked-together than my current script. But unless I actually get around to making a plugin architecture for it, it's still going to assume you're using a Unifi gateway.
I know my way around networking, I know that my networking equipment will always try to request the same IP address/IPV6 range. But I can't do shit with it if my ISP has lost my reservation and given that to someone else.
And as numerous other comments here have shown, some ISPs are incompetent bordering on malicious, but sometimes, they're the best you have. My ISP is pretty decent, but that doesn't keep me from playing with "what if"-scenarios and solve things that may not ever happen for me.
I learnt something from it - not the core networking stuff, there is nothing in that that was new to me, but I leart a lot about how to do things more dynamically in Kubernetes, and I had to dig into the APIs of my router to achieve what I needed.
However, when I write a blog post, I also try to assume not everyone has a deep understanding of the things. If someone read my blog post and just then learnt about IPv6 addressing, that's great! Then they too would have learnt some things, even if Kubernetes is not for them.
Thanks. If I was a company, I would probably be in control over when my IPv6 range changes. And if my ISP is any good (I just recently switched to it), my IPv6 network should stay the same.
The network range in a home setting is always given by your ISP, most likely with DHCPV6 prefix delegation, very rarely do you in a home setting dish out for a permanent IPv6 network range. Granted, most decent ISPs try to persist it, since there's no good reasons not to, and it's a strong recommendation from standardization bodies etc. But it's still just best effort, accidents happen, state get lost, and suddently you have a different network.
Sure, it's probably take me less than an hour to just change everything, but we are hackers here, so what's the fun in that? At least I gravitate towards perfecting things even beyong pure needs, just because I can. At work, I have to call it a day when it gives no more significant gain, at home I am free to think "this is fine, but can I actually do it better?". If the answer is yes, and you have the time, I'd say go for it. Some people like to watch cat videos on Youtube, I prefer to tinker with getting stuff to work. Sometimes it's useful, sometimes it's just for the fun of it.
I'm on my way to improve this, by the way. I plan to create a Unifi Networking Operator that can help me not only this, but to configure my Unifi Gateway and firewall rules through Kubernetes properties. It will be more logical to let my "dynamic IP" setup just change Kubernetes properties, and let the OPerator handling the Unifi Configuration of it.
Overkill? Hell, yes! Fun? For me, at least? Will I learn something? Yes, I will learn how to create a Kubernetes Operator!
Yeah, I'm a beginner in Kubernetes, but not in IT and sysadmining in general, I've got 30 years experience there. For now, Kubernetes is a just-for-fun project at home, but it's used to run my day-to-day home services, which makes it even more fun to improve it. We use Kubernetes where I work, but not in my area, it's not inconcieveable that my home-tinkering will be of benefit at work, some day.
And yes. I run a personal blog (in my Kubernetes cluster). I try to make it a bit educational, with more or less repeatable experiments for people to pick and chose from.
Some will be good, some will probably be a bad idea. But as long as there's learnings to be had, it's worth doing.
My ISP gives me native IPv6. Granted, it hasn't changed yet. I am pretty sure it will, some day. Probably by an accident of mine or the ISP.
And I do.
I used to run a dynamic DNS service, but these days I prefer to do it myself towards the API of my DNS provider. External-DNS in k8s is pretty neat that way.
Changing the K8s resources automatically is not really a big deal. It's a fun exercise.
My Unifi Cloud Gateway Max doesn't (yet) support BGP, but other Unifi devices do, so I do hope that it'll come to my device to. If not, I'll have to think of other ways to test it. But in the meantime, there's plenty of other stuffs to learn.
I have a real, ISP-routed IPv6 net to play with.
The goal wasn't necessarily the result.
I like to tinker.
And well...my K8s cluster is only one node so far, so there's limits to what I can play with.
And please: No comments that K8s is overkill. I know, and I don't care :) There's things to learn from it, and that's good enough reason for me.
Of course I haven't mastered he fundamentals of K8s yet, I am just beginning to learn it.
Like you, I have been using docker for years, and to be honest it served me very well - and would probably continue to do so. But as a geek, I have a natural curiosity, sometimes just the curiosity of whether or not something can be done, and how it works, is enough justifications to do it.
As you probably read, this is in my home services. Which is where I am free to do exactly these experiments before I know the inns and outs of it.
Some of what I wrote in the blog post, I have already ditched. I am no longer hardcoding the ipv6 addresses from the pools, for example, but I still need to change my pool ip addresses if my ISP changes the range. I am not sure if my way is the correct one. I could do it manually, but what's the fun in that ?
There will be more blog posts as I learn, you be sure (there already is). I have more coming up, but one of my current projects will take a bit of time, as I have decided that writing a Unifi Operator for managing firewall rules is a better way to do it :)
Now, for home use? Whoever does that, write K8s Operators?
If you're on hacker news then you should understand that the goal isn't necessarily the result, it's the learning experience.
Yeah, I don't expect this to really change, either, in normal operations. But I'm a home user, I don't pay for a static IP address or a static IPV6 prefix.
But I'm a geek/hacker by heart, so curiosity sometimes get to me.
I did it because there was things to learn from it.
I do port forwarding for IPv4. But port forwarding on IPv6? You must be kidding me, the /56 I get from my ISP is meant to be used on the inside. It hasn't changed yet, and maybe it never will.
I am running Unifi as router, and they are claiming that the prefix IDs assigned to the networks won't change. But I have had it happen - probably through my own fault. Wish I could just hardcode the prefix. As for the metalLB IP addresses, since writing this I have done away with hardcoding the actual IP addresses and just let the pool assign them. It still means I need to update the firewall rules on my router, though, should they change. And my metalLB range would of course need to be updated.
The IPv4 is still hardcoded due to the port forwarding, and since it's private space that I won't change anyhow.
As for why I don't do it manually, you must be kidding me. You are. reading hacker news, and you question why people tinker with complex automations and just don't do it manually? Because I can of course, and that's the only reason I need.
I like to pretend like my home network matter, that I run a mission critical service.
I run services at home. Multiple. Because I can, and I like to learn. The blog runs at home, of course, even though hosted blog services have existed for years now. I also run Nextcloud. It saves me the cost of extra storage on Dropbox and/or Google Cloud, I do it to my home network instead. Then there's plex, home assistant plus all the other services a geek would like to run. They all run in my K8s cluster now. I was served well by docker for years, but I wanted to test K8s, and that was the only reason I needed.
And a cluster? Well, it's called that in Kubernetes. But in reality, it's only one node. Because two would be overkill for home usage.
To sum it up:
I did it because
1) I wanted to 2) I could 3) I would learn something from it 4) It would give a modest benefit.
It's all the reason I needed to.
As for why automating things I could do it manually should it happen, see 1, 2, 3 and 4 above.
And this, you want to do after significant adoption?
So, you are basically going to tell the Starbuckses and other large corporations that have built a large infrastructure around onchain transactions that they need to stop that, wait a few years until 2nd layers are adopted, and then start using that?