![kubernetes](kubernetes.svg) L'orchestration de conteneurs grace à **Kubernetes**
Alexandre Buisine [@alexbuisine](https://twitter.com/alexbuisine)
![enix](enix.svg)
# Mais qui suis-je ?
un **dev** (réalité virtuelle)
+ un **ops** (ce qui me fait vibrer)
+ un **manager** (mon CV)
+ un **entrepreneur** (ces dernières années)
=
**entreprenOps ?**
je suis aujourd'hui associé dirigeant chez **Enix**
3 métiers :
**orchestration de conteneurs**
, **virtualisation**
, **réseaux**
3 exemples :
**kubernetes**
, **openstack**
, **arista**
# Roadmap du talk * **docker** et les conteneurs * l'**orchestration** de conteneurs * **kubernetes** * cas **pratique** * **méthodes** et **outils** ![qr code](qr.svg)
# Contexte
Une **application** qui tourne dans un **container**,
lui même sur une **machine virtuelle**,
elle même hébergée sur un **serveur physique**.
On parle même de **serverless**.
![les poupées russes](virtualisation.svg)
# La révolution des conteneurs ![ubiquity](ubiquity.jpg)
# Les conteneurs informatiques ![isolation](isolation.png)
# Docker ![container](container.jpg) une **app** / un **micro-service**
# Les stacks de conteneurs ![stack](stack.png) On combine un **ensemble d'applications** qui fonctionnent ensemble pour former une **stack**.
# Orchestration de stack ![orchestration](orchestration.png)
# Pourquoi Kubernetes ? 1.
Buzz
2.
**Communauté**
3.
**Ecosystème**
Les autres solutions (ex: **Docker swarm**) ont perdu la bataille
# L'écosystème *cloud-native* La [Cloud Native Computing Foundation](https://www.cncf.io/) est une filiale de la [Linux Foundation](https://www.linuxfoundation.org/). The Cloud Native Computing Foundation builds sustainable **ecosystems** and fosters a **community** around a constellation of high-quality projects that **orchestrate** containers as part of a **microservices** architecture.
# Les composants de kubernetes ![control-plane](kubernetes-control-plane.png)
# Les composants avec intégration cloud provider ![control-plane-cloud](kubernetes-control-plane-cloud.png)
# Le language kubernetes
On parle à l'*api-server* avec un **verb** (create, edit, delete, get)
et un **object** :
**Pod**
Service
Volume
Namespace
mais également **Deployment** ReplicaSet StatefulSet DaemonSet Job
et plus encore
avec les **Custom Resource Definition**
# Cette complexité vaut-elle le coup ?
Ca dépend !
En règle générale, les **ops** et **architectes** adorent,
les **devs** pas vraiment.
Les développeurs **profitent** grandement des **conteneurs** et **stack applicatives**, mais c'est moins évident pour l'orchestration.
# kubectl get namespaces ![kubectl](kubectl-ns.png)
# kubectl get pods ![kubectl](kubectl.png)
# kubectl delete pod
# déclaratif vs impératif
On demande à kubernetes un état **cible**, plutôt que de lui donner une **liste d'actions** à mener.
C'est possible et beaucoup plus **puissant** à condition que l'on sache **observer** l'état du système.
Plus de détails [ici](https://vimeo.com/302847894)
# Déclarons donc un Deployment ! ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: bbl-kubernetes-laposte name: bbl-kubernetes-laposte namespace: slides-enix-io spec: selector: matchLabels: app: bbl-kubernetes-laposte template: metadata: labels: app: bbl-kubernetes-laposte spec: containers: - image: docker-registry.enix.io/website/bbl-kubernetes-laposte:master imagePullPolicy: Always name: bbl-kubernetes-laposte imagePullSecrets: - name: bbl-kubernetes-laposte-docker-registry-enix-io ```
# Comment gérer les specs kubernetes *
les charts [Helm](https://helm.sh/)
*
le concept [gitops](https://www.weave.works/technologies/gitops/)
*
CI et CD dans votre [gestionnaire de code](https://about.gitlab.com/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/)
# Cas pratique
*J'ai un talk à faire à La Poste et je décide de faire un site statique*
*Je vais donc me retrouver avec une application **stateless** à orchestrer*
# Cas pratique - Stratégie #1 ![service](service.png)
# Cas pratique - Stratégie #2 ![ingress](ingress.png)
# Cas pratique
![deployment-1](deployment-1.png)
![deployment-2](deployment-2.png)
![deployment](deployment.png)
# Cas pratique Il existe de multiples [façons](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0) de présenter un service !
LoadBalancer
NodePort
ClusterIP
Ingress
# Les outils autour de l'orchestation
Dans un monde ou les pods apparaissent et disparaissent en fonction du vent, il est important d'avoir les **outils adaptés**.
1.
Les **logs** centralisés (ex: [ELK](https://www.elastic.co/elk-stack))
2.
Les **métriques** centralisées (ex: [Prometheus](https://prometheus.io/) et [grafana](https://grafana.com/))
3.
Les **traces** centralisées (ex [Jaeger](https://www.jaegertracing.io))
# Les méthodes *cloud-native*
Livrer des applications **observables** !
*
Une **volumétrie** de **log** modérée et classifiée
*
L'export de **métriques** indiquant les **performances**
# La suite Si vous avez besoin d'un coup de main pensez à nous ! Le code **LAPOSTELOVESKUBE** vous donne droit à **-30%** sur la formation [docker](https://enix.io/fr/services/formation/bien-demarrer-avec-les-conteneurs/) du 15/16 avril et [kubernetes](https://enix.io/fr/services/formation/deployer-ses-applications-avec-kubernetes/) du 23/24 avril. ![qr enix](qr-enix.io.svg)