Translate in french all the doc

content/fr/docs/_index.md

@@ -5,7 +5,7 @@ description: "Tout ce que vous devez savoir sur l'organisation de la documentati
 
 # Bienvenue
 
-Bienvenue dans la documentation de [Helm](https://helm.sh/). Helm est le manageur de paquet pour Kubernetes. Les informations générales détaillées sont disponnibles ici : [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/).
+Bienvenue dans la documentation de [Helm](https://helm.sh/). Helm est le manageur de paquet pour Kubernetes. Les informations générales détaillées sont disponibles ici : [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/).
 
 # Comment la documentation est organisée
 

content/fr/docs/chart_best_practices/_index.md

@@ -0,0 +1,12 @@
+---
+title: "Bonnes Pratiques"
+sidebar: true
+weight: 4
+---
+
+# Le guide des Bonnes Pratiques
+
+Ce guide couvre les bonnes pratiques considérées par l'équipe de Helm, pour créer des charts. Il se concentre sur la manière dont les charts doivent structurés.
+
+
+Nous nous concentrons principalement sur les meilleures pratiques pour les charts qui peuvent être déployés publiquement. Nous savons que de nombreux charts sont destinés à un usage interne uniquement et les auteurs des ces charts peuvent estimer que leurs intérêts internes priment sur nos suggestions ici.

content/fr/docs/chart_best_practices/conventions.md

@@ -0,0 +1,42 @@
+---
+title: "Conventions Générales"
+description: "Conventions générales pour les charts."
+weight: 1
+---
+
+Cette partie du Guide des Bonnes Pratiques présente les conventions générales
+
+## Nommages des Charts
+
+Les noms de charts doivent être constitués de lettres minuscules et de chiffres. Les mots _peuvent_ être séparés par des tirets (-) :
+
+Exemples :
+
+```
+drupal
+nginx-lego
+aws-cluster-autoscaler
+```
+
+Ni les majuscules ni les traits de soulignement ne peuvent être utilisés dans les noms de charts. Les points ne doivent pas être utilisés dans les noms de charts.
+
+## Numérotation de Version
+
+Dans la mesure du possible, Helm utilise [SemVer 2](https://semver.org) pour représenter les numéros de version. (Notez que les tags des images Docker ne suivent pas nécessairement SemVer et et sont donc considérées comme une malheureuse exception à la règle.)
+
+Quand les versions SemVer sont stockées dans les labels Kubernetes, nous remplaçons conventionnellement le caractère `+` par un `_` car les labels n'autorisent pas le signe `+` comme valeur.
+
+## Formatage YAML
+
+Les fichiers YAML doivent être indentés en utilisant _deux espaces_ (et non avec des tabulations).
+
+## Utilisation des mots Helm et Chart
+
+Il existe  plusieurs conventions pour utiliser les mots _Helm_ et _helm_.
+
+- _Helm_ fait référence au projet dans son ensemble
+- `helm` fait référence à la commande côté client
+- Le terme `chart` n'a pas besoin d'être majuscule, car ce n'est pas un nom propre
+- Cependant, `Chart.yaml` doit être en majuscule car le nom du fichier est sensible à la casse
+
+En cas de doute, utilisez _Helm_ (avec un 'H' majuscule).

content/fr/docs/chart_best_practices/custom_resource_definitions.md

@@ -0,0 +1,38 @@
+---
+title: "Définition de Ressource Personalisée"
+description: "Comment gérer la création et l'utilisation de CRDs."
+weight: 7
+---
+
+Cette section du Guide des Bonnes Pratiques traite de la création et de l'utilisation d'objets de Définition de Ressource Personnalisée.
+
+Lorsque vous travaillez avec des Définitions de Ressource Personnalisées (_Custom Resource Definitions, CRDs_), il est important de distinguer deux types différents :
+
+- Il existe une déclaration de CRD. Il s'agit d'un fichier YAML qui a le genre `CustomResourceDefinition`
+- Ensuite, il y a des ressources qui _utilisent_ le CRD. Supposons qu'une CRD définisse `foo.example.com/v1`. Toutes ressource ayant `ApiVersion : example.com/v1` et `kind: foo` est une ressource qui utilise la CRD.
+
+## Installer une déclaration CRD avant d'utiliser la ressource
+
+Helm est optimisé pour charger le plus de ressources possible dans Kubernetes aussi rapidement que possible. Par conception, Kubernetes peut prendre un ensemble complet de manifests et les mettre tous en ligne (c'est ce qu'on appelle la boucle de reconciliation).
+
+Mais il y a une différence avec les CRDs.
+
+Pour une CRD, la déclaration doit être enregistrée avant que des ressources de ce(s) type(s) puissent être utilisées. Ce processus d'enregistrement prend parfois quelques secondes.
+
+### Méthode 1 : Laisse `Helm` le faire pour toi
+
+Avec l'arrivée de Helm 3, nous avons supprimé les anciens hooks `crd-install` au profit d'une méthodologie plus simple. Il existe maintenant un répertoire spécial appelé `crds` que vous pouvez créer dans votre chart pour y placer vos CRDs. Ces CRDs ne sont pas templatisées, mais seront installées par défaut lors de l'exécution de la commande `helm install` pour le chart. Si la CRD existe déjà, elle sera ignorée avec un avertissement. Si vous souhaitez passer l'étape d'installation des CRDs, vous pouvez utiliser l'option `--skip-crds`.
+
+#### Quelques mises en garde (et explications)
+
+Il n'y a pas de support pour la mise à niveau ou la suppression des CRDs avec Helm pour le moment. Il s'agit d'une décision explicite prise après de nombreuses discussions au sein de la communauté en raison du risque de perte de données non intentionnelle. De plus, il n'y a pas encore de consensus au sein de la communauté sur la manière de gérer les CRDs et leur cycle de vie. À mesure que cela évoluera, Helm ajoutera un support pour ces cas d'utilisation.
+
+L'option `--dry-run` des commandes `helm install` et `helm upgrade` n'est pas actuellement supportée pour les CRDs. L'objectif de l'option "Dry Run" est de valider que le résultat du chart fonctionnera réellement s'il est envoyé au serveur. Mais les CRDs sont une modification du comportement du serveur. Helm ne peut pas installer le CRD lors d'un dry run, donc le client de découverte ne connaîtra pas cette Ressource Personnalisée (CR), et la validation échouera. Vous pouvez alternativement déplacer les CRDs dans leur propre chart ou utiliser `helm template` à la place.
+
+Un autre point important à considérer dans la discussion autour du support des CRDs est la manière dont le rendu des templates est géré. Un des inconvénients majeurs de la méthode `crd-install` utilisée dans Helm 2 était l'incapacité de valider correctement les charts en raison de la disponibilité changeante des API (une CRD ajoute en fait une autre API disponible à votre cluster Kubernetes). Si un chart installait une CRD, `helm` n'avait plus un ensemble valide de versions d'API sur lequel se baser. C'est également la raison pour laquelle le support du templating a été supprimé pour les CRDs. Avec la nouvelle méthode d'installation des CRDs via le répertoire `crds`, nous veillons maintenant à ce que `helm` dispose d'informations complètement valides sur l'état actuel du cluster.
+
+### Méthode 2 : Charts séparés
+
+Une autre façon de procéder est de placer la définition du CRD dans un chart, puis de mettre les ressources qui utilisent cette CRD dans _un autre_ chart.
+
+Avec cette méthode, chaque chart doit être installé séparément. Cependant, ce workflow peut être plus utile pour les opérateurs de cluster qui ont un accès admin à un cluster.

content/fr/docs/chart_best_practices/dependencies.md

@@ -0,0 +1,62 @@
+---
+title: "Dépendances"
+description: "Couvre les meilleures pratiques pour les dépendances des Charts."
+weight: 4
+---
+
+Cette section du guide couvre les bonne pratiques pour les `dependencies` déclarées dans `Chart.yaml`.
+
+## Versions
+
+Dans la mesure du possible, utilisez des plages de versions au lieu d’épingler une version exacte. La valeur par défaut suggérée consiste à utiliser une correspondance de version au niveau du correctif :
+
+```yaml
+version: ~1.2.3
+```
+
+Cela correspondra à la version `1.2.3`et tous les correctifs de cette version.  Autrement dit, `~1.2.3` est équivalent à `>= 1.2.3, < 1.3.0`
+
+Pour la syntaxe complète de correspondance de version, veuillez consulter la [documentation semver](https://github.com/Masterminds/semver#checking-version-constraints).
+
+### Versions préliminaires
+
+Les contraintes de version ci-dessus ne correspondront pas aux versions préliminaires. Par exemple, `version: ~1.2.3` correspondra à `version: ~1.2.4` mais pas à `version: ~1.2.3-1`. Ce qui suit permet de faire correspondre à la fois les versions préliminaires et les niveaux de correctifs :
+
+```yaml
+version: ~1.2.3-0
+```
+
+### URL de dépots
+
+Dans la mesure du possible, utilisez des URLs de dépots en `https://`, suivie des URLs en `http://`.
+
+Si le dépôt a été ajouté au fichier d'index des dépôts, le nom du dépôt peut être utilisé comme un alias de l'URL. Utilisez `alias:` ou `@` suivi des noms de dépôt.
+
+Les URLs de type `file://...` sont considérées comme un "cas spécial" pour les charts qui sont assemblés par un pipeline de déploiement fixe.
+
+Lorsque vous utilisez des [plugins de téléchargement]({{< ref "../topics/plugins#plugins-de-téléchargement" >}}), le schéma de l'URL sera spécifique au plugin. Notez qu'un utilisateur du chart devra avoir un plugin prenant en charge le schéma installé pour mettre à jour ou construire la dépendance.
+
+Helm ne peut pas effectuer d'opérations de gestion des dépendances sur la dépendance lorsque le champ `repository` est laissé vide. Dans ce cas, Helm supposera que la dépendance se trouve dans un sous-répertoire du dossier `charts`, avec un nom identique à la propriété `name` de la dépendance.
+
+## Conditions et Tags
+
+Les conditions ou les tags doivent être ajoutés à toutes les dépendances qui _sont optionnelles_.
+
+La forme préférée pour une condition est :
+
+```yaml
+condition: somechart.enabled
+```
+
+Où `somechart` est le nom d'un chart de la dépendance.
+
+Lorsque plusieurs sous-charts (dépendances) fournissent ensemble une fonctionnalité optionnelle ou interchangeable, ces charts devraient partager les mêmes tags.
+
+Par exemple, si à la fois `nginx` et `memcached` fournissent ensemble des optimisations de performance pour l'application principale du chart, et qu'ils doivent tous deux être présents lorsque cette fonctionnalité est activée, alors ils devraient tous les deux avoir une section de tags comme ceci :
+
+```yaml
+tags:
+  - webaccelerator
+```
+
+Cela permet à un utilisateur d'activer ou de désactiver cette fonctionnalité avec un seul tag.

content/fr/docs/chart_best_practices/labels.md

@@ -0,0 +1,36 @@
+---
+title: "Labels et Annotations"
+description: "Couvre les bonnes pratiques pour l'utilisation des labels et des annotations dans votre Chart."
+weight: 5
+---
+
+Cette partie du Guide des Bonnes Pratiques discute des meilleures pratiques pour l'utilisation des labels et des annotations dans votre chart.
+
+## Est-ce un Label ou une Annotation ?
+
+Un élément de métadonnées doit être un label dans les conditions suivantes :
+
+- Il est utilisé par Kubernetes pour identifier cette ressource.
+- Il est utile de l'exposer aux opérateurs pour interroger le système.
+
+Par exemple, nous suggérons d'utiliser `helm.sh/chart: NAME-VERSION` comme label afin que les opérateurs puissent facilement trouver toutes les instances d'un chart particulier à utiliser.
+
+Si un élément de métadonnées n'est pas utilisé pour les requêtes, il doit être défini comme une annotation à la place.
+
+Les hooks de Helm sont toujours des annotations.
+
+## Labels standards
+
+Le tableau suivant définit les labels couramment utilisés dans les charts Helm. Helm ne requiert jamais la présence d'un label particulier. Les labels marqués REC sont recommandés et _devraient_ être placés sur un chart pour une cohérence globale. Ceux marqués OPT sont optionnels. Ils sont idiomatiques ou couramment utilisés, mais ne sont pas souvent indispensables à des fins opérationnelles.
+
+Nom | Statut | Description  
+----- | ------ | ----------  
+`app.kubernetes.io/name` | REC | Ce label doit correspondre au nom de l'application, reflétant l'ensemble de l'application. Habituellement, `{{ template "name" . }}` est utilisé pour cela. Ce label est utilisé par de nombreux manifests Kubernetes et n'est pas spécifique à Helm.  
+`helm.sh/chart` | REC | Ce label doit contenir le nom du chart et la version : `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`.  
+`app.kubernetes.io/managed-by` | REC | Ce label doit toujours être défini sur `{{ .Release.Service }}`. Il permet de trouver tous les éléments gérés par Helm.  
+`app.kubernetes.io/instance` | REC | Ce label doit correspondre à `{{ .Release.Name }}`. Il aide à différencier les différentes instances de la même application.  
+`app.kubernetes.io/version` | OPT | La version de l'application, qui peut être définie sur `{{ .Chart.AppVersion }}`.  
+`app.kubernetes.io/component` | OPT | Ce label est couramment utilisé pour marquer les différents rôles que peuvent jouer les éléments d'une application. Par exemple, `app.kubernetes.io/component: frontend`.  
+`app.kubernetes.io/part-of` | OPT | Utilisé lorsque plusieurs charts ou éléments logiciels sont utilisés ensemble pour créer une application. Par exemple, un logiciel applicatif et une base de données pour produire un site web. Ce label peut être défini pour l'application principale soutenue.
+
+Vous pouvez trouver plus d'informations sur les labels Kubernetes, les prefix en `app.kubernetes.io`, dans la [documentation Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).

content/fr/docs/chart_best_practices/pods.md

@@ -0,0 +1,68 @@
+---
+title: "Pods et PodTemplates"
+description: "Formatage des parties Pod et PodTemplate dans les manifests de Chart."
+weight: 6
+---
+
+Cette partie du Guide des Bonnes Pratiques discute du formatage des sections Pod et PodTemplate dans les manifests de chart.
+
+La liste (non-exhaustive) des ressources suivantes, utilise des PodTemplates :
+
+- Deployment
+- ReplicationController
+- ReplicaSet
+- DaemonSet
+- StatefulSet
+
+## Images
+
+Une image de conteneur devrait utiliser un tag fixe ou le SHA de l'image. Elle ne devrait pas utiliser les tags `latest`, `head`, `canary`, ou d'autres tags conçus pour être "flottants".
+
+
+Les images _peuvent_ être définies dans le fichier `values.yaml` pour faciliter le remplacement des images.
+
+```yaml
+image: {{ .Values.redisImage | quote }}
+```
+
+Une image et un tag _peuvent_ être définie dans le fichier `values.yaml` séparé en deux champs distincts :
+
+```yaml
+image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}"
+```
+
+## ImagePullPolicy
+
+`helm create` définit par défaut la `imagePullPolicy` sur `IfNotPresent` en faisant ce qui suit dans votre `deployment.yaml` :
+
+```yaml
+imagePullPolicy: {{ .Values.image.pullPolicy }}
+```
+
+Et dans le fichier `values.yaml` :
+
+```yaml
+image:
+  pullPolicy: IfNotPresent
+```
+
+De même, Kubernetes définit par défaut la `imagePullPolicy` sur `IfNotPresent` si elle n'est pas du tout définie. Si vous souhaitez une valeur autre que `IfNotPresent`, il vous suffit de mettre à jour la valeur dans `values.yaml` selon vos besoins.
+
+
+## Les PodTemplates devraient déclarer des sélecteurs
+
+Toutes les sections PodTemplate devraient spécifier un sélecteur. Par exemple :
+
+```yaml
+selector:
+  matchLabels:
+      app.kubernetes.io/name: MyName
+template:
+  metadata:
+    labels:
+      app.kubernetes.io/name: MyName
+```
+
+C'est une bonne pratique car cela établit clairement la relation entre le set et le pod.
+
+Mais c'est encore plus important pour des ensembles comme les Deployments. Sans cela, l'_ensemble_ des labels est utilisé pour sélectionner les pods correspondants, et cela peut échouer si vous utilisez des labels qui changent, comme la version ou la date de publication.

content/fr/docs/chart_best_practices/rbac.md

@@ -0,0 +1,70 @@
+---
+title: "Role-Based Access Control"
+description: "Création et formatage des ressources RBAC dans les manifests de Chart."
+weight: 8
+---
+
+Cette partie du Guide des Bonnes Pratiques discute de la création et du formatage des ressources RBAC dans les manifests de chart.
+
+Les ressources RBAC sont :
+
+- ServiceAccount (namespacé)
+- Role (namespacé)
+- ClusterRole
+- RoleBinding (namespacé)
+- ClusterRoleBinding
+
+## Configuration YAML
+
+RBAC and ServiceAccount configuration should happen under separate keys. They
+are separate things. Splitting these two concepts out in the YAML disambiguates
+them and makes this clearer.
+
+```yaml
+rbac:
+  # Précise si les ressources RBAC doivent être créées
+  create: true
+
+serviceAccount:
+  # Précise si un ServiceAccount doit être créé
+  create: true
+  # Le nom du ServiceAccount à utiliser
+  # Si ce n'est pas défini et que la création est activée, un nom est généré en utilisant le nom complet du modèle.
+  name:
+```
+
+Cette structure peut être étendue pour des charts plus complexes qui nécessitent plusieurs ServiceAccounts.
+
+```yaml
+someComponent:
+  serviceAccount:
+    create: true
+    name:
+anotherComponent:
+  serviceAccount:
+    create: true
+    name:
+```
+
+## Les ressources RBAC devraient être créées par défaut 
+
+`rbac.create` devrait être une valeur booléenne contrôlant la création des ressources RBAC. La valeur par défaut devrait être `true`. Les utilisateurs qui souhaitent gérer les contrôles d'accès RBAC eux-mêmes peuvent définir cette valeur sur `false` (voir ci-dessous dans ce cas).
+
+## Utilisation des ressources RBAC
+
+`serviceAccount.name` doit être défini sur le nom du ServiceAccount à utiliser par les ressources contrôlées par les accès créées par le chart. Si `serviceAccount.create` est vrai, alors un ServiceAccount avec ce nom doit être créé. Si le nom n'est pas défini, un nom est généré en utilisant le modèle `fullname`. Si `serviceAccount.create` est faux, le ServiceAccount ne doit pas être créé, mais il doit néanmoins être associé aux mêmes ressources afin que les ressources RBAC créées manuellement qui le référencent fonctionnent correctement. Si `serviceAccount.create` est faux et que le nom n'est pas spécifié, le ServiceAccount par défaut est utilisé.
+
+Le modèle d'aide suivant devrait être utilisé pour le ServiceAccount :
+
+```yaml
+{{/*
+Créer le nom du compte de service à utiliser
+*/}}
+{{- define "mychart.serviceAccountName" -}}
+{{- if .Values.serviceAccount.create -}}
+    {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }}
+{{- else -}}
+    {{ default "default" .Values.serviceAccount.name }}
+{{- end -}}
+{{- end -}}
+```