81–90 of 180 posts
There's so much power on the platform with Flycast, LiteFS and other clever ways to work with containers. If it was 90% stable I'd consider it a huge win.
Why should one use kubernetes? Or rather, at what point of an apps growth cycle does k8s become appropriate?
That said, it's a questionable design choice when you get to a hyperscale environment, since all the primitives are extremely opinionated and have design and scalability issues with service discovery, networking, and so on. All the controllers had to be rewritten, we had to roll our own deployment system, our own service discovery system, our own load balancing, and so on. But if you reach this level, you're probably making a lot of money and can figure out how to solve your problems.
This is one of the biggest footguns of a tech company I've seen in the last decade. Time will tell if embracing the complexity of Kubernetes was a good play for them or not. But, in all honesty, I'm pretty sad to see this happening, although I'm sure they had their reasons.
This is one of the biggest footguns of a tech company I've seen in the last decade. Time will tell if embracing the complexity of Kubernetes was a good play for them or not. But, in all honesty, I'm pretty sad to see this happening, although I'm sure they had their reasons.
We don't use k8s and you don't have to either. This is for current and future users who absolutely want k8s. We are a compute provider after all and making it easy to host a great variety of apps is good for our users.
Am I understanding correctly that because they map a “Pod” to a “Fly Machine”, there’s no intermediate “Node” concept? If so, this is very attractive. When using GKS, we had to do a lot of work to get our Node utilization (the percent of resources we had reserve on a VM actually occupied by pods) to be higher than 50%. Curios what happens when you run “kubectl get nodes” - does it lie to you, or call each region one…
> Had to do a lot of work to get node utilization ... higher than 50% How is this the schedulers fault? Is this not just your resource requests being wildly off? Mapping directly to a "fly machine" just means your "fly machine" utilization will be low
Someone else linked GKE Autopilot which manages all of that for you. So if you’re using GKE I don’t see much improvement, since you lose out on k8s features like persistent volumes and DaemonSets.
This is one of the biggest footguns of a tech company I've seen in the last decade. Time will tell if embracing the complexity of Kubernetes was a good play for them or not. But, in all honesty, I'm pretty sad to see this happening, although I'm sure they had their reasons.
Kubernetes is really epic and powerful if you actually take the time to understand it from first principles. Unfortunately people don't do this, and individuals without good networking/devops experience roll something half-baked out with a terrible deployment process, a mess of helm charts, etc... and it ends up being hated by everyone. At FarmLogs (yc 12) we had a pretty righteous gitops (homegrown) kube platform ru…
I've also used Chef, custom RPM packages and classic Unix startup scripts. And I'm probably forgetting some.
And honestly? Kubernetes can be really great. Especially if you:
- Read enough to understand the split between pods/replication controllers/deployments, which is a bit unusual, and the fact that "services" are basically a name lookup system. This split is weird, but it's not that hard to figure out.
- Pay someone for a quality managed Kubernetes.
- Don't get clever with the networking overlays.
I especially like the way that Kubernetes allows me to deploy almost anything with a short YAML file, and the fact that I never need to worry about individual servers at all.
Now, I wouldn't use Kubernetes if I could get away with a "Heroku like" system. But for anything more complicated than that, Kubernetes can be pretty simple and reliable. Certainly I'd take Kubernetes over a really complex Terraform setup.
I don't know why would anyone would be like "here's a container execution platform, let me go ahead and use their fake Pods API instead of their official API".
> When you create a cluster, we run K3s and the Virtual Kubelet on a single Fly Machine.
Why a single machine? Is it because this single fly machine is itself orchestrated by your control plane (Nomad)?
> ...we built our own Rust-based TLS-terminating Anycast proxy (and designed a WireGuard/IPv6-based private network system based on eBPF). But the ideas are the same.
very cool, is this similar to how Cilium works?
Man, I just wish they'd work on stability. Fly.io is an amazing offering. But it's so buggy, it's almost more headache than it's worth trying to build PaaS-flavored software on it. Even the Fly docs are "buggy" since they mostly transitioned to v2 Machines but the docs are still a mix of Nomad and Machines. There's so much power on the platform with Flycast, LiteFS and other clever ways to work with containers. If it…
Once you start deploying in SIN/CDG etc you start to get really weird instability (and this is on v2 machines).