I want to learn about Kubernetes

[scripting]

I keep reading about Kubernetes and how it's taking over the world, but every piece also says it's very complicated. Why?

Heroku set the initial prior art in this area. It's easy to get started with. Here we are many years later, it seems we are going the wrong way. Or am I missing the point.

Isn't Kubernetes trying to solve the same problem as Heroku? In any case an open source user-deployable Heroku that was easy would be very welcome.

[stympy]

Perhaps dokku is what you want.

[scripting]

@stympy -- thanks for the suggestion.

My first question is this -- are there any services that offer hosting of dokku?

And of course there is a howto for Digital Ocean which I will read. ;-)

https://auth0.com/blog/hosting-applications-using-digitalocean-and-dokku/

Dave

[scripting]

Interesting timing. Digital Ocean introduced a new Kubernetes service yesterday.

https://blog.digitalocean.com/digitalocean-releases-k8s-as-a-service/

Dave

[corntoole]

Heroku/Dokku is fine for one-off apps. But If you have a stack that includes many applications or an application composed of many services, then Kubernetes is probably a good idea. If you already pay for large infrastructure resources, Kubernetes can be used to get better utilization of those resources.

[scripting]

Pretty much everything I have is "one-off" apps if I understand correctly.

What would be an example of an app that needs Kubernetes?

GitHub probably, right?

Twitter...

Anything with millions of users?

[corntoole]

I see Kubernetes (k8s) as standardizing the technology and practices (12 Factor apps, DevOps, etc) that a Heroku would use to build and operate a platform-as-a-service. But not just for types of applications specifically supported by Heroku, but for anything that can run in containers.

You have enough individual apps, that you could either run them in separate servers(virtual or physical) or in separate Heroku projects; or you could run them all in the same cluster. K8s enables one to specify a virtual cluster that can be provisioned onto any collection of infrastructure that implements the k8s APIs (ranging from a laptop to a cluster with 1+ bare metal or virtualized servers).

A single app consisting of 3 or more interacting services would need something like k8s, especially if you wanted flexible scaling, self-healing or needed fine grained control of how components were deployed. So yeah, an app that needs to scale to support millions of users would be an example.

A stack with multiple individual apps where you wanted unified interfaces for monitoring and administration of each workload could use Kubernetes. In order words, you want to manage your apps, not the servers they run on.

Another app that needs Kubernetes would be a service that needs to scale up from zero based some event like a customer request or API call. (e.g. AWS Lambda or Google Cloud Functions or code sandbox apps like repl.it or Glitch).

[scripting]

@corntoole -- thanks for the explanation!

What does "cluster" mean in this context?

[corntoole]

A cluster is one or more hosts running a Kubernetes master along with multiple worker machines. A k8s cluster could be just one server running something like minikube.

[tedchoward]

I'm currently working on an application deployed on a Kubernetes cluster.

To me Kubernetes solves a different problem than Heroku. Where they both are about application hosting, herok seems focused on speed and ease of deployment for a developer. What we call a "Platform as a Service". They provide a databases and a runtime, you give them source code and configuration, and you're off to the races.

Kubernetes is technology lower in the stack. The problem it is focused on is: how do I manage multiple applications running on multiple machines? let's say, for example, I have three servers. To serve my application, I have a MySQL database and an API server. I get a lot of traffic, so maybe I want to run multiple copies of the API server. Which machine do I run what on? What do I do if I need to add a third instance of the API server?

Kubernetes says, "Let me handle that" You put Kubernetes in charge of all your servers, and it gives you a "cluster". Think of it as a super-server. (Maybe it's 3 machines, maybe it's 5, it doesn't matter).

Then you tell kubernetes about your applications: "I need two copies of API server that each need 1 CPU and 256Mb RAM" and 1 copy of MySQL that needs 0.5 CPU and 256Mb RAM. It decided how to spread the work across the servers.

You can add and remove servers to and from the "cluster" as you need, but you don't need to think about what runs where.

There are more sophisticated things you can do with it as well, but this is the basic gist.

[thescarletmanuka]

I have found hosted kubernetes quite easy to use for simple combinations of apps. Running it yourself is where a lot of the "complicated" talk comes from, as you are generally setting up a datacentre with cpu, storage, ....

The config is yaml based, so I wouldn't suggest it to non-tech family yet.

If you have a one-piece app (stateless, or state in hosted service such as s3) then package it into a container. Your favourite cloud probably offers a simple interface for running it, keeping it up, and even autoscaling. No need to complicate things with kubernetes.

[emk]

👍 to what @corntoole and @tedchoward said.

TL;dr: If Heroku works fine, don't worry about Kubernetes at all. People are excited about Kubernetes because it fills in a gap in between Heroku and AWS, because it helps minimize AWS lock-in, and because it isn't completely terrible. If you do try Kubernetes, plan on reading an introductory book first. Don't install or manage Kubernetes yourself.

Heroku vs. a private server vs. Kubernetes

1. Use Heroku (or something similar) whenever you can. It's easy and painless. But sometimes you need disk storage, or your own database server, or a few apps which cooperate. This is hard to do with Heroku.
2. You can always run your own private server. We all know the tradeoffs here. It's easy (but only if you know Unix by heart!), and you can set it up however you like. But servers often turn into a mess of badly-documented customizations, they need to be updated all the time, they're hard to scale, etc.
3. Kubernetes is basically like a heavily customizable Heroku, with all the good and bad that "heavily customizable" implies. Kubernetes assumes that you have a cluster of servers, but like Heroku's servers, you basically want a pool of machines that get managed for you. Unlike Heroku, Kubernetes can manage disks, run databases, etc.

Dockerfile

With a Dockerfile, you can run your program locally on your computer, on Heroku, or using Kubernetes. It's basically a universal "cargo container" for server software; all the vendors can run it.

You only want a Dockerfile when a package.json isn't enough to get your app running.

A Dockerfile is basically like a package.json file, except you get to customize the virtual machine. Pick a distro! Install some packages! Run npm package install.

Before using Kubernetes, you need to learn how to make a Dockerfile for a Node app, and how to run it on your computer using docker run. Here's an example, adapted from this tutorial:

# Specify what version of Node to use.
FROM node:8

# Create app directory.
WORKDIR /usr/src/app

# Install app dependencies. (We do this first so we can cache it and not
# need to re-run `npm install` unless we change the package files.)
COPY package*.json ./
RUN npm install

# Bundle the rest of the app source.
COPY . .

EXPOSE 8080
CMD [ "npm", "start" ]

The whole tutorial is good, and it will show you how to build and run your app using the above Dockerfile.

What Kubernetes is like on a day-to-day basis

Basically, you write some YAML files describing all the things you want Kubernetes to create (applications, databases, disks, load balancers, etc.). Here are some examples for an RSS reader. Then you run:

kubectl apply -f my_big_app.yml

...and Kubernetes creates everything, making sure you have enough servers, creating any virtual disks you need, etc. If you get something wrong, or want to scale up, just edit the YAML file and re-run kubectl apply.

Basically, you spend all your time Googling for sample YAML templates, tweaking them, and applying them. It's not too bad.

You can even install support for new kinds of "resources". For example, gitkube basically turns your Kubernetes into something more like Heroku, complete with git push.

You can also find YAML templates that say, "Run one copy of the monitoring program described by this Dockerfile on each of my physical servers, automatically."

It mostly does what it promises. There are still some sketchy bugs (I spent 2 hours yesterday working around flaky Kubernetes 1.10 DNS, before giving up and hitting Google's "Updgrade my cluster to 1.11" button).

Kubernetes survival guide

So let's say you've decided that Heroku and package.json just aren't enough, and—for some reason—you don't just want to throw it all on a VM. Here are two key steps that will prevent a lot of suffering:

1. Buy and read a Kubernetes book, either The Kubernetes Book (nice and short) or O'Reilly's Kubernetes: Up and Running (more thorough). Basically, Kubernetes is like Linux in the 1990s—it's not too bad if you've read the book, but if you don't set aside that time, you're going to be confused.
2. DO NOT TRY TO INSTALL OR MANAGE KUBERNETES YOURSELF. Pay somebody to do this for you, and by "somebody" I mean either Google Cloud or possibly Digital Ocean. Do not use AWS Kubernetes unless you want to get your hands very dirty. (And I hear that Azure Kubernetes is not quite there yet.) Google's version is fine (once you learn your way around Google Cloud), and Digital Ocean has good reputation, so they're probably worth a look.

What's really going on here

AWS is great! But it locks you into Amazon. Of course, Google, Microsoft, Digital Ocean, etc., all see that this is a problem. So do a lot of Amazon customers. And they all realize that we can't do everything on Heroku.

So Kubernetes is basically there to paper over 80% of the differences between the different cloud setups. It acts an interface to AWS, or Google Cloud, or to Digital Ocean. It abstracts away servers like Heroku does. It runs Docker containers. It can manage disks, hook up load balancers, manage rolling deploys, all that stuff.

But if your app runs fine on Heroku, run your app on Heroku.

[danderson3]

very useful commentary - thanks!