2021 tuto

tutorial/k8s/overview.md

@@ -9,13 +9,13 @@ spécifications qu'on lui aura demandé.
 
 Ce projet est l'aboutissement de plus d'une dizaine d'années d'expérience de
 gestion de conteneurs applicatifs chez Google (rappelons que c'est eux qui ont
-poussés de nombreuses technologies dans le noyau Linux, notamment les
+poussé de nombreuses technologies dans le noyau Linux, notamment les
 *cgroups*, ...).
 
 Dans Kubernetes, il n'est pas question d'indiquer comment lancer ses
 conteneurs, ni même quels cgroups utiliser. On va fournir à l'orchestrateur des
 informations, des *spécifications* qui vont altérer l'état du cluster. Et c'est
-en cherchant à être constamment dans l'état que l'on lui a décrit, qu'il va
+en cherchant à être constamment dans l'état qu'on lui a décrit, qu'il va
 s'adapter pour répondre aux besoins.
 
 Par exemple, on ne va pas lui expliquer comment lancer des conteneurs ou
@@ -94,7 +94,7 @@ node
 pod
 : un groupe de conteneurs travaillant ensemble. Il s'agit de la ressource que
   l'on déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas
-  être séparés pour travailler sur deux *nodes* différent.
+  être séparés pour travailler sur deux *nodes* différents.
 
 service
 : c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
@@ -128,8 +128,8 @@ compléter ce schéma...
 
 Chaque plugin implémente la [spécification
 CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
-(Container Network Interface). On trouve donc autant de plugin qu'il n'y a de
-besoin en terme de réseau.
+(Container Network Interface). On trouve donc autant de plugin qu'il y a de
+besoins en terme de réseau.
 
 Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
 loisir d'allouer l'adresse IP, d'ajouter les interfaces réseaux adéquates, de