instructor: Nigel Poulton
course gh: https://github.com/nigelpoulton/getting-started-k8s

Introduction

Kubernetes came out of Google - no doubt one of the biggest and most important open source technologies today. Written in Go (programming language). A descendant of Borg and Omega, proprietary container orchestration at Google. Kubernetes comes from the greek work meaning Helmsman - the person who steers a ship. Often abbreviated K8s.

What is Kubernetes

A legacy app with 10s or 100s of VMs could have 1000s of containers - need a way to manage them - cue Kubernetes. Instead of caring what specific computer something is running on, leave that to a tool like K8s.

  • Package apps as containers
  • Describe them in a declarative manifest
  • Give them to k8s and let it decide how to pull images, verify, run them

Some terms

  • monolith - need to patch a tiny part of the app, take the whole thing down, update it - same with scaling.
  • microservices - takes the same things, but breaks everything into its own mini application that can each be managed independently

Kubernetes Architecture

  • Control plane nodes - extremely important to have an H/A control plane in production. 3 tends to be the magic number to avoid split brain and dead locks. There is always a leader that is responsible for changing the cluster, and if it goes down a new one is elected
    • kube-apiserver - gateway to k8s cluster - only component most people or things ever directly interact with
    • Cluster store - persists cluster state & config based on etcd. Performance is absolutely critical and requires having a recovery plan in place
    • kube-controller-manager - Controller of controllers - node controller, deployment controller, endpoints controller. Runs as a reconciliation loop and looks for changes
    • kube-scheduler - watches api server for work and assigns tasks to worker nodes based on constraints, affinity rules, resources, etc.
  • Worker nodes - kubelet, container runtime, kube proxy
    • kubelet - main k8s agent that runs on every cluster node - watches api server for work and executes pod
    • container runtime - pluggable container runtime interface (CRI) usually runs containerd today
    • kube-proxy - network brains of the node, gives running pods an IP, and load balances traffic for all pods behind a service

Declarative Model and Desired State

  • Declarative model - has a config file that describes what we want the cluster and/or our apps to look like

Pods

The atomic unit of scheduling in kubernetes

  • Shared execution environment for all containers in the pod
  • Loosely coupled containers in separate pods with a network connection is better than sharing multiple containers per pod
  • Service mesh is an example of where we tend to have multiple containers in a pod on a regular basis
  • Pods are only ready when all containers inside are also ready
  • Pods can only live on a single node - you can’t have one container on one node and another container on another node

Stable Networking with Services

Pods change frequently between scaling, self healing, etc. and they always get new IP addresses which could be a challenge to deal with. So we cannot rely on pod IP addresses

  • Services have a stable IP and DNS name and sit in front of pods
  • This is part of the contract between kubernetes and a service
  • The way a pod makes it into a list of pods a service will send traffic to is via labels
  • Services only send traffic to healthy pods
  • Services can send traffic to endpoints outside of the cluster
  • TCP and UDP

Deployments

Deployment controller runs on the control plane and looks for deployment configurations in our desired state, then watches for changes in a reconciliation loop. spec once, deploy many.

  • Makes rollouts and rollbacks extremely simple
  • Deployments are a first class rest object in the API - defined in yaml files
  • deployments are used for stateless apps!

Getting Kubernetes

  • Docker Desktop
  • Linode Kubernetes Engine
  • Course Files

Working with Pods

A precursor to creating a pod manifest is having a docker image in a registry somewhere that your k8s cluster has access to.

  • Pods are the smallest deployable object
  • manifest can be applied with kubectl apply -f <file>
  • Pod with multiple containers will not show ready until all containers are ready

Working With Services

The way in kubernetes to expose applications. Abstraction that sits above pods to expose them on a reliable endpoint. Services have a “frontend” and “backend”. The frontend is a name & IP, and the backend is load balancing. IP on the frontend is a ClusterIP assigned by k8s. The name is registered with cluster DNS. Three types of services:

  • ClusterIP - Default services, enabled communication between pods in a cluster
  • NodePort - Has a port mapped on every pod and are assigned a clusterIP. Not advisable for use primarily.
  • LoadBalancer - works with k8s cloud provider to provision a load balancer and provides access to applications from the Internet

Create a Service Imperatively

This is not the preferred way to do anything in k8s, but it’s worth knowing how to do. Declarative methods are preferred. kubectl expose pod hello-pod --name=hello-svc --target-port=8080 --type=NodePort

Create a Service Declaratively

This it the preferred method for declaring a service - defined in a yaml file called a service manifest.

Create an Internet Load Balancer Service

type LoadBalancer

Kubernetes Deployments

Deployments are resources in the k8s API. They provide self-healing, scaling, rollouts, and rollbacks.

Creating a deployment yaml

  • Write your yaml, apply with kubectl
  • Deployment will create a replicaset for you

Self-healing and Scaling

  • 5 pods managed by a deployment/replicaset
  • Delete a pod manually, so we no longer match desired state
  • replicaset controller automatically brings another pod online
  • Turn off a node backing the cluster, some pods go with it, replicaset spins up more again
  • k8s will also get back to a desired state for number of nodes and will spin up a new one
  • Editing deployment yaml to modify replica count will add or remove pods as necessary

Rollouts and Rollbacks

  • Currently have two replicas of pods with 1.0 version tag
  • Set update strategy and burst limits etc.