Cette présentation était en partenariat avec WeScale (Cédric Hauber).
De nos jours, de plus en plus d’entreprises adoptent Docker. Mais comment faire avec des dizaines, des centaines voire des milliers de conteneurs à gérer ? Google s’est posé ces questions et de ses forges une réponse est sortie : le projet Kubernetes. Venez marcher dans les pas du géant en découvrant Kubernetes dans son intimité. Vous apprendrez à déployer une application, la scaler, la mettre à jour en rolling update et l'isoler des environnements. Entre démonstrations et retours de terrain, vous repartirez avec tous les outils pour conteneuriser la planète.
20. #DevoxxFR
Livraison
● Lorsque je livre mon application, je la livre avec
son contexte d’exécution
● Je peux placer mon conteneur sur n’importe
quelle machine où Docker est installé
20
26. #DevoxxFR
Sur un cluster ?
Nouvelles problématiques :
- Comment savoir où se trouvent les conteneurs
- Que faire si un noeud tombe
- Comment correctement allouer les ressources
26
30. #DevoxxFR
Fleet
+
- Partie intégrante de CoreOS
- Repose sur Etcd
- Permet de maintenir des services systemd dans le cluster
-
- Orchestrateur bas niveau → Fonctions limitées
30
31. #DevoxxFR
Swarm
+
- Créé par Docker pour Docker
- Repose sur Consul
- Très simple d’utilisation
-
- Forte adhérence à l’API Docker
- Pas de Health-Check, pas de LoadBalancing...
31
32. #DevoxxFR
Rancher
+
- Image minimaliste
- OS orienté tout-conteneur
- Interface de management
- Kubernetes / Swarm / Cattle out of the box
-
- Installation parfois compliquée
- Supporte uniquement Docker
32
33. #DevoxxFR
Kubernetes
+
- Profite du savoir-faire de Google en matière de Conteneurs
- Repose sur Etcd
- Compatible avec Docker & Rocket
- Une communauté très établie
- Regorge de fonctionnalités
-
- Mise en place parfois ardue
33
34. #DevoxxFR
Mesos - Marathon
+
- Déploiement rapide sur AWS / GCP / Azure
- A fait ses preuves
- Supporte plusieurs frameworks
-
- Une couche supplémentaire qui n’est pas nécessaire
dans 90% des cas
34
35. “When you are not using Kubernetes to orchestrate Docker containers”
Chris Baun35
36. #DevoxxFR
Pourquoi Kubernetes
● La solution la plus aboutie
● Preuve d’une expérience de plus de 10 ans
● Grosse communauté
● Opinionated
● Cloud-Provider Aware :)
● Production-Ready !
● C’est super cool !
36
52. #DevoxxFR
Kubelet
● Agent principal sur chaque Node
● Reçoit les demandes de création
de Pod
● Monte les Volumes des Pods
● Lance les conteneurs
● Rapporte l’état des
pods/conteneurs à l’API-Server
52
58. #DevoxxFR
Pod
● Plus petite unité logique
● Encapsule un ou plusieurs conteneurs
○ Partage de contexte
● Unité pouvant être répliquée
● Lié à un node
● Existence temporaire
58
94. #DevoxxFR
Service
Problème :
un Pod est éphémère
son adresse IP également
Solution :
le service joue le rôle d’ambassadeur
en fournissant une adresse ip durable
Il joue également le rôle de load balancer
94
106. #DevoxxFR
NodePort
• Kubernetes alloue un port :
• [30 000 - 32 767]
• Tous les Nodes du cluster vont exposer ce port
• Kubernetes expose alors le service :
• <Node IP>:<NodePort>
106
117. #DevoxxFR
Deployments
- Permet de déployer facilement des applications
- Supporte plusieurs types de mises à jour :
- Rolling Update
- Replace
- A/B Deployment
- Il n’a pas vocation à remplacer le ReplicationController
117
118. #DevoxxFR
Rolling Update
● Une application sera mise à jour de multiples fois au
cours de son existence
● Cette procédure de mise à jour doit donc être simple et
automatisée
● C’est d’autant plus vrai dans un cluster
● Kubernetes a pensé à vous
118
131. #DevoxxFR
node Worker
Pod v.1
Replica
Set
Replica
Set
node Worker
Pod v.1
node Worker
Pod v.1 Pod v.2Pod v.2
Service
app: todo
version: v1
app: todo
version: v1
app: todo
version: v1
app: todo
version: v1
app: todo
version: v2
app: todo
version: v2
131
132. #DevoxxFR
node Worker
Pod v.1
Replica
Set
Replica
Set
node Worker
Pod v.1
node Worker
Pod v.1 Pod v.2Pod v.2Pod v.2
Service
app: todo
version: v1
app: todo
version: v1
app: todo
version: v1
app: todo
version: v1
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
132
133. #DevoxxFR
node Worker
Pod v.1
Replica
Set
Replica
Set
node Worker
Pod v.1
node Worker
Pod v.1 Pod v.2Pod v.2Pod v.2
Service
app: todo
version: v1
app: todo
version: v1
app: todo
version: v1
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
133
134. #DevoxxFR
node Worker
Replica
Set
node Worker node Worker
Pod v.2Pod v.2Pod v.2
Service
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
134
140. #DevoxxFR
node Worker
Replica
Set
node Worker node Worker
Pod v.2Pod v.2Pod v.2
Service
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
app: todo
version: v2
140
147. #DevoxxFR
Connaître l’état d’un conteneur
Rôle de l’agent Kubelet qui est présent sur chacun des nodes.
Est-ce que mon conteneur est prêt ?
→ Readiness probe
Est-ce que mon conteneur est vivant ?
→ Liveness probe
147
150. #DevoxxFR
Et la réaction ?
Readiness échoue → le pod garde son état mais n’est plus accessible
Liveness échoue → dépend de la politique de redémarrage
150
161. #DevoxxFR
Plusieurs types de Volumes
● emptyDir
● hostPath
● gitRepo
● Secret
● nfs
● iscsi
● flocker
● glusterfs
● Rbd (Ceph)
● gcePersistentDisk
● awsElasticBlockStore
● azureFileVolume
● persistentVolumeClaim
Sur le Node
Non persistent
161
162. #DevoxxFR
Plusieurs types de Volumes
● emptyDir
● hostPath
● gitRepo
● Secret
● nfs
● iscsi
● flocker
● glusterfs
● Rbd (Ceph)
● gcePersistentDisk
● awsElasticBlockStore
● azureFileVolume
● persistentVolumeClaim
Sur le Node
Non persistant
Partage Réseau
Persistant
162
163. #DevoxxFR
Plusieurs types de Volumes
● emptyDir
● hostPath
● gitRepo
● Secret
● nfs
● iscsi
● flocker
● glusterfs
● Rbd (Ceph)
● gcePersistentDisk
● awsElasticBlockStore
● azureFileVolume
● persistentVolumeClaim
Sur le Node
Non persistant
Partage Réseau
Persistant
Accès stockage Cloud Provider
Persistant
163
164. #DevoxxFR
Plusieurs types de Volumes
● emptyDir
● hostPath
● gitRepo
● Secret
● nfs
● iscsi
● flocker
● glusterfs
● Rbd (Ceph)
● gcePersistentDisk
● awsElasticBlockStore
● azureFileVolume
● persistentVolumeClaim
Sur le Node
Non persistant
Partage Réseau
Persistant
Accès stockage Cloud Provider
Persistant
Représente une demande d’
espace de stockage
164
165. #DevoxxFR
emptyDir
Répertoire créé sur le host et alloué au conteneur
Survit au crash du conteneur
Peut être associé à de la RAM
Supprimé lors de l’arrêt/déplacement du Pod
A utiliser typiquement comme espace de travail temporaire
165
167. #DevoxxFR
emptyDir
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-storage
mountPath: /data/redis
volumes:
- name: redis-storage
emptyDir: {}
La déclaration
du volume
Montage du
volume dans le
conteneur
167
168. #DevoxxFR
hostPath
Accès à un répertoire spécifique du Node
Suppose que tous les Nodes ont la même arborescence
En général utilisation déconseillée sauf si vous savez ce que
vous faites
168
169. #DevoxxFR
Secret
- Permettent de stocker des informations sensibles:
- Mot de passe
- Clés SSH
- Information d’authentification
- …
- Stockés en clair dans Etcd
- Ne sont pas cryptés
- Ne sont pas stockés sur les noeuds
169
171. #DevoxxFR
Secret
171
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MWYyZDFlMmU2N2RmCg==
username: YWRtaW4K
apiVersion: v1
kind: Pod
metadata:
name: mysql
labels:
name: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
volumeMounts:
- name: mysql-secret
mountPath: /etc/mysql
reaOnly: true
volumes:
- name: mysql-secret
secret:
secretName: mysecret
Récupération comme
un Volume
172. #DevoxxFR
Secret
172
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MWYyZDFlMmU2N2RmCg==
username: YWRtaW4K
apiVersion: v1
kind: Pod
metadata:
name: mysql
labels:
name: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
Récupération dans des
variables d’environnement
173. #DevoxxFR
nfs
Permet de monter un partage NFS
Pour pré-charger des données utilisées par le Pod
Pour persister les données au delà de la vie du Pod
173
188. #DevoxxFR
Le Persistent Volume passe
à l’état “released”
nfs-pv
NFSStockage Réseau:
Persistent Volume:
node (Worker) Releasing
188
189. #DevoxxFR
La “reclaim policy” utilisée lors de la création du PV
indique la strategie de remise dans le pool:
Retain : opération manuelle
Recycle : nettoyage auto (rm -rf /thevolume/*)
nfs-pv
NFSStockage Réseau:
Persistent Volume:
node (Worker) Reclaiming
189
206. #DevoxxFR
• Par défaut : “n’importe où dans le cluster”
• Il est possible d’orienter le scheduler avec l’
attribut
• nodeSelector + l’utilisation des labels
206
211. #DevoxxFR
Jobs
- Lance un ou plusieurs Pods et renvoie le résultat
(success, fail) d’exécution de ceux-ci
- Il nettoie ensuite les Pods et garde en mémoire une
trace des exécutions
211
217. #DevoxxFR
Bi-Sam
- Solution BI à destination des fonds d’investissements
- Hébergée chez RackSpace (Openstack)
- Base de données Oracle → Cloud hybride
- Besoin
- Haute disponibilité
- Cloisonnement entre les clients
- Scaling rapide
217