[chipdart]

> I'd say its 100% production ready.

That's fine. Some people also manually launch containers individually with Docker as their production system.

They'd be wasting their time and making their lives needlessly harder, though.

They already have tools that do all the legwork for them. Why not do the research and opt to force a square peg into a round hole?

Research Docker swarm mode, reverse proxies like Traefik, and Let's Encrypt. Kubernetes can be even easier with implementations like microk8s, which are a snap away from any Ubuntu installation. Look at what you're doing and figure out the right tool for the job. Don't just whine about how you're doing something wrong and it's the tool that needs to change to fix your own mistakes.

[wink]

Not sure what axe you have to grind, but the person you replied to didn't whine about anything as far as I can see. I've also been hosting a lot of stuff on docker-compose and it is perfectly fine for a lot of things. No one said it's perfect or does everything.

[hifromwork]

>They'd be wasting their time and making their lives needlessly harder, though.

Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

Before you say that I just need to research more: I know Docker swarm mode, I run my personal server on Kubernetes using Traefik and Let's Encrypt, I professionally work with Kubernetes (both as an admin and working on Kubernetes security, which is tough to get right), most services in my dayjob run on Kubernetes, and I was the person who introduced CI/CD pipelines there some years ago.

I still claim that there are production usecases that are better served by docker-compose.

[chipdart]

> Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

I think this is a very ignorant and misguided take.

Kubernetes is a container orchestration system, just like Docker swarm mode or even Docker compose. If you need to deploy sets of containerized apps into your own VMs, you can pick up any Kubernetes implementation. You don't even need Helm or anything. Plain old kustomize scripts will do. Some aren't even longer than a docker-compose.yml.

More to the point, Kubernetes is an interface. One that you can use in local deployment and in major cloud providers.

You should really check your notes because your comments contrast with the realities of actually running a service.

> Before you say that I just need to research more: (...)

All your appeals to authority are falsified by your claims.

I, on the other hand, actually use Kubernetes both professionally and in personal projects, as well as Docker swarm mode, and can tell you I'm no uncertain terms that none of your points have any traction in reality.

> I still claim that there are production usecases that are better served by docker-compose.

I'm sorry, but your comments simply sound deeply uninformed and misguided.

I mean, it makes absolutely no sense to comment on using docker compose in production when Docker swarm mode is far more capable and Docker swarm mode stacks already share most of the schema with docker compose. You literally have virtually nothing to do to adapt a docker-compose script to launch a stack.

Unbelievable.

[papichulo2023]

Most people dont need rolling release, 24/7 availability, auto scaling, etc.. on their home server, so managing k8s just add way more complexity. My main reason to not use is because I would need to host a artifact service somewhere else which is PITA. Some k8s runtime support local building but is not as easy as compose in my experience.

[chipdart]

> Most people dont need rolling release, 24/7 availability, auto scaling, etc..

That's perfectly fine. That's not the reason why you are better off running your apps in Kubernetes though.

You are better off running your apps in Kubernetes because it handles everything you ever need to effortlessly run containerized apps. You don't even need to install tooling or deployment tools or anything at all. You can have a single kustomize script that defines your services and deployments, have in place an ingress and Let's Encrypt, and you're done. You don't need to bother with anything else. Just run kubectl apply and go grab a coffee.

Is this something no one would ever need?

[papichulo2023]

> You don't need to bother with anything else.

Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended. Also having the master and the node in the same server can be problematic because by design it shouldnt be like.

One last point, the runtime ram and cpu overhead is far from minimal.

[chipdart]

> Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended.

You sound like you tried to put together an ad-hoc ingress controller without knowing what an ingress controller is and why abusing NodePort is a mistake in the context of a cluster.

You can check this out to go through the basics.

https://kubernetes.io/docs/concepts/services-networking/ingr...

> Also having the master and the node in the same server can be problematic because by design it shouldnt be like.

You should look at the problem to see if an approach makes sense. If you're using vanilla Kubernetes on a one-box deployment then you're abusing a large-scale high-scalable cluster management system by shoving it into a single box. It can work, but most of the resources will be wasted on managing your cluster of one node.

There are plenty of Kubernetes distributions that are designed to handle well small clusters, and even one-box systems. Minikube, microk8s, and even k3s come to mind. I'm partial towards microk8s because installing it is just a matter of installing a single package from the distro's official repository.