> How do I install GKE on my servers? ;)

Great question! All major Cloud providers offer managed Kubernetes services:

https://cloud.google.com/kubernetes-engine

https://azure.microsoft.com/en-us/services/container-service

https://aws.amazon.com/eks

https://www.ibm.com/cloud/container-service

The choice is Cloud + Kubernetes vs. roll everything on your own hardware.

Running your own hardware is a major IT effort. Kubernetes is just a part of that effort. Then you have take care about planning, provisioning, logging, monitoring, alerting, auditing, networking, storage, oncall.

You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount.

EKS isn't generally available

> Running your own hardware is a major IT effort. Kubernetes is just a part of that effort.

For Enterprise nerds VMWare has also just launched a Kubernetes service, so the #1 Enterprise VM supplier just added k8s on-prem for everyone who is in a hybrid cloud situation.

> You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount.

You can always rent dedicated hardware – much cheaper than renting similar amounts of virtual servers, and the same administration and operations costs. It’s often even significantly cheaper than what GCE offers – but of course, setting up Kubernetes is more complicated.

Exactly. Hardware rental is one way to tackle provisioning. You're still left with all the other tasks required to bootstrap your own datacenter. As you build up the roll-your-own solution, you end up in the same place: hire IT headcount.

If you are a small startup looking to validate market fit, your best bet is Cloud + Kubernetes. If you are an established business with millions of daily customers and serious IT headcount budget, you may look into roll-your-own. The best orchestrator at that scale is, again, Kubernetes.

> Exactly. Hardware rental is one way to tackle provisioning. You're still left with all the other tasks required to bootstrap your own datacenter. As you build up the roll-your-own solution, you end up in the same place: hire IT headcount.

For a startup, building a datacenter isn’t required in the beginning.

I meant, literally renting existing hardware, in an existing datacenter. This is just a single step from renting VMs at AWS or GCE, but already improves costs significantly.

I think pacala's point still stands - if you rent hardware, there is still a larger effort involved around running scalable services (DR, auto-scaling/load balancing, deployments etc). If you rent hardware, you likely will need a larger dedicated % of resources dedicated to maintaining that, over OOTB service providers.

Edit: got user names wrong

you still have to go from bare metal in someone else's DC to having you software running on top of it, who's going to do all that config work? You're spending resources either way.

As I said before, thanks to container linux, that's 3 lines in a json config.

I've deployed a handful of servers automatically myself this way, and I'm still a student.

Saving about an order of magnitude in terms of costs, gaining flexibility, and the only additional work is so low that it costs a compsci student half an hour once (aka ~10€ in wages) — there's no reason not to do it.

That's not true in a whole lot of industries. Many (!) small shops simply can't choose the cloud because of various reasons (regulations, for example).

Thanks for the reply.

I agree with what you say. I'm not tying to say people should all jump to k8s. Having options on the market is great.

But I was trying to refute the notion that Kubernetes has no advantages unless you're running a huge cluster. My main points where:

* It works great with 1 node.

* It comes with many features that Swarm does not have that are useful even at 1 node (PersistentVolumes, StatefulSets are biggest for me, though there are _many_ more I wouldn't want to go without anymore).

* Docker is not trivial to set up, either.

> How do I install GKE on my servers? ;)

Yes, of course. I was just saying there's a solid option to start exploring quickly.

> It only listens for commands on a local socket.

This is kind of a non-starter, isn't it? Of course it's easy to apt-get install docker, but then you want to control it remotely, right? Once you realize how nice it is to control Docker remotely, it's hard to imagine life before.

Actually if you are using StatefulSets and PV, then kubernetes is a better fit for you.

However, Swarm is undeniably simpler to work with unless you have very specific requirements that only K8S provides. The yml file is incredibly simpler.

Docker Swarm is the Kotlin to Kubernetes' Java. It's a much pleasanter and much less intimidating way to build production systems that scale pretty well.

Kubernetes needs you to have load balancers setup which can talk K8S ingress. Bare metal setup for k8s is a huge effort (and I have stuck long enough on #sig-metal to know) as compared to Swarm.

You should try out Swarm - you might choose not to use it, but you will enjoy the experience.

Completely agree. Tried them both and found Docker Swarm to be much simpler to setup and maintain.

> Docker is not trivial to set up, either.

Do you have a concrete example of what you ran into? What do you mean by "secure install"?

on osx its just a matter on installing docker4mac and other linux distributions has pre-made packages. I am a linux noob and I was able to setup a 20 machine cluster with swarm trivially on centos7.

I was acutally surprised that I was able to do that so trivially, given I have minimal linux admin experience if any.

I’m referring to all the stuff Docker machine does beyond apt-get install docker. It sets up TLS certs and sockets do you can control the docker daemon remotely. When docker machine works it’s great, but when it doesn’t it’s frustrating.

Its built into docker swarm, afaik. You don't need to do anything special setup for TLS.

https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk...

> Kubernetes has no advantages unless you're running a huge cluster.

You're absolutely correct. Kubernetes has its advantages, even in a single-node setup. What many others are pointing out is that it also has significant disadvantages, too.

> but then you want to control it remotely, right?

By the way, I do talk to Docker (Swarm mode or standalone) deployments remotely, forwarding the socket via SSH.

    ssh -nNT -L /tmp/example.docker.sock:/run/docker.sock example.org
    docker -H unix:///tmp/example.docker.sock info

(Needs user to have access to the socket, of course. If sudo with password-requirements is desirable, `ssh + sudo socat` is a viable alternative.)

But, really, there is Ansible for this. Declare `docker_service` and get it deployed (or updated) as a part of the playbook. And ELK (with logging.driver=gelf for the containers or application-level) for logging.

(BTW, what's nice about K8s is that IIRC it allows to exec into pods with just `kubectl exec`. With Swarm you need some script to discover the the right node and container ID, SSH into it and run `docker exec` there - no remote access.)

I appreciate where you’re coming from, but you can’t bring GKE into a conversation about the challenges of Kubernetes ops. GKE does everything for you.

I guess you are correct. What about Docker Machine vs Kops, then?