Intros

• Hello! We are:

  • 👷🏻‍♀️ AJ (@s0ulshake, EphemeraSearch)

  • 🐳 Jérôme (@jpetazzo, Enix SAS)

• The training will run from 9:30 to 13:00

• There will be a break at 11:00

• Feel free to interrupt for questions at any time

• Especially when you see full screen container pictures!

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

Accessing these slides now

• We recommend that you open these slides in your browser:

  https://2020-06-enix.container.training/

• Use arrows to move to next/previous slide

  (up, down, left, right, page up, page down)

• Type a slide number + ENTER to go to that slide

• The slide number is also visible in the URL bar

  (e.g. .../#123 for slide 123)

shared/about-slides.md

Accessing these slides later

• Slides will remain online so you can review them later if needed

  (let's say we'll keep them online at least 1 year, how about that?)

• You can download the slides using that URL:

  https://2020-06-enix.container.training/slides.zip

  (then open the file 5.yml.html)

• You will to find new versions of these slides on:

  https://container.training/

shared/about-slides.md

These slides are open source

• You are welcome to use, re-use, share these slides

• These slides are written in markdown

• The sources of these slides are available in a public GitHub repository:

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

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

👇 Try it! The source file will be shown and you can view it on GitHub and fork and edit it.

shared/about-slides.md

Chat room

• We've set up a chat room that we will monitor during the workshop

• Don't hesitate to use it to ask questions, or get help, or share feedback

• The chat room will also be available after the workshop

• Join the chat room: Gitter

• Say hi in the chat room!

shared/chat-room-im.md

Module 1

• Pre-requirements

• Kubernetes architecture

• The Kubernetes API

• Other control plane components

• Building our own cluster

(auto-generated TOC)

Module 2

• Adding nodes to the cluster

• The Container Network Interface

• Interconnecting clusters

(auto-generated TOC)

Module 3

• API server availability

• Setting up Kubernetes

• Running a local development cluster

• Deploying a managed cluster

• Kubernetes distributions and installers

• Static pods

• Upgrading clusters

• Backing up clusters

(auto-generated TOC)

Module 4

• Pod Security Policies

• The CSR API

• OpenID Connect

(auto-generated TOC)

shared/toc.md

Pre-requirements

• Kubernetes concepts

  (pods, deployments, services, labels, selectors)

• Hands-on experience working with containers

  (building images, running them; doesn't matter how exactly)

• Familiar with the UNIX command-line

  (navigating directories, editing files, using kubectl)

k8s/prereqs-admin.md

Labs and exercises

• We are going to build and break multiple clusters

• Everyone will get their own private environment(s)

• You are invited to reproduce all the demos (but you don't have to)

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

k8s/prereqs-admin.md

Private environments

• Each person gets their own private set of VMs

• Each person should have a printed card with connection information

• We will connect to these VMs with SSH

  (if you don't have an SSH client, install one now!)

k8s/prereqs-admin.md

Doing or re-doing this on your own?

• We are using basic cloud VMs with Ubuntu LTS

• Kubernetes packages or binaries have been installed

  (depending on what we want to accomplish in the lab)

• We disabled IP address checks

  • we want to route pod traffic directly between nodes

  • most cloud providers will treat pod IP addresses as invalid

  • ... and filter them out; so we disable that filter k8s/prereqs-admin.md

Kubernetes architecture

We can arbitrarily split Kubernetes in two parts:

• the nodes, a set of machines that run our containerized workloads;

• the control plane, a set of processes implementing the Kubernetes APIs.

Kubernetes also relies on underlying infrastructure:

• servers, network connectivity (obviously!),

• optional components like storage systems, load balancers ...

k8s/architecture.md

Control plane location

The control plane can run:

• in containers, on the same nodes that run other application workloads

  (example: Minikube; 1 node runs everything, kind)

• on a dedicated node

  (example: a cluster installed with kubeadm)

• on a dedicated set of nodes

  (example: Kubernetes The Hard Way; kops)

• outside of the cluster

  (example: most managed clusters like AKS, EKS, GKE)

k8s/architecture.md

What runs on a node

• Our containerized workloads

• A container engine like Docker, CRI-O, containerd...

  (in theory, the choice doesn't matter, as the engine is abstracted by Kubernetes)

• kubelet: an agent connecting the node to the cluster

  (it connects to the API server, registers the node, receives instructions)

• kube-proxy: a component used for internal cluster communication

  (note that this is not an overlay network or a CNI plugin!)

k8s/architecture.md

What's in the control plane

• Everything is stored in etcd

  (it's the only stateful component)

• Everyone communicates exclusively through the API server:

  • we (users) interact with the cluster through the API server

  • the nodes register and get their instructions through the API server

  • the other control plane components also register with the API server

• API server is the only component that reads/writes from/to etcd

k8s/architecture.md

Communication protocols: API server

• The API server exposes a REST API

  (except for some calls, e.g. to attach interactively to a container)

• Almost all requests and responses are JSON following a strict format

• For performance, the requests and responses can also be done over protobuf

  (see this design proposal for details)

• In practice, protobuf is used for all internal communication

  (between control plane components, and with kubelet)

k8s/architecture.md

Communication protocols: on the nodes

The kubelet agent uses a number of special-purpose protocols and interfaces, including:

• CRI (Container Runtime Interface)

  • used for communication with the container engine
  • abstracts the differences between container engines
  • based on gRPC+protobuf

• CNI (Container Network Interface)

  • used for communication with network plugins
  • network plugins are implemented as executable programs invoked by kubelet
  • network plugins provide IPAM
  • network plugins set up network interfaces in pods

k8s/architecture.md

The Kubernetes API

The Kubernetes API server is a "dumb server" which offers storage, versioning, validation, update, and watch semantics on API resources.

(Clayton Coleman, Kubernetes Architect and Maintainer)

What does that mean?

k8s/architecture.md

The Kubernetes API is declarative

• We cannot tell the API, "run a pod"

• We can tell the API, "here is the definition for pod X"

• The API server will store that definition (in etcd)

• Controllers will then wake up and create a pod matching the definition

k8s/architecture.md

The core features of the Kubernetes API

• We can create, read, update, and delete objects

• We can also watch objects

  (be notified when an object changes, or when an object of a given type is created)

• Objects are strongly typed

• Types are validated and versioned

• Storage and watch operations are provided by etcd

  (note: the k3s project allows us to use sqlite instead of etcd)

k8s/architecture.md

Let's experiment a bit!

• For the exercises in this section, connect to the first node of the test cluster

k8s/architecture.md

Create

• Let's create a simple object

This is equivalent to kubectl create namespace hello.

k8s/architecture.md

Read

• Let's retrieve the object we just created

We see a lot of data that wasn't here when we created the object.

Some data was automatically added to the object (like spec.finalizers).

Some data is dynamic (typically, the content of status.)

k8s/architecture.md

API requests and responses

• Almost every Kubernetes API payload (requests and responses) has the same format:

  apiVersion: xxx
  kind: yyy
  metadata:
    name: zzz
    (more metadata fields here)
  (more fields here)

• The fields shown above are mandatory, except for some special cases

  (e.g.: in lists of resources, the list itself doesn't have a metadata.name)

• We show YAML for convenience, but the API uses JSON

  (with optional protobuf encoding)

k8s/architecture.md

Update

• Let's update our namespace object

• There are many ways to do that, including:

  • kubectl apply (and provide an updated YAML file)
  • kubectl edit
  • kubectl patch
  • many helpers, like kubectl label, or kubectl set

• In each case, kubectl will:

  • get the current definition of the object
  • compute changes
  • submit the changes (with PATCH requests)

k8s/architecture.md

Adding a label

• For demonstration purposes, let's add a label to the namespace

• The easiest way is to use kubectl label

We demonstrated update and watch semantics.

k8s/architecture.md

What's special about watch?

• The API server itself doesn't do anything: it's just a fancy object store

• All the actual logic in Kubernetes is implemented with controllers

• A controller watches a set of resources, and takes action when they change

• Examples:

  • when a Pod object is created, it gets scheduled and started

  • when a Pod belonging to a ReplicaSet terminates, it gets replaced

  • when a Deployment object is updated, it can trigger a rolling update

k8s/architecture.md

Other control plane components

• API server ✔️

• etcd ✔️

• Controller manager

• Scheduler

k8s/architecture.md

Controller manager

• This is a collection of loops watching all kinds of objects

• That's where the actual logic of Kubernetes lives

• When we create a Deployment (e.g. with kubectl create deployment web --image=nginx),

  • we create a Deployment object

  • the Deployment controller notices it, and creates a ReplicaSet

  • the ReplicaSet controller notices the ReplicaSet, and creates a Pod

k8s/architecture.md

Scheduler

• When a pod is created, it is in Pending state

• The scheduler (or rather: a scheduler) must bind it to a node

  • Kubernetes comes with an efficient scheduler with many features

  • if we have special requirements, we can add another scheduler
    (example: this demo scheduler uses the cost of nodes, stored in node annotations)

• A pod might stay in Pending state for a long time:

  • if the cluster is full

  • if the pod has special constraints that can't be met

  • if the scheduler is not running (!)

19,000 words

They say, "a picture is worth one thousand words."

The following 19 slides show what really happens when we run:

kubectl create deployment web --image=nginx

k8s/deploymentslideshow.md

Building our own cluster

• Let's build our own cluster!

  Perfection is attained not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint-Exupery)

• Our goal is to build a minimal cluster allowing us to:

  • create a Deployment (with kubectl create deployment)
  • expose it with a Service
  • connect to that service

• "Minimal" here means:

  • smaller number of components
  • smaller number of command-line flags
  • smaller number of configuration files

k8s/dmuc.md

Non-goals

• For now, we don't care about security

• For now, we don't care about scalability

• For now, we don't care about high availability

• All we care about is simplicity

k8s/dmuc.md

Our environment

• We will use the machine indicated as dmuc1

  (this stands for "Dessine Moi Un Cluster" or "Draw Me A Sheep",
  in homage to Saint-Exupery's "The Little Prince")

• This machine:

  • runs Ubuntu LTS

  • has Kubernetes, Docker, and etcd binaries installed

  • but nothing is running

k8s/dmuc.md

Checking our environment

• Let's make sure we have everything we need first

k8s/dmuc.md

The plan

1. Start API server

2. Interact with it (create Deployment and Service)

3. See what's broken

4. Fix it and go back to step 2 until it works!

k8s/dmuc.md

Dealing with multiple processes

• We are going to start many processes

• Depending on what you're comfortable with, you can:

  • open multiple windows and multiple SSH connections

  • use a terminal multiplexer like screen or tmux

  • put processes in the background with &
    (warning: log output might get confusing to read!)

k8s/dmuc.md

Starting API server

Since the API server stores everything in etcd, it cannot start without it.

k8s/dmuc.md

Starting etcd

Success!

Note the last line of output:

serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!

Sure, that's discouraged. But thanks for telling us the address!

k8s/dmuc.md

Starting API server (for real)

• Try again, passing the --etcd-servers argument

• That argument should be a comma-separated list of URLs

Success!

k8s/dmuc.md

Interacting with API server

• Let's try a few "classic" commands

We should get No resources found. and the kubernetes service, respectively.

Note: the API server automatically created the kubernetes service entry.

k8s/dmuc.md

Creating a Deployment

• Let's run a web server!

Success?

k8s/dmuc.md

Checking our Deployment status

Our Deployment is in bad shape:

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   0/1     0            0           2m26s

And, there is no ReplicaSet, and no Pod.

k8s/dmuc.md

What's going on?

• We stored the definition of our Deployment in etcd

  (through the API server)

• But there is no controller to do the rest of the work

• We need to start the controller manager

k8s/dmuc.md

Starting the controller manager

The final error message is:

invalid configuration: no configuration has been provided

But the logs include another useful piece of information:

Neither --kubeconfig nor --master was specified.
Using the inClusterConfig.  This might not work.

k8s/dmuc.md

Reminder: everyone talks to API server

• The controller manager needs to connect to the API server

• It does not have a convenient localhost:8080 default

• We can pass the connection information in two ways:

  • --master and a host:port combination (easy)

  • --kubeconfig and a kubeconfig file

• For simplicity, we'll use the first option

k8s/dmuc.md

Starting the controller manager (for real)

Success!

k8s/dmuc.md

Checking our Deployment status

We now have a ReplicaSet.

But we still don't have a Pod.

k8s/dmuc.md

What's going on?

In the controller manager logs, we should see something like this:

E0404 15:46:25.753376   22847 replica_set.go:450] Sync "default/web-5bc9bd5b8d"
failed with No API token found for service account "default", retry after the
token is automatically created and added to the service account

• The service account default was automatically added to our Deployment

  (and to its pods)

• The service account default exists

• But it doesn't have an associated token

  (the token is a secret; creating it requires signature; therefore a CA)

k8s/dmuc.md

Solving the missing token issue

There are many ways to solve that issue.

We are going to list a few (to get an idea of what's happening behind the scenes).

Of course, we don't need to perform all the solutions mentioned here.

k8s/dmuc.md

Option 1: disable service accounts

• Restart the API server with --disable-admission-plugins=ServiceAccount

• The API server will no longer add a service account automatically

• Our pods will be created without a service account

k8s/dmuc.md

Option 2: do not mount the (missing) token

• Add automountServiceAccountToken: false to the Deployment spec

  or

• Add automountServiceAccountToken: false to the default ServiceAccount

• The ReplicaSet controller will no longer create pods referencing the (missing) token

k8s/dmuc.md

Option 3: set up service accounts properly

• This is the most complex option!

• Generate a key pair

• Pass the private key to the controller manager

  (to generate and sign tokens)

• Pass the public key to the API server

  (to verify these tokens)

k8s/dmuc.md

Continuing without service account token

• Once we patch the default service account, the ReplicaSet can create a Pod

Note: we might have to wait a bit for the ReplicaSet controller to retry.

If we're impatient, we can restart the controller manager.

k8s/dmuc.md

What's next?

• Our pod exists, but it is in Pending state

• Remember, we don't have a node so far

  (kubectl get nodes shows an empty list)

• We need to:

  • start a container engine

  • start kubelet

k8s/dmuc.md

Starting a container engine

• We're going to use Docker (because it's the default option)

Success!

Feel free to check that it actually works with e.g.:

docker run alpine echo hello world

k8s/dmuc.md

Starting kubelet

• If we start kubelet without arguments, it will start

• But it will not join the cluster!

• It will start in standalone mode

• Just like with the controller manager, we need to tell kubelet where the API server is

• Alas, kubelet doesn't have a simple --master option

• We have to use --kubeconfig

• We need to write a kubeconfig file for kubelet

k8s/dmuc.md

Writing a kubeconfig file

• We can copy/paste a bunch of YAML

• Or we can generate the file with kubectl

k8s/dmuc.md

Our ~/.kube/config file

The file that we generated looks like the one below.

That one has been slightly simplified (removing extraneous fields), but it is still valid.

apiVersion: v1
kind: Config
current-context: localhost
contexts:
- name: localhost
  context:
    cluster: localhost
clusters:
- name: localhost
  cluster:
    server: http://localhost:8080

k8s/dmuc.md

Starting kubelet

Success!

k8s/dmuc.md

Looking at our 1-node cluster

• Let's check that our node registered correctly

Our node should show up.

Its name will be its hostname (it should be dmuc1).

k8s/dmuc.md

Are we there yet?

• Let's check if our pod is running

Scheduling our pod

• Why do we need a scheduling decision, since we have only one node?

• The node might be full, unavailable; the pod might have constraints ...

• The easiest way to schedule our pod is to start the scheduler

  (we could also schedule it manually)

k8s/dmuc.md

Starting the scheduler

• The scheduler also needs to know how to connect to the API server

• Just like for controller manager, we can use --kubeconfig or --master

• Our pod should now start correctly

k8s/dmuc.md

Checking the status of our pod

• Our pod will go through a short ContainerCreating phase

• Then it will be Running

Success!

k8s/dmuc.md

Connecting to our pod

• Let's check that our pod correctly runs NGINX

We should see the Welcome to nginx! page.

k8s/dmuc.md

Exposing our Deployment

• We can now create a Service associated with this Deployment

Starting kube-proxy

• kube-proxy also needs to connect to the API server

• It can work with the --master flag

  (although that will be deprecated in the future)

k8s/dmuc.md

Connecting to our Service

• Now that kube-proxy is running, we should be able to connect

Success!

k8s/dmuc.md

Adding nodes to the cluster

• So far, our cluster has only 1 node

• Let's see what it takes to add more nodes

• We are going to use another set of machines: kubenet

k8s/multinode.md

The environment

• We have 3 identical machines: kubenet1, kubenet2, kubenet3

• The Docker Engine is installed (and running) on these machines

• The Kubernetes packages are installed, but nothing is running

• We will use kubenet1 to run the control plane

k8s/multinode.md

The plan

• Start the control plane on kubenet1

• Join the 3 nodes to the cluster

• Deploy and scale a simple web server

k8s/multinode.md

Running the control plane

• We will use a Compose file to start the control plane components

k8s/multinode.md

Checking the control plane status

• Before moving on, verify that the control plane works

k8s/multinode.md

Joining the nodes

• We need to generate a kubeconfig file for kubelet

• This time, we need to put the public IP address of kubenet1

  (instead of localhost or 127.0.0.1)

k8s/multinode.md

Distributing the kubeconfig file

• We need that kubeconfig file on the other nodes, too

k8s/multinode.md

Starting kubelet

• Reminder: kubelet needs to run as root; don't forget sudo!

k8s/multinode.md

Checking cluster status

• We should now see all 3 nodes

• At first, their STATUS will be NotReady

• They will move to Ready state after approximately 10 seconds

k8s/multinode.md

Deploy a web server

• Let's create a Deployment and scale it

  (so that we have multiple pods on multiple nodes)

k8s/multinode.md

Check our pods

• The pods will be scheduled on the nodes

• The nodes will pull the nginx image, and start the pods

• What are the IP addresses of our pods?

What's going on?

• Without the --network-plugin flag, kubelet defaults to "no-op" networking

• It lets the container engine use a default network

  (in that case, we end up with the default Docker bridge)

• Our pods are running on independent, disconnected, host-local networks

k8s/multinode.md

What do we need to do?

• On a normal cluster, kubelet is configured to set up pod networking with CNI plugins

• This requires:

  • installing CNI plugins

  • writing CNI configuration files

  • running kubelet with --network-plugin=cni

k8s/multinode.md

Using network plugins

• We need to set up a better network

• Before diving into CNI, we will use the kubenet plugin

• This plugin creates a cbr0 bridge and connects the containers to that bridge

• This plugin allocates IP addresses from a range:

  • either specified to kubelet (e.g. with --pod-cidr)

  • or stored in the node's spec.podCIDR field

See here for more details about this kubenet plugin. k8s/multinode.md

What kubenet does and does not do

• It allocates IP addresses to pods locally

  (each node has its own local subnet)

• It connects the pods to a local bridge

  (pods on the same node can communicate together; not with other nodes)

• It doesn't set up routing or tunneling

  (we get pods on separated networks; we need to connect them somehow)

• It doesn't allocate subnets to nodes

  (this can be done manually, or by the controller manager)

k8s/multinode.md

Setting up routing or tunneling

• On each node, we will add routes to the other nodes' pod network

• Of course, this is not convenient or scalable!

• We will see better techniques to do this; but for now, hang on!

k8s/multinode.md

Allocating subnets to nodes

• There are multiple options:

  • passing the subnet to kubelet with the --pod-cidr flag

  • manually setting spec.podCIDR on each node

  • allocating node CIDRs automatically with the controller manager

• The last option would be implemented by adding these flags to controller manager:

  --allocate-node-cidrs=true --cluster-cidr=<cidr>

k8s/multinode.md

Restarting kubelet wih pod CIDR

• We need to stop and restart all our kubelets

• We will add the --network-plugin and --pod-cidr flags

• We all have a "cluster number" (let's call that C) printed on your VM info card

• We will use pod CIDR 10.C.N.0/24 (where N is the node number: 1, 2, 3)

k8s/multinode.md

What happens to our pods?

• When we stop (or kill) kubelet, the containers keep running

• When kubelet starts again, it detects the containers

🤔 But our pods still use local IP addresses!

k8s/multinode.md

Recreating the pods

• The IP address of a pod cannot change

• kubelet doesn't automatically kill/restart containers with "invalid" addresses
  (in fact, from kubelet's point of view, there is no such thing as an "invalid" address)

• We must delete our pods and recreate them

k8s/multinode.md

Adding kube-proxy

• Let's start kube-proxy to provide internal load balancing

• Then see if we can create a Service and use it to contact our pods

k8s/multinode.md

Test internal load balancing

Routing traffic

• Our pods have new, distinct IP addresses

• But they are on host-local, isolated networks

• If we try to ping a pod on a different node, it won't work

• kube-proxy merely rewrites the destination IP address

• But we need that IP address to be reachable in the first place

• How do we fix this?

  (hint: check the title of this slide!)

k8s/multinode.md

Important warning

• The technique that we are about to use doesn't work everywhere

• It only works if:

  • all the nodes are directly connected to each other (at layer 2)

  • the underlying network allows the IP addresses of our pods

• If we are on physical machines connected by a switch: OK

• If we are on virtual machines in a public cloud: NOT OK

  • on AWS, we need to disable "source and destination checks" on our instances

  • on OpenStack, we need to disable "port security" on our network ports

k8s/multinode.md

Routing basics

• We need to tell each node:

  "The subnet 10.C.N.0/24 is located on node N" (for all values of N)

• This is how we add a route on Linux:

  ip route add 10.C.N.0/24 via W.X.Y.Z

  (where W.X.Y.Z is the internal IP address of node N)

• We can see the internal IP addresses of our nodes with:

  kubectl get nodes -o wide

k8s/multinode.md

Firewalling

• By default, Docker prevents containers from using arbitrary IP addresses

  (by setting up iptables rules)

• We need to allow our containers to use our pod CIDR

• For simplicity, we will insert a blanket iptables rule allowing all traffic:

  iptables -I FORWARD -j ACCEPT

• This has to be done on every node

k8s/multinode.md

Setting up routing

k8s/multinode.md

What's next?

• We did a lot of manual operations:

  • allocating subnets to nodes

  • adding command-line flags to kubelet

  • updating the routing tables on our nodes

• We want to automate all these steps

• We want something that works on all networks

The Container Network Interface

• Allows us to decouple network configuration from Kubernetes

• Implemented by plugins

• Plugins are executables that will be invoked by kubelet

• Plugins are responsible for:

  • allocating IP addresses for containers

  • configuring the network for containers

• Plugins can be combined and chained when it makes sense

k8s/cni.md

Combining plugins

• Interface could be created by e.g. vlan or bridge plugin

• IP address could be allocated by e.g. dhcp or host-local plugin

• Interface parameters (MTU, sysctls) could be tweaked by the tuning plugin

The reference plugins are available here.

Look in each plugin's directory for its documentation. k8s/cni.md

How does kubelet know which plugins to use?

• The plugin (or list of plugins) is set in the CNI configuration

• The CNI configuration is a single file in /etc/cni/net.d

• If there are multiple files in that directory, the first one is used

  (in lexicographic order)

• That path can be changed with the --cni-conf-dir flag of kubelet

k8s/cni.md

CNI configuration in practice

• When we set up the "pod network" (like Calico, Weave...) it ships a CNI configuration

  (and sometimes, custom CNI plugins)

• Very often, that configuration (and plugins) is installed automatically

  (by a DaemonSet featuring an initContainer with hostPath volumes)

• Examples:

  • Calico CNI config and volume

  • kube-router CNI config and volume

k8s/cni.md

In practice: kube-router

• We are going to set up a new cluster

• For this new cluster, we will use kube-router

• kube-router will provide the "pod network"

  (connectivity with pods)

• kube-router will also provide internal service connectivity

  (replacing kube-proxy)

k8s/cni.md

How kube-router works

• Very simple architecture

• Does not introduce new CNI plugins

  (uses the bridge plugin, with host-local for IPAM)

• Pod traffic is routed between nodes

  (no tunnel, no new protocol)

• Internal service connectivity is implemented with IPVS

• Can provide pod network and/or internal service connectivity

• kube-router daemon runs on every node

k8s/cni.md

What kube-router does

• Connect to the API server

• Obtain the local node's podCIDR

• Inject it into the CNI configuration file

  (we'll use /etc/cni/net.d/10-kuberouter.conflist)

• Obtain the addresses of all nodes

• Establish a full mesh BGP peering with the other nodes

• Exchange routes over BGP

k8s/cni.md

The plan

• We'll work in a new cluster (named kuberouter)

• We will run a simple control plane (like before)

• ... But this time, the controller manager will allocate podCIDR subnets

  (so that we don't have to manually assign subnets to individual nodes)

• We will create a DaemonSet for kube-router

• We will join nodes to the cluster

• The DaemonSet will automatically start a kube-router pod on each node

k8s/cni.md

Logging into the new cluster

k8s/cni.md

Our control plane

• We will use a Compose file to start the control plane

• It is similar to the one we used with the kubenet cluster

• The API server is started with --allow-privileged

  (because we will start kube-router in privileged pods)

• The controller manager is started with extra flags too:

  --allocate-node-cidrs and --cluster-cidr

• We need to edit the Compose file to set the Cluster CIDR

k8s/cni.md

Starting the control plane

• Our cluster CIDR will be 10.C.0.0/16

  (where C is our cluster number)

k8s/cni.md

The kube-router DaemonSet

• In the same directory, there is a kuberouter.yaml file

• It contains the definition for a DaemonSet and a ConfigMap

• Before we load it, we also need to edit it

• We need to indicate the address of the API server

  (because kube-router needs to connect to it to retrieve node information)

k8s/cni.md

Creating the DaemonSet

• The address of the API server will be http://A.B.C.D:8080

  (where A.B.C.D is the public address of kuberouter1, running the control plane)

Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).

k8s/cni.md

Generating the kubeconfig for kubelet

• This is similar to what we did for the kubenet cluster

k8s/cni.md

Distributing kubeconfig

• We need to copy that kubeconfig file to the other nodes

k8s/cni.md

Starting kubelet

• We don't need the --pod-cidr option anymore

  (the controller manager will allocate these automatically)

• We need to pass --network-plugin=cni

k8s/cni.md

Setting up a test

• Let's create a Deployment and expose it with a Service

k8s/cni.md

Checking that everything works

Note that if you send multiple requests, they are load-balanced in a round robin manner.

This shows that we are using IPVS (vs. iptables, which picked random endpoints).

k8s/cni.md

Interconnecting clusters

• We assigned different Cluster CIDRs to each cluster

• This allows us to connect our clusters together

• We will leverage kube-router BGP abilities for that

• We will peer each kube-router instance with a route reflector

• As a result, we will be able to ping each other's pods

k8s/interco.md

Disclaimers

• There are many methods to interconnect clusters

• Depending on your network implementation, you will use different methods

• The method shown here only works for nodes with direct layer 2 connection

• We will often need to use tunnels or other network techniques

k8s/interco.md

The plan

• Someone will start the route reflector

  (typically, that will be the person presenting these slides!)

• We will update our kube-router configuration

• We will add a peering with the route reflector

  (instructing kube-router to connect to it and exchange route information)

• We should see the routes to other clusters on our nodes

  (in the output of e.g. route -n or ip route show)

• We should be able to ping pods of other nodes

k8s/interco.md

Starting the route reflector

• Only do this slide if you are doing this on your own

• There is a Compose file in the compose/frr-route-reflector directory

• Before continuing, make sure that you have the IP address of the route reflector

k8s/interco.md

Configuring kube-router

• This can be done in two ways:

  • with command-line flags to the kube-router process

  • with annotations to Node objects

• We will use the command-line flags

  (because it will automatically propagate to all nodes)

Note: with Calico, this is achieved by creating a BGPPeer CRD.

k8s/interco.md

Updating kube-router configuration

• We need to pass two command-line flags to the kube-router process

k8s/interco.md

Restarting kube-router

• The DaemonSet will not update the pods automatically

  (it is using the default updateStrategy, which is OnDelete)

• We will therefore delete the pods

  (they will be recreated with the updated definition)

Note: the other updateStrategy for a DaemonSet is RollingUpdate.
For critical services, we might want to precisely control the update process.

k8s/interco.md

Checking peering status

• We can see informative messages in the output of kube-router:

  time="2019-04-07T15:53:56Z" level=info msg="Peer Up"
  Key=X.X.X.X State=BGP_FSM_OPENCONFIRM Topic=Peer

• We should see the routes of the other clusters show up

• For debugging purposes, the reflector also exports a route to 1.0.0.2/32

• That route will show up like this:

  1.0.0.2     172.31.X.Y    255.255.255.255 UGH   0      0        0 eth0

• We should be able to ping the pods of other clusters!

k8s/interco.md

If we wanted to do more ...

• kube-router can also export ClusterIP addresses

  (by adding the flag --advertise-cluster-ip)

• They are exported individually (as /32)

• This would allow us to easily access other clusters' services

  (without having to resolve the individual addresses of pods)

• Even better if it's combined with DNS integration

  (to facilitate name → ClusterIP resolution)

API server availability

• When we set up a node, we need the address of the API server:

  • for kubelet

  • for kube-proxy

  • sometimes for the pod network system (like kube-router)

• How do we ensure the availability of that endpoint?

  (what if the node running the API server goes down?)

k8s/apilb.md

Option 1: external load balancer

• Set up an external load balancer

• Point kubelet (and other components) to that load balancer

• Put the node(s) running the API server behind that load balancer

• Update the load balancer if/when an API server node needs to be replaced

• On cloud infrastructures, some mechanisms provide automation for this

  (e.g. on AWS, an Elastic Load Balancer + Auto Scaling Group)

• Example in Kubernetes The Hard Way

k8s/apilb.md

Option 2: local load balancer

• Set up a load balancer (like NGINX, HAProxy...) on each node

• Configure that load balancer to send traffic to the API server node(s)

• Point kubelet (and other components) to localhost

• Update the load balancer configuration when API server nodes are updated

k8s/apilb.md

Updating the local load balancer config

• Distribute the updated configuration (push)

• Or regularly check for updates (pull)

• The latter requires an external, highly available store

  (it could be an object store, an HTTP server, or even DNS...)

• Updates can be facilitated by a DaemonSet

  (but remember that it can't be used when installing a new node!)

k8s/apilb.md

Option 3: DNS records

• Put all the API server nodes behind a round-robin DNS

• Point kubelet (and other components) to that name

• Update the records when needed

• Note: this option is not officially supported

  (but since kubelet supports reconnection anyway, it should work)

k8s/apilb.md

Option 4: ....................

• Many managed clusters expose a high-availability API endpoint

  (and you don't have to worry about it)

• You can also use HA mechanisms that you're familiar with

  (e.g. virtual IPs)

• Tunnels are also fine

  (e.g. k3s uses a tunnel to allow each node to contact the API server)

Setting up Kubernetes

• Kubernetes is made of many components that require careful configuration

• Secure operation typically requires TLS certificates and a local CA

  (certificate authority)

• Setting up everything manually is possible, but rarely done

  (except for learning purposes)

• Let's do a quick overview of available options!

k8s/setup-overview.md

Local development

• Are you writing code that will eventually run on Kubernetes?

• Then it's a good idea to have a development cluster!

• Development clusters only need one node

• This simplifies their setup a lot:

  • pod networking doesn't even need CNI plugins, overlay networks, etc.

  • they can be fully contained (no pun intended) in an easy-to-ship VM image

  • some of the security aspects may be simplified (different threat model)

• Examples: Docker Desktop, k3d, KinD, MicroK8s, Minikube

  (some of these also support clusters with multiple nodes)

k8s/setup-overview.md

Managed clusters

• Many cloud providers and hosting providers offer "managed Kubernetes"

• The deployment and maintenance of the cluster is entirely managed by the provider

  (ideally, clusters can be spun up automatically through an API, CLI, or web interface)

• Given the complexity of Kubernetes, this approach is strongly recommended

  (at least for your first production clusters)

• After working for a while with Kubernetes, you will be better equipped to decide:

  • whether to operate it yourself or use a managed offering

  • which offering or which distribution works best for you and your needs

k8s/setup-overview.md

Managed clusters details

• Pricing models differ from one provider to another

  • nodes are generally charged at their usual price

  • control plane may be free or incur a small nominal fee

• Beyond pricing, there are huge differences in features between providers

• The "major" providers are not always the best ones!

k8s/setup-overview.md

Managed clusters differences

• Most providers let you pick which Kubernetes version you want

  • some providers offer up-to-date versions

  • others lag significantly (sometimes by 2 or 3 minor versions)

• Some providers offer multiple networking or storage options

• Others will only support one, tied to their infrastructure

  (changing that is in theory possible, but might be complex or unsupported)

• Some providers let you configure or customize the control plane

  (generally through Kubernetes "feature gates")

k8s/setup-overview.md

Kubernetes distributions and installers

• If you want to run Kubernetes yourselves, there are many options

  (free, commercial, proprietary, open source ...)

• Some of them are installers, while some are complete platforms

• Some of them leverage other well-known deployment tools

  (like Puppet, Terraform ...)

• A good starting point to explore these options is this guide

  (it defines categories like "managed", "turnkey" ...)

k8s/setup-overview.md

kubeadm

• kubeadm is a tool part of Kubernetes to facilitate cluster setup

• Many other installers and distributions use it (but not all of them)

• It can also be used by itself

• Excellent starting point to install Kubernetes on your own machines

  (virtual, physical, it doesn't matter)

• It even supports highly available control planes, or "multi-master"

  (this is more complex, though, because it introduces the need for an API load balancer)

k8s/setup-overview.md

Manual setup

• The resources below are mainly for educational purposes!

• Kubernetes The Hard Way by Kelsey Hightower

  • step by step guide to install Kubernetes on Google Cloud

  • covers certificates, high availability ...

  • “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.”

• Deep Dive into Kubernetes Internals for Builders and Operators

  • conference presentation showing step-by-step control plane setup

  • emphasis on simplicity, not on security and availability

k8s/setup-overview.md

About our training clusters

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

kubeadm "drawbacks"

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

  (this is by design, to give us choice)

• Doesn't set up the overlay network

  (this is also by design, for the same reasons)

• HA control plane requires some extra steps

• Note that HA control plane also requires setting up a specific API load balancer

  (which is beyond the scope of kubeadm)

Running a local development cluster

• Let's review some options to run Kubernetes locally

• There is no "best option", it depends what you value:

  • ability to run on all platforms (Linux, Mac, Windows, other?)

  • ability to run clusters with multiple nodes

  • ability to run multiple clusters side by side

  • ability to run recent (or even, unreleased) versions of Kubernetes

  • availability of plugins

  • etc.

k8s/setup-devel.md

Docker Desktop

• Available on Mac and Windows

• Gives you one cluster with one node

• Rather old version of Kubernetes

• Very easy to use if you are already using Docker Desktop:

  go to Docker Desktop preferences and enable Kubernetes

• Ideal for Docker users who need good integration between both platforms

k8s/setup-devel.md

k3d

• Based on K3s by Rancher Labs

• Requires Docker

• Runs Kubernetes nodes in Docker containers

• Can deploy multiple clusters, with multiple nodes, and multiple master nodes

• As of June 2020, two versions co-exist: stable (1.7) and beta (3.0)

• They have different syntax and options, this can be confusing

  (but don't let that stop you!)

k8s/setup-devel.md

k3d in action

• Get k3d beta 3 binary on https://github.com/rancher/k3d/releases

• Create a simple cluster:

  k3d create cluster petitcluster --update-kubeconfig

• Use it:

  kubectl config use-context k3d-petitcluster

• Create a more complex cluster with a custom version:

  k3d create cluster groscluster --update-kubeconfig \
      --image rancher/k3s:v1.18.3-k3s1 --masters 3 --workers 5 --api-port 6444

  (note: API port seems to be necessary when running multiple clusters)

k8s/setup-devel.md

KinD

• Kubernetes-in-Docker

• Requires Docker (obviously!)

• Deploying a single node cluster using the latest version is simple:

  kind create cluster

• More advanced scenarios require writing a short config file

  (to define multiple nodes, multiple master nodes, set Kubernetes versions ...)

• Can deploy multiple clusters

k8s/setup-devel.md

Minikube

• The "legacy" option!

  (note: this is not a bad thing, it means that it's very stable, has lots of plugins, etc.)

• Supports many drivers

  (HyperKit, Hyper-V, KVM, VirtualBox, but also Docker and many others)

• Can deploy a single cluster; recent versions can deploy multiple nodes

• Great option if you want a "Kubernetes first" experience

  (i.e. if you don't already have Docker and/or don't want/need it)

k8s/setup-devel.md

MicroK8s

• Available on Linux, and since recently, on Mac and Windows as well

• The Linux version is installed through Snap

  (which is pre-installed on all recent versions of Ubuntu)

• Also supports clustering (as in, multiple machines running MicroK8s)

• DNS is not enabled by default; enable it with microk8s enable dns

k8s/setup-devel.md

VM with custom install

• Choose your own adventure!

• Pick any Linux distribution!

• Build your cluster from scratch or use a Kubernetes installer!

• Discover exotic CNI plugins and container runtimes!

• The only limit is yourself, and the time you are willing to sink in!

Deploying a managed cluster

"The easiest way to install Kubernetes is to get someone else to do it for you."
(Jérôme Petazzoni)

• Let's see a few options to install managed clusters!

• This is not an exhaustive list

  (the goal is to show the actual steps to get started)

• The list is sorted alphabetically

• All the options mentioned here require an account with a cloud provider

• ... And a credit card

k8s/setup-managed.md

AKS (initial setup)

• Install the Azure CLI

• Login:

  az login

• Select a region

• Create a "resource group":

  az group create --name my-aks-group --location westeurope

k8s/setup-managed.md

AKS (create cluster)

• Create the cluster:

  az aks create --resource-group my-aks-group --name my-aks-cluster

• Wait about 5-10 minutes

• Add credentials to kubeconfig:

  az aks get-credentials --resource-group my-aks-group --name my-aks-cluster

k8s/setup-managed.md

AKS (cleanup)

• Delete the cluster:

  az aks delete --resource-group my-aks-group --name my-aks-cluster

• Delete the resource group:

  az group delete --resource-group my-aks-group

• Note: delete actions can take a while too!

  (5-10 minutes as well)

k8s/setup-managed.md

AKS (notes)

• The cluster has useful components pre-installed, such as the metrics server

• There is also a product called AKS Engine:

  • leverages ARM (Azure Resource Manager) templates to deploy Kubernetes

  • it's "the library used by AKS"

  • fully customizable

  • think of it as "half-managed" Kubernetes option

k8s/setup-managed.md

Amazon EKS (the old way)

• Read the doc

• Create service roles, VPCs, and a bunch of other oddities

• Try to figure out why it doesn't work

• Start over, following an official AWS blog post

• Try to find the missing Cloud Formation template

Amazon EKS (the new way)

• Install eksctl

• Set the usual environment variables

  (AWS_DEFAULT_REGION, AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY)

• Create the cluster:

  eksctl create cluster

• Cluster can take a long time to be ready (15-20 minutes is typical)

• Add cluster add-ons

  (by default, it doesn't come with metrics-server, logging, etc.)

k8s/setup-managed.md

Amazon EKS (cleanup)

• Delete the cluster:

  eksctl delete cluster <clustername>

• If you need to find the name of the cluster:

  eksctl get clusters

Note: the AWS documentation has been updated and now includes eksctl instructions.

k8s/setup-managed.md

Amazon EKS (notes)

• Convenient if you have to use AWS

• Needs extra steps to be truly production-ready

• Versions tend to be outdated

• The only officially supported pod network is the Amazon VPC CNI plugin

  • integrates tightly with security groups and VPC networking

  • not suitable for high density clusters (with many small pods on big nodes)

  • other plugins should still work but will require extra work

k8s/setup-managed.md

Digital Ocean (initial setup)

• Install doctl

• Generate API token (in web console)

• Set up the CLI authentication:

  doctl auth init

  (It will ask you for the API token)

• Check the list of regions and pick one:

  doctl compute region list

  (If you don't specify the region later, it will use nyc1)

k8s/setup-managed.md

Digital Ocean (create cluster)

• Create the cluster:

  doctl kubernetes cluster create my-do-cluster [--region xxx1]

• Wait 5 minutes

• Update kubeconfig:

  kubectl config use-context do-xxx1-my-do-cluster

• The cluster comes with some components (like Cilium) but no metrics server

k8s/setup-managed.md

Digital Ocean (cleanup)

• List clusters (if you forgot its name):

  doctl kubernetes cluster list

• Delete the cluster:

  doctl kubernetes cluster delete my-do-cluster

k8s/setup-managed.md

GKE (initial setup)

• Install gcloud

• Login:

  gcloud auth init

• Create a "project":

  gcloud projects create my-gke-project
  gcloud config set project my-gke-project

• Pick a region

  (example: europe-west1, us-west1, ...)

k8s/setup-managed.md

GKE (create cluster)

• Create the cluster:

  gcloud container clusters create my-gke-cluster --region us-west1 --num-nodes=2

  (without --num-nodes you might exhaust your IP address quota!)

• The first time you try to create a cluster in a given project, you get an error

  • you need to enable the Kubernetes Engine API
  • the error message gives you a link
  • follow the link and enable the API (and billing)
    (it's just a couple of clicks and it's instantaneous)

• Clutser should be ready in a couple of minutes

k8s/setup-managed.md

GKE (cleanup)

• List clusters (if you forgot its name):

  gcloud container clusters list

• Delete the cluster:

  gcloud container clusters delete my-gke-cluster --region us-west1

• Delete the project (optional):

  gcloud projects delete my-gke-project

k8s/setup-managed.md

GKE (notes)

• Well-rounded product overall

  (it used to be one of the best managed Kubernetes offerings available; now that many other providers entered the game, that title is debatable)

• The cluster comes with many add-ons

• Versions lag a bit:

  • latest minor version (e.g. 1.18) tends to be unsupported

  • previous minor version (e.g. 1.17) supported through alpha channel

  • previous versions (e.g. 1.14-1.16) supported

k8s/setup-managed.md

Scaleway (initial setup)

• After creating your account, make sure you set a password or get an API key

  (by default, it uses email "magic links" to sign in)

• Install scw

  (you need CLI v2, which in beta as of May 2020)

• Generate the CLI configuration with scw init

  (it will prompt for your API key, or email + password)

k8s/setup-managed.md

Scaleway (create cluster)

• Create the cluster:

  k8s cluster create name=my-kapsule-cluster version=1.18.3 cni=cilium \
      default-pool-config.node-type=DEV1-M default-pool-config.size=3

• After less than 5 minutes, cluster state will be ready

  (check cluster status with e.g. scw k8s cluster list on a wide terminal )

• Add connection information to your .kube/config file:

  scw k8s kubeconfig install CLUSTERID

  (the cluster ID is shown by scw k8s cluster list)

k8s/setup-managed.md

Scaleway (cleanup)

• Get cluster ID (e.g. with scw k8s cluster list)

• Delete the cluster:

  scw cluster delete cluster-id=$CLUSTERID

• Warning: as of May 2020, load balancers have to be deleted separately!

k8s/setup-managed.md

Scaleway (notes)

• The create command is a bit more complex than with other providers

  (you must specify the Kubernetes version, CNI plugin, and node type)

• To see available versions and CNI plugins, run scw k8s version list

• As of May 2020, Kapsule supports:

  • multiple CNI plugins, including: cilium, calico, weave, flannel

  • Kubernetes versions 1.15 to 1.18

  • multiple container runtimes, including: Docker, containerd, CRI-O

• To see available node types and their price, check their pricing page

k8s/setup-managed.md

More options

• Alibaba Cloud

• IBM Cloud

• Linode Kubernetes Engine (LKE)

• OVHcloud Managed Kubernetes Service

• ...

Kubernetes distributions and installers

• Sometimes, we need to run Kubernetes ourselves

  (as opposed to "use a managed offering")

• Beware: it takes a lot of work to set up and maintain Kubernetes

• It might be necessary if you have specific security or compliance requirements

  (e.g. national security for states that don't have a suitable domestic cloud)

• There are countless distributions available

• We can't review them all

• We're just going to explore a few options

k8s/setup-selfhosted.md

kops

• Deploys Kubernetes using cloud infrastructure

  (supports AWS, GCE, Digital Ocean ...)

• Leverages special cloud features when possible

  (e.g. Auto Scaling Groups ...)

k8s/setup-selfhosted.md

kubeadm

• Provisions Kubernetes nodes on top of existing machines

• kubeadm init to provision a single-node control plane

• kubeadm join to join a node to the cluster

• Supports HA control plane with some extra steps

k8s/setup-selfhosted.md

kubespray

• Based on Ansible

• Works on bare metal and cloud infrastructure

  (good for hybrid deployments)

• The expert says: ultra flexible; slow; complex

k8s/setup-selfhosted.md

RKE (Rancher Kubernetes Engine)

• Opinionated installer with low requirements

• Requires a set of machines with Docker + SSH access

• Supports highly available etcd and control plane

• The expert says: fast; maintenance can be tricky

k8s/setup-selfhosted.md

Terraform + kubeadm

• Sometimes it is necessary to build a custom solution

• Example use case:

  • deploying Kubernetes on OpenStack

  • ... with highly available control plane

  • ... and Cloud Controller Manager integration

• Solution: Terraform + kubeadm (kubeadm driven by remote-exec)

  • GitHub repository

  • Blog post (in French)

k8s/setup-selfhosted.md

And many more ...

• AKS Engine

• Docker Enterprise Edition

• Lokomotive, leveraging Terraform and Flatcar Linux

• Pivotal Container Service (PKS)

• Tarmak, leveraging Puppet and Terraform

• Tectonic by CoreOS (now being integrated into Red Hat OpenShift)

• Typhoon, leveraging Terraform

• VMware Tanzu Kubernetes Grid (TKG)

k8s/setup-selfhosted.md

Bottom line

• Each distribution / installer has pros and cons

• Before picking one, we should sort out our priorities:

  • cloud, on-premises, hybrid?

  • integration with existing network/storage architecture or equipment?

  • are we storing very sensitive data, like finance, health, military?

  • how many clusters are we deploying (and maintaining): 2, 10, 50?

  • which team will be responsible for deployment and maintenance?
    (do they need training?)

  • etc.

Static pods

• Hosting the Kubernetes control plane on Kubernetes has advantages:

  • we can use Kubernetes' replication and scaling features for the control plane

  • we can leverage rolling updates to upgrade the control plane

• However, there is a catch:

  • deploying on Kubernetes requires the API to be available

  • the API won't be available until the control plane is deployed

• How can we get out of that chicken-and-egg problem?

k8s/staticpods.md

A possible approach

• Since each component of the control plane can be replicated...

• We could set up the control plane outside of the cluster

• Then, once the cluster is fully operational, create replicas running on the cluster

• Finally, remove the replicas that are running outside of the cluster

What could possibly go wrong?

k8s/staticpods.md

Sawing off the branch you're sitting on

• What if anything goes wrong?

  (During the setup or at a later point)

• Worst case scenario, we might need to:

  • set up a new control plane (outside of the cluster)

  • restore a backup from the old control plane

  • move the new control plane to the cluster (again)

• This doesn't sound like a great experience

k8s/staticpods.md

Static pods to the rescue

• Pods are started by kubelet (an agent running on every node)

• To know which pods it should run, the kubelet queries the API server

• The kubelet can also get a list of static pods from:

  • a directory containing one (or multiple) manifests, and/or

  • a URL (serving a manifest)

• These "manifests" are basically YAML definitions

  (As produced by kubectl get pod my-little-pod -o yaml)

k8s/staticpods.md

Static pods are dynamic

• Kubelet will periodically reload the manifests

• It will start/stop pods accordingly

  (i.e. it is not necessary to restart the kubelet after updating the manifests)

• When connected to the Kubernetes API, the kubelet will create mirror pods

• Mirror pods are copies of the static pods

  (so they can be seen with e.g. kubectl get pods)

k8s/staticpods.md

Bootstrapping a cluster with static pods

• We can run control plane components with these static pods

• They can start without requiring access to the API server

• Once they are up and running, the API becomes available

• These pods are then visible through the API

  (We cannot upgrade them from the API, though)

This is how kubeadm has initialized our clusters.

k8s/staticpods.md

Static pods vs normal pods

• The API only gives us read-only access to static pods

• We can kubectl delete a static pod...

  ...But the kubelet will re-mirror it immediately

• Static pods can be selected just like other pods

  (So they can receive service traffic)

• A service can select a mixture of static and other pods

k8s/staticpods.md

From static pods to normal pods

• Once the control plane is up and running, it can be used to create normal pods

• We can then set up a copy of the control plane in normal pods

• Then the static pods can be removed

• The scheduler and the controller manager use leader election

  (Only one is active at a time; removing an instance is seamless)

• Each instance of the API server adds itself to the kubernetes service

• Etcd will typically require more work!

k8s/staticpods.md

From normal pods back to static pods

• Alright, but what if the control plane is down and we need to fix it?

• We restart it using static pods!

• This can be done automatically with the Pod Checkpointer

• The Pod Checkpointer automatically generates manifests of running pods

• The manifests are used to restart these pods if API contact is lost

  (More details in the Pod Checkpointer documentation page)

• This technique is used by bootkube k8s/staticpods.md

Where should the control plane run?

Is it better to run the control plane in static pods, or normal pods?

• If I'm a user of the cluster: I don't care, it makes no difference to me

• What if I'm an admin, i.e. the person who installs, upgrades, repairs... the cluster?

• If I'm using a managed Kubernetes cluster (AKS, EKS, GKE...) it's not my problem

  (I'm not the one setting up and managing the control plane)

• If I already picked a tool (kubeadm, kops...) to set up my cluster, the tool decides for me

• What if I haven't picked a tool yet, or if I'm installing from scratch?

  • static pods = easier to set up, easier to troubleshoot, less risk of outage

  • normal pods = easier to upgrade, easier to move (if nodes need to be shut down)

k8s/staticpods.md

Static pods in action

• On our clusters, the staticPodPath is /etc/kubernetes/manifests

We should see YAML files corresponding to the pods of the control plane.

k8s/staticpods.md

Upgrading clusters

• It's recommended to run consistent versions across a cluster

  (mostly to have feature parity and latest security updates)

• It's not mandatory

  (otherwise, cluster upgrades would be a nightmare!)

• Components can be upgraded one at a time without problems

k8s/cluster-upgrade.md

Checking what we're running

• It's easy to check the version for the API server

• In a HA setup with multiple API servers, they can have different versions

• Running the command above multiple times can return different values

k8s/cluster-upgrade.md

Node versions

• It's also easy to check the version of kubelet

• Different nodes can run different kubelet versions

• Different nodes can run different kernel versions

• Different nodes can run different container engines

k8s/cluster-upgrade.md

Control plane versions

• If the control plane is self-hosted (running in pods), we can check it

k8s/cluster-upgrade.md

What version are we running anyway?

• When I say, "I'm running Kubernetes 1.15", is that the version of:

  • kubectl

  • API server

  • kubelet

  • controller manager

  • something else?

k8s/cluster-upgrade.md

Other versions that are important

• etcd

• kube-dns or CoreDNS

• CNI plugin(s)

• Network controller, network policy controller

• Container engine

• Linux kernel

k8s/cluster-upgrade.md

General guidelines

• To update a component, use whatever was used to install it

• If it's a distro package, update that distro package

• If it's a container or pod, update that container or pod

• If you used configuration management, update with that

k8s/cluster-upgrade.md

Know where your binaries come from

• Sometimes, we need to upgrade quickly

  (when a vulnerability is announced and patched)

• If we are using an installer, we should:

  • make sure it's using upstream packages

  • or make sure that whatever packages it uses are current

  • make sure we can tell it to pin specific component versions

k8s/cluster-upgrade.md

Important questions

• Should we upgrade the control plane before or after the kubelets?

• Within the control plane, should we upgrade the API server first or last?

• How often should we upgrade?

• How long are versions maintained?

• All the answers are in the documentation about version skew policy!

• Let's review the key elements together ...

k8s/cluster-upgrade.md

Kubernetes uses semantic versioning

• Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.17.2:

  • MAJOR = 1
  • MINOR = 17
  • PATCH = 2

• It's always possible to mix and match different PATCH releases

  (e.g. 1.16.1 and 1.16.6 are compatible)

• It is recommended to run the latest PATCH release

  (but it's mandatory only when there is a security advisory)

k8s/cluster-upgrade.md

Version skew

• API server must be more recent than its clients (kubelet and control plane)

• ... Which means it must always be upgraded first

• All components support a difference of one¹ MINOR version

• This allows live upgrades (since we can mix e.g. 1.15 and 1.16)

• It also means that going from 1.14 to 1.16 requires going through 1.15

k8s/cluster-upgrade.md

Release cycle

• There is a new PATCH relese whenever necessary

  (every few weeks, or "ASAP" when there is a security vulnerability)

• There is a new MINOR release every 3 months (approximately)

• At any given time, three MINOR releases are maintained

• ... Which means that MINOR releases are maintained approximately 9 months

• We should expect to upgrade at least every 3 months (on average)

k8s/cluster-upgrade.md

In practice

• We are going to update a few cluster components

• We will change the kubelet version on one node

• We will change the version of the API server

• We will work with cluster test (nodes test1, test2, test3)

k8s/cluster-upgrade.md

Updating the API server

• This cluster has been deployed with kubeadm

• The control plane runs in static pods

• These pods are started automatically by kubelet

  (even when kubelet can't contact the API server)

• They are defined in YAML files in /etc/kubernetes/manifests

  (this path is set by a kubelet command-line flag)

• kubelet automatically updates the pods when the files are changed

k8s/cluster-upgrade.md

Changing the API server version

• We will edit the YAML file to use a different image version

k8s/cluster-upgrade.md

Checking what we've done

• The API server will be briefly unavailable while kubelet restarts it

k8s/cluster-upgrade.md

Was that a good idea?

Updating the whole control plane

• Let's make it right, and use kubeadm to upgrade the entire control plane

  (note: this is possible only because the cluster was installed with kubeadm)

Note 1: kubeadm thinks that our cluster is running 1.16.0.
It is confused by our manual upgrade of the API server!

Note 2: kubeadm itself is still version 1.15.9.
It doesn't know how to upgrade do 1.16.X.

k8s/cluster-upgrade.md

Upgrading kubeadm

• First things first: we need to upgrade kubeadm

Problem: kubeadm doesn't know know how to handle upgrades from version 1.15.

This is because we installed version 1.17 (or even later).

We need to install kubeadm version 1.16.X.

k8s/cluster-upgrade.md

Downgrading kubeadm

• We need to go back to version 1.16.X (e.g. 1.16.6)

kubeadm should now agree to upgrade to 1.16.6.

k8s/cluster-upgrade.md

Upgrading the cluster with kubeadm

• Ideally, we should revert our image: change

  (so that kubeadm executes the right migration steps)

• Or we can try the upgrade anyway

k8s/cluster-upgrade.md

Updating kubelet

• These nodes have been installed using the official Kubernetes packages

• We can therefore use apt or apt-get

k8s/cluster-upgrade.md

Checking what we've done

k8s/cluster-upgrade.md

Was that a good idea?

Upgrading kubelet the right way

• We need to upgrade kubeadm, upgrade kubelet config, then upgrade kubelet

  (after upgrading the control plane)

k8s/cluster-upgrade.md

Checking what we've done

• All our nodes should now be updated to version 1.16.6

k8s/cluster-upgrade.md

Backing up clusters

• Backups can have multiple purposes:

  • disaster recovery (servers or storage are destroyed or unreachable)

  • error recovery (human or process has altered or corrupted data)

  • cloning environments (for testing, validation...)

• Let's see the strategies and tools available with Kubernetes!

k8s/cluster-backup.md

Important

• Kubernetes helps us with disaster recovery

  (it gives us replication primitives)

• Kubernetes helps us clone / replicate environments

  (all resources can be described with manifests)

• Kubernetes does not help us with error recovery

• We still need to back up/snapshot our data:

  • with database backups (mysqldump, pgdump, etc.)

  • and/or snapshots at the storage layer

  • and/or traditional full disk backups

k8s/cluster-backup.md

In a perfect world ...

• The deployment of our Kubernetes clusters is automated

  (recreating a cluster takes less than a minute of human time)

• All the resources (Deployments, Services...) on our clusters are under version control

  (never use kubectl run; always apply YAML files coming from a repository)

• Stateful components are either:

  • stored on systems with regular snapshots

  • backed up regularly to an external, durable storage

  • outside of Kubernetes

k8s/cluster-backup.md

Kubernetes cluster deployment

• If our deployment system isn't fully automated, it should at least be documented

• Litmus test: how long does it take to deploy a cluster...

  • for a senior engineer?

  • for a new hire?

• Does it require external intervention?

  (e.g. provisioning servers, signing TLS certs...)

k8s/cluster-backup.md

Plan B

• Full machine backups of the control plane can help

• If the control plane is in pods (or containers), pay attention to storage drivers

  (if the backup mechanism is not container-aware, the backups can take way more resources than they should, or even be unusable!)

• If the previous sentence worries you:

  automate the deployment of your clusters!

k8s/cluster-backup.md

Managing our Kubernetes resources

• Ideal scenario:

  • never create a resource directly on a cluster

  • push to a code repository

  • a special branch (production or even master) gets automatically deployed

• Some folks call this "GitOps"

  (it's the logical evolution of configuration management and infrastructure as code)

k8s/cluster-backup.md

GitOps in theory

• What do we keep in version control?

• For very simple scenarios: source code, Dockerfiles, scripts

• For real applications: add resources (as YAML files)

• For applications deployed multiple times: Helm, Kustomize...

  (staging and production count as "multiple times")

k8s/cluster-backup.md

GitOps tooling

• Various tools exist (Weave Flux, GitKube...)

• These tools are still very young

• You still need to write YAML for all your resources

• There is no tool to:

  • list all resources in a namespace

  • get resource YAML in a canonical form

  • diff YAML descriptions with current state

k8s/cluster-backup.md

GitOps in practice

• Start describing your resources with YAML

• Leverage a tool like Kustomize or Helm

• Make sure that you can easily deploy to a new namespace

  (or even better: to a new cluster)

• When tooling matures, you will be ready

k8s/cluster-backup.md

Plan B

• What if we can't describe everything with YAML?

• What if we manually create resources and forget to commit them to source control?

• What about global resources, that don't live in a namespace?

• How can we be sure that we saved everything?

k8s/cluster-backup.md

Backing up etcd

• All objects are saved in etcd

• etcd data should be relatively small

  (and therefore, quick and easy to back up)

• Two options to back up etcd:

  • snapshot the data directory

  • use etcdctl snapshot

k8s/cluster-backup.md

Making an etcd snapshot

• The basic command is simple:

  etcdctl snapshot save <filename>

• But we also need to specify:

  • an environment variable to specify that we want etcdctl v3

  • the address of the server to back up

  • the path to the key, certificate, and CA certificate
    (if our etcd uses TLS certificates)

k8s/cluster-backup.md

Snapshotting etcd on kubeadm

• The following command will work on clusters deployed with kubeadm

  (and maybe others)

• It should be executed on a master node

docker run --rm --net host -v $PWD:/vol \
    -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd:ro \
    -e ETCDCTL_API=3 k8s.gcr.io/etcd:3.3.10 \
    etcdctl --endpoints=https://[127.0.0.1]:2379 \
            --cacert=/etc/kubernetes/pki/etcd/ca.crt \
            --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
            --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
            snapshot save /vol/snapshot

• It will create a file named snapshot in the current directory

k8s/cluster-backup.md

How can we remember all these flags?

• Older versions of kubeadm did add a healthcheck probe with all these flags

• That healthcheck probe was calling etcdctl with all the right flags

• With recent versions of kubeadm, we're on our own!

• Exercise: write the YAML for a batch job to perform the backup

  (how will you access the key and certificate required to connect?)

k8s/cluster-backup.md

Restoring an etcd snapshot

• Execute exactly the same command, but replacing save with restore

  (Believe it or not, doing that will not do anything useful!)

• The restore command does not load a snapshot into a running etcd server

• The restore command creates a new data directory from the snapshot

  (it's an offline operation; it doesn't interact with an etcd server)

• It will create a new data directory in a temporary container

  (leaving the running etcd node untouched)

k8s/cluster-backup.md

When using kubeadm

1. Create a new data directory from the snapshot:

   sudo rm -rf /var/lib/etcd
   docker run --rm -v /var/lib:/var/lib -v $PWD:/vol \
         -e ETCDCTL_API=3 k8s.gcr.io/etcd:3.3.10 \
         etcdctl snapshot restore /vol/snapshot --data-dir=/var/lib/etcd

2. Provision the control plane, using that data directory:

   sudo kubeadm init \
       --ignore-preflight-errors=DirAvailable--var-lib-etcd

3. Rejoin the other nodes

k8s/cluster-backup.md

The fine print

• This only saves etcd state

• It does not save persistent volumes and local node data

• Some critical components (like the pod network) might need to be reset

• As a result, our pods might have to be recreated, too

• If we have proper liveness checks, this should happen automatically

k8s/cluster-backup.md

More information about etcd backups

• Kubernetes documentation about etcd backups

• etcd documentation about snapshots and restore

• A good blog post by elastisys explaining how to restore a snapshot

• Another good blog post by consol labs on the same topic

k8s/cluster-backup.md

Don't forget ...

• Also back up the TLS information

  (at the very least: CA key and cert; API server key and cert)

• With clusters provisioned by kubeadm, this is in /etc/kubernetes/pki

• If you don't:

  • you will still be able to restore etcd state and bring everything back up

  • you will need to redistribute user certificates

k8s/cluster-backup.md

Stateful services

• It's totally fine to keep your production databases outside of Kubernetes

  Especially if you have only one database server!

• Feel free to put development and staging databases on Kubernetes

  (as long as they don't hold important data)

• Using Kubernetes for stateful services makes sense if you have many

  (because then you can leverage Kubernetes automation)

k8s/cluster-backup.md

Snapshotting persistent volumes

• Option 1: snapshot volumes out of band

  (with the API/CLI/GUI of our SAN/cloud/...)

• Option 2: storage system integration

  (e.g. Portworx can create snapshots through annotations)

• Option 3: snapshots through Kubernetes API

  (now in alpha for a few storage providers: GCE, OpenSDS, Ceph, Portworx)

k8s/cluster-backup.md

More backup tools

• Stash

  back up Kubernetes persistent volumes

• ReShifter

  cluster state management

• Heptio Ark Velero

  full cluster backup

• kube-backup

  simple scripts to save resource YAML to a git repository

• bivac

  Backup Interface for Volumes Attached to Containers

Pod Security Policies

• By default, our pods and containers can do everything

  (including taking over the entire cluster)

• We are going to show an example of a malicious pod

• Then we will explain how to avoid this with PodSecurityPolicies

• We will enable PodSecurityPolicies on our cluster

• We will create a couple of policies (restricted and permissive)

• Finally we will see how to use them to improve security on our cluster

k8s/podsecuritypolicy.md

Setting up a namespace

• For simplicity, let's work in a separate namespace

• Let's create a new namespace called "green"

k8s/podsecuritypolicy.md

Creating a basic Deployment

• Just to check that everything works correctly, deploy NGINX

k8s/podsecuritypolicy.md

One example of malicious pods

• We will now show an escalation technique in action

• We will deploy a DaemonSet that adds our SSH key to the root account

  (on each node of the cluster)

• The Pods of the DaemonSet will do so by mounting /root from the host

k8s/podsecuritypolicy.md

Deploying the malicious pods

• Let's deploy our "exploit"!

k8s/podsecuritypolicy.md

Cleaning up

• Before setting up our PodSecurityPolicies, clean up that namespace

k8s/podsecuritypolicy.md

Pod Security Policies in theory

• To use PSPs, we need to activate their specific admission controller

• That admission controller will intercept each pod creation attempt

• It will look at:

  • who/what is creating the pod

  • which PodSecurityPolicies they can use

  • which PodSecurityPolicies can be used by the Pod's ServiceAccount

• Then it will compare the Pod with each PodSecurityPolicy one by one

• If a PodSecurityPolicy accepts all the parameters of the Pod, it is created

• Otherwise, the Pod creation is denied and it won't even show up in kubectl get pods

k8s/podsecuritypolicy.md

Pod Security Policies fine print

• With RBAC, using a PSP corresponds to the verb use on the PSP

  (that makes sense, right?)

• If no PSP is defined, no Pod can be created

  (even by cluster admins)

• Pods that are already running are not affected

• If we create a Pod directly, it can use a PSP to which we have access

• If the Pod is created by e.g. a ReplicaSet or DaemonSet, it's different:

  • the ReplicaSet / DaemonSet controllers don't have access to our policies

  • therefore, we need to give access to the PSP to the Pod's ServiceAccount

k8s/podsecuritypolicy.md

Pod Security Policies in practice

• We are going to enable the PodSecurityPolicy admission controller

• At that point, we won't be able to create any more pods (!)

• Then we will create a couple of PodSecurityPolicies

• ...And associated ClusterRoles (giving use access to the policies)

• Then we will create RoleBindings to grant these roles to ServiceAccounts

• We will verify that we can't run our "exploit" anymore

k8s/podsecuritypolicy.md

Enabling Pod Security Policies

• To enable Pod Security Policies, we need to enable their admission plugin

• This is done by adding a flag to the API server

• On clusters deployed with kubeadm, the control plane runs in static pods

• These pods are defined in YAML files located in /etc/kubernetes/manifests

• Kubelet watches this directory

• Each time a file is added/removed there, kubelet creates/deletes the corresponding pod

• Updating a file causes the pod to be deleted and recreated

k8s/podsecuritypolicy.md

Updating the API server flags

• Let's edit the manifest for the API server pod

k8s/podsecuritypolicy.md

Adding the PSP admission plugin

• There should already be a line with --enable-admission-plugins=...

• Let's add PodSecurityPolicy on that line

k8s/podsecuritypolicy.md

Waiting for the API server to restart

• The kubelet detects that the file was modified

• It kills the API server pod, and starts a new one

• During that time, the API server is unavailable

k8s/podsecuritypolicy.md

Check that the admission plugin is active

• Normally, we can't create any Pod at this point

We can get hints at what's happening by looking at the ReplicaSet and Events.

k8s/podsecuritypolicy.md

Introducing our Pod Security Policies

• We will create two policies:

  • privileged (allows everything)

  • restricted (blocks some unsafe mechanisms)

• For each policy, we also need an associated ClusterRole granting use

k8s/podsecuritypolicy.md

Creating our Pod Security Policies

• We have a couple of files, each defining a PSP and associated ClusterRole:

  • k8s/psp-privileged.yaml: policy privileged, role psp:privileged
  • k8s/psp-restricted.yaml: policy restricted, role psp:restricted

• The privileged policy comes from the Kubernetes documentation

• The restricted policy is inspired by that same documentation page

k8s/podsecuritypolicy.md

Check that we can create Pods again

• We haven't bound the policy to any user yet

• But cluster-admin can implicitly use all policies

k8s/podsecuritypolicy.md

What's going on?

• We can create Pods directly (thanks to our root-like permissions)

• The Pods corresponding to a Deployment are created by the ReplicaSet controller

• The ReplicaSet controller does not have root-like permissions

• We need to either:

  • grant permissions to the ReplicaSet controller

  or

  • grant permissions to our Pods' ServiceAccount

• The first option would allow anyone to create pods

• The second option will allow us to scope the permissions better

k8s/podsecuritypolicy.md

Binding the restricted policy

• Let's bind the role psp:restricted to ServiceAccount green:default

  (aka the default ServiceAccount in the green Namespace)

• This will allow Pod creation in the green Namespace

  (because these Pods will be using that ServiceAccount automatically)

k8s/podsecuritypolicy.md

Trying it out

• The Deployments that we created earlier will eventually recover

  (the ReplicaSet controller will retry to create Pods once in a while)

• If we create a new Deployment now, it should work immediately

k8s/podsecuritypolicy.md