21–30 of 229 posts
Be careful with Hetzner, they null routed my game server on launch day due to false positives from their abuse system, and then took 3 days for their support team to re-enable traffic. By that point I had already moved to a different provider of course.
When I worked in web hosting (more than 10 years ago), we would constantly be blackholeing Hetzner IPs due to bad behavior. Same with every other budget/cheap vm provider. For us, it had nothing to do with geo databases, just behavior. You get what you pay for, and all that.
Any free hosting service will be overwhelmed by spammers and fraudsters. Cheap services the same but less so, and the more expensive they are the less they will be used for scams and spams.
Earlier quoted context omitted.
I'm a bit sad the aggressive comment by the new account was deleted :-( The comment was making fun of the wishful thinking and the realities of networking. It was a funny comment :-(
It wasn’t funny. I can still see it. The answer was vpn. If you want to go fancy you can do istio with vms.
https://tailscale.com/kb/1236/kubernetes-operator
They've even improved it, so you can now actually resolve the services etc via the tailnet dns
https://tailscale.com/learn/managing-access-to-kubernetes-wi...
I haven't tried that second part though, only read about it.
Earlier quoted context omitted.
It wasn’t funny. I can still see it. The answer was vpn. If you want to go fancy you can do istio with vms.
And if you wanna be lazy, there is a tailscale integration to run the cluster communication over it. https://tailscale.com/kb/1236/kubernetes-operator They've even improved it, so you can now actually resolve the services etc via the tailnet dns https://tailscale.com/learn/managing-access-to-kubernetes-wi... I haven't tried that second part though, only read about it.
> Hetzner volumes are, in my experience, too slow for a production database. While you may in the past have had a good experience running customer-facing databases on AWS EBS, with Hetzner's volumes we were seeing >50ms of IOWAIT with very low IOPS. There is a surprisingly easy way to address this issue: use (ridiculously cheap) Hetzner metal machines as nodes. The ones with nvme storage offer excellent performance f…
There are just pinning the database pods to specific nodes and using a LocalPathProvisioner or distributed solutions like JuiceFS, OpenEBS etc.
Earlier quoted context omitted.
It wasn’t funny. I can still see it. The answer was vpn. If you want to go fancy you can do istio with vms.
And if you wanna be lazy, there is a tailscale integration to run the cluster communication over it. https://tailscale.com/kb/1236/kubernetes-operator They've even improved it, so you can now actually resolve the services etc via the tailnet dns https://tailscale.com/learn/managing-access-to-kubernetes-wi... I haven't tried that second part though, only read about it.
you can't just slap an overlay on and expect everything to work in a reliable and performant manner. yes, it will work for your initial tests, but then shit gets real when you find that the route from datacenter a to datacenter b is asymmetric and/or shifts between providers, altering site to site performance on a regular basis.
the concept of bursting into on-prem is the most offensive bit about the original comment. when your site traffic is at its highest, you're going to add an extra network hop and proxy into the mix with a subset of your traffic getting shipped off to another datacenter over internet quality links.
Very nicely written article. I’m also running a k8s cluster but on bare metal and qemu-kvms for the base load. Wonder why you would chose VMs instead of bare metal if you looking for cost optimisation (additional overhead maybe?), could you share more about this or did I miss it?
I’m planning on doing something similar but want to use Talos with bare metal machines. I suspect to see similar price reductions from our current EKS bill.
It took minutes to setup a cluster and I love having a UI to see what is happening.
I wish there were more products like this as I suspect there will be a trend towards more self-managed Kubernetes clusters given how expensive the cloud is becoming.
I loved the article. Insightful, and packed with real world applications. What a gem. I have a side-question pertaining to cost-cutting with Kubernetes. I've been musing over the idea of setting up Kubernetes clusters similar to these ones but mixing on-premises nodes with nodes from the cloud provider. The setup would be something like: - vCPUs for bursty workloads, - bare metal nodes for the performance-oriented wo…
Sidero Omni have done this: https://omni.siderolabs.com
They run a Wireguard network between the nodes so you can have a mix of on-premise and cloud within one cluster. Works really well but unfortunately is a commercial product with a pricing model that is a little inflexible.
But at least it shows it's technically possible so maybe open source options exist.