Intros

• Hello! We are Jérôme (@jpetazzo, Docker Inc.) & AJ (@s0ulshake, Travis CI)

Logistics

• The tutorial will run from 9:00am to 12:15pm

• There will be a coffee break at 10:30am
  (please remind me if I forget about it!)

• This will be fast-paced, but DON'T PANIC!
  (all the content is publicly available)

• Feel free to interrupt for questions at any time

• Live feedback, questions, help on Gitter

(inline)

About these slides

• Your one-stop shop to awesomeness:

  http://container.training/

• The content that you're viewing right now is in a public GitHub repository:

  https://github.com/jpetazzo/orchestration-workshop

• Typos? Mistakes? Questions? Feel free to hover over the bottom of the slide ...

Chapter 1

• Pre-requirements

• Our sample application

• Running the application

• Identifying bottlenecks

(auto-generated TOC)

Chapter 2

• Kubernetes concepts

• Declarative vs imperative

• Kubernetes network model

• First contact with kubectl

• Setting up Kubernetes

• Running our first containers on Kubernetes

(auto-generated TOC)

Chapter 3

• Exposing containers

• Deploying a self-hosted registry

• Exposing services internally

• Exposing services for external access

• The Kubernetes dashboard

• Security implications of kubectl apply

(auto-generated TOC)

Chapter 4

• Scaling a deployment

• Daemon sets

• Updating a service through labels and selectors

• Rolling updates

• Next steps

(inline)

Pre-requirements

• Computer with internet connection and a web browser

• For instructor-led workshops: an SSH client to connect to remote machines

  • on Linux, OS X, FreeBSD... you are probably all set

  • on Windows, get putty, Microsoft Win32 OpenSSH, Git BASH, or MobaXterm

• A tiny little bit of Docker knowledge

  (that's totally OK if you're not a Docker expert!)

kube/prereqs-k8s.md

Hands-on sections

• The whole workshop is hands-on

• We will see Docker and Kubernetes in action

• You are invited to reproduce all the demos

• All hands-on sections are clearly identified, like the gray rectangle below

kube/prereqs-k8s.md

We will (mostly) interact with node1 only

• Unless instructed, all commands must be run from the first VM, node1

• We will only checkout/copy the code on node1

• During normal operations, we do not need access to the other nodes

• If we had to troubleshoot issues, we would use a combination of:

  • SSH (to access system logs, daemon status...)

  • Docker API (to check running containers and container engine status)

kube/prereqs-k8s.md

Terminals

Once in a while, the instructions will say:
"Open a new terminal."

There are multiple ways to do this:

• create a new window or tab on your machine, and SSH into the VM;

• use screen or tmux on the VM and open a new window from there.

You are welcome to use the method that you feel the most comfortable with.

kube/prereqs-k8s.md

Tmux cheatsheet

• Ctrl-b c → creates a new window
• Ctrl-b n → go to next window
• Ctrl-b p → go to previous window
• Ctrl-b " → split window top/bottom
• Ctrl-b % → split window left/right
• Ctrl-b Alt-1 → rearrange windows in columns
• Ctrl-b Alt-2 → rearrange windows in rows
• Ctrl-b arrows → navigate to other windows
• Ctrl-b d → detach session
• tmux attach → reattach to session

kube/prereqs-k8s.md

Brand new versions!

• Kubernetes 1.8
• Docker Engine 17.10
• Docker Compose 1.16

kube/versions-k8s.md

Our sample application

• Visit the GitHub repository with all the materials of this workshop:
  https://github.com/jpetazzo/orchestration-workshop

• The application is in the dockercoins subdirectory

• Let's look at the general layout of the source code:

  there is a Compose file docker-compose.yml ...

  ... and 4 other services, each in its own directory:

  • rng = web service generating random bytes
  • hasher = web service computing hash of POSTed data
  • worker = background process using rng and hasher
  • webui = web interface to watch progress

common/sampleapp.md

Links, naming, and service discovery

• Containers can have network aliases (resolvable through DNS)

• Compose file version 2+ makes each container reachable through its service name

• Compose file version 1 did require "links" sections

• Our code can connect to services using their short name

  (instead of e.g. IP address or FQDN)

• Network aliases are automatically namespaced

  (i.e. you can have multiple apps declaring and using a service named database)

common/sampleapp.md

Example in worker/worker.py

common/sampleapp.md

What's this application?

common/sampleapp.md

What's this application?

• It is a DockerCoin miner! 💰🐳📦🚢

Getting the application source code

• We will clone the GitHub repository

• The repository also contains scripts and tools that we will use through the workshop

(You can also fork the repository on GitHub and clone your fork if you prefer that.)

common/sampleapp.md

Running the application

Without further ado, let's start our application.

Compose tells Docker to build all container images (pulling the corresponding base images), then starts all containers, and displays aggregated logs.

common/sampleapp.md

Lots of logs

• The application continuously generates logs

• We can see the worker service making requests to rng and hasher

• Let's put that in the background

• ^C stops all containers by sending them the TERM signal

• Some containers exit immediately, others take longer
  (because they don't handle SIGTERM and end up being killed after a 10s timeout)

common/sampleapp.md

Restarting in the background

• Many flags and commands of Compose are modeled after those of docker

docker-compose ps also shows the ports exposed by the application.

common/sampleapp.md

Connecting to the web UI

• The webui container exposes a web dashboard; let's view it

You should see a speed of approximately 4 hashes/second.

More precisely: 4 hashes/second, with regular dips down to zero.
This is because Jérôme is incapable of writing good frontend code.
Don't ask. Seriously, don't ask. This is embarrassing.

common/sampleapp.md

Scaling up the application

• Our goal is to make that performance graph go up (without changing a line of code!)

Looking at resource usage

• Let's look at CPU, memory, and I/O usage

We have available resources.

• Why?
• How can we use them?

common/sampleapp.md

Scaling workers on a single node

• Docker Compose supports scaling
• Let's scale worker and see what happens!

common/sampleapp.md

Adding more workers

• Great, let's add more workers and call it a day, then!

common/sampleapp.md

Identifying bottlenecks

• You should have seen a 3x speed bump (not 10x)

• Adding workers didn't result in linear improvement

• Something else is slowing us down

Accessing internal services

• rng and hasher are exposed on ports 8001 and 8002

• This is declared in the Compose file:

  ...
  rng:
    build: rng
    ports:
    - "8001:80"
  hasher:
    build: hasher
    ports:
    - "8002:80"
  ...

common/sampleapp.md

Measuring latency under load

We will use httping.

rng has a much higher latency than hasher.

common/sampleapp.md

Let's draw hasty conclusions

• The bottleneck seems to be rng

• What if we don't have enough entropy and can't generate enough random numbers?

• We need to scale out the rng service on multiple machines!

Note: this is a fiction! We have enough entropy. But we need a pretext to scale out.

(In fact, the code of rng uses /dev/urandom, which never runs out of entropy...
...and is just as good as /dev/random.)

common/sampleapp.md

Clean up

• Before moving on, let's remove those containers

common/sampleapp.md

Kubernetes concepts

• Kubernetes is a container management system

• It runs and manages containerized applications on a cluster

Basic things we can ask Kubernetes to do

Other things that Kubernetes can do for us

• Basic autoscaling

• Blue/green deployment, canary deployment

• Long running services, but also batch (one-off) jobs

• Overcommit our cluster and evict low-priority jobs

• Run services with stateful data (databases etc.)

• Fine-grained access control defining what can be done by whom on which resources

• Integrating third party services (service catalog)

• Automating complex tasks (operators)

kube/concepts-k8s.md

Kubernetes architecture

kube/concepts-k8s.md

Kubernetes architecture

• Ha ha ha ha

• OK, I was trying to scare you, it's much simpler than that ❤️

kube/concepts-k8s.md

Credits

• The first schema is a Kubernetes cluster with storage backed by multi-path iSCSI

  (Courtesy of Yongbok Kim)

• The second one is a simplified representation of a Kubernetes cluster

  (Courtesy of Imesh Gunaratne)

kube/concepts-k8s.md

Kubernetes architecture: the master

• The Kubernetes logic (its "brains") is a collection of services:

  • the API server (our point of entry to everything!)
  • core services like the scheduler and controller manager
  • etcd (a highly available key/value store; the "database" of Kubernetes)

• Together, these services form what is called the "master"

• These services can run straight on a host, or in containers
  (that's an implementation detail)

• etcd can be run on separate machines (first schema) or co-located (second schema)

• We need at least one master, but we can have more (for high availability)

kube/concepts-k8s.md

Kubernetes architecture: the nodes

• The nodes executing our containers run another collection of services:

  • a container Engine (typically Docker)
  • kubelet (the "node agent")
  • kube-proxy (a necessary but not sufficient network component)

• Nodes were formerly called "minions"

• It is customary to not run apps on the node(s) running master components

  (Except when using small development clusters)

kube/concepts-k8s.md

Do we need to run Docker at all?

No!

Do we need to run Docker at all?

Yes!

Do we need to run Docker at all?

• On our development environments, CI pipelines ... :

  Yes, almost certainly

• On our production servers:

  Yes (today)

  Probably not (in the future)

More information about CRI on the Kubernetes blog.

kube/concepts-k8s.md

Kubernetes resources

• The Kubernetes API defines a lot of objects called resources

• These resources are organized by type, or Kind (in the API)

• A few common resource types are:

  • node (a machine — physical or virtual — in our cluster)
  • pod (group of containers running together on a node)
  • service (stable network endpoint to connect to one or multiple containers)
  • namespace (more-or-less isolated group of things)
  • secret (bundle of sensitive data to be passed to a container)

  And much more! (We can see the full list by running kubectl get)

kube/concepts-k8s.md

Declarative vs imperative

• Kubernetes puts a very strong emphasis on being declarative

• Declarative:

  I would like a cup of tea.

• Imperative:

  Boil some water. Pour it in a teapot. Add tea leaves. Steep for a while. Serve in cup.

Declarative vs imperative

• What declarative would really be:

  I want a cup of tea, obtained by pouring an infusion¹ of tea leaves in a cup.

Declarative vs imperative

• Imperative systems:

  • simpler

  • if a task is interrupted, we have to restart from scratch

• Declarative systems:

  • if a task is interrupted (or if we show up to the party half-way through), we can figure out what's missing and do only what's necessary

  • we need to be able to observe the system

  • ... and compute a "diff" between what we have and what we want

kube/concepts-k8s.md

Declarative vs imperative in Kubernetes

• Virtually everything we create in Kubernetes is created from a spec

• Watch for the spec fields in the YAML files later!

• The spec describes how we want the thing to be

• Kubernetes will reconcile the current state with the spec
  (technically, this is done by a number of controllers)

• When we want to change some resource, we update the spec

• Kubernetes will then converge that resource

kube/concepts-k8s.md

Kubernetes network model

• TL,DR:

  Our cluster (nodes and pods) is one big flat IP network.

Kubernetes network model: the good

• Everything can reach everything

• No address translation

• No port translation

• No new protocol

• Pods cannot move from a node to another and keep their IP address

• IP addresses don't have to be "portable" from a node to another

  (We can use e.g. a subnet per node and use a simple routed topology)

• The specification is simple enough to allow many various implementations

kube/kubenet.md

Kubernetes network model: the bad and the ugly

• Everything can reach everything

  • if you want security, you need to add network policies

  • the network implementation that you use needs to support them

• There are literally dozens of implementations out there

  (15 are listed in the Kubernetes documentation)

• It looks like you have a level 3 network, but it's only level 4

  (The spec requires UDP and TCP, but not port ranges or arbitrary IP packets)

• kube-proxy is on the data path when connecting to a pod or container,
  and it's not particularly fast (relies on userland proxying or iptables)

kube/kubenet.md

Kubernetes network model: in practice

• The nodes that we are using have been set up to use Weave

• We don't endorse Weave in a particular way, it just Works For Us

• Don't worry about the warning about kube-proxy performance

• Unless you:

  • routinely saturate 10G network interfaces

  • count packet rates in millions per second

  • run high-traffic VOIP or gaming platforms

  • do weird things that involve millions of simultaneous connections
    (in which case you're already familiar with kernel tuning)

kube/kubenet.md

First contact with kubectl

• kubectl is (almost) the only tool we'll need to talk to Kubernetes

• It is a rich CLI tool around the Kubernetes API

  (Everything you can do with kubectl, you can do directly with the API)

• On our machines, there is a ~/.kube/config file with:

  • the Kubernetes API address

  • the path to our TLS certificates used to authenticate

• You can also use the --kubeconfig flag to pass a config file

• Or directly --server, --user, etc.

• kubectl can be pronounced "Cube C T L", "Cube cuttle", "Cube cuddle"...

kube/kubectlget.md

kubectl get

• Let's look at our Node resources with kubectl get!

kube/kubectlget.md

From human-readable to machine-readable output

• kubectl get can output JSON, YAML, or be directly formatted

kube/kubectlget.md

(Ab)using kubectl and jq

• It's super easy to build custom reports

kube/kubectlget.md

What's available?

• kubectl has pretty good introspection facilities

• We can list all available resource types by running kubectl get

• We can view details about a resource with:

  kubectl describe type/name
  kubectl describe type name

• We can view the definition for a resource type with:

  kubectl explain type

Each time, type can be singular, plural, or abbreviated type name.

kube/kubectlget.md

Services

• A service is a stable endpoint to connect to "something"

  (In the initial proposal, they were called "portals")

ClusterIP services

• A ClusterIP service is internal, available from the cluster only

• This is useful for introspection from within containers

Listing running containers

• Containers are manipulated through pods

• A pod is a group of containers:

  • running together (on the same node)

  • sharing resources (RAM, CPU; but also network, volumes)

Namespaces

• Namespaces allow to segregate resources

Accessing namespaces

• By default, kubectl uses the default namespace

• We can switch to a different namespace with the -n option

What are all these pods?

• etcd is our etcd server

• kube-apiserver is the API server

• kube-controller-manager and kube-scheduler are other master components

• kube-dns is an additional component (not mandatory but super useful, so it's there)

• kube-proxy is the (per-node) component managing port mappings and such

• weave is the (per-node) component managing the network overlay

• the READY column indicates the number of containers in each pod

• the pods with a name ending with -node1 are the master components
  (they have been specifically "pinned" to the master node)

kube/kubectlget.md

Setting up Kubernetes

• How did we set up these Kubernetes clusters that we're using?

kubeadm drawbacks

• Doesn't set up Docker or any other container engine

• Doesn't set up the overlay network

• Scripting is complex
  (because extracting the token requires advanced kubectl commands)

• Doesn't set up multi-master (no high availability)

Other deployment options

• If you are on Google Cloud: GKE

  Empirically the best Kubernetes deployment out there

• If you are on AWS: kops

  ... But with AWS re:invent just around the corner, expect some changes

• On a local machine: minikube, kubespawn, Docker4Mac (coming soon)

• If you want something customizable: kubicorn

  Probably the closest to a multi-cloud/hybrid solution so far, but in development

• Also, many commercial options!

kube/setup-k8s.md

Running our first containers on Kubernetes

• First things first: we cannot run a container

Starting a simple pod with kubectl run

• We need to specify at least a name and the image we want to use

Behind the scenes of kubectl run

• Let's look at the resources that were created by kubectl run

Deployments, replica sets, and replication controllers

• A deployment is a high-level construct

  • allows scaling, rolling updates, rollbacks

  • multiple deployments can be used together to implement a canary deployment

  • delegates pods management to replica sets

• A replica set is a low-level construct

  • makes sure that a given number of identical pods are running

  • allows scaling

  • rarely used directly

• A replication controller is the (deprecated) predecessor of a replica set

kube/kubectlrun.md

Our pingpong deployment

• kubectl run created a deployment, deploy/pingpong

• That deployment created a replica set, rs/pingpong-xxxx

• That replica set created a pod, po/pingpong-yyyy

• We'll see later how these folks play together for:

  • scaling

  • high availability

  • rolling updates

kube/kubectlrun.md

Viewing container output

• Let's use the kubectl logs command

• We will pass either a pod name, or a type/name

  (E.g. if we specify a deployment or replica set, it will get the first pod in it)

• Unless specified otherwise, it will only show logs of the first container in the pod

  (Good thing there's only one in ours!)

kube/kubectlrun.md

Streaming logs in real time

• Just like docker logs, kubectl logs supports convenient options:

  • -f/--follow to stream logs in real time (à la tail -f)

  • --tail to indicate how many lines you want to see (from the end)

  • --since to get logs only after a given timestamp

kube/kubectlrun.md

Scaling our application

• We can create additional copies of our container (I mean, our pod) with kubectl scale

Note: what if we tried to scale rs/pingpong-xxxx?

We could! But the deployment would notice it right away, and scale back to the initial level.

kube/kubectlrun.md

Resilience

• The deployment pingpong watches its replica set

• The replica set ensures that the right number of pods are running

• What happens if pods disappear?

kube/kubectlrun.md

What if we wanted something different?

• What if we wanted to start a "one-shot" container that doesn't get restarted?

• We could use kubectl run --restart=OnFailure or kubectl run --restart=Never

• These commands would create jobs or pods instead of deployments

• Under the hood, kubectl run invokes "generators" to create resource descriptions

• We could also write these resource descriptions ourselves (typically in YAML),
  and create them on the cluster with kubectl apply -f (discussed later)

• With kubectl run --schedule=..., we can also create cronjobs

kube/kubectlrun.md

Viewing logs of multiple pods

• When we specify a deployment name, only one single pod's logs are shown

• We can view the logs of multiple pods by specifying a selector

• A selector is a logic expression using labels

• Conveniently, when you kubectl run somename, the associated objects have a run=somename label

Unfortunately, --follow cannot (yet) be used to stream the logs from multiple containers.

kube/kubectlrun.md

Exposing containers

• kubectl expose creates a service for existing pods

• A service is a stable address for a pod (or a bunch of pods)

• If we want to connect to our pod(s), we need to create a service

• Once a service is created, kube-dns will allow us to resolve it by name

  (i.e. after creating service hello, the name hello will resolve to something)

• There are different types of services, detailed on the following slides:

  ClusterIP, NodePort, LoadBalancer, ExternalName

kube/kubectlexpose.md

Basic service types

• ClusterIP (default type)

  • a virtual IP address is allocated for the service (in an internal, private range)
  • this IP address is reachable only from within the cluster (nodes and pods)
  • our code can connect to the service using the original port number

• NodePort

  • a port is allocated for the service (by default, in the 30000-32768 range)
  • that port is made available on all our nodes and anybody can connect to it
  • our code must be changed to connect to that new port number

These service types are always available.

Under the hood: kube-proxy is using a userland proxy and a bunch of iptables rules.

kube/kubectlexpose.md

More service types

• LoadBalancer

  • an external load balancer is allocated for the service
  • the load balancer is configured accordingly
    (e.g.: a NodePort service is created, and the load balancer sends traffic to that port)

• ExternalName

  • the DNS entry managed by kube-dns will just be a CNAME to a provided record
  • no port, no IP address, no nothing else is allocated

The LoadBalancer type is currently only available on AWS, Azure, and GCE.

kube/kubectlexpose.md

Running containers with open ports

• Since ping doesn't have anything to connect to, we'll have to run something else

The -w option "watches" events happening on the specified resources.

Note: please DO NOT call the service search. It would collide with the TLD.

kube/kubectlexpose.md

Exposing our deployment

• We'll create a default ClusterIP service

kube/kubectlexpose.md

Services are layer 4 constructs

• You can assign IP addresses to services, but they are still layer 4

  (i.e. a service is not an IP address; it's an IP address + protocol + port)

• This is caused by the current implementation of kube-proxy

  (it relies on mechanisms that don't support layer 3)

• As a result: you have to indicate the port number for your service

• Running services with arbitrary port (or port ranges) requires hacks

  (e.g. host networking mode)

kube/kubectlexpose.md

Testing our service

• We will now send a few HTTP requests to our ElasticSearch pods

What's on the menu?

In this part, we will:

• build images for our app,

• ship these images with a registry,

• run deployments using these images,

• expose these deployments so they can communicate with each other,

• expose the web UI so we can access it from outside.

kube/ourapponkube.md

The plan

• Build on our control node (node1)

• Tag images so that they are named $REGISTRY/servicename

• Upload them to a registry

• Create deployments using the images

• Expose (with a ClusterIP) the services that need to communicate

• Expose (with a NodePort) the WebUI

kube/ourapponkube.md

Which registry do we want to use?

• We could use the Docker Hub

• Or a service offered by our cloud provider (GCR, ECR...)

• Or we could just self-host that registry

We'll self-host the registry because it's the most generic solution for this workshop.

kube/ourapponkube.md

Using the open source registry

• We need to run a registry:2 container
  (make sure you specify tag :2 to run the new version!)

• It will store images and layers to the local filesystem
  (but you can add a config file to use S3, Swift, etc.)

• Docker requires TLS when communicating with the registry

  • unless for registries on 127.0.0.0/8 (i.e. localhost)

  • or with the Engine flag --insecure-registry

• Our strategy: publish the registry container on a NodePort,
  so that it's available through 127.0.0.1:xxxxx on each node

kube/ourapponkube.md

Deploying a self-hosted registry

• We will deploy a registry container, and expose it with a NodePort

kube/ourapponkube.md

Connecting to our registry

• We need to find out which port has been allocated

kube/ourapponkube.md

Testing our registry

• A convenient Docker registry API route to remember is /v2/_catalog

Testing our local registry

• We can retag a small image, and push it to the registry

kube/ourapponkube.md

Checking again what's on our local registry

• Let's use the same endpoint as before

The curl command should now output:

{"repositories":["busybox"]}

kube/ourapponkube.md

Building and pushing our images

• We are going to use a convenient feature of Docker Compose

Let's have a look at the dockercoins.yml file while this is building and pushing.

kube/ourapponkube.md

version: "3"
services:
  rng:
    build: dockercoins/rng
    image: ${REGISTRY-127.0.0.1:5000}/rng:${TAG-latest}
    deploy:
      mode: global
  ...
  redis:
    image: redis
  ...
  worker:
    build: dockercoins/worker
    image: ${REGISTRY-127.0.0.1:5000}/worker:${TAG-latest}
    ...
    deploy:
      replicas: 10

Just in case you were wondering ... Docker "services" are not Kubernetes "services".

kube/ourapponkube.md

Deploying all the things

• We can now deploy our code (as well as a redis instance)

kube/ourapponkube.md

Is this working?

• After waiting for the deployment to complete, let's look at the logs!

  (Hint: use kubectl get deploy -w to watch deployment events)

Exposing services internally

• Three deployments need to be reachable by others: hasher, redis, rng

• worker doesn't need to be exposed

• webui will be dealt with later

kube/ourapponkube.md

Is this working yet?

• The worker has an infinite loop, that retries 10 seconds after an error

Exposing services for external access

• Now we would like to access the Web UI

• We will expose it with a NodePort

  (just like we did for the registry)

kube/ourapponkube.md

Accessing the web UI

• We can now connect to any node, on the allocated node port, to view the web UI

The Kubernetes dashboard

• Kubernetes resources can also be viewed with a web dashboard

• We are going to deploy that dashboard with three commands:

  • one to actually run the dashboard

  • one to make the dashboard available from outside

  • one to bypass authentication for the dashboard

Running the dashboard

• We need to create a deployment and a service for the dashboard

• But also a secret, a service account, a role and a role binding

• All these things can be defined in a YAML file and created with kubectl apply -f

The goo.gl URL expands to:
https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

kube/dashboard.md

Making the dashboard reachable from outside

• The dashboard is exposed through a ClusterIP service

• We need a NodePort service instead

Editing the kubernetes-dashboard service

• If we look at the YAML that we loaded just before, we'll get a hint

Connecting to the dashboard

• We have three authentication options at this point:

  • token (associated with a role that has appropriate permissions)

  • kubeconfig (e.g. using the ~/.kube/config file from node1)

  • "skip" (use the dashboard "service account")

• Let's use "skip": we get a bunch of warnings and don't see much

kube/dashboard.md

Granting more rights to the dashboard

• The dashboard documentation explains how to do

• We just need to load another YAML file!

Security implications of kubectl apply

• When we do kubectl apply -f <URL>, we create arbitrary resources

• Resources can be evil; imagine a deployment that ...

kubectl apply is the new curl | sh

• curl | sh is convenient

• It's safe if you use HTTPS URLs from trusted sources

Scaling a deployment

• We will start with an easy one: the worker deployment

After a few seconds, the graph in the web UI should show up.
(And peak at 10 hashes/second, just like when we were running on a single one.)

kube/kubectlscale.md

Daemon sets

• Remember: we did all that cluster orchestration business for rng

• We want one (and exactly one) instance of rng per node

• If we just scale deploy/rng to 4, nothing guarantees that they spread

• Instead of a deployment, we will use a daemonset

• Daemon sets are great for cluster-wide, per-node processes:

  • kube-proxy
  • weave (our overlay network)
  • monitoring agents
  • hardware management tools (e.g. SCSI/FC HBA agents)
  • etc.

• They can also be restricted to run only on some nodes

kube/daemonset.md

Creating a daemon set

• Unfortunately, as of Kubernetes 1.8, the CLI cannot create daemon sets

Creating the YAML file for our daemon set

• Let's start with the YAML file for the current rng resource

Note: --export will remove "cluster-specific" information, i.e.:

• namespace (so that the resource is not tied to a specific namespace)
• status and creation timestamp (useless when creating a new resource)
• resourceVersion and uid (these would cause... interesting problems)

kube/daemonset.md

"Casting" a resource to another

• What if we just changed the kind field?

  (It can't be that easy, right?)

Understanding the problem

• The core of the error is:

  error validating data:
  [ValidationError(DaemonSet.spec):
  unknown field "replicas" in io.k8s.api.extensions.v1beta1.DaemonSetSpec,
  ...

Use the --force, Luke

• We could also tell Kubernetes to ignore these errors and try anyway

• The --force flag actual name is --validate=false

Checking what we've done

• Did we transform our deployment into a daemonset?

Explanation

• You can have different resource types with the same name

  (i.e. a deployment and a daemonset both named rng)

• We still have the old rng deployment

• But now we have the new rng daemonset as well

• If we look at the pods, we have:

  • one pod for the deployment

  • one pod per node for the daemonset

kube/daemonset.md

What are all these pods doing?

• Let's check the logs of all these rng pods

• All these pods have a run=rng label:

  • the first pod, because that's what kubectl run does
  • the other ones (in the daemon set), because we copied the spec from the first one

• Therefore, we can query everybody's logs using that run=rng selector

The magic of selectors

• The rng service is load balancing requests to a set of pods

• This set of pods is defined as "pods having the label run=rng"

When we created additional pods with this label, they were automatically detected by svc/rng and added as endpoints to the associated load balancer.

kube/daemonset.md

Removing the first pod from the load balancer

• What would happen if we removed that pod, with kubectl delete pod ...?

Deep dive into selectors

• Let's look at the selectors for the rng deployment and the associated replica set

Updating a service through labels and selectors

• What if we want to drop the rng deployment from the load balancer?

• Option 1:

  • destroy it

• Option 2:

  • add an extra label to the daemon set

  • update the service selector to refer to that label

Add an extra label to the daemon set

• We will update the daemon set "spec"

• Option 1:

  • edit the rng.yml file that we used earlier

  • load the new definition with kubectl apply

• Option 2:

  • use kubectl edit

We've put resources in your resources all the way down

• Reminder: a daemon set is a resource that creates more resources!

• There is a difference between:

  • the label(s) of a resource (in the metadata block in the beginning)

  • the selector of a resource (in the spec block)

  • the label(s) of the resource(s) created by the first resource (in the template block)

• You need to update the selector and the template (metadata labels are not mandatory)

• The template must match the selector

  (i.e. the resource will refuse to create resources that it will not select)

kube/daemonset.md

Adding our label

• Let's add a label isactive: yes

• In YAML, yes should be quoted; i.e. isactive: "yes"

kube/daemonset.md

Checking what we've done

The timestamps should give us a hint about how many pods are currently receiving traffic.

kube/daemonset.md

More labels, more selectors, more problems?

• Bonus exercise 1: clean up the pods of the "old" daemon set

• Bonus exercise 2: how could we have done to avoid creating new pods?

kube/daemonset.md

Rolling updates

• By default (without rolling updates), when a scaled resource is updated:

  • new pods are created

  • old pods are terminated

  • ... all at the same time

  • if something goes wrong, ¯\_(ツ)_/¯

kube/rollout.md

Rolling updates

• With rolling updates, when a resource is updated, it happens progressively

• Two parameters determine the pace of the rollout: maxUnavailable and maxSurge

• They can be specified in absolute number of pods, or percentage of the replicas count

• At any given time ...

  • there will always be at least replicas-maxUnavailable pods available

  • there will never be more than replicas+maxSurge pods in total

  • there will therefore be up to maxUnavailable+maxSurge pods being updated

• We have the possibility to rollback to the previous version
  (if the update fails or is unsatisfactory in any way)

kube/rollout.md

Rolling updates in practice

• As of Kubernetes 1.8, we can do rolling updates with:

  deployments, daemonsets, statefulsets

• Editing one of these resources will automatically result in a rolling update

• Rolling updates can be monitored with the kubectl rollout subcommand

kube/rollout.md

Building a new version of the worker service

kube/rollout.md

Rolling out the new version of the worker service

Rolling out a boo-boo

• What happens if we make a mistake?

Recovering from a bad rollout

• We could push some v0.3 image

  (the pod retry logic will eventually catch it and the rollout will proceed)

• Or we could invoke a manual rollback

kube/rollout.md

Changing rollout parameters

• We want to:

  • revert to v0.1
  • be conservative on availability (always have desired number of available workers)
  • be aggressive on rollout speed (update more than one pod at a time)
  • give some time to our workers to "warm up" before starting more

The corresponding changes can be expressed in the following YAML snippet:

spec:
  template:
    spec:
      containers:
      - name: worker
        image: $REGISTRY/worker:v0.1
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 3
  minReadySeconds: 10

kube/rollout.md

Applying changes through a YAML patch

• We could use kubectl edit deployment worker

• But we could also use kubectl patch with the exact YAML shown before

kube/rollout.md

Next steps

Alright, how do I get started and containerize my apps?

Namespaces

• Namespaces let you run multiple identical stacks side by side

• Two namespaces (e.g. blue and green) can each have their own redis service

• Each of the two redis services has its own ClusterIP

• kube-dns creates two entries, mapping to these two ClusterIP addresses:

  redis.blue.svc.cluster.local and redis.green.svc.cluster.local

• Pods in the blue namespace get a search suffix of blue.svc.cluster.local

• As a result, resolving redis from a pod in the blue namespace yields the "local" redis

This does not provide isolation! That would be the job of network policies.

kube/whatsnext.md

Stateful services (databases etc.)

• As a first step, it is wiser to keep stateful services outside of the cluster

• Exposing them to pods can be done with multiple solutions:

  • ExternalName services
    (redis.blue.svc.cluster.local will be a CNAME record)

  • ClusterIP services with explicit Endpoints
    (instead of letting Kubernetes generate the endpoints from a selector)

  • Ambassador services
    (application-level proxies that can provide credentials injection and more)

kube/whatsnext.md

Stateful services (second take)

• If you really want to host stateful services on Kubernetes, you can look into:

  • volumes (to carry persistent data)

  • storage plugins

  • persistent volume claims (to ask for specific volume characteristics)

  • stateful sets (pods that are not ephemeral)

kube/whatsnext.md

HTTP traffic handling

• Services are layer 4 constructs

• HTTP is a layer 7 protocol

• It is handled by ingresses (a different resource kind)

• Ingresses allow:

  • virtual host routing
  • session stickiness
  • URI mapping
  • and much more!

• Check out e.g. Træfik

kube/whatsnext.md

Logging and metrics

• Logging is delegated to the container engine

• Metrics are typically handled with Prometheus

  (Heapster is a popular add-on)

kube/whatsnext.md

Managing the configuration of our applications

• Two constructs are particularly useful: secrets and config maps

• They allow to expose arbitrary information to our containers

• Avoid storing configuration in container images

  (There are some exceptions to that rule, but it's generally a Bad Idea)

• Never store sensitive information in container images

  (It's the container equivalent of the password on a post-it note on your screen)

kube/whatsnext.md

Managing stack deployments

• The best deployment tool will vary, depending on:

  • the size and complexity of your stack(s)
  • how often you change it (i.e. add/remove components)
  • the size and skills of your team

• A few examples:

  • shell scripts invoking kubectl
  • YAML resources descriptions committed to a repo
  • Helm (~package manager)
  • Spinnaker (Netflix' CD platform)

kube/whatsnext.md

Cluster federation

Cluster federation

• Kubernetes master operation relies on etcd

• etcd uses the Raft protocol

• Raft recommends low latency between nodes

• What if our cluster spreads multiple regions?

Developer experience

I've put this last, but it's pretty important!

• How do you on-board a new developer?

• What do they need to install to get a dev stack?

• How does a code change make it from dev to prod?

• How does someone add a component to a stack?

kube/whatsnext.md