DOCKER - osones.com · AUTEURS (DOCKER/K8S) Romain Guichard Kevin Lefevre [email protected]...
Transcript of DOCKER - osones.com · AUTEURS (DOCKER/K8S) Romain Guichard Kevin Lefevre [email protected]...
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
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 <[email protected]>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