The document provides an overview of containers and Kubernetes. It discusses the need for containers due to microservices and infrastructure as code. It then covers technical details of containers like Dockerfiles, images, and registries. It also discusses Kubernetes and its components like kube-apiserver, etcd, and kubelet. Finally, it covers Kubernetes concepts like pods, services, deployments, and how they are configured.

1. Containers and Kubernetes
Leo’s Notes
Leopold Gault

3. Program Agenda
1. Containers:
1. The need for containers
2. Technical overview of containers
2. Kubernetes:
1. The need for Kubernetes
2. Technical overview of Kubernetes

4. Program Agenda
1. Containers:
1. The need for containers
2. Technical overview of containers
2. Kubernetes:
1. The need for Kubernetes
2. Technical overview of Kubernetes

5. The need for containers
1. The need for micro-services
2. The need for infrastructure as code

6. Monolithic vs SOA vs Microservice

7. Monolithic applications VS Microservices
Monolithic application Microservices (APIs)

8. Monolithic applications VS Microservices
Monolithic cake
Microservices cake

9. The need for containers
1. The need for micro-services
2. The need for infrastructure as code
Subject covered orally

10. Program Agenda
1. Containers:
1. The need for containers
2. Technical overview of containers
2. Kubernetes:
1. The need for Kubernetes
2. Technical overview of Kubernetes

11. Containers: what they are
A container is an image of a set of applications and configuration-
data.
Such image is:
• Immutable
• Portable
• Can be saved in a “photo album”: an images-repository.

12. Virtual Machines vs. Containers
Virtual Machines
● Each virtual machine (VM) includes the
app, the necessary binaries and libraries
and an entire guest operating system
Containers
● Containers include the app & all of its dependencies, but
share the OS kernel with other containers.
● Run as an isolated process in the userspace of the host OS
VMs
Containers

13. Let’s have a look at Wikipedia’s listing
Different levels of virtualization
source
Version of 14th Sept 2017

14. Different types of containers
• Linux Containers (LXC)
• OpenVZ
• Warden Containers (used by Pivotal CloudFoundry)
• RKT (developed by CoreOS)
• Docker
• Implementations of the Open Containers Initiative (OCI)
• …
OS-level virtualization solutions

15. Dockerfile
Container image
docker build
Repo
Docker registry docker run
Container runtime:
Linux kernel + Docker engine
Highlight about Docker

16. Building container images
My mongoDB :
FROM ubuntu_base_image
RUN apt-get update
RUN apt-get install
mongoDB
EXPOSE 8080
ENTRY POINT
/uns/binn/mongoDb
DockerFile
Ubuntu_base_image
(from private or
public registry)
Docker deamon
> docker build
Container image
Repo
My Docker
registry
Leo’s container
image

17. Container image
Repo
Docker registry
docker run -p 4000 :8080 friendlyhello
Container runtime:
Linux kernel + Docker engine
:8080
:4000

18. About building images on top of other images
Files that are removed by subsequent layers in the system are
actually still present in the images; they’re just inaccessible.
E.g.
In terms of building images, this also means that if
server.js is changed, layer B and layer C will have to
be rebuilt (so you have to order your layers from
the least likely to change to most likely)
Image
Image
Image
Although “BigFile” is no longer accessible in the image
‘Layer C’, it is still present in Layer A, which Layer C is
built on.
With the right tools, BigFile can still be accessed by
anyone having access to the image Layer C.
In terms of network traffic, this also means that
whenever you push or pull Layer C, BigFile is still
transmitted through the network.

19. Program Agenda
1. Containers:
1. The need for containers
2. Technical overview of containers
2. Kubernetes:
1. The need for Kubernetes
2. Technical overview of Kubernetes

20. The need for Kubernetes
1. The need for declarative infrastructure as code
2. The need for cluster management of container-engines
Subject covered orally

21. The need for Kubernetes
1. The need for declarative infrastructure as code
2. The need for cluster management of container-engines

22. Containers management platforms
Manage distributed containers, and their lifecycle
Containers
Management
Platform

23. Containers management platforms
Manage distributed containers, and their lifecycle
Docker Swarm

24. Program Agenda
1. Containers:
1. The need for containers
2. Technical overview of containers
2. Kubernetes:
1. The need for Kubernetes
2. Technical overview of Kubernetes

25. Components of a K8s cluster

26. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
Master node
Worker node
cloud-controller-manager
It is the front-end for the Kubernetes
control plane
controls
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)

27. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
Master node
Worker node
cloud-controller-manager
Distributed key-value store.
Provides a dynamic configuration
registry.
controls
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)

28. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
Master node
Worker node
cloud-controller-manager
Watches newly created pods that
have no node assigned yet, and
selects a node for them to run on.
controls
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)

29. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
Master node
Worker node
cloud-controller-manager
controls
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)
Component on the master that runs controllers.
These controllers include:
• Node Controller: detects when nodes go down, and responds.
• Replication Controller: maintains the correct number of pods for every replication
controller object (replicaset?) in the system.
• Endpoints Controller: deploys the “Endpoints object” (i.e. services and pods) into the
cluster.
• Service Account & Token Controllers: Creates default accounts and API access tokens for
new namespaces.

30. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
Master node
Worker node
cloud-controller-manager
controls
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)
Runs controllers that interact with the underlying cloud providers.
Those controllers are specific to the cloud-provider. Those controllers are:
• Node Controller: when a node stops responding, it checks with the cloud
provider to determine if this node has been deleted
• Route Controller: sets up routes in the underlying cloud infrastructure
• Service Controller: creates, updates and deletes cloud provider load balancers
• Volume Controller: creates, attaches, and mounts volumes, and interacts with
the cloud provider to orchestrate volumes

31. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
controls
Master node
Worker node
cloud-controller-manager
Makes sure that containers are running in a pod.
The kubelet takes a set of PodSpecs that are provided through various
mechanisms and ensures that the containers described in those PodSpecs
are running and healthy.
kube-proxy
Container runtime
(Docker, rkt, runc, etc.)

32. Components of a cluster
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Kubelet
connected to
controls
Master node
Worker node
cloud-controller-manager
kube-proxy
Enables the Kubernetes service abstraction by
maintaining network rules on the host and performing
connection forwarding.
Container runtime
(Docker, rkt, runc, etc.)

33. Pods, services, deployments

34. Pods
IP2
Shared storage
Node 1
IP1
Shared storage
(volume)
Leo:
You normally put in a pod just one container, or a
handful of containers that are tightly coupled (e.g. a
Tomcat container + a Git syncrhonizer; with both apps
interacting thru a local filesystem).
You achieve horizontal scaling by replicating pods; not
by replicating containers within a pod.
Created from an image

35. Example of anti-pattern Pod
Node 1
IP1

36. Pod spec
Example of pod spec

37. Communication between containers within a same
pod
Node 1
IP1
Shared storage
(volume)
From: localhost:8080
To: localhost:3306
Kubernetes has an “IP-per-pod model”: containers within a
same pod share the same IP address, and communicate with
each other using distinct ports, on localhost.
I know this is anti-pattern. It
is just an example.

38. Pods and network
Private overlay network within the Kubernetes cluster
Node 1
Node 2
Real network
IP3IP1
IP2

39. The need for services
Private overlay network within the Kubernetes cluster
Node 1
Node 2
Real network
IP3IP1
IP2
Weblogic cluster
Managed server1
Managed server2
App which is a client of the
Weblogic cluster

40. Services and network
Private overlay network within the Kubernetes cluster
Node 1
Node 2
Real network
IP3
ServiceA
IP4
IP1
IP2
Acts like a LB
between Pods

41. Service
A level of abstraction providing an external and durable access to a set of pods.
A service :
• encompasses serval Pods,
• has its own (private) IP (thus allowing consuming services to use the Service’s IP,
instead of the Pod’s, which may change frequently),
• load balances the IP packets it receives to its Pods.

42. Services and network
Private overlay network within the Kubernetes cluster
Node 1
Node 2
Real network
IP3
ServiceA
IP4
IP1
IP2
Can optionally be made
reachable from the real
network
Acts like a LB
between Pods

43. Services and network
Private overlay network within the Kubernetes cluster
Real network
IP3
ServiceA
IP4
IP1
IP2
Can optionally be made
reachable from the real
network
Port of your choosing
E.g. with the service-type “NodePort”:
each hosting node will act as a NAT
server specifically for this IP; i.e. it will
associate one of its port to the IP4
Acts like a LB
between Pods
Port of your choosing

44. Service
A level of abstraction providing an external and durable access to a set of pods.
A service :
• encompasses serval Pods,
• has its own (private) IP (thus allowing consuming services to use the Service’s IP,
instead of the Pod’s, which may change frequently),
• load balances the IP packets it receives to its Pods.
• Provides 3 types of access:
• ClusterIP: the service is only visible from inside the cluster

45. Services and network
Private overlay network within the Kubernetes cluster
Node 1
Node 2
Real network
IP3
ServiceA
IP4
IP1
IP2
Acts like a LB
between Pods

46. Service
A level of abstraction providing an external and durable access to a set of pods.
A service :
• encompasses serval Pods,
• has its own (private) IP (thus allowing consuming services to use the Service’s IP,
instead of the Pod’s, which may change frequently),
• load balances the IP packets it receives to its Pods.
• Provides 3 types of access:
• ClusterIP: the service is only visible from inside the cluster
• NodePort: each node in the cluster maps an external port to the service’s private IP

47. Services and network
Private overlay network within the Kubernetes cluster
Real network
IP3
ServiceA
IP4
IP1
IP2
Can optionally be made
reachable from the real
network
Port of your choosing
E.g. with the service-type “NodePort”:
each hosting node will act as a NAT
server specifically for this IP; i.e. it will
associate one of its port to the IP4
Acts like a LB
between Pods
Port of your choosing

48. Service
A level of abstraction providing an external and durable access to a set of pods.
A service :
• encompasses serval Pods,
• has its own (private) IP (thus allowing consuming services to use the Service’s IP,
instead of the Pod’s, which may change frequently),
• load balances the IP packets it receives to its Pods.
• Provides 3 types of access:
• ClusterIP: the service is only visible from inside the cluster
• NodePort: each node in the cluster maps an external port to the service’s private IP
• LoadBalancer: a LB from the cloud provider will forward the traffic from the service the
nodes within it. (like NodePort, but on top of this, an external LB is configured to balance the
traffic between the nodes:servicePort?)

49. Services and network
Private overlay network within the Kubernetes cluster
Real (private) network
IP3
ServiceA
IP4
IP1
IP2
Port of your choosing
Acts like a LB
between Pods
Port of your choosing
load balancer
(cloud service)

50. Services identify their pods (and deployments) thanks to labels

51. Deployment features
Additional: enforce replicasets, by
• deploying the pods,
• monitoring them,
• Stop/restart them,
• redeploying them on another node if
needed.
• Perform rolling updates
• Undo an update if requested
Deployments
Deployments are a declarative way to ensure that the number of Pods running is equal to what the user declared to want.
Deployments keep our Pods up and running, even when the nodes they run on fail.
If Pods are declaratively updated (e.g. container image changed) or scaled, the Deployment will handle that.

52. Deployment spec vs Pod spec
Example of deployment Example of pod
The same as a pod spec
Specific to deployment spec

53. Deployment spec vs Pod spec
Example of deployment Example of pod
The same as a pod spec
Specific to deployment spec

54. Deployment spec vs Pod spec
Example of deployment Example of pod
The same as a pod spec
Specific to deployment spec
Services identify their pods,
and thus their deployments,
thanks to labels

55. Deployments
Pod
deployment1 (replicas==1)
Pod(s) host

56. E.g. of deployment spec
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template: # create pods using pod definition in this template
metadata:
# unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is
# generated from the deployment name
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
deployment.yaml