FORMATION DOCKER

1
CONCERNANT CES SUPPORTS DE COURS

2.1
SUPPORTS DE COURS RALISS PAR OSONES
https://osones.com

Copyright 2016 Osones

Licence : Creative Commons BY-SA 4.0
Sources : https://github.com/Osones/Formations/
Online : http://formations.osones.com

2.2
 AUTEURS
Romain Guichard
romain.guichard@osones.io
Kevin Lefevre kevin.lefevre@osones.io

2.3
LE CLOUD : VUE DENSEMBLE

3.1
 LE CLOUD, CEST LARGE !
Stockage/calcul distant (on oublie, cf.
externalisation)
Virtualisation++
Abstraction du matriel (voire plus)
Accs normalis par des APIs
Service et facturation la demande
Flexibilit, lasticit

3.2
WAAS : WHATEVER AS A SERVICE
IaaS : Infrastructure as a
Service
PaaS : Platform as a Service
SaaS : Software as a Service

3.3
LE CLOUD EN UN SCHMA

3.4
POURQUOI DU CLOUD ? CT TECHNIQUE
Abstraction des couches basses
On peut tout programmer son gr (API)
Permet la mise en place darchitectures scalables

3.5
 VIRTUALISATION DANS LE CLOUD
Le cloud IaaS repose souvent sur la virtualisation
Ressources compute : virtualisation
Virtualisation complte : KVM, Xen
Virtualisation conteneurs : OpenVZ, LXC, Docker,
RKT

3.6
 NOTIONS ET VOCABULAIRE IAAS
Linstance est par dfinition phmre
Elle doit tre utilise comme ressource de
calcul
Sparer les donnes des instances

3.7
 ORCHESTRATION DES RESSOURCES ?
Groupement fonctionnel de ressources : micro services
Infrastructure as Code : Dfinir toute une infrastructure dans
un seul fichier texte de manire dclarative
Scalabilit : passer l'chelle son infrastructure en fonction
de diffrentes mtriques.

3.8
 POSITIONNEMENT DES CONTENEURS DANS
L'COSYSTME CLOUD ?
Facilitent la mise en place de PaaS
Fonctionnent sur du IaaS ou sur du bare-metal
Simplifient la dcomposition d'applications en micro
services

3.9
LES CONTENEURS

4.1
 DFINITION
Les conteneurs fournissent un environnement isol sur un
systme hte, semblable un chroot sous Linux ou une jail
sous BSD, mais en proposant plus de fonctionnalits en
matire d'isolation et de configuration. Ces fonctionnalits
sont dpendantes du systme hte et notamment du kernel.

4.2
LE KERNEL LINUX
Namespaces
Cgroups (control groups)

4.3
LES NAMESPACES

4.4
 MOUNT NAMESPACES ( LINUX 2.4.19)
Permet de crer un arbre des points de montage
indpendants de celui du systme hte.

4.5
 UTS NAMESPACES (LINUX 2.6.19)
Unix Time Sharing : Permet un conteneur de disposer de
son propre nom de domaine et didentit NIS sur laquelle
certains protocoles tel que LDAP peuvent se baser.

4.6
 IPC NAMESPACES (LINUX 2.6.19)
Inter Process Communication : Permet disoler les bus de
communication entre les processus dun conteneur.

4.7
 PID NAMESPACES (LINUX 2.6.24)
Isole larbre dexcution des processus et permet donc
chaque conteneur de disposer de son propre processus
matre (PID 0) qui pourra ensuite excuter et manager
d'autres processus avec des droits illimits tout en tant un
processus restreint au sein du systme hte.

4.8
 USER NAMESPACES (LINUX 2.6.23-3.8)
Permet lisolation des utilisateurs et des groupes au sein dun
conteneur. Cela permet notamment de grer des utilisateurs
tels que lUID 0 et GID 0, le root qui aurait des permissions
absolues au sein dun namespace mais pas au sein du
systme hte.

4.9
 NETWORK NAMESPACES (LINUX 2.6.29)
Permet lisolation des ressources associes au rseau,
chaque namespace dispose de ses propres cartes rseaux,
plan IP, table de routage, etc.

4 . 10
 CGROUPS : CONTROL CROUPS
CGroup: /
|--docker
| |--7a977a50f48f2970b6ede780d687e72c0416d9ab6e0b02030698c1633fdde956
| |--6807 nginx: master process ngin
| | |--6847 nginx: worker proces

4 . 11
 CGROUPS : LIMITATION DE RESSOURCES
Limitation des ressources : des groupes peuvent tre mis en
place afin de ne pas dpasser une limite de mmoire.

4 . 12
 CGROUPS : PRIORISATION
Priorisation : certains groupes peuvent obtenir une plus
grande part de ressources processeur ou de bande passante
d'entre-sortie.

4 . 13
 CGROUPS : COMPTABILIT
Comptabilit : permet de mesurer la quantit de ressources
consommes par certains systmes, en vue de leur
facturation par exemple.

4 . 14
 CGROUPS : ISOLATION
Isolation : sparation par espace de nommage pour les
groupes, afin qu'ils ne puissent pas voir les processus des
autres, leurs connexions rseaux ou leurs fichiers.

4 . 15
 CGROUPS : CONTRLE
Contrle : figer les groupes ou crer un point de sauvegarde
et redmarrer.

4 . 16
 DEUX PHILOSOPHIES DE CONTENEURS
Systeme : simule une squence de boot complte avec un init
process ainsi que plusieurs processus (LXC, OpenVZ).
Process : un conteneur excute un ou plusieurs processus
directement, en fonction de l'application conteneurise
(Docker, Rkt).

4 . 17
ENCORE PLUS CLOUD QUUNE INSTANCE
Partage du kernel
Un seul processus par conteneur
Le conteneur est encore plus phmre que
linstance
Le turnover des conteneurs est lev : orchestration

4 . 18
CONTAINER RUNTIME
Docker
Rkt
LXC

4 . 19
 LXC
Conteneur systme
Utilise la liblxc
Virtualisation d'un systme complet (boot)

4 . 20
 DOCKER
Dvelopp par dotCloud et open sourc en mars 2013
Fonctionne en mode daemon : difficult d'intgration avec
les init-process
Utilisait la liblxc
Utilise dsormais la libcontainer

4 . 21
 ROCKET (RKT)
Se prononce rock-it
Dvelopp par CoreOS
Pas de daemon : intgration avec systemd
Utilise systemd-nspawn et propose maintenant d'autres
solutions (eg. KVM)
Adresse certains problmes de scurit inhrents Docker

4 . 22
 LES CONTENEURS: CONCLUSION
Fonctionnalits offertes par le Kernel
Les conteneurs engine fournissent des interfaces
d'abstraction
Plusieurs types de conteneurs pour diffrents besoins

4 . 23
LES CONCEPTS

5.1
UN ENSEMBLE DE CONCEPTS ET DE
COMPOSANTS
Layers
Stockage
Volumes
Rseau
Publication de ports
Links
5.2
 LAYERS
Les conteneurs et leurs images sont dcomposs en couches
(layers)
Les layers peuvent tre rutiliss entre diffrents conteneurs
Gestion optimise de l'espace disque.

5.3
 LAYERS : UNE IMAGE

Une image se decompose en layers

5.4
 LAYERS : UN CONTENEUR

Une conteneur = une image + un layer r/w

5.5
LAYERS : PLUSIEURS CONTENEURS

Une image, plusieurs conteneurs

5.6
LAYERS : RPTITION DES LAYERS

Les layers sont indpendants de l'image

5.7
 STOCKAGE
Images Docker, donnes des conteneurs, volumes
Multiples backends (extensibles via plugins):
AUFS
DeviceMapper
OverlayFS
NFS (via plugin Convoy)
GlusterFS (via plugin Convoy)

5.8
 STOCKAGE : AUFS
A unification filesystem
Stable : performance criture moyenne
Non intgr dans le Kernel Linux (mainline)

5.9
STOCKAGE : DEVICE MAPPER
Bas sur LVM
Thin Provisionning et snapshot
Intgr dans le Kernel Linux (mainline)
Stable : performance criture moyenne

5 . 10
 STOCKAGE : OVERLAYFS
Successeur de AUFS
Performances accrues
Relativement stable mais moins prouv que AUFS ou Device
Mapper

5 . 11
 STOCKAGE : PLUGINS
tendre les drivers de stockages disponibles
Utiliser des systmes de fichier distribus
(GlusterFS)
Partager des volumes entre plusieurs htes docker

5 . 12
 VOLUMES
Assurent une persistance des donnes
Indpendance du volume par rapport au conteneur et aux
layers
Deux types de volumes :
Conteneur : Les donnes sont stockes dans ce que l'on
appelle un data conteneur
Hte : Montage d'un dossier de l'hte docker dans le
conteneur
Partage de volumes entre plusieurs conteneurs
5 . 13
 VOLUMES : EXEMPLE

Un volume mont sur deux conteneurs

5 . 14
 VOLUMES : PLUGINS
Permettre le partage de volumes entre differents htes
Fonctionnalit avances : snapshot, migration,
restauration
Quelques exemples:
Convoy : multi-host et multi-backend (NFS, GlusterFS)
Flocker : migration de volumes dans un cluster

5 . 15
RSEAU : A LA BASE, PAS GRAND CHOSE...
NETWORK ID NAME DRIVER
42f7f9558b7a bridge bridge
6ebf7b150515 none null
0509391a1fbd host host

5 . 16
RSEAU : BRIDGE

5 . 17
RSEAU : HOST

5 . 18
RSEAU : NONE
Explicite

5 . 19
 RSEAU : LES VOLUTIONS
Refactorisation des composants rseau (libnetwork)
Systme de plugins : multi host et multi backend (overlay
network)
Quelques exemples d'overlay :
Flannel : UDP et VXLAN
Weaves : UDP

5 . 20
RSEAU : MULTIHOST OVERLAY

5 . 21
 PUBLICATION DE PORTS
Dans le cas d'un rseau diffrent de l'hte
Les conteneurs ne sont pas accessible depuis l'extrieur
Possibilit de publier des ports depuis l'hte vers le
conteneur (iptables)
L'hte sert de proxy au service

5 . 22
PUBLICATION DE PORTS

5 . 23
 LINKS
Les conteneurs d'un mme rseau peuvent communiquer via
IP
Les liens permettent de lier deux conteneurs par nom
Systme de DNS rudimentaire (/etc/hosts)
Remplacs par les discovery services

5 . 24
 LES CONCEPTS: CONCLUSION
Les composants de Docker sont modulaires
Nombreuses possibilits offertes par dfaut.
Possibilit d'tendre les fonctionnalits via des
plugins

5 . 25
BUILD, SHIP AND RUN !

6.1
BUILD

6.2
LE CONTENEUR ET SON IMAGE
Flexibilit et lasticit
Format standard de facto
Instanciation illimite

6.3
 CONSTRUCTION D'UNE IMAGE
Possibilit de construire son image la main (long et source
d'erreurs)
Suivi de version et construction d'images de manire
automatise
Utilisation de Dockerfile afin de garantir l'idempotence des
images

6.4
 DOCKERFILE
Suite d'instruction qui dfinit une image
Permet de vrifier le contenu d'une image

FROM alpine:3.4
MAINTAINER Osones <docker@osones.io>
RUN apk -U add nginx
EXPOSE 80 443
CMD ["nginx"]

6.5
 DOCKERFILE : PRINCIPALES INSTRUCTIONS
FROM : baseimage utilise
RUN : Commandes effectues lors du build de l'image
EXPOSE : Ports exposes lors du run (si -P est prcis)
ENV : Variables d'environnement du conteneur
l'instanciation
CMD : Commande unique lance par le conteneur
ENTRYPOINT : "Prfixe" de la commande unique lance par
le conteneur
6.6
 DOCKERFILE : BEST PRACTICES
Bien choisir sa baseimage
Chaque commande Dockerfile gnre un nouveau
layer
Comptez vos layers !

6.7
 DOCKERFILE : BAD LAYERING
RUN apk --update add \
git \
tzdata \
python \
unrar \
zip \
libxslt \
py-pip \

RUN rm -rf /var/cache/apk/*

VOLUME /config /downloads

EXPOSE 8081

CMD ["--datadir=/config", "--nolaunch"]

ENTRYPOINT ["/usr/bin/env","python2","/sickrage/SickBeard.py"]

6.8
 DOCKERFILE : GOOD LAYERING
RUN apk --update add \
git \
tzdata \
python \
unrar \
zip \
libxslt \
py-pip \
&& rm -rf /var/cache/apk/*

VOLUME /config /downloads

EXPOSE 8081

CMD ["--datadir=/config", "--nolaunch"]

ENTRYPOINT ["/usr/bin/env","python2","/sickrage/SickBeard.py"]

6.9
 DOCKERFILE : DOCKERHUB
Build automatise d'images Docker
Intgration GitHub / DockerHub
Plateforme de stockage et de distribution d'images
Docker

6 . 10
SHIP

6 . 11
SHIP : LES CONTENEURS SONT MANIPULABLES
Sauvegarder un conteneur
:
docker commit mon-conteneur backup/mon-conteneur

docker run -it backup/mon-conteneur

Exporter un conteneur
:
docker save -o mon-image.tar backup/mon-conteneur

Importer un conteneur
:
docker import mon-image.tar backup/mon-conteneur

6 . 12
 SHIP : DOCKER REGISTRY
DockerHub nest quau Docker registry ce que GitHub est
git
Pull and Push
Image officielle : registry

6 . 13
RUN

6 . 14
RUN : LANCER UN CONTENEUR
docker run
-d (detach)
-i (interactive)
-t (pseudo tty)

6 . 15
RUN : BEAUCOUP DOPTIONS...
-v /directory/host:/directory/container
-p portHost:portContainer
-P
-e VARIABLE=valeur
restart=always
name=mon-conteneur

6 . 16
RUN : ...DONT CERTAINES UN PEU
DANGEREUSES
privileged (Accs tous les devices)
pid=host (Accs aux PID de lhost)
net=host (Accs la stack IP de
lhost)

6 . 17
RUN : SE CONNECTER UN CONTENEUR
docker exec
docker attach

6 . 18
RUN : DTRUIRE UN CONTENEUR
docker kill (SIGKILL)
docker stop (SIGTERM puis
SIGKILL)
docker rm (dtruit compltement)

6 . 19
BUILD, SHIP AND RUN : CONCLUSIONS
cosystme de gestion d'images
Construction automatise d'images
Contrle au niveau conteneurs

6 . 20
COSYSTME DOCKER

7.1
 DOCKER INC.
Docker Inc != Docker Project
Docker Inc est le principal dveloppeur du Docker Engine,
Compose, Machine, Kitematic, Swarm etc.
Ces projets restent OpenSource et les contributions sont
possibles

7.2
 OCI
Cr sous la Linux Fondation
But : Crer des standards OpenSource concernant la manire
de "runner" et le format des conteneurs
Non li des produits commerciaux
Non li des orchestrateurs ou des clients particuliers
runC a t donn par Docker l'OCI comme base pour leurs
travaux

7.3
LES AUTRES PRODUITS DOCKER

7.4
DOCKER-COMPOSE
Concept de stack
Infrastructure as a
code
Scalabilit

7.5
 DOCKER-COMPOSE
docker-compose.yml
nginx:
image: vsense/nginx
ports:
- "80:80"
- "443:443"
volumes:
- "/srv/nginx/etc/sites-enabled:/etc/nginx/sites-enabled"
- "/srv/nginx/etc/certs:/etc/nginx/certs"
- "/srv/nginx/etc/log:/var/log/nginx"
- "/srv/nginx/data:/var/www"

7.6
 DOCKER-MACHINE
"Metal" as a Service
Provisionne des htes Docker
Abstraction du Cloud Provider

7.7
 DOCKER SWARM
Clustering : Mutualisation d'htes Docker
Orchestration : placement intelligent des conteneurs au sein
du cluster

7.8
 AUTOUR DE DOCKER
Plugins : tendre les fonctionnalits notamment rseau et
volumes

Systmes de gestion de conteneurs

(COE)
Docker as a Service :
Docker Cloud
Tutum
7.9
 COSYSTME DOCKER : CONCLUSION
Le projet Docker est Open Source et n'appartient plus a
Docker
Des outils permettent d'tendre les fonctionnalits de Docker
Docker Inc. construit des offres commerciales autour de
Docker

7 . 10
DOCKER HOSTS

8.1
LES DISTRIBUTIONS TRADITIONNELLES
Debian, CentOS, Ubuntu
Supportent tous Docker
Paquets DEB et RPM
disponibles

8.2
 UN PEU "TOO MUCH" NON ?
Paquets inutiles ou out of date
Services par dfaut/inutiles alourdissent les
distributions
Cycle de release fig

8.3
 OS ORIENTS CONTENEURS
Faire tourner un conteneur engine
Optimis pour les conteneurs : pas de services superflus
Fonctionnalits avances lies aux conteneurs (clustering,
network, etc.)
Scurit accrue de part le minimalisme

8.4
OS ORIENTS CONTENEURS : EXEMPLES
CoreOS (CoreOS)
Atomic (Red Hat)
RancherOS (Rancher)
Photon (VMware)
Ubuntu Snappy Core
(Ubuntu)

8.5
 COREOS : PHILOSOPHIE
Trois "channels" : stable, beta, alpha
Dual root : facilit de mise jour
Systme de fichier en read only
Pas de gestionnaire de paquets : tout est
conteneuris
Forte intgration de systemd

8.6
COREOS : FONCTIONNALITS ORIENTES
CONTENEURS
Inclus :
Docker
Rkt
Etcd (base de donnes cl/valeur)
Fleet (systme d'init distribu)
Flannel (overlay network)
Kubernetes Kubelet
Permet nativement d'avoir un cluster
complet
Stable et prouv en production
Idal pour faire tourner Kubernetes (Tectonic)

8.7
 COREOS : ETCD
Systme de stockage simple : cl =
valeur
Hautement disponible (quorum)
Accessible via API

8.8
 COREOS : FLEET
Systme d'init distribu bas sur systemd
Orchestration de conteneurs entre diffrents htes
supportant systemd
S'appuie sur un systme cl/valeur comme etcd

8.9
 COREOS : FLANNEL
Communication multi-hosts
UDP ou VXLAN
S'appuie sur un systme cl/valeur comme
etcd

8 . 10
 RANCHEROS : PHILOSOPHIE
Docker et juste Docker : Docker est le process de PID 1)
Docker in Docker : Daemon User qui tourne dans le Daemon
System
Pas de processus tiers, pas d'init, juste Docker
Encore en beta

8 . 11
 FEDORA ATOMIC : PHILOSOPHIE
quivalent CoreOS mais base sur Fedora
Utilise systemd
Update Atomic (incrmentielles pour
rollback)

8 . 12
 PROJECT PHOTON
Dvelopp par VMware mais Open Source
Optimis pour vSphere
Supporte Docker, Rkt et Pivotal Garden (Cloud Foundry)

8 . 13
 DOCKER HOSTS : CONCLUSION
Rpond un besoin diffrent des distributions classiques
Fourni des outils et une logique adapte aux environnements
full conteneurs
Scurit accrue (mise jour)

8 . 14
DOCKER EN PRODUCTION

9.1
O DPLOYER ?
Cloud public:
GCE
AWS

Cloud priv:
OpenStack

Bare Metal
9.2
 COMMENT ?
Utilisation de COE (Container Orchestration
Engine)
Utilisation d'infrastructure as code
Utilisation d'un Discovery Service

9.3
 CONTAINER ORCHESTRATION ENGINE
Gestion du cycle de vie des conteneurs/applications
Abstraction des htes et des cloud providers (clustering)
Scheduling en fonction des besoins de l'application
Quelques exemples:
Etcd/Fleet (CoreOS)
Docker Swarm
Rancher
Mesos / Kubernetes (K8s)

9.4
 INFRASTRUCTURE AS A CODE
Version Control System
Intgration / Dploiement Continue
Outils de templating (Heat, Terraform,
Cloudformation)

9.5
 DISCOVERY SERVICE
La nature phmre des conteneurs empche toute
configuration manuelle
Connatre de faon automatique l'tat de ses conteneurs
tout instant
Fournir un endpoint fixe une application susceptible de
bouger au sein d'un cluster

9.6
 ETCD/FLEET
Etcd
Distributed key-Value store (KV store)
Rsilient de par sa construction, l'information est
rplique et une dfaillance du master n'impact pas les
donnes
Fleet
Clustering minimaliste d'htes supportant systemd
Positionnement intelligent des units en fonction des
besoins

9.7
 ETCD/FLEET
Exemple :
[Unit]
Description=Apache-sidekick
BindsTo=apache.service
After=apache.service

[Service]
ExecStart=/bin/sh -c "while true; do etcdctl set /services/website/apache '{\"host\": \"%H\", \"port\": 8
ExecStop=/usr/bin/etcdctl rm /services/website/apache

[X-Fleet]
MachineOf=apache.service

9.8
 CONSUL
Combinaison de plusieurs services : KV Store, DNS,
HTTP
Failure detection
Datacenter aware
Github

9.9
 CONSUL
Exemple :
$ curl -X PUT -d 'docker' http://localhost:8500/v1/kv/container/key1
true
$ curl http://localhost:8500/v1/kv/container/key1 | jq .
[
{
"CreateIndex": 5,
"ModifyIndex": 5,
"LockIndex": 0,
"Key": "container/key1",
"Flags": 0,
"Value": "ZG9ja2Vy"
}
]
$ echo ZG9ja2Vy | base64 -d
docker

9 . 10
 CONSUL
L'enregistrement des nouveaux conteneurs peut tre
automatis
Registrator est un process coutant le daemon Docker et
enregistrant les vnements

9 . 11
 RANCHER
Permet de provisionner et mutualiser des htes Docker sur
diffrents Cloud Provider
Fournit des fonctionnalit de COE :
Cattle : COE dvelopp par Rancher
Kubernetes : COE dvelopp par Google
Bon compromis entre simplicit et fonctionnalits compar
Mesos ou Kubernetes
Encore jeune, adapt aux environnement de taille moyenne
(problmes de passage l'chelle)

9 . 12
 APACHE MESOS / MARATHON
Mesos : Gestion et orchestration de systmes distribus
A la base orient Big Data (Hadoop, Elasticsearch...) et
tendu aux conteneurs via Marathon
Marathon : Scheduler pour Apache Mesos orient conteneur
Multi Cloud/Datacenter
Adapt aux gros environnements, prouv jusque 10000
nodes

9 . 13
 KUBERNETES (K8S)
COE dvelopp par Google, devenu open source en
2014
Utilis par Google pour la gestion de leurs conteneurs
Adapt tout type d'environnements
Devenu populaire en trs peu de temps

9 . 14
 QUELQUES AUTRES
Hashicorp Nomad
Amazon Container Engine
Docker Cloud
Docker UCP (Universal Control
Plane)

9 . 15
DOCKER EN PRODUCTION : CONCLUSION

9 . 16
MONITORER UNE INFRASTRUCTURE DOCKER

10 . 1
QUOI MONITORER ?
L'infrastructure
Les conteneurs

10 . 2
 MONITORER SON INFRASTRUCTURE
Problmatique classique
Monitorer des serveur est une problmatique rsolu depuis de
nombreuses annes par des outils devenus des standards :

Nagios
Shinken
Centreons
Icinga

10 . 3
 INTRT ?
Un des principes du cloud computing est d'abstraire les
couches basses
Docker accentue cette pratique
Est-ce intressant de monitorer son infra ?

10 . 4
Oui bien sr ;)

10 . 5
 MONITORER SES CONTENEURS
Monitorer les services fournis par les
conteneurs
Monitorer l'tat d'un cluster
Monitorer un conteneur spcifique

10 . 6
 PROBLMATIQUES DES CONTENEURS
Les conteneurs sont des botes noires
Les conteneurs sont dynamiques
La scalabilit induite par les conteneurs devient un
problme

10 . 7
 MONITORER LES SERVICES
La problmatique est diffrente pour chaque service
Concernant les web services (grande majorit), le temps de
rponse du service et la disponibilit du service sont de bons
indicatifs
Problme adress par certains services discovery pour
conserver une vision du systme cohrente (ex : Consul

10 . 8
 MONITORER L'TAT D'UN CLUSTER
Dpends grandement de la technologie employe
Le cluster se situe t-il au niveau de l'host Docker ou des
conteneurs eux mmes ?

10 . 9
MONITORER, OK MAIS DEPUIS O ?
Commandes excutes dans le container
Agents l'intrieur du conteneur
Agents l'extrieur du conteneur

10 . 10
LES OUTILS DE MONITORING
Docker stats
CAdvisor
Datadog
Sysdig
Prometheus

10 . 11
KUBERNETES : CONCEPTS ET OBJETS

11 . 1
 KUBERNETES (K8S)
COE dvelopp par Google, devenu open source en 2014
Utilis par Google pour la gestion de leurs conteneurs (bas
sur Borg)
Adapt tout type d'environnements
Devenu populaire en trs peu de temps

11 . 2
KUBERNETES : CONCEPTS
PODs
Networking
Volumes
Namespaces
Replication Controllers
Services
Providers : Load Balancer
Deployments / ReplicaSet
Ingress et Ingress
controller
NetworkPolicy
11 . 3
 KUBERNETES : POD
Ensemble logique compos de un ou plusieurs conteneurs
Les conteneurs d'un pod fonctionnent ensemble
(instanciation et destruction) et sont orchestrs sur un mme
hte
Les conteneurs partagent certaines spcifications du POD :
La stack IP (network namespace)
Inter-process communication (PID namespace)
Volumes
C'est la plus petite unit orchestrable dans Kubernetes
11 . 4
 KUBERNETES : POD
Les PODs sont dfinis en YAML comme les fichiers
docker-compose :
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

11 . 5
 KUBERNETES : NETWORKING
Overlay Network ncessaire (idem que ceux utilisables avec
Docker) :
Cannal : Flannel + Calico
Weaves
OpenShift
OpenContrail
Romana
Les conteneurs peuvent communiquer sans NAT
Un nuds peut accder aux conteneurs des autres nuds
sans NAT
11 . 6
 KUBERNETES : VOLUMES
Fournir du stockage persistent aux PODs
Fonctionnent de la mme faon que les volumes Docker pour
les volumes hte :
EmptyDir ~= volumes docker
HostPath ~= volumes hte
Support de multiples backend de stockage :
GCE : PD
AWS : EBS
glusterFS / NFS
Ceph
iSCSI
11 . 7
 KUBERNETES : VOLUMES
On dclare d'abord le volume et on l'affecte un service
:
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-persistent-storage
mountPath: /data/redis
volumes:
- name: redis-persistent-storage
emptyDir: {}

11 . 8
 KUBERNETES : NAMESPACES
Fournissent une sparation logique des ressources par
exemple :
Par utilisateurs
Par projet / applications
Autres...
Les objets existent uniquement au sein d'un namespaces
donn
vitent la collision de nom d'objets

11 . 9
 KUBERNETES : LABELS
Systme de cl/valeur
Organiser les diffrents objets de Kubernetes (PODs, RC,
Services, etc.) d'une manire cohrente qui reflte la
structure de l'application
Corrler des lments de Kubernetes : par exemple un
service vers des PODs

11 . 10
 KUBERNETES : LABELS
Exemple de label :
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

11 . 11
 KUBERNETES : REPLICATION CONTROLLERS
Permet de manager les PODs de manire homogne (version
de PODs, nombres, etc.)
Gre la dure de vie des PODs : cration et destruction
Assure qu'un nombre minimum de PODs est prsent
l'instant T sur l'infrastructure K8s (scaling)

11 . 12
KUBERNETES : REPLICATION CONTROLLERS
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-controller
spec:
replicas: 2
selector:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

11 . 13
 KUBERNETES : SERVICES
Abstraction des PODs et RCs, sous forme d'une VIP de
service
Rendre un ensemble de PODs accessibles depuis l'extrieur
Load Balancing entre les PODs d'un mme service

11 . 14
 KUBERNETES : SERVICES
Load Balancing : intgration avec des cloud provider :
AWS ELB
GCE
Node Port forwarding : limitations
ClusterIP : IP dans le rseau priv Kubernetes (VIP)
IP Externes : le routage de l'IP publique vers le cluster est
manuel

11 . 15
 KUBERNETES : SERVICES
Exemple de service (on remarque la selection sur le
label):
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "example-service"
},
"spec": {
"ports": [{
"port": 8765,
"targetPort": 9376
}],
"selector": {
"app": "example"
},
"type": "LoadBalancer"
}
}

11 . 16
KUBERNETES : DEPLOYMENTS ET REPLICASETS
Evolution des ReplicationController
Permet de dfinir un ensemble de PODs ainsi qu'un
ReplicaSet
Version, Update et Rollback
Souvent combin avec un objet de type service

11 . 17
KUBERNETES : DEPLOYMENTS ET REPLICASETS
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 3
template:
metadata:
labels:
11 . 18
 KUBERNETES : INGRESS RESOURCE
Dfinition de rgles de routage applicative (HTTP/HTTPS)
Traffic load balancing, SSL termination, name based virtual
hosting
Dfinies dans l'API et ensuite implmentes par un Ingress
Controller

internet | internet
| | |
------------ | [ Ingress ]
[ Services ] | --|-----|--
| [ Services ]

11 . 19
 KUBERNETES : INGRESS RESOURCE
Exemple :
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: default
name: traefik
annotations:
kubernetes.io/ingress.class: "traefik"
spec:
rules:
- host: traefik.archifleks.net
http:
paths:
- backend:
serviceName: traefik-console
servicePort: 8080

11 . 20
KUBERNETES : INGRESS CONTROLLER
Routeur applicatif de bordure (L7 Load
Balancer)
Implmente les Ingress Resources
Plusieurs implmentations :
Trfk
nginx

11 . 21
 KUBERNETES : NETWORKPOLICY
Contrle la communication entre les PODs au sein d'un
namespace
Pare-feu entre les lments composant une application :

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
ingress:
- from:
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports: 11 . 22
 KUBERNETES : RUN ET ADMINISTRATION
WebUI (Kubernetes Dashboard)
Kubectl (Outil CLI)
Objets: Secret et ConfigMap : paramtrages, plus scuriss
que les variables d'environnements

11 . 23
 KUBERNETES : AUJOURD'HUI
Version 1.4 : stable en production
Solution complte et une des plus utilises
prouve par Google
S'intgre parfaitement CoreOS (support de rkt et Tectonic,
la solution commerciale) et Atomic

11 . 24
KUBERNETES : ARCHITECTURE

12 . 1
 KUBERNETES : COMPOSANTS
Kubernetes est crit en Go, compil statiquement.
Un ensemble de binaires sans dpendances
Faciles conteneuriser et packager
Peut se dployer uniquement avec des conteneurs sans
dpendances d'OS

12 . 2
KUBERNETES : COMPOSANTS

12 . 3
kubelet : Service "agent" fonctionnant sur tous les nuds et
assure le fonctionnement des autres services
kube-apiserver : API server qui permet la configuration
d'objet Kubernetes (Pods, Service, Replication Controller,
etc.)
kube-proxy : Permet le forwarding TCP/UDP et le load
balancing entre les services et les backend (Pods)
kube-scheduler : Implmente les fonctionnalit de
scheduling
kube-controller-manager : Responsable de l'tat du cluster,
boucle infinie qui rgule l'tat du cluster afin d'atteindre un
tat dsir
(network-policy-controller) : Composant qui implmente
l'objet NetworkPolicy
kubectl : Client qui permet de piloter un cluster Kubernetes
 KUBERNETES : KUBELET
Service principal de Kubernetes
Permet Kubernetes de s'auto configurer :
Surveille un dossier contenant les manifests (fichiers YAML
des diffrents composant de K8s).
Applique les modifications si besoin (upgrade, rollback).
Surveille l'tat des services du cluster via l'API server (kube-
apiserver).
Dossier de manifest sur un noeud master :

ls /etc/kubernetes/manifests/
kube-apiserver.yaml kube-controller-manager.yaml kube-proxy.yaml kube-scheduler.yaml policy-c

12 . 4
 KUBERNETES : KUBELET
Exemple du manifest kube-proxy
:
apiVersion: v1
kind: Pod
metadata:
name: kube-proxy
namespace: kube-system
annotations:
rkt.alpha.kubernetes.io/stage1-name-override: coreos.com/rkt/stage1-fly
spec:
hostNetwork: true
containers:
- name: kube-proxy
image: quay.io/coreos/hyperkube:v1.3.6_coreos.0
command:
- /hyperkube
- proxy
- --master=http://127.0.0.1:8080
- --proxy-mode=iptables
securityContext:
privileged: true
volumeMounts: 12 . 5
 KUBERNTES : KUBE-APISERVER
Les configuration d'objets (Pods, Service, RC, etc.) se font via
l'API server
Un point d'accs l'tat du cluster aux autres composant via
une API REST
Tous les composant sont relis l'API server

12 . 6
 KUBERNETES : KUBE-SCHEDULER
Planifie les ressources sur le cluster
En fonction de rgles implicites (CPU, RAM, stockage
disponible, etc.)
En fonction de rgles explicites (rgles d'affinit et anti-
affinit, labels, etc.)

12 . 7
 KUBERNETES : KUBE-PROXY
Responsable de la publication de services
Utilise iptables
Route les paquets a destination des PODs et ralise le load
balancing TCP/UDP

12 . 8
KUBERNETES : KUBE-CONTROLLER-MANAGER
Boucle infinie qui contrle l'tat d'un cluster
Effectue des oprations pour atteindre un tat donn
De base dans Kubernetes : replication controller, endpoints
controller, namespace controller et serviceaccounts
controller

12 . 9
KUBERNETES : NETWORK-POLICY-CONTROLLER
Implmente l'objet NetworkPolicy
Contrle la communication entre les PODs
Externe Kubernetes et implment par la solution de
Networking choisie :
OpenShift
OpenContrail
Romana
Calico

12 . 10
KUBERNETES : CONCLUSION

12 . 11
OPENSHIFT : INTRODUCTION

13 . 1
 OPENSHIFT
Solution de PaaS dveloppe par Red Hat
Deux version :
Open Source : OpenShift Origin
Entreprise : OpenShift Container Platform
Se base sur Kubernetes en tant qu'orchestrateur de
conteneurs

13 . 2
OPENSHIFT VS KUBERNETES : DIFFRENCES ET
AJOUTS
Pas d'Ingress : Router
Build et Images Stream : Cration d'images et pipeline de
CI/CD
Templates : Permet de definir et templatiser facilement un
ensemble d'Objet OpenShift
OpenShift SDN ou Nuage Network pour le rseau

13 . 3
 OPENSHIFT : ROUTER
Quasiment identique Ingress mais implments avant
Kubernetes
Fournissent les mme fonctionnalits
Deux implementations :
HAProxy
F5 Big IP

13 . 4
 OPENSHIFT : BUILD
Permet de construire et reproduire des images d'application
Docker builds : via Dockerfile
Source-to-Image (S2I) builds : systme de build propre
OpenShift qui produit une image Docker d'une application
depuis les source
Pipeline builds : via Jenkins

13 . 5
 OPENSHIFT : IMAGE STREAM
Similaires un dpt DockerHub
Rassemble des images similaires identifies par des
tags
Permet de garder un historique des diffrentes versions

13 . 6
OPENSHIFT : CONCLUSION

13 . 7
CONCLUSION

14 . 1