FR localization: replaced {{< codenew ... >}} with {{% codenew ... %}…

…} in all files

content/fr/docs/concepts/cluster-administration/logging.md

@@ -50,7 +50,7 @@ d'évènements avec le flux de sortie standard. Cette démonstration utilise un
 manifeste pour un Pod avec un seul conteneur qui écrit du texte sur le flux
 de sortie standard toutes les secondes.
 
-{{< codenew file="debug/counter-pod.yaml" >}}
+{{% codenew file="debug/counter-pod.yaml" %}}
 
 Pour lancer ce Pod, utilisez la commande suivante :
 
@@ -243,7 +243,7 @@ Un Pod exécute un unique conteneur et ce conteneur écrit dans deux fichiers de
 journaux différents en utilisant deux format différents. Voici le manifeste du
 Pod :
 
-{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
 
 Il serait très désordonné d'avoir des évènements avec des formats différents
 dans le même journal en redirigeant les évènements dans le flux de sortie
@@ -253,8 +253,7 @@ suit un des fichiers et renvoie les évènements sur son propre `stdout`.
 
 Ci-dessous se trouve le manifeste pour un Pod avec deux conteneurs side-car.
 
-{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml"
->}}
+{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
 
 Quand ce Pod s'exécute, chaque journal peut être diffusé séparément en
 utilisant les commandes suivantes :
@@ -323,7 +322,7 @@ Le premier fichier contient un
 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) pour
 configurer fluentd.
 
-{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
 
 {{< note >}}
 La configuration de fluentd est hors du cadre de cet article. Vous trouverez
@@ -335,7 +334,7 @@ Le second fichier est un manifeste pour un Pod avec un conteneur side-car qui
 exécute fluentd. Le Pod monte un volume où fluentd peut récupérer sa
 configuration.
 
-{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
 
 Apres quelques minutes, les évènements apparaîtront dans l'interface de
 Stackdriver.

content/fr/docs/concepts/services-networking/ingress.md

@@ -330,7 +330,7 @@ type: kubernetes.io/tls
 
 Référencer ce secret dans un Ingress indiquera au contrôleur d'Ingress de sécuriser le canal du client au load-balancer à l'aide de TLS. Vous devez vous assurer que le secret TLS que vous avez créé provenait d'un certificat contenant un Common Name (CN), aussi appelé nom de domaine pleinement qualifié (FQDN), pour `https-example.foo.com`.
 
-{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
+{{% codenew file="service/networking/tls-example-ingress.yaml" %}}
 
 
 {{< note >}}

content/fr/docs/concepts/workloads/controllers/deployment.md

@@ -49,7 +49,7 @@ Voici des cas d'utilisation typiques pour les déploiements:
 Voici un exemple de déploiement.
 Il crée un ReplicaSet pour faire apparaître trois pods `nginx`:
 
-{{< codenew file="controllers/nginx-deployment.yaml" >}}
+{{% codenew file="controllers/nginx-deployment.yaml" %}}
 
 Dans cet exemple:
 

content/fr/docs/concepts/workloads/controllers/replicaset.md

@@ -41,7 +41,7 @@ utilisez plutôt un déploiement et définissez votre application dans la sectio
 
 ## Exemple
 
-{{< codenew file="controllers/frontend.yaml" >}}
+{{% codenew file="controllers/frontend.yaml" %}}
 
 Enregistrer ce manifeste dans `frontend.yaml` et le soumettre à un cluster Kubernetes va créer le ReplicaSet défini et les pods qu’il gère.
 
@@ -145,7 +145,7 @@ labels correspondant au sélecteur de l’un de vos ReplicaSets. Car un ReplicaS
 
 Prenez l'exemple précédent de ReplicaSet, ainsi que les pods spécifiés dans le manifeste suivant :
 
-{{< codenew file="pods/pod-rs.yaml" >}}
+{{% codenew file="pods/pod-rs.yaml" %}}
 
 Ces pods n’ayant pas de contrôleur (ni d’objet) en tant que référence propriétaire, ils correspondent au sélecteur de du ReplicaSet frontend, ils seront donc immédiatement acquis par ce ReplicaSet.
 
@@ -291,7 +291,7 @@ Un ReplicaSet peut également être une cible pour
 Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible
 le ReplicaSet que nous avons créé dans l'exemple précédent.
 
-{{< codenew file="controllers/hpa-rs.yaml" >}}
+{{% codenew file="controllers/hpa-rs.yaml" %}}
 
 Enregistrer ce manifeste dans `hpa-rs.yaml` et le soumettre à un cluster Kubernetes devrait
 créer le HPA défini qui scale automatiquement le ReplicaSet cible en fonction de l'utilisation du processeur

content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -95,7 +95,7 @@ Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés `foo:bar`
 
 Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être :
 
-{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
+{{% codenew file="pods/topology-spread-constraints/one-constraint.yaml" %}}
 
 `topologyKey: zone` implique que la distribution uniforme sera uniquement appliquée pour les noeuds ayant le label "zone:&lt;any value&gt;" présent. `whenUnsatisfiable: DoNotSchedule` indique au scheduler de laisser le Pod dans l'état Pending si le Pod entrant ne peut pas satisfaire la contrainte.
 
@@ -133,7 +133,7 @@ Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4
 
 Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds :
 
-{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
+{{% codenew file="pods/topology-spread-constraints/two-constraints.yaml" %}}
 
 Dans ce cas, pour satisfaire la première contrainte, le Pod entrant peut uniquement être placé dans "zoneB" ; alors que pour satisfaire la seconde contrainte, le Pod entrant peut uniquement être placé dans "node4". Le résultat étant l'intersection des résultats des 2 contraintes, l'unique option possible est de placer le Pod entrant dans "node4".
 
@@ -182,7 +182,7 @@ Il existe quelques conventions implicites qu'il est intéressant de noter ici :
 
     et vous savez que "zoneC" doit être exclue. Dans ce cas, vous pouvez écrire le yaml ci-dessous, pour que "mypod" soit placé dans "zoneB" plutôt que dans "zoneC". `spec.nodeSelector` est pris en compte de la même manière.
 
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+    {{% codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" %}}
 
 ### Contraintes par défaut au niveau du cluster
 

content/fr/docs/contribute/style/write-new-topic.md

@@ -108,13 +108,14 @@ Utilisez cette méthode pour inclure des exemples de fichiers YAML lorsque l'éc
 Lors de l'ajout d'un nouveau fichier d'exemple autonome, tel qu'un fichier YAML, placez le code dans l'un des sous-répertoires `<LANG>/examples/` où `<LANG>` est la langue utilisé dans votre page.
 Dans votre fichier, utilisez le shortcode `codenew` :
 
-<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
-
+```none
+{{%/* codenew file="<RELPATH>/my-example-yaml>" */%}}
+```
 où `<RELPATH>` est le chemin vers le fichier à inclure, relatif au répertoire `examples`.
 Le shortcode Hugo suivant fait référence à un fichier YAML situé sur `/content/en/examples/pods/storage/gce-volume.yaml`.
 
 ```none
-{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
+{{%/* codenew file="pods/storage/gce-volume.yaml" */%}}
 ```
 
 {{< note >}}

content/fr/docs/reference/access-authn-authz/rbac.md

@@ -1228,7 +1228,7 @@ comprend des recommandations pour restreindre cet accès dans les clusters exist
 Si vous souhaitez que les nouveaux clusters conservent ce niveau d'accès dans les rôles agrégés,
 vous pouvez créer le ClusterRole suivant :
 
-{{< codenew file="access/endpoints-aggregated.yaml" >}}
+{{% codenew file="access/endpoints-aggregated.yaml" %}}
 
 ## Mise à niveau à partir d'ABAC
 

content/fr/docs/tasks/access-application-cluster/connecting-frontend-backend.md

@@ -33,7 +33,7 @@ Si votre environnement ne prend pas en charge cette fonction, vous pouvez utilis
 Le backend est un simple microservice de salutations.
 Voici le fichier de configuration pour le Deployment backend :
 
-{{< codenew file="service/access/backend-deployment.yaml" >}}
+{{% codenew file="service/access/backend-deployment.yaml" %}}
 
 Créez le Deployment backend :
 
@@ -91,7 +91,7 @@ Un Service utilise des {{< glossary_tooltip text="sélecteurs" term_id="selector
 
 Tout d'abord, explorez le fichier de configuration du Service :
 
-{{< codenew file="service/access/backend-service.yaml" >}}
+{{% codenew file="service/access/backend-service.yaml" %}}
 
 Dans le fichier de configuration, vous pouvez voir que le Service, 
 nommé `hello`, achemine le trafic vers les Pods ayant les labels `app: hello` et `tier: backend`.
@@ -120,16 +120,16 @@ Les Pods du frontend Deployment exécutent une image nginx
 configurée pour acheminer les requêtes vers le Service backend `hello`. 
 Voici le fichier de configuration nginx :
 
-{{< codenew file="service/access/frontend-nginx.conf" >}}
+{{% codenew file="service/access/frontend-nginx.conf" %}}
 
 Comme pour le backend, le frontend dispose d'un Deployment et d'un Service. 
 Une différence importante à noter entre les services backend et frontend est que 
 le Service frontend est configuré avec un `type: LoadBalancer`, ce qui signifie que le Service utilise 
 un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster.
 
-{{< codenew file="service/access/frontend-service.yaml" >}}
+{{% codenew file="service/access/frontend-service.yaml" %}}
 
-{{< codenew file="service/access/frontend-deployment.yaml" >}}
+{{% codenew file="service/access/frontend-deployment.yaml" %}}
 
 Créez le Deployment et le Service frontend :
 

content/fr/docs/tasks/access-application-cluster/service-access-application-cluster.md

@@ -27,7 +27,7 @@ ayant deux instances en cours d'exécution.
 
 Voici le fichier de configuration pour le déploiement de l'application :
 
-{{< codenew file="service/access/hello-application.yaml" >}}
+{{% codenew file="service/access/hello-application.yaml" %}}
 
 1. Exécutez une application Hello World dans votre cluster :
    Créez le déploiement de l'application en utilisant le fichier ci-dessus :

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

@@ -74,7 +74,7 @@ Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouv
 Pour les fournisseurs qui se trouvent déjà dans Kubernetes, vous pouvez exécuter le cloud-controller-manager dans l'arborescence en tant que Daemonset dans votre cluster.
 Utilisez ce qui suit comme guide:
 
-{{< codenew file="admin/cloud/ccm-example.yaml" >}}
+{{% codenew file="admin/cloud/ccm-example.yaml" %}}
 
 ## Limitations
 

content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md

@@ -64,7 +64,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de CPU
 
 Dans cet exercice, vous allez créer un Pod qui a un seul conteneur. Le conteneur a une demande de 0.5 CPU et une limite de 1 CPU. Voici le fichier de configuration du Pod :
 
-{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
+{{% codenew file="pods/resource/cpu-request-limit.yaml" %}}
 
 La section `args` du fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre. L'argument `-cpus "2"` demande au conteneur d'utiliser 2 CPUs.
 
@@ -147,7 +147,7 @@ L'ordonnancement des pods est basé sur les demandes. Un Pod est prévu pour se
 Dans cet exercice, vous allez créer un Pod qui a une demande de CPU si importante qu'elle dépassera la capacité de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod
 qui a un seul conteneur. Le conteneur nécessite 100 CPU, ce qui est susceptible de dépasser la capacité de tous les nœuds de votre cluster.
 
-{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
+{{% codenew file="pods/resource/cpu-request-limit-2.yaml" %}}
 
 Créez le Pod :
 

content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md

@@ -60,7 +60,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de mé
 Dans cet exercice, vous créez un pod qui possède un seul conteneur. Le conteneur dispose d'une demande de mémoire de 100 MiB et une limite de mémoire de 200 MiB. Voici le fichier de configuration
 pour le Pod :
 
-{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit.yaml" %}}
 
 La section `args` de votre fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre.
 Les arguments `"--vm-bytes", "150M"` indiquent au conteneur d'allouer 150 MiB de mémoire.
@@ -123,7 +123,7 @@ Si un conteneur terminé peut être redémarré, le kubelet le redémarre, comme
 Dans cet exercice, vous créez un Pod qui tente d'allouer plus de mémoire que sa limite.
 Voici le fichier de configuration d'un Pod qui contient un conteneur avec une demande de mémoire de 50 MiB et une limite de mémoire de 100 MiB :
 
-{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit-2.yaml" %}}
 
 Dans la section `args` du fichier de configuration, vous pouvez voir que le conteneur
 tentera d'allouer 250 MiB de mémoire, ce qui est bien au-dessus de la limite de 100 MiB.
@@ -226,7 +226,7 @@ L'ordonnancement des modules est basé sur les demandes. Un Pod est schedulé po
 
 Dans cet exercice, vous allez créer un Pod dont la demande de mémoire est si importante qu'elle dépasse la capacité de la mémoire de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod qui possède un seul conteneur avec une demande de 1000 GiB de mémoire, qui dépasse probablement la capacité de tous les nœuds de votre cluster.
 
-{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
+{{% codenew file="pods/resource/memory-request-limit-3.yaml" %}}
 
 Créez le Pod :
 

content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md

@@ -62,7 +62,7 @@ Cette page montre comment assigner un Pod à un nœud particulier dans un cluste
 
 Le fichier de configuration de pod décrit un pod qui possède un selector de nœud de type `disktype:ssd`. Cela signifie que le pod sera planifié sur un nœud ayant le label `disktype=ssd`.
 
-{{< codenew file="pods/pod-nginx.yaml" >}}
+{{% codenew file="pods/pod-nginx.yaml" %}}
 
 1. Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur votre nœud choisi :
 
@@ -86,7 +86,7 @@ Le fichier de configuration de pod décrit un pod qui possède un selector de n
 
 Vous pouvez également ordonnancer un pod sur un nœud spécifique via le paramètre `nodeName`.
 
-{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
+{{% codenew file="pods/pod-nginx-specific-node.yaml" %}}
 
 Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur `foo-node` uniquement.
 

content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -29,7 +29,7 @@ De nombreuses applications fonctionnant pour des longues périodes finissent par
 
 Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image  `registry.k8s.io/busybox`. Voici le fichier de configuration pour le Pod :
 
-{{< codenew file="pods/probe/exec-liveness.yaml" >}}
+{{% codenew file="pods/probe/exec-liveness.yaml" %}}
 
 Dans le fichier de configuration, vous constatez que le Pod a un seul conteneur.
 Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liveness toutes les 5 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 5 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet exécute la commande `cat /tmp/healthy` dans le conteneur. Si la commande réussit, elle renvoie 0, et le Kubelet considère que le conteneur est vivant et en bonne santé. Si la commande renvoie une valeur non nulle, le Kubelet tue le conteneur et le redémarre.
@@ -104,7 +104,7 @@ liveness-exec   1/1       Running   1          1m
 Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
 d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/liveness`.
 
-{{< codenew file="pods/probe/http-liveness.yaml" >}}
+{{% codenew file="pods/probe/http-liveness.yaml" %}}
 
 Dans le fichier de configuration, vous pouvez voir que le Pod a un seul conteneur.
 Le champ `periodSeconds` spécifie que le Kubelet doit effectuer une liveness probe toutes les 3 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 3 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet envoie une requête HTTP GET au serveur qui s'exécute dans le conteneur et écoute sur le port 8080. Si le handler du chemin `/healthz` du serveur renvoie un code de succès, le Kubelet considère que le conteneur est vivant et en bonne santé. Si le handler renvoie un code d'erreur, le Kubelet tue le conteneur et le redémarre.
@@ -152,7 +152,7 @@ Dans les versions postérieures à la v1.13, les paramètres de la variable d'en
 Un troisième type de liveness probe utilise un TCP Socket. Avec cette configuration, le Kubelet tentera d'ouvrir un socket vers votre conteneur sur le port spécifié.
 S'il arrive à établir une connexion, le conteneur est considéré comme étant en bonne santé, s'il n'y arrive pas, c'est un échec.
 
-{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
+{{% codenew file="pods/probe/tcp-liveness-readiness.yaml" %}}
 
 Comme vous le voyez, la configuration pour un check TCP est assez similaire à un check HTTP.
 Cet exemple utilise à la fois des readiness et liveness probes. Le Kubelet transmettra la première readiness probe 5 secondes après le démarrage du conteneur. Il tentera de se connecter au conteneur `goproxy` sur le port 8080. Si la probe réussit, le conteneur sera marqué comme prêt. Kubelet continuera à effectuer ce check tous les 10 secondes.

content/fr/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

@@ -75,7 +75,7 @@ pour paramétrer du
 [provisioning dynamique](/docs/concepts/storage/dynamic-provisioning/).
 
 Voici le fichier de configuration pour le PersistentVolume de type hostPath:
-{{< codenew file="pods/storage/pv-volume.yaml" >}}
+{{% codenew file="pods/storage/pv-volume.yaml" %}}
 
 Le fichier de configuration spécifie que le chemin du volume sur le noeud est `/mnt/data`. Il spécifie aussi une taille de 10 gibibytes, ainsi qu'un mode d'accès de type `ReadWriteOnce`, impliquant que le volume ne peut être monté en lecture et écriture que par un seul noeud. Le fichier définit un [nom de StorageClass](/docs/concepts/storage/persistent-volumes/#class) à `manual`, ce qui sera utilisé pour attacher un PersistentVolumeClaim à ce PersistentVolume
 
@@ -103,7 +103,7 @@ La prochaine étape est de créer un PersistentVolumeClaim (demande de stockage)
 Dans cet exercice, vous créez un PersistentVolumeClaim qui demande un volume d'au moins 3 GB, et qui peut être monté en lecture et écriture sur au moins un noeud. 
 
 Voici le fichier de configuration du PersistentVolumeClaim:
-{{< codenew file="pods/storage/pv-claim.yaml" >}}
+{{% codenew file="pods/storage/pv-claim.yaml" %}}
 
 Créez le PersistentVolumeClaim:
 
@@ -137,7 +137,7 @@ La prochaine étape est de créer un Pod qui utilise le PersistentVolumeClaim co
 
 Voici le fichier de configuration du Pod:
 
-{{< codenew file="pods/storage/pv-pod.yaml" >}}
+{{% codenew file="pods/storage/pv-pod.yaml" %}}
 
 Notez que le fichier de configuration du Pod spécifie un PersistentVolumeClaim et non un PersistentVolume. Du point de vue du Pod, la demande est un volume de stockage.
 
@@ -200,7 +200,7 @@ Vous pouvez maintenant arrêter la session shell vers votre noeud.
 Vous pouvez monter plusieurs fois un même PersistentVolume
 à plusieurs endroits différents dans votre container nginx:
 
-{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
+{{% codenew file="pods/storage/pv-duplicate.yaml" %}}
 
 - `/usr/share/nginx/html` pour le site statique
 - `/etc/nginx/nginx.conf` pour la configuration par défaut