Merge branch 'master' of https://github.com/kubernetes/website into reviewer

Makefile

@@ -17,12 +17,15 @@ CCEND=\033[0m
 help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
 
+module-check:
+	@git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2
+
 all: build ## Build site with production settings and put deliverables in ./public
 
-build: ## Build site with production settings and put deliverables in ./public
+build: module-check ## Build site with production settings and put deliverables in ./public
 	hugo --minify
 
-build-preview: ## Build site with drafts and future posts enabled
+build-preview: module-check ## Build site with drafts and future posts enabled
 	hugo --buildDrafts --buildFuture
 
 deploy-preview: ## Deploy preview site via netlify
@@ -39,7 +42,7 @@ production-build: build check-headers-file ## Build the production site and ensu
 non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
 	hugo --enableGitInfo
 
-serve: ## Boot the development server.
+serve: module-check ## Boot the development server.
 	hugo server --buildFuture
 
 docker-image:
@@ -60,10 +63,10 @@ container-image:
 		--tag $(CONTAINER_IMAGE) \
 		--build-arg HUGO_VERSION=$(HUGO_VERSION)
 
-container-build:
+container-build: module-check
 	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo
 
-container-serve:
+container-serve: module-check
 	$(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
 
 test-examples:
@@ -81,4 +84,3 @@ docker-internal-linkcheck:
 container-internal-linkcheck: link-checker-image-pull
 	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
 	$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
-

content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md

@@ -18,7 +18,7 @@ This is post #1 in a series about the local deployment options on Linux, and it
 
 [Minikube](https://github.com/kubernetes/minikube) is a cross-platform, community-driven [Kubernetes](https://kubernetes.io/) distribution, which is targeted to be used primarily in local environments. It deploys a single-node cluster, which is an excellent option for having a simple Kubernetes cluster up and running on localhost.
 
-Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md) outside of VirtualBox.
+Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://minikube.sigs.k8s.io/docs/drivers/) outside of VirtualBox.
 
 By default, Minikube uses Virtualbox as a runtime for running the virtual machine. Virtualbox is a cross-platform solution, which can be used on a variety of operating systems, including GNU/Linux, Windows, and macOS.
 

content/en/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -254,6 +254,7 @@ spec:
   request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
   usages:
   - client auth
+EOF
 ```
 
 Some points to note:

content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify
 
   Example:
 
-```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+  ```conf
+  release=1.0
+  tier=frontend
+  environment=pod
+  track=stable
+  ```
 
 - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
 

content/es/docs/concepts/workloads/controllers/garbage-collection.md

@@ -0,0 +1,183 @@
+---
+title: Recolección de Basura
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos
+que en algún momento tuvieron un propietario, pero que ahora ya no.
+
+{{% /capture %}}
+
+
+{{% capture body %}}referencias de propietario
+
+## Propietarios y subordinados
+
+Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet
+es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan *subordinados* del
+objeto propietario. Cada objeto subordinado tiene un campo `metadata.ownerReferences` 
+que apunta al objeto propietario.
+
+En ocasiones, Kubernetes pone el valor del campo `ownerReference` automáticamente.
+ Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo 
+`ownerReference` de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes
+automáticamente pone el valor de `ownerReference` para los objetos creados o adoptados
+por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job
+y CronJob.
+
+También puedes configurar las relaciones entre los propietarios y sus subordinados
+de forma manual indicando el valor del campo `ownerReference`.
+
+Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods:
+
+{{< codenew file="controllers/replicaset.yaml" >}}
+
+Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede 
+observar el campo OwnerReferences:
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
+kubectl get pods --output=yaml
+```
+
+La salida muestra que el propietario del Pod es el ReplicaSet denominado `my-repset`:
+
+```shell
+apiVersion: v1
+kind: Pod
+metadata:
+  ...
+  ownerReferences:
+  - apiVersion: apps/v1
+    controller: true
+    blockOwnerDeletion: true
+    kind: ReplicaSet
+    name: my-repset
+    uid: d9607e19-f88f-11e6-a518-42010a800195
+  ...
+```
+
+{{< note >}}
+No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que: 
+1) Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace,
+y propietarios dentro del ámbito de clúster.
+2) Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no
+propietarios dentro del ámbito de Namespaces.
+{{< /note >}}
+
+## Controlar cómo el recolector de basura elimina los subordinados
+
+Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también
+de forma automática. Eliminar los subordinados automáticamente se denomina *borrado en cascada*.  
+Hay dos modos de *borrado en cascada*: *en segundo plano* y *en primer plano*.
+
+Si eliminas un objeto sin borrar sus subordinados de forma automática,
+dichos subordinados se convierten en *huérfanos*.
+
+### Borrado en cascada en primer plano
+
+En el *borrado en cascada en primer plano*, el objeto raíz primero entra en un estado
+llamado "deletion in progress". En este estado "deletion in progress",
+se cumplen las siguientes premisas:
+
+ * El objeto todavía es visible a través de la API REST
+ * Se pone el valor del campo `deletionTimestamp` del objeto
+ * El campo `metadata.finalizers` del objeto contiene el valor "foregroundDeletion".
+
+Una vez que se pone el estado "deletion in progress", el recolector de basura elimina
+los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos
+los subordinados "bloqueantes" (los objetos con `ownerReference.blockOwnerDeletion=true`), elimina
+el objeto propietario.
+
+Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en 
+`ownerReference.blockOwnerDeletion` bloquean la eliminación del objeto propietario.
+A partir de la versión 1.7, Kubernetes añadió un [controlador de admisión](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) 
+que controla el acceso de usuario cuando se intenta poner el campo `blockOwnerDeletion` a true 
+con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados
+no puedan retrasar la eliminación del objeto propietario.
+
+Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo `ownerReferences` de un objeto,
+se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo.
+
+### Borrado en cascada en segundo plano
+
+En el *borrado en cascada en segundo plano*, Kubernetes elimina el objeto propietario
+inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano.
+
+### Configurar la regla de borrado en cascada
+
+Para controlar la regla de borrado en cascada, configura el campo `propagationPolicy`
+del parámetro `deleteOptions` cuando elimines un objeto. Los valores posibles incluyen "Orphan",
+"Foreground", o "Background".
+
+Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era `orphan`.
+Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment. 
+Para los tipos dentro de las versiones de grupo `extensions/v1beta1`, `apps/v1beta1`, y `apps/v1beta2`, a menos que
+se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto. 
+En Kubernetes 1.9, para todos los tipos de la versión de grupo `apps/v1`, los objetos subordinados se eliminan por defecto.
+
+Aquí se muestra un ejemplo que elimina los subordinados en segundo plano:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+-H "Content-Type: application/json"
+```
+
+Aquí se muestra un ejemplo que elimina los subordinados en primer plano:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+-H "Content-Type: application/json"
+```
+
+Aquí se muestra un ejemplo de subordinados huérfanos:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+-H "Content-Type: application/json"
+```
+
+kubectl también permite el borrado en cascada.
+Para eliminar los subordinados automáticamente, utiliza el parámetro `--cascade` a true.
+  Usa false para subordinados huérfanos. Por defecto, el valor de `--cascade`
+es true.
+
+Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet:
+
+```shell
+kubectl delete replicaset my-repset --cascade=false
+```
+
+### Nota adicional sobre los Deployments
+
+Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se *debía* usar `propagationPolicy: Foreground`
+para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de _propagationPolicy_
+no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos.
+Ver [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) para más información.
+
+## Problemas conocidos
+
+Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+
+[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+
+[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+
+{{% /capture %}}
+
+
+

content/es/examples/controllers/nginx-deployment.yaml

@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  labels:
+    app: nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80

content/es/examples/controllers/replicaset.yaml

@@ -0,0 +1,17 @@
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+  name: my-repset
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      pod-is-for: garbage-collection-example
+  template:
+    metadata:
+      labels:
+        pod-is-for: garbage-collection-example
+    spec:
+      containers:
+      - name: nginx
+        image: nginx

content/fr/_index.html

@@ -3,9 +3,6 @@ title: "Solution professionnelle d’orchestration de conteneurs"
 abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs"
 cid: home
 ---
-{{< announcement >}}
-
-{{< deprecationwarning >}}
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}

content/fr/docs/reference/glossary/uid.md

@@ -0,0 +1,17 @@
+---
+title: UID
+id: uid
+date: 2018-04-12
+full_link: /docs/concepts/overview/working-with-objects/names
+short_description: >
+  Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
+
+aka: 
+tags:
+- fundamental
+---
+ Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
+
+<!--more--> 
+
+Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer  les occurrences historiques d'entités similaires.

content/fr/docs/setup/learning-environment/minikube.md

@@ -242,9 +242,9 @@ Voir [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) pour plus de détails
 * vmwarefusion
 * kvm2 ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
 * hyperkit ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver))
 Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`.
-* vmware ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
+* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver)
 * none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker ([docker installer](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) et un environnement Linux)
 
 #### Démarrage d'un cluster sur des exécutions de conteneur alternatives

content/fr/docs/tasks/configure-pod-container/configure-service-account.md

@@ -0,0 +1,283 @@
+---
+title: Configurer les comptes de service pour les pods
+content_template: templates/task
+weight: 90
+---
+
+{{% capture overview %}}
+Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod.
+
+*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi
+[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).*
+
+{{< note >}}
+Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable.
+{{< /note >}}
+
+Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes
+authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit 
+généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`).
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Utiliser le compte de service par défaut pour accéder au API server.
+
+Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/<podname> -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
+
+Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
+Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage.
+
+Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service :
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: build-robot
+automountServiceAccountToken: false
+...
+```
+
+Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier :
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-pod
+spec:
+  serviceAccountName: build-robot
+  automountServiceAccountToken: false
+  ...
+```
+
+La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`.
+
+## Utiliser plusieurs comptes de services.
+
+Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`.
+Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande :
+
+```shell
+kubectl get serviceAccounts
+```
+La sortie est comme la suivante :
+
+```
+NAME      SECRETS    AGE
+default   1          1d
+```
+
+Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci :
+
+```shell
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: build-robot
+EOF
+```
+
+Si vous obtenez un dump complet de l'objet compte de service, par exemple :
+
+```shell
+kubectl get serviceaccounts/build-robot -o yaml
+```
+La sortie est comme la suivante :
+
+```
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  creationTimestamp: 2015-06-16T00:12:59Z
+  name: build-robot
+  namespace: default
+  resourceVersion: "272500"
+  selfLink: /api/v1/namespaces/default/serviceaccounts/build-robot
+  uid: 721ab723-13bc-11e5-aec2-42010af0021e
+secrets:
+- name: build-robot-token-bvbk5
+```
+
+vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service.
+
+Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
+
+Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser.
+
+Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté.
+
+Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé.
+
+Vous pouvez supprimer le compte de service de cet exemple comme ceci :
+
+```shell
+kubectl delete serviceaccount/build-robot
+```
+
+## Créez manuellement un API token de compte de service.
+
+Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement.
+
+```shell
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Secret
+metadata:
+  name: build-robot-secret
+  annotations:
+    kubernetes.io/service-account.name: build-robot
+type: kubernetes.io/service-account-token
+EOF
+```
+
+Vous pouvez maintenant confirmer que le Secret nouvellement construit est rempli d'un API token pour le compte de service "build-robot".
+
+Tous les tokens pour des comptes de service non-existants seront nettoyés par le contrôleur de token.
+
+```shell
+kubectl describe secrets/build-robot-secret
+```
+La sortie est comme la suivante :
+
+```
+Name:           build-robot-secret
+Namespace:      default
+Labels:         <none>
+Annotations:    kubernetes.io/service-account.name=build-robot
+                kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
+
+Type:   kubernetes.io/service-account-token
+
+Data
+====
+ca.crt:         1338 bytes
+namespace:      7 bytes
+token:          ...
+```
+
+{{< note >}}
+Le contenu de `token` est éludé ici.
+{{< /note >}}
+
+## Ajouter ImagePullSecrets à un compte de service
+
+Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+Puis, vérifiez qu'il a été créé. Par exemple :
+
+```shell
+kubectl get secrets myregistrykey
+```
+
+La sortie est comme la suivante :
+
+```
+NAME             TYPE                              DATA    AGE
+myregistrykey    kubernetes.io/.dockerconfigjson   1       1d
+```
+
+Ensuite, modifiez le compte de service par défaut du Namespace pour utiliser ce Secret comme un `imagePullSecret`.
+
+```shell
+kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
+```
+
+La version interactive nécessite un traitement manuel :
+
+```shell
+kubectl get serviceaccounts default -o yaml > ./sa.yaml
+```
+
+La sortie du fichier `sa.yaml` est similaire à celle-ci :
+
+```shell
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  creationTimestamp: 2015-08-07T22:02:39Z
+  name: default
+  namespace: default
+  resourceVersion: "243024"
+  selfLink: /api/v1/namespaces/default/serviceaccounts/default
+  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
+secrets:
+- name: default-token-uudge
+```
+
+En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez.
+
+La sortie du fichier `sa.yaml` est similaire à celle-ci :
+
+```shell
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  creationTimestamp: 2015-08-07T22:02:39Z
+  name: default
+  namespace: default
+  selfLink: /api/v1/namespaces/default/serviceaccounts/default
+  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
+secrets:
+- name: default-token-uudge
+imagePullSecrets:
+- name: myregistrykey
+```
+
+Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour.
+
+```shell
+kubectl replace serviceaccount default -f ./sa.yaml
+```
+
+Maintenant, tous les nouveaux Pods créés dans le Namespace courant auront ceci ajouté à leurs spécifications :
+
+```yaml
+spec:
+  imagePullSecrets:
+  - name: myregistrykey
+```
+
+## Projection du volume des tokens de compte de service
+
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+
+{{< note >}}
+Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et
+activé en passant tous les paramètres suivants au serveur API :
+
+* `--service-account-issuer`
+* `--service-account-signing-key-file`
+* `--service-account-api-audiences`
+
+{{< /note >}}
+
+Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité.
+Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé
+
+Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé
+[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un
+Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec :
+
+{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
+
+Créez le Pod
+
+```shell
+kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
+```
+
+Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures.
+
+L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation.
+
+{{% /capture %}}

content/fr/examples/pods/pod-projected-svc-token.yaml

@@ -0,0 +1,20 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - image: nginx
+    name: nginx
+    volumeMounts:
+    - mountPath: /var/run/secrets/tokens
+      name: vault-token
+  serviceAccountName: build-robot
+  volumes:
+  - name: vault-token
+    projected:
+      sources:
+      - serviceAccountToken:
+          path: vault-token
+          expirationSeconds: 7200
+          audience: vault

content/zh/docs/concepts/policy/resource-quotas.md

@@ -150,7 +150,7 @@ The following resource types are supported:
 In addition to the resources mentioned above, in release 1.10, quota support for
 [extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added.
 -->
-除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。
+除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#扩展资源-extended-resources)的支持。
 
 <!--
 As overcommit is not allowed for extended resources, it makes no sense to specify both `requests`
@@ -820,7 +820,7 @@ plugins:
     limitedResources:
     - resource: pods
       matchScopes:
-      - scopeName: PriorityClass 
+      - scopeName: PriorityClass
         operator: In
         values: ["cluster-services"]
 ```
@@ -839,7 +839,7 @@ plugins:
     limitedResources:
     - resource: pods
       matchScopes:
-      - scopeName: PriorityClass 
+      - scopeName: PriorityClass
         operator: In
         values: ["cluster-services"]
 ```
@@ -888,5 +888,3 @@ See a [detailed example for how to use resource quota](/docs/tasks/administer-cl
 See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
 -->
 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。
-
-

content/zh/docs/concepts/storage/dynamic-provisioning.md

@@ -176,7 +176,7 @@ can enable this behavior by:
   is enabled on the API server.
 -->
 - 标记一个 `StorageClass` 为 *默认*；
-- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
+- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
 
 <!--
 An administrator can mark a specific `StorageClass` as default by adding the
@@ -211,5 +211,3 @@ Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
 在[多区域](/docs/setup/multiple-zones)集群中，Pod 可以被分散到多个区域。
 单区域存储后端应该被供应到 Pod 被调度到的区域。
 这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
-
-

content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -1,5 +1,6 @@
 ---
-title: Using a Service to Expose Your App
+<!--title: Using a Service to Expose Your App-->
+title: 使用 Service 暴露您的应用
 weight: 10
 ---
 
@@ -17,42 +18,61 @@ weight: 10
 
 		<div class="row">
 			<div class="col-md-8">
-    		<h3>Objectives</h3>
+<!--        <h3>Objectives</h3>-->
+        <h3>目标</h3>
 				<ul>
-					<li>Learn about a Service in Kubernetes</li>
-					<li>Understand how labels and LabelSelector objects relate to a Service</li>
-					<li>Expose an application outside a Kubernetes cluster using a Service</li>
+<!--          <li>Learn about a Service in Kubernetes</li>-->
+<!--          <li>Understand how labels and LabelSelector objects relate to a Service</li>-->
+<!--          <li>Expose an application outside a Kubernetes cluster using a Service</li>-->
+					<li>了解 Kubernetes 中的 Service </li>
+					<li>了解 标签(Label) 和 标签选择器(Label Selector) 对象如何与 Service 关联</li>
+          <li>在 Kubernetes 集群外用 Service 暴露应用</li>
 				</ul>
 			</div>
 
 			<div class="col-md-8">
-			<h3>Overview of Kubernetes Services</h3>
+<!--        <h3>Overview of Kubernetes Services</h3>-->
+        <h3>Kubernetes Service 总览</h3>
 
-			<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
+<!--        <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>-->
+        <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/pod-overview/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
 
-			<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
+<!--        <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>-->
+        <p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>
 
-			<p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
+<!--        <p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>-->
+        <p>尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记<code>type</code>的方式暴露</p>
 			<ul>
-				<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
-				<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>. Superset of ClusterIP.</li>
-				<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
-				<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
+<!--        <li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>-->
+<!--        <li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>. Superset of ClusterIP.</li>-->
+<!--        <li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>-->
+<!--        <li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>-->
+				<li><i>ClusterIP</i> (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。</li>
+				<li><i>NodePort</i> - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code> 从集群外部访问 Service。是 ClusterIP 的超集。</li>
+				<li><i>LoadBalancer</i> - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。</li>
+				<li><i>ExternalName</i> - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的<code>externalName</code>指定)公开 Service。不使用代理。这种类型需要<code>kube-dns</code>的v1.7或更高版本。</li>
 			</ul>
-			<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
-			<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
+<!--        <p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>-->
+        <p>更多关于不同 Service 类型的信息可以在<a href="/zh/docs/tutorials/services/source-ip/">使用源 IP </a> 教程。 也请参阅 <a href="/zh/docs/concepts/services-networking/connect-applications-service">连接应用程序和 Service </a>。</p>
+<!--        <p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>-->
+        <p>另外，需要注意的是有一些 Service 的用例没有在 spec 中定义<code>selector</code>。 一个没有<code>selector</code>创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用<code>type: ExternalName</code>来标记。</p>
 			</div>
 			<div class="col-md-4">
 				<div class="content__box content__box_lined">
-					<h3>Summary</h3>
+<!--          <h3>Summary</h3>-->
+          <h3>总结</h3>
 					<ul>
-						<li>Exposing Pods to external traffic</li>
-						<li>Load balancing traffic across multiple Pods</li>
-						<li>Using labels</li>
+<!--            <li>Exposing Pods to external traffic</li>-->
+<!--            <li>Load balancing traffic across multiple Pods</li>-->
+<!--            <li>Using labels</li>-->
+						<li>将 Pod 暴露给外部通信</li>
+						<li>跨多个 Pod 的负载均衡</li>
+						<li>使用标签(Label)</li>
 					</ul>
 				</div>
 				<div class="content__box content__box_fill">
-						<p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>
+<!--          <p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>-->
+          <p><i>Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。</i></p>
 				</div>
 			</div>
 		</div>
@@ -60,7 +80,7 @@ weight: 10
 
 		<div class="row">
 			<div class="col-md-8">
-				<h3>Services and Labels</h3>
+				<h3>Service 和 Label</h3>
 			</div>
 		</div>
 
@@ -72,18 +92,24 @@ weight: 10
 
 		<div class="row">
 			<div class="col-md-8">
-				<p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>
-				<p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>
+<!--        <p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>-->
+        <p>Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。</p>
+<!--        <p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>-->
+        <p>Service 匹配一组 Pod 是使用 <a href="/zh/docs/concepts/overview/working-with-objects/labels">标签(Label)和选择器(Selector)</a>, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:</p>
 				<ul>
-					<li>Designate objects for development, test, and production</li>
-					<li>Embed version tags</li>
-					<li>Classify an object using tags</li>
+<!--          <li>Designate objects for development, test, and production</li>-->
+<!--          <li>Embed version tags</li>-->
+<!--          <li>Classify an object using tags</li>-->
+					<li>指定用于开发，测试和生产的对象</li>
+					<li>嵌入版本标签</li>
+					<li>使用 Label 将对象进行分类</li>
 				</ul>
 
 			</div>
 			<div class="col-md-4">
 				<div class="content__box content__box_fill">
-					<p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>
+<!--          <p><i>You can create a Service at the same time you create a Deployment by using<br><code>&#45;&#45;expose</code> in kubectl.</i></p>-->
+          <p><i>你也可以在创建 Deployment 的同时用 <code>--expose</code>创建一个 Service 。</i></p>
 				</div>
 			</div>
 		</div>
@@ -98,13 +124,15 @@ weight: 10
 		<br>
 		<div class="row">
 			<div class="col-md-8">
-				<p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>
+<!--        <p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>-->
+        <p> 标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。</p>
 			</div>
 		</div>
 		<br>
 		<div class="row">
 			<div class="col-md-12">
-				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>
+<!--        <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>-->
+        <a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">开始交互式教程<span class="btn__next">›</span></a>
 			</div>
 		</div>
 	</main>

i18n/zh.toml

@@ -2,7 +2,7 @@
 # 注意：修改此文件时请维持字符串名称的字母顺序并与英文版保持一致
 
 [caution]
-other = "警告:"
+other = "注意："
 
 [cleanup_heading]
 other = "清理现场"
@@ -164,7 +164,7 @@ other = "了解"
 other = "了解更多"
 
 [note]
-other = "注意："
+other = "说明："
 
 [objectives_heading]
 other = "教程目标"