[protomikron]

And yet I still have to deploy my first Kubernetes setup and have used Docker multiple times ...

Is there some kind of "Kubernetes-light" out there? So something like in-between running services like NGinx and Postgres on bare Linux machines and having this (I think complex) Kubernetes setup? It's important to say that I don't need any scaling capabilities (apart from maybe some load-balancing in case of a machine error).

[KuiN]

Docker Swarm mode. Honestly it's great, I'm surprised I don't see it spoken about here more often. It's maybe 30 minutes to get started, much less of a brick-wall learning curve than Kubernetes. It does basics well and you can still do complex things like cluster storage etc. I'm using it to deploy a couple docker-compose stacks across a tiny two-region Droplet cluster and it's been excellent.

[Multicomp]

Anecdote : we had a much better experience in terms of reliability with k3s than Docker Swarm. The latter was slightly more complicated to admin and was much more prone to random lockups or needing all containers scaled down to nothing then back up.

K3s (run on same hardware) had a similar Api to full k8s which we had previous experience with and handled container lifecycles much more robustly.

[heipei]

I would give Nomad a try. After reading pages on pages of Kubernetes setup and trying the many half-working setup tools de-jour, setting up Nomad was a breeze and keeping it running over many months took almost no effort at all. URL: https://www.nomadproject.io

[kawsper]

Nomad is great, and easier to grasp than Kubernetes, and with Consul you also have have DNS-based service discovery for your Nomad programs.

[scarface74]

I agree with this 100%. Nomad can orchestrate anything. Docker containers, executables, jar filed etc.

Nomad+Consul is the definition of easy.

[15155]

https://k3s.io/

Has been posted here a few times.

[protomikron]

Thanks, that looks interesting. I hope I don't get toooo many different suggestions. ;)

[wyaeld]

easiest way is just start experimenting with GKE on google cloud, and see if it has value to you. Don't bother trying to deploy and manage it before you've kicked the tires.

Out of the box its quite good, depending on what you are doing, once you have cert-manager issuing you free certs, linkerd managing a service mesh, and stackdriver giving you an entire ops stack, its a bit hard to go back

[williamallthing]

Thanks for the Linkerd shoutout! For those who aren't familiar with the project, Linkerd will give you per-service metrics (success rates, RPS, latency distributions), mutual TLS, load balancing, and a bunch of other cool stuff, on almost any Kubernetes app, right out of the box. No config necessary.

[collyw]

Is there a way to do this without spedning a fortune on Google cloud costs?

[protomikron]

How big is the vendor-lockin though? Let's say I want to use both Hetzner Cloud and GCP instances - I am sure it's possible, but the question is how much of a hassle it is ...

[bonesss]

That depends on your app portfolio (naturally), how impacted it is by k8s version changes, and how much cloud specialization it requires.

You're probably better off on k8s than just about anything you didn't write yourself wrt to vendor lock-in. The true lock-in, IME, are when you use cloud features that aren't portable. Humble apps are fine, but ambitious apps are bound to those ambitious capabilities.

Seen next to comparable parallel installations it's a pretty minimal of per-environment specialization, and you can generally tweak the environments to support transparent parallel deployments. It's the differences in how load balancers work and which resources are immediately available that create work since the abstraction layer may not fully abstract away the environments.

[tjpnz]

Most of the issues I've faced (Ingress cough) have been solved by reading through the relevant pages in the Kubernetes documentation. A lot of the docs/tutorials provided by GCP link back there.

[mjlee]

If you want to use both then you should investigate rancher - that's the problem they're trying to solve.

[speg]

https://kubernetes.io/docs/setup/learning-environment/miniku...

Note: I’ve not yet tried it, but when we switch this was one of the things I was going to try first.

[amq]

Good point, there is still a barrier between how people deploy (kubernetes) and how people develop (docker-compose). And it's not just different syntax, developers typically never have to deal with concepts like ingress and persistent volume claims. Things like converting compose to k8s manifests don't really help developers to understand how kubernetes works in production. As a result, Kubernetes tends to help to reinforce the need for ops people, for better or worse.

[throwaway008]

learning kubernetes here too. helm seemed to be the answer but...

i spent hours trying to make helm work on my mac and in the end gave up. the original error was with comparing floats in the latest version. that error seems to pop up every now and then in their issues list. now, there is no way to install an earlier version. not with brew anyways. installing from binaries or sources is nightmarish. and when you do, it might not like your minikube setup. and yaddi yaddi yadda...

it feels odd and strange to me that the trend nowadays is to accept these complicated systems and be amazed by how complicated they are...

[saberience]

AWS ECS (it's what we use)