61–70 of 180 posts
And fly becomes the standard cloud provider like everyone else. I think this transition is only natural. It's hard to be a big business without catering to the needs of larger companies and that is the operation of many services, not individual apps.
> But, come on: you never took us too seriously about K8s, right? What a strange way to admit they were wrong.
Is this still a limitation for Fly k8s? > A Fly Volume is a slice of an NVMe drive on the physical server your Fly App runs on. It’s tied to that hardware. Does the k8s have any kind of storage provisioning that allows pods with persistent storage (e.g. databases) to just do their thing without me worrying about it or do I still need to handle disks potentially vanishing? I think this is the only hold-up that stops m…
Why should one use kubernetes? Or rather, at what point of an apps growth cycle does k8s become appropriate?
Earlier quoted context omitted.
The node would be a virtual-kubelet. You can check out the virtual-kubelet GitHub repo for more info. Interestingly, there are already multiple providers of virtual-kubelet. For example, Azure AKS has virtual nodes where pods are Azure Container Instances. There’s even a Nomad provider. > So that’s what we do. When you create a cluster, we run K3s and the Virtual Kubelet on a single Fly Machine. So probably a cluster…
The diagram on https://virtual-kubelet.io/docs/architecture/ makes me wonder whether it's possible to have a k8s cluster where the nodes are all virtual kubelets backed by different cloud providers (and then perhaps schedule loads preferentially with selectors)
Azure AKS and EKS provide virtual-kubelet functionality in some form, but AKS is an a managed control-plane where you can’t add nodes yourself and EKS only allows nodes in the same VPC.
Edit: It already is a thing. https://github.com/virtual-kubelet/tensile-kube
Earlier quoted context omitted.
I wonder how it copes with things like anti-affinity rules, where you don't want two things running on the same physical / virtual server for resilience reasons.
You wouldn’t use affinity rules anymore. The pods are scheduled on a single virtual-kubelet node, so if you use anti-affinity scheduling would fail.
Why should one use kubernetes? Or rather, at what point of an apps growth cycle does k8s become appropriate?
Kubernetes is a great fit for even extremely simple applications - assuming you have dozens to keep track of and dozens of developers who want to make changes to them.