container.training/slides/k8s/concepts-k8s.md

Kubernetes concepts

• Kubernetes is a container management system

• It runs and manages containerized applications on a cluster

--

• What does that really mean?

---

What can we do with Kubernetes?

• Let's imagine that we have a 3-tier e-commerce app:

  • web frontend

  • API backend

  • database (that we will keep out of Kubernetes for now)

• We have built images for our frontend and backend components

  (e.g. with Dockerfiles and docker build)

• We are running them successfully with a local environment

  (e.g. with Docker Compose)

• Let's see how we would deploy our app on Kubernetes!

---

Basic things we can ask Kubernetes to do

--

• Start 5 containers using image atseashop/api:v1.3

--

• Place an internal load balancer in front of these containers

--

• Start 10 containers using image atseashop/webfront:v1.3

--

• Place a public load balancer in front of these containers

--

• It's Black Friday (or Christmas), traffic spikes, grow our cluster and add containers

--

• New release! Replace my containers with the new image atseashop/webfront:v1.4

--

• Keep processing requests during the upgrade; update my containers one at a time

---

Other things that Kubernetes can do for us

• Autoscaling

  (straightforward on CPU; more complex on other metrics)

• Resource management and scheduling

  (reserve CPU/RAM for containers; placement constraints)

• Advanced rollout patterns

  (blue/green deployment, canary deployment)

---

More things that Kubernetes can do for us

• Batch jobs

  (one-off; parallel; also cron-style periodic execution)

• Fine-grained access control

  (defining what can be done by whom on which resources)

• Stateful services

  (databases, message queues, etc.)

• Automating complex tasks with operators

  (e.g. database replication, failover, etc.)

---

Kubernetes architecture

---

class: pic

---

Kubernetes architecture

• Ha ha ha ha

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

---

class: pic

---

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)

---

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)

---

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"

---

class: pic

---

class: extra-details

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)

---

class: extra-details

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

---

class: extra-details

How many nodes should a cluster have?

• There is no particular constraint

  (no need to have an odd number of nodes for quorum)

• A cluster can have zero node

  (but then it won't be able to start any pods)

• For testing and development, having a single node is fine

• For production, make sure that you have extra capacity

  (so that your workload still fits if you lose a node or a group of nodes)

• Kubernetes is tested with up to 5000 nodes

  (however, running a cluster of that size requires a lot of tuning)

---

class: extra-details

Do we need to run Docker at all?

No!

--

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

• We can leverage other pluggable runtimes through the Container Runtime Interface

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

---

class: extra-details

Some runtimes available through CRI

• containerd

  • maintained by Docker, IBM, and community
  • used by Docker Engine, microk8s, k3s, GKE; also standalone
  • comes with its own CLI, ctr

• CRI-O:

  • maintained by Red Hat, SUSE, and community
  • used by OpenShift and Kubic
  • designed specifically as a minimal runtime for Kubernetes

• And more

---

class: extra-details

Do we need to run Docker at all?

Yes!

--

• In this workshop, we run our app on a single node first

• We will need to build images and ship them around

• We can do these things without Docker
  (and get diagnosed with NIH¹ syndrome)

• Docker is still the most stable container engine today
  (but other options are maturing very quickly)

.footnote[¹Not Invented Here]

---

class: extra-details

Do we need to run Docker at all?

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

  Yes, almost certainly

• On our production servers:

  Yes (today)

  Probably not (in the future)

.footnote[More information about CRI on the Kubernetes blog]

---

Interacting with Kubernetes

• We will interact with our Kubernetes cluster through the Kubernetes API

• The Kubernetes API is (mostly) RESTful

• It allows us to create, read, update, delete resources

• A few common resource types are:

  • node (a machine — physical or virtual — in our cluster)

  • pod (group of containers running together on a node)

  • service (stable network endpoint to connect to one or multiple containers)

---

class: pic

---

Scaling

• How would we scale the pod shown on the previous slide?

• Do create additional pods

  • each pod can be on a different node

  • each pod will have its own IP address

• Do not add more NGINX containers in the pod

  • all the NGINX containers would be on the same node

  • they would all have the same IP address
    (resulting in Address alreading in use errors)

---

Together or separate

• Should we put e.g. a web application server and a cache together?
  ("cache" being something like e.g. Memcached or Redis)

• Putting them in the same pod means:

  • they have to be scaled together

  • they can communicate very efficiently over localhost

• Putting them in different pods means:

  • they can be scaled separately

  • they must communicate over remote IP addresses
    (incurring more latency, lower performance)

• Both scenarios can make sense, depending on our goals

---

Credits

• The first diagram is courtesy of Lucas Käldström, in this presentation

  • it's one of the best Kubernetes architecture diagrams available!

• The second diagram is courtesy of Weave Works

  • a pod can have multiple containers working together

  • IP addresses are associated with pods, not with individual containers

Both diagrams used with permission.