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

311–320 of 369 posts

Re: Nomad vs. Kubernetes

#311

Post by shaklee3 »

glynnforrest wrote: post #229
robertlagrant wrote: post #93

Earlier quoted context omitted.

> For example, if you're a golang shop you can run everything as native binaries and cut out docker completely. Ironically you can also just deploy a go executable into an empty Docker container and it's basically the same as the raw executable, but with all the config abstracted to be the same as other containers'.

Good point! Although Docker does add a networking layer on top. I'd prefer to run something like HAProxy without Docker if possible.

Adding the networking layer is a good thing since it's centrally managed

Re: Nomad vs. Kubernetes

#312

Post by shaklee3 »

jnsaff2 wrote: post #34

I liked Mesos when I worked on it, and it's been replaced by more modern tools like Nomad, but every time I have to work on k8s it's .. well it's being promoted like a cult, has a cult following and I think the whole thing is set up to suck up complexity and layering. How do you deploy a thing to run on k8s? One would think you deploy a manifest to it and that's it. Like yaml or json or hcl or whatever. No. The built…

At some point you need to take a few minutes to learn new technologies in a tech career. Kubernetes is just not that hard if you spend a little time understanding it. You don't need a service mesh. Calico is very simple, or you can use cilium for something more advanced

Re: Nomad vs. Kubernetes

#313

Post by pronoiac »

still_grokking wrote: post #296
pronoiac wrote: post #293

Earlier quoted context omitted.

It's been a while, so I'm fuzzy on some details: * in a legacy system, a server, perhaps with the leader node, filled up disk space and became unhealthy, the consul agent kept reporting it and itself as healthy, and failover and gossip generally wedged * in a dev environment, after we replaced some servers in the cluster, the other nodes noted cert changes and refused to work with the new servers * second-hand, in se…

And what is the replacement for it?

We rearchitected. At one workplace, we built and distributed our own service. At another, we shifted to semi-automated more static lists of servers for roles; those servers were much less dynamic.

Re: Nomad vs. Kubernetes

#314

Post by shaklee3 »

still_grokking wrote: post #296
pronoiac wrote: post #293

Earlier quoted context omitted.

It's been a while, so I'm fuzzy on some details: * in a legacy system, a server, perhaps with the leader node, filled up disk space and became unhealthy, the consul agent kept reporting it and itself as healthy, and failover and gossip generally wedged * in a dev environment, after we replaced some servers in the cluster, the other nodes noted cert changes and refused to work with the new servers * second-hand, in se…

And what is the replacement for it?

etcd

Re: Nomad vs. Kubernetes

#315

Post by _y5hn »

still_grokking wrote: post #301
zmmmmm wrote: post #261

Earlier quoted context omitted.

> 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 thi…

Fun fact: There are formers devs among Ops, and sometimes vica versa.

Go binaries are statically compiled usually, no VM or managed. It's a simple language for simple solutions, which is often underrated.

Not that versed in Python, but there is CPython.

Bash is totally ok in the hands of someone who uses it for good ;) Agree it has too quirky syntax when you need complexity, so not good for large stuff.

Footguns are everywhere. You usually trade one in for another.

Re: Nomad vs. Kubernetes

#316

Post by rixed »

AlexCoventry wrote: post #305
gizdan wrote: post #197

Earlier quoted context omitted.

> 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?

IIUC, despite K8s having started at Google by Go enthusiasts who had good knowledge of borg, the goal has never been to write a borg clone, even less a replacement for borg.

And after so many years of independent development, I see no reason to believe that K8s ressemble borg any more than superficially.

This seems to be very much assumed by kubernetes authors. Current borg users please correct me if I'm wrong.

Re: Nomad vs. Kubernetes

#317

Post by mcdevilkiller »

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…

Definitely the contrary in my experience

Re: Nomad vs. Kubernetes

#318

Post by m00x »

glynnforrest wrote: post #229
robertlagrant wrote: post #93

Earlier quoted context omitted.

> For example, if you're a golang shop you can run everything as native binaries and cut out docker completely. Ironically you can also just deploy a go executable into an empty Docker container and it's basically the same as the raw executable, but with all the config abstracted to be the same as other containers'.

Good point! Although Docker does add a networking layer on top. I'd prefer to run something like HAProxy without Docker if possible.

You can run it on the host network as well.

Re: Nomad vs. Kubernetes

#319

Post by vegai_ »

proxysna wrote: post #73
vegai_ wrote: post #47

Nomad could use an official or semi-official distribution. Something that you could throw into any VM with minimal configuration and it would create a new or join an existing nomad cluster. I've been thinking about building such a thing on Arch (btw) but haven't acquired enough time-energy to do it.

Nomad + Consul does auto-clustering. All you have to do is specify in which mode your nomad binary is working and where your consul client is listening. For local development -dev mode exists for both Consul and Nomad.

Yeah, I figure this shouldn't be too difficult to implement, but will be at least laborious to consistently keep up-to-date and stable.

Re: Nomad vs. Kubernetes

#320

Post by softveda »

wg0 wrote: post #179
specialp wrote: post #177

Earlier quoted context omitted.

It doesn't take long working with Nomad to hit the cases where you need to augment it. Now I know some of people enjoy being able to plug and play the various layers that you get in the complicated kitchen sink Kubernetes. We already had something that just ran containers and that was Mesos. They had the opinion that all the stuff like service discovery could be implemented and handled by other services like Marathon…

One of the things that I don't like about Nomad is HCL. It is a language that is mainly limited to HashiCorp tools and there's no wider adoption outside at least not to my knowledge. From the documentation: > Nomad HCL is parsed in the command line and sent to Nomad in JSON format via the HTTP API. So why not just JSON or even JSON at all and not MsgPack or just straight up HCL because that's over and over introduced…

OctopusDeploy selected HCL for its pipeline config as code.

https://octopus.com/blog/state-of-config-file-formats

Post reply on HN