171–180 of 180 posts
Earlier quoted context omitted.
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
Yes. The point still stands.
Earlier quoted context omitted.
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
> Aren't most k8s users not cloud providers? Yes. The point still stands.
Can you explain why we should be reluctant to use k8s?
Earlier quoted context omitted.
> Aren't most k8s users not cloud providers? Yes. The point still stands.
People and companies use it because it makes this easier in several areas, it's industry standard at this point. Can you explain why we should be reluctant to use k8s?
Compute on demand is significantly more complex using k8s than what most companies already pay for from their own cloud provider, AWS is the industry standard for this purpose, followed by Azure, then TF, then Pulumi maybe.
k8s is a meme for resume-driven development.
Earlier quoted context omitted.
People and companies use it because it makes this easier in several areas, it's industry standard at this point. Can you explain why we should be reluctant to use k8s?
> People and companies use it because it makes this easier in several areas Compute on demand is significantly more complex using k8s than what most companies already pay for from their own cloud provider, AWS is the industry standard for this purpose, followed by Azure, then TF, then Pulumi maybe. k8s is a meme for resume-driven development.
Earlier quoted context omitted.
You're basically describing Kubernetes and why it has become so popular
K8s is the opposite. It's proprietary, insular, not compatible with anything else, tightly coupled, not layered, not backwards compatible, etc. It has network services, logging, auth, etc, but so does literally every other system in the world, that doesn't make them all identical. K8s is popular because it's free, has a lot of bells and whistles, and was made by Google. Otherwise nobody would use it. It's basically a…
Is this a joke post? It's literally the opposite of all those things
I like the discussion on scheduling. One of the things I've thought recently is that, since there's no one model of how an app or system should work, nor one network architecture, there shouldn't be one scheduler. Instead, I think the system components should expose themselves as independent entities, and grant other system components the ability to use them under criteria. With this model, any software which can use…
You're basically describing Kubernetes and why it has become so popular
Earlier quoted context omitted.
The problem is not the need to bin-pack, the problem is completeness. Sidecars and multiple containers are used for logging, backups, etc. Not to mention that if you grab a manifest or chart for an app, it is going to have pods with multiple containers (whether that's strictly needed or not), and those won't work on fly.io. This is a critical feature available in every Kubernetes offering, and as such people rely on…
Again: Fly Machines are just Linux VMs, and you have root on them.
Earlier quoted context omitted.
> People and companies use it because it makes this easier in several areas Compute on demand is significantly more complex using k8s than what most companies already pay for from their own cloud provider, AWS is the industry standard for this purpose, followed by Azure, then TF, then Pulumi maybe. k8s is a meme for resume-driven development.
Ok, you're obviously just a hater and aren't worth taking seriously
Earlier quoted context omitted.
Right, but what is the point of FKS then? It’s no longer Kubernetes if it doesn’t support a core behavior of Kubernetes. If you only support deploying single containers with single processes on FKS, then you might as well use flyctl. It’s a solvable issue of course. The virtual-kubelet implementation would need to create a Machine running a container runtime image that would then run a the pod containers to match the…
We're actively working on the ability to run multiple processes with different images because it's something people using our platform want and it just happens to also be something needed for us to make FKS a more standardized Kubernetes offering.
Kata has a guest image and guest agent to run multiple isolated containers [1].
[0] https://katacontainers.io/
[1] https://github.com/kata-containers/kata-containers/blob/main...
Earlier quoted context omitted.
Widely? I lived in this helm, kubernetes, pulumi world the past 4 years and we followed the simple rule of one service/container per pod. Why add complexity where it’s not needed. Like running a dB a and a service in the same docker container - a no go for me and many.
The thing is you might not be adding the sidecars yourself. Kubernetes has a resource called MutatingAdmissionWebhook that allows mutations of the Pod object before creation. I think the most common use case is for service meshes. Your Deployment might not have any sidecars, but the service mesh controller will automatically add a network proxy container to your pod via the admission webhook. Another use case would b…