This could all be solved using HE.net tunnel broker for free…
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.
101–105 of 105 posts
This could all be solved using HE.net tunnel broker for free…
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.
Kubernetes admin here with ~2y experience. Since a lot of you have misconception of what this guy is doing I will try to explain. Author wrote a piece of code which will interact with network gateway to get IPv4/IPv6 network address and then update kubernetes configuration accordingly from within a container running on said cluster. That seems to be needed, because MetalLB component in use exposes kubernetes deployme…
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 is in total control over my external IP addresses. I don’t pay for permanent IP addresses, and while they haven’t so far changed neither my IPv4 address or my IPv6 network, it can happen. Probably by mistake, since I have no kept my current ones for three months" If you can't shell a buck or persuade your isp to reserve a static ip for you. Try to persuade their dhcp server. https://datatracker.ietf.org/doc/h…
It's really concerning that we have people trying to use tools like Kubernetes without understanding the basics that underlie them, like networking. Post author should read Beej's Guide to Network Programming and come back when that's comfortable for them.
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 for the post. I ran into the same issue with assigning IPv6 addresses to k8s pods. Wish there were easier solutions to handle the prefix changing.
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.
Crazy that someone is using something as complex as k8s on a home server and without knowing basics. Newbies are better served starting with the simple stuff and then moving to the complex if needed