Formation Docker

Concernant ces supports de cours

Supports de cours réalisés par Osones

https://osones.com

Auteurs

Le Cloud : vue d’ensemble

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é

WaaS : Whatever as a Service

  • IaaS : Infrastructure as a Service

  • PaaS : Platform as a Service

  • SaaS : Software as a Service

Le cloud en un schéma

Pourquoi du cloud ? Côté technique

  • Abstraction des couches basses

  • On peut tout programmer à son gré (API)

  • Permet la mise en place d’architectures scalables

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

Notions et vocabulaire IaaS

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

  • Elle doit être utilisée comme ressource de calcul

  • Séparer les données des instances

Orchestration des ressources ?

  • Groupement fonctionnel de ressources : micro services

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

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

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 micro services

Les conteneurs

Définition

  • Les conteneurs fournissent un environnement isolé sur un système hôte, semblable à un chroot sous Linux ou une jail sous BSD, mais en proposant plus de fonctionnalités en matière d'isolation et de configuration. Ces fonctionnalités sont dépendantes du système hôte et notamment du kernel.

Le Kernel Linux

  • Namespaces

  • Cgroups (control groups)

Les namespaces

Mount namespaces ( Linux 2.4.19)

  • Permet de créer un arbre des points de montage indépendants de celui du système hôte.

UTS namespaces (Linux 2.6.19)

  • Unix Time Sharing : Permet à un conteneur de disposer de son propre nom de domaine et d’identité NIS sur laquelle certains protocoles tel que LDAP peuvent se baser.

IPC namespaces (Linux 2.6.19)

  • Inter Process Communication : Permet d’isoler les bus de communication entre les processus d’un conteneur.

PID namespaces (Linux 2.6.24)

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

User namespaces (Linux 2.6.23-3.8)

  • Permet l’isolation des utilisateurs et des groupes au sein d’un conteneur. Cela permet notamment de gérer des utilisateurs tels que l’UID 0 et GID 0, le root qui aurait des permissions absolues au sein d’un namespace mais pas au sein du système hôte.

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.

Cgroups : Control Croups

CGroup: /
           |--docker
           |  |--7a977a50f48f2970b6ede780d687e72c0416d9ab6e0b02030698c1633fdde956
           |  |--6807 nginx: master process ngin
           |  |  |--6847 nginx: worker proces

Cgroups : Limitation de ressources

  • Limitation des ressources : des groupes peuvent être mis en place afin de ne pas dépasser une limite de mémoire.

Cgroups : Priorisation

  • Priorisation : certains groupes peuvent obtenir une plus grande part de ressources processeur ou de bande passante d'entrée-sortie.

Cgroups : Comptabilité

  • Comptabilité : permet de mesurer la quantité de ressources consommées par certains systèmes, en vue de leur facturation par exemple.

Cgroups : Isolation

  • Isolation : séparation par espace de nommage pour les groupes, afin qu'ils ne puissent pas voir les processus des autres, leurs connexions réseaux ou leurs fichiers.

Cgroups : Contrôle

  • Contrôle : figer les groupes ou créer un point de sauvegarde et redémarrer.

Deux philosophies de conteneurs

  • Systeme : simule une séquence de boot complète avec un init process ainsi que plusieurs processus (LXC, OpenVZ).
  • Process : un conteneur exécute un ou plusieurs processus directement, en fonction de l'application conteneurisée (Docker, Rkt).

Encore plus “cloud” qu’une instance

  • Partage du kernel

  • Un seul processus par conteneur

  • Le conteneur est encore plus éphémère que l’instance

  • Le turnover des conteneurs est élevé : orchestration

Container runtime

  • Docker

  • Rkt

  • LXC

LXC

  • Conteneur système

  • Utilise la liblxc

  • Virtualisation d'un système complet (boot)

Docker

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

  • Fonctionne en mode daemon : difficulté d'intégration avec les init-process

  • Utilisait la liblxc

  • Utilise désormais la libcontainer

Rocket (rkt)

  • Se prononce “rock-it”

  • Développé par CoreOS

  • Pas de daemon : intégration avec systemd

  • Utilise systemd-nspawn et propose maintenant d'autres solutions (eg. KVM)

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

Les conteneurs: conclusion

  • Fonctionnalités offertes par le Kernel

  • Les conteneurs engine fournissent des interfaces d'abstraction

  • Plusieurs types de conteneurs pour différents besoins

Les concepts

Un ensemble de concepts et de composants

  • Layers

  • Stockage

  • Volumes

  • Réseau

  • Publication de ports

  • Links

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.

Layers : une image

Une image se decompose en layers
Une image se decompose en layers

Layers : un conteneur

Une conteneur = une image + un layer r/w
Une conteneur = une image + un layer r/w

Layers : plusieurs conteneurs

Une image, plusieurs conteneurs
Une image, plusieurs conteneurs

Layers : Répétition des layers

Les layers sont indépendants de l'image
Les layers sont indépendants de l'image

Stockage

  • Images Docker, données des conteneurs, volumes

  • Multiples backends (extensibles via plugins):
    • AUFS
    • DeviceMapper
    • OverlayFS
    • NFS (via plugin Convoy)
    • GlusterFS (via plugin Convoy)

Stockage : AUFS

  • A unification filesystem

  • Stable : performance écriture moyenne

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

Stockage : Device Mapper

  • Basé sur LVM

  • Thin Provisionning et snapshot

  • Intégré dans le Kernel Linux (mainline)

  • Stable : performance écriture moyenne

Stockage : OverlayFS

  • Successeur de AUFS

  • Performances accrues

  • Relativement stable mais moins éprouvé que AUFS ou Device Mapper

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

Volumes

  • Assurent une persistance des données

  • Indépendance du volume par rapport au conteneur et aux layers

  • Deux types de volumes :
    • Conteneur : Les données sont stockées dans ce que l'on appelle un data conteneur
    • Hôte : Montage d'un dossier de l'hôte docker dans le conteneur
  • Partage de volumes entre plusieurs conteneurs

Volumes : Exemple

Un volume monté sur deux conteneurs
Un volume monté sur deux conteneurs

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

Réseau : A la base, pas grand chose...

NETWORK ID      NAME      DRIVER
42f7f9558b7a    bridge    bridge
6ebf7b150515    none      null
0509391a1fbd    host      host

Réseau : Bridge

Réseau : Host

Réseau : None

  • Explicite

Réseau : Les évolutions

  • Refactorisation des composants réseau (libnetwork)

  • Système de plugins : multi host et multi backend (overlay network)

  • Quelques exemples d'overlay :
    • Flannel : UDP et VXLAN
    • Weaves : UDP

Réseau : multihost overlay

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 le conteneur (iptables)

  • L'hôte sert de proxy au service

Publication de ports

Les concepts: conclusion

  • Les composants de Docker sont modulaires

  • Nombreuses possibilités offertes par défaut.

  • Possibilité d'étendre les fonctionnalités via des plugins

Build, Ship and Run !

Build

Le conteneur et son image

  • Flexibilité et élasticité

  • Format standard de facto

  • Instanciation illimitée

Construction d'une image

  • Possibilité de construire son image à la main (long et source d'erreurs)

  • Suivi de version et construction d'images de manière automatisée

  • Utilisation de Dockerfile afin de garantir l'idempotence des images

Dockerfile

  • Suite d'instruction qui définit une image

  • Permet de vérifier le contenu d'une image

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

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 par le conteneur

Dockerfile : best practices

  • Bien choisir sa baseimage

  • Chaque commande Dockerfile génère un nouveau layer

  • Comptez vos layers !

Dockerfile : Bad Layering

RUN apk --update add \
    git \
    tzdata \
    python \
    unrar \
    zip \
    libxslt \
    py-pip \

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

VOLUME /config /downloads

EXPOSE 8081

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

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

Dockerfile : Good Layering

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

VOLUME /config /downloads

EXPOSE 8081

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

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

Dockerfile : DockerHub

  • Build automatisée d'images Docker

  • Intégration GitHub / DockerHub

  • Plateforme de stockage et de distribution d'images Docker

Ship

Ship : Les conteneurs sont manipulables

  • Sauvegarder un conteneur :
docker commit mon-conteneur backup/mon-conteneur
docker run -it backup/mon-conteneur
  • Exporter un conteneur :
docker save -o mon-image.tar backup/mon-conteneur
  • Importer un conteneur :
docker import mon-image.tar backup/mon-conteneur

Ship : Docker Registry

  • DockerHub n’est qu’au Docker registry ce que GitHub est à git

  • Pull and Push

  • Image officielle : registry

Run

Run : lancer un conteneur

  • docker run

  • -d (detach)

  • -i (interactive)

  • -t (pseudo tty)

Run : beaucoup d’options...

  • -v /directory/host:/directory/container

  • -p portHost:portContainer

  • -P

  • -e “VARIABLE=valeur”

  • –restart=always

  • –name=mon-conteneur

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 de l’host)

Run : se “connecter” à un conteneur

  • docker exec

  • docker attach

Run : Détruire un conteneur

  • docker kill (SIGKILL)

  • docker stop (SIGTERM puis SIGKILL)

  • docker rm (détruit complètement)

Build, Ship and Run : Conclusions

  • Écosystème de gestion d'images

  • Construction automatisée d'images

  • Contrôle au niveau conteneurs

Écosystème Docker

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 sont possibles

OCI

  • Créé sous la Linux Fondation

  • But : Créer des standards OpenSource concernant la manière de "runner" et le format des conteneurs

  • Non lié à des produits commerciaux

  • Non lié à des orchestrateurs ou des clients particuliers

  • runC a été donné par Docker à l'OCI comme base pour leurs travaux

Les autres produits Docker

Docker-compose

  • Concept de stack

  • Infrastructure as a code

  • Scalabilité

Docker-compose

docker-compose.yml

nginx:
  image: vsense/nginx
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "/srv/nginx/etc/sites-enabled:/etc/nginx/sites-enabled"
    - "/srv/nginx/etc/certs:/etc/nginx/certs"
    - "/srv/nginx/etc/log:/var/log/nginx"
    - "/srv/nginx/data:/var/www"

Docker-machine

  • "Metal" as a Service

  • Provisionne des hôtes Docker

  • Abstraction du Cloud Provider

Docker Swarm

  • Clustering : Mutualisation d'hôtes Docker

  • Orchestration : placement intelligent des conteneurs au sein du cluster

Autour de Docker

  • Plugins : étendre les fonctionnalités notamment réseau et volumes

  • Systèmes de gestion de conteneurs (COE)

  • Docker as a Service :
    • Docker Cloud
    • Tutum

Écosystème Docker : conclusion

  • Le projet Docker est Open Source et n'appartient plus a Docker

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

  • Docker Inc. construit des offres commerciales autour de Docker

Docker Hosts

Les distributions traditionnelles

  • Debian, CentOS, Ubuntu

  • Supportent tous Docker

  • Paquets DEB et RPM disponibles

Un peu "too much" non ?

  • Paquets inutiles ou out of date

  • Services par défaut/inutiles alourdissent les distributions

  • Cycle de release figé

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

OS orientés conteneurs : exemples

  • CoreOS (CoreOS)

  • Atomic (Red Hat)

  • RancherOS (Rancher)

  • Photon (VMware)

  • Ubuntu Snappy Core (Ubuntu)

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 est conteneurisé

  • Forte intégration de systemd

CoreOS : fonctionnalités orientées conteneurs

  • Inclus :
    • Docker
    • Rkt
    • Etcd (base de données clé/valeur)
    • Fleet (système d'init distribué)
    • Flannel (overlay network)
    • Kubernetes Kubelet
  • Permet nativement d'avoir un cluster complet

  • Stable et éprouvé en production

  • Idéal pour faire tourner Kubernetes (Tectonic)

CoreOS : Etcd

  • Système de stockage simple : clé = valeur

  • Hautement disponible (quorum)

  • Accessible via API

CoreOS : Fleet

  • Système d'init distribué basé sur systemd

  • Orchestration de conteneurs entre différents hôtes supportant systemd

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

CoreOS : Flannel

  • Communication multi-hosts

  • UDP ou VXLAN

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

RancherOS : philosophie

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

  • Docker in Docker : Daemon User qui tourne dans le Daemon System

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

  • Encore en beta

Fedora Atomic : philosophie

  • Équivalent à CoreOS mais basée sur Fedora

  • Utilise systemd

  • Update Atomic (incrémentielles pour rollback)

Project Photon

  • Développé par VMware mais Open Source

  • Optimisé pour vSphere

  • Supporte Docker, Rkt et Pivotal Garden (Cloud Foundry)

Docker Hosts : conclusion

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

  • Fourni des outils et une logique adaptée aux environnements full conteneurs

  • Sécurité accrue (mise à jour)

Docker en production

Où déployer ?

  • Cloud public:
    • GCE
    • AWS

  • Cloud privé: OpenStack
  • Bare Metal

Comment ?

  • Utilisation de COE (Container Orchestration Engine)

  • Utilisation d'infrastructure as code

  • Utilisation d'un Discovery Service

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:
    • Etcd/Fleet (CoreOS)
    • Docker Swarm
    • Rancher
    • Mesos / Kubernetes (K8s)

Infrastructure as a Code

  • Version Control System

  • Intégration / Déploiement Continue

  • Outils de templating (Heat, Terraform, Cloudformation)

Discovery Service

  • La nature éphémère des conteneurs empêche toute configuration manuelle

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

  • Fournir un endpoint fixe à une application susceptible de bouger au sein d'un cluster

Etcd/Fleet

  • Etcd
    • Distributed key-Value store (KV store)
    • Résilient de par sa construction, l'information est répliquée et une défaillance du master n'impact pas les données
  • Fleet
    • Clustering minimaliste d'hôtes supportant systemd
    • Positionnement intelligent des units en fonction des besoins

Etcd/Fleet

  • Exemple :
[Unit]
Description=Apache-sidekick
BindsTo=apache.service
After=apache.service

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

[X-Fleet]
MachineOf=apache.service

Consul

  • Combinaison de plusieurs services : KV Store, DNS, HTTP

  • Failure detection

  • Datacenter aware

  • Github

Consul

Exemple :

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

Consul

  • L'enregistrement des nouveaux conteneurs peut être automatisé

  • Registrator est un process écoutant le daemon Docker et enregistrant les évènements

Rancher

  • Permet de provisionner et mutualiser des hôtes Docker sur différents Cloud Provider

  • Fournit des fonctionnalité de COE :
    • Cattle : COE développé par Rancher
    • Kubernetes : 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)

Apache Mesos / Marathon

  • Mesos : 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 10000 nodes

Kubernetes (K8s)

  • COE développé par Google, devenu open source en 2014

  • Utilisé par Google pour la gestion de leurs conteneurs

  • Adapté à tout type d'environnements

  • Devenu populaire en très peu de temps

Quelques autres

  • Hashicorp Nomad

  • Amazon Container Engine

  • Docker Cloud

  • Docker UCP (Universal Control Plane)

Docker en production : conclusion

Monitorer une infrastructure Docker

Quoi monitorer ?

  • L'infrastructure

  • Les conteneurs

Monitorer son infrastructure

  • Problématique classique

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

  • Nagios

  • Shinken

  • Centreons

  • Icinga

Intérêt ?

  • Un des principes du cloud computing est d'abstraire les couches basses

  • Docker accentue cette pratique

  • Est-ce intéressant de monitorer son infra ?

Oui bien sûr ;)

Monitorer ses conteneurs

  • Monitorer les services fournis par les conteneurs

  • Monitorer l'état d'un cluster

  • Monitorer un conteneur spécifique

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

Monitorer les services

  • La problématique est différente pour chaque service

  • Concernant les web services (grande majorité), le temps de réponse du service et la disponibilité du service sont de bons indicatifs

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

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 des conteneurs eux mêmes ?

Monitorer, OK mais depuis où ?

  • Commandes exécutées dans le container

  • Agents à l'intérieur du conteneur

  • Agents à l'extérieur du conteneur

Les outils de monitoring

  • Docker stats

  • CAdvisor

  • Datadog

  • Sysdig

  • Prometheus

Kubernetes : Concepts et Objets

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

  • PODs

  • Networking

  • Volumes

  • Namespaces

  • Replication Controllers

  • Services

  • Providers : Load Balancer

  • Deployments / ReplicaSet

  • Ingress et Ingress controller

  • NetworkPolicy

Kubernetes : POD

  • Ensemble logique composé de un ou plusieurs conteneurs

  • Les conteneurs d'un pod fonctionnent ensemble (instanciation et destruction) et sont orchestrés sur un même hô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

Kubernetes : POD

  • Les PODs sont définis en YAML comme les fichiers docker-compose :
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Kubernetes : Networking

  • Overlay Network nécessaire (idem que ceux utilisables avec Docker) :
    • Cannal : Flannel + Calico
    • Weaves
    • OpenShift
    • OpenContrail
    • Romana
  • Les conteneurs peuvent communiquer sans NAT

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

Kubernetes : Volumes

  • Fournir du stockage persistent aux PODs

  • Fonctionnent de la même façon que les volumes Docker pour les volumes hôte :
    • EmptyDir ~= volumes docker
    • HostPath ~= volumes hôte
  • Support de multiples backend de stockage :
    • GCE : PD
    • AWS : EBS
    • glusterFS / NFS
    • Ceph
    • iSCSI

Kubernetes : Volumes

  • On déclare d'abord le volume et on l'affecte à un service :
apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-persistent-storage
      mountPath: /data/redis
  volumes:
  - name: redis-persistent-storage
    emptyDir: {}

Kubernetes : Namespaces

  • Fournissent une séparation logique des ressources par exemple :
    • Par utilisateurs
    • Par projet / applications
    • Autres...
  • Les objets existent uniquement au sein d'un namespaces donné

  • Évitent la collision de nom d'objets

Kubernetes : Labels

  • Système de clé/valeur

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

  • Corréler des éléments de Kubernetes : par exemple un service vers des PODs

Kubernetes : Labels

  • Exemple de label :
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Kubernetes : Replication Controllers

  • Permet de manager les PODs de manière homogène (version de 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)

Kubernetes : Replication Controllers

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-controller
spec:
  replicas: 2
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Kubernetes : Services

  • Abstraction des PODs et RCs, sous forme d'une VIP de service

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

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

Kubernetes : Services

  • Load Balancing : intégration avec des cloud provider :
    • AWS ELB
    • GCE
  • Node Port forwarding : limitations

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

  • IP Externes : le routage de l'IP publique vers le cluster est manuel

Kubernetes : Services

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

Kubernetes : Deployments et ReplicaSets

  • Evolution des ReplicationController

  • Permet de définir un ensemble de PODs ainsi qu'un ReplicaSet

  • Version, Update et Rollback

  • Souvent combiné avec un objet de type service

Kubernetes : Deployments et ReplicaSets

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Kubernetes : Ingress Resource

  • Définition de règles de routage applicative (HTTP/HTTPS)

  • Traffic load balancing, SSL termination, name based virtual hosting

  • Définies dans l'API et ensuite implémentées par un Ingress Controller

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

Kubernetes : Ingress Resource

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

Kubernetes : Ingress Controller

  • Routeur applicatif de bordure (L7 Load Balancer)

  • Implémente les Ingress Resources

  • Plusieurs implémentations :

Kubernetes : NetworkPolicy

  • Contrôle la communication entre les PODs au sein d'un namespace

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

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
 name: test-network-policy
 namespace: default
spec:
 podSelector:
  matchLabels:
    role: db
 ingress:
  - from:
     - namespaceSelector:
        matchLabels:
         project: myproject
     - podSelector:
        matchLabels:
         role: frontend
    ports:
     - protocol: tcp
       port: 6379

Kubernetes : Run et administration

  • WebUI (Kubernetes Dashboard)

  • Kubectl (Outil CLI)

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

Kubernetes : Aujourd'hui

  • Version 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

Kubernetes : Architecture

Kubernetes : Composants

  • Kubernetes 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 sans dépendances d'OS

Kubernetes : Composants

  • kubelet : Service "agent" fonctionnant sur tous les nœuds et assure le fonctionnement des autres services
  • kube-apiserver : API server qui permet la configuration d'objet Kubernetes (Pods, Service, Replication Controller, etc.)
  • kube-proxy : Permet le forwarding TCP/UDP et le load balancing entre les services et les backend (Pods)
  • kube-scheduler : Implémente les fonctionnalité de scheduling
  • kube-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émente l'objet NetworkPolicy
  • kubectl : Client qui permet de piloter un cluster Kubernetes

Kubernetes : kubelet

  • Service principal de Kubernetes

  • Permet à Kubernetes de s'auto configurer :
    • Surveille un dossier contenant les manifests (fichiers YAML des 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

Kubernetes : kubelet

  • Exemple du manifest kube-proxy :
apiVersion: v1
kind: Pod
metadata:
  name: kube-proxy
  namespace: kube-system
  annotations:
    rkt.alpha.kubernetes.io/stage1-name-override: coreos.com/rkt/stage1-fly
spec:
  hostNetwork: true
  containers:
  - name: kube-proxy
    image: quay.io/coreos/hyperkube:v1.3.6_coreos.0
    command:
    - /hyperkube
    - proxy
    - --master=http://127.0.0.1:8080
    - --proxy-mode=iptables
    securityContext:
      privileged: true
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ssl-certs-host
      readOnly: true
  volumes:
  - hostPath:
      path: /usr/share/ca-certificates
    name: ssl-certs-host

Kuberntes : kube-apiserver

  • Les configuration d'objets (Pods, Service, RC, etc.) se font via l'API server

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

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

Kubernetes : kube-scheduler

  • Planifie les ressources sur le cluster

  • En fonction de règles implicites (CPU, RAM, stockage disponible, etc.)

  • En fonction de règles explicites (règles d'affinité et anti-affinité, labels, etc.)

Kubernetes : kube-proxy

  • Responsable de la publication de services

  • Utilise iptables

  • Route les paquets a destination des PODs et réalise le load balancing TCP/UDP

Kubernetes : kube-controller-manager

  • Boucle infinie qui contrôle l'état d'un cluster

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

  • De base dans Kubernetes : replication controller, endpoints controller, namespace controller et serviceaccounts controller

Kubernetes : network-policy-controller

  • Implémente l'objet NetworkPolicy

  • Contrôle la communication entre les PODs

  • Externe à Kubernetes et implémenté par la solution de Networking choisie :
    • OpenShift
    • OpenContrail
    • Romana
    • Calico

kubernetes : Conclusion

OpenShift : Introduction

OpenShift

OpenShift VS Kubernetes : Différences et ajouts

  • Pas d'Ingress : Router

  • Build et Images Stream : Création d'images et pipeline de CI/CD

  • Templates : Permet de definir et templatiser facilement un ensemble d'Objet OpenShift

  • OpenShift SDN ou Nuage Network pour le réseau

OpenShift : Router

  • Quasiment identique à Ingress mais implémentés avant Kubernetes

  • Fournissent les même fonctionnalités

  • Deux implementations :
    • HAProxy
    • F5 Big IP

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 application depuis les source

  • Pipeline builds : via Jenkins

OpenShift : Image Stream

  • Similaires à un dépôt DockerHub

  • Rassemble des images similaires identifiées par des tags

  • Permet de garder un historique des différentes versions

OpenShift : Conclusion

Conclusion