Intros

• Hello! We are:

  • ✨ Bridget Kromhout (@bridgetkromhout)

  • 💁🏻‍♀️ Karen Chu (@karenhchu)

  • 🌟 Ralph Squillace (@ralph_squillace)

• The workshop will run from 9:00am - 12:30pm

• There will be a break from 10:30am - 11:00am

• Feel free to interrupt for questions at any time

• Especially when you see full screen container pictures!

logistics-bridget.md

Say hi!

• We encourage networking at #velocityconf

• Take a minute to introduce yourself to your neighbors

• Tell them where you're from (where you're based out of & what org you work at)

• Share what you're hoping to learn in this session! ✨

logistics-bridget.md

A brief introduction

• This was initially written by Jérôme Petazzoni to support in-person, instructor-led workshops and tutorials

• Credit is also due to multiple contributors — thank you!

• You can also follow along on your own, at your own pace

• We included as much information as possible in these slides

• We recommend having a mentor to help you ...

• ... Or be comfortable spending some time reading the Kubernetes documentation ...

• ... And looking for answers on StackOverflow and other outlets

k8s/intro.md

About these slides

• All the content is available in a public GitHub repository:

  https://github.com/jpetazzo/container.training

• You can get updated "builds" of the slides there:

  http://container.training/

Chapter 1

• Our sample application

• Kubernetes concepts

• Declarative vs imperative

• Kubernetes network model

• First contact with kubectl

• Setting up Kubernetes

(auto-generated TOC)

Chapter 2

• Running our first containers on Kubernetes

• Exposing containers

• Deploying a self-hosted registry

• Exposing services internally

• Exposing services for external access

• Accessing the API with kubectl proxy

(auto-generated TOC)

Chapter 3

• The Kubernetes dashboard

• Security implications of kubectl apply

• Scaling a deployment

• Daemon sets

• Updating a service through labels and selectors

• Rolling updates

(auto-generated TOC)

Chapter 4

• Accessing logs from the CLI

• Managing stacks with Helm

• Namespaces

• Network policies

• Links and resources

• Thank you!

(auto-generated TOC)

shared/toc.md

Hands-on

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

• Each person gets a private cluster of cloud VMs (not shared with anybody else)

• All you need is a computer (or even a phone or tablet!), with:

  • an internet connection

  • a web browser

  • an SSH client

shared/prereqs.md

Versions installed

• Kubernetes 1.12.0
• Docker Engine 18.06.1-ce
• Docker Compose 1.21.1

k8s/versions-k8s.md

Our sample application

• We will clone the GitHub repository onto our node1

• 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.)

shared/sampleapp.md

Downloading and running the application

Let's start this before we look around, as downloading will take a little time...

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

shared/sampleapp.md

More detail on our sample application

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

• 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

shared/sampleapp.md

What's this application?

Our application at work

• On the left-hand side, the "rainbow strip" shows the container names

• On the right-hand side, we see the output of our containers

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

• For rng and hasher, we see HTTP access logs

shared/sampleapp.md

Connecting to the web UI

• "Logs are exciting and fun!" (No-one, ever)

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

A drawing area should show up, and after a few seconds, a blue graph will appear.

shared/sampleapp.md

Stopping the application

• If we interrupt Compose (with ^C), it will politely ask the Docker Engine to stop the app

• The Docker Engine will send a TERM signal to the containers

• If the containers do not exit in a timely manner, the Engine sends a KILL signal

Clean up

• Before moving on, let's remove those containers

shared/composedown.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)

k8s/concepts-k8s.md

Kubernetes architecture

k8s/concepts-k8s.md

Kubernetes architecture

• Ha ha ha ha

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

k8s/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)

k8s/concepts-k8s.md

Kubernetes architecture: the nodes

• The nodes executing our containers run a 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"

  (You might see that word in older articles or documentation)

k8s/concepts-k8s.md

Kubernetes architecture: the control plane

• 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 the control plane of our cluster

• The control plane is also called the "master"

k8s/concepts-k8s.md

Running the control plane on special nodes

• It is common to reserve a dedicated node for the control plane

  (Except for single-node development clusters, like when using minikube)

• This node is then called a "master"

  (Yes, this is ambiguous: is the "master" a node, or the whole control plane?)

• Normal applications are restricted from running on this node

  (By using a mechanism called "taints")

• When high availability is required, each service of the control plane must be resilient

• The control plane is then replicated on multiple nodes

  (This is sometimes called a "multi-master" setup)

k8s/concepts-k8s.md

Running the control plane outside containers

• The services of the control plane can run in or out of containers

• For instance: since etcd is a critical service, some people deploy it directly on a dedicated cluster (without containers)

  (This is illustrated on the first "super complicated" schema)

• In some hosted Kubernetes offerings (e.g. AKS, GKE, EKS), the control plane is invisible

  (We only "see" a Kubernetes API endpoint)

• In that case, there is no "master node"

For this reason, it is more accurate to say "control plane" rather than "master".

k8s/concepts-k8s.md

Default container runtime

• By default, Kubernetes uses the Docker Engine to run containers

• We could also use rkt ("Rocket") from CoreOS

• Or leverage other pluggable runtimes through the Container Runtime Interface

  (like CRI-O, or containerd)

More information about CRI on the Kubernetes blog

k8s/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)
  • IP addresses are associated with pods, not with individual containers
  • 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 api-resources

  (In Kubernetes 1.10 and prior, the command to list API resources was kubectl get)

k8s/concepts-k8s.md

Declarative vs imperative

• Our container orchestrator 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 a 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

shared/declarative.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

k8s/declarative.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

k8s/kubenet.md

Kubernetes network model: the less good

• 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)

• Pods have level 3 (IP) connectivity, but services are level 4

  (Services map to a single UDP or TCP port; no 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)

k8s/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)

• If necessary, there are alternatives to kube-proxy; e.g. kube-router

k8s/kubenet.md

The Container Network Interface (CNI)

• The CNI has a well-defined specification for network plugins

• When a pod is created, Kubernetes delegates the network setup to CNI plugins

• Typically, a CNI plugin will:

  • allocate an IP address (by calling an IPAM plugin)

  • add a network interface into the pod's network namespace

  • configure the interface as well as required routes etc.

• Using multiple plugins can be done with "meta-plugins" like CNI-Genie or Multus

• Not all CNI plugins are equal

  (e.g. they don't all implement network policies, which are required to isolate pods)

k8s/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"...

k8s/kubectlget.md

kubectl get

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

k8s/kubectlget.md

Obtaining machine-readable output

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

k8s/kubectlget.md

(Ab)using kubectl and jq

• It's super easy to build custom reports

k8s/kubectlget.md

What's available?

• kubectl has pretty good introspection facilities

• We can list all available resource types by running kubectl api-resources
  (In Kubernetes 1.10 and prior, this command used to be 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.

k8s/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 us 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 control plane pods?

• etcd is our etcd server

• kube-apiserver is the API server

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

• coredns provides DNS-based service discovery (replacing kube-dns as of 1.11)

• 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)

k8s/kubectlget.md

What about kube-public?

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

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

Other deployment options

• If you are on Azure: AKS

• If you are on Google Cloud: GKE

• If you are on AWS: EKS or kops

• On a local machine: minikube, kubespawn, Docker4Mac

• If you want something customizable: kubicorn

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

k8s/setup-k8s.md

Even more deployment options

• If you like Ansible: kubespray

• If you like Terraform: typhoon

• If you like Terraform and Puppet: tarmak

• You can also learn how to install every component manually, with the excellent tutorial Kubernetes The Hard Way

  Kubernetes The Hard Way is optimized for learning, which means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster.

• There are also many commercial options available!

• For a longer list, check the Kubernetes documentation:
  it has a great guide to pick the right solution to set up Kubernetes.

k8s/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

What are these different things?

• 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

k8s/kubectlrun.md

Our pingpong deployment

• kubectl run created a deployment, deployment.apps/pingpong

NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/pingpong   1         1         1            1           10m

• That deployment created a replica set, replicaset.apps/pingpong-xxxxxxxxxx

NAME                                  DESIRED   CURRENT   READY     AGE
replicaset.apps/pingpong-7c8bbcd9bc   1         1         1         10m

• That replica set created a pod, pod/pingpong-xxxxxxxxxx-yyyyy

NAME                            READY     STATUS    RESTARTS   AGE
pod/pingpong-7c8bbcd9bc-6c9qz   1/1       Running   0          10m

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

  • scaling, high availability, rolling updates

k8s/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!)

k8s/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

k8s/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 replicaset.apps/pingpong-xxxxxxxxxx?

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

k8s/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?

k8s/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

k8s/kubectlrun.md

What about that deprecation warning?

• As we can see from the previous slide, kubectl run can do many things

• The exact type of resource created is not obvious

• To make things more explicit, it is better to use kubectl create:

  • kubectl create deployment to create a deployment

  • kubectl create job to create a job

• Eventually, kubectl run will be used only to start one-shot pods

  (see https://github.com/kubernetes/kubernetes/pull/68132)

k8s/kubectlrun.md

Various ways of creating resources

• kubectl run

  • easy way to get started
  • versatile

• kubectl create <resource>

  • explicit, but lacks some features
  • can't create a CronJob
  • can't pass command-line arguments to deployments

• kubectl create -f foo.yaml or kubectl apply -f foo.yaml

  • all features are available
  • requires writing YAML

k8s/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.

k8s/kubectlrun.md

Aren't we flooding 1.1.1.1?

• If you're wondering this, good question!

• Don't worry, though:

  APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

  (Source: https://blog.cloudflare.com/announcing-1111/)

• It's very unlikely that our concerted pings manage to produce even a modest blip at Cloudflare's NOC!

k8s/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, CoreDNS 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

k8s/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.

k8s/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)
  • available only when the underlying infrastructure provides some "load balancer as a service"
    (e.g. AWS, Azure, GCE, OpenStack...)

• ExternalName

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

k8s/kubectlexpose.md

Running containers with open ports

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

The jpetazzo/httpenv image runs an HTTP server on port 8888.
It serves its environment variables in JSON format.

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

k8s/kubectlexpose.md

Exposing our deployment

• We'll create a default ClusterIP service

k8s/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)

k8s/kubectlexpose.md

Testing our service

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

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

k8s/ourapponkube.md

Which registry do we want to use?

• We could use the Docker Hub

• Or a service offered by our cloud provider (ACR, 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.

k8s/ourapponkube.md

Using the open source registry

• We need to run a registry container

• 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

k8s/ourapponkube.md

Deploying a self-hosted registry

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

k8s/ourapponkube.md

Connecting to our registry

• We need to find out which port has been allocated

k8s/ourapponkube.md

Testing our registry

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

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.

k8s/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".

k8s/ourapponkube.md

Deploying all the things

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

k8s/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

k8s/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)

k8s/ourapponkube.md

Accessing the web UI

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

Accessing the API with kubectl proxy

• The API requires us to authenticate¹

• There are many authentication methods available, including:

  • TLS client certificates
    (that's what we've used so far)

  • HTTP basic password authentication
    (from a static file; not recommended)

  • various token mechanisms
    (detailed in the documentation)

¹OK, we lied. If you don't authenticate, you are considered to be user system:anonymous, which doesn't have any access rights by default.

k8s/kubectlproxy.md

Accessing the API directly

• Let's see what happens if we try to access the API directly with curl

The API will tell us that user system:anonymous cannot access this path.

k8s/kubectlproxy.md

Authenticating to the API

If we wanted to talk to the API, we would need to:

• extract our TLS key and certificate information from ~/.kube/config

  (the information is in PEM format, encoded in base64)

• use that information to present our certificate when connecting

  (for instance, with openssl s_client -key ... -cert ... -connect ...)

• figure out exactly which credentials to use

  (once we start juggling multiple clusters)

• change that whole process if we're using another authentication method

🤔 There has to be a better way!

k8s/kubectlproxy.md

Using kubectl proxy for authentication

• kubectl proxy runs a proxy in the foreground

• This proxy lets us access the Kubernetes API without authentication

  (kubectl proxy adds our credentials on the fly to the requests)

• This proxy lets us access the Kubernetes API over plain HTTP

• This is a great tool to learn and experiment with the Kubernetes API

• ... And for serious usages as well (suitable for one-shot scripts)

• For unattended use, it is better to create a service account

k8s/kubectlproxy.md

Trying kubectl proxy

• Let's start kubectl proxy and then do a simple request with curl!

The output is a list of available API routes.

k8s/kubectlproxy.md

kubectl proxy is intended for local use

• By default, the proxy listens on port 8001

  (But this can be changed, or we can tell kubectl proxy to pick a port)

• By default, the proxy binds to 127.0.0.1

  (Making it unreachable from other machines, for security reasons)

• By default, the proxy only accepts connections from:

  ^localhost$,^127\.0\.0\.1$,^\[::1\]$

• This is great when running kubectl proxy locally

• Not-so-great when you want to connect to the proxy from a remote machine

k8s/kubectlproxy.md

Running kubectl proxy on a remote machine

• If we wanted to connect to the proxy from another machine, we would need to:

  • bind to INADDR_ANY instead of 127.0.0.1

  • accept connections from any address

• This is achieved with:

  kubectl proxy --port=8888 --address=0.0.0.0 --accept-hosts=.*

Do not do this on a real cluster: it opens full unauthenticated access!

k8s/kubectlproxy.md

Security considerations

• Running kubectl proxy openly is a huge security risk

• It is slightly better to run the proxy where you need it

  (and copy credentials, e.g. ~/.kube/config, to that place)

• It is even better to use a limited account with reduced permissions

k8s/kubectlproxy.md

Good to know ...

• kubectl proxy also gives access to all internal services

• Specifically, services are exposed as such:

  /api/v1/namespaces/<namespace>/services/<service>/proxy

• We can use kubectl proxy to access an internal service in a pinch

  (or, for non HTTP services, kubectl port-forward)

• This is not very useful when running kubectl directly on the cluster

  (since we could connect to the services directly anyway)

• But it is very powerful as soon as you run kubectl from a remote machine

k8s/kubectlproxy.md

The Kubernetes dashboard

• Kubernetes resources can also be viewed with a web dashboard

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

  1) actually run the dashboard

  2) bypass SSL for the dashboard

  3) bypass authentication for the dashboard

1) 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

k8s/dashboard.md

2) Bypassing SSL for the dashboard

• The Kubernetes dashboard uses HTTPS, but we don't have a certificate

• Recent versions of Chrome (63 and later) and Edge will refuse to connect

  (You won't even get the option to ignore a security warning!)

• We could (and should!) get a certificate, e.g. with Let's Encrypt

• ... But for convenience, for this workshop, we'll forward HTTP to HTTPS

Do not do this at home, or even worse, at work!

k8s/dashboard.md

Running the SSL unwrapper

• We are going to run socat, telling it to accept TCP connections and relay them over SSL

• Then we will expose that socat instance with a NodePort service

• For convenience, these steps are neatly encapsulated into another YAML file

All our dashboard traffic is now clear-text, including passwords!

k8s/dashboard.md

Connecting to the dashboard

You'll want the 3xxxx port.

The dashboard will then ask you which authentication you want to use.

k8s/dashboard.md

Dashboard authentication

• 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

k8s/dashboard.md

3) Bypass authentication for the dashboard

• The dashboard documentation explains how to do this

• We just need to load another YAML file!

Exposing the dashboard over HTTPS

• We took a shortcut by forwarding HTTP to HTTPS inside the cluster

• Let's expose the dashboard over HTTPS!

• The dashboard is exposed through a ClusterIP service (internal traffic only)

• We will change that into a NodePort service (accepting outside traffic)

Editing the kubernetes-dashboard service

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

Running the Kubernetes dashboard securely

• The steps that we just showed you are for educational purposes only!

• If you do that on your production cluster, people can and will abuse it

• For an in-depth discussion about securing the dashboard,
  check this excellent post on Heptio's blog

k8s/dashboard.md

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.)

k8s/kubectlscale.md

Daemon sets

• We want to scale rng in a way that is different from how we scaled worker

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

• What if we just scale up deploy/rng to the number of nodes?

  • nothing guarantees that the rng containers will be distributed evenly

  • if we add nodes later, they will not automatically run a copy of rng

  • if we remove (or reboot) a node, one rng container will restart elsewhere

• Instead of a deployment, we will use a daemonset

k8s/daemonset.md

Daemon sets in practice

• 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

k8s/daemonset.md

Creating a daemon set

• Unfortunately, as of Kubernetes 1.12, 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)

k8s/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's actual name is --validate=false

Checking what we've done

• Did we transform our deployment into a daemonset?

deploy/rng and ds/rng

• You can have different resource types with the same name

  (i.e. a deployment and a daemon set both named rng)

• We still have the old rng deployment

  NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/rng        1         1         1            1           18m

• But now we have the new rng daemon set as well

  NAME                DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
  daemonset.apps/rng  2        2        2      2           2          <none>         9s

k8s/daemonset.md

Too many pods

• If we check with kubectl get pods, we see:

  • one pod for the deployment (named rng-xxxxxxxxxx-yyyyy)

  • one pod per node for the daemon set (named rng-zzzzz)

  NAME                        READY     STATUS    RESTARTS   AGE
  rng-54f57d4d49-7pt82        1/1       Running   0          11m
  rng-b85tm                   1/1       Running   0          25s
  rng-hfbrr                   1/1       Running   0          25s
  [...]

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.

k8s/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

• 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)

k8s/daemonset.md

Adding our label

• Let's add a label isactive: yes

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

k8s/daemonset.md

Checking what we've done

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

k8s/daemonset.md

Cleaning up

• The pods of the deployment and the "old" daemon set are still running

• We are going to identify them programmatically

k8s/daemonset.md

Cleaning up stale pods

$ kubectl get pods
NAME                        READY     STATUS        RESTARTS   AGE
rng-54f57d4d49-7pt82        1/1       Terminating   0          51m
rng-54f57d4d49-vgz9h        1/1       Running       0          22s
rng-b85tm                   1/1       Terminating   0          39m
rng-hfbrr                   1/1       Terminating   0          39m
rng-vplmj                   1/1       Running       0          7m
rng-xbpvg                   1/1       Running       0          7m
[...]

• The extra pods (noted Terminating above) are going away

• ... But a new one (rng-54f57d4d49-vgz9h above) was restarted immediately!

Deleting a deployment

Avoiding extra pods

• When we changed the definition of the daemon set, it immediately created new pods. We had to remove the old ones manually.

• How could we have avoided this?

Labels and debugging

• When a pod is misbehaving, we can delete it: another one will be recreated

• But we can also change its labels

• It will be removed from the load balancer (it won't receive traffic anymore)

• Another pod will be recreated immediately

• But the problematic pod is still here, and we can inspect and debug it

• We can even re-add it to the rotation if necessary

  (Very useful to troubleshoot intermittent and elusive bugs)

k8s/daemonset.md

Labels and advanced rollout control

• Conversely, we can add pods matching a service's selector

• These pods will then receive requests and serve traffic

• Examples:

  • one-shot pod with all debug flags enabled, to collect logs

  • pods created automatically, but added to rotation in a second step
    (by setting their label accordingly)

• This gives us building blocks for canary and blue/green deployments

k8s/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, ¯\_(ツ)_/¯

k8s/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)

k8s/rollout.md

Checking current rollout parameters

• Recall how we build custom reports with kubectl and jq:

k8s/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

k8s/rollout.md

Building a new version of the worker service

k8s/rollout.md

Rolling out the new worker service

Give it some time

• At first, it looks like nothing is happening (the graph remains at the same level)

• According to kubectl get deploy -w, the deployment was updated really quickly

• But kubectl get pods -w tells a different story

• The old pods are still here, and they stay in Terminating state for a while

• Eventually, they are terminated; and then the graph decreases significantly

• This delay is due to the fact that our worker doesn't handle signals

• Kubernetes sends a "polite" shutdown request to the worker, which ignores it

• After a grace period, Kubernetes gets impatient and kills the container

  (The grace period is 30 seconds, but can be changed if needed)

k8s/rollout.md

Rolling out something invalid

• What happens if we make a mistake?

What's going on with our rollout?

• Why is our app a bit slower?

• Because MaxUnavailable=25%

  ... So the rollout terminated 2 replicas out of 10 available

• Okay, but why do we see 5 new replicas being rolled out?

• Because MaxSurge=25%

  ... So in addition to replacing 2 replicas, the rollout is also starting 3 more

• It rounded down the number of MaxUnavailable pods conservatively,
  but the total number of pods being rolled out is allowed to be 25+25=50%

k8s/rollout.md

Checking the dashboard during the bad rollout

If you haven't deployed the Kubernetes dashboard earlier, just skip this slide.

Note the 3xxxx port.

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

k8s/rollout.md

Changing rollout parameters

• We want to:

  • revert to v0.1
  • be conservative on availability (always have desired number of available workers)
  • go slow on rollout speed (update only 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: 1
  minReadySeconds: 10

k8s/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

k8s/rollout.md

Accessing logs from the CLI

• The kubectl logs commands has limitations:

  • it cannot stream logs from multiple pods at a time

  • when showing logs from multiple pods, it mixes them all together

• We are going to see how to do it better

k8s/logs-cli.md

Doing it manually

• We could (if we were so inclined), write a program or script that would:

  • take a selector as an argument

  • enumerate all pods matching that selector (with kubectl get -l ...)

  • fork one kubectl logs --follow ... command per container

  • annotate the logs (the output of each kubectl logs ... process) with their origin

  • preserve ordering by using kubectl logs --timestamps ... and merge the output

Stern

Stern is an open source project by Wercker.

From the README:

Stern allows you to tail multiple pods on Kubernetes and multiple containers within the pod. Each result is color coded for quicker debugging.

The query is a regular expression so the pod name can easily be filtered and you don't need to specify the exact id (for instance omitting the deployment id). If a pod is deleted it gets removed from tail and if a new pod is added it automatically gets tailed.

Exactly what we need!

k8s/logs-cli.md

Installing Stern

• Run stern (without arguments) to check if it's installed:

  $ stern
  Tail multiple pods and containers from Kubernetes
  Usage:
  stern pod-query [flags]

• If it is not installed, the easiest method is to download a binary release

• The following commands will install Stern on a Linux Intel 64 bit machine:

  sudo curl -L -o /usr/local/bin/stern \
     https://github.com/wercker/stern/releases/download/1.8.0/stern_linux_amd64
  sudo chmod +x /usr/local/bin/stern

k8s/logs-cli.md

Using Stern

• There are two ways to specify the pods for which we want to see the logs:

  • -l followed by a selector expression (like with many kubectl commands)

  • with a "pod query", i.e. a regex used to match pod names

• These two ways can be combined if necessary

k8s/logs-cli.md

Stern convenient options

• The --tail N flag shows the last N lines for each container

  (Instead of showing the logs since the creation of the container)

• The -t / --timestamps flag shows timestamps

• The --all-namespaces flag is self-explanatory

k8s/logs-cli.md

Using Stern with a selector

• When specifying a selector, we can omit the value for a label

• This will match all objects having that label (regardless of the value)

• Everything created with kubectl run has a label run

• We can use that property to view the logs of all the pods created with kubectl run

k8s/logs-cli.md

Managing stacks with Helm

• We created our first resources with kubectl run, kubectl expose ...

• We have also created resources by loading YAML files with kubectl apply -f

• For larger stacks, managing thousands of lines of YAML is unreasonable

• These YAML bundles need to be customized with variable parameters

  (E.g.: number of replicas, image version to use ...)

• It would be nice to have an organized, versioned collection of bundles

• It would be nice to be able to upgrade/rollback these bundles carefully

• Helm is an open source project offering all these things!

k8s/helm.md

Helm concepts

• helm is a CLI tool

• tiller is its companion server-side component

• A "chart" is an archive containing templatized YAML bundles

• Charts are versioned

• Charts can be stored on private or public repositories

k8s/helm.md

Installing Helm

• If the helm CLI is not installed in your environment, install it

k8s/helm.md

Installing Tiller

• Tiller is composed of a service and a deployment in the kube-system namespace

• They can be managed (installed, upgraded...) with the helm CLI

If Tiller was already installed, don't worry: this won't break it.

At the end of the install process, you will see:

Happy Helming!

k8s/helm.md

Fix account permissions

• Helm permission model requires us to tweak permissions

• In a more realistic deployment, you might create per-user or per-team service accounts, roles, and role bindings

(Defining the exact roles and permissions on your cluster requires a deeper knowledge of Kubernetes' RBAC model. The command above is fine for personal and development clusters.)

k8s/helm.md

View available charts

• A public repo is pre-configured when installing Helm

• We can view available charts with helm search (and an optional keyword)

k8s/helm.md

Install a chart

• Most charts use LoadBalancer service types by default

• Most charts require persistent volumes to store data

• We need to relax these requirements a bit

Where do these --set options come from?

k8s/helm.md

Inspecting a chart

• helm inspect shows details about a chart (including available options)

The chart's metadata includes an URL to the project's home page.

(Sometimes it conveniently points to the documentation for the chart.)

k8s/helm.md

Creating a chart

• We are going to show a way to create a very simplified chart

• In a real chart, lots of things would be templatized

  (Resource names, service types, number of replicas...)

k8s/helm.md

Exporting the YAML for our application

• The following section assumes that DockerCoins is currently running

k8s/helm.md

Testing our helm chart

Namespaces

• We cannot have two resources with the same name

  (Or can we...?)

Pre-existing namespaces

• If we deploy a cluster with kubeadm, we have three namespaces:

  • default (for our applications)

  • kube-system (for the control plane)

  • kube-public (contains one secret used for cluster discovery)

• If we deploy differently, we may have different namespaces

k8s/namespaces.md

Creating namespaces

• Creating a namespace is done with the kubectl create namespace command:

  kubectl create namespace blue

• We can also get fancy and use a very minimal YAML snippet, e.g.:

  kubectl apply -f- <<EOF
  apiVersion: v1
  kind: Namespace
  metadata:
    name: blue
  EOF

• The two methods above are identical

• If we are using a tool like Helm, it will create namespaces automatically

k8s/namespaces.md

Using namespaces

• We can pass a -n or --namespace flag to most kubectl commands:

  kubectl -n blue get svc

• We can also use contexts

• A context is a (user, cluster, namespace) tuple

• We can manipulate contexts with the kubectl config command

k8s/namespaces.md

Creating a context

• We are going to create a context for the blue namespace

We have created a context; but this is just some configuration values.

The namespace doesn't exist yet.

k8s/namespaces.md

Using a context

• Let's switch to our new context and deploy the DockerCoins chart

In the last command line, dockercoins is just the local path where we created our Helm chart before.

k8s/namespaces.md

Viewing the deployed app

• Let's see if our Helm chart worked correctly!

Note: it might take a minute or two for the app to be up and running.

k8s/namespaces.md

Namespaces and isolation

• Namespaces do not provide isolation

• A pod in the green namespace can communicate with a pod in the blue namespace

• A pod in the default namespace can communicate with a pod in the kube-system namespace

• CoreDNS uses a different subdomain for each namespace

• Example: from any pod in the cluster, you can connect to the Kubernetes API with:

  https://kubernetes.default.svc.cluster.local:443/

k8s/namespaces.md

Isolating pods

• Actual isolation is implemented with network policies

• Network policies are resources (like deployments, services, namespaces...)

• Network policies specify which flows are allowed:

  • between pods

  • from pods to the outside world

  • and vice-versa

k8s/namespaces.md

Switch back to the default namespace

• Let's make sure that we don't run future exercises in the blue namespace

k8s/namespaces.md

Switching namespaces more easily

• Defining a new context for each namespace can be cumbersome

• We can also alter the current context with this one-liner:

  kubectl config set-context --current --namespace=foo

• We can also use a little helper tool called kubens:

  # Switch to namespace foo
  kubens foo
  # Switch back to the previous namespace
  kubens -

k8s/namespaces.md

kubens and kubectx

• With kubens, we can switch quickly between namespaces

• With kubectx, we can switch quickly between contexts

• Both tools are simple shell scripts available from https://github.com/ahmetb/kubectx

• On our clusters, they are installed as kns and kctx

  (for brevity and to avoid completion clashes between kubectx and kubectl)

k8s/namespaces.md

kube-ps1

• It's easy to lose track of our current cluster / context / namespace

• kube-ps1 makes it easy to track these, by showing them in our shell prompt

• It's a simple shell script available from https://github.com/jonmosco/kube-ps1

• On our clusters, kube-ps1 is installed and included in PS1:

  [123.45.67.89] (kubernetes-admin@kubernetes:default) docker@node1 ~

  (The highlighted part is context:namespace, managed by kube-ps1)

• Highly recommended if you work across multiple contexts or namespaces!

k8s/namespaces.md

Network policies

• Namespaces help us to organize resources

• Namespaces do not provide isolation

• By default, every pod can contact every other pod

• By default, every service accepts traffic from anyone

• If we want this to be different, we need network policies

k8s/netpol.md

What's a network policy?

A network policy is defined by the following things.

• A pod selector indicating which pods it applies to

  e.g.: "all pods in namespace blue with the label zone=internal"

• A list of ingress rules indicating which inbound traffic is allowed

  e.g.: "TCP connections to ports 8000 and 8080 coming from pods with label zone=dmz, and from the external subnet 4.42.6.0/24, except 4.42.6.5"

• A list of egress rules indicating which outbound traffic is allowed

A network policy can provide ingress rules, egress rules, or both.

k8s/netpol.md

How do network policies apply?

• A pod can be "selected" by any number of network policies

• If a pod isn't selected by any network policy, then its traffic is unrestricted

  (In other words: in the absence of network policies, all traffic is allowed)

• If a pod is selected by at least one network policy, then all traffic is blocked ...

  ... unless it is explicitly allowed by one of these network policies

k8s/netpol.md

Pod-to-pod traffic

• Connections from pod A to pod B have to be allowed by both pods:

  • pod A has to be unrestricted, or allow the connection as an egress rule

  • pod B has to be unrestricted, or allow the connection as an ingress rule

• As a consequence: if a network policy restricts traffic going from/to a pod,
  the restriction cannot be overridden by a network policy selecting another pod

• This prevents an entity managing network policies in namespace A (but without permission to do so in namespace B) from adding network policies giving them access to namespace B

k8s/netpol.md

The rationale for network policies

• In network security, it is generally considered better to "deny all, then allow selectively"

  (The other approach, "allow all, then block selectively" makes it too easy to leave holes)

• As soon as one network policy selects a pod, the pod enters this "deny all" logic

• Further network policies can open additional access

• Good network policies should be scoped as precisely as possible

• In particular: make sure that the selector is not too broad

  (Otherwise, you end up affecting pods that were otherwise well secured)

k8s/netpol.md

Our first network policy

This is our game plan:

• run a web server in a pod

• create a network policy to block all access to the web server

• create another network policy to allow access only from specific pods

k8s/netpol.md

Running our test web server

The curl command should show us the "Welcome to nginx!" page.

k8s/netpol.md

Adding a very restrictive network policy

• The policy will select pods with the label run=testweb

• It will specify an empty list of ingress rules (matching nothing)

The curl command should now time out.

k8s/netpol.md

Looking at the network policy

This is the file that we applied:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-all-for-testweb
spec:
  podSelector:
    matchLabels:
      run: testweb
  ingress: []

k8s/netpol.md

Allowing connections only from specific pods

• We want to allow traffic from pods with the label run=testcurl

• Reminder: this label is automatically applied when we do kubectl run testcurl ...