Kubernetes 1.6: Multi-user, Multi-workloads at Scale

I don't know if it's the holy grail but it's surely one of the nicest and most impressive piece of tech I've seen since I tried Asterisk 10 years ago and had a long OMG moment myself.

The ecosystem is growing by the day and Kubernetes itself changes a lot very quickly. The pace of its development is sometimes crazy. You might find yourself trying to stay on top of the latest release just to notice there's a new one out of the door and that you will surely want to move to. In this regard I would say to wait a bit, hold your horses and come back to Kubernetes once its release cycle is a bit saner for production environments (my personal estimation is by the end of this year, or earlier than that).

What is missing in my opinion is a better container backend other than Docker (I just find it not enough for more complex scenarios, too bloated, there is the PID-1-hell, etc). With the new container runtime interface I am sure this won't be a problem in the long term.

Also, storage. I mean, the whole user side of setting it up is a breeze. The new release makes it even more simple apparently. However I'm still not very sure how reliable things are here. Maybe it's just me not understanding how storage works in a Kubernetes world... whatever. I know for a fact I am not the only one with this concern though.

What I can tell you is that after seeing a full deployment pipeline in Kubernetes actually working, and seeing all its load balancing and HA and rollout/rollback features, I am not going to stop using it.

My recommendation for starters: the docs are good, read about every Object type and things will eventually "click" in your head. Make sure you understand every bit that is inside a spec file, it will make things easier to understand. Get how ingress/egress work, they can be a pain in Kubernetes sometimes. Try minikube, for Darwin's sake.

Yes, it is the holy grail. Yes, the documentation is a bit spotty in some cases. We've been using kubernetes in GCE for about 1 year. We run both interactive services and batch jobs in 2 clusters: dev and production. The production cluster runs fully with declarative configs (we have a jenkins instance that performs the deployments of committed k8s configs). There are a couple of features that we are missing: (pod anti-affinity now in 1.6) and better support for storage. But in general kubernetes has the right concepts for running services, imho. We have 0 ops people. Our clusters run on large VMs with 10s of PODs in the same VM. We can get high cpu/mem utilization; resilience to failures; logging; monitoring (via prometheus - GCE /stackdriver is awful). I don't think there is anything out there that comes close in terms of supporting the right abstractions and being ready to use in production.

There are definitely a lot of moving parts in Kubernetes just to get it running and it was a big hurdle to get everything set up (I'm running a vanilla cluster in Vagrant).

The documentation definitely covers a lot, but I found myself hunting issues down for trying to get something to work like getting k8s to schedule pods across a flannel overlay network and making sure traffic is being routed properly. Of course, you don't have to worry about any of this if you use GKE or another cloud provider.

Once I got that set up, everything worked beautifully. I can just write a config and apply it to the cluster and services are deployed and scaled and whatnot. Treating your cluster as a pool of resources is pretty powerful. There are a lot of Kubernetes API objects (Deployments, Stateful Sets, Daemon Sets, ConfigMaps, Secrets), but everything has a purpose and Kubernetes makes everything come together nicely.

The Kubernetes Slack channel was really helpful for me as well, there's a lot of nice and friendly people there willing to answer your questions and help you debug your setup.

Yeah, I feel you. I found kubernetes very hard to learn as well. I wanted was to find a good tool to run a SaaS (to handle 10k users). Only after reading up a lot did I even realize that this was not for me. I had fallen into the Hackernews hype trap and thought kubernetes is the right tool for me. I am back to my simple docker based deploys in 5 EC2 instances. It's very much by hand but works with some simple instructions to follow on a wiki page.

I have also found kubernetes labor hard to find. The ones I found were way too expensive for me (upwards of 150k USD).

Having worked mostly with mesos and k8s, I found k8s configuration superior, e.g. how one can import secrets, config files, and more importantly set up the network without address translation or port forwarding. Tooling seems OK with both, and I agree one needs to spend some time to get familiar with the CLI and nomenclature, IMHO because both are quite flexible and powerful.

I think it's the holy grail for stateless services. For stateful systems though, (that need to persist data) things can be tricky. Maybe the improved node affinity features in this release will improve things but I still feel limited because I can't seem to find a way to permanently bind a Pod to a specific host's file system. They keep pushing for NFS or other complex network file systems that add huge network I/O overheads instead of letting you deal with distributed storage across multiple hosts yourself (which would work better with most new database engines that have built-in cluster support). Last time I checked, you COULD bind a Pod to the underlying host's file system but the documentation says that this is only for debugging purposes and not suitable for production.

ACK. We recognize this aspect of the docs (engineers writing docs == encyclopedia articles). We have real, honest to goodness tech writers now, and they are working on it. One piece at a time.

No it hasn't. You can track the progress of CronJob by subscribing to the feature issue (which should generate fairly low email traffic):

https://github.com/kubernetes/features/issues/19

Wouldn't The Right Way (TM) be to have a daemon running on the cluster that's watching either your nodes (if you want to allow access from all your nodes) or specific pods and then call your PostgreSQL provider's API to let it know about valid access IPs dynamically?

Is IP whitelisting your only option? I really haven't found a good way to pull this off in Kubernetes. You could set up and instance outside the cluster to act as a proxy, but that just feels like a very substandard solution.

On GCP, you can use the SQL Proxy [1] to avoid IP whitelisting or manual SSL setup. Postgres on GCP is still beta, so you probably don't want to run a production DB with it, but hopefully your provider has a similar option.

1: https://cloud.google.com/sql/docs/postgres/sql-proxy

(I work on Google Cloud)

But aren't the node IPs relatively constant, barring complete node failure? You could just whitelist all of the node IPs you'd expect to connect.

This problem could be solved by finer grained control over network routing configuration in general. The problem seems to be that this configuration differs depending on what network virtualization technology/driver you choose, and so implementing it is best left outside the scope of kubernetes.

I don't think there is even an open issue for this. You should file one!