formation docker

1

FORMATION DOCKER

2 . 1

CONCERNANT CES SUPPORTS DE COURS

2 . 2

SUPPORTS DE COURS RÉALISÉS PAR OSONEShttps://osones.com

Copyright © 2017 OsonesLicence : Sources : Online :

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

https://osones.com/formations/docker.html

2 . 3

AUTEURSRomain Guichard

Kevin Lefevre romain.guichard@osones.io

kevin.lefevre@osones.io

3 . 1

LE CLOUD : VUE D’ENSEMBLE

3 . 2

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 . 3

WAAS : WHATEVER AS A SERVICEIaaS : Infrastructure as aService

PaaS : Platform as a Service

SaaS : Software as a Service

3 . 4

LE CLOUD EN UN SCHÉMA

3 . 5

POURQUOI DU CLOUD ? CÔTÉ TECHNIQUEAbstraction des couches basses

On peut tout programmer à son gré (API)

Permet la mise en place d’architectures scalables

3 . 6

VIRTUALISATION DANS LE CLOUDLe cloud IaaS repose souvent sur la virtualisation

Ressources compute : virtualisation

Virtualisation complète : KVM, Xen

Virtualisation conteneurs : OpenVZ, LXC, Docker,RKT

3 . 7

NOTIONS ET VOCABULAIRE IAASL’instance est par définition éphémère

Elle doit être utilisée comme ressource decalcul

Séparer les données des instances

3 . 8

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 . 9

POSITIONNEMENT DES CONTENEURS DANSL'É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

4 . 1

LES CONTENEURS

4 . 2

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 . 3

LE KERNEL LINUXNamespaces

Cgroups (control groups)

4 . 4

LES NAMESPACES

4 . 5

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 . 6

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 . 7

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

4 . 8

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 . 9

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 . 10

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 . 11

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

4 . 12

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

4 . 13

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

4 . 14

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

4 . 15

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 . 16

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

4 . 17

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 . 18

ENCORE PLUS “CLOUD” QU’UNE INSTANCEPartage 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 . 19

CONTAINER RUNTIMEDocker

Rkt

LXC

4 . 20

LXCConteneur système

Utilise la liblxc

Virtualisation d'un système complet (boot)

4 . 21

DOCKERDé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 . 22

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 . 23

LES CONTENEURS: CONCLUSIONFonctionnalités offertes par le Kernel

Les conteneurs engine fournissent des interfacesd'abstraction

Plusieurs types de conteneurs pour différents besoins

5 . 1

LES CONCEPTS

5 . 2

UN ENSEMBLE DE CONCEPTS ET DECOMPOSANTSLayers

Stockage

Volumes

Réseau

Publication de ports

Links

5 . 3

LAYERSLes 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 . 4

LAYERS : UNE IMAGE

Une image se decompose en layers

5 . 5

LAYERS : UN CONTENEUR

Une conteneur = une image + un layer r/w

5 . 6

LAYERS : PLUSIEURS CONTENEURS

Une image, plusieurs conteneurs

5 . 7

LAYERS : RÉPÉTITION DES LAYERS

Les layers sont indépendants de l'image

5 . 8

STOCKAGEImages Docker, données des conteneurs, volumes

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

5 . 9

STOCKAGE : AUFSA unification filesystem

Stable : performance écriture moyenne

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

5 . 10

STOCKAGE : DEVICE MAPPERBasé sur LVM

Thin Provisionning et snapshot

Intégré dans le Kernel Linux (mainline)

Stable : performance écriture moyenne

5 . 11

STOCKAGE : OVERLAYFSSuccesseur de AUFS

Performances accrues

Relativement stable mais moins éprouvé que AUFS ou DeviceMapper

5 . 12

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 . 13

VOLUMESAssurent 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 . 14

VOLUMES : EXEMPLE

Un volume monté sur deux conteneurs

5 . 15

VOLUMES : PLUGINSPermettre 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 . 16

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

5 . 17

RÉSEAU : BRIDGE

5 . 18

RÉSEAU : HOST

5 . 19

RÉSEAU : NONEExplicite

5 . 20

RÉSEAU : LES ÉVOLUTIONSRefactorisation 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 . 21

RÉSEAU : MULTIHOST OVERLAY

5 . 22

PUBLICATION DE PORTSDans 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 . 23

PUBLICATION DE PORTS

5 . 24

LINKSLes 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 . 25

LES CONCEPTS: CONCLUSIONLes composants de Docker sont modulaires

Nombreuses possibilités offertes par défaut.

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

6 . 1

BUILD, SHIP AND RUN !

6 . 2

BUILD

6 . 3

LE CONTENEUR ET SON IMAGEFlexibilité et élasticité

Format standard de facto

Instanciation illimitée

6 . 4

CONSTRUCTION D'UNE IMAGEPossibilité 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 . 5

DOCKERFILESuite 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 . 6

DOCKERFILE : PRINCIPALES INSTRUCTIONSFROM : 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 . 7

DOCKERFILE : BEST PRACTICESBien choisir sa baseimage

Chaque commande Dockerfile génère un nouveaulayer

Comptez vos layers !

6 . 8

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 . 9

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 . 10

DOCKERFILE : DOCKERHUBBuild automatisée d'images Docker

Intégration GitHub / DockerHub

Plateforme de stockage et de distribution d'imagesDocker

6 . 11

SHIP

6 . 12

SHIP : LES CONTENEURS SONT MANIPULABLESSauvegarder 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 . 13

SHIP : DOCKER REGISTRYDockerHub n’est qu’au Docker registry ce que GitHub est àgit

Pull and Push

Image officielle : registry

6 . 14

RUN

6 . 15

RUN : LANCER UN CONTENEURdocker run

-d (detach)

-i (interactive)

-t (pseudo tty)

6 . 16

RUN : BEAUCOUP D’OPTIONS...-v /directory/host:/directory/container

-p portHost:portContainer

-P-e “VARIABLE=valeur”

–restart=always–name=mon-conteneur

6 . 17

RUN : ...DONT CERTAINES UN PEUDANGEREUSES

–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 . 18

RUN : SE “CONNECTER” À UN CONTENEURdocker exec

docker attach

6 . 19

RUN : DÉTRUIRE UN CONTENEURdocker kill (SIGKILL)

docker stop (SIGTERM puisSIGKILL)

docker rm (détruit complètement)

6 . 20

BUILD, SHIP AND RUN : CONCLUSIONSÉcosystème de gestion d'images

Construction automatisée d'images

Contrôle au niveau conteneurs

7 . 1

ÉCOSYSTÈME DOCKER

7 . 2

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 . 3

OCICréé 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 . 4

LES AUTRES PRODUITS DOCKER

7 . 5

DOCKER-COMPOSEConcept de stack

Infrastructure as acode

Scalabilité

7 . 6

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 . 7

DOCKER-MACHINE"Metal" as a Service

Provisionne des hôtes Docker

Abstraction du Cloud Provider

7 . 8

DOCKER SWARMClustering : Mutualisation d'hôtes Docker

Orchestration : placement intelligent des conteneurs au seindu cluster

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

7 . 10

ÉCOSYSTÈME DOCKER : CONCLUSIONLe 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

8 . 1

DOCKER HOSTS

8 . 2

LES DISTRIBUTIONS TRADITIONNELLESDebian, CentOS, Ubuntu

Supportent tous Docker

Paquets DEB et RPMdisponibles

8 . 3

UN PEU "TOO MUCH" NON ?Paquets inutiles ou out of date

Services par défaut/inutiles alourdissent lesdistributions

Cycle de release figé

8 . 4

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

OS ORIENTÉS CONTENEURS : EXEMPLESCoreOS (CoreOS)

Atomic (Red Hat)

RancherOS (Rancher)

Photon (VMware)

Ubuntu Snappy Core(Ubuntu)

8 . 6

COREOS : PHILOSOPHIETrois "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

COREOS : FONCTIONNALITÉS ORIENTÉESCONTENEURS

8 . 7

Inclus :DockerRktEtcd (base de données clé/valeur)Fleet (système d'init distribué)Flannel (overlay network)Kubernetes Kubelet

Permet nativement d'avoir un clustercomplet

Stable et éprouvé en production

Idéal pour faire tourner Kubernetes (Tectonic)

8 . 8

COREOS : ETCDSystème de stockage simple : clé =valeur

Hautement disponible (quorum)

Accessible via API

8 . 9

COREOS : FLEETSystème d'init distribué basé sur systemd

Orchestration de conteneurs entre différents hôtessupportant systemd

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

8 . 10

COREOS : FLANNELCommunication multi-hosts

UDP ou VXLAN

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

8 . 11

RANCHEROS : PHILOSOPHIEDocker 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 . 12

FEDORA ATOMIC : PHILOSOPHIEÉquivalent à CoreOS mais basée sur Fedora

Utilise systemd

Update Atomic (incrémentielles pourrollback)

8 . 13

PROJECT PHOTONDéveloppé par VMware mais Open Source

Optimisé pour vSphere

Supporte Docker, Rkt et Pivotal Garden (Cloud Foundry)

8 . 14

DOCKER HOSTS : CONCLUSIONRépond à un besoin différent des distributions classiques

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

Sécurité accrue (mise à jour)

9 . 1

DOCKER EN PRODUCTION

9 . 2

OÙ DÉPLOYER ?Cloud public:

GCEAWS

Cloud privé:OpenStack

Bare Metal

9 . 3

COMMENT ?Utilisation de COE (Container OrchestrationEngine)

Utilisation d'infrastructure as code

Utilisation d'un Discovery Service

9 . 4

CONTAINER ORCHESTRATION ENGINEGestion 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:Etcd/Fleet (CoreOS)Docker SwarmRancherMesos / Kubernetes (K8s)

9 . 5

INFRASTRUCTURE AS A CODEVersion Control System

Intégration / Déploiement Continue

Outils de templating (Heat, Terraform,Cloudformation)

9 . 6

DISCOVERY SERVICELa 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 . 7

ETCD/FLEET

Distributed key-Value store (KV store)Résilient de par sa construction, l'information estrépliquée et une défaillance du master n'impact pas lesdonnées

Clustering minimaliste d'hôtes supportant systemdPositionnement intelligent des units en fonction desbesoins

Etcd

Fleet

9 . 8

ETCD/FLEETExemple :

[Unit]Description=Apache-sidekickBindsTo=apache.serviceAfter=apache.service

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

[X-Fleet]MachineOf=apache.service

9 . 9

CONSULCombinaison de plusieurs services : KV Store, DNS,HTTP

Failure detection

Datacenter aware

Github

9 . 10

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 . 11

CONSULL'enregistrement des nouveaux conteneurs peut êtreautomatisé

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

9 . 12

RANCHERPermet 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 . 13

APACHE MESOS / MARATHONMesos : Gestion et orchestration de systèmes distribués

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 10000nodes

9 . 14

KUBERNETES (K8S)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 . 15

QUELQUES AUTRESHashicorp Nomad

Amazon Container Engine

Docker Cloud

Docker UCP (Universal ControlPlane)

9 . 16

DOCKER EN PRODUCTION : CONCLUSION

10 . 1

MONITORER UNE INFRASTRUCTURE DOCKER

10 . 2

QUOI MONITORER ?L'infrastructure

Les conteneurs

10 . 3

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 . 4

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 . 5

Oui bien sûr ;)

10 . 6

MONITORER SES CONTENEURSMonitorer les services fournis par lesconteneurs

Monitorer l'état d'un cluster

Monitorer un conteneur spécifique

10 . 7

PROBLÉMATIQUES DES CONTENEURSLes conteneurs sont des boîtes noires

Les conteneurs sont dynamiques

La scalabilité induite par les conteneurs devient unproblème

10 . 8

MONITORER LES SERVICESLa 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 . 9

MONITORER L'ÉTAT D'UN CLUSTERDé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 . 10

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 . 11

LES OUTILS DE MONITORINGDocker stats

CAdvisor

Datadog

Sysdig

Prometheus

11 . 1

KUBERNETES : CONCEPTS ET OBJETS

11 . 2

KUBERNETES (K8S)COE développé 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 très peu de temps

KUBERNETES : CONCEPTS

11 . 3

PODs

Networking

Volumes

Namespaces

Replication Controllers

Services

Providers : Load Balancer

Deployments / ReplicaSet

Ingress et Ingresscontroller

NetworkPolicy

11 . 4

KUBERNETES : PODEnsemble logique composé de un ou plusieurs conteneurs

Les conteneurs d'un pod fonctionnent ensemble(instanciation et destruction) et sont orchestrés sur un mêmehôte

Les conteneurs partagent certaines spécifications du POD :La stack IP (network namespace)Inter-process communication (PID namespace)Volumes

C'est la plus petite unité orchestrable dans Kubernetes

11 . 5

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 . 6

KUBERNETES : NETWORKINGOverlay Network nécessaire (idem que ceux utilisables avecDocker) :

Cannal : Flannel + CalicoWeavesOpenShiftOpenContrailRomana

Les conteneurs peuvent communiquer sans NAT

Un nœuds peut accéder aux conteneurs des autres nœudssans NAT

11 . 7

KUBERNETES : VOLUMESFournir du stockage persistent aux PODs

Fonctionnent de la même façon que les volumes Docker pourles volumes hôte :

EmptyDir ~= volumes dockerHostPath ~= volumes hôte

Support de multiples backend de stockage :GCE : PDAWS : EBSglusterFS / NFSCephiSCSI

11 . 8

KUBERNETES : VOLUMESOn déclare d'abord le volume et on l'affecte à un service:

apiVersion: v1kind: Podmetadata: name: redisspec: containers: - name: redis image: redis volumeMounts: - name: redis-persistent-storage mountPath: /data/redis volumes: - name: redis-persistent-storage emptyDir: {}

11 . 9

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

Par utilisateursPar projet / applicationsAutres...

Les objets existent uniquement au sein d'un namespacesdonné

Évitent la collision de nom d'objets

11 . 10

KUBERNETES : LABELSSystème de clé/valeur

Organiser les différents objets de Kubernetes (PODs, RC,Services, etc.) d'une manière cohérente qui reflète lastructure de l'application

Corréler des éléments de Kubernetes : par exemple unservice vers des PODs

11 . 11

KUBERNETES : LABELSExemple de label :

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

11 . 12

KUBERNETES : REPLICATION CONTROLLERSPermet de manager les PODs de manière homogène (versionde PODs, nombres, etc.)

Gère la durée de vie des PODs : création et destruction

Assure qu'un nombre minimum de PODs est présent àl'instant T sur l'infrastructure K8s (scaling)

11 . 13

KUBERNETES : REPLICATION CONTROLLERSapiVersion: v1kind: ReplicationControllermetadata: name: nginx-controllerspec: replicas: 2 selector: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

11 . 14

KUBERNETES : SERVICESAbstraction des PODs et RCs, sous forme d'une VIP deservice

Rendre un ensemble de PODs accessibles depuis l'extérieur

Load Balancing entre les PODs d'un même service

11 . 15

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

AWS ELBGCE

Node Port forwarding : limitations

ClusterIP : IP dans le réseau privé Kubernetes (VIP)

IP Externes : le routage de l'IP publique vers le cluster estmanuel

11 . 16

KUBERNETES : SERVICESExemple de service (on remarque la selection sur lelabel):

{ "kind": "Service", "apiVersion": "v1", "metadata": { "name": "example-service" }, "spec": { "ports": [{ "port": 8765, "targetPort": 9376 }], "selector": { "app": "example" }, "type": "LoadBalancer" }}

11 . 17

KUBERNETES : DEPLOYMENTS ET REPLICASETSEvolution des ReplicationController

Permet de définir un ensemble de PODs ainsi qu'unReplicaSet

Version, Update et Rollback

Souvent combiné avec un objet de type service

11 . 18

KUBERNETES : DEPLOYMENTS ET REPLICASETSapiVersion: v1kind: Servicemetadata: name: my-nginx-svc labels: app: nginxspec: type: LoadBalancer ports: - port: 80 selector: app: nginx---apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: my-nginxspec: replicas: 3 template: metadata: labels:

11 . 19

KUBERNETES : INGRESS RESOURCEDéfinition de règles de routage applicative (HTTP/HTTPS)

Traffic load balancing, SSL termination, name based virtualhosting

Définies dans l'API et ensuite implémentées par un IngressController

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

11 . 20

KUBERNETES : INGRESS RESOURCEExemple :

apiVersion: extensions/v1beta1kind: Ingressmetadata: 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 . 21

KUBERNETES : INGRESS CONTROLLERRouteur applicatif de bordure (L7 LoadBalancer)

Implémente les Ingress Resources

Plusieurs implémentations :Træfɪknginx

11 . 22

KUBERNETES : NETWORKPOLICYContrôle la communication entre les PODs au sein d'unnamespace

Pare-feu entre les éléments composant une application :

apiVersion: extensions/v1beta1kind: NetworkPolicymetadata: name: test-network-policy namespace: defaultspec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports:

11 . 23

KUBERNETES : RUN ET ADMINISTRATIONWebUI (Kubernetes Dashboard)

Kubectl (Outil CLI)

Objets: Secret et ConfigMap : paramétrages, plus sécurisésque les variables d'environnements

11 . 24

KUBERNETES : AUJOURD'HUIVersion 1.4 : stable en production

Solution complète et une des plus utilisées

Éprouvée par Google

S'intègre parfaitement à CoreOS (support de rkt et Tectonic,la solution commerciale) et Atomic

12 . 1

KUBERNETES : ARCHITECTURE

12 . 2

KUBERNETES : COMPOSANTSKubernetes est écrit en Go, compilé statiquement.

Un ensemble de binaires sans dépendances

Faciles à conteneuriser et à packager

Peut se déployer uniquement avec des conteneurs sansdépendances d'OS

12 . 3

KUBERNETES : COMPOSANTS

kubelet : Service "agent" fonctionnant sur tous les nœuds etassure le fonctionnement des autres serviceskube-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é 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é(network-policy-controller) : Composant qui implémentel'objet NetworkPolicykubectl : Client qui permet de piloter un cluster Kubernetes

12 . 4

KUBERNETES : KUBELETService principal de Kubernetes

Permet à Kubernetes de s'auto configurer :Surveille un dossier contenant les manifests (fichiers YAMLdes différents 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-controller.yaml

12 . 5

KUBERNETES : KUBELETExemple du manifest kube-proxy:

apiVersion: v1kind: Podmetadata: name: kube-proxy namespace: kube-system annotations: rkt.alpha.kubernetes.io/stage1-name-override: coreos.com/rkt/stage1-flyspec: 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 . 6

KUBERNTES : KUBE-APISERVERLes configuration d'objets (Pods, Service, RC, etc.) se font vial'API server

Un point d'accès à l'état du cluster aux autres composant viaune API REST

Tous les composant sont reliés à l'API server

12 . 7

KUBERNETES : KUBE-SCHEDULERPlanifie les ressources sur le cluster

En 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 . 8

KUBERNETES : KUBE-PROXYResponsable de la publication de services

Utilise iptables

Route les paquets a destination des PODs et réalise le loadbalancing TCP/UDP

12 . 9

KUBERNETES : KUBE-CONTROLLER-MANAGERBoucle infinie qui contrôle l'état d'un cluster

Effectue des opérations pour atteindre un état donné

De base dans Kubernetes : replication controller, endpointscontroller, namespace controller et serviceaccountscontroller

12 . 10

KUBERNETES : NETWORK-POLICY-CONTROLLERImplémente l'objet NetworkPolicy

Contrôle la communication entre les PODs

Externe à Kubernetes et implémenté par la solution deNetworking choisie :

OpenShiftOpenContrailRomanaCalico

12 . 11

KUBERNETES : CONCLUSION

13 . 1

OPENSHIFT : INTRODUCTION

13 . 2

OPENSHIFTSolution 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 . 3

OPENSHIFT VS KUBERNETES : DIFFÉRENCES ETAJOUTS

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 . 4

OPENSHIFT : ROUTERQuasiment identique à Ingress mais implémentés avantKubernetes

Fournissent les même fonctionnalités

Deux implementations :HAProxyF5 Big IP

13 . 5

OPENSHIFT : BUILDPermet 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 . 6

OPENSHIFT : IMAGE STREAMSimilaires à un dépôt DockerHub

Rassemble des images similaires identifiées par destags

Permet de garder un historique des différentes versions

13 . 7

OPENSHIFT : CONCLUSION

14 . 1

CONCLUSION