Skip to content

Commit bf5eda7

Browse files
andreygoranandreygoran
committed
FR localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
1 parent ff6d646 commit bf5eda7

34 files changed

Lines changed: 83 additions & 81 deletions

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

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@ d'évènements avec le flux de sortie standard. Cette démonstration utilise un
5050
manifeste pour un Pod avec un seul conteneur qui écrit du texte sur le flux
5151
de sortie standard toutes les secondes.
5252

53-
{{< codenew file="debug/counter-pod.yaml" >}}
53+
{{% codenew file="debug/counter-pod.yaml" %}}
5454

5555
Pour lancer ce Pod, utilisez la commande suivante :
5656

@@ -243,7 +243,7 @@ Un Pod exécute un unique conteneur et ce conteneur écrit dans deux fichiers de
243243
journaux différents en utilisant deux format différents. Voici le manifeste du
244244
Pod :
245245

246-
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
246+
{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
247247

248248
Il serait très désordonné d'avoir des évènements avec des formats différents
249249
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`.
253253

254254
Ci-dessous se trouve le manifeste pour un Pod avec deux conteneurs side-car.
255255

256-
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml"
257-
>}}
256+
{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
258257

259258
Quand ce Pod s'exécute, chaque journal peut être diffusé séparément en
260259
utilisant les commandes suivantes :
@@ -323,7 +322,7 @@ Le premier fichier contient un
323322
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) pour
324323
configurer fluentd.
325324

326-
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
325+
{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
327326

328327
{{< note >}}
329328
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
335334
exécute fluentd. Le Pod monte un volume où fluentd peut récupérer sa
336335
configuration.
337336

338-
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
337+
{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
339338

340339
Apres quelques minutes, les évènements apparaîtront dans l'interface de
341340
Stackdriver.

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -330,7 +330,7 @@ type: kubernetes.io/tls
330330

331331
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`.
332332

333-
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
333+
{{% codenew file="service/networking/tls-example-ingress.yaml" %}}
334334

335335

336336
{{< note >}}

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ Voici des cas d'utilisation typiques pour les déploiements:
4949
Voici un exemple de déploiement.
5050
Il crée un ReplicaSet pour faire apparaître trois pods `nginx`:
5151

52-
{{< codenew file="controllers/nginx-deployment.yaml" >}}
52+
{{% codenew file="controllers/nginx-deployment.yaml" %}}
5353

5454
Dans cet exemple:
5555

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ utilisez plutôt un déploiement et définissez votre application dans la sectio
4141

4242
## Exemple
4343

44-
{{< codenew file="controllers/frontend.yaml" >}}
44+
{{% codenew file="controllers/frontend.yaml" %}}
4545

4646
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.
4747

@@ -145,7 +145,7 @@ labels correspondant au sélecteur de l’un de vos ReplicaSets. Car un ReplicaS
145145

146146
Prenez l'exemple précédent de ReplicaSet, ainsi que les pods spécifiés dans le manifeste suivant :
147147

148-
{{< codenew file="pods/pod-rs.yaml" >}}
148+
{{% codenew file="pods/pod-rs.yaml" %}}
149149

150150
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.
151151

@@ -291,7 +291,7 @@ Un ReplicaSet peut également être une cible pour
291291
Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible
292292
le ReplicaSet que nous avons créé dans l'exemple précédent.
293293

294-
{{< codenew file="controllers/hpa-rs.yaml" >}}
294+
{{% codenew file="controllers/hpa-rs.yaml" %}}
295295

296296
Enregistrer ce manifeste dans `hpa-rs.yaml` et le soumettre à un cluster Kubernetes devrait
297297
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‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -95,7 +95,7 @@ Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés `foo:bar`
9595

9696
Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être :
9797

98-
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
98+
{{% codenew file="pods/topology-spread-constraints/one-constraint.yaml" %}}
9999

100100
`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.
101101

@@ -133,7 +133,7 @@ Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4
133133

134134
Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds :
135135

136-
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
136+
{{% codenew file="pods/topology-spread-constraints/two-constraints.yaml" %}}
137137

138138
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".
139139

@@ -182,7 +182,7 @@ Il existe quelques conventions implicites qu'il est intéressant de noter ici :
182182
183183
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.
184184
185-
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
185+
{{% codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" %}}
186186
187187
### Contraintes par défaut au niveau du cluster
188188

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

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -108,13 +108,14 @@ Utilisez cette méthode pour inclure des exemples de fichiers YAML lorsque l'éc
108108
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.
109109
Dans votre fichier, utilisez le shortcode `codenew` :
110110

111-
<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
112-
111+
```none
112+
{{%/* codenew file="<RELPATH>/my-example-yaml>" */%}}
113+
```
113114
où `<RELPATH>` est le chemin vers le fichier à inclure, relatif au répertoire `examples`.
114115
Le shortcode Hugo suivant fait référence à un fichier YAML situé sur `/content/en/examples/pods/storage/gce-volume.yaml`.
115116

116117
```none
117-
{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
118+
{{%/* codenew file="pods/storage/gce-volume.yaml" */%}}
118119
```
119120

120121
{{< note >}}

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1228,7 +1228,7 @@ comprend des recommandations pour restreindre cet accès dans les clusters exist
12281228
Si vous souhaitez que les nouveaux clusters conservent ce niveau d'accès dans les rôles agrégés,
12291229
vous pouvez créer le ClusterRole suivant :
12301230

1231-
{{< codenew file="access/endpoints-aggregated.yaml" >}}
1231+
{{% codenew file="access/endpoints-aggregated.yaml" %}}
12321232

12331233
## Mise à niveau à partir d'ABAC
12341234

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

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ Si votre environnement ne prend pas en charge cette fonction, vous pouvez utilis
3333
Le backend est un simple microservice de salutations.
3434
Voici le fichier de configuration pour le Deployment backend :
3535

36-
{{< codenew file="service/access/backend-deployment.yaml" >}}
36+
{{% codenew file="service/access/backend-deployment.yaml" %}}
3737

3838
Créez le Deployment backend :
3939

@@ -91,7 +91,7 @@ Un Service utilise des {{< glossary_tooltip text="sélecteurs" term_id="selector
9191

9292
Tout d'abord, explorez le fichier de configuration du Service :
9393

94-
{{< codenew file="service/access/backend-service.yaml" >}}
94+
{{% codenew file="service/access/backend-service.yaml" %}}
9595

9696
Dans le fichier de configuration, vous pouvez voir que le Service,
9797
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
120120
configurée pour acheminer les requêtes vers le Service backend `hello`.
121121
Voici le fichier de configuration nginx :
122122

123-
{{< codenew file="service/access/frontend-nginx.conf" >}}
123+
{{% codenew file="service/access/frontend-nginx.conf" %}}
124124

125125
Comme pour le backend, le frontend dispose d'un Deployment et d'un Service.
126126
Une différence importante à noter entre les services backend et frontend est que
127127
le Service frontend est configuré avec un `type: LoadBalancer`, ce qui signifie que le Service utilise
128128
un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster.
129129

130-
{{< codenew file="service/access/frontend-service.yaml" >}}
130+
{{% codenew file="service/access/frontend-service.yaml" %}}
131131

132-
{{< codenew file="service/access/frontend-deployment.yaml" >}}
132+
{{% codenew file="service/access/frontend-deployment.yaml" %}}
133133

134134
Créez le Deployment et le Service frontend :
135135

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ ayant deux instances en cours d'exécution.
2727

2828
Voici le fichier de configuration pour le déploiement de l'application :
2929

30-
{{< codenew file="service/access/hello-application.yaml" >}}
30+
{{% codenew file="service/access/hello-application.yaml" %}}
3131

3232
1. Exécutez une application Hello World dans votre cluster :
3333
Créez le déploiement de l'application en utilisant le fichier ci-dessus :

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,7 @@ Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouv
7474
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.
7575
Utilisez ce qui suit comme guide:
7676

77-
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
77+
{{% codenew file="admin/cloud/ccm-example.yaml" %}}
7878

7979
## Limitations
8080

0 commit comments

Comments
 (0)