Skip to content

GitLab

Commit 0234353b authored by Martin Souchal's avatar Martin Souchal
Browse files

relecture

parents c3c9a867 f8314d4b
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 523 additions and 59 deletions
images/components-of-kubernetes.svg 0 → 100644
View file @ 0234353b
This diff is collapsed.
prez.html
View file @ 0234353b
......@@ -67,9 +67,10 @@
### Principe de base
- A l'arrêt, un conteneur est un fichier (ou un ensemble de fichiers) qui est enregistré sur un disque.
- Au démarage du conteneur, le moteur décompresse les fichiers et les méta-données nécessaires, puis les transmet au noyau Linux, comme un processus normal.
- Au démarrage du conteneur, le moteur décompresse les fichiers et les méta-données nécessaires, puis les transmet au noyau Linux, comme un processus normal.
- Un appel API au noyau déclenche une isolation supplémentaire (si nécessaire) et monte une copie des fichiers de l'image du conteneur.
- Une fois lancés, les conteneurs sont un processus Linux comme un autre.
- Un conteneur est immuable (modifier un conteneur = créer un nouveau)
---
# Open Container initiative (OCI)
......@@ -154,9 +155,9 @@
- Temps d'instanciation modéré (plus rapide que VMs)
- Performances dégradées, dépendantes hardware
- Performances lièes aux formats d'images
- Performances liées aux formats d'images
- Format en couches optimisés pour téléchargement
- Format fchier optimisé pour le stockage
- Format fichier optimisé pour le stockage
.footnote[Source : Three Easy Ways to Improve a Container’s Performance by Marialena Perpiraki]
---
......@@ -174,7 +175,7 @@
Profile: default # default seccomp profile applied by default
...
```
- En désactivant completement seccomp, tous les syscalls sont autorisés :
- En désactivant complètement seccomp, tous les syscalls sont autorisés :
```bash
# Lancer un conteneur sans seccomp
......@@ -207,12 +208,12 @@
- Docker : daemon root, possibilité d'être root dans un conteneur
- Possibilité d'utiliser AppArmor ou seccomp coté admin pour "verrouiller" l'infra
- Conteneurs user mode :
- Conteneurs dans le namespace "user" :
- même utilisateur hors du conteneur et dans le conteneur
- les problématiques d'élévation de priviléges sont reportées sur le noyau linux
- Attention au SUID...
- Isolation plus ou moins forte (de userNS a VM)
- Vecteur de failles de sécurité logicelle important (cf Alpine Linux)
- Vecteur de failles de sécurité logicielle important (cf Alpine Linux)
- Vecteur d'attaque pour rootkit (très facile de cacher du code malicieux dans un conteneur)
<img style="float: right;" src="images/software-supply-chain.png" >
......@@ -220,7 +221,7 @@
---
# Registres publics
* Images vérifées
* Images vérifiées
- [NVIDIA NGC](https://ngc.nvidia.com) - images orientées GPU
- [Docker Hub](https://hub.docker.com/) - images officielles
......@@ -249,7 +250,7 @@
- Spécifier toutes les versions exactes des OS et des logiciels dans les manifestes (conda env export, pip freeze, etc....)
- Taguer les images des conteneurs
- Signer les conteneurs diffusés à l'aide de clés
- Préferer les catalogues d'images vérifiées, ou au moins ceux qui scannent les failles de sécurité
- Préférer les catalogues d'images vérifiées, ou au moins ceux qui scannent les failles de sécurité
---
name: inverse
class: center, inverse, middle
......@@ -325,21 +326,31 @@
---
background-image: url(images/docker.png)
# Docker et le calcul
### Un ecosystème pas très adapté...
### Un écosystème pas très adapté...
- Docker est un micro service (un conteneur, une application), pas très facile de gérer des chaines de calcul
- Network namespace et compatibilité matériel réseau pour cluster (Intel OmniPath, Infiniband...)
- Aucun support MPI.
- Aucun support MPI
- Image docker : superpositions de couches, pas très portable dans un cluster
- GPU Nvidia supportés par [nvidia-docker](https://github.com/NVIDIA/nvidia-docker)
- Utilisé massivement en Intégration continue
- Sécurité :
- daemon root à installer sur tous les noeuds de calculs...
- des utilisateurs root dans votre cluster...
- mais sécurisation possible via seccomp
.right[![](images/docker-filesystems-multilayer.png)]
---
background-image: url(images/docker.png)
# Docker et le calcul
### ... mais néanmoins intéressant
- pour la gestion de bases de données
- pour l'optimisation des téléchargements
- pour la création de stacks logicielles (docker-compose)
- trés répandu et portable (tous OS)
- pour la catalogue existant (docker hub...)
- sécurisation possible via seccomp
- pour nvidia-docker...
---
# Nivida docker
- Permet d'utiliser des GPUs Nvidia avec Docker
......@@ -352,7 +363,7 @@
.footnote[Source [NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/overview.html)]
---
# Conteneurs orientés calcul
## 4 Conteneurs usermode compatibles HPC
## 4 Conteneurs compatibles HPC
<hr />
......@@ -376,8 +387,8 @@
- conteneurs utilisables sans droits root
- un conteneur = un répertoire
- Support GPU avec drivers dans le conteneur
- Pas de gestion integrée du réseau
- Ecrit en C, peu de ligne de code (autour de 1000)
- Pas de gestion intégrée du réseau
- Écrit en C, peu de ligne de code (autour de 1000)
- Libre et gratuit
---
......@@ -391,9 +402,9 @@
- Nécessite un Image gateway pour faire lien entre docker et shifter
- utilisable sans droits root mais avec un daemon
- Support GPU avec drivers dans le conteneur
- Pas de gestion integrée du réseau
- Pas de gestion intégrée du réseau
- Documentation quasi inexistante
- Ecrit en C
- Écrit en C
- Libre et gratuit
---
......@@ -403,7 +414,7 @@
- Pratique le principe KISS
- Standalone (pas de daemon)
- Tourne en namespace user (pas de binaire setuid, cgroup, configuration par utilisateur...)
- Tourne en namespace user (pas de binaire setuid, cgroups, configuration par utilisateur...)
- Facile à utiliser (simple image format, scriptable, root remapping...)
- Pas à peu d'isolation
- Configuration administrateur et utilisateur
......@@ -433,48 +444,76 @@
* Première release en Avril 2016
* Les retours de la communauté ont menés à la version 2.0 en Juin 2016
* Sylabs.io en Janvier 2018
* Sortie de la version 3.0 en Octobre 2018 avec une réécriture complète, de nouvelles fonctionalités et une ambition hors HPC
* Sortie de la version 3.0 en Octobre 2018 avec une réécriture complète, de nouvelles fonctionnalités et une ambition hors HPC
* Support officiel NVIDIA via GPU Cloud
---
background-image: url(images/singu.png)
# Fonctionnalités
* Necessite Golang > 1.13 pour la compilation
* Nécessite Golang > 1.13 pour la compilation
* Package RPM uniquement
* Droits root nécessaires pour créer un conteneur localement
* Fichier image unique, executable
* Fichier image SIF : unique, executable, chiffré et signé
* Support natif de MPI, Xorg, GPU
* Infrastructure Cloud (Container Library, Remote Builder, et Keystore)
* Possibilité d’exécuter des images Docker et OCI
* Support/isolation réseau (plugins CNI / root uniquement)
* Support GPU natif avec les drivers de la machine hôte
* Libre et gratuit / Version pro payante
---
background-image: url(images/singu.png)
# Sécurité
* Support des Cgroups
* Support des Cgroups pour la gestion des ressources
* L’utilisateur root peut définir un set de capabilities à l’exécution
* L’administrateur peut gérer les capabilities des utilisateurs (avec précaution)
* Les utilisateurs peuvent passer un contexte d’exécution SELinux, ou un profil AppArmor
* Les utilisateurs peuvent passer leurs propres filtres d’appel système via seccomp
* Support d’exécution avec des UID/GID différents pour l’utilisateur root
* Support d’exécution avec des UID/GID différents pour l’utilisateur root (par défaut c'est le même)
* Conteneurs chiffrés, signés (SIF)
---
background-image: url(images/singu.png)
# Singularity coté admin
### singularity.conf
* Définir les ressources, les restrictions de sécurité, les montages, les options réseau...
* Activer ou non le mode SUID entraîne des limitations*, notamment liées aux images SIF et a fakeroot (user NS)
* Gérer les capabilities des utilisateurs selon 3 modes d'execution :
* full
* file
* no
* Gestion de la sécurité via SELinux, AppArmor, et seccomp
```bash
$ singularity exec --drop-caps CAP_NET_RAW library://sylabs/tests/ubuntu_ping:v1.0 ping -c 1 8.8.8.8
ping: socket: Operation not permitted
```
```bash
$ sudo whoami
root
$ sudo singularity exec --security uid:1000 my_container.sif whoami
david
```
.footnote[*Plus d'infos dans la documentation [officielle](https://sylabs.io/guides/3.7/admin-guide/user_namespace.html#userns-limitations)]
---
background-image: url(images/singu.png)
# Avantages de Singularity pour le HPC
- Facile à installer et à déployer sur un cluster de calcul
- Compatibilité avec Docker
- Utilisation de registres Public/Privé dédiés (http://www.singularity-hub.org/)
- Facile à installer, configurer et à déployer sur un cluster de calcul
- Compatibilité avec le catalogue d'image Docker
- Utilisation de registres Public/Privé dédiés (http://www.singularity-hub.org/), compatibilité gitlab
- Un conteneur est facile à transporter pour l'utilisateur (un fichier SIF à copier)
- Singularity apps
- Compatible tous scheduler
- Singularity apps pour la gestion des chaines de calcul complexes
- Compatible tous job scheduler
- Intégration de tests et d'aide intégrée dans le conteneur
- Accès direct aux GPU de la machine
- Intégration dans Kubernetes
- Conteneurs chiffrés et signés
- Conteneurs en lecture seule
- Sécurité a la carte
---
name: inverse
......@@ -487,74 +526,87 @@
*Un Orchestrateur est un système permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées*
- Approche microservice : les conteneurs qui composent une application sont regroupés dans des unités logiques (pods) pour en faciliter la gestion et la découverte
- Deux acteurs : [Kubernetes](https://kubernetes.io/) (The Linux Foundation) et [Nomad](https://www.nomadproject.io/) (Hashicorp)
- Deux acteurs principaux : [Kubernetes](https://kubernetes.io/) (The Linux Foundation) et [Nomad](https://www.nomadproject.io/) (Hashicorp)
<img style="width:600px;" src="images/k8vN.png">
---
# Kubernetes
<img style="width:100px;float:right" src="images/kubernetes_icons.svg" >
* Kubernetes est orienté microservice et web
* Pas de support natif d'accélérateurs (framework device plugins)
* Basé sur Docker, ouvert aux runtime CRI (containerd, CRI-O, Singularity)
* Gestion d'accélérateurs avec framework device plugins
* Basé sur Docker, ouvert aux runtime OCI (containerd, CRI-O, Singularity)
* Pas de gestion de batch dans Kubernetes, ce qui s'en rapproche le plus est la notion de Job
* Un job crée un ou plusieurs pods et s'assure qu'ils se terminent bien. Lorsqu'un pod se termine avec succès le Job l'enregistre. Quand tous les pods sont terminés, le Job est complet. Supprimer un job supprime le Pod qu'il a crée.
* Un ensemble de pods qui exécutent une tâche et s'arrêtent.
* Le job lance un nouveau pod si un pod échoue ou est supprimé.
* Possibilité de lancer plusieurs pods en parallèle (mais pas avec MPI).
* Singularity-CRI est fourni avec le support natif des GPU NVIDIA en [device plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* Singularity-CRI permet le support des GPU NVIDIA en [device plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
<img style="width:100px;float:right" src="images/kubernetes_icons.svg" >
<img style="width:600px;float:right" src="images/components-of-kubernetes.svg" >
---
# Nomad
<img style="width:30%;float:right" src="images/nomad.svg" >
* Scheduler Hybride et multi cloud
* Déployer facilement des applications conteneurisées ou pas
* Infrastructure as cloud déclaratif
* Binaire multi plateforme
* Version 0.10, déja en production
* Compatible GPU, FPGA, TPUs...
* Uniquement de la gestion de cluster et scheduling
* Supporte Spark
* Version 1.0.2
* Kubernetes vise à fournir toutes les fonctionnalités nécessaires à l'exécution d'applications basées sur Docker, notamment la gestion des clusters, le scheduling, la découverte de services, la surveillance, la gestion des secrets, etc...
* Nomad ne fait que de la gestion de cluster et du scheduling
<img style="width:30%;float:right" src="images/nomad.svg" >
<img style="width:500px;" src="images/nomad_reference_diagram.png" >
---
# Intérêt de Nomad vs Kubernetes pour le calcul
# Nomad
<img style="width:30%;float:right" src="images/nomad.svg" >
* Auto rescheduling
* Fédération native d'orchestrateur multi-region et multi-datacenter
* Intégration parfaite avec la stack HashiCorp (Vault, Consul et Terraform...)
* Intégration automatique des GPU/TPU/FPGA
* Pas orienté conteneur uniquement (possibilité d'orchestrer des VMs ou des applications batchs)
* S'intègre avec Consul (découverte et maillage de services, réseau), Terraform (déploiement) et Vault (gestion de secrets)
* Nomad supporte la fédération native multi-region et multi-datacenter
* Nomad intègre la gestion des GPU/TPU/FPGA, support Spark
* Nomad permet d'orchestrer des VMs ou des applications batchs en plus des conteneurs
* Scalabilité : Kubernetes est limité a 5000 nœuds et a 100 pods par nœuds. Instances de Nomad de plus de 10 000 nœuds en production.
* Entièrement et uniquement développé par des employés d'HashiCorp, en open source.
* Compatible Linux, MacOs et Windows (Kubernetes n'est supporté que sur Linux)
* Binaire de 75Mb (pour client et serveur).
* Nomad est entièrement et uniquement développé par des employés d'HashiCorp, en open source mais sans support communautaire
* Nomad est compatible Linux, MacOs et Windows, Kubernetes n'est supporté que sur Linux
* Nomad distribué sous la forme d'un binaire de 75Mb (pour client et serveur), Kubernetes demande le déploiement de nombreux conteneurs
<img style="width:30%;float:right" src="images/nomad.svg" >
---
# Désavantages de Nomad
<img style="width:30%;float:right" src="images/nomad.svg" >
* Kubernetes fournit tous les services necessaires pour faire tourner des conteneurs Docker or Rkt-based (cluster management, scheduling, service discovery, monitoring, secrets management, ...).
* Nomad est développé par une seule entité, HashiCorp et n'a pas de support communautaire.
* Définition des ressources manuelle
* Auto scaling pas encore disponible
* Développement très rapide, avec une certaine tendance à la dépréciation sauvage et sans préavis
* Un certains nombre de fonctionnalités payantes
<img style="width:30%;float:right" src="images/nomad.svg" >
---
# Job scheduler
- Approche Job avec heure de début - fin, ressources à utiliser
- mécanismes de
- Notion de job avec heure de début - fin, ressources à utiliser
- Mécanismes de :
- files d’attente/de mises en attente ou pause (checkpointing)
- priorités / Fair sharing
- droits/accès et partages des ressources physiques
- Intégration dans l’environnement cluster existant
- Compatible tous runtimes en userNS
<img style="width:30%;float:right" src="images/slurm.jpg" >
---
# Conclusion
* Les conteneurs ne garantissent pas la reproductibilité
* ... ni la répétabilité *a priori*
* ils ont d'autres qualités : la portabilité, l'intégration continue, l'autonomie de l'utilisateur, le partage de logiciels...
* Peu d'isolation entraîne une grande dépendance a l'environnement hôte...
* ...et posent des problèmes de sécurité !
---
# Questions
Retrouvez nous sur
* Rocket Chat : [#computeops](https://chat.in2p3.fr/channel/computeops)
* [Citadel CNRS](https://cnrs.citadel.team/#/room/!HWuisClGdDMYoEwIAV:cnrs.citadel.team)
---
</textarea>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment