FR localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files

Author: andreygoran

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