Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fly Kubernetes

fly.io

Post reply on HN
Print view View original

111–120 of 180 posts

Re: Fly Kubernetes

#111

Post by philsnow »

kuhsaft wrote: post #73
philsnow wrote: post #60

Earlier quoted context omitted.

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)

I think the biggest hurdle would be networking between the pods since they will be running on different cloud providers.

I've seen some people using wireguard for intra-cluster networking so that all their nodes can run pretty much anywhere.

Re: Fly Kubernetes

#113

Post by nailer »

paxys wrote: post #19
verdverm wrote: post #2

If they are reluctant and only do it because they have to, are they really the right vendor for managed k8s? What about them makes for a good trade-off when considering the many other vendors?

Maybe a got fit for someone who is reluctant to use Kubernetes but has to for whatever reason.

If someone isn't a cloud provider they should be reluctant to use Kubernetes.

Re: Fly Kubernetes

#115

Post by verdverm »

kasey_junk wrote: post #91
verdverm wrote: post #30

Earlier quoted context omitted.

> We're not a K8s vendor It might now be more accurate to say "You were not a k8s vendor", but now you are based on > If K8s is important for your project, and that’s all that’s been holding you back from trying out Fly.io, we’ve spent the past several months building something for you. If it's fundamentally different, maybe you shouldn't call it Kubernetes, perhaps a Kubernetes API compatible alternative? fwiw/conte…

Are any of the cloud provided managed K8s offerings just K8s under the covers? I’ve always assumed all of them shim the K8s api onto other more bespoke orchestration systems.

Most are pretty much actually k8s, though they tend to have different ways of handling the masters, my understanding is that it's the same k8s binaries and code

What I've seen is the k8s APIs working their way into other systems like cloud functions and servers, so you can use the same Yaml across vendors and products. This is further solidifying k8s APIs as an industry standard

Searching "managed kubernetes providers" is a good starting point to learn about the various offerings

Re: Fly Kubernetes

#116

Post by philsnow »

kuhsaft wrote: post #67
philsnow wrote: post #60

Earlier quoted context omitted.

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)

I think it’s completely possible. Though, you’ll have to manage your own control-plane. 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

tensile-kube seems to be structured as a "k8s cluster of k8s clusters", with an upper kubemaster farming out resources to lower kubemasters (through virtual-node). I don't know if there's any particular reason to have that separation; possibly the lower kubemasters could be removed and you could just run a bunch of virtual-kubelets.

Re: Fly Kubernetes

#117

Post by xena »

syrusakbary wrote: post #108
jeromegn wrote: post #83

Earlier 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.

It seems I misunderstood the article. I'm happy to read this in any case, thanks for the follow up!

fly.io employee here, it's basically an adaptor from the Kubernetes world of YAML to the fly.io world of Machines. How could we have framed it better so that it was more clear?

Re: Fly Kubernetes

#118

Post by remram »

kuhsaft wrote: post #110

How 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 containe…

You can use mount namespaces, or even containers in your VM. Maybe that's how?

Re: Fly Kubernetes

#119

Post by thorawy7 »

I ditched k8s and imported an eBPF library into my project. When certain conditions are met I fork logic, and scale back as needed. I haz a v8-like engine built into my project.

Not needing a bloated black box sysadmin framework (aside from Linux itself, which is plenty bloated and over engineered) is a huge time saver. And the eBPF libs have a lot of eyes on them.

IMO sysadmin and devops are done for. They lasted this long to “create jobs”.

Re: Fly Kubernetes

#120

Post by verdverm »

nailer wrote: post #113
paxys wrote: post #19

Earlier quoted context omitted.

Maybe a got fit for someone who is reluctant to use Kubernetes but has to for whatever reason.

If someone isn't a cloud provider they should be reluctant to use Kubernetes.

Aren't most k8s users not cloud providers?

It's more about good abstractions and APIs for running applications in the cloud. Cloud providers are the one's offering the APIs and abstractions we use, and increasingly putting k8s abst/apis at the forefront, because that is where industry has moved to

Post reply on HN