master node replicas are added to the cluster, congured

in High-Availability (HA) mode

A master node has the following components:

API server

Scheduler

Controller managers

etcd.

17

Master Node Components: API Server

All the administrative tasks are coordinated by the

kube-apiserver, a central control plane component

running on the master node. The API server intercepts

RESTful calls from users, operators and external agents,

then validates and processes them.

During processing the API server reads the Kubernetes

cluster's current state from the etcd, and after a call's

execution, the resulting state of the Kubernetes cluster is

saved in the distributed key-value data store for

persistence.

18

Master Node Components: etcd

etcd is a distributed key-value data store used to persist a

Kubernetes cluster's state. New data is written to the

data store only by appending to it, data is never replaced

in the data store. Obsolete data is compacted periodically

to minimize the size of the data store.

Out of all the control plane components, only the API

server is able to communicate with the etcd data store.

19

20

Master Node Components: Scheduler

The role of the kube-scheduler is to assign new objects,

such as pods, to nodes. During the scheduling process,

decisions are made based on current Kubernetes cluster

state and new object's requirements.

The scheduler obtains from etcd, via the API server,

resource usage data for each worker node in the cluster.

The scheduler also receives from the API server the new

object's requirements which are part of its conguration

data.

Master Node Components: Controller Managers 1/2

The controller managers are control plane components

on the master node running controllers to regulate the

state of the Kubernetes cluster.

Controllers are watch-loops continuously running and

comparing the cluster's desired state (provided by

objects' conguration data) with its current state

(obtained from etcd data store via the API server). In case

of a mismatch corrective action is taken in the cluster

until its current state matches the desired state.

21

Master Node Components: Controller Managers 2/2

The kube-controller-manager runs controllers

responsible to act when nodes become unavailable, to

ensure pod counts are as expected, to create endpoints,

service accounts, and API access tokens.

The cloud-controller-manager runs controllers

responsible to interact with the underlying infrastructure

of a cloud provider when nodes become unavailable, to

manage storage volumes when provided by a cloud

service, and to manage load balancing and routing.

22

A worker node provides a running environment for client

applications.

Though containerized microservices, these applications

are encapsulated in Pods, controlled by the cluster

control plane agents running on the master node

Pods

Pods are scheduled on worker nodes, where they nd

required compute, memory and storage resources to run,

and networking to talk to each other and the outside

world.

A Pod is the smallest scheduling unit in Kubernetes. It is a

logical collection of one or more containers scheduled

together.

23

24

A worker node has the following components:

Container runtime (Docker for example)

kubelet

kube-proxy

Addons for DNS, Dashboard, cluster-level

monitoring and logging.

Worker Node Components: Container Runtime

In order to run and manage a container's lifecycle,

Kubernetes requires a container runtime on the node

where a Pod and its containers are to be scheduled.

Kubernetes supports many container runtimes:

Docker

CRI-O

containerd

rkt

rktlet

25

26

Worker Node Components: kubelet

The kubelet is an agent running on each node and

communicates with the control plane components from

the master node.

It receives Pod denitions, primarily from the API server,

and interacts with the container runtime on the node to

run containers associated with the Pod. It also monitors

the health of the Pod's running containers.

Worker Node Components: kube-proxy

The kube-proxy is the network agent which runs on each

node responsible for dynamic updates and maintenance

of all networking rules on the node.

It abstracts the details of Pods networking and forwards

connection requests to Pods.

27

28

Worker Node Components: Addons

Addons are cluster features and functionality not yet

available in Kubernetes, therefore implemented through

3rd-party pods and services.

DNS - cluster DNS is a DNS server required to assign DNS records to

Kubernetes objects and resources

Dashboard - a general purposed web-based user interface for

cluster management

Monitoring - collects cluster-level container metrics and saves

them to a central data store

Logging - collects cluster-level container logs and saves them to a

central log store for analysis.

29

30

Kubernetes, as a container orchestrator, is needs to address 4 distinct networking challenges:

Container-to-container communication inside Pods

Pod-to-Pod communication on the same node and across cluster nodes

Pod-to-Service communication within the same namespace and across cluster namespaces

External-to-Service communication for clients to access applications in a cluster.

31

32

TABLE DES MATI RES

01

02

03

Pr sentation de Kubernetes

Architecture Kubernetes

Objets Kubernetes

04

Manipulation de Kubernetes en ligne de Commande

05

Exemple

Version 1.0

33

Kubernetes rich object model, represents different persistent entities in

the Kubernetes cluster (Pods, ReplicaSets, Deployments, Namespaces,

Services&)

With each object, we declare our intent or the desired state under the spec

section. The Kubernetes system manages the status section for objects, where it

records the actual state of the object. At any given point in time, the Kubernetes

Control Plane tries to match the object's actual state to the object's desired

state.

34

Kubernetes rich object model, represents different persistent entities in

the Kubernetes cluster (Pods, ReplicaSets, Deployments, Namespaces,

Services&)

in practice, a YAML le is used to describe the desired state (the spec section) of

an object and is send to the apiserver of master node using kubectl (kubernetes

cli)

35

36

apiVersion: v1

kind: Pod

metadata:

name: mypod

labels:

app: webserver

spec:

containers:

D

O

P

• name: mycontainer

image: nginx:latest

resources:

requests:

memory: "128Mi" # 128Mi = 128 mebibytes

cpu: "500m" # 500m = 500 milliCPUs (1/2 CPU)

limits:

memory: "128Mi"

cpu: "500m"

ports:

• containerPort: 80

E

C

A

P

S

E

M

A

N

I

E

C

V

R

E

S

apiVersion: v1

kind: Namespace

metadata:

name: microservice

labels:

app: counter

apiVersion: v1

kind: Service

metadata:

name: app-tier

labels:

app: microservices

spec:

ports:

• port: 8080

selector:

app: webserver

37

apiVersion : required, species the API endpoint on the API server which

we want to connect to. Must match an existing version for the object type

dened

kind : required, specifying the object type (Deployment, Pod, Replicaset,

Namespace, Service, ...)

metadata : required, holds the object's basic information, such as name,

labels, namespace, etc

spec : required, marks the beginning of the block dening the desired state

of the object

38

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deployment

labels:

app: nginx

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

T

N

E

M

Y

O

L

P

E

D

app: nginx

spec:

containers:

• name: nginx

image: nginx:1.15.11

ports:

• containerPort: 80

39

If multiple users and teams use the same Kubernetes cluster we can

partition the cluster into virtual sub-clusters using Namespaces. The

names of the resources/objects created inside a Namespace are unique,

but not across Namespaces in the cluster.

Generally, Kubernetes creates four default Namespaces:

kube-system / kube-public / kube-node-lease : the objects created by the

Kubernetes system

default : objects and resources created by administrators and developers.

40

Groupe de containers

La plus petite entit de construction dans

Kubernetes (unit of deployment)

Des abstractions (objets) plus utiles et complexes sont b ties sur la notion de

Pods

A Pod is a logical collection of one or more containers, which:

Are scheduled together on the same host with the Pod

Share the same network namespace

Have access to mount the same external storage (volumes).

41

Groupe de containers

Sa d claration (chier yaml) inclut tous les d tails relatifs aux containers

Propri t s intrins ques aux containers : image, ports, restart policy, limite de

ressources

Propri t s requises par K8S pour la gestion de containers

Le Pod poss de une seule adresse IP

Tous les containers dun Pod partagent le m me r seau

42

Pods are ephemeral in nature,

Do not have the capability to self-heal by themselves

That is the reason they are used with controllers

which handle Pods' replication, fault tolerance, self-healing, etc. (for example:

Deployments, ReplicaSets, ReplicationControllers, etc)

in YAML :

apiVersion : v1 / kind : Pod / metadata : ... / spec : &.

D nit les r gles r seau permettant dexposer un groupe de Pods

Vers les autres Pods

Vers le public (internet)

Un service poss de une adresse IP xe

Un service distribue la charge de travail vers les diff rents Pods du groupe

Un service peut tre cr pour acc der un groupe de pod en utilisant les

labels

43

44

key-value pairs attached to Kubernetes objects

Used to organize and select a subset of objects,

based on the requirements in place

Many objects can have the same Label(s)

Labels do not provide uniqueness to objects

Controllers use Labels to logically group together decoupled objects,

rather than using objects' names or IDs.

With the help of the ReplicaSet, we can scale the number of Pods running

a specic container

application image.

Scaling can be accomplished

manually or through the use

of an autoscaler.

45

46

47

48

ReplicaSets can be used independently as Pod controllers but they only

offer a limited set of features. A set of complementary features are

provided by Deployments, the recommended controllers for the

orchestration of Pods.

Deployments manage the creation, deletion, and updates of Pods. A

Deployment automatically creates a ReplicaSet, which then creates a

Pod.

No need to manage ReplicaSets and Pods separately, the Deployment will

manage them on our behalf.

Prend en charge le d ploiement des changements de conguration vers

les Pods en ex cution

Prend en charge la mise l' chelle horizontale (scale out / horizontal

scaling)

49

Deployment objects provide declarative updates to Pods and ReplicaSets.

The Deployment Controller is part of the master node's controller

manager, and it ensures that the current state always matches the desired

state.

It allows for seamless application updates and downgrades through rollouts

and rollbacks, and it directly manages its ReplicaSets for application scaling.

50

51

52

Rolling update NGINX 1.7. => 1.9.1

Once the rolling update has

completed, the Deployment

will show both ReplicaSets A

and B where A is scaled to 0

(zero) Pods, and B is scaled to

3 Pods.

TABLE DES MATI RES

01

02

03

Pr sentation de Kubernetes

Architecture Kubernetes

Objets Kubernetes

04

Manipulation de Kubernetes en ligne de Commande

05

Exemple

Version 1.0

53

54

kubectl create creates a new Kubernetes resource (based on YAML manifest le)

kubectl delete deletes a particular resource.

kubectl get returns a list of all the resources of a specied type.

kubectl get pods will list pods.

kubectl describe prints detailed information about a particular resource or a list of

resources.

kubectl describe pod server gives detailed information about the pod named server.

kubectl logs prints container logs for a particular pod or a specic container inside

of a multi-container pod.

The pod / container log contains all what is written to standard output /

standard error output

Kubernetes est une plateforme dorchestration de containers

Un groupe de noeuds forme un cluster Kubernetes

Master : Cerveau du cluster, ex cute la partie contr le (control plane)

Worker : Ex cute le workload m tier, contient le SW pour communiquer avec

le master

Kubernetes ex cute les containers dans des groupes appel s Pods

Un Service K8S expose les Pods au cluster et au r seau public (internet)

Un d ploiement Kubernetes contr le le rollout/rollback des containers

55

56

TABLE DES MATI RES

01

02

03

Pr sentation de Kubernetes

Architecture Kubernetes

Objets Kubernetes

04

Manipulation de Kubernetes en ligne de Commande

05

Exemple

DEMO TIME

Auto formation

training.play-with-kubernetes.com

katacoda kubernetes playground

Exemple

https://github.com/cloudacademy/intro-to-k8s

Version 1.0

57

58

BD cl s/valeur en m moire,

permettant d'enregistrer la

valeur actuelle du compteur

Expose des web services

permettant aux poller et

counter de fonctionner

DATA Tier

name=redis

(redis)

Service Tier

name=app

(microservice/nodejs)

Utilisation de variables

dEnvironement pour la

conguration des containers

Afche la valeur du compteur

dans un message sur la sortie

standard

Support Tier

name=poller

(shell)

Support Tier

name=counter

(shell)

Incr mente le compteur par un

chiffre al atoire entre 1 et 10.

Afche un message indiquant la

valeur de l'incr ment sur la

sortie standard

59

more app/poll.sh

#!/usr/bin/env sh

while true; do

echo "Current counter: $(curl -s "${API_URL}/")"

sleep 2

done

Support Tier

name=poller

(shell)

DATA Tier

name=redis

(redis)

Service Tier

name=app

(microservice/nodejs)

Support Tier

name=counter

(shell)

more app/count.sh

#!/usr/bin/env sh

while true; do

n="$(shuf -i 1-10 -n 1)"

echo "Incrementing counter by ${n} ..."

curl -s -X POST -d "n=${n}" "${API_URL}/"

sleep 1

done

60

DATA Tier

name=redis

(redis)

Service Tier

name=app

(microservice/nodejs)

POD = app

namespace = microservice

Support Tier

name=poller

(shell)

Support Tier

name=counter

(shell)

DATA Tier

name=redis

(redis)

I

E

C

V

R

E

S

Service Tier

name=app

(microservice/nodejs)

I

E

C

V

R

E

S

POD = data-tier

POD = app-tier

namespace = service-discovery

Support Tier

name=poller

(shell)

Support Tier

name=counter

(shell)

POD = support-tier

61

62

based on deployment

artifact (yaml file)

based on deployment

artifact (yaml file)

DATA Tier

name=redis

(redis)

I

E

C

V

R

E

S

Service Tier

name=app

(microservice/nodejs)

I

E

C

V

R

E

S

based on deployment

artifact (yaml file)

Support Tier

name=poller

(shell)

Support Tier

name=counter

(shell)

namespace = deployment

63