DOCKER

1

CONCERNANT CES SUPPORTS DE COURS

2 . 1

SUPPORTS DE COURS RÉALISÉS PAR OSONES

Logo OsonesCopyright © 2014 - 2018 OsonesLicence : Sources : HTML/PDF :

Licence Creative Commons BY-SA 4.0

https://osones.com

Creative Commons BY-SA 4.0https://github.com/Osones/formations/

https://osones.com/formations/

2 . 2

AUTEURS (DOCKER/K8S)Romain Guichard Kevin Lefevre

romain.guichard@osones.iokevin.lefevre@osones.io

2 . 3

LE CLOUD : VUE D’ENSEMBLE

3 . 1

LE CLOUD, C’EST LARGE !

Stockage/calcul distant (on oublie, cf. externalisation)

Virtualisation++

Abstraction du matériel (voire plus)

Accès normalisé par des APIs

Service et facturation à la demande

Flexibilité, élasticité

3 . 2

WAAS : WHATEVER AS A SERVICE

IaaS : Infrastructure as aService

PaaS : Platform as a Service

SaaS : Software as a Service

3 . 3

LE CLOUD EN UN SCHÉMA

3 . 4

POURQUOI DU CLOUD ? CÔTÉ TECHNIQUE

Abstraction des couches basses

On peut tout programmer à son gré (API)

Permet la mise en place d’architecturesscalables

3 . 5

VIRTUALISATION DANS LE CLOUD

Le cloud IaaS repose souvent sur la virtualisation

Ressources compute : virtualisation

Virtualisation complète : KVM, Xen

Virtualisation conteneurs : OpenVZ, LXC, Docker,RKT

3 . 6

NOTIONS ET VOCABULAIRE IAAS

L’instance est par définition éphémère

Elle doit être utilisée comme ressource decalcul

Séparer les données des instances

3 . 7

ORCHESTRATION DES RESSOURCES ?

Groupement fonctionnel de ressources : micro services

Infrastructure as Code : Définir toute une infrastructure dansun seul fichier texte de manière déclarative

Scalabilité : passer à l'échelle son infrastructure en fonctionde différentes métriques.

3 . 8

POSITIONNEMENT DES CONTENEURS DANS L'ÉCOSYSTÈME CLOUD?

Facilitent la mise en place de PaaS

Fonctionnent sur du IaaS ou sur du bare-metal

Simplifient la décomposition d'applications en microservices

3 . 9

LES CONTENEURS

4 . 1

DÉFINITIONLes conteneurs fournissent un environnement isolé sur unsystème hôte, semblable à un chroot sous Linux ou une jailsous BSD, mais en proposant plus de fonctionnalités enmatière d'isolation et de configuration. Ces fonctionnalitéssont dépendantes du système hôte 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 créer un arbre des points de montageindépendants de celui du système hôte.

4 . 5

UTS NAMESPACES (LINUX 2.6.19)Unix Time Sharing : Permet à un conteneur de disposer deson propre nom de domaine et d’identité NIS sur laquellecertains protocoles tel que LDAP peuvent se baser.

4 . 6

IPC NAMESPACES (LINUX 2.6.19)Inter Process Communication : Permet d’isoler les bus decommunication entre les processus d’un conteneur.

4 . 7

PID NAMESPACES (LINUX 2.6.24)Isole l’arbre d’exécution des processus et permet donc àchaque conteneur de disposer de son propre processusmaître (PID 0) qui pourra ensuite exécuter et managerd'autres processus avec des droits illimités tout en étant unprocessus restreint au sein du système hôte.

4 . 8

USER NAMESPACES (LINUX 2.6.23-3.8)Permet l’isolation des utilisateurs et des groupes au sein d’unconteneur. Cela permet notamment de gérer des utilisateurstels que l’UID 0 et GID 0, le root qui aurait des permissionsabsolues au sein d’un namespace mais pas au sein dusystème hôte.

4 . 9

NETWORK NAMESPACES (LINUX 2.6.29)Permet l’isolation des ressources associées au réseau,chaque namespace dispose de ses propres cartes réseaux,plan IP, table de routage, etc.

4 . 10

CGROUPS : CONTROL CROUPSCGroup: / |--docker | |--7a977a50f48f2970b6ede780d687e72c0416d9ab6e0b02030698c1633fdde956 | |--6807 nginx: master process ngin | | |--6847 nginx: worker proces

4 . 11

CGROUPS : LIMITATION DE RESSOURCESLimitation des ressources : des groupes peuvent être mis enplace afin de ne pas dépasser une limite de mémoire.

4 . 12

CGROUPS : PRIORISATIONPriorisation : certains groupes peuvent obtenir une plusgrande part de ressources processeur ou de bande passanted'entrée-sortie.

4 . 13

CGROUPS : COMPTABILITÉComptabilité : permet de mesurer la quantité de ressourcesconsommées par certains systèmes, en vue de leurfacturation par exemple.

4 . 14

CGROUPS : ISOLATIONIsolation : séparation par espace de nommage pour lesgroupes, afin qu'ils ne puissent pas voir les processus desautres, leurs connexions réseaux ou leurs fichiers.

4 . 15

CGROUPS : CONTRÔLEContrôle : figer les groupes ou créer un point de sauvegardeet redémarrer.

4 . 16

DEUX PHILOSOPHIES DE CONTENEURSSysteme : simule une séquence de boot complète avec un initprocess ainsi que plusieurs processus (LXC, OpenVZ).Process : un conteneur exécute un ou plusieurs processusdirectement, en fonction de l'application conteneurisée(Docker, Rkt).

4 . 17

ENCORE PLUS “CLOUD” QU’UNE INSTANCE

Partage du kernel

Un seul processus par conteneur

Le conteneur est encore plus éphémère quel’instance

Le turnover des conteneurs est élevé : orchestration

4 . 18

CONTAINER RUNTIME

Docker

Rkt

LXC

4 . 19

LXC

Conteneur système

Utilise la liblxc

Virtualisation d'un système complet (boot)

4 . 20

DOCKER

Développé par dotCloud et open sourcé en mars 2013

Fonctionne en mode daemon : difficulté d'intégration avecles init-process

Utilisait la liblxc

Utilise désormais la libcontainer

4 . 21

ROCKET (RKT)

Se prononce “rock-it”

Développé par CoreOS

Pas de daemon : intégration avec systemd

Utilise systemd-nspawn et propose maintenant d'autressolutions (eg. KVM)

Adresse certains problèmes de sécurité inhérents à Docker

4 . 22

LES CONTENEURS: CONCLUSION

Fonctionnalités offertes par le Kernel

Les conteneurs engine fournissent des interfacesd'abstraction

Plusieurs types de conteneurs pour différents besoins

4 . 23

LES CONCEPTS

5 . 1

UN ENSEMBLE DE CONCEPTS ET DE COMPOSANTS

Layers

Stockage

Volumes

Réseau

Publication de ports

Service Discovery

5 . 2

LAYERS

Les conteneurs et leurs images sont décomposés en couches(layers)

Les layers peuvent être réutilisés entre différents conteneurs

Gestion optimisée 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/w5 . 5

LAYERS : PLUSIEURS CONTENEURS

Une image, plusieurs conteneurs5 . 6

LAYERS : RÉPÉTITION DES LAYERS

Les layers sont indépendants de l'image

5 . 7

STOCKAGE

Images Docker, données des conteneurs, volumes

Multiples backends (extensibles via plugins):AUFSDeviceMapperOverlayFSNFS (via plugin Convoy)GlusterFS (via plugin Convoy)

5 . 8

STOCKAGE : AUFS

A unification filesystem

Stable : performance écriture moyenne

Non intégré dans le Kernel Linux (mainline)

5 . 9

STOCKAGE : DEVICE MAPPER

Basé sur LVM

Thin Provisionning et snapshot

Intégré 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 DeviceMapper

5 . 11

STOCKAGE : PLUGINS

Étendre les drivers de stockages disponibles

Utiliser des systèmes de fichier distribués(GlusterFS)

Partager des volumes entre plusieurs hôtes docker

5 . 12

VOLUMES

Assurent une persistance des données

Indépendance du volume par rapport au conteneur et auxlayers

Deux types de volumes :Conteneur : Les données sont stockées dans ce que l'onappelle un data conteneurHôte : Montage d'un dossier de l'hôte docker dans leconteneur

Partage de volumes entre plusieurs conteneurs

5 . 13

VOLUMES : EXEMPLE

Un volume monté sur deux conteneurs5 . 14

VOLUMES : PLUGINS

Permettre le partage de volumes entre differents hôtes

Fonctionnalité avancées : snapshot, migration, restauration

Quelques exemples:Convoy : multi-host et multi-backend (NFS, GlusterFS)Flocker : migration de volumes dans un cluster

5 . 15

RÉSEAU : A LA BASE, PAS GRAND CHOSE...NETWORK ID NAME DRIVER42f7f9558b7a bridge bridge6ebf7b150515 none null0509391a1fbd host host

5 . 16

RÉSEAU : BRIDGE

5 . 17

RÉSEAU : HOST

5 . 18

RÉSEAU : NONEExplicite

5 . 19

RÉSEAU : LES ÉVOLUTIONS

Refactorisation des composants réseau (libnetwork)

Système de plugins : multi host et multi backend (overlaynetwork)

Quelques exemples d'overlay :Flannel : UDP et VXLANWeaves : UDP

5 . 20

RÉSEAU : MULTIHOST OVERLAY

5 . 21

PUBLICATION DE PORTS

Dans le cas d'un réseau diffèrent de l'hôte

Les conteneurs ne sont pas accessible depuis l'extérieur

Possibilité de publier des ports depuis l'hôte vers leconteneur (iptables)

L'hôte sert de proxy au service

5 . 22

PUBLICATION DE PORTS

5 . 23

LINKS

Les conteneurs d'un même réseau peuvent communiquer viaIP

Les liens permettent de lier deux conteneurs par nom

Système de DNS rudimentaire (/etc/hosts)

Remplacés par les discovery services

5 . 24

LES CONCEPTS: CONCLUSION

Les composants de Docker sont modulaires

Nombreuses possibilités offertes par défaut.

Possibilité d'étendre les fonctionnalités via desplugins

5 . 25

BUILD, SHIP AND RUN !

6 . 1

BUILD

6 . 2

LE CONTENEUR ET SON IMAGE

Flexibilité et élasticité

Format standard de facto

Instanciation illimitée

6 . 3

CONSTRUCTION D'UNE IMAGE

Possibilité de construire son image à la main (long et sourced'erreurs)

Suivi de version et construction d'images de manièreautomatisée

Utilisation de Dockerfile afin de garantir l'idempotence desimages

6 . 4

DOCKERFILE

Suite d'instruction qui définit une image

Permet de vérifier le contenu d'une image

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

6 . 5

DOCKERFILE : PRINCIPALES INSTRUCTIONS

FROM : baseimage utilisée

RUN : Commandes effectuées lors du build de l'image

EXPOSE : Ports exposées lors du run (si -P est précisé)

ENV : Variables d'environnement du conteneur àl'instanciation

CMD : Commande unique lancée par le conteneur

ENTRYPOINT : "Préfixe" de la commande unique lancée parle conteneur

6 . 6

DOCKERFILE : BEST PRACTICES

Bien choisir sa baseimage

Chaque commande Dockerfile génère un nouveaulayer

Comptez vos layers !

6 . 7

DOCKERFILE : BAD LAYERINGRUN 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 LAYERINGRUN 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 automatisée d'images Docker

Intégration GitHub / DockerHub

Plateforme de stockage et de distribution d'images Docker

6 . 10

SHIP

6 . 11

SHIP : LES CONTENEURS SONT MANIPULABLESSauvegarder un conteneur :

Exporter un conteneur :

Importer un conteneur :

docker commit mon-conteneur backup/mon-conteneur

docker run -it backup/mon-conteneur

docker save -o mon-image.tar backup/mon-conteneur

docker import mon-image.tar backup/mon-conteneur

6 . 12

SHIP : DOCKER REGISTRY

DockerHub n’est qu’au 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 D’OPTIONS...

-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 (Accès à tous les devices)

–pid=host (Accès aux PID de l’host)

–net=host (Accès à la stack IP del’host)

6 . 17

RUN : SE “CONNECTER” À UN CONTENEUR

docker exec

docker attach

6 . 18

RUN : DÉTRUIRE UN CONTENEUR

docker kill (SIGKILL)

docker stop (SIGTERM puisSIGKILL)

docker rm (détruit complètement)

6 . 19

BUILD, SHIP AND RUN : CONCLUSIONS

Écosystème de gestion d'images

Construction automatisée d'images

Contrôle au niveau conteneurs

6 . 20

ÉCOSYSTÈME DOCKER

7 . 1

DOCKER INC.

Docker Inc != Docker Project

Docker Inc est le principal développeur du Docker Engine,Compose, Machine, Kitematic, Swarm etc.

Ces projets restent OpenSource et les contributions sontpossibles

7 . 2

OCI

Créé sous la Linux Fondation

But : Créer des standards OpenSource concernant la manièrede "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 leurstravaux

7 . 3

LES AUTRES PRODUITS DOCKER

7 . 4

DOCKER-COMPOSE

Concept de stack

Infrastructure as a code

Scalabilité

7 . 5

DOCKER-COMPOSEdocker-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 hôtes Docker

Abstraction du Cloud Provider

7 . 7

DOCKER SWARM

Clustering : Mutualisation d'hôtes Docker

Orchestration : placement intelligent des conteneurs au seindu cluster

7 . 8

AUTOUR DE DOCKERPlugins : étendre les fonctionnalités notamment réseau etvolumes

Systèmes de gestion de conteneurs (COE)

Docker as a Service :Docker CloudTutum

7 . 9

ÉCOSYSTÈME DOCKER : CONCLUSION

Le projet Docker est Open Source et n'appartient plus aDocker

Des outils permettent d'étendre les fonctionnalités de Docker

Docker Inc. construit des offres commerciales autour deDocker

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 défaut/inutiles alourdissent les distributions

Cycle de release figé

8 . 3

OS ORIENTÉS CONTENEURS

Faire tourner un conteneur engine

Optimisé pour les conteneurs : pas de services superflus

Fonctionnalités avancées liées aux conteneurs (clustering,network, etc.)

Sécurité accrue de part le minimalisme

8 . 4

OS ORIENTÉS 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

Système de fichier en read only

Pas de gestionnaire de paquets : tout estconteneurisé

Forte intégration de systemd

8 . 6

COREOS : FONCTIONNALITÉS ORIENTÉES CONTENEURSInclus :

DockerRktEtcd (base de données clé/valeur)Flannel (overlay network)Kubernetes Kubelet

Permet nativement d'avoir un cluster complet

Stable et éprouvé en production

Idéal pour faire tourner Kubernetes (Tectonic)

8 . 7

COREOS : ETCD

Système de stockage simple : clé =valeur

Hautement disponible (quorum)

Accessible via API

8 . 8

COREOS : FLANNEL

Communication multi-hosts

UDP ou VXLAN

S'appuie sur un système clé/valeur commeetcd

8 . 9

RANCHEROS : PHILOSOPHIE

Docker et juste Docker : Docker est le process de PID 1)

Docker in Docker : Daemon User qui tourne dans le DaemonSystem

Pas de processus tiers, pas d'init, juste Docker

Encore en beta

8 . 10

FEDORA ATOMIC : PHILOSOPHIE

Équivalent à CoreOS mais basée sur Fedora

Utilise systemd

Update Atomic (incrémentielles pourrollback)

8 . 11

PROJECT PHOTON

Développé par VMware mais Open Source

Optimisé pour vSphere

Supporte Docker, Rkt et Pivotal Garden (CloudFoundry)

8 . 12

DOCKER HOSTS : CONCLUSION

Répond à un besoin différent des distributions classiques

Fourni des outils et une logique adaptée aux environnementsfull conteneurs

Sécurité accrue (mise à jour)

8 . 13

DOCKER EN PRODUCTION

9 . 1

OÙ DÉPLOYER ?Cloud public:

GCEAWS

Cloud privé: OpenStack

BareMetal

9 . 2

COMMENT ?

Utilisation de COE (Container OrchestrationEngine)

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 hôtes et des cloud providers (clustering)

Scheduling en fonction des besoins de l'application

Quelques exemples:Docker SwarmRancherMesosKubernetes

9 . 4

INFRASTRUCTURE AS A CODE

Version Control System

Intégration / Déploiement Continue

Outils de templating (Heat, Terraform,Cloudformation)

9 . 5

DISCOVERY SERVICE

La nature éphémère des conteneurs empêche touteconfiguration manuelle

Connaître de façon automatique l'état de ses conteneurs àtout instant

Fournir un endpoint fixe à une application susceptible debouger au sein d'un cluster

9 . 6

CONSUL

Combinaison de plusieurs services : KV Store, DNS,HTTP

Failure detection

Datacenter aware

Github

9 . 7

CONSULExemple :

$ curl -X PUT -d 'docker' http://localhost:8500/v1/kv/container/key1true$ 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 -ddocker

9 . 8

CONSUL

L'enregistrement des nouveaux conteneurs peut êtreautomatisé

Registrator est un process écoutant le daemon Docker etenregistrant les évènements

9 . 9

RANCHER

Permet de provisionner et mutualiser des hôtes Docker surdifférents Cloud Provider

Fournit des fonctionnalité de COE :Cattle : COE développé par RancherKubernetes : COE développé par Google

Bon compromis entre simplicité et fonctionnalités comparé àMesos ou Kubernetes

Encore jeune, adapté aux environnement de taille moyenne(problèmes de passage à l'échelle)

9 . 10

APACHE MESOS / MARATHON

Mesos : Gestion et orchestration de systèmes distribués

A la base orienté Big Data (Hadoop, Elasticsearch...) et étenduaux conteneurs via Marathon

Marathon : Scheduler pour Apache Mesos orienté conteneur

Multi Cloud/Datacenter

Adapté aux gros environnements, éprouvé jusque 10000nodes

9 . 11

KUBERNETES

COE développé par Google, devenu open source en2014

Utilisé par Google pour la gestion de leurs conteneurs

Adapté à tout type d'environnements

Devenu populaire en très peu de temps

9 . 12

QUELQUES AUTRES

Hashicorp Nomad

Amazon ECS

Docker Cloud

Docker UCP (Universal Control Plane)

9 . 13

DOCKER EN PRODUCTION : CONCLUSION

9 . 14

MONITORER UNE INFRASTRUCTURE DOCKER

10 . 1

QUOI MONITORER ?

L'infrastructure

Les conteneurs

10 . 2

MONITORER SON INFRASTRUCTUREProblématique classique

Monitorer des serveur est une problématique résolu depuis denombreuses années par des outils devenus des standards :

Nagios

Shinken

Centreons

Icinga

10 . 3

INTÉRÊT ?

Un des principes du cloud computing est d'abstraire lescouches basses

Docker accentue cette pratique

Est-ce intéressant de monitorer son infra ?

10 . 4

Oui bien sûr ;)

10 . 5

MONITORER SES CONTENEURS

Monitorer les services fournis par lesconteneurs

Monitorer l'état d'un cluster

Monitorer un conteneur spécifique

10 . 6

PROBLÉMATIQUES DES CONTENEURS

Les conteneurs sont des boîtes noires

Les conteneurs sont dynamiques

La scalabilité induite par les conteneurs devient un problème

10 . 7

MONITORER LES SERVICES

La problématique est différente pour chaque service

Concernant les web services (grande majorité), le temps deréponse du service et la disponibilité du service sont de bonsindicatifs

Problème adressé par certains services discovery pourconserver une vision du système cohérente (ex : Consul

10 . 8

MONITORER L'ÉTAT D'UN CLUSTER

Dépends grandement de la technologie employée

Le cluster se situe t-il au niveau de l'host Docker ou desconteneurs eux mêmes ?

10 . 9

MONITORER, OK MAIS DEPUIS OÙ ?

Commandes exécutées dans le container

Agents à l'intérieur du conteneur

Agents à l'extérieur du conteneur

10 . 10

LES OUTILS DE MONITORING

Docker stats

CAdvisor

Datadog

Sysdig

Prometheus

10 . 11

KUBERNETES : CONCEPTS ET OBJETS

11 . 1

KUBERNETES : API RESOURCESPodsDeploymentsDaemonSetsServicesNamespacesIngressNetworkPolicyVolumes

11 . 2

KUBERNETES : PODEnsemble logique composé de un ou plusieurs conteneursLes conteneurs d'un pod fonctionnent ensemble(instanciation et destruction) et sont orchestrés sur un mêmehôteLes conteneurs partagent certaines spécifications du Pod :

La stack IP (network namespace)Inter-process communication (PID namespace)Volumes

C'est la plus petite et la plus simple unité dans Kubernetes

11 . 3

KUBERNETES : PODLes Pods sont définis en YAML comme les fichiersdocker-compose :

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - name: nginx image: nginx ports: - containerPort: 80

11 . 4

KUBERNETES : DEPLOYMENTPermet d'assurer le fonctionnement d'un ensemble dePodsVersion, Update et RollbackSouvent combiné avec un objet de type service

11 . 5

KUBERNETES : DEPLOYMENTapiVersion: apps/v1kind: Deploymentmetadata: name: my-nginxspec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:stable ports: - containerPort: 80

11 . 6

KUBERNETES : SERVICESAbstraction des Pods et Replication Controllers, sous formed'une VIP de serviceRendre un ensemble de Pods accessibles depuis l'extérieurLoad Balancing entre les Pods d'un même service

11 . 7

KUBERNETES : SERVICESLoad Balancing : intégration avec des cloud provider :

AWS ELBGCPAzure Kubernetes ServiceOpenStack

NodePort : chaque noeud du cluster ouvre un port statiqueet redirige le trafic vers le port indiquéClusterIP : IP dans le réseau privé Kubernetes (VIP)LoadBalancer : expose le service à l'externe en utilisant leloadbalancer d'un cloud provider (AWS, Google, Azure)ExternalIP: le routage de l'IP publique vers le cluster estmanuel

11 . 8

KUBERNETES : SERVICES

11 . 9

KUBERNETES : SERVICESExemple de service (on remarque la sélection sur le label et lemode d'exposition):

apiVersion: v1kind: Servicemetadata: name: frontend labels: app: guestbook tier: frontendspec: type: NodePort ports: - port: 80 selector: app: guestbook tier: frontend

11 . 10

KUBERNETES : SERVICESIl est aussi possible de mapper un service avec un nom de

domaine en spécifiant le paramètre spec.externalName.

kind: ServiceapiVersion: v1metadata: name: my-service namespace: prodspec: type: ExternalName externalName: my.database.example.com

11 . 11

KUBERNETES: INGRESSL'objet Ingress permet d'exposer un service à l'extérieurd'un cluster KubernetesIl permet de fournir une URL visible permettant d'accéder unService KubernetesIl permet d'avoir des terminations TLS, de faire du LoadBalancing, etc...

11 . 12

KUBERNETES : INGRESSapiVersion: extensions/v1beta1kind: Ingressmetadata: name: osonesspec: rules: - host: blog.osones.com http: paths: - path: / backend: serviceName: osones-nodeport servicePort: 80

11 . 13

KUBERNETES : INGRESS CONTROLLERPour utiliser un Ingress, il faut un Ingress Controller. Il existe

plusieurs offres sur le marché :

Traefik : Istio : Linkerd : Contour : Nginx Controller :

https://github.com/containous/traefikhttps://github.com/istio/istio

https://github.com/linkerd/linkerdhttps://www.github.com/heptio/contour/

https://github.com/kubernetes/ingress-nginx

11 . 14

KUBERNETES : DAEMONSETAssure que tous les noeuds exécutent une copie du pod surtous les noeuds du clusterNe connaît pas la notion de replicas.Utilisé pour des besoins particuliers comme :

l'exécution d'agents de collection de logs comme fluentdou logstashl'exécution de pilotes pour du matériel commenvidia-pluginl'exécution d'agents de supervision comme NewRelicagent, Prometheus node exporter

NB : kubectl ne peut pas créer de DaemonSet

11 . 15

KUBERNETES : DAEMONSETapiVersion: apps/v1beta2kind: DaemonSetmetadata: name: ssd-monitor spec: selector: matchLabels: app: ssd-monitor template: metadata: labels: app: ssd-monitor spec: nodeSelector: disk: ssd containers: - name: main image: luksa/ssd-monitor

11 . 16

KUBERNETES : STATEFULSETSimilaire au DeploymentLes pods possèdent des identifiants uniques.Chaque replica de pod est créé par ordre d'indexNécessite un Persistent Volume et un Storage Class.Supprimer un StatefulSet ne supprime pas le PV associé

11 . 17

KUBERNETES : STATEFULSETapiVersion: apps/v1kind: StatefulSetmetadata: name: webspec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports:

11 . 18

KUBERNETES : LABELSSystème de clé/valeurOrganiser les différents objets de Kubernetes (Pods, RC,Services, etc.) d'une manière cohérente qui reflète lastructure de l'applicationCorréler des éléments de Kubernetes : par exemple un servicevers des Pods

11 . 19

KUBERNETES : LABELSExemple de label :

apiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - name: nginx image: nginx ports: - containerPort: 80

11 . 20

KUBERNETES : LABELSLa commande kubectl get pods, par défaut, ne liste pasles labels. Il est possible de les voir en utilisant--show-labels:

$ kubectl get pods --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 31s app=nginx,env=prod

11 . 21

KUBERNETES : NAMESPACESFournissent une séparation logique des ressources parexemple :

Par utilisateursPar projet / applicationsAutres...

Les objets existent uniquement au sein d'un namespacedonnéÉvitent la collision de nom d'objets

11 . 22

KUBERNETES : ARCHITECTURE

12 . 1

KUBERNETES : COMPOSANTSKubernetes est écrit en Go, compilé statiquement.Un ensemble de binaires sans dépendancesFaciles à conteneuriser et à packagerPeut se déployer uniquement avec des conteneurs sansdépendances d'OS

12 . 2

KUBERNETES : COMPOSANTSkube-apiserver : API server qui permet la configurationd'objet Kubernetes (Pods, Service, Replication Controller,etc.)kube-proxy : Permet le forwarding TCP/UDP et le loadbalancing entre les services et les backend (Pods)kube-scheduler : Implémente les fonctionnalités deschedulingkube-controller-manager : Responsable de l'état du cluster,boucle infinie qui régule l'état du cluster afin d'atteindre unétat désiré

12 . 3

KUBERNETES : COMPOSANTSkubelet : Service "agent" fonctionnant sur tous les nœuds etassure le fonctionnement des autres serviceskubectl : Client qui permet de piloter un cluster Kubernetes

12 . 4

KUBERNETES : KUBELETService principal de KubernetesPermet à Kubernetes de s'auto configurer :

Surveille un dossier contenant les manifests (fichiers YAMLdes différents composant de Kubernetes).Applique les modifications si besoin (upgrade, rollback).

Surveille l'état des services du cluster via l'API server (kube-apiserver).

12 . 5

KUBERNETES : KUBE-APISERVERLes configurations d'objets (Pods, Service, RC, etc.) se font vial'API serverUn point d'accès à l'état du cluster aux autres composantsvia une API RESTTous les composants sont reliés à l'API server

12 . 6

KUBERNETES : KUBE-SCHEDULERPlanifie les ressources sur le clusterEn fonction de règles implicites (CPU, RAM, stockagedisponible, etc.)En fonction de règles explicites (règles d'affinité et anti-affinité, labels, etc.)

12 . 7

KUBERNETES : KUBE-PROXYResponsable de la publication de servicesUtilise iptablesRoute les paquets à destination des PODs et réalise le loadbalancing TCP/UDP

12 . 8

KUBERNETES : KUBE-CONTROLLER-MANAGERBoucle infinie qui contrôle l'état d'un clusterEffectue des opérations pour atteindre un état donnéDe base dans Kubernetes : replication controller, endpointscontroller, namespace controller et serviceaccountscontroller

12 . 9

KUBERNETES : KUBELETroot@ubuntu-xenial:~# ls -lh /etc/kubernetes/manifests/total 16K-rw------- 1 root root 2.0K Sep 23 20:04 etcd.yaml-rw------- 1 root root 3.2K Sep 23 20:04 kube-apiserver.yaml-rw------- 1 root root 2.5K Sep 23 20:04 kube-controller-manager.yaml-rw------- 1 root root 1.1K Sep 23 20:04 kube-scheduler.yaml

12 . 10

KUBERNETES : NETWORK-POLICY-CONTROLLERImplémente l'objet NetworkPolicyContrôle la communication entre les PodsExterne à Kubernetes et implémenté par la solution deNetworking choisie :

Calico : Flannel : Romana : Weave : more :

https://projectcalico.org/https://coreos.com/flannel

https://romana.io/https://www.weave.works/oss/net/

https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model

12 . 11

KUBERNETES : AUJOURD'HUIVersion 1.11.x : stable en productionSolution complète et une des plus utiliséesÉprouvée par GoogleS'intègre parfaitement à d'autres Container RuntimeInterfaces (CRI) comme containerd, cri-o, rktlet, frakti, etc...

12 . 12

OPENSHIFT : INTRODUCTION

13 . 1

OPENSHIFT

Solution de PaaS développée par Red Hat

Deux version :Open Source : Entreprise :

Se base sur Kubernetes en tant qu'orchestrateur deconteneurs

OpenShift OriginOpenShift Container Platform

13 . 2

OPENSHIFT VS KUBERNETES : DIFFÉRENCES ET AJOUTS

Pas d'Ingress : Router

Build et Images Stream : Création d'images et pipeline deCI/CD

Templates : Permet de definir et templatiser facilement unensemble d'Objet OpenShift

OpenShift SDN ou Nuage Network pour le réseau

13 . 3

OPENSHIFT : ROUTER

Quasiment identique à Ingress mais implémentés avantKubernetes

Fournissent les même fonctionnalités

Deux implementations :HAProxyF5 Big IP

13 . 4

OPENSHIFT : BUILD

Permet de construire et reproduire des images d'application

Docker builds : via Dockerfile

Source-to-Image (S2I) builds : système de build propre àOpenShift qui produit une image Docker d'une applicationdepuis les source

Pipeline builds : via Jenkins

13 . 5

OPENSHIFT : IMAGE STREAM

Similaires à un dépôt DockerHub

Rassemble des images similaires identifiées par destags

Permet de garder un historique des différentes versions

13 . 6

OPENSHIFT : CONCLUSION

13 . 7

CONCLUSION

14 . 1