[outime]

The biggest problem with these posts is that authors seem to fail to see how K8s isn't targeting home servers or small companies. Sure, there's K3s which allows you to have a more minimalistic experience but it's still K8s.

K8s is enterprise stuff and should be seen as such. It's complex because the problems that are being attempted to solve are complex and varied. That doesn't discount that Nomad is a great piece of software though.

[flyinprogrammer]

Nomad's support for CNI and CSI is improving with just about every release, and they just proved you can run over 2 million containers in a globally distributed cluster.

https://www.hashicorp.com/blog/hashicorp-nomad-meets-the-2-m...

So what's an example of "enterprise" and "complex" problems you think it can't do?

[outime]

K8s targets a long list of things that Nomad just doesn't want to deal with in the name of simplicity - and that's ok, if that suits your use case.

Some are mentioned in the post but I can think of secret management, load balancing, config management, routing, orchestration beyond workloads (e.g. storage), rollbacks/rollouts and many more. Perhaps in few areas there are some support but it's not what Nomad intends to do anyway. I also like these points from another comment: https://news.ycombinator.com/item?id=26142658

In order to supply those needs in Nomad you'll need to spend time finding out how to integrate different solutions, keep them up-to-date, etc. At that point, K8s may be a better answer. If you don't need any of those, use Nomad or anything else that's simpler (e.g. ECS if you're in AWS, K3s if that's simple enough for your home server, etc).

[stickupkid]

> Some are mentioned in the post but I can think of secret management

Hashicorp Vault seamless integration.

> In order to supply those needs in Nomad you'll need to spend time finding out how to integrate different solutions, keep them up-to-date, etc

Like how k8s secrets are secure out of the box ?

[outime]

I can understand how they seamlessly integrate with their own products (and I like Vault a lot) - not sure how it'd work with other secret backends if you'd prefer them over Vault. It's also fine you picked an individual item of a long list to rebut what I said. But this is what I said:

>Perhaps in few areas there are some support but it's not what Nomad intends to do anyway

Look, I think we can agree that K8s have many features that Nomad don't and that's just how it is (not good or bad, just different). This comes with added complexity. If you wanted to have all these features in Nomad it'd cost you a lot to the point of being impractical. "I don't need all of those" then don't use K8s - but then don't complain when you bring a vast machine that does 1000 things to do 100 and complain it's too complex.

[sofixa]

> of secret management, load balancing, config management, routing, orchestration beyond workloads (e.g. storage), rollbacks/rollouts

Nomad does all of these either natively ( rollbacks/rollouts) or via external tooling ( Vault, Consul, a load balancer). Unix philosophy and all that, and besides, Kubernetes doesn't do load balancing, and secret management is a joke.

[Aeolun]

If it does these things through external integrations, it’s not really something Nomad does.

[sofixa]

By that logic, Kubernetes does nothing that is offloaded to operators, CRDs, CSI plugins, etc. The fact that you can extend it with extra features and it supports that is kinda doing something.

[mr-karan]

> authors seem to fail to see how K8s isn't targeting home servers or small companies

Well, I do run K8s in prod at my org. And my comparison was based off my experience with it running in prod.

> It's complex because the problems that are being attempted to solve are complex

Most people just want to deploy their workloads in a consistent, repeatable manner. That's why they look to run an orchestrator. K8s is the most popular choice but it's time we look at other tools which can also help us reach that goal with less headache.

[jsiepkes]

> The biggest problem with these posts is that authors seem to fail to see how K8s isn't targeting home servers or small companies.

Who would you say are in the target audience of Kubernetes?

I doubt most medium to large companies I see implementing Kubernetes could be considered a good fit for Kubernetes. If you want to run on-prem / colo you are probably better of with something simpler like Nomad. If you want Kubernetes it's probably a better idea to use a hosted Kubernetes solution like Google's offering. For most teams it's probably too much complexity to be able to maintain, troubleshoot, secure, update, etc.

[outime]

>Who would you say are in the target audience of Kubernetes?

Everything else - I literally said "K8s is enterprise stuff". Now if we go to specifics then it depends of what the company does, maybe they'd do just fine with Nomad or a managed solution like ECS.

>If you want Kubernetes it's probably a better idea to use a hosted Kubernetes solution like Google's offering.

Well I agree? All of the big companies I've been in used EKS and before EKS was decent there was some maintenance overhead. It'd still be less than the maintenance overhead to maintain the full list of features that K8s provides with Nomad, as Nomad doesn't provide any of those and you'd need to seek solutions outside of the product and try to fit them in.

The same way you'd not buy a car if you're going to drive yourself quarter of a mile once a week, you'd not use such a complex solution to run a few dozen containers.

[the_angry_angel]

> I doubt most medium to large companies I see implementing Kubernetes could be considered a good fit for Kubernetes. If you want to run on-prem / colo you are probably better of with something simpler like Nomad.

Our path has been Ansible -> Ansible+Docker -> Docker Swarm -> k8s. We absolutely don't need k8s, but the other options all had downsides.

1. Nomad was on our list and probably would've been better, but there were no managed Nomad solutions at the time and it was not as widely used as other solutions

2. Our time on Swarm was /ok/, but it was more and more obvious that being on the lesser walked path was a problem, and it's future made us run away from it

3. k8s gave us a nice declarative deployment mechanism

4. We can switch to a managed solution down the road with less friction

[linkdd]

> If you want Kubernetes it's probably a better idea to use a hosted Kubernetes solution like Google's offering.

This may not be true in the future with distributions like k0s[1]

[1]: https://k0sproject.io/

[parhamn]

> K8s is enterprise stuff

The comment you’re replying to already said whom.

[znpy]

> The biggest problem with these posts is that authors seem to fail to see how K8s isn't targeting home servers or small companies.

Indeed.

On the same bus one should be reading posts like "how I switched to a minivan for my family and dropped the complexity of enterprise-grade multi-carriage trains".