63
Kubernetes me This Batman Or I how I quit worrying and learned to love container clustering

Kubernetes Me this Batman

Embed Size (px)

Citation preview

Kubernetes me This Batman

Or I how I quit worrying and learned to love container clustering

Disclaimer: I don’t work for google. Also, still mad about Google Reader. RIP sweet prince.

Presentation Schedule● Part 0: What Does This Have to Do With Batman?● Part 1: Kubernetes is very opinionated but I agree with

most of them.● Part 2: All about drawings.● Part 3: Demo Time!

Part 0: What Does This Have To Do With

Batman?

I like to think that I am Batman✓ Does not have superpowers

✓ Relies on his intuition and mental skills

✓ Has lots of cool gadgets

✓ Likes to surprise people

I like to DevOp and love to play with new tools to fight crime downtime

one day I started playing with containers because everyone else was doing it and that never went poorly so why not. (looks inviting)

And then I was gonna launch all my containers in production and wow all my friends (because my wife doesn’t get wowed by containers).

This was the result. It was not good. No-one was wowed.

And then I heard about this Kubernetes thing. And wanted to learn how to use it.

Kubernetes was like the Riddler to me✓ Likes to confuse people

✓ Is clever but not funny

✓ Does a lot of taunting

✓ Made me feel dumb

After a class at Oscon and some good ol’ learnin, I was able to outsmart the Riddler Kubernetes.

Part 1: Kubernetes is very opinionated but I agree with

most of them.

I was told memes were good to have in a presentation. Here is one right off the bat.

From Chapter 4 of Getting Real by 37 Signals

The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

Running and scheduling containers is a very opinionated field.

Google has an opinion called Kubernetes.● Pronounced /koo-ber-nay'-tace/. It’s actually a Greek

term for “ship master”.● Developed at Google. The third iteration of container

management.○ Daddy was Omega.○ Grandaddy was Borg.

● Kubernetes is not a PaaS, but you can build one with it.● Google says that Kubernetes is planet scale.

k8sBTW, Google wants you to stop writing Kubernetes and use

this clever acronym instead. Although it technically should be pronounced “Kates”.

This is the Kubernetes logo. The lack of symmetry bugs me.

There are two big ideas in Kubernetes: labels and Pods.

Pods

● For the most part …● Pods can contain one or more containers.● The containers in a pod are scheduled on the same node.● Everything in Kubernetes is some flavor of of pod or an

extension of the pod spec.● Remember this for now, we’ll get back to it in a second.

A pod is a collection of containers.

Pods are flat files. No, really. Like YAML or JSON (boo*).apiVersion: v1kind: Podmetadata: name: "" labels: name: "" namespace: "" annotations: [] generateName: ""spec: ? "// See 'The spec schema' for details." : ~

{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "", "labels": { "name": "" }, "generateName": "", "namespace": "", "annotations": [] }, "spec": {

// See 'The spec schema' for details.

}}

*Font size 14 vs font size 10, YAML is the clear winner. Especially in the context of Shannon’s Information Theory. The same density of information can be transmitted in less lines with YAML.

Pods. Both of these are the same.apiVersion: v1kind: Podmetadata: name: redis-django labels: app: webspec: containers: - name: key-value-store image: redis ports: - containerPort: 6379 - name: frontend image: django ports: - containerPort: 8000

K8S Node 1redis-django pod 1

redis container

django container

some-other pod

K8S Node 2redis-django pod 2

redis container

django container

redis-django pod 3

redis container

django container

The Pod Lifecycle in a ClusterLet’s say you want to fire up a pod. With kubectl you would:

1. Make a Pod request to the API server using a local pod definition file.

2. The API server saves the info for the pod in ETCD.3. The scheduler finds the unscheduled pod and schedules it

to a node.4. Kubelet sees the pod scheduled and fires up docker.5. Docker runs the container.

The entire lifecycle state of the pod is stored in ETCD.

Most of the things in Kubernetes are built on top of Pods.

Labels

Labels and selectors are the fairy dust in k8s.● A label is a key-value pair that is assigned to objects

in k8s.○ Pods, services, lots of things can have labels.

● A selector is a way to filter for labels that match a certain criteria or logic.○ There are two types of selectors:

■ Equality based■ Set based

An example of each."labels": { "environment" : "prod", "type" : "nginx"}

environment = prodtype != nginx

"labels": { "environment" : "prod", "type" : "redis"}

environment = prodtype != nginx

No

Yes"labels": { "environment" : "prod", "type" : "redis"}

environment in (prod, qa)type notin (nginx, mysql)!partitionYes

When one thing in k8s needs to find another thing in k8s, it uses labels.

The K8S Cluster

A basic cluster.K8S Node 1

redis-django pod 1

redis container

django container

some-other pod

K8S Node 2redis-django pod 2

redis container

django container

redis-django pod 3

redis container

django container

K8S Master

SkyDns pod

ETCD pod

Kibana pod

Grafana pod

Elasticsearch pod

Heapster pod

basic-cluster-01

bonus stuff● When you launch a

cluster, you get some built in services.

● Each one of these has their own endpoints and / or UIs.

● They run on the master directly though you could schedule them across the cluster or other masters.

● To find the endpoints type: kubectl cluster-info

Heapster

Namespaces.

A Virtual Cluster in Your Cluster● A namespace as an isolated section of a cluster.● It’s a virtual cluster in your cluster. ● Each cluster can have multiple namespaces.● The root services have their own.● Namespaces are in network isolation from each other and

can are (normally) used to house different environments on the same cluster.

Part 2: All about drawings.

Let’s look at a Kubernetes cluster diagram.

This diagram is a bit small, let’s break it down.

The master● Everything is done via

kubectl, which then makes calls against the kube-apiserver.

● The Controller Manager, Scheduler Service, and ETCD can be spread across nodes based on cluster size.

● All state about everything is stored in ETCD.

● Also, kubelet is running here too (more on that next slide).

The Node● The name of the agent

process is called kubelet. Think “cubed omelette”.

● The kubelet process manages the Pods, including containers & volumes.

● The kube-proxy service handles network routing and service exposure.

A master is a master because it has the api services and scheduler. The state is all in etcd.

Kubernetes objects.

My mental model of k8s● I find it easiest to think of everything as a variation

of a Pod or another object.● Google has done a very good job at extending base objects

to add flexibility or support new features.● This also means that the Pod spec is relatively stable

given the massive list of features that is dropped every release.

What k8s looks like in my head.PodSpec

Container

Replica SetPodSpec

Container

Replication Controller

PodSpec

Container

Daemon SetPodSpec

Container

Pet SetPodSpec

Container

Deployment

Replica SetPodSpec

Container

ServicePod

ServicePod

Ingress Service

SpecContainer

JobPodSpec

Container

Or this.

The Base Things in Containers are called Specs (Not like Dust, like Specification)● The only required field is

containers.○ And it requires two entries

■ name■ image

● restartPolicy is for all containers in a pod.

● volumes are volumes (duh) that any container in a pod can mount.

● The spec is very extensible by design.

Spec

Container

Then there is the pod● Specs don’t do anything by

themselves; for that you need a pod.

● Pods are just collections of containers that share a few things:○ Access to volumes.○ Networking.○ Are co-located.

● Pods can be run by themselves but have no guarantee to restart or stay running or scale or do anything useful really.

Pod

Spec

Container

Services.● Services point to a Pod.● … or to an external source.● With Pods a virtual endpoint is

created then routed to using the kube-proxy.

● For non-pod services a virtual IP in the cluster is used to route externally.

Service

Pod

Ingress Service = AWS API Gateway.● An Ingress Controller sits at the

boundary of the cluster and routes requests to Services.

● One Ingress Controller can handle multiple domains.

● Each route can point to a different Service.

● Relies on the creation of an Ingress Controller in the cluster (another service that is not enabled by default).

Service

Pod

Ingress Service

Daemon sets. Scary.● Daemons is an object that ensures that a copy

of each Pod runs on each node.● This is commonly used to make sure side-car

containers are running across the cluster.● If new nodes come up they’ll get a copy of the

daemon set and will come up.● Daemon sets don’t have scaling rules.

Daemon SetPodSpec

Container

Pet sets. Not so scary.● New in 1.3, Pet Sets allow you to create

complex microservices across the cluster.● They have the ability to set dependency on

other containers.● They require:

○ A stable hostname, available in DNS○ An ordinal index○ Stable storage: linked to the ordinal &

hostname● It’s for launching a cluster in your cluster.

Pet SetPodSpec

Container

Replication Controller (deprecated)● A Replication Controller was the best way to

run Pods. ● You set a number of pods to run and the

Replication Controller made sure that the number was running across the cluster.

● Rolling updates could be performed by starting a new Replication Controller and scaling up.

Replication Controller

PodSpec

Container

Replcia Set. The new hotness.● A Replica Set differs from the Replication

Controller because it can be updated.● If you update the Replica Set template you can

fire and update and automatically roll changes.

● Roll backs are also built in.● These are not designed to use directly. For

that you need ...

PodSpec

Container

Replica Set

Deployments. The king of the hill.● A Deployment controls the running state of

Pods and Replica Sets.● In k8s 1.3 it is the primary object you should

be manipulating.● Deployments have:

○ History.○ Rolling updates.○ Pausing updates.○ Roll-backs.

Deployment

Replica SetPodSpec

Container

There’s more stuff too.

Other stuff.● Secrets:

○ K8s comes with a built-in secret store that is namespaced and uses labels to control pod read access.

● Network Policies:○ You can use labels to define whitelist rules between pods.

● Persistent Volumes:○ These live outside of normal pod volumes and can be used for shared

storage for things like databases. Yes, databases in containers.

● Ubernetes:○ A way to cluster your clusters.

Part 3: Demo Time!

You Only Need a Computer, BTW● Minikube

○ https://github.com/kubernetes/minikube

○ Runs a Kubernetes node on top of your favorite (probably Virtualbox) VM.

○ Lots of involvement from the K8s community.

● Kube-solo○ https://github.com/TheNewNormal/kube-solo-osx○ Uses the Corectl app to run a Kube VM.○ Also has a multi-node version.

On to Minikube!

FIN

Contact me!keybase.io/richardboydii

@richardboydii

richardboydii.com

coutnzer0.com