Corrections de @rekcah78

content/fr/docs/tasks/administer-cluster/running-cloud-controller.md

@@ -86,20 +86,20 @@ Le cloud-controller-manager n'implémente aucun des contrôleurs de volume trouv
 Au fur et à mesure de l'évolution de CSI (interface de stockage de conteneur) et de la prise en charge renforcée des plug-ins de volume flexible, le cloud-controller-manager prendra en charge le support nécessaire afin que les clouds puissent pleinement s'intégrer aux volumes.
 Pour en savoir plus sur les plug-ins de volume CSI en dehors des sources de Kubernetes consultez [ceci](https://github.com/kubernetes/features/issues/178).
 
-### Scalability
+### Charge sur les APIs cloud
 
 Dans l'architecture précédente pour les fournisseurs de cloud, nous utilisions des kubelets utilisant un service de métadonnées local pour extraire des informations sur les nœuds.
-Avec cette nouvelle architecture, nous comptons désormais entièrement sur les cloud controler manager pour extraire les informations de tous les nœuds.
+Avec cette nouvelle architecture, nous comptons désormais entièrement sur les cloud-controller-manager pour extraire les informations de tous les nœuds.
 Pour les très grand clusters, vous devez envisager les goulots d'étranglement tels que les besoins en ressources et la limitation de la vitesse des APIs de votre fournisseur cloud.
 
 ### Problème de l'oeuf et de la poule
 
-L'objectif du projet des cloud-controler-manager est de dissocier le développement des fonctionnalités de cloud computing du projet de base Kubernetes.
+L'objectif du projet des cloud-controller-manager est de dissocier le développement des fonctionnalités de cloud computing du projet de base Kubernetes.
 Malheureusement, de nombreux aspects du projet Kubernetes supposent que les fonctionnalités de fournisseur de cloud soient étroitement intégrées au projet.
 Par conséquent, l'adoption de cette nouvelle architecture peut créer plusieurs situations dans lesquelles une demande d'informations auprès d'un fournisseur de cloud est demandée, mais le cloud-controller-manager peut ne pas être en mesure de renvoyer ces informations sans que la demande d'origine soit complète.
 
 La fonctionnalité d’amorçage TLS dans Kubelet en est un bon exemple.
-Actuellement, l’amorçage TLS suppose que Kubelet aie la possibilité de demander au fournisseur de cloud (ou à un service de métadonnées local) tous ses types d’adresses (privé, public, etc.), mais le cloud-controler-manager ne peut pas définir les types d’adresse d’un nœud sans être initialisé dans le système. Ce qui nécessite que le kubelet possède des certificats TLS pour communiquer avec l’apiserver.
+Actuellement, l’amorçage TLS suppose que Kubelet aie la possibilité de demander au fournisseur de cloud (ou à un service de métadonnées local) tous ses types d’adresses (privé, public, etc.), mais le cloud-controller-manager ne peut pas définir les types d’adresse d’un nœud sans être initialisé dans le système. Ce qui nécessite que le kubelet possède des certificats TLS pour communiquer avec l’apiserver.
 
 À mesure que cette initiative évoluera, des modifications seront apportées pour résoudre ces problèmes dans les prochaines versions.