This post is based on my talk at KubeCon Europe 2017. The recording, slides, and demos of this talk are all available. In this talk, I gave an overview of built-in controllers in Kubernetes. The intended audience is Kubernetes beginners.

You may remember that, the AWS outage happened last month broke lots of popular websites and applications. After the incident, Rob Scott, VP of Software Architecture at Spire, shared a story of how Spire mitigated AWS outage with the magic of Kubernetes.

Rob Scott on Twitter

So @kubernetesio is basically magic. It automatically redistributed our systems after instance failure in today's AWS outage - no downtime.

Kubernetes is a platform for containerized application patterns. These patterns make applications easier to deploy, to administer, to scale, and to recover from failures — that’s the magic.

What’s in a Kubernetes Cluster?

Here is a simplified Kubernetes cluster:

A pod is the smallest and simplest unit that you create or deploy in Kubernetes. A single pod has usually one, or sometimes several tightly coupled containers, and their shared resources. A pod represents a single instance of an application in Kubernetes.

Controller is a higher level of abstraction in Kubernetes. Each controller represents one application pattern. A controller (the red square in the above diagram) manages copies of pods for a specific application pattern. Therefore, you don’t need to create pods directly. Instead, you create controllers to run applications in patterns.

A node is a physical or virtual machine. The master node makes global decisions about the cluster, and the worker nodes maintain pods and provide them running environment. Controllers run on the master node, and manage pods running on the worker nodes.

In this post, I’ll discuss 4 general patterns in Kubernetes: stateless, stateful, daemons, and batch. Again, each pattern is represented by one controller.

Stateless Pattern: Deployment

Stateless means that you don’t need to keep state (persistent data) in your workloads. The controller for stateless pattern is called Deployment. If you want to manage and scale stateless workloads, such as your web applications, mobile backends, or API servers, Deployment is the controller for you.

Deployment leans towards availability than consistency [1]. Deployment provides availability by creating multiple copies of the same pod. Those pods are disposable — if they become unhealthy, Deployment will just create new replacements. What’s more, you can update Deployment at a controlled rate, without a service outage. When an incident like the AWS outage happens, your workloads will automatically recover.

• Concrete examples: nginx, Tomcat

Below is a demo of deploying and rolling updating a stateless application with Deployment. In this demo, I used the Kubernetes CLI tool, kubectl, to interact with the cluster. kubectl makes asynchronous requests to the controller, tells the controller what the desired state is, and the controller will just make it so. I also created Service in the demo. Services front applications. You don’t talk to pods directly, but talk to Services. Services load balance traffic to healthy pods, so that when any pod becomes unhealthy or is being terminated, your service is still available.

Stateful Pattern: StatefulSet

For stateless applications, scale and recover is easy. However, some of your applications need to store data, like databases, cache, and message queues.
If you’re running distributed stateful workloads, such as Zookeeper, each of your stateful pod will need a stronger notion of identity.

The pods created by Deployment won’t have the same identity after being killed and recreated, and they don’t have unique persistent storage either. Therefore, we need another controller for stateful pattern: StatefulSet. Unlike Deployment, StatefulSet chooses consistency over availability. StatefulSet also manages multiple pods, but unlike Deployment, each pod of a StatefulSet has stable, unique, and sticky identity and storage. That is to say, each pod is similar but slightly different. With StatefulSet, you can deploy, scale, and delete pods in order. This is safer, and makes it easier for you to reason about your stateful applications.

• Concrete examples: Zookeeper, MongoDB, MySQL

Daemon Pattern: DaemonSet

Sometimes, you want to run daemon-like workloads on your nodes, such as running logs collection daemons or node monitoring daemons. In this case, you use DaemonSet.

DaemonSet makes sure that every node runs a copy of a pod. If you add or remove nodes, pods will be created or removed on them automatically. If you just want to run the daemons on some of the nodes, use node labels to control it — put some labels on nodes, and tell the DaemonSet “Hey, run DaemonSet pods only on nodes with these labels.”

• Concrete examples: fluentd, linkerd

Batch Pattern: Job

You might also need to run batch processing workloads in your clusters. The controller for batch workloads is called Job.

Job creates multiple pods running in parallel. You can specify how many number of pods need to complete in this Job. Job is designed for parallel processing of independent but related work items. This can be the emails to be sent, or the frames to be rendered.

Summary

So these are the only patterns that are supported in Kubernetes, right? No! They’re just the most common, general patterns that are supported in Kubernetes. In summary:

• Stateless pattern: use Deployment that provides availability, to scale and recover easily
• Stateful pattern: use StatefulSet for consistency, to give each pod a unique and sticky identity and storage, and to deploy, scale, terminate in order
• Daemon pattern: use DaemonSet, which runs one pod per node by default, or can be customized using node labels
• Batch pattern: use Job to run multiple pods in parallel and run them to completion

Now, a question you may have is “This sounds great, but where do I start? Are there examples or tools for me to move my workloads to Kubernetes?”

Yes! There are lots of great tools for you to start with, and one of which is Helm. Helm is the Kubernetes package manager. With Helm, you can download and install helm charts, the curated Kubernetes-native applications, and you start from there.

Another question you might have is “What if I need to run other patterns in Kubernetes? How do I customize?”

Kubernetes is extensible. It provides all the essential primitives, so you can write your own controllers, or use controllers others wrote. For example, ElasticSearch Operator and etcd Operator.

Kubernetes is open. It’s open for suggestions and feedback. You can send a patch or file a bug report to Kubernetes GitHub repo, or chat with us on Slack. You can also follow the latest Kubernetes news on Twitter @kubernetesio. If you have questions or want to follow up, you’re more than welcome to find me on Twitter as well.

Hope you enjoy the post!

1. https://en.wikipedia.org/wiki/CAP_theorem

Running Workloads in Kubernetes was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

It all started a month ago when Kelsey Hightower challenged the Kubernetes team to create a Kubernetes cluster from scratch in 45 minutes (without using Google Container Engine or any scripts).

Kelsey Hightower on Twitter

Advocating for users is the best part of my job. Here's how I collaborate with the Kubernetes engineering teams.pic.twitter.com/OBDYD9fshT

When your engineers have the same problems as the people they are building things for, watch how fast the problems get fixed. — Kelsey Hightower

Today, we had Kubernetes user empathy session round two!

Kelsey Hightower on Twitter

Kubernetes user empathy session round two! Continually making Kubernetes the best automation platform on the planet.pic.twitter.com/UEdyXPjtlS

The challenge my group (Brian Grant + me) picked was “Use the Kubernetes API to scale a Deployment from a Slack channel.” It was enlightening and fun building a slack bot that talks to a Kubernetes cluster. Here, I’ll show you how we created the bot.

Prerequisite

First, you’ll need a Kubernetes cluster. You can start with creating a Kubernetes cluster with Google Container Engine following the quickstart.

Slack Token and Channels

Create a new bot user in your Slack team (see Slack bot users for more details), and get an authentication token. Then invite your bot to the appropriate channels.

You also need to get the channel ids:

https://slack.com/api/channels.list?token={YOUR_TOKEN}

Create a Secret

Let’s create a Kubernetes Secret to hold your sensitive information.

kubectl create secret generic kubebot --from-literal=token=<your_token_here> --from-literal=channel=<your_channel_id_here>

Create a Deployment

Lastly, create the following kubebot Deployment that consumes the secret you just created, and that’s it!

kubectl create -f kubebot.yaml

Note that you can adjust the environment variable in your kubebot container to control who the kubebot will listen to, and what valid kubectl commands are allowed.

Interact with the Bot

Now, start asking the bot to run those kubectl commands for you.

You can read the source code of the kubebot in janetkuo/kubebot GitHub repo (forked from harbur/kubebot). It’s a Slack bot written in golang that runs kubectl when admins ask it to.

How to make a Slack bot speak Kubernetes was originally published in Dev Stash on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a recent graduate from University of Washington, one of the most amazing college campuses, I want to share its beauty with you.

All photos were taken by me using iPhone 5s. Thank you technology!