(Justin)
Tech nerd from Sweden
Self hosting can save a lot of money compared to Google or aws. Also, self hosting doesn’t make you vulnerable to DDOS, you can be DDOSed even without a home server.
You don’t need VLANs to keep your network secure, but you should make sure than any self hosted service isn’t unnecessarily opens up tot he internet, and make sure that all your services are up to date.
What services are you planning to run? I could help suggest a threat model and security policy.
I’m using IPv6 on Kubernetes and it’s amazing. Every Pod has its own global IP address. There is no NAT and no giant ARP routing table slowing down the other computers on my network. Each of my nodes announces a /112 for itself to my router, allowing it to give addresses to over 65k pods. There is no feasible limit to the amount of IP addresses I could assign to my containers and load balancers, and no routing overhead. I have no need for port forwarding on my router or worrying about dynamic IPs, since I just have a /80 block with no firewall that I assign to my public facing load balancers.
Of course, I only have around 300 pods on my cluster, and realistically, it’s not really possible for there to be over 1 million containers in current kubernetes clusters, due to other limitations. But it is still a huge upgrade in reducing overhead and complexity, and increasing scale.
I haven’t really looked into it, but it doesn’t seem like it.
Heres the documentation about having multiple cidr pools in one cluster with the Cilium network driver, and it seems to imply that each Pod only gets one IP.
https://docs.cilium.io/en/stable/network/concepts/ipam/multi-pool/
There’s something called Multus that I haven’t looked into, but even then it looks like that is for multiple interfaces per Pod, not multiple IPS per interface.
https://github.com/k8snetworkplumbingwg/multus-cni
Containers are just network namespaces on Linux, and all the routing is done in iptables or ebpf, so it’s theoretically possible to have multiple IP addresses, but doesn’t look like anybody has started implementing it. There’s actually a lot of Kubernetes clusters that just use stateful IPv6 NAT for the internal Pod network, unfortunately.
Yeah, I wonder if there’s any proposals to allow for multiple IPV6 addresses in Kubernetes, it would be a much better solution than NAT.
As far as I know, it’s currently not possible. Every container/Pod receives a single IPv4 and/or IPv6 address on creation from the networking driver.
I have static IPs for my Kubernetes nodes, and I actually use DHCPv6 for dynamic dns so I can reach any device with a hostname, even though most of my devices don’t have static IPs.
The issue is those static IPs are tied to my current ISP, preventing me from changing ISPs without deleting my entire Kubernetes cluster.
Hurricane Electric gives me a /48.
Site-local ipv6 would work here as well, true. But then my containers wouldnt have internet access. Kubernetes containers use Ipam with a single subnet, they can’t use SLAAC.
1:1 stateless NAT is useful for static IPs. Since all your addresses are otherwise global, if you need to switch providers or give up your /64, then you’ll need to re-address your static addresses. Instead, you can give your machines static private IPs, and just translate the prefix when going through NAT. It’s a lot less horrible than IPv4 NAT since there’s no connection tracking needed.
This is something I probably should have done setting up my home Kubernetes cluster. My current IPv6 prefix is from Hurricane Electric, and if my ISP ever gives me a real IPv6 prefix, I will have to delete the entire cluster and recreate it with the new prefix.
yeah, Id recommend switching on your secondary machine, so you can try it out and use it properly, but not get frustrated if it does something you don’t expect.
It’s an algorithm for determining how fast to upload packets. This article just talks about how to enable it.
Here’s the Wikipedia section about it: https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
The gist is that instead of only throttling upload rate based on packet loss, BBR constantly measures roundtrip delay (ping) to determine how much bandwidth is available.
Yeah, there’s definitely a learning curve since it’s so different from docker, but there are some good tutorials and everything just makes sense. All the error messages are googlable and everything fits together so well.
Kubernetes has user accounts that you could use to restart containers in an unprivileged way. Create a role and role binding that gives the “delete Pod” permission to a service account. Kind makes it very easy to run Kubernetes without any setup. You’d just need to convert your docker compose files to Deployments, Services, and PersistentVolumes.
If converting to a kubernetes setup is too big of a leap, you could maybe try to write a C program that uses setuid to gain docker privileges in a restricted way.
Probably easiest to just have a cronjob that restarts the container regularly, though.
Your internet/wifi seems really overloaded, average ping rtt should be under 100ms, not 712ms. Your wifi signal might be bad, a computer may be downloading/uploading a lot of data, or there is an issue with your internet line.
Double check your wifi signal and computer traffic, maybe try using a direct wired ethernet connection and disconnecting all other computers. Otherwise, contact your ISP with these ping results and speed results from speedtest.net.
Check for PSI stalling in htop (add PSI meters for cpu, ram, and io in the config menu), to rule out your system being overloaded. Check internet connectivity with ping 1.1.1.1, and see why registry is timing out with curl -v https://registry-1.docker.io/v2/
You can also test your dns servers if you think that they are an issue with
dig registry-1.docker.io @1.1.1.1
dig registry-1.docker.io @194.168.4.100
If the dig command outputs differ from each other, then it is likely that your ISP’s DNS servers are faulty and you should switch nameservers to 1.1.1.1 and 1.0.0.1 like the other commenter said.
docker compose isn’t really scalable. If you need automatic, hgih availability load balancing, you should look into Kubernetes Ingress.
FreeOTP+ is a good TOTP app for mobile, if anybody is looking for a TOTP app. It’s a FOSS fork extending an internal Red Hat app. https://f-droid.org/packages/org.liberty.android.freeotpplus/
nixos unstable had it too: https://github.com/NixOS/nixpkgs/pull/300028
I’m not an economics major, but maybe something like a blind auction every year, and if you owned the domain last year, you also have the option of matching the highest bidder to keep the domain.
The biggest flaw with a system like that is that it would still discourage trying to buy an already owned domain, since you could pay for it, but not actually get it if the owner exercises their matching right. But it would definitely discourage domain squatting since the more other people want your domain, the more you have to pay to keep it.
There are admin overrides for those, I use them.
Coops are still about the money. They’re about saving money by sharing resources with fellow workers/consumers, and maintaining democratic control over the company. You’re not going to get rich from a coop (without embezzlement), but you and your coowners will be cutting out the middle man. Obviously, it only makes sense for industries that you’re heavily invested in.