• Big picture view
• Masters
• Nodes
• Pods
• Services
• Deployments
• Recap

Kubernetes

Big Picture View

Kubernetes

An Orchestrator for

Microservice Apps

Masters

The Kubernetes Control Plane

Multi-master HA

kube-apiserver

Front-end to the control
plane

Exposes the API (REST)

Consumes JSON

(via manifest files)

Cluster store

Persistent storage

Cluster state and config

Uses etcd

Distributed, consistent, watchable…

The “source of truth” for the cluster

Have a backup plan for it!

kube-controller-manager

Controller of controllers

• Node controller
• Endpoints controller
• Namespace controller
• …

Watches for changes
Helps maintain desired state

Controllers

Control Loops

kube-scheduler

Watches apiserver for new pods

Assigns work to nodes

• affinity/anti-affinity
• constraints
• resources
• …

Nodes a . k . a “Minions”

The Kubernetes Worker

Kubelet

• The main Kubernetes agent
• Registers node with cluster
• Watches apiserver
• Instantiates pods
• Reports back to master
• Exposes endpoint on :10255

Container Engine

Does container management:

• Pulling images
• Starting/stopping containers
• ...

Pluggable:

• Usually Docker
• Can be rkt

Kubernetes Networking Requirements

kube-proxy

Kubernetes networking:

• Pod IP addresses
• All containers in a
  pod share a single IP
• Load balances across
  all pods in a service

Kubelet
Main Kubernetes agent

Container
engine Docker or rkt

kube-proxy
Kubernetes networking

Scheduled/Add-On Pods

Declarative Model

Desired State

Kubernetes API Objects

Not an exhaustive list, but these are the key players

Containers always
run inside of pods

Pods can have multiple
containers
(advanced use-case)

Ring-fenced environment

• Network stack
• Kernel namespaces
• ...

n containers

All containers in pod
share the pod environment

Tight Coupling

Loose Coupling

Pods and Scaling

Multi-container Pods

Pods are Atomic

Pods are Atomic

Pods are Atomic

Pod Lifecycle

Theory

Inter-pod Communication

Intra-pod Communication

Pods

One or more containers
It’s your application or service
The most basic unit of work
Unit of scheduling
Ephemeral - no Pod is ever “redeployed”
Atomicity - they’re there or NOT

Pods - Continued

Kubernetes’ job is keeping your Pods running
More specifically keeping the desired state
State - is the Pod up and running
Health - is the application in the Pod running
Liveness probes

Deploying Pods

Usually via higher level objects

Deploying Pods

Usually via higher level objects

Services

Deployments

Objects
in the
K8s API

Pods : Atomic unit of scheduling…

Replication
Controllers : Scale pods, desired state etc…

Deployments : RC + rolling updates, rollbacks…

Services : Stable networking…

So how does Kubernetes manage my
Pods’ state?

Controllers

Create and manage Pods for you
Define your desired state Respond to Pod state and health
ReplicaSet
Number of replicas
Deployment
Manage rollout of ReplicaSet
Many more…and not just Pods

So how does Kubernetes add persistency
to all this ephemerality?

Services

Adds persistency to our ephemeral world
Networking abstraction for Pod access
IP and DNS name for the service
Redeployed Pods automatically updated
Scaled by adding/removing Pods
Load balancing

What about my data?
Where’s that stored in Kubernetes?