Well, that's a surprise. Glad to see that the team is flexible and willing to change. :)
Fly Kubernetes
101–110 of 180 posts
Re: Fly Kubernetes
#102Am 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…
GKE Autopilot is an attractive option here if you don't want to worry about node utilization and provisioning. Effectively you have an on-demand infinitely-sized k8s cluster that scales up and down as you need new pods. Some caveats, but it's an incredible onramp if you're coming from a Heroku or similar PaaS and don't want to worry about the infrastructure side of things: Github Actions building images and deploying…
If this is “free GKE autopilot” (autopilot billed at the same price as regular Fly Machine compute), then that changes the way I think about Fly’s basic compute pricing a lot.
I would think they should highlight that a lot more in the product announcement!
Re: Fly Kubernetes
#103I kind of miss the point of this. So if I'm reading this right, fly.io practically only exposes the Pods API, but Kubernetes is really much more than that. I'm not very familiar with any serious company that directly uses Pods API to launch containers, so if their reimplementation of Pods API is just a shim, and they're not going to be able to implement ever-growing set of features in Kubernetes Pod lifecycle/configu…
I think there’s potential here.
It is Kubernetes since they are running k3s as the control-plane. It’s not just an implementation of the Pod API, it’s an implementation of kubelet which handles logs/exec/etc APIs. The rest of the Kubernetes API is part of the control-plane on k3s.
The only major issue I see is persistent volume support, but persistent volumes in Kubernetes were always a bit flaky and I’ve always preferred to use an externally managed DB or storage solution.
Re: Fly Kubernetes
#104Earlier quoted context omitted.
GKE Autopilot is an attractive option here if you don't want to worry about node utilization and provisioning. Effectively you have an on-demand infinitely-sized k8s cluster that scales up and down as you need new pods. Some caveats, but it's an incredible onramp if you're coming from a Heroku or similar PaaS and don't want to worry about the infrastructure side of things: Github Actions building images and deploying…
If this is “free GKE autopilot” (autopilot billed at the same price as regular Fly Machine compute), then that changes the way I think about Fly’s basic compute pricing a lot. I would think they should highlight that a lot more in the product announcement!
Say more! What should we highlight more?
Re: Fly Kubernetes
#105Man, 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…
[deleted]
Re: Fly Kubernetes
#106Wen custom OS?
Re: Fly Kubernetes
#107Earlier quoted context omitted.
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.
We really didn't expect so many people to read this like "Fly is going all K8s"! It's interesting.
[deleted]
Re: Fly Kubernetes
#108This 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.
It seems I misunderstood the article. I'm happy to read this in any case, thanks for the follow up!
Re: Fly Kubernetes
#109Why should one use kubernetes? Or rather, at what point of an apps growth cycle does k8s become appropriate?
I'd say, not in an app's growth cycle, but when an organization wants to manage and scale platforms for itself, on which it runs apps, is when k8s becomes appropriate. In other words, k8s is a platform builder.
Re: Fly Kubernetes
#110How does this handle multiple containers for a Pod? In a container runtime k8s, containers within a pod share the same network namespace (same localhost) and possibly pid namespace.
The press release maps pods to machines, but provides no mapping of pod containers to a Fly.io concept.
Are multiple containers allowed? Do they share the same network namespace? Is sharing PID namespace optional?
Having multiple containers per pod is a core functionality of Kubernetes.