Kubernetes University - Cap sur l'orchestration
0 j'aime52 vues
Cette présentation aborde l'orchestration avec Kubernetes, en expliquant son succès par rapport à d'autres solutions. Elle détaille les composants de Kubernetes, le rôle des pods, et les différents types de services disponibles pour assurer la communication entre conteneurs. En soulignant les avantages de Kubernetes, comme son écosystème établi et sa compatibilité, la présentation en fait un choix privilégié pour la gestion de conteneurs.
![#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](https://image.slidesharecdn.com/kubernetescapsurorchestration-160426101139-160502113352/85/Kubernetes-University-Cap-sur-l-orchestration-106-320.jpg)
Kubernetes University - Cap sur l'orchestration
- 1. #DevoxxFR Kubernetes University Cap sur l’orchestration ! Cédric Hauber @cedboss Gérôme Egron @geromeegron Jean-Baptiste Claramonte @jbclaramonte 1
- 2. #DevoxxFR 2
- 8. #DevoxxFR Echangeons ! jobs@wescale.fr blog.wescale.fr 8 Cloud Designer Cloud Builder Cloud Runner
- 10. #DevoxxFR Il y a eu du changement 10
- 11. #DevoxxFR Product Backlog Tâches du sprint Planification de sprint Revue de sprint Sprint 2 à 4 semaines Produit enrichi Les équipes sont devenues agiles 11
- 12. #DevoxxFR Backend DB Frontend Les architectures micro-services se sont répandues 12
- 13. #DevoxxFR Backend DB Frontend Gateway DB Frontend Module 1 Module 2 Module 3 Les architectures micro-services se sont répandues 13
- 14. #DevoxxFR Agilité Augmentation du nombre de livraisons Micro- service Augmentation du nombre de modules à livrer 14
- 17. #DevoxxFR Et Docker est arrivé 17
- 18. #DevoxxFR VM vs conteneurs Guest OS Bins /Libs App #1 Hyperviseur Host OS Server Guest OS Bins /Libs App #1 Guest OS Bins /Libs App #1 Bins /Libs App #1 Host OS Server Bins /Libs App #1 Bins /Libs App #1 Docker engine VM Container 18
- 19. #DevoxxFR Raison de son succès 19
- 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
- 23. #DevoxxFR Application découpée en plusieurs conteneurs Application Rethink db 23
- 24. #DevoxxFR En local ● Partage du réseau hôte ● Utilisation de l’option Link de Docker ● Utilisation de l’API X-Networking 24
- 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
- 28. Orchestrateur 28
- 29. #DevoxxFR - Fleet - Swarm - Cattle (Rancher) - Mesos - Kubernetes Lequel choisir ? 29
- 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
- 39. #DevoxxFR 39
- 40. #DevoxxFR node (physical or virtual machine) cluster node (physical or virtual machine) node (physical or virtual machine) node (physical or virtual machine) node (physical or virtual machine) node (physical or virtual machine) 40
- 41. #DevoxxFR node (physical or virtual machine) cluster Master node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker 41
- 45. #DevoxxFR Etcd ● Développé par CoreOs ● BDD Clé/Valeur distribuée ● Stocke l’état du cluster Kubernetes 45
- 46. #DevoxxFR API-Server ● Point d’interface avec le cluster ○ CLI: kubectl ○ REST API ● Stateless ○ Utilise etcd comme stockage 46
- 47. #DevoxxFR API-Server API-Server SchedulerController-Manager kubectl / http client node (Master) node (Worker) 47
- 48. #DevoxxFR Scheduler ● Vision globale des ressources du cluster ● Distribue les conteneurs d’applications dans le cluster 48
- 49. #DevoxxFR Scheduler API-Server SchedulerController-Manager node (Master) node (Worker) Pod 49
- 50. #DevoxxFR Controller-Manager ● C’est la boucle de contrôle pour toutes les ressources Kubernetes ● Assure l’état du cluster 50
- 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
- 53. #DevoxxFR Kubelet API-Server Kubelet Kube-Proxy node (Master) node (Worker) Pod 53
- 54. #DevoxxFR Kube-Proxy ● Observe l’ajout/suppression de Services et Endpoints ● Met à jour iptables 54
- 55. #DevoxxFR API-Server Kubelet Kube-Proxy node (Master) node (Worker) watch Kube-Proxy 55
- 57. #DevoxxFR Pod 57
- 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
- 59. #DevoxxFR IP node Worker kubernetes binaries Virtual IP Pod Virtual IP Pod 59
- 62. #DevoxxFR Labels • Pairs clé/valeur • Attachable à tous les éléments de kubernetes • Donner du sens aux objets de kubernetes 62
- 63. #DevoxxFR node node node node node node disk: ssddisk: ssd disk: ssd gpu: true disk: ssd gpu: true disk: ssd 63
- 64. #DevoxxFR node Worker Pod Pod role: database role: webfront fwk: angular2 pods can have labels 64
- 65. #DevoxxFR kubectl get pods -l release=stable, tier=frontend kubectl get pods -l release in stable, tier in (frontend)’ kubectl get pods -l release in (stable, canary)’ kubectl get pods -l ‘release notin (stable) Requêtage évolué 65
- 67. #DevoxxFR node Worker Pod role: database selector Replication controller template replicas: 2 Pod role: database 67
- 68. #DevoxxFR node Worker Pod role: database selector Replication controller template replicas: 2 Pod role: database 68
- 69. #DevoxxFR node Worker Pod role: database selector Replication controller template replicas: 2 69
- 70. #DevoxxFR node Worker Pod role: database selector Replication controller template replicas: 2 Pod role: database 70
- 71. #DevoxxFR node Worker Pod role: database selector Replication controller template replicas: 2 Pod role: database 71
- 75. #DevoxxFR node Worker Pod Load balancing Service role: database Pod role: database 75 node Worker node Worker Pod role: application
- 77. #DevoxxFR 77 node Worker Pod Service rethinkdbdb: rethinkdb role: replica node Worker Service todo-app Pod app: todo
- 79. #DevoxxFR Plusieurs solutions 79 - Google Compute Advanced Routing - Flannel - OpenVSwitch - Weave - Calico - Romana
- 80. #DevoxxFR node (physical or virtual machine) Master node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker 80
- 81. #DevoxxFR node (physical or virtual machine) Flannel Master node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker node (physical or virtual machine) Worker 81
- 82. #DevoxxFR Pod 82
- 87. #DevoxxFR Pod rethinkdb1 Pod app2 Pod rethinkdb2 Pod app1 10.2.1.2 10.2.1.5 10.2.2.3 10.2.2.2 Docker 10.2.1.1/24 Flannel 10.2.1.0/16 Docker 10.2.2.1/24 Flannel 10.2.2.0/16 Ethernet 192.168.0.100 Ethernet 192.168.0.100 MAC Node IP Container / Pod IP Packet Packet Flannel 87
- 88. #DevoxxFR Pod rethinkdb1 Pod app2 Pod rethinkdb2 Pod app1 10.2.1.2 10.2.1.5 10.2.2.3 10.2.2.2 Docker 10.2.1.1/24 Flannel 10.2.1.0/16 Docker 10.2.2.1/24 Flannel 10.2.2.0/16 Ethernet 192.168.0.100 Ethernet 192.168.0.100 MAC Node IP Container / Pod IP Packet Packet Flannel 88
- 89. #DevoxxFR Pod rethinkdb1 Pod app2 Pod rethinkdb2 Pod app1 10.2.1.2 10.2.1.5 10.2.2.3 10.2.2.2 Docker 10.2.1.1/24 Flannel 10.2.1.0/16 Docker 10.2.2.1/24 Flannel 10.2.2.0/16 Ethernet 192.168.0.100 Ethernet 192.168.0.100 MAC Node IP Container / Pod IP Packet Packet Flannel 89
- 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
- 95. #DevoxxFR Différents types de Service • ClusterIP • NodePort • LoadBalancer 95
- 96. #DevoxxFR ClusterIP • Par défaut • IP Uniquement accessible depuis le cluster • Virtual IP 96
- 97. #DevoxxFR node Worker Virt IP Pod my- app node Worker IPIP 97
- 98. #DevoxxFR node Worker Virt IP Pod my- app node Worker IPIP Pod another-app 98
- 99. #DevoxxFR node Worker Virt IP Pod my- app node Worker IPIP Pod another-app 99
- 100. #DevoxxFR node Worker Virt IP Pod my- app Virt IPService my-app node Worker IPIP 100
- 101. #DevoxxFR node Worker Virt IP Pod my- app Virt IPService my-app node Worker IPIP Pod another-app 101
- 102. #DevoxxFR node Worker Virt IP Pod my- app Virt IPService my-app node Worker IPIP Pod another-app 102
- 104. #DevoxxFR Accès via DNS • Utilise le addon Kubernetes “SkyDNS” <service-name>.<namespace>.svc.cluster.local Ou tout simplement <service-name> 104
- 105. #DevoxxFR Démo 105
- 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
- 107. #DevoxxFR node Worker Pod my- app Service my-app node WorkerLabel selector 107
- 108. #DevoxxFR node Worker Pod my- app Service my-app node Worker IP:<NodePort>IP:<NodePort> Label selector 108
- 109. #DevoxxFR node Worker Pod my- app Service my-app node Worker IP:<NodePort>IP:<NodePort> Label selector 109
- 110. #DevoxxFR node Worker Pod my- app Service my-app node Worker IP:<NodePort>IP:<NodePort> Label selector 110
- 111. #DevoxxFR node Worker Pod my- app Service my-app node Worker IP:<NodePort>IP:<NodePort> Label selector 111
- 112. #DevoxxFR node Worker Pod my- app Service my-app node Worker IP:<NodePort>IP:<NodePort> Label selector 112
- 113. #DevoxxFR Différences ClusterIP / NodePort # type=NodePort Name: my-app-node-port Namespace: default Labels: run=my-app Selector: run=my-app Type: NodePort IP: 10.0.0.246 Port: <unset> 80/TCP NodePort: <unset> 30084/TCP Endpoints: 172.17.0.2:80 Session Affinity: None # type=ClusterIP Name: my-app Namespace: default Labels: run=my-app Selector: run=my-app Type: ClusterIP IP: 10.0.0.242 Port: <unset> 80/TCP Endpoints: 172.17.0.2:80 Session Affinity: None 113
- 114. #DevoxxFR Service load balancer • Fonctionne uniquement pour certains Cloud Providers • GCP • AWS • RackSpace • OpenStack 114
- 115. #DevoxxFR nodeWorker Pod my- app Cluster kubernetes Cloud provider nodeWorker Pod my- app nodeWorker Pod my- app Load balancer 115
- 116. #DevoxxFR Démo 116
- 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
- 119. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.1 119
- 120. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.1 Pod v.2 120
- 121. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.2 121
- 122. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 Pod v.2 node Worker Pod v.2 122
- 123. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.2 node Worker Pod v.2 123
- 124. #DevoxxFR node Worker Pod v.1 Replica Set Pod v.2 Replica Set node Worker Pod v.2 node Worker Pod v.2 124
- 125. #DevoxxFR node Worker Replica Set Pod v.2 Replica Set node Worker Pod v.2 node Worker Pod v.2 125
- 126. #DevoxxFR node Worker Pod v.2 Replica Set node Worker Pod v.2 node Worker Pod v.2 126
- 127. #DevoxxFR Démo 127
- 128. #DevoxxFR A/B Deployment ● Nous déployons une nouvelle version de l’application ● Une fois testée, nous redirigons le trafic sur celle-ci 128
- 129. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.1 Service app: todo version: v1 app: todo version: v1 app: todo version: v1 app: todo version: v1 129
- 130. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.1 Pod v.2 Service app: todo version: v1 app: todo version: v1 app: todo version: v1 app: todo version: v1 app: todo version: v2 130
- 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
- 135. #DevoxxFR Démo 135
- 136. #DevoxxFR Replace ● L’ancienne version de l’application est supprimée ● La nouvelle version nest déployée 136
- 137. #DevoxxFR node Worker Pod v.1 Replica Set Replica Set node Worker Pod v.1 node Worker Pod v.1 Service app: todo version: v1 app: todo version: v1 app: todo version: v1 app: todo version: v1 137
- 138. #DevoxxFR node Worker Replica Set node Worker node Worker Pod v.2 Service app: todo version: v2 app: todo version: v2 138
- 139. #DevoxxFR node Worker Replica Set node Worker node Worker Pod v.2Pod v.2 Service app: todo version: v2 app: todo version: v2 app: todo version: v2 139
- 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
- 141. #DevoxxFR Démo 141
- 144. #DevoxxFR Cycle de vie Pending Running 144
- 145. #DevoxxFR Cycle de vie Pending Running Failed Succeeded 145
- 146. #DevoxxFR Cycle de vie Pending Running Failed Succeeded Unknown 146
- 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
- 148. #DevoxxFR Handlers disponibles - HTTP Health checks - Container exec - TCP Socket 148
- 149. #DevoxxFR Résultats possibles - Success - Failure - Unknown 149
- 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
- 151. #DevoxxFR Politique de redémarrage - Always - On failure - Never 151
- 152. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 152 running Conteneur Restart policy : never
- 153. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 153 running Conteneur Restart policy : never
- 154. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 154 failed Conteneur Restart policy : never
- 155. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 155 running Conteneur Restart policy : Always ou onFailure
- 156. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 156 running Conteneur Restart policy : Always ou onFailure
- 157. #DevoxxFR node (Worker) Kube-ProxyKubelet Docker Pod 157 running Conteneur Restart policy : Always ou onFailure
- 159. #DevoxxFR Le problème Les Pods sont éphémères Quand ils disparaissent leurs données disparaissent également 159
- 160. #DevoxxFR La Solution Les Volumes Un Volume permet de créer un point de montage dans le conteneur d’un pod 160
- 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
- 166. #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 166
- 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
- 170. #DevoxxFR Secret $ echo "1f2d1e2e67df" | base64 MWYyZDFlMmU2N2RmCg== $ echo "admin" | base64 YWRtaW4K 170 apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: password: MWYyZDFlMmU2N2RmCg== username: YWRtaW4K
- 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
- 174. #DevoxxFR nfs apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis volumeMounts: - name: nfs-redis-storage mountPath: /data/redis volumes: - name: nfs-redis-storage nfs: 192.168.10.3 path: /export/redis La déclaration du volume nfs 174
- 175. #DevoxxFR nfs apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis volumeMounts: - name: nfs-redis-storage mountPath: /data/redis volumes: - name: nfs-redis-storage nfs: 192.168.10.3 path: /exports/redis La déclaration du volume Montage du volume dans le conteneur 175
- 176. #DevoxxFR Plusieurs types de Volumes ● emptyDir ● hostPath ● gitRepo ● Secret ● nfs ● iscsi ● flocker ● glusterfs ● Rbd (Ceph) ● gcePersistentDisk ● awsElasticBlockStore ● azureFileVolume ● persistentVolumeClaim Celui-ci est particulier ! 176
- 177. #DevoxxFR persistentVolumeClaim Permet une abstraction du type de volume utilisé Sépare l’offre et la demande d’utilisation d’espace de stockage 177
- 178. #DevoxxFR 1. L’admin créee un PV nfs-pv NFSStockage Réseau: Persistent Volume: Provisionning 178
- 179. #DevoxxFR nfs-pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" Provisioning par l’admin du cluster de 1 Go 179
- 180. #DevoxxFR nfs-pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" Le PV autorise ici la lecture et l’écriture par un seul container 180
- 181. #DevoxxFR nfs-pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" Possible aussi: ● ReadOnlyMany ● ReadWriteMany 181
- 182. #DevoxxFR my-redis-persistence-volume-claim2. Le Dev “claims” des PV nfs-pv NFSStockage Réseau: Persistent Volume: Binding 182
- 183. #DevoxxFR apiVersion: v1 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: my-redis-persistence-volume-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi my-redis-persistence-volume-claim.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" Binding par un développeur ReadWriteOnce ReadOnlyMany ReadWriteMany 183
- 184. #DevoxxFR my-redis-persistence-volume-claim 3. Le Dev utilise le claim dans un pod nfs-pv NFSStockage Réseau: Persistent Volume: Pod db node (Worker) Using 184
- 185. #DevoxxFR apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis volumeMounts: - name: my-redis-persistence-volume mountPath: "/data/redis volumes: - name: my-redis-persistence-volume persistentVolumeClaim: claimName: my-redis-persistence-volume-claim apiVersion: v1 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: my-redis-persistence-volume- claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi my-redis-pod.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" 185
- 186. #DevoxxFR apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis volumeMounts: - name: my-redis-persistence-volume mountPath: "/data/redis volumes: - name: my-redis-persistence-volume persistentVolumeClaim: claimName: my-redis-persistence-volume-claim apiVersion: v1 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: my-redis-persistence-volume- claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi my-redis-pod.yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 10.20.23.43 path: "/some/path" Montage 186
- 187. #DevoxxFR my-redis-persistence-volume-claim 4. Le Dev supprime le Pod et le PVC nfs-pv NFSStockage Réseau: Persistent Volume: Releasing Pod db node (Worker) 187
- 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
- 190. #DevoxxFR PV concernés ● GCEPersistentDisk ● AWSElasticBlockStore ● NFS ● iSCSI ● RBD (Ceph Block Device) ● Glusterfs ● HostPath 190
- 192. #DevoxxFR A quoi ça sert ? Différents environnements Cloisonnement 192
- 193. #DevoxxFR nodePod nodePod node PodPodPod Node 1 Node 2 Node 3 Namespace A Namespace B 193
- 194. #DevoxxFR nodePod nodePod node PodPodPod Node 1 Node 2 Node 3 Namespace A Namespace B 194
- 195. #DevoxxFR nodePod nodePod node PodPodPod Node 1 Node 2 Node 3 Namespace A Namespace B 195
- 196. #DevoxxFR nodePod nodePod node PodPodPod Node 1 Node 2 Node 3 Namespace A Namespace B 196
- 197. #DevoxxFR Démo 197
- 198. #DevoxxFR D’autres possibilités de Kubernetes 198
- 199. #DevoxxFR Limiter l’utilisation des ressources par un Pod 199
- 200. #DevoxxFR Limitations Limitation du CPU Limitation de la mémoire Configuration par conteneur 200
- 201. #DevoxxFR resources apiVersion: v1 kind: Pod metadata: labels: run: my-nginx name: my-nginx namespace: default spec: containers: - image: nginx name: my-nginx resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" ports: - containerPort: 80 protocol: TCP 201
- 203. #DevoxxFR Horizontal scaling Ajuste automatiquement le nombre de réplicas pour satisfaire la demande Utilise l’utilisation de CPU comme mesure pour déterminer le nombre de réplicas nécessaires 203
- 205. #DevoxxFR Stratégie de placement des pods 205
- 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
- 207. #DevoxxFR apiVersion: v1 kind: Pod metadata: labels: run: my-nginx name: my-nginx namespace: default spec: containers: - image: nginx name: my-nginx ports: - containerPort: 80 protocol: TCP nodeSelector: disktype: ssd nodeSelector 207
- 209. #DevoxxFR Daemon Sets - S’assure que tous les nodes exécute un Pod définit en tant que template - Très utile pour des services de supervision 209
- 210. #DevoxxFR Jobs 210
- 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
- 212. #DevoxxFR Je veux tester ! Kubernetes.io kmachine Google Container Engine Open Shift v3 212
- 214. #DevoxxFR 3 règles 214 - Un cluster Etcd - Volume durable - Un master par zone
- 215. #DevoxxFR 215 node Master Zone A node Worker node Master Zone B node Worker node Master Zone C node Worker podmaster podmaster podmaster
- 216. #DevoxxFR Kubernetes dans la vraie vie ? 216
- 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
- 218. #DevoxxFR Episode I Docker, en avant toute ! 218
- 219. #DevoxxFR Episode II CoreOS, Fleet, Etcd → Mes conteneurs tu protègeras 219
- 220. #DevoxxFR Episode III Par l’orchestration du vainqueras 220
- 221. #DevoxxFR Episode IV À mon environnement tu t’adapteras 221
- 222. #DevoxxFR Episode V Des statistiques et des logs tu m’ enseigneras 222
- 223. #DevoxxFR Episode VI À la production tu survivras 223
- 225. #DevoxxFR 225
- 226. #DevoxxFR
- 229. #DevoxxFR Merci 229