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

Nomad vs. Kubernetes

nomadproject.io

Post reply on HN
Print view View original

301–310 of 369 posts

Re: Nomad vs. Kubernetes

#301

Post by still_grokking »

zmmmmm wrote: post #261
johnnycerberus wrote: post #59

Earlier quoted context omitted.

Yes, exactly my thoughts, the problem is that devops generally are used to Python/Go and in my company though they don't make it mandatory, they recommend Go. Also, they have a repulsive reaction to everything .NET and JVM :).

> Also, they have a repulsive reaction to everything .NET and JVM It's an interesting phenomenon I observe quite commonly. I think in the devops space they see these VM based languages as basically introducing ten redundant layers of unnecessary assumptions and complexity on top of what is already a good foundation - the Unix OS layer. They know the unix os layer well but every time they deploy one of these VM based…

Fun fact: Python and Go are both managed languages and need some kind of VM.

I guess those people are just not educated enough. Those Ops people don't know much about programming in large usually. A lot of them for example think it's OK to write serous programs in Bash. This says it all, imho.

It's OK when someone looking after admin stuff isn't a full blown programmer. It's a different kind of job after all. But this needs to be taken into account when looking at that mentioned phenomenon.

Re: Nomad vs. Kubernetes

#302

Post by ascendantlogic »

llama052 wrote: post #242
websap wrote: post #238

Earlier quoted context omitted.

I couldn't disagree with this more. I manage and run Kubernetes clusters as part of my job, and I can tell you that configuring, running and installing these clusters is no small feat. I don't know much about Nomad, but I would highly encourage most users to not think K8S is simple by any standard. Multiple cloud providers now provide ways to run your code directly, or your containers directly. Unless you have a reas…

Honestly if you use a managed kubernetes provider it's pretty simple once you nail the concepts. Though you'll get hit with cloud provider issues every now and then but it's really not terrible. I'd manage services in Kubernetes before I start deploying VMs again, that's for sure.

Almost everything is pretty simple "once you nail the concepts". It's getting to the point where you have the concepts nailed that is the measuring stick for complexity.

Re: Nomad vs. Kubernetes

#304

Post by coredog64 »

saynay wrote: post #60
sheeshkebab wrote: post #57

Earlier quoted context omitted.

Maybe bc no one uses that in reality and use helm instead?

Helm is useful if you need your software to run in many different places, and is widely known. This is why you see so many projects offering Helm charts; because you see them, they are set up to run in many environments. There is no reason to use it for your own software if you just have a single cluster.

At a previous employer, they’re building k8s clusters not for developers but for their infrastructure teams. In the past, where a vendor might have supplied an OVF file as the distributable product, they’re now providing Helm charts.

Re: Nomad vs. Kubernetes

#305

Post by AlexCoventry »

gizdan wrote: post #197
throwaway923840 wrote: post #117

Earlier quoted context omitted.

They're both complex. But one of them has 10 times the components than the other, and requires you to use them. One of them is very difficult to install - so much so that there are a dozen different projects intended just to get it running. While the other is a single binary. And while one of them is built around containers (and all of the complexity that comes with interacting with them / between them), the other on…

> But one of them has 10 times the components than the other I've said this before. Kubernetes gives you a lot more too. For example in Nomad you don't have secrets management, so you need to set up Vault. Both Nomad and Vault need Consul for Enterprise set ups, of which Vault needs 2 Consul clusters for Enterprise setups. So now you have 3 separate Consul clusters, a Vault cluster, and a Nomad cluster. So what did y…

That surprises me. Does Google have a more complete secrets-management system for its in-house services?

Re: Nomad vs. Kubernetes

#306

Post by [deleted] »

ninkendo wrote: post #213
SirMonkey wrote: post #188

Earlier quoted context omitted.

You mean the helm-package you installed without reading the documentation? Hate the player, not the game.

No. No, no no. This was legitimate a bug that they immediately fixed when I reported it... There is no legitimate reason to expose the master JNLP port to the internet, ever . The chart did not have a configuration option for this, it just exposed the JNLP port as part of the same k8s Service that exposed the web port. (The JNLP port is for jenkins workers to phone back home to the main instance, it's not for externa…

[deleted]

Re: Nomad vs. Kubernetes

#307

Post by _y5hn »

AzzieElbab wrote: post #226
rbonvall wrote: post #220

Earlier quoted context omitted.

Crockford himself says JSON was not invented but rather discovered.

Didn’t know he did but it is somewhat obvious. Lispish roots of js do shine through sometimes

Syntax and data structures are very similar to LPC serialization. Obvious but very useful.

https://en.m.wikipedia.org/wiki/LPMud

Re: Nomad vs. Kubernetes

#308

Post by m00x »

still_grokking wrote: post #291
cfigueir wrote: post #284

Earlier quoted context omitted.

The comparison is a bit misleading. As someone that has used both nomad and k8s at scale -- - Nomad is a scheduler. Clean and focused. It is very fast. I was an early user and encountered a number of bumps, but that's software. The people at Hashicorp are super sharp and lovely. - K8s is a lot more. It includes a scheduler, but in the simplest sense, it is a complete control-plane based on the control-loop pattern. Y…

I'm not sure it's a good idea to use Google's "monolithic cloud operation system". Such a monoculture has the same issues as MS Windows had, even for the same reasons. The "Unix Way" of simple tools interacting seems more reasonable. Especially when it comes to lock-in effects.

K8s itself is divided in multiple parts, where you can customize to your own liking, and you can swap parts if you'd like as long as the APIs are similar.

It's very much built the UNIX way.

Re: Nomad vs. Kubernetes

#309

Post by shaklee3 »

websap wrote: post #238
jeswin wrote: post #94

Despite its reputation, Kubernetes is actually quite easy to master for simple use cases. And affordable enough for more complex ones. The fundamental abstractions are as simple as they can be, representing concepts that you'd already be familiar with in a datacenter environment. A cluster has nodes (machines), and you can run multiple pods (which is the smallest deployable unit on the cluster) on each node. A pod ru…

I couldn't disagree with this more. I manage and run Kubernetes clusters as part of my job, and I can tell you that configuring, running and installing these clusters is no small feat. I don't know much about Nomad, but I would highly encourage most users to not think K8S is simple by any standard. Multiple cloud providers now provide ways to run your code directly, or your containers directly. Unless you have a reas…

I also maintained several kubernetes clusters and never found it very difficult. We never had any major outages, and the only downtime was trying new features.

Re: Nomad vs. Kubernetes

#310

Post by shaklee3 »

throwaway923840 wrote: post #117
jeswin wrote: post #94

Despite its reputation, Kubernetes is actually quite easy to master for simple use cases. And affordable enough for more complex ones. The fundamental abstractions are as simple as they can be, representing concepts that you'd already be familiar with in a datacenter environment. A cluster has nodes (machines), and you can run multiple pods (which is the smallest deployable unit on the cluster) on each node. A pod ru…

They're both complex. But one of them has 10 times the components than the other, and requires you to use them. One of them is very difficult to install - so much so that there are a dozen different projects intended just to get it running. While the other is a single binary. And while one of them is built around containers (and all of the complexity that comes with interacting with them / between them), the other on…

Kubernetes has been a single binary with hyperkube for over 5 years. This argument is really tiring.
Post reply on HN