81–90 of 369 posts
I have never deployed or built a K8s cluster, but recently I moved about a dozen AWS ECS Fargate workloads into a K8s cluster that a colleague of mine has setup. I was surprised. I really like it (from the perspective of a user/developer). I deploy my apps by updating a simple yaml file in a git repo. All my other practices (vim, go code with standard Makefiles, docker container image registry) are unchanged. I also…
There seems to be plenty of reasons to run Nomad, compared to Kubernetes, but in what scenarios do Nomad lose out to Kubernetes? Is it simply a matter of Kubernetes being an open source project and Nomad being owned by HashiCorp?
Earlier quoted context omitted.
Nomad will still get you where you need to be. Aside from vm live migration i am yet to find a good example of a workload where nomad is straight up is unable to do what you need.
You mean you run VMs inside... Kubernetes? Am I misunderstanding something here?
[0] https://www.nomadproject.io/docs/drivers/qemu [1] https://kubevirt.io/
We started by using it as a "systemd with a REST API" on a single server, and gradually evolved into multiple clusters with dozens of nodes each.
It has been mostly a smooth ride, even if bumpy at moments, but operationally speaking Nomad is closer to Docker Swarm in simplicity and Kubernetes in terms of the feature set.
We didn't find ourselves needing K8s as we're also leveraging components from the cloud provider to complete our infrastructure.
[0]: https://monitoro.co
> Kubernetes is an orchestration system for containers Yes, but No. Kubernetes is a portability platform, that happen to -also- orchestrate containers. Using kubernetes means you have complete reproducibility of the network setup, the deployment and the operation of any workload -no matter how complex-, on any kubernenetes cluster and cloud provider. Nomad, is -well- just a glorified Airflow.
Kubernetes is the new POSIX. It is complex for sure. But yes, portability is what matters. No vendor lock-in as long as you've abstracted your workloads to Kubernetes.
For example, if your application uses a database the major lock-in concern is the flavor. If you're using Kubernetes to deploy MySQL or Postgres or paying e.g. Amazon/Google to provide it for you, there's relatively low cost of switching because it's a very tested, standard interface with well-defined semantics. On the other hand, if you're using something like AWS DynamoDB or GCP Datastore you probably do want to think carefully about an exit strategy because you'd be baking in assumptions about how those services work in a way which is non-trivial to replicate outside.
The important thing is remembering that this is a business decision, not a holy cause, and the right answers vary from project to project. For example, in a larger organization you might find that it's worth using the platform services not because they're cheaper or better tested than what you can build for yourself but simply because it's easier to be able to check various auditing boxes using the standard auditing tools than having to laboriously demonstrate that your implementation meets the same requirements.
> Kubernetes is an orchestration system for containers Yes, but No. Kubernetes is a portability platform, that happen to -also- orchestrate containers. Using kubernetes means you have complete reproducibility of the network setup, the deployment and the operation of any workload -no matter how complex-, on any kubernenetes cluster and cloud provider. Nomad, is -well- just a glorified Airflow.
This doesn't make sense. While in the end these tools might both run code in containers they serve a different purpose. Airflow is far more aware of ETL concepts and comes with a lot of batteries included for those use cases. Whereas Nomad is more a generic solution with more emphasis on infrastructure.
This article just seems like "All of Nomad's best features phrased kindly vs all of K8s' worst features phrased critically".