Hacker News Reader

Comment by _rp6i | Hacker News Reader

The second question:

> Choosing a cloud provider

This really annoys me about Kubernetes. Essentially all the official documentation is about how to select a cloud and let a cloud-specific tool magically do everything for you. There's no procedure for setting up a single host for development purposes or to have a Dokku-like personal PaaS.

This guide is super useful because it avoids all the magic and lets you set things up properly (despite assuming you're doing it on a cloud) and potentially even do it on a single host.

View on HN

Thanks for that. This is one of the few comments in this thread that truly captures the idea behind this guide.

I've grown quite a thick skin since I exposed the first project of mine to a wider audience. But still, it's feedback like yours that keeps me going.

No worries, thanks for writing it! A lot easier to follow than https://kubernetes.io/docs/getting-started-guides/scratch/#b..., which I was looking at previously.

Let me also chime in and say I deeply appreciate the tone and level of technical detail in this... repo? report? guide? It's precisely the sort of thing that's been infuriatingly absent from the Kubernetes community for far too long. If this or something like it had been released with 1.0 we'd be a lot further along than we are now, I think.

> There's no procedure for setting up a single host for development purposes or to have a Dokku-like personal PaaS."

Can you clarify what you mean by this? Since the beginning (pre-1.0) it's been possible to stand up a cluster on bare metal/VMs using a single command. This used to be done with the `kube-up.sh`[1] tool, which has been replaced with kubeadm in 1.6 [1].

If anything, I thought the fair complaint would be that there are too many ways to set up a cluster, and it's confusing to figure out which is the right one [2].

[1]: https://kubernetes.io/docs/getting-started-guides/kubeadm/ [2]: https://kubernetes.io/docs/setup/pick-right-solution/#table-...

The problem with these tools for me was that they required either Ubuntu or CentOS/RHEL. I was installing on bare metal running Fedora and I'm unwilling to rebuild my machine for one application.

I think I eventually got something set up using the manual documentation but at the time said documentation resulted in a completely insecure installation, entirely unauthenticated. Since I don't have (or want) a "private" network and the docs didn't tell me how to get security any other way, I just gave up on Kubernetes.

And really, it's incredibly frustrating how inflexible the docs and setup tools are. As detailed in another comment (https://news.ycombinator.com/item?id=14296176), Kubernetes really just consists of Docker and 6 Go binaries. There's no reason setup should be so difficult and certainly no reason why it should be OS dependent.

Got you, that's fair. It's definitely something that's been a pain point in the past, and is what kubeadm was designed to solve.

There are actually a lot of tedious configuration parameters that need to be tuned per-distro, which is why there's only now a candidate for a unified solution; it's harder than you might think to create a truly generic tool for this job. (Take a look at the kube-up saltstack files if you want to be horrified by some surprising complexity).

Nowadays, it looks like there are a couple options on Fedora, specifically

https://kubernetes.io/docs/getting-started-guides/fedora/fed... https://kubernetes.io/docs/getting-started-guides/fedora/fla...

If you're looking for something that "Just Works (tm)", the ansible config (above) would be my bet for where to start these days.

> here's no procedure for setting up a single host for development purposes

I felt exactly like this, but then found one.

https://kubernetes.io/docs/getting-started-guides/kubeadm/

It requires manual kubelet setup (usually there are OS packages for that - which is the proper way to install software on the host system), and then it generates a CA, node certificate, spins up etcd and flanneld containers and sets up k8s on top of those. It also lets one join that cluster in a semi-automatic manner, making the whole setup no harder than Docker Swarm.

I think it's a reasonably nice middle point between unexplainable cloud magic and do-it-all-yourself-the-hard-way setups.

Red Hat Container Development Kit is a great way to get started locally, if you want to deploy OpenShift on a VM there's an Ansible-based installed that will interview you and install it on your VM's (since OpenShift is just a layer on top of k8s you can use all the underlying primitives if you don't want the additional features).

It's for real world distributed systems. The sort of thing that cannot run or be simulated on a single machine.

It's not worth bothering to make a single machine setup.

Except they provide a official single-machine setup called minikube. Sadly minikube suffers from the same issue GP describes - it is just calling one of the existing automagic bootstrapping scripts against a local VM.

> It's for real world distributed systems.

The same can be said of Heroku, yet Dokku exists. The same can be said of Docker, yet plenty of hobbyists use it for their projects.

> It's not worth bothering to make a single machine setup.

Sure it is. Say you're a web developer and you use MySQL, PHP and Apache on Kubernetes in prod. Why would you go to the effort of setting those up individually on your machine when you could just put your prod manifest on Kubernetes on your workstation?

There's nothing about Kubernetes (aside from poor documentation) that prevents it from being used on a single host. Actually, according to its own documentation (https://kubernetes.io/docs/getting-started-guides/scratch/), it consists of:

- Docker/Rkt

- Kubelet

- Kube-proxy

- Etcd

- Apiserver

- Controller

- Scheduler

The bottom 6 are actually written in Go and can be run from a single binary.

There's no reason Kubernetes should be hard to set up. There's no reason it can't run on a single node. There's no reason you need a cloud. There's no reason you need a "supported" operating system.

>>> Say you're a web developer and you use MySQL, PHP and Apache on Kubernetes in prod. Why would you go to the effort of setting those up individually on your machine when you could just put your prod manifest on Kubernetes on your workstation?

A basic LAMP stack doesn't need Kubernetes to operate. It's up to you to justify the effort of setting up 7 super complicated and useless software.

But a developer doesn't want "a basic LAMP stack," they want something that matches what's in production. "It worked on my machine" is not a great way to do software development.

Reply on news.ycombinator.com