kubernetes, pourquoi et comment
•
14 j'aime•4,912 vues
Docker nous permet de déployer nos applications dans des conteneurs. Du coup notre infrastructure se retrouve divisée dans différents conteneurs, un pour la base de données, un pour le front, un pour le backend. Voir même une division en services lorsque l’on est dans une approche micro-services. Mais comment faire communiquer ces différents conteneurs? Comment orchestrer un cluster de conteneurs? Kubernetes est une réponse à ces questions.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à kubernetes, pourquoi et comment
Similaire à kubernetes, pourquoi et comment (20)
kubernetes, pourquoi et comment
- 2. Qui sommes nous ? 2 @geromeegron@jbclaramonte
- 3. Agenda Pourquoi ? Orchestration, scheduler, cluster management … Comment ? Concepts Spécificités Cas Pratique 3
- 5. 5 Cela reste intuitif Containers sur une machine Apache Tomcat Postgres
- 6. 6 Mais quand on passe à plusieurs serveurs on comprend vite qu’il faut un outil pour pouvoir garder le contrôle Containers sur plusieurs machines Apache Tomcat Tomcat Postgres Redis Tomcat Redis
- 7. Et si ...
- 8. … un container s’arrête … ?
- 9. … on veut scaler facilement … ?
- 10. Comment nos applications connaissent les endpoints des services appellés ?
- 11. Comment se passe la persistance des données de certains de mes containers
- 12. 12 En fait ...
- 13. 13 Vous avez besoin d’un … Orchestrateur (de containers)
- 18. 18 Cluster Management Cluster Manager AA j’ai un nouveau serveur dans mon cluster
- 21. 21 Deploy
- 24. 24 Scale
- 27. 27 Health check
- 31. Monolithic un cluster manager + un scheduler Google Borg 31 Two Level un cluster manager + plusieurs scheduler Mesos Marathon Shared State plusieurs schedulers ” autonomes” Omega, Kubernetes
- 33. 33 2004 : Google Borg 2006 : Google release les cgroups dans linux 2009 ? : Google Omega 2011 : Mesos 2014 : Google “open source” Kubernetes 2015 : Kubernetes V1.0
- 34. 34
- 38. 38 Pod ● Plus petite unité logique du cluster ● Englobe un ou plusieurs conteneur(s) partageant un même contexte (adresse IP, volumes) ● Unité pouvant être répliquée ● Lié à un node ● Existence temporaire
- 39. Replication controller ● Superviseur des pods à travers le cluster ● Se base sur un template de pod ● Son rôle est de s’assurer qu’un certain nombre de pods sont actuellement en vie ● Ce n’est pas un load balancer! 39
- 40. Service ● Point d’accès à un pod ou à un ensemble de pods ● N’est pas lié au Replication Controller ● Load balancer 40 { "kind": "Service", "apiVersion": "v1", "metadata": { "name": "my-service" }, "spec": { "selector": { "app": "MyApp" }, "ports": [ { "protocol": "TCP", "port": 80, "targetPort": 9376 } ] } }
- 41. 41 Service [name=my-service] { selector: MyApp } Pod 1 { label: MyApp } Pod 2 { label: MyApp }
- 42. En résumé ● Node / Master ● Pods ● Replication Controller ● Service 42
- 44. Appel du service intra-cluster $client = new redis_client([ 'scheme' => 'tcp', 'host' => 'my-service', 'port' => 80, ]); 44
- 45. Et de l’extérieur? 45 Lors de la configuration d’un service, un champ type est à configurer: ● cluster IP (par défaut et non accéssible de l’extérieur) ● node port ● load balancer
- 47. Composition du master ● Expose une API REST ● Replication controller ● Scheduler ● etcd ● Node controller 47
- 48. 48 Node controller ● S’occupe de vérifier le statut des nodes ● N’est pas capable de provisionner les nodes ● Ajoute les nodes qui sont configurés au cluster ● Supporte jusqu’à 100 noeuds (objectifs: 1000 pour 2016)
- 49. Configuration d’un node ● Kubelet ● Kube-proxy ● Docker ● Flannel (ou autre surcouche réseau) 49
- 50. Health checking Trois types: ● HTTP Health checks ● Container exec ● TCP Socket 50
- 51. Volume ● Cycle de vie lié à celui du pod le contenant, selon le type ● Un pod peut être lié à plusieurs volumes ● Plusieurs types de volumes sont disponibles: ○ emptyDir ○ gcePersistentDisk ○ awsElasticBlockStore ○ nfs ○ gitRepo ○ secret ○ etc ... 51
- 52. Comment déployer un cluster? ● En local ○ Vagrant ○ Docker ○ Cluster en local ● Solution hôte ○ Google Container Engine ● Solution Cloud ○ GCE ○ AWS ○ Azure ● Autres 52
- 54. Comment déployer mon application ? Nous allons déployer une application constitué de: ● Un master redis ● Deux slaves redis ● Trois frontends accessibles de l’extérieur 54
- 55. 55 Redis Master Redis Slave Frontend Frontend Frontend Load Balancer Redis Slave
- 58. 58 Pod Redis Master Replication Controller Service Redis Master Pod Redis Slave Pod Redis Slave Replication Controller
- 59. 59 Pod Redis Master Replication Controller Service Redis Master Service Redis Slave Pod Redis Slave Pod Redis Slave Replication Controller
- 60. 60 Pod Redis Master Replication Controller Service Redis Master Service Redis Slave Pod Redis Slave Pod Redis Slave Replication Controller Pod Frontend Pod Frontend Pod Frontend Replication Controller
- 61. 61 Pod Redis Master Replication Controller Service Redis Master Service Redis Slave Pod Redis Slave Pod Redis Slave Replication Controller Pod Frontend Pod Frontend Pod Frontend Replication Controller Service Frontend en mode load balancer
- 62. Comment puis-je monitorer mon cluster? 62 Master Node Pod Pod Node Heapster Kubelet Kubelet cAdvisor cAdvisor Storage Backend
- 64. Conclusion ● Un projet stabilisé pour la V1 ● Amélioration de la documentation, mais peut encore mieux faire ● Beaucoup de choses à venir ○ provisionning de node ○ migration de pod ● Cherche à être totalement adaptable 64
- 66. Merci Kubernetes