formation docker
TRANSCRIPT
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
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 <[email protected]>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