Merge pull request #35445 from windsonsea/eventyhf

[zh-cn] updated /docs/reference/glossary/event.md

content/en/docs/concepts/security/rbac-good-practices.md

@@ -24,15 +24,15 @@ The good practices laid out here should be read in conjunction with the general
 
 ### Least privilege
 
-Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions 
-explicitly required for their operation should be used. Whilst each cluster will be different, 
+Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions 
+explicitly required for their operation should be used. While each cluster will be different, 
 some general rules that can be applied are :
 
  - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to 
    ClusterRoleBindings to give users rights only within a specific namespace.
  - Avoid providing wildcard permissions when possible, especially to all resources.
    As Kubernetes is an extensible system, providing wildcard access gives rights
-   not just to all object types presently in the cluster, but also to all future object types
+   not just to all object types that currently exist in the cluster, but also to all future object types
    which are created in the future.
  - Administrators should not use `cluster-admin` accounts except where specifically needed. 
    Providing a low privileged account with
@@ -66,7 +66,7 @@ the RBAC rights provided by default can provide opportunities for security harde
 In general, changes should not be made to rights provided to `system:` accounts some options 
 to harden cluster rights exist:
 
-- Review bindings for the `system:unauthenticated` group and remove where possible, as this gives 
+- Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives 
   access to anyone who can contact the API server at a network level.
 - Avoid the default auto-mounting of service account tokens by setting
   `automountServiceAccountToken: false`. For more details, see
@@ -129,20 +129,19 @@ PersistentVolumes, and constrained users should use PersistentVolumeClaims to ac
 ### Access to `proxy` subresource of Nodes
 
 Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 
-which allows for command execution on every pod on the node(s) which they have rights to. 
+which allows for command execution on every pod on the node(s) to which they have rights. 
 This access bypasses audit logging and admission control, so care should be taken before 
 granting rights to this resource.
 
 ### Escalate verb
 
-Generally the RBAC system prevents users from creating clusterroles with more rights than 
-they possess. The exception to this is the `escalate` verb. As noted in the
-[RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
+Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. 
+The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
 users with this right can effectively escalate their privileges.
 
 ### Bind verb
 
-Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes 
+Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes 
 in-built protections against privilege escalation, allowing users to create bindings to 
 roles with rights they do not already have.
 

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

@@ -116,7 +116,7 @@ can enable this behavior by:
   is enabled on the API server.
 
 An administrator can mark a specific `StorageClass` as default by adding the
-`storageclass.kubernetes.io/is-default-class` annotation to it.
+`storageclass.kubernetes.io/is-default-class` [annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it.
 When a default `StorageClass` exists in a cluster and a user creates a
 `PersistentVolumeClaim` with `storageClassName` unspecified, the
 `DefaultStorageClass` admission controller automatically adds the

content/en/docs/tasks/administer-cluster/access-cluster-api.md

@@ -226,7 +226,7 @@ mvn install
 See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.
 
 The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-15/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
 
 ```java
 package io.kubernetes.client.examples;

content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md

@@ -5,8 +5,8 @@ content_type: task
 ---
 
 This task outlines the steps needed to update your container runtime to containerd from Docker. It
-is applicable for cluster operators running Kubernetes 1.23 or earlier. Also  this covers an
-example scenario for migrating from dockershim to containerd and alternative container runtimes
+is applicable for cluster operators running Kubernetes 1.23 or earlier. This also covers an
+example scenario for migrating from dockershim to containerd. Alternative container runtimes
 can be picked from this [page](/docs/setup/production-environment/container-runtimes/).
 
 ## {{% heading "prerequisites" %}}
@@ -100,7 +100,7 @@ then run the following commands:
 
 Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags.
 `--container-runtime=remote` and
-`--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`.
+`--container-runtime-endpoint=unix:///run/containerd/containerd.sock`.
 
 Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
 an annotation in the Node object for that host. To change it you can execute the following command

content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md

@@ -10,7 +10,7 @@ card:
 <!-- overview -->
 Many applications rely on configuration which is used during either application initialization or runtime.
 Most of the times there is a requirement to adjust values assigned to configuration parameters.
-ConfigMaps is the kubernetes way to inject application pods with configuration data.
+ConfigMaps are the Kubernetes way to inject application pods with configuration data.
 ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
 
 
@@ -623,24 +623,6 @@ Like before, all previous files in the `/etc/config/` directory will be deleted.
 You can project keys to specific paths and specific permissions on a per-file
 basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax.
 
-### Optional References
-
-A ConfigMap reference may be marked "optional".  If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced
-key is non-existent the path will be absent beneath the mount point.
-
-### Mounted ConfigMaps are updated automatically
-
-When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into
-existence after a pod has started.
-
-Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
-ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
-kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet.
-
-{{< note >}}
-A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
-{{< /note >}}
-
 
 
 <!-- discussion -->
@@ -675,7 +657,7 @@ data:
 
 ### Restrictions
 
-- You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
+- You must create the `ConfigMap` object before you reference it in a Pod specification. Alternatively, mark the ConfigMap reference as `optional` in the Pod spec (see [Optional ConfigMaps](#optional-configmaps)). If you reference a ConfigMap that doesn't exist and you don't mark the reference as `optional`, the Pod won't start. Similarly, references to keys that don't exist in the ConfigMap will also prevent the Pod from starting, unless you mark the key references as `optional`.
 
 - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
 
@@ -693,7 +675,75 @@ data:
 
 - You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this.
 
+### Optional ConfigMaps
 
+You can mark a reference to a ConfigMap as _optional_ in a Pod specification.
+If the ConfigMap doesn't exist, the configuration for which it provides data in the Pod (e.g. environment variable, mounted volume) will be empty.
+If the ConfigMap exists, but the referenced key is non-existent the data is also empty.
+
+For example, the following Pod specification marks an environment variable from a ConfigMap as optional:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: gcr.io/google_containers/busybox
+      command: [ "/bin/sh", "-c", "env" ]
+      env:
+        - name: SPECIAL_LEVEL_KEY
+          valueFrom:
+            configMapKeyRef:
+              name: a-config
+              key: akey
+              optional: true # mark the variable as optional
+  restartPolicy: Never
+```
+
+If you run this pod, and there is no ConfigMap named `a-config`, the output is empty.
+If you run this pod, and there is a ConfigMap named `a-config` but that ConfigMap doesn't have
+a key named `akey`, the output is also empty. If you do set a value for `akey` in the `a-config`
+ConfigMap, this pod prints that value and then terminates.
+
+You can also mark the volumes and files provided by a ConfigMap as optional. Kubernetes always creates the mount paths for the volume, even if the referenced ConfigMap or key doesn't exist. For example, the following
+Pod specification marks a volume that references a ConfigMap as optional:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dapi-test-pod
+spec:
+  containers:
+    - name: test-container
+      image: gcr.io/google_containers/busybox
+      command: [ "/bin/sh", "-c", "ls /etc/config" ]
+      volumeMounts:
+      - name: config-volume
+        mountPath: /etc/config
+  volumes:
+    - name: config-volume
+      configMap:
+        name: no-config
+        optional: true # mark the source ConfigMap as optional
+  restartPolicy: Never
+```
+
+### Mounted ConfigMaps are updated automatically
+
+When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into
+existence after a pod has started.
+
+The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
+ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
+kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet.
+
+{{< note >}}
+A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -29,7 +29,7 @@ When they do, they are authenticated as a particular Service Account (for exampl
 
 <!-- steps -->
 
-## Use the Default Service Account to access the API server.
+## Use the Default Service Account to access the API server
 
 When you create a pod, if you do not specify a service account, it is
 automatically assigned the `default` service account in the same namespace.
@@ -68,7 +68,7 @@ spec:
 
 The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
 
-## Use Multiple Service Accounts.
+## Use Multiple Service Accounts
 
 Every namespace has a default service account resource called `default`.
 You can list this and any other serviceAccount resources in the namespace with this command:
@@ -136,7 +136,7 @@ You can clean up the service account from this example like this:
 kubectl delete serviceaccount/build-robot
 ```
 
-## Manually create a service account API token.
+## Manually create a service account API token
 
 Suppose we have an existing service account named "build-robot" as mentioned above, and we create
 a new secret manually.

content/es/_index.html

@@ -41,12 +41,12 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Ver vídeo</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Asista a la KubeCon en San Diego del 18 al 21 de Nov. 2019</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Asista a la KubeCon en Norte América del 24 al 28 de Octubre 2022</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Asista a la KubeCon en Amsterdam del 30 Marzo al 2 Abril</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/" button id="desktopKCButton">Asista a la KubeCon en Europa del 17 al 21 de Abril 2023</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/es/docs/concepts/services-networking/network-policies.md

@@ -0,0 +1,287 @@
+---
+reviewers:
+- raelga
+- electrocucaracha
+title: Políticas de red (Network Policies)
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+Si quieres controlar el tráfico de red a nivel de dirección IP o puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un {{< glossary_tooltip text="Pod" term_id="pod">}} puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones.
+
+Las entidades con las que un Pod puede comunicarse son de una combinación de estos 3 tipos:
+
+1. Otros Pods permitidos (excepción: un Pod no puede bloquear el acceso a sí mismo)
+2. Namespaces permitidos
+3. Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo)
+
+Cuando se define una NetworkPolicy basada en Pods o Namespaces, se utiliza un {{< glossary_tooltip text="Selector" term_id="selector">}} para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector.
+
+Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políticas basadas en bloques de IP (rangos CIDR).
+
+
+  <!-- body -->
+## Prerrequisitos
+
+Las políticas de red son implementadas por el [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá efecto alguno.
+
+
+## Dos Tipos de Aislamiento de Pod
+
+Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones".  La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita.  Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un Pod a otro.
+
+Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al Pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva.
+
+Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al Pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva.
+
+Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política.
+
+Para que se permita una conexión desde un Pod de origen a un Pod de destino, tanto la política de salida del Pod de origen como la de entrada del Pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá.
+
+
+## El Recurso NetworkPolicy {#networkpolicy-resource}
+
+Ver la referencia [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) para una definición completa del recurso.
+
+Un ejemplo de NetworkPolicy pudiera ser este:
+
+{{< codenew file="service/networking/networkpolicy.yaml" >}}
+
+{{< note >}}
+Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red soporte de políticas de red.
+{{< /note >}}
+
+__Campos Obligatorios__: Como con todos los otras configuraciones de Kubernetes, una NetworkPolicy
+necesita los campos `apiVersion`, `kind`, y `metadata`.  Para obtener información general
+sobre cómo funcionan esos ficheros de configuración, puedes consultar
+[Configurar un Pod para usar un ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+y [Gestión de Objetos](/docs/concepts/overview/working-with-objects/object-management).
+
+__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contiene toda la información necesaria para definir una política de red dado un Namespace.
+
+__podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona Pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace.
+
+__policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida.
+
+__ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`.
+
+__egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`.
+
+Por lo tanto, la NetworkPolicy de ejemplo:
+
+1. Aísla los Pods "role=db" en el Namespace "default" para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados)
+2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes:
+
+  * cualquier Pod en el Namespace "default" con el label "role=frontend"
+  * cualquier Pod en un Namespace con el label "project=myproject"
+  * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24)
+3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978
+
+Ver el artículo de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos.
+
+
+## Comportamiento de los selectores `to` y `from`
+
+Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` o en una sección de `egress` `to`:
+
+__podSelector__: Este selector selecciona Pods específicos en el mismo Namespace que la NetworkPolicy para permitir el tráfico como origen de entrada o destino de salida.
+
+__namespaceSelector__: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida.
+
+__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifica tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de Namespaces específicos. Es importante revisar que se utiliza la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política:
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+      podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+contiene un elemento `from` permitiendo conexiones desde los Pods con el label `role=client` en Namespaces con el label `user=alice`. Por el contrario, *esta* política:
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+    - podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+contiene dos elementos en el array `from`, y permite conexiones desde Pods en los Namespaces con el label `role=client`, *o* desde cualquier Pod en cualquier Namespace con el label `user=alice`.
+
+En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpretado la política.
+
+
+<a name="behavior-of-ipblock-selectors"></a>
+__ipBlock__: Este selector selecciona rangos CIDR de IP específicos para permitirlas como origen de entrada o destino de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles.
+
+Los mecanismos de entrada y salida del clúster a menudo requieren reescribir la IP de origen o destino
+de los paquetes. En los casos en los que esto ocurre, no está definido si esto ocurre antes o
+después del procesamiento de NetworkPolicy, y el comportamiento puede ser diferente para diferentes
+combinaciones de plugin de red, proveedor de nube, implementación de `Service`, etc.
+
+En el caso de la entrada, esto significa que en algunos casos se pueden filtrar paquetes 
+entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la
+la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP del Nodo donde este el Pod involucrado, etc.
+
+Para la salida, esto significa que las conexiones de los Pods a las IPs de `Service` que se reescriben a
+IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBlock`.
+
+
+## Políticas por defecto
+
+Por defecto, si no existen políticas en un Namespace, se permite todo el tráfico de entrada y salida hacia y desde los Pods de ese Namespace. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese Namespace.
+
+
+### Denegar todo el tráfico de entrada por defecto
+
+Puedes crear una política que "por defecto" aisle a un Namespace del tráfico de entrada con la creación de una política que seleccione todos los Pods del Namespace pero no permite ningún tráfico de entrada en esos Pods.
+
+{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+
+Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pod. 
+
+
+### Permitir todo el tráfico de entrada
+
+Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un Namespace, puedes crear una política que explícitamente permita eso.
+
+{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+
+Con esta política en curso, ninguna política(s) adicional puede hacer que se niegue cualquier conexión entrante a esos Pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier Pod.
+
+
+### Denegar por defecto todo el tráfico de salida
+
+Puedes crear una política que "por defecto" aisle el tráfico de salida para un Namespace, creando una NetworkPolicy que seleccione todos los Pods pero que no permita ningún tráfico de salida desde esos Pods.
+
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+
+Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tengan permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún Pod.
+
+
+### Permitir todo el tráfico de salida
+
+Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, puedes crear una política que permita explícitamente todas las conexiones salientes de los Pods de ese Namespace.
+
+{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+
+Con esta política en vigor, ninguna política(s) adicional puede hacer que se niegue cualquier conexión de salida desde esos Pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier Pod.
+
+
+### Denegar por defecto todo el tráfico de entrada y de salida
+
+Puede crear una política que "por defecto" en un Namespace impida todo el tráfico de entrada y de salida creando la siguiente NetworkPolicy en ese Namespace.
+
+{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+
+Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida.
+
+
+## Soporte a SCTP 
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+Como característica estable, está activada por defecto. Para deshabilitar SCTP a nivel de clúster, usted (o el administrador de su clúster) tiene que deshabilitar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SCTPSupport` para el API Server con el flag `--feature-gates=SCTPSupport=false,...`.
+Cuando esta feature gate está habilitada, puede establecer el campo `protocol` de una NetworkPolicy como `SCTP`.
+
+{{< note >}}
+Debes utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que soporte el protocolo SCTP NetworkPolicies.
+{{< /note >}}
+
+
+## Apuntar a un rango de puertos
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+Cuando se escribe una NetworkPolicy, se puede apuntar a un rango de puertos en lugar de un solo puerto.
+
+Esto se puede lograr con el uso del campo `endPort`, como el siguiente ejemplo:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: multi-port-egress
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+  - Egress
+  egress:
+  - to:
+    - ipBlock:
+        cidr: 10.0.0.0/24
+    ports:
+    - protocol: TCP
+      port: 32000
+      endPort: 32768
+```
+
+La regla anterior permite que cualquier Pod con la etiqueta `role=db` en el Namespace `default` se comunique 
+con cualquier IP dentro del rango `10.0.0.0/24` sobre el protocolo TCP, siempre que el puerto 
+esté entre el rango 32000 y 32768.
+
+Se aplican las siguientes restricciones al utilizar este campo:
+* Como característica en estado beta, está activada por defecto. Para desactivar el campo `endPort` a nivel de clúster, usted (o su administrador de clúster) debe desactivar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NetworkPolicyEndPort`  
+en el API Server con el flag `--feature-gates=NetworkPolicyEndPort=false,...`.
+* El campo `endPort` debe ser igual o mayor que el campo `port`.
+* Sólo se puede definir `endPort` si también se define `port`.
+* Ambos puertos deben ser numéricos.
+
+
+{{< note >}}
+Su clúster debe utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que
+soporte el campo `endPort` en las especificaciones de NetworkPolicy.
+Si su [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 
+no soporta el campo `endPort` y usted especifica una NetworkPolicy que use este campo,
+la política se aplicará sólo para el campo `port`.
+{{< /note >}}
+
+
+## Como apuntar a un Namespace usando su nombre
+
+{{< feature-state for_k8s_version="1.22" state="stable" >}}
+
+El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.io/metadata.name` en todos los
+Namespaces, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`.
+El valor de la etiqueta es el nombre del Namespace.
+
+Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un Namespace específico.
+
+
+ ## Que no puedes hacer con políticas de red (al menos, aún no)
+
+Actualmente, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión.  En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy.
+
+- Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy).
+- Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un Ingress controllers para esto).
+- Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente).
+- Apuntar Services por nombre (sin embargo, puede orientar los Pods o los Namespaces por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable).
+- Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero.
+- Políticas que por defecto son aplicadas a todos los Namespaces o Pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto).
+- Consulta avanzada de políticas y herramientas de accesibilidad.
+- La capacidad de registrar los eventos de seguridad de la red (por ejemplo, las conexiones bloqueadas o aceptadas).
+- La capacidad de negar explícitamente las políticas (actualmente el modelo para NetworkPolicies es negar por defecto, con sólo la capacidad de añadir reglas de permitir).
+- La capacidad de impedir el tráfico entrante de Loopback o de Host (actualmente los Pods no pueden bloquear el acceso al host local, ni tienen la capacidad de bloquear el acceso desde su nodo residente).
+
+
+## {{% heading "whatsnext" %}}
+
+- Leer el artículo de como [Declarar de Políticas de Red](/docs/tasks/administer-clúster/declare-network-policy/) para ver más ejemplos.
+- Ver más [recetas](https://github.com/ahmetb/kubernetes-network-policy-recipes) de escenarios comunes habilitados por los recursos de las NetworkPolicy.

content/es/examples/service/networking/network-policy-allow-all-egress.yaml

@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-egress
+spec:
+  podSelector: {}
+  egress:
+  - {}
+  policyTypes:
+  - Egress

content/es/examples/service/networking/network-policy-allow-all-ingress.yaml

@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-ingress
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress

content/es/examples/service/networking/network-policy-default-deny-all.yaml

@@ -0,0 +1,10 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+  - Egress

content/es/examples/service/networking/network-policy-default-deny-egress.yaml

@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-egress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Egress

content/es/examples/service/networking/network-policy-default-deny-ingress.yaml

@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-ingress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress

content/es/examples/service/networking/networkpolicy.yaml

@@ -0,0 +1,35 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+    - Ingress
+    - Egress
+  ingress:
+    - from:
+        - ipBlock:
+            cidr: 172.17.0.0/16
+            except:
+              - 172.17.1.0/24
+        - namespaceSelector:
+            matchLabels:
+              project: myproject
+        - podSelector:
+            matchLabels:
+              role: frontend
+      ports:
+        - protocol: TCP
+          port: 6379
+  egress:
+    - to:
+        - ipBlock:
+            cidr: 10.0.0.0/24
+      ports:
+        - protocol: TCP
+          port: 5978
+

content/pl/_index.html

@@ -44,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Weź udział w KubeCon Europe 17-20.06.2022</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Weź udział w KubeCon North America 24-28.10.2022</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Weź udział w KubeCon North America 24-28.10.2022</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023" button id="desktopKCButton">Weź udział w KubeCon Europe 17-21.04.2023</a>
 
 </div>
 <div id="videoPlayer">

content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md

@@ -0,0 +1,126 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+
+Crie tokens de inicialização no servidor
+
+### Sinopse
+
+Este comando criará um token de inicialização. Você pode especificar os usos para este token, o "tempo de vida" e uma descrição amigável, que é opcional.
+
+O [token] é o token real para gravar. Este deve ser um token aleatório gerado com segurança da forma "[a-z0-9]{6}.[a-z0-9]{16}". Se nenhum [token] for fornecido, o kubeadm gerará um token aleatório.
+
+```
+kubeadm token create [token]
+```
+
+### Opções
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--certificate-key string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Quando usado em conjunto com '--print-join-command', exibe a flag completa 'kubeadm join' necessária para se unir ao cluster como um nó de camada de gerenciamento. Para criar uma nova chave de certificado, você deve usar 'kubeadm init phase upload-certs --upload-certs'.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--config string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Caminho para o arquivo de configuração kubeadm.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--description string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Uma descrição amigável de como esse token é usado.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--groups strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "system:bootstrappers:kubeadm:default-node-token"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Grupos extras que este token autenticará quando usado para autenticação. Deve corresponder &quot;\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z&quot;</p></td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para create</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--print-join-command</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Em vez de exibir apenas o token, exibe a flag completa 'kubeadm join' necessária para se associar ao cluster usando o token.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--ttl duração&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: 24h0m0s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A duração antes do token ser excluído automaticamente (por exemplo, 1s, 2m, 3h). Se definido como '0', o token nunca expirará</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--usages strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "signing,authentication"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Descreve as maneiras pelas quais esse token pode ser usado. Você pode passar --usages várias vezes ou fornecer uma lista de opções separada por vírgulas. Opções válidas: [signing,authentication]</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+### Opções herdadas dos comandos superiores
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--dry-run</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
+</tr>
+
+</tbody>
+</table>

content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md

@@ -0,0 +1,80 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+
+Excluir tokens de inicialização no servidor
+
+### Sinopse
+
+Este comando excluirá uma lista de tokens de inicialização para você.
+
+O [token-value] é um Token completo na forma "[a-z0-9]{6}.[a-z0-9]{16}" ou o ID do Token na forma "[a-z0-9]{6}" a ser excluído.
+
+```
+kubeadm token delete [token-value] ...
+```
+
+### Opções
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para delete</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+### Opções herdadas dos comandos superiores
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--dry-run</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+

content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md

@@ -0,0 +1,82 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+
+Gere e exiba um token de inicialização, mas não o crie no servidor
+
+### Sinopse
+
+Este comando exibirá um token de inicialização gerado aleatoriamente que pode ser usado com os comandos "init" e "join".
+
+Você não precisa usar este comando para gerar um token. Você pode fazer isso sozinho, desde que esteja no formato "[a-z0-9]{6}.[a-z0-9]{16}". Este comando é fornecido por conveniência para gerar tokens no formato fornecido.
+
+Você também pode usar "kubeadm init" sem especificar um token e ele gerará e exibirá um para você.
+
+```
+kubeadm token generate [flags]
+```
+
+### Opções
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para generate</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+### Opções herdadas dos comandos superiores
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--dry-run</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+

content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md

@@ -0,0 +1,99 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+
+Liste tokens de inicialização no servidor
+
+### Sinopse
+
+Este comando listará todos os tokens de inicialização para você
+
+```
+kubeadm token list [flags]
+```
+
+### Opções
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--allow-missing-template-keys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: true</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Se verdadeiro (true), ignora quaisquer erros nos modelos quando um campo ou chave de mapa estiver faltando no modelo. Aplica-se apenas aos formatos de saída golang e jsonpath.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">-o, --experimental-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "text"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Formato de saída. Valores válidos: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para list</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--show-managed-fields</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Se verdadeiro (true), mantém os managedFields ao exibir os objetos no formato JSON ou YAML.</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+### Opções herdadas dos comandos superiores
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--dry-run</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
+</tr>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+

content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md

@@ -0,0 +1,72 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+
+Exibe a versão do kubeadm
+
+### Sinopse
+
+
+Exibe a versão do kubeadm
+
+```
+kubeadm version [flags]
+```
+
+### Opções
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para version</p></td>
+</tr>
+
+<tr>
+<td colspan="2">-o, --output string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Formato de saída; as opções disponíveis são 'yaml', 'json' e 'short'</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+### Opção herdada do comando superior
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
+</tr>
+
+</tbody>
+</table>
+
+
+

content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md

@@ -0,0 +1,27 @@
+---
+title: kubeadm token
+content_type: concept
+weight: 70
+---
+<!-- overview -->
+
+Os Bootstrap tokens são usados para estabelecer uma relação de confiança bidirecional entre um nó que se junta ao cluster e um nó do plano de controle, conforme descrito na [autenticação com tokens de inicialização](/docs/reference/access-authn-authz/bootstrap-tokens/).
+
+O `kubeadm init` cria um token inicial com um TTL de 24 horas. Os comandos a seguir permitem que você gerencie esse token e também crie e gerencie os novos.
+
+<!-- body -->
+## kubeadm token create {#cmd-token-create}
+{{< include "generated/kubeadm_token_create.md" >}}
+
+## kubeadm token delete {#cmd-token-delete}
+{{< include "generated/kubeadm_token_delete.md" >}}
+
+## kubeadm token generate {#cmd-token-generate}
+{{< include "generated/kubeadm_token_generate.md" >}}
+
+## kubeadm token list {#cmd-token-list}
+{{< include "generated/kubeadm_token_list.md" >}}
+
+## {{% heading "whatsnext" %}}
+
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md

@@ -0,0 +1,10 @@
+---
+title: kubeadm version
+content_type: concept
+weight: 80
+---
+<!-- overview -->
+Este comando exibe a versão do kubeadm.
+
+<!-- body -->
+{{< include "generated/kubeadm_version.md" >}}

content/zh-cn/case-studies/netease/index.html

@@ -1,105 +1,174 @@
 ---
 title: 案例研究：NetEase
+linkTitle: NetEase
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+logo: netease_featured_logo.png
+featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/netease/banner1.jpg
+heading_title_logo: /images/netease_logo.png
+subheading: >
+  NetEase 如何利用 Kubernetes 支持在全球的互联网业务
+case_study_details:
+  - 公司: NetEase
+  - 位置: Hangzhou， China
+  - 行业: 互联网科技
 ---
 
+<!-- 
+title: NetEase Case Study
+linkTitle: NetEase
+case_study_styles: true
+cid: caseStudies
+logo: netease_featured_logo.png
+featured: false
 
-<!-- <div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> How NetEase Leverages Kubernetes to Support Internet Business Worldwide</div></h1>
+new_case_study_styles: true
+heading_background: /images/case-studies/netease/banner1.jpg
+heading_title_logo: /images/netease_logo.png
+subheading: >
+  How NetEase Leverages Kubernetes to Support Internet Business Worldwide
+case_study_details:
+  - Company: NetEase
+  - Location: Hangzhou, China
+  - Industry: Internet technology
+-->
 
-</div> -->
-<div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
-  <h1> 案例研究：<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> 网易如何利用 Kubernetes 支持在全球的互联网业务</div></h1>
+<!-- 
+<h2>Challenge</h2>
+-->
+<h2>挑战</h2>
 
-</div>
+<!-- 
+<p>Its gaming business is one of the largest in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
+-->
+<p>其游戏业务是世界上最大的游戏业务之一，但这不是 <a href="https://netease-na.com/">NetEase</a> 为中国消费者提供的所有。公司还经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务有近10亿用户通过网站使用免费的电子邮件服务，如 <a href="https://www.163.com/">163.com</a>。在2015 年，为所有这些系统提供基础设施的 NetEase Cloud 团队意识到，他们的研发流程正在减缓开发人员的速度。NetEase Cloud 和容器服务架构师 Feng Changjian 表示：“我们的用户需要自己准备所有基础设施。”“我们希望通过无服务器容器服务自动为用户提供基础设施和工具。”</p>
 
+<!-- 
+<h2>Solution</h2>
+-->
+<h2>解决方案</h2>
 
-<div class="details" style="font-size:1em">
-    公司 &nbsp;<b>网易</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;位置 &nbsp;<b>杭州，中国</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>互联网科技</b>
-</div>
+<!-- 
+<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers.</p>
+-->
+<p>在考虑构建自己的业务流程解决方案后，NetEase 决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上 NetEase 的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”Feng Changjian 说。该团队于 2015 年开始与 Kubernetes 合作，那会它甚至还不是 1.0 版本。如今，NetEase 内部云平台还使用了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>、<a href="https://www.envoyproxy.io/">Envoy</a>、<a href="https://goharbor.io/">Harbor</a>、<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>， 在生产集群中运行 10000 个节点，并可支持集群多达 30000 个节点。基于对内部平台的学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，NetEase 轻舟微服务。</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="margin-left:-1.5% !important">
-    <h2>挑战</h2>
-         <!-- Its gaming business is one of the largest in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.” -->
-其游戏业务是世界上最大的游戏业务之一，但这不是<a href="https://netease-na.com/">网易</a>为中国消费者提供的所有。公司还经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务有近10亿用户通过网站使用免费的电子邮件服务，如<a href="https://www.163.com/">163.com</a>。2015 年，为所有这些系统提供基础设施的网易云团队意识到，他们的研发流程正在减缓开发人员的速度。网易云和容器服务架构师冯长健表示：“我们的用户需要自己准备所有基础设施。”“我们希望通过无服务器容器服务自动为用户提供基础设施和工具。”
-<br><br>
- <h2>解决方案</h2>
-      <!-- After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. -->
-在考虑构建自己的业务流程解决方案后，网易决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上网易的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”冯长健说。该团队于 2015 年开始与 Kubernetes 合作，那会它甚至还不是1.0版本。如今，网易内部云平台还使用了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>、<a href="https://www.envoyproxy.io/">Envoy</a>、<a href="https://goharbor.io/">Harbor</a>、<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>， 在生产集群中运行 10000 个节点，并可支持集群多达 30000 个节点。基于对内部平台的学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，网易轻舟微服务。
-
-
-<br><br>
+<!-- 
+<h2>Impact</h2>
+-->
 <h2>影响</h2>
-      <!-- The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments,” he says. Those improvements have also brought an increase in resource utilization. -->
-网易团队报告说，Kubernetes 已经提高了研发效率一倍多，部署效率提高了 2.8倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”冯长健说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。
-</div>
-</div>
 
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    <!-- "The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Zeng Yuxing, Architect, NetEase</span> -->
-    “系统可以在单个群集中支持 30000 个节点。在生产中，我们在单个群集中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— 曾宇兴,网易架构师</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <!-- <h2>Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.</h2>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.”<br><br> -->
- <h2>其游戏业务是世界<a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">第五大</a>游戏业务，但这不是<a href="https://netease-na.com/">网易</a>为消费者提供的所有业务。</h2>公司还在中国经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务是有近10亿用户使用的网站，如<a href="https://www.163.com/">163.com</a>和<a href="https://www.126.com/">126.com</a>免费电子邮件服务。有了这样的规模，为所有这些系统提供基础设施的网易云团队在 2015 年就意识到，他们的研发流程使得开发人员难以跟上需求。网易云和容器服务架构师冯长健表示：“我们的用户需要自己准备所有基础设施。”“我们渴望通过无服务器容器服务自动为用户提供基础设施和工具。”<br><br>
- <!-- After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng. -->
-在考虑构建自己的业务流程解决方案后，网易决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自谷歌，这一事实让团队有信心，它能够跟上网易的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”冯长健说。
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/netease/banner3.jpg')">
-  <div class="banner3text">
-    <!-- "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment." -->
-“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- 冯长健,网易云和容器托管平台架构师</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  <!-- The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. “We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework,” says Feng. “We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment.”<br><br> -->
-该团队于 2015 年开始采用 Kubernetes，那会它甚至还不是1.0版本，因为它相对易于使用，并且使 DevOps 在公司中得以实现。“我们放弃了 Kubernetes 的一些概念；我们只想使用标准化框架，”冯长健说。“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”<br><br>
-  <!-- The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. “We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices,” says Feng.<br><br> -->
-团队首先专注于构建容器平台以更好地管理资源，然后通过添加内部系统（如监视）来改进对微服务的支持。这意味着整合了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>，<a href="https://www.envoyproxy.io/">Envoy</a>，<a href="https://goharbor.io/">Harbor</a>，<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>。“我们正在努力提供简化和标准化的流程，以便我们的用户和客户能够利用我们的最佳实践，”冯长健说。<br><br>
-  <!-- And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment. -->
-团队正在继续改进。例如，企业的电子商务部分需要利用混合部署，过去需要使用两个单独的平台：基础架构即服务平台和 Kubernetes 平台。最近，网易创建了一个跨平台应用程序，支持将两者同时使用单命令部署。
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/netease/banner4.jpg')">
-  <div class="banner4text">
-    <!-- "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span> -->
-“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的有所助力的技术。”<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- 李兰青, 网易 Kubernetes 开发人员</span>
-  </div>
-  </div>
-</div>
+<!-- 
+<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments," he says. Those improvements have also brought an increase in resource utilization.</p>
+-->
+<p>NetEase 团队报告说，Kubernetes 已经提高了研发效率一倍多，部署效率提高了 2.8 倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”Feng Changjian 说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  <!-- Today, the NetEase internal cloud platform “can support 30,000 nodes in a single cluster,” says Architect Zeng Yuxing. “In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production.” <br><br> -->
-“系统可以在单个群集中支持 30000 个节点。在生产中，我们在单个群集中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”<br><br>
-  <!-- The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments.” Those improvements have also brought an increase in resource utilization. -->
-网易团队报告说，Kubernetes 已经提高了研发效率一倍多。部署效率提高了 2.8倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”冯长健说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。
+<!-- 
+{{< case-studies/quote author="Zeng Yuxing, Architect, NetEase" >}}
+"The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote author="Zeng Yuxing，NetEase 架构师" >}}
+“系统可以在单个集群中支持 30000 个节点。在生产中，我们在单个集群中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”
+{{< /case-studies/quote >}}
 
-</div>
+<!-- 
+{{< case-studies/lead >}}
+Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.
+{{< /case-studies/lead >}}
+-->
+{{< case-studies/lead >}}
+其游戏业务是世界<a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">第五大</a>游戏业务，但这不是 <a href="https://netease-na.com/">NetEase</a> 为消费者提供的所有业务。
+{{< /case-studies/lead >}}
 
-<div class="banner5">
-  <div class="banner5text">
-  <!-- "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span> -->
-“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- 李兰青, 网易 Kubernetes 开发人员</span>
-  </div>
-</div>
-<div class="fullcol">
-  <!-- Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. “The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users,” says Zeng. <br><br> -->
-基于使用内部平台的成果和学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，网易轻舟微服务。“我们的想法是，我们可以找到我们的游戏和电子商务以及云音乐提供商遇到的问题，所以我们可以整合他们的体验，并提供一个平台，以满足所有用户的需求，”曾宇兴说。<br><br>
-  <!-- With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. “As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them,” says Kubernetes developer Li Lanqing.<br><br> -->
-无论是否使用网易产品，该团队鼓励其他公司尝试 Kubernetes。Kubernetes 开发者李兰青表示：“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的技术，可以帮助他们。”<br><br>
-  <!-- As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they’ve done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. “We are a team focusing on addressing the challenges of microservices architecture,” says Feng. “By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved.” -->
-作为最终用户和供应商，网易已经更多地参与社区，向其他公司学习，分享他们所做的工作。该团队一直在为 Harbor 和 Envoy 项目做出贡献，在网易进行规模测试技术时提供反馈。“我们是一个团队，专注于应对微服务架构的挑战，”冯长健说。“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”
-</div>
-</section>
+<!-- 
+<p>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
+-->
+<p>公司还在中国经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务是有近 10 亿用户使用的网站，如 <a href="https://www.163.com/">163.com</a> 和 <a href="https://www.126.com/">126.com</a> 免费电子邮件服务。有了这样的规模，为所有这些系统提供基础设施的 NetEase Cloud 团队在 2015 年就意识到，他们的研发流程使得开发人员难以跟上需求。NetEase Cloud 和容器服务架构师 Feng Changjian 表示：“我们的用户需要自己准备所有基础设施。”“我们渴望通过无服务器容器服务自动为用户提供基础设施和工具。”</p>
+
+<!-- 
+<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng.</p>
+-->
+<p>在考虑构建自己的业务流程解决方案后，NetEase 决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上 NetEase 的规模。“经过 2 到 3 个月的评估，我们相信它能满足我们的需求，”Feng Changjian 说。</p>
+
+<!-- 
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner3.jpg"
+  author="Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase"
+>}}
+"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner3.jpg"
+  author="Feng Changjian，NetEase Cloud 和容器托管平台架构师"
+>}}
+“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”
+{{< /case-studies/quote >}}
+
+<!-- 
+<p>The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. "We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework," says Feng. "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."</p>
+-->
+<p>该团队于 2015 年开始采用 Kubernetes，那会它甚至还不是 1.0 版本，因为它相对易于使用，并且使 DevOps 在公司中得以实现。“我们放弃了 Kubernetes 的一些概念；我们只想使用标准化框架，”Feng Changjian 说。“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”</p>
+
+<!-- 
+<p>The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. "We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices," says Feng.</p>
+-->
+<p>团队首先专注于构建容器平台以更好地管理资源，然后通过添加内部系统（如监视）来改进对微服务的支持。这意味着整合了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>，<a href="https://www.envoyproxy.io/">Envoy</a>，<a href="https://goharbor.io/">Harbor</a>，<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>。“我们正在努力提供简化和标准化的流程，以便我们的用户和客户能够利用我们的最佳实践，”Feng Changjian 说。</p>
+
+<!-- 
+<p>And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.</p>
+-->
+<p>团队正在继续改进。例如，企业的电子商务部分需要利用混合部署，过去需要使用两个单独的平台：基础架构即服务平台和 Kubernetes 平台。最近，NetEase 创建了一个跨平台应用程序，支持将两者同时使用单命令部署。</p>
+
+<!-- 
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner4.jpg"
+  author="Li Lanqing, Kubernetes Developer, NetEase"
+>}}
+"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner4.jpg"
+  author="Li Lanqing，NetEase Kubernetes 开发人员"
+>}}
+“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的有所助力的技术。”
+{{< /case-studies/quote >}}
+
+<!-- 
+<p>Today, the NetEase internal cloud platform "can support 30,000 nodes in a single cluster," says Architect Zeng Yuxing. "In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."</p>
+-->
+<p>“如今，系统可以在单个集群中支持 30000 个节点，“架构师 Zeng Yuxing 说。“在生产中，我们在单个集群中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”</p>
+
+<!-- 
+<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments." Those improvements have also brought an increase in resource utilization.</p>
+-->
+<p>NetEase 团队报告说，Kubernetes 已经提高了研发效率一倍多。部署效率提高了 2.8 倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”Feng Changjian 说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。</p>
+
+<!-- 
+{{< case-studies/quote author="Li Lanqing, Kubernetes Developer, NetEase">}}
+"By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote author="Li Lanqing，NetEase Kubernetes 开发人员">}}
+“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”
+{{< /case-studies/quote >}}
+
+<!-- 
+<p>Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. "The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users," says Zeng.</p>
+-->
+<p>基于使用内部平台的成果和学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，<a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase 轻舟微服务</a>。“我们的想法是，我们可以找到我们的游戏和电子商务以及云音乐提供商遇到的问题，所以我们可以整合他们的体验，并提供一个平台，以满足所有用户的需求，”Zeng Yuxing 说。</p>
+
+<!-- 
+<p>With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them," says Kubernetes developer Li Lanqing.</p>
+-->
+<p>无论是否使用 NetEase 产品，该团队鼓励其他公司尝试 Kubernetes。Kubernetes 开发者 Li Lanqing 表示：“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的技术，可以帮助他们。”</p>
+
+<!-- 
+<p>As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they've done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. "We are a team focusing on addressing the challenges of microservices architecture," says Feng. "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."</p>
+-->
+<p>作为最终用户和供应商，NetEase 已经更多地参与社区，向其他公司学习，分享他们所做的工作。该团队一直在为 Harbor 和 Envoy 项目做出贡献，在 NetEase 进行规模测试技术时提供反馈。“我们是一个团队，专注于应对微服务架构的挑战，”Feng Changjian 说。“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”</p>

content/zh-cn/case-studies/nordstrom/index.html

@@ -2,151 +2,156 @@
 title: 案例研究：Nordstrom
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nordstrom/banner1.jpg
+heading_title_logo: /images/nordstrom_logo.png
+subheading: >
+  在艰难的零售环境下寻找数百万的潜在成本节约
+case_study_details:
+  - 公司: Nordstrom
+  - 地点: Seattle, Washington
+  - 行业: 零售
 ---
-
-<!-- <div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate
-
-</div></h1>
-
-</div> -->
-
-<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
-  <h1> 案例研究:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">在艰难的零售环境下寻找数百万的潜在成本节约
-
-
-</div></h1>
-
-</div>
-
-<!-- <div class="details">
-    Company &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Seattle, Washington</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail</b>
-</div> -->
-
-<div class="details">
-    公司 &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;地点 &nbsp;<b>西雅图, 华盛顿</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>零售</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <!-- <h2>Challenge</h2>
-    Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs. -->
-
+<!-- 
+<h2>Challenge</h2>
+-->
 <h2>挑战</h2>
-Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom.com 电子商务网站。与此同时，Nordstrom 技术公司正在寻找压缩技术运营成本的方法。
 
-<br>
-    <!-- <h2>Solution</h2>
-    After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>. -->
+<!--
+<p>Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.</p>
+-->
+<p>Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom.com 电子商务网站。与此同时，Nordstrom 技术公司正在寻找压缩技术运营成本的方法。</p>
 
+<!-- 
+<h2>Solution</h2>
+-->
 <h2>解决方案</h2>
-在四年前采用 DevOps 转型并启动持续集成/部署 (CI/CD)项目后，该公司将部署时间从 3 个月缩短到 30 分钟。但是他们想在部署环境上走得更快，所以他们开始他们的云原生之旅，采用与<a href="http://kubernetes.io/"> Kubernetes </a>协调的Docker容器。
 
-  <br>
-
-
-</div>
-
-<div class="col2">
-
-  <!-- <h2>Impact</h2>
-  Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren’t effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase." -->
+<!-- 
+<p>After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.</p>
+-->
+<p>在四年前采用 DevOps 转型并启动持续集成/部署 (CI/CD)项目后，该公司将部署时间从 3 个月缩短到 30 分钟。但是他们想在部署环境上走得更快，所以他们开始他们的云原生之旅，采用与 <a href="http://kubernetes.io/">Kubernetes</a> 协调的 Docker 容器。</p>
 
+<!--
+<h2>Impact</h2>
+-->
 <h2>影响</h2>
-为 Nordstrom 构建 Kubernetes 企业平台的团队高级工程师 Dhawal Patel 说，“使用 Kubernetes 的 Nordstrom 技术开发人员现在项目部署得更快，并且能够只专注于编写应用程序。”此外，该团队还提高了运营效率,根据工作负载将 CPU 利用率从 5 倍提高到 12 倍。Patel 说：“我们运行了数千台虚拟机 (VM),但无法有效地使用所有这些资源。借助  Kubernetes ,我们甚至不需要尝试去提高群集的效率,就能使运营效率增长 10 倍。”
 
-</div>
-</div>
-</section>
-<div class="banner2">
-<div class="banner2text">
-<!-- "We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It’s a win-win." -->
-“我们一直在寻找通过技术进行优化和提供更多价值的方法。通过 Kubernetes ，我们在开发效率和运营效率这两方面取得了示范性的提升。这是一个双赢。”
-<!-- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, senior engineer at Nordstrom</span> -->
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, Nordstrom 高级工程师</span>
-</div>
-</div>
-<section class="section2">
-<div class="fullcol">
-<!-- When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer’s website, he realized there was an opportunity to help speed up development cycles. -->
-当 Dhawal Patel 五年前加入<a href="http://shop.nordstrom.com/"> Nordstrom </a>，担任该零售商网站的应用程序开发人员时，他意识到有机会帮助加快开发周期。
-<br><br>
-<!-- In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it." -->
-在早期的 DevOps 时代,，Nordstrom 技术仍然遵循传统的孤岛团队和功能模型。Patel 说：“作为开发人员，我花在维护环境上的时间比编写代码和为业务增加价值的时间要多。我对此充满热情，因此我有机会参与帮助修复它。”
-<br><br>
-<!-- The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom’s cloud native journey. -->
-公司也渴望加快步伐，并在 2013 年启动了首个持续集成/部署 (CI/CD)项目。该项目是 Nordstrom 云原生之旅的第一步。
-<br><br>
-<!-- Dev and Ops team members built a CI/CD pipeline, working with the company’s servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point." -->
-开发人员和运营团队成员构建了一个 CI/CD 管道，在内部使用公司的服务器。团队选择了<a href="https://www.chef.io/chef/"> Chef </a>，并编写了自动虚拟 IP 创建、服务器和负载均衡的指导手册。Patel 说：“项目完成后,部署时间从 3 个月减少到 30 分钟。我们仍有开发、测试、暂存、然后生产等多个环境需要重新部署。之后，每个运行 Chef 说明书的环境部署都只花 30 分钟。在那个时候，这是一个巨大的成就。”
-<br><br>
-<!-- But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company’s 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes. -->
-但是，新环境仍然需要很长时间才能出现，因此下一步是在云中工作。如今，Nordstrom  Technology 已经构建了一个企业平台，允许公司的1500 名开发人员在云中部署以 Docker 容器身份运行的应用程序，这些应用程序由 Kubernetes 进行编排。
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
-<div class="banner3text">
-<!-- "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," -->
+<!-- 
+<p>Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren't effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."</p>
+-->
+<p>为 Nordstrom 构建 Kubernetes 企业平台的团队高级工程师 Dhawal Patel 说，“使用 Kubernetes 的 Nordstrom 技术开发人员现在项目部署得更快，并且能够只专注于编写应用程序。”此外，该团队还提高了运营效率，根据工作负载将 CPU 利用率从 5 倍提高到 12 倍。Patel 说：“我们运行了数千台虚拟机（VM），但无法有效地使用所有这些资源。借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，就能使运营效率增长 10 倍。”</p>
+
+<!-- 
+{{< case-studies/quote author="Dhawal Patel, senior engineer at Nordstrom" >}}
+"We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It's a win-win."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote author="Dhawal Patel， Nordstrom 高级工程师" >}}
+“我们一直在寻找通过技术进行优化和提供更多价值的方法。通过 Kubernetes，我们在开发效率和运营效率这两方面取得了示范性的提升。这是一个双赢。”
+{{< /case-studies/quote >}}
+
+<!-- 
+<p>When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer's website, he realized there was an opportunity to help speed up development cycles.</p> -->
+<p>当 Dhawal Patel 五年前加入 <a href="http://shop.nordstrom.com/">Nordstrom</a>，担任该零售商网站的应用程序开发人员时，他意识到有机会帮助加快开发周期。</p>
+
+<!-- 
+<p>In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."</p>
+-->
+<p>在早期的 DevOps 时代，Nordstrom 技术仍然遵循传统的孤岛团队和功能模型。Patel 说：“作为开发人员，我花在维护环境上的时间比编写代码和为业务增加价值的时间要多。我对此充满热情，因此我有机会参与帮助修复它。”</p>
+
+<!-- 
+<p>The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom's cloud native journey.</p>
+-->
+<p>公司也渴望加快步伐，并在 2013 年启动了首个持续集成/部署（CI/CD）项目。该项目是 Nordstrom 云原生之旅的第一步。</p>
+
+<!-- 
+<p>Dev and Ops team members built a CI/CD pipeline, working with the company's servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."</p>
+-->
+<p>开发人员和运营团队成员构建了一个 CI/CD 管道，在内部使用公司的服务器。团队选择了 <a href="https://www.chef.io/chef/">Chef</a>，并编写了自动虚拟 IP 创建、服务器和负载均衡的指导手册。Patel 说：“项目完成后，部署时间从 3 个月减少到 30 分钟。我们仍有开发、测试、暂存、然后生产等多个环境需要重新部署。之后，每个运行 Chef 说明书的环境部署都只花 30 分钟。在那个时候，这是一个巨大的成就。”</p>
+
+<!-- 
+<p>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company's 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.</p> -->
+<p>但是，新环境仍然需要很长时间才能出现，因此下一步是在云中工作。如今，Nordstrom  Technology 已经构建了一个企业平台，允许公司的 1500 名开发人员在云中部署以 Docker 容器身份运行的应用程序，这些应用程序由 Kubernetes 进行编排。</p>
+
+<!-- 
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
+"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
 “了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”
-</div>
-</div>
-<section class="section3">
-<div class="fullcol">
+{{< /case-studies/quote >}}
 
-<!-- "The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes." -->
-Patel 说：“云提供了对资源的更快访问,因为我们在内部需要花数周时间才能部署一个虚拟机 (VM)来提供服务。但现在我们可以做同样的事情，只需五分钟。”
-<br><br>
-<!-- Nordstrom’s first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom. -->
-Nordstrom 首次尝试在集群上调度容器，是基于 CoreOS fleet 的原生系统。他们开始使用该系统做一些概念验证项目，直到 Kubernetes 1.0发布时才将正式项目迁移到里面。Nordstrom 的 Kubernetes 团队经理 Marius Grigoriu 表示：“了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”
-<!-- While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes." -->
-虽然 Kubernetes 通常被视为微服务的平台，但在 Nordstrom 担任关键生产角色的 Kubernetes 上推出的第一个应用程序是 Jira。Patel 承认：“这不是我们希望作为第一个应用程序获得的理想微服务，但致力于此应用程序的团队对 Docker 和 Kubernetes 非常热情，他们希望尝试一下。他们的应用程序部署在内部运行，并希望将其移动到 Kubernetes。
-<br><br>
-<!-- The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -->
-对于加入的团队来说,这些好处是立竿见影的。Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
-  <div class="banner4text">
- <!-- "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -->
+<!-- 
+<p>"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."</p>
+-->
+<p>Patel 说：“云提供了对资源的更快访问，因为我们在内部需要花数周时间才能部署一个虚拟机（VM）来提供服务。但现在我们可以做同样的事情，只需五分钟。”</p>
+
+<!-- 
+<p>Nordstrom's first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.</p>
+-->
+<p>Nordstrom 首次尝试在集群上调度容器，是基于 CoreOS fleet 的原生系统。他们开始使用该系统做一些概念验证项目，直到 Kubernetes 1.0 发布时才将正式项目迁移到里面。Nordstrom 的 Kubernetes 团队经理 Marius Grigoriu 表示：“了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”</p>
+
+<!-- 
+<p>While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."</p>
+-->
+<p>虽然 Kubernetes 通常被视为微服务的平台，但在 Nordstrom 担任关键生产角色的 Kubernetes 上推出的第一个应用程序是 Jira。Patel 承认：“这不是我们希望作为第一个应用程序获得的理想微服务，但致力于此应用程序的团队对 Docker 和 Kubernetes 非常热情，他们希望尝试一下。他们的应用程序部署在内部运行，并希望将其移动到 Kubernetes。</p>
+
+<!-- 
+<p>The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."</p> -->
+<p>对于加入的团队来说，这些好处是立竿见影的。Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。</p>
+
+<!-- 
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
+"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
 Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。”
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section5">
-<div class="fullcol">
-  <!-- To support these early adopters, Patel’s team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam. -->
-为了支持这些早期使用者，Patel 的团队开始发展集群并构建生产级服务。“我们与<a href="https://prometheus.io/"> Prometheus </a>集成了监控功能，并配有<a href="https://grafana.com/"> Grafana </a>前端；我们使用<a href="http://www.fluentd.org/"> Fluentd </a>将日志推送到<a href="https://www.elastic.co/"> Elasticsearch </a>，从而提供日志聚合”Patel 说。该团队还增加了数十个开源组件，包括 CNCF 项目，而且把这些成果都贡献给了 Kubernetes 、Terraform 和 kube2iam 。
- <br><br>
-<!-- There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in." -->
-现在有60多个开发团队在 Nordstrom 上运行 Kubernetes ，随着成功案例的涌现，更多的团队加入
-进来。Patel 说：“我们最初的客户群，那些愿意尝试这些的客户群，现在已经开始向后续用户宣传。一个早期使用者拥有 Docker 容器，他不知道如何在生产中运行它。我们和他坐在一起，在15分钟内，我们将其部署到生产中。他认为这是惊人的，他所在的组织更多的人开始加入进来。”
- <br><br>
-<!-- For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes. -->
-对于 Nordstrom 而言，云原生极大地提高了开发和运营
-效率。现在，使用 Kubernetes 的开发人员部署速度更快，可以专注于在其应用程序中构建价值。一个团队从 25 分钟的合并开始，通过在云中启动虚拟机来进行部署。切换到 Kubernetes 的过程速度是原来 5 倍，将合并时间缩短为 5 分钟。
-</div>
+<!-- 
+<p>To support these early adopters, Patel's team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.</p>
+-->
+<p>为了支持这些早期使用者，Patel 的团队开始发展集群并构建生产级服务。“我们与 <a href="https://prometheus.io/">Prometheus</a> 集成了监控功能，并配有 <a href="https://grafana.com/">Grafana</a> 前端；我们使用 <a href="http://www.fluentd.org/">Fluentd</a> 将日志推送到 <a href="https://www.elastic.co/">Elasticsearch</a>，从而提供日志聚合”Patel 说。该团队还增加了数十个开源组件，包括 CNCF 项目，而且把这些成果都贡献给了 Kubernetes、Terraform 和 kube2iam。</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    <!-- "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead." -->
-“借助 Kubernetes ，我们甚至不需要尝试去提高群集的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 pod ，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
-  </div>
-</div>
+<!-- 
+<p>There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."</p>
+-->
+<p>现在有 60 多个开发团队在 Nordstrom 上运行 Kubernetes，随着成功案例的涌现，更多的团队加入进来。Patel 说：“我们最初的客户群，那些愿意尝试这些的客户群，现在已经开始向后续用户宣传。一个早期使用者拥有 Docker 容器，他不知道如何在生产中运行它。我们和他一起协作，在 15 分钟内，我们将其部署到生产中。他认为这是惊人的，他所在的组织更多的人开始加入进来。”</p>
 
-<div class="fullcol">
-  <!-- Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead." -->
-速度是伟大的，并且很容易证明，但也许更大的影响在于运营效率。Patel 说：“我们在 AWS 上运行了数千个 VM ，它们的总体平均 CPU 利用率约为 4%。借助 Kubernetes ，我们甚至不需要尝试去提高群集的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 pod ，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
-<br><br>
-  <!-- Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they’re only working with Kubernetes." -->
-Patel 说：“如果我们能构建一个本地 Kubernetes 集群，我们就能将云的力量带到本地快速调配资源。然后，对于开发人员，他们的接口是Kubernetes；他们甚至可能没有意识到或不关心他们的服务现在部署在内部，因为他们只与 Kubernetes 合作。
-  <!-- For that reason, Patel is eagerly following Kubernetes’ development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud." -->
-因此，Patel 热切关注 Kubernetes 多集群能力的发展。他说：“有了集群联合，我们可以将内部部署作为主群集，将云作为辅助可突发集群。因此,当有周年销售或黑色星期五销售,我们需要更多的容器时，我们可以去云。”
-<br><br>
-  <!-- That kind of possibility—as well as the impact that Grigoriu and Patel’s team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It’s a win-win." -->
-这种可能性以及 Grigoriu 和 Patel 的团队已经使用Kubernetes所提供的影响，是 Nordstrom 最初在云原生之旅中所起
-的作用。Grigoriu 说：“在当下的零售模式下，我们正在努力在力所能及的地方建立响应能力和灵活性。Kubernetes 使得为开发端和运维端同时带来效率的提升，这是一个双赢。”
-</div>
-</section>
+<!-- 
+<p>For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.</p>
+-->
+<p>对于 Nordstrom 而言，云原生极大地提高了开发和运营效率。现在，使用 Kubernetes 的开发人员部署速度更快，可以专注于在其应用程序中构建价值。一个团队从 25 分钟的合并开始，通过在云中启动虚拟机来进行部署。切换到 Kubernetes 的过程速度是原来 5 倍，将合并时间缩短为 5 分钟。</p>
+
+<!-- 
+{{< case-studies/quote >}}
+"With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."
+{{< /case-studies/quote >}}
+-->
+{{< case-studies/quote >}}
+“借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 Pod，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
+{{< /case-studies/quote >}}
+
+<!-- 
+<p>Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."</p>
+-->
+<p>速度很重要，并且很容易证明，但也许更大的影响在于运营效率。Patel 说：“我们在 AWS 上运行了数千个 VM，它们的总体平均 CPU 利用率约为 4%。借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 Pod，如果它们直接上云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。</p>
+
+<!-- 
+<p>Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they're only working with Kubernetes."</p>
+-->
+<p>Patel 说：“如果我们能构建一个本地 Kubernetes 集群，我们就能将云的力量带到本地快速调配资源。之后对于开发人员来说，他们面向的接口是 Kubernetes；他们甚至可能没有意识到或不关心他们的服务现在部署在内部，因为他们只与 Kubernetes 一起工作。</p>
+
+<!-- 
+<p>For that reason, Patel is eagerly following Kubernetes' development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."</p>
+-->
+<p>因此，Patel 热切关注 Kubernetes 多集群能力的发展。他说：“有了集群联合，我们可以将内部部署作为主集群，将云作为辅助可突发集群。因此，当有周年销售或黑色星期五销售并且我们需要更多的容器时，我们可以上云。”</p>
+
+<!-- 
+<p>That kind of possibility—as well as the impact that Grigoriu and Patel's team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It's a win-win."</p>
+-->
+<p>这种可能性以及 Grigoriu 和 Patel 的团队已经使用Kubernetes所提供的影响，是 Nordstrom 最初在云原生之旅中所起的作用。Grigoriu 说：“在当下的零售模式下，我们正在努力在力所能及的地方建立响应能力和灵活性。Kubernetes 使得为开发端和运维端同时带来效率的提升，这是一个双赢。”</p>

content/zh-cn/docs/concepts/overview/working-with-objects/names.md

@@ -3,6 +3,14 @@ title: 对象名称和 IDs
 content_type: concept
 weight: 20
 ---
+<!--
+reviewers:
+- mikedanese
+- thockin
+title: Object Names and IDs
+content_type: concept
+weight: 20
+-->
 
 <!-- overview -->
 
@@ -21,10 +29,10 @@ For example, you can only have one Pod named `myapp-1234` within the same [names
 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。
 
 <!--
-For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
+For non-unique user-provided attributes, Kubernetes provides [labels](/docs/concepts/overview/working-with-objects/labels/) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
 -->
 对于用户提供的非唯一性的属性，Kubernetes 提供了
-[标签（Labels）](/zh-cn/docs/concepts/working-with-objects/labels)和
+[标签（Labels）](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和
 [注解（Annotation）](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)机制。
 
 <!-- body -->
@@ -75,7 +83,7 @@ DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123)
 - 必须以字母数字结尾
 
 <!--
-### DNS Label Names
+### RFC 1123 Label Names {#dns-label-names}
 
 Some resource types require their names to follow the DNS
 label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
@@ -132,7 +140,7 @@ not contain "/" or "%".
 换句话说，其名称不能是 `.`、`..`，也不可以包含 `/` 或 `%` 这些字符。
 
 <!--
-Here’s an example manifest for a Pod named `nginx-demo`.
+Here's an example manifest for a Pod named `nginx-demo`.
 -->
 下面是一个名为 `nginx-demo` 的 Pod 的配置清单：
 
@@ -149,10 +157,10 @@ spec:
     - containerPort: 80
 ```
 
+{{< note >}}
 <!--
 Some resource types have additional restrictions on their names.
 -->
-{{< note >}}
 某些资源类型可能具有额外的命名约束。
 {{< /note >}}
 
@@ -175,5 +183,3 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
 -->
 * 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)
 * 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md)的设计文档
-
-

content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -17,40 +17,45 @@ weight: 20
 <!-- overview -->
 
 <!--
-You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
-{{< glossary_tooltip text="node(s)" term_id="node" >}}.
+You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it is 
+_restricted_ to run on particular {{< glossary_tooltip text="node(s)" term_id="node" >}},
+or to _prefer_ to run on particular nodes.
 There are several ways to do this and the recommended approaches all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
-Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
+Often, you do not need to set any such constraints; the
+{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}  will automatically do a reasonable placement
 (for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
 However, there are some circumstances where you may want to control which node
-the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two different
-services that communicate a lot into the same availability zone.
+the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it,
+or to co-locate Pods from two different services that communicate a lot into the same availability zone.
 -->
 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}
-只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
+以便 **限制** 其只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行，
+或优先在特定的节点上运行。
 有几种方法可以实现这点，推荐的方法都是用
 [标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来进行选择。
 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，
 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制
-Pod 被部署到的节点。例如，确保 Pod 最终落在连接了 SSD 的机器上，
+Pod 被部署到哪个节点。例如，确保 Pod 最终落在连接了 SSD 的机器上，
 或者将来自两个不同的服务且有大量通信的 Pods 被放置在同一个可用区。
 
 <!-- body -->
 
 <!--
 You can use any of the following methods to choose where Kubernetes schedules
-specific Pods: 
+specific Pods:
 
-* [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
-* [Affinity and anti-affinity](#affinity-and-anti-affinity)
-* [nodeName](#nodename) field
+  * [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
+  * [Affinity and anti-affinity](#affinity-and-anti-affinity)
+  * [nodeName](#nodename) field
+  * [Pod topology spread constraints](#pod-topology-spread-constraints)
 -->
 你可以使用下列方法中的任何一种来选择 Kubernetes 对特定 Pod 的调度：
 
 * 与[节点标签](#built-in-node-labels)匹配的 [nodeSelector](#nodeSelector)
 * [亲和性与反亲和性](#affinity-and-anti-affinity)
 * [nodeName](#nodename) 字段
+* [Pod 拓扑分布约束](#pod-topology-spread-constraints)
 
 <!--
 ## Node labels {#built-in-node-labels}
@@ -328,12 +333,12 @@ For example, consider the following Pod spec:
 
 <!--
 If there are two possible nodes that match the
-`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
+`preferredDuringSchedulingIgnoredDuringExecution` rule, one with the
 `label-1:key-1` label and another with the `label-2:key-2` label, the scheduler
 considers the `weight` of each node and adds the weight to the other scores for
 that node, and schedules the Pod onto the node with the highest final score.
 -->
-如果存在两个候选节点，都满足 `requiredDuringSchedulingIgnoredDuringExecution` 规则，
+如果存在两个候选节点，都满足 `preferredDuringSchedulingIgnoredDuringExecution` 规则，
 其中一个节点具有标签 `label-1:key-1`，另一个节点具有标签 `label-2:key-2`，
 调度器会考察各个节点的 `weight` 取值，并将该权重值添加到节点的其他得分值之上，
 
@@ -392,8 +397,8 @@ NodeAffinity specified in the PodSpec.
 That is, in order to match the Pod, nodes need to satisfy `addedAffinity` and
 the Pod's `.spec.NodeAffinity`.
 -->
-这里的 `addedAffinity` 除遵从 Pod 规约中设置的节点亲和性之外，还
-适用于将 `.spec.schedulerName` 设置为 `foo-scheduler`。
+这里的 `addedAffinity` 除遵从 Pod 规约中设置的节点亲和性之外，
+还适用于将 `.spec.schedulerName` 设置为 `foo-scheduler`。
 换言之，为了匹配 Pod，节点需要满足 `addedAffinity` 和 Pod 的 `.spec.NodeAffinity`。
 
 <!--
@@ -627,33 +632,35 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
 -->
 用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector`
 是对名字空间集合进行标签查询的机制。
-亲和性条件会应用到 `namespaceSelector` 所选择的名字空间和 `namespaces` 字段中
-所列举的名字空间之上。
+亲和性条件会应用到 `namespaceSelector` 所选择的名字空间和 `namespaces` 字段中所列举的名字空间之上。
 注意，空的 `namespaceSelector`（`{}`）会匹配所有名字空间，而 null 或者空的
 `namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
 
-
 <!--
 #### More practical use-cases
 
 Inter-pod affinity and anti-affinity can be even more useful when they are used with higher
 level collections such as ReplicaSets, StatefulSets, Deployments, etc.  These
 rules allow you to configure that a set of workloads should
-be co-located in the same defined topology, eg., the same node.
+be co-located in the same defined topology; for example, preferring to place two related
+Pods onto the same node.
 -->
 #### 更实际的用例
 
 Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSet、StatefulSet、
 Deployment 等）一起使用时，它们可能更加有用。
-这些规则使得你可以配置一组工作负载，使其位于相同定义拓扑（例如，节点）中。
+这些规则使得你可以配置一组工作负载，使其位于所定义的同一拓扑中；
+例如优先将两个相关的 Pod 置于相同的节点上。
 
 <!--
-Take, for example, a three-node cluster running a web application with an
-in-memory cache like redis. You could use inter-pod affinity and anti-affinity
-to co-locate the web servers with the cache as much as possible.
+For example: imagine a three-node cluster. You use the cluster to run a web application
+and also an in-memory cache (such as Redis). For this example, also assume that latency between
+the web application and the memory cache should be as low as is practical. You could use inter-pod
+affinity and anti-affinity to co-locate the web servers with the cache as much as possible.
 -->
-以一个三节点的集群为例，该集群运行一个带有 Redis 这种内存缓存的 Web 应用程序。
-你可以使用节点间的亲和性和反亲和性来尽可能地将 Web 服务器与缓存并置。
+以一个三节点的集群为例。你使用该集群运行一个带有内存缓存（例如 Redis）的 Web 应用程序。
+在此例中，还假设 Web 应用程序和内存缓存之间的延迟应尽可能低。
+你可以使用 Pod 间的亲和性和反亲和性来尽可能地将该 Web 服务器与缓存并置。
 
 <!--
 In the following example Deployment for the redis cache, the replicas get the label `app=store`. The
@@ -696,14 +703,14 @@ spec:
 ```
 
 <!--
-The following Deployment for the web servers creates replicas with the label `app=web-store`. The
-Pod affinity rule tells the scheduler to place each replica on a node that has a
-Pod with the label `app=store`. The Pod anti-affinity rule tells the scheduler
-to avoid placing multiple `app=web-store` servers on a single node.
+The following example Deployment for the web servers creates replicas with the label `app=web-store`.
+The Pod affinity rule tells the scheduler to place each replica on a node that has a Pod
+with the label `app=store`. The Pod anti-affinity rule tells the scheduler never to place
+multiple `app=web-store` servers on a single node.
 -->
-下面的 Deployment 用来提供 Web 服务器服务，会创建带有标签 `app=web-store` 的副本。
-Pod 亲和性规则告诉调度器将副本放到运行有标签包含 `app=store` Pod 的节点上。
-Pod 反亲和性规则告诉调度器不要在同一节点上放置多个 `app=web-store` 的服务器。
+下例的 Deployment 为 Web 服务器创建带有标签 `app=web-store` 的副本。
+Pod 亲和性规则告诉调度器将每个副本放到存在标签为 `app=store` 的 Pod 的节点上。
+Pod 反亲和性规则告诉调度器决不要在单个节点上放置多个 `app=web-store` 服务器。
 
 ```yaml
 apiVersion: apps/v1
@@ -756,11 +763,20 @@ where each web server is co-located with a cache, on three separate nodes.
 | *webserver-1*        |   *webserver-2*     |    *webserver-3*   |
 |  *cache-1*           |     *cache-2*       |     *cache-3*      |
 
+<!-- 
+The overall effect is that each cache instance is likely to be accessed by a single client, that
+is running on the same node. This approach aims to minimize both skew (imbalanced load) and latency. 
+-->
+总体效果是每个缓存实例都非常可能被在同一个节点上运行的某个客户端访问。
+这种方法旨在最大限度地减少偏差（负载不平衡）和延迟。
+
 <!--
+You might have other reasons to use Pod anti-affinity.
 See the [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
 for an example of a StatefulSet configured with anti-affinity for high
 availability, using the same technique as this example.
 -->
+你可能还有使用 Pod 反亲和性的一些其他原因。
 参阅 [ZooKeeper 教程](/zh-cn/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
 了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用，
 所使用的是与此例相同的技术。
@@ -820,6 +836,27 @@ The above Pod will only run on the node `kube-01`.
 -->
 上面的 Pod 只能运行在节点 `kube-01` 之上。
 
+<!-- 
+## Pod topology spread constraints
+
+You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}}
+are spread across your cluster among failure-domains such as regions, zones, nodes, or among any other
+topology domains that you define. You might do this to improve performance, expected availability, or
+overall utilization.
+
+Read [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
+to learn more about how these work. 
+-->
+## Pod 拓扑分布约束 {#pod-topology-spread-constraints}
+
+你可以使用 **拓扑分布约束（Topology Spread Constraints）** 来控制
+{{< glossary_tooltip text="Pod" term_id="Pod" >}} 在集群内故障域之间的分布，
+故障域的示例有区域（Region）、可用区（Zone）、节点和其他用户自定义的拓扑域。
+这样做有助于提升性能、实现高可用或提升资源利用率。
+
+阅读 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
+以进一步了解这些约束的工作方式。
+
 ## {{% heading "whatsnext" %}}
 
 <!--

content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md

@@ -0,0 +1,867 @@
+---
+title: Pod 拓扑分布约束
+content_type: concept
+weight: 40
+---
+
+<!-- 
+title: Pod Topology Spread Constraints
+content_type: concept
+weight: 40 
+-->
+
+<!-- overview -->
+
+<!-- 
+You can use _topology spread constraints_ to control how
+{{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster
+among failure-domains such as regions, zones, nodes, and other user-defined topology
+domains. This can help to achieve high availability as well as efficient resource
+utilization.
+
+You can set [cluster-level constraints](#cluster-level-default-constraints) as a default,
+or configure topology spread constraints for individual workloads. 
+-->
+你可以使用 **拓扑分布约束（Topology Spread Constraints）** 来控制
+{{< glossary_tooltip text="Pod" term_id="Pod" >}} 在集群内故障域之间的分布，
+例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。
+这样做有助于实现高可用并提升资源利用率。
+
+你可以将[集群级约束](#cluster-level-default-constraints)设为默认值，或为个别工作负载配置拓扑分布约束。
+
+<!-- body -->
+
+<!-- 
+## Motivation
+
+Imagine that you have a cluster of up to twenty nodes, and you want to run a
+{{< glossary_tooltip text="workload" term_id="workload" >}}
+that automatically scales how many replicas it uses. There could be as few as
+two Pods or as many as fifteen.
+When there are only two Pods, you'd prefer not to have both of those Pods run on the
+same node: you would run the risk that a single node failure takes your workload
+offline.
+
+In addition to this basic usage, there are some advanced usage examples that
+enable your workloads to benefit on high availability and cluster utilization. 
+-->
+## 动机 {#motivation}
+
+假设你有一个最多包含二十个节点的集群，你想要运行一个自动扩缩的
+{{< glossary_tooltip text="工作负载" term_id="workload" >}}，请问要使用多少个副本？
+答案可能是最少 2 个 Pod，最多 15 个 Pod。
+当只有 2 个 Pod 时，你倾向于这 2 个 Pod 不要同时在同一个节点上运行：
+你所遭遇的风险是如果放在同一个节点上且单节点出现故障，可能会让你的工作负载下线。
+
+除了这个基本的用法之外，还有一些高级的使用案例，能够让你的工作负载受益于高可用性并提高集群利用率。
+
+<!-- 
+As you scale up and run more Pods, a different concern becomes important. Imagine
+that you have three nodes running five Pods each. The nodes have enough capacity
+to run that many replicas; however, the clients that interact with this workload
+are split across three different datacenters (or infrastructure zones). Now you
+have less concern about a single node failure, but you notice that latency is
+higher than you'd like, and you are paying for network costs associated with
+sending network traffic between the different zones.
+
+You decide that under normal operation you'd prefer to have a similar number of replicas
+[scheduled](/docs/concepts/scheduling-eviction/) into each infrastructure zone,
+and you'd like the cluster to self-heal in the case that there is a problem.
+
+Pod topology spread constraints offer you a declarative way to configure that.
+-->
+随着你的工作负载扩容，运行的 Pod 变多，将需要考虑另一个重要问题。
+假设你有 3 个节点，每个节点运行 5 个 Pod。这些节点有足够的容量能够运行许多副本；
+但与这个工作负载互动的客户端分散在三个不同的数据中心（或基础设施可用区）。
+现在你可能不太关注单节点故障问题，但你会注意到延迟高于自己的预期，
+在不同的可用区之间发送网络流量会产生一些网络成本。
+
+你决定在正常运营时倾向于将类似数量的副本[调度](/zh-cn/docs/concepts/scheduling-eviction/)
+到每个基础设施可用区，且你想要该集群在遇到问题时能够自愈。
+
+Pod 拓扑分布约束使你能够以声明的方式进行配置。
+
+<!-- 
+## `topologySpreadConstraints` field
+
+The Pod API includes a field, `spec.topologySpreadConstraints`. Here is an example: 
+-->
+## `topologySpreadConstraints` 字段
+
+Pod API 包括一个 `spec.topologySpreadConstraints` 字段。这里有一个示例：
+
+```yaml
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: example-pod
+spec:
+  # 配置一个拓扑分布约束
+  topologySpreadConstraints:
+    - maxSkew: <integer>
+      minDomains: <integer> # 可选；自从 v1.24 开始成为 Alpha
+      topologyKey: <string>
+      whenUnsatisfiable: <string>
+      labelSelector: <object>
+  ### 其他 Pod 字段置于此处
+```
+
+<!-- 
+You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`. 
+-->
+你可以运行 `kubectl explain Pod.spec.topologySpreadConstraints` 阅读有关此字段的更多信息。
+
+<!-- 
+### Spread constraint definition
+
+You can define one or multiple `topologySpreadConstraints` entries to instruct the
+kube-scheduler how to place each incoming Pod in relation to the existing Pods across
+your cluster. Those fields are: 
+-->
+### 分布约束定义
+
+你可以定义一个或多个 `topologySpreadConstraints` 条目以指导 kube-scheduler
+如何将每个新来的 Pod 与跨集群的现有 Pod 相关联。这些字段包括：
+
+<!--
+- **maxSkew** describes the degree to which Pods may be unevenly distributed. You must
+  specify this field and the number must be greater than zero. Its semantics differ
+  according to the value of `whenUnsatisfiable`:
+
+  - if you select `whenUnsatisfiable: DoNotSchedule`, then `maxSkew` defines the
+    maximum permitted difference between the number of matching pods in the target
+    topology and the _global minimum_
+    (the minimum number of pods that match the label selector in a topology domain).
+    For example, if you have 3 zones with 2, 4 and 5 matching pods respectively,
+    then the global minimum is 2 and `maxSkew` is compared relative to that number.
+  - if you select `whenUnsatisfiable: ScheduleAnyway`, the scheduler gives higher
+    precedence to topologies that would help reduce the skew.
+-->
+- **maxSkew** 描述这些 Pod 可能被均匀分布的程度。你必须指定此字段且该数值必须大于零。
+  其语义将随着 `whenUnsatisfiable` 的值发生变化：
+  
+  - 如果你选择 `whenUnsatisfiable: DoNotSchedule`，则 `maxSkew` 定义目标拓扑中匹配 Pod 的数量与
+    **全局最小值**（与拓扑域中标签选择算符匹配的最小 Pod 数量）之间的最大允许差值。
+    例如，如果你有 3 个可用区，分别有 2、4 和 5 个匹配的 Pod，则全局最小值为 2，
+    而 `maxSkew` 相对于该数字进行比较。
+  - 如果你选择 `whenUnsatisfiable: ScheduleAnyway`，则该调度器会更为偏向能够降低偏差值的拓扑域。
+
+<!--
+- **minDomains** indicates a minimum number of eligible domains. This field is optional.
+  A domain is a particular instance of a topology. An eligible domain is a domain whose
+  nodes match the node selector.
+
+  The `minDomains` field is an alpha field added in 1.24. You have to enable the
+  `MinDomainsInPodToplogySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+  in order to use it.
+-->
+- **minDomains** 表示符合条件的域的最小数量。此字段是可选的。域是拓扑的一个特定实例。
+  符合条件的域是其节点与节点选择器匹配的域。
+  
+  {{< note >}}
+  `minDomains` 字段是 1.24 中添加的一个 Alpha 字段。
+  你必须启用 `MinDomainsInPodToplogySpread` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，才能使用该字段。
+  {{< /note >}}
+  
+  <!--
+  - The value of `minDomains` must be greater than 0, when specified.
+    You can only specify `minDomains` in conjunction with `whenUnsatisfiable: DoNotSchedule`.
+  - When the number of eligible domains with match topology keys is less than `minDomains`,
+    Pod topology spread treats global minimum as 0, and then the calculation of `skew` is performed.
+    The global minimum is the minimum number of matching Pods in an eligible domain,
+    or zero if the number of eligible domains is less than `minDomains`.
+  - When the number of eligible domains with matching topology keys equals or is greater than
+    `minDomains`, this value has no effect on scheduling.
+  - If you do not specify `minDomains`, the constraint behaves as if `minDomains` is 1.
+  -->
+
+  - 指定的 `minDomains` 值必须大于 0。你可以结合 `whenUnsatisfiable: DoNotSchedule` 仅指定 `minDomains`。
+  - 当符合条件的、拓扑键匹配的域的数量小于 `minDomains` 时，拓扑分布将“全局最小值”（global minimum）设为 0，
+    然后进行 `skew` 计算。“全局最小值” 是一个符合条件的域中匹配 Pod 的最小数量，
+    如果符合条件的域的数量小于 `minDomains`，则全局最小值为零。
+  - 当符合条件的拓扑键匹配域的个数等于或大于 `minDomains` 时，该值对调度没有影响。
+  - 如果你未指定 `minDomains`，则约束行为类似于 `minDomains` 等于 1。
+
+<!--
+- **topologyKey** is the key of [node labels](#node-labels). If two Nodes are labelled
+  with this key and have identical values for that label, the scheduler treats both
+  Nodes as being in the same topology. The scheduler tries to place a balanced number
+  of Pods into each topology domain.
+
+- **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
+  - `DoNotSchedule` (default) tells the scheduler not to schedule it.
+  - `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
+
+- **labelSelector** is used to find matching Pods. Pods
+  that match this label selector are counted to determine the
+  number of Pods in their corresponding topology domain.
+  See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+  for more details.
+-->
+- **topologyKey** 是[节点标签](#node-labels)的键。如果两个节点使用此键标记并且具有相同的标签值，
+  则调度器会将这两个节点视为处于同一拓扑域中。该调度器尝试在每个拓扑域中放置数量均衡的 Pod。
+
+- **whenUnsatisfiable** 指示如果 Pod 不满足分布约束时如何处理：
+  - `DoNotSchedule`（默认）告诉调度器不要调度。
+  - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对节点进行排序。
+
+- **labelSelector** 用于查找匹配的 Pod。匹配此标签的 Pod 将被统计，以确定相应拓扑域中 Pod 的数量。
+  有关详细信息，请参考[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
+
+<!--
+When a Pod defines more than one `topologySpreadConstraint`, those constraints are
+combined using a logical AND operation: the kube-scheduler looks for a node for the incoming Pod
+that satisfies all the configured constraints.
+-->
+当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。
+kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。
+
+<!--
+### Node labels
+
+Topology spread constraints rely on node labels to identify the topology
+domain(s) that each {{< glossary_tooltip text="node" term_id="node" >}} is in.
+For example, a node might have labels:
+-->
+### 节点标签 {#node-labels}
+
+拓扑分布约束依赖于节点标签来标识每个{{< glossary_tooltip text="节点" term_id="node" >}}所在的拓扑域。例如，某节点可能具有标签：
+
+```yaml
+  region: us-east-1
+  zone: us-east-1a
+```
+
+<!--
+For brevity, this example doesn't use the
+[well-known](/docs/reference/labels-annotations-taints/) label keys
+`topology.kubernetes.io/zone` and `topology.kubernetes.io/region`. However,
+those registered label keys are nonetheless recommended rather than the private
+(unqualified) label keys `region` and `zone` that are used here.
+
+You can't make a reliable assumption about the meaning of a private label key
+between different contexts.
+-->
+{{< note >}}
+为了简便，此示例未使用[众所周知](/zh-cn/docs/reference/labels-annotations-taints/)的标签键
+`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`。
+但是，建议使用那些已注册的标签键，而不是此处使用的私有（不合格）标签键 `region` 和 `zone`。
+
+你无法对不同上下文之间的私有标签键的含义做出可靠的假设。
+{{< /note >}}
+
+<!--
+Suppose you have a 4-node cluster with the following labels:
+-->
+假设你有一个 4 节点的集群且带有以下标签：
+
+```
+NAME    STATUS   ROLES    AGE     VERSION   LABELS
+node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
+node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
+node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
+node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
+```
+
+<!--
+Then the cluster is logically viewed as below:
+-->
+那么，从逻辑上看集群如下：
+
+{{<mermaid>}}
+graph TB
+    subgraph "zoneB"
+        n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        n1(Node1)
+        n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+<!--
+## Consistency
+
+You should set the same Pod topology spread constraints on all pods in a group.
+
+Usually, if you are using a workload controller such as a Deployment, the pod template
+takes care of this for you. If you mix different spread constraints then Kubernetes
+follows the API definition of the field; however, the behavior is more likely to become
+confusing and troubleshooting is less straightforward.
+
+You need a mechanism to ensure that all the nodes in a topology domain (such as a
+cloud provider region) are labelled consistently.
+To avoid you needing to manually label nodes, most clusters automatically
+populate well-known labels such as `topology.kubernetes.io/hostname`. Check whether
+your cluster supports this.
+-->
+## 一致性 {#Consistency}
+
+你应该为一个组中的所有 Pod 设置相同的 Pod 拓扑分布约束。
+
+通常，如果你正使用一个工作负载控制器，例如 Deployment，则 Pod 模板会你你解决这个问题。
+如果你混合不同的分布约束，则 Kubernetes 会遵循该字段的 API 定义；
+但是，该行为可能更令人困惑，并且故障排除也没那么简单。
+
+你需要一种机制来确保拓扑域（例如云提供商区域）中的所有节点具有一致的标签。
+为了避免你需要手动为节点打标签，大多数集群会自动填充知名的标签，
+例如 `topology.kubernetes.io/hostname`。检查你的集群是否支持此功能。
+
+<!--
+## Topology spread constraint examples
+
+### Example: one topology spread constraint {#example-one-topologyspreadconstraint}
+
+Suppose you have a 4-node cluster where 3 Pods labelled `foo: bar` are located in
+node1, node2 and node3 respectively:
+-->
+## 拓扑分布约束示例 {#topology-spread-constraint-examples}
+
+### 示例：一个拓扑分布约束 {#example-one-topologyspreadconstraint}
+
+假设你拥有一个 4 节点集群，其中标记为 `foo: bar` 的 3 个 Pod 分别位于 node1、node2 和 node3 中：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+<!--
+If you want an incoming Pod to be evenly spread with existing Pods across zones, you
+can use a manifest similar to:
+-->
+如果你希望新来的 Pod 均匀分布在现有的可用区域，则可以按如下设置其清单：
+
+{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
+
+<!--
+From that manifest, `topologyKey: zone` implies the even distribution will only be applied
+to nodes that are labelled `zone: <any value>` (nodes that don't have a `zone` label
+are skipped). The field `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let the
+incoming Pod stay pending if the scheduler can't find a way to satisfy the constraint.
+
+If the scheduler placed this incoming Pod into zone `A`, the distribution of Pods would
+become `[3, 1]`. That means the actual skew is then 2 (calculated as `3 - 1`), which
+violates `maxSkew: 1`. To satisfy the constraints and context for this example, the
+incoming Pod can only be placed onto a node in zone `B`:
+-->
+从此清单看，`topologyKey: zone` 意味着均匀分布将只应用于存在标签键值对为 `zone: <any value>` 的节点
+（没有 `zone` 标签的节点将被跳过）。如果调度器找不到一种方式来满足此约束，
+则 `whenUnsatisfiable: DoNotSchedule` 字段告诉该调度器将新来的 Pod 保持在 pending 状态。
+
+如果该调度器将这个新来的 Pod 放到可用区 `A`，则 Pod 的分布将成为 `[3, 1]`。
+这意味着实际偏差是 2（计算公式为 `3 - 1`），这违反了 `maxSkew: 1` 的约定。
+为了满足这个示例的约束和上下文，新来的 Pod 只能放到可用区 `B` 中的一个节点上：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+或者
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n3
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+<!--
+You can tweak the Pod spec to meet various kinds of requirements:
+
+- Change `maxSkew` to a bigger value - such as `2` -  so that the incoming Pod can
+  be placed into zone `A` as well.
+- Change `topologyKey` to `node` so as to distribute the Pods evenly across nodes
+  instead of zones. In the above example, if `maxSkew` remains `1`, the incoming
+  Pod can only be placed onto the node `node4`.
+- Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway`
+  to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs
+  are satisfied). However, it's preferred to be placed into the topology domain which
+  has fewer matching Pods. (Be aware that this preference is jointly normalized
+  with other internal scheduling priorities such as resource usage ratio).
+-->
+你可以调整 Pod 规约以满足各种要求：
+
+- 将 `maxSkew` 更改为更大的值，例如 `2`，这样新来的 Pod 也可以放在可用区 `A` 中。
+- 将 `topologyKey` 更改为 `node`，以便将 Pod 均匀分布在节点上而不是可用区中。
+  在上面的例子中，如果 `maxSkew` 保持为 `1`，则新来的 Pod 只能放到 `node4` 节点上。
+- 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`，
+  以确保新来的 Pod 始终可以被调度（假设满足其他的调度 API）。但是，最好将其放置在匹配 Pod 数量较少的拓扑域中。
+  请注意，这一优先判定会与其他内部调度优先级（如资源使用率等）排序准则一起进行标准化。
+
+<!--
+### Example: multiple topology spread constraints {#example-multiple-topologyspreadconstraints}
+
+This builds upon the previous example. Suppose you have a 4-node cluster where 3
+existing Pods labeled `foo: bar` are located on node1, node2 and node3 respectively:
+-->
+### 示例：多个拓扑分布约束 {#example-multiple-topologyspreadconstraints}
+
+下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，
+其中 3 个标记为 `foo: bar` 的 Pod 分别位于 node1、node2 和 node3 上：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+<!--
+You can combine two topology spread constraints to control the spread of Pods both
+by node and by zone:
+-->
+可以组合使用 2 个拓扑分布约束来控制 Pod 在节点和可用区两个维度上的分布：
+
+{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
+
+<!--
+In this case, to match the first constraint, the incoming Pod can only be placed onto
+nodes in zone `B`; while in terms of the second constraint, the incoming Pod can only be
+scheduled to the node `node4`. The scheduler only considers options that satisfy all
+defined constraints, so the only valid placement is onto node `node4`.
+-->
+在这种情况下，为了匹配第一个约束，新的 Pod 只能放置在可用区 `B` 中；
+而在第二个约束中，新来的 Pod 只能调度到节点 `node4` 上。
+该调度器仅考虑满足所有已定义约束的选项，因此唯一可行的选择是放置在节点 `node4` 上。
+
+<!--
+### Example: conflicting topology spread constraints {#example-conflicting-topologyspreadconstraints}
+
+Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
+-->
+### 示例：有冲突的拓扑分布约束 {#example-conflicting-topologyspreadconstraints}
+
+多个约束可能导致冲突。假设有一个跨 2 个可用区的 3 节点集群：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p4(Pod) --> n3(Node3)
+        p5(Pod) --> n3
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n1
+        p3(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+<!--
+If you were to apply
+[`two-constraints.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/topology-spread-constraints/two-constraints.yaml)
+(the manifest from the previous example)
+to **this** cluster, you would see that the Pod `mypod` stays in the `Pending` state.
+This happens because: to satisfy the first constraint, the Pod `mypod` can only
+be placed into zone `B`; while in terms of the second constraint, the Pod `mypod`
+can only schedule to node `node2`. The intersection of the two constraints returns
+an empty set, and the scheduler cannot place the Pod.
+
+To overcome this situation, you can either increase the value of `maxSkew` or modify
+one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`. Depending on
+circumstances, you might also decide to delete an existing Pod manually - for example,
+if you are troubleshooting why a bug-fix rollout is not making progress.
+-->
+如果你将 [`two-constraints.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/topology-spread-constraints/two-constraints.yaml)
+（来自上一个示例的清单）应用到**这个**集群，你将看到 Pod `mypod` 保持在 `Pending` 状态。
+出现这种情况的原因为：为了满足第一个约束，Pod `mypod` 只能放置在可用区 `B` 中；
+而在第二个约束中，Pod `mypod` 只能调度到节点 `node2` 上。
+两个约束的交集将返回一个空集，且调度器无法放置该 Pod。
+
+为了应对这种情形，你可以提高 `maxSkew` 的值或修改其中一个约束才能使用 `whenUnsatisfiable: ScheduleAnyway`。
+根据实际情形，例如若你在故障排查时发现某个漏洞修复工作毫无进展，你还可能决定手动删除一个现有的 Pod。
+
+<!--
+#### Interaction with node affinity and node selectors
+
+The scheduler will skip the non-matching nodes from the skew calculations if the
+incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
+-->
+#### 与节点亲和性和节点选择算符的相互作用 {#interaction-with-node-affinity-and-node-selectors}
+
+如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，
+调度器将在偏差计算中跳过不匹配的节点。
+
+<!--
+### Example: topology spread constraints with node affinity {#example-topologyspreadconstraints-with-nodeaffinity}
+
+Suppose you have a 5-node cluster ranging across zones A to C:
+-->
+### 示例：带节点亲和性的拓扑分布约束 {#example-topologyspreadconstraints-with-nodeaffinity}
+
+假设你有一个跨可用区 A 到 C 的 5 节点集群：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+class n1,n2,n3,n4,p1,p2,p3 k8s;
+class p4 plain;
+class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneC"
+        n5(Node5)
+    end
+
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+class n5 k8s;
+class zoneC cluster;
+{{< /mermaid >}}
+
+<!--
+and you know that zone `C` must be excluded. In this case, you can compose a manifest
+as below, so that Pod `mypod` will be placed into zone `B` instead of zone `C`.
+Similarly, Kubernetes also respects `spec.nodeSelector`.
+-->
+而且你知道可用区 `C` 必须被排除在外。在这种情况下，可以按如下方式编写清单，
+以便将 Pod `mypod` 放置在可用区 `B` 上，而不是可用区 `C` 上。
+同样，Kubernetes 也会一样处理 `spec.nodeSelector`。
+
+{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+
+<!--
+## Implicit conventions
+
+There are some implicit conventions worth noting here:
+
+- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
+
+- The scheduler bypasses any nodes that don't have any `topologySpreadConstraints[*].topologyKey`
+  present. This implies that:
+
+  1. any Pods located on those bypassed nodes do not impact `maxSkew` calculation - in the
+     above example, suppose the node `node1` does not have a label "zone", then the 2 Pods will
+     be disregarded, hence the incoming Pod will be scheduled into zone `A`.
+  2. the incoming Pod has no chances to be scheduled onto this kind of nodes -
+     in the above example, suppose a node `node5` has the **mistyped** label `zone-typo: zoneC`
+     (and no `zone` label set). After node `node5` joins the cluster, it will be bypassed and
+     Pods for this workload aren't scheduled there.
+-->
+## 隐式约定 {#implicit-conventions}
+
+这里有一些值得注意的隐式约定：
+
+- 只有与新来的 Pod 具有相同命名空间的 Pod 才能作为匹配候选者。
+
+- 调度器会忽略没有任何 `topologySpreadConstraints[*].topologyKey` 的节点。这意味着：
+  
+  1. 位于这些节点上的 Pod 不影响 `maxSkew` 计算，在上面的例子中，假设节点 `node1` 没有标签 "zone"，
+     则 2 个 Pod 将被忽略，因此新来的 Pod 将被调度到可用区 `A` 中。
+  2. 新的 Pod 没有机会被调度到这类节点上。在上面的例子中，
+     假设节点 `node5` 带有 **拼写错误的** 标签 `zone-typo: zoneC`（且没有设置 `zone` 标签）。
+     节点 `node5` 接入集群之后，该节点将被忽略且针对该工作负载的 Pod 不会被调度到那里。
+
+<!--
+- Be aware of what will happen if the incoming Pod's
+  `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the
+  above example, if you remove the incoming Pod's labels, it can still be placed onto
+  nodes in zone `B`, since the constraints are still satisfied. However, after that
+  placement, the degree of imbalance of the cluster remains unchanged - it's still zone `A`
+  having 2 Pods labelled as `foo: bar`, and zone `B` having 1 Pod labelled as
+  `foo: bar`. If this is not what you expect, update the workload's
+  `topologySpreadConstraints[*].labelSelector` to match the labels in the pod template.
+-->
+- 注意，如果新 Pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的标签不匹配，将会发生什么。
+  在上面的例子中，如果移除新 Pod 的标签，则 Pod 仍然可以放置到可用区 `B` 中的节点上，因为这些约束仍然满足。
+  然而，在放置之后，集群的不平衡程度保持不变。可用区 `A` 仍然有 2 个 Pod 带有标签 `foo: bar`，
+  而可用区 `B` 有 1 个 Pod 带有标签 `foo: bar`。如果这不是你所期望的，
+  更新工作负载的 `topologySpreadConstraints[*].labelSelector` 以匹配 Pod 模板中的标签。
+
+<!--
+## Cluster-level default constraints
+
+It is possible to set default topology spread constraints for a cluster. Default
+topology spread constraints are applied to a Pod if, and only if:
+
+- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
+- It belongs to a Service, ReplicaSet, StatefulSet or ReplicationController.
+
+Default constraints can be set as part of the `PodTopologySpread` plugin
+arguments in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
+The constraints are specified with the same [API above](#api), except that
+`labelSelector` must be empty. The selectors are calculated from the Services,
+ReplicaSets, StatefulSets or ReplicationControllers that the Pod belongs to.
+
+An example configuration might look like follows:
+-->
+## 集群级别的默认约束 {#cluster-level-default-constraints}
+
+为集群设置默认的拓扑分布约束也是可能的。默认拓扑分布约束在且仅在以下条件满足时才会被应用到 Pod 上：
+
+- Pod 没有在其 `.spec.topologySpreadConstraints` 中定义任何约束。
+- Pod 隶属于某个 Service、ReplicaSet、StatefulSet 或 ReplicationController。
+
+默认约束可以设置为[调度方案](/zh-cn/docs/reference/scheduling/config/#profiles)中
+`PodTopologySpread` 插件参数的一部分。约束的设置采用[如前所述的 API](#api)，
+只是 `labelSelector` 必须为空。
+选择算符是根据 Pod 所属的 Service、ReplicaSet、StatefulSet 或 ReplicationController 来设置的。
+
+配置的示例可能看起来像下面这个样子：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - schedulerName: default-scheduler
+    pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
+          defaultingType: List
+```
+
+<!--
+The [`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
+is disabled by default. The Kubernetes project recommends using `PodTopologySpread`
+to achieve similar behavior.
+-->
+{{< note >}}
+默认配置下，[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)是被禁用的。
+Kubernetes 项目建议使用 `PodTopologySpread` 以执行类似行为。
+{{< /note >}}
+
+<!--
+### Built-in default constraints {#internal-default-constraints}
+-->
+### 内置默认约束 {#internal-default-constraints}
+
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
+
+<!--
+If you don't configure any cluster-level default constraints for pod topology spreading,
+then kube-scheduler acts as if you specified the following default topology constraints:
+-->
+如果你没有为 Pod 拓扑分布配置任何集群级别的默认约束，
+kube-scheduler 的行为就像你指定了以下默认拓扑约束一样：
+
+```yaml
+defaultConstraints:
+  - maxSkew: 3
+    topologyKey: "kubernetes.io/hostname"
+    whenUnsatisfiable: ScheduleAnyway
+  - maxSkew: 5
+    topologyKey: "topology.kubernetes.io/zone"
+    whenUnsatisfiable: ScheduleAnyway
+```
+
+<!--
+Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
+is disabled by default.
+-->
+此外，原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。
+
+<!--
+The `PodTopologySpread` plugin does not score the nodes that don't have
+the topology keys specified in the spreading constraints. This might result
+in a different default behavior compared to the legacy `SelectorSpread` plugin when
+using the default topology constraints.
+
+If your nodes are not expected to have **both** `kubernetes.io/hostname` and
+`topology.kubernetes.io/zone` labels set, define your own constraints
+instead of using the Kubernetes defaults.
+-->
+{{< note >}}
+对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些拓扑键的节点评分。
+这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同。
+
+如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和 `topology.kubernetes.io/zone` 标签，
+你应该定义自己的约束而不是使用 Kubernetes 的默认约束。
+{{< /note >}}
+
+<!--
+If you don't want to use the default Pod spreading constraints for your cluster,
+you can disable those defaults by setting `defaultingType` to `List` and leaving
+empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
+-->
+如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List`，
+并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - schedulerName: default-scheduler
+    pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints: []
+          defaultingType: List
+```
+
+<!--
+## Comparison with podAffinity and podAntiAffinity {#comparison-with-podaffinity-podantiaffinity}
+
+In Kubernetes, [inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+control how Pods are scheduled in relation to one another - either more packed
+or more scattered.
+
+`podAffinity`
+: attracts Pods; you can try to pack any number of Pods into qualifying
+  topology domain(s)
+`podAntiAffinity`
+: repels Pods. If you set this to `requiredDuringSchedulingIgnoredDuringExecution` mode then
+  only a single Pod can be scheduled into a single topology domain; if you choose
+  `preferredDuringSchedulingIgnoredDuringExecution` then you lose the ability to enforce the
+  constraint.
+-->
+## 比较 podAffinity 和 podAntiAffinity {#comparison-with-podaffinity-podantiaffinity}
+
+在 Kubernetes 中，Pod 间亲和性和反亲和性控制 Pod 彼此的调度方式（更密集或更分散）。
+
+对于 `podAffinity`：吸引 Pod；你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
+对于 `podAntiAffinity`：驱逐 Pod。如果将此设为 `requiredDuringSchedulingIgnoredDuringExecution` 模式，
+则只有单个 Pod 可以调度到单个拓扑域；如果你选择 `preferredDuringSchedulingIgnoredDuringExecution`，
+则你将丢失强制执行此约束的能力。
+
+<!--
+For finer control, you can specify topology spread constraints to distribute
+Pods across different topology domains - to achieve either high availability or
+cost-saving. This can also help on rolling update workloads and scaling out
+replicas smoothly.
+
+For more context, see the
+[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
+section of the enhancement proposal about Pod topology spread constraints.
+-->
+要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，从而实现高可用性或节省成本。
+这也有助于工作负载的滚动更新和平稳地扩展副本规模。
+
+有关详细信息，请参阅有关 Pod 拓扑分布约束的增强倡议的
+[动机](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)一节。
+
+<!--
+## Known limitations
+
+- There's no guarantee that the constraints remain satisfied when Pods are removed. For
+  example, scaling down a Deployment may result in imbalanced Pods distribution.
+
+  You can use a tool such as the [Descheduler](https://github.com/kubernetes-sigs/descheduler)
+  to rebalance the Pods distribution.
+- Pods matched on tainted nodes are respected.
+  See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921).
+-->
+## 已知局限性 {#known-limitations}
+
+- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时，Pod 的分布可能不再均衡。
+  
+  你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler) 来重新实现 Pod 分布的均衡。
+
+- 具有污点的节点上匹配的 Pod 也会被统计。
+  参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
+
+<!--
+- The scheduler doesn't have prior knowledge of all the zones or other topology
+  domains that a cluster has. They are determined from the existing nodes in the
+  cluster. This could lead to a problem in autoscaled clusters, when a node pool (or
+  node group) is scaled to zero nodes, and you're expecting the cluster to scale up,
+  because, in this case, those topology domains won't be considered until there is
+  at least one node in them.  
+  You can work around this by using an cluster autoscaling tool that is aware of
+  Pod topology spread constraints and is also aware of the overall set of topology
+  domains.
+-->
+- 该调度器不会预先知道集群拥有的所有可用区和其他拓扑域。
+  拓扑域由集群中存在的节点确定。在自动扩缩的集群中，如果一个节点池（或节点组）的节点数量缩减为零，
+  而用户正期望其扩容时，可能会导致调度出现问题。
+  因为在这种情况下，调度器不会考虑这些拓扑域，因为其中至少有一个节点。  
+  你可以通过使用感知 Pod 拓扑分布约束并感知整个拓扑域集的集群自动扩缩工具来解决此问题。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- The blog article [Introducing PodTopologySpread](/blog/2020/05/introducing-podtopologyspread/)
+  explains `maxSkew` in some detail, as well as covering some advanced usage examples.
+- Read the [scheduling](/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling) section of
+  the API reference for Pod.
+-->
+- 博客：[PodTopologySpread 介绍](/blog/2020/05/introducing-podtopologyspread/)详细解释了 `maxSkew`，
+  并给出了一些进阶的使用示例。
+- 阅读针对 Pod 的 API 参考的
+  [调度](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)一节。

content/zh-cn/docs/concepts/security/pod-security-policy.md

@@ -402,12 +402,19 @@ controller selects policies according to the following criteria:
    PodSecurityPolicies doesn't matter.
 2. If the pod must be defaulted or mutated, the first PodSecurityPolicy
    (ordered by name) to allow the pod is selected.
+
+When a Pod is validated against a PodSecurityPolicy, [a `kubernetes.io/psp` annotation](/docs/reference/labels-annotations-taints/#kubernetes-io-psp)
+is added to the Pod, with the name of the PodSecurityPolicy as the annotation value.
 -->
 1. 优先考虑允许 Pod 保持原样，不会更改 Pod 字段默认值或其他配置的 PodSecurityPolicy。
    这类非更改性质的 PodSecurityPolicy 对象之间的顺序无关紧要。
 2. 如果必须要为 Pod 设置默认值或者其他配置，（按名称顺序）选择第一个允许
    Pod 操作的 PodSecurityPolicy 对象。
 
+当根据 PodSecurityPolicy 对一个 Pod 进行验证时，会为 Pod 添加
+[一个 `kubernetes.io/psp` 注释](/zh-cn/docs/reference/labels-annotations-taints/#kubernetes-io-psp)会被添加到 Pod 中，
+注解的值为 PodSecurityPolicy 的名称。
+
 {{< note >}}
 <!--
 During update operations (during which mutations to pod specs are disallowed)
@@ -457,15 +464,15 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
 <!--
 ### Create a policy and a pod
 
-Define the example PodSecurityPolicy object in a file. This is a policy that
-prevents the creation of privileged pods.
+This is a policy that prevents the creation of privileged pods.
+
 The name of a PodSecurityPolicy object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
 ### 创建一个策略和一个 Pod   {#create-a-policy-and-a-pod}
 
-在一个文件中定义一个示例的 PodSecurityPolicy 对象。
-这里的策略只是用来禁止创建有特权要求的 Pods。
+下面是一个防止创建特权 Pod 的策略。
+
 PodSecurityPolicy 对象的名称必须是合法的
 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
@@ -477,7 +484,7 @@ And create it with kubectl:
 使用 kubectl 执行创建操作：
 
 ```shell
-kubectl-admin create -f example-psp.yaml
+kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml
 ```
 
 <!--
@@ -517,6 +524,11 @@ pod's service account nor `fake-user` have permission to use the new policy:
 kubectl-user auth can-i use podsecuritypolicy/example
 ```
 
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
 ```
 no
 ```
@@ -597,11 +609,29 @@ pod "pause" created
 ```
 
 <!--
-It works as expected! But any attempts to create a privileged pod should still
-be denied:
+It works as expected! You can verify that the pod was validated against the
+newly created PodSecurityPolicy:
 -->
 此次尝试不出所料地成功了！
-不过任何创建特权 Pod 的尝试还是会被拒绝：
+你可以验证 Pod 是根据新创建的 PodSecurityPolicy 验证的。
+
+```shell
+kubectl-user get pod pause -o yaml | grep kubernetes.io/psp
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+kubernetes.io/psp: example
+```
+<!--
+But any attempts to create a privileged pod should still
+be denied:
+-->
+但任何试图创建特权 Pod 的请求仍然会被拒绝。
 
 ```shell
 kubectl-user create -f- <<EOF

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

@@ -1,5 +1,5 @@
 ---
-title: 动态卷供应
+title: 动态卷制备
 content_type: concept
 weight: 40
 ---
@@ -20,11 +20,11 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates
 the need for cluster administrators to pre-provision storage. Instead, it
 automatically provisions storage when it is requested by users.
 -->
-动态卷供应允许按需创建存储卷。
-如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
+动态卷制备允许按需创建存储卷。
+如果没有动态制备，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
 然后在 Kubernetes 集群创建
 [`PersistentVolume` 对象](/zh-cn/docs/concepts/storage/persistent-volumes/)来表示这些卷。
-动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
+动态制备功能消除了集群管理员预先配置存储的需要。相反，它在用户请求时自动制备存储。
 
 <!-- body -->
 
@@ -40,9 +40,9 @@ from the API group `storage.k8s.io`. A cluster administrator can define as many
 *provisioner*) that provisions a volume and the set of parameters to pass to
 that provisioner when provisioning.
 -->
-动态卷供应的实现基于 `storage.k8s.io` API 组中的 `StorageClass` API 对象。
-集群管理员可以根据需要定义多个 `StorageClass` 对象，每个对象指定一个*卷插件*（又名 *provisioner*），
-卷插件向卷供应商提供在创建卷时需要的数据卷信息及相关参数。
+动态卷制备的实现基于 `storage.k8s.io` API 组中的 `StorageClass` API 对象。
+集群管理员可以根据需要定义多个 `StorageClass` 对象，每个对象指定一个**卷插件**（又名 **provisioner**），
+卷插件向卷制备商提供在创建卷时需要的数据卷信息及相关参数。
 
 <!--
 A cluster administrator can define and expose multiple flavors of storage (from
@@ -52,7 +52,7 @@ about the complexity and nuances of how storage is provisioned, but still
 have the ability to select from multiple storage options.
 -->
 集群管理员可以在集群中定义和公开多种存储（来自相同或不同的存储系统），每种都具有自定义参数集。
-该设计也确保终端用户不必担心存储供应的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。
+该设计也确保终端用户不必担心存储制备的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。
 
 <!--
 More information on storage classes can be found
@@ -63,7 +63,7 @@ More information on storage classes can be found
 <!--
 ## Enabling Dynamic Provisioning
 -->
-## 启用动态卷供应  {#enabling-dynamic-provisioning}
+## 启用动态卷制备  {#enabling-dynamic-provisioning}
 
 <!--
 To enable dynamic provisioning, a cluster administrator needs to pre-create
@@ -76,8 +76,8 @@ The name of a StorageClass object must be a valid
 The following manifest creates a storage class "slow" which provisions standard
 disk-like persistent disks.
 -->
-要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
-`StorageClass` 对象定义当动态供应被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。
+要启用动态制备功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
+`StorageClass` 对象定义当动态制备被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。
 StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。
 
@@ -110,7 +110,7 @@ parameters:
 <!--
 ## Using Dynamic Provisioning
 -->
-## 使用动态卷供应
+## 使用动态卷制备 {#using-dynamic-provisioning}
 
 <!--
 Users request dynamically provisioned storage by including a storage class in
@@ -121,7 +121,7 @@ is deprecated since v1.9. Users now can and should instead use the
 this field must match the name of a `StorageClass` configured by the
 administrator (see [below](#enabling-dynamic-provisioning)).
 -->
-用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态供应的存储。
+用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态制备的存储。
 在 Kubernetes v1.9 之前，这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。然而，这个注解自 v1.6 起就不被推荐使用了。
 用户现在能够而且应该使用 `PersistentVolumeClaim` 对象的 `storageClassName` 字段。
 这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[下面](#enabling-dynamic-provisioning)）。
@@ -150,7 +150,7 @@ spec:
 This claim results in an SSD-like Persistent Disk being automatically
 provisioned. When the claim is deleted, the volume is destroyed.
 -->
-该声明会自动供应一块类似 SSD 的永久磁盘。
+该声明会自动制备一块类似 SSD 的永久磁盘。
 在删除该声明后，这个卷也会被销毁。
 
 <!--
@@ -163,7 +163,7 @@ Dynamic provisioning can be enabled on a cluster such that all claims are
 dynamically provisioned if no storage class is specified. A cluster administrator
 can enable this behavior by:
 -->
-可以在集群上启用动态卷供应，以便在未指定存储类的情况下动态设置所有声明。
+可以在集群上启用动态卷制备，以便在未指定存储类的情况下动态设置所有声明。
 集群管理员可以通过以下方式启用此行为：
 
 <!--
@@ -171,18 +171,20 @@ can enable this behavior by:
 - Making sure that the [`DefaultStorageClass` admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
   is enabled on the API server.
 -->
-- 标记一个 `StorageClass` 为 *默认*；
+- 标记一个 `StorageClass` 为 **默认**；
 - 确保 [`DefaultStorageClass` 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
 
 <!--
 An administrator can mark a specific `StorageClass` as default by adding the
-`storageclass.kubernetes.io/is-default-class` annotation to it.
+`storageclass.kubernetes.io/is-default-class` [annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it.
 When a default `StorageClass` exists in a cluster and a user creates a
 `PersistentVolumeClaim` with `storageClassName` unspecified, the
 `DefaultStorageClass` admission controller automatically adds the
 `storageClassName` field pointing to the default storage class.
 -->
-管理员可以通过向其添加 `storageclass.kubernetes.io/is-default-class` 注解来将特定的 `StorageClass` 标记为默认。
+管理员可以通过向其添加 `storageclass.kubernetes.io/is-default-class`
+[annotation](/zh-cn/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)
+来将特定的 `StorageClass` 标记为默认。
 当集群中存在默认的 `StorageClass` 并且用户创建了一个未指定 `storageClassName` 的 `PersistentVolumeClaim` 时，
 `DefaultStorageClass` 准入控制器会自动向其中添加指向默认存储类的 `storageClassName` 字段。
 
@@ -191,13 +193,13 @@ Note that there can be at most one *default* storage class on a cluster, or
 a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot
 be created.
 -->
-请注意，集群上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
+请注意，集群上最多只能有一个 **默认** 存储类，否则无法创建没有明确指定
 `storageClassName` 的 `PersistentVolumeClaim`。
 
 <!--
 ## Topology Awareness
 -->
-## 拓扑感知
+## 拓扑感知 {#topology-awareness}
 
 <!--
 In [Multi-Zone](/docs/setup/multiple-zones) clusters, Pods can be spread across
@@ -205,7 +207,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
 Pods are scheduled. This can be accomplished by setting the [Volume Binding
 Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
 -->
-在[多区域](/zh-cn/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
-单区域存储后端应该被供应到 Pod 被调度到的区域。
+在[多可用区](/zh-cn/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到某个区域的多个可用区。
+单可用区存储后端应该被制备到 Pod 被调度到的可用区。
 这可以通过设置[卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
 

content/zh-cn/docs/concepts/storage/volume-snapshots.md

@@ -12,13 +12,11 @@ weight: 40
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="1.17" state="beta" >}}
-
 <!--
 In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
 -->
-在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
-的 [持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)。
+在 Kubernetes 中，**卷快照** 是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
+的[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)。
 
 <!-- body -->
 
@@ -31,29 +29,31 @@ In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage
 <!--
 Similar to how API resources `PersistentVolume` and `PersistentVolumeClaim` are used to provision volumes for users and administrators, `VolumeSnapshotContent` and `VolumeSnapshot` API resources are provided to create volume snapshots for users and administrators.
 -->
-与 `PersistentVolume` 和 `PersistentVolumeClaim` 两个 API 资源用于给用户和管理员提供卷类似，`VolumeSnapshotContent` 和 `VolumeSnapshot` 两个 API 资源用于给用户和管理员创建卷快照。
+与 `PersistentVolume` 和 `PersistentVolumeClaim` 这两个 API 资源用于给用户和管理员制备卷类似，
+`VolumeSnapshotContent` 和 `VolumeSnapshot` 这两个 API 资源用于给用户和管理员创建卷快照。
 
 <!--
 A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource.
 -->
-`VolumeSnapshotContent` 是一种快照，从管理员已提供的集群中的卷获取。就像持久卷是集群的资源一样，它也是集群中的资源。
+`VolumeSnapshotContent` 是从一个卷获取的一种快照，该卷由管理员在集群中进行制备。
+就像持久卷（PersistentVolume）是集群的资源一样，它也是集群中的资源。
 
 <!--
 A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.
 -->
-`VolumeSnapshot` 是用户对于卷的快照的请求。它类似于持久卷声明。
+`VolumeSnapshot` 是用户对于卷的快照的请求。它类似于持久卷声明（PersistentVolumeClaim）。
 
 <!--
 `VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attributes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
 -->
-`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。
+`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，
+这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。
 
 <!--
 Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
 -->
-卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点
-复制卷的内容，并且不需要创建全新的卷。例如，这一功能使得数据库管理员
-能够在执行编辑或删除之类的修改之前对数据库执行备份。
+卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点复制卷的内容，并且不需要创建全新的卷。
+例如，这一功能使得数据库管理员能够在执行编辑或删除之类的修改之前对数据库执行备份。
 
 <!--
 Users need to be aware of the following when using this feature:
@@ -68,8 +68,8 @@ Users need to be aware of the following when using this feature:
 * CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
 * The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
 -->
-* API 对象 `VolumeSnapshot`，`VolumeSnapshotContent` 和 `VolumeSnapshotClass` 
-  是 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}，
+* API 对象 `VolumeSnapshot`，`VolumeSnapshotContent` 和 `VolumeSnapshotClass`
+  是 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}，
   不属于核心 API。
 * `VolumeSnapshot` 支持仅可用于 CSI 驱动。
 * 作为 `VolumeSnapshot` 部署过程的一部分，Kubernetes 团队提供了一个部署于控制平面的快照控制器，
@@ -78,12 +78,12 @@ Users need to be aware of the following when using this feature:
   并且负责创建和删除 `VolumeSnapshotContent` 对象。
   边车 csi-snapshotter 监视 `VolumeSnapshotContent` 对象，
   并且触发针对 CSI 端点的 `CreateSnapshot` 和 `DeleteSnapshot` 的操作。
-* 还有一个验证性质的 Webhook 服务器，可以对快照对象进行更严格的验证。 
-  Kubernetes 发行版应将其与快照控制器和 CRD（而非 CSI 驱动程序）一起安装。 
+* 还有一个验证性质的 Webhook 服务器，可以对快照对象进行更严格的验证。
+  Kubernetes 发行版应将其与快照控制器和 CRD（而非 CSI 驱动程序）一起安装。
   此服务器应该安装在所有启用了快照功能的 Kubernetes 集群中。
-* CSI 驱动可能实现，也可能没有实现卷快照功能。CSI 驱动可能会使用 csi-snapshotter 
+* CSI 驱动可能实现，也可能没有实现卷快照功能。CSI 驱动可能会使用 csi-snapshotter
   来提供对卷快照的支持。详见 [CSI 驱动程序文档](https://kubernetes-csi.github.io/docs/)
-* Kubernetes 负责 CRDs 和快照控制器的安装。
+* Kubernetes 负责 CRD 和快照控制器的安装。
 
 <!--
 ## Lifecycle of a volume snapshot and volume snapshot content
@@ -92,30 +92,33 @@ Users need to be aware of the following when using this feature:
 -->
 ## 卷快照和卷快照内容的生命周期 {#lifecycle-of-a-volume-snapshot-and-volume-snapshot-content}
 
-`VolumeSnapshotContents` 是集群中的资源。`VolumeSnapshots` 是对于这些资源的请求。`VolumeSnapshotContents` 和 `VolumeSnapshots` 之间的交互遵循以下生命周期：
+`VolumeSnapshotContents` 是集群中的资源。`VolumeSnapshots` 是对于这些资源的请求。
+`VolumeSnapshotContents` 和 `VolumeSnapshots` 之间的交互遵循以下生命周期：
 
 <!--
 ### Provisioning Volume Snapshot
 
 There are two ways snapshots may be provisioned: pre-provisioned or dynamically provisioned.
 -->
-### 供应卷快照 {#provisioning-volume-snapshot}
+### 制备卷快照 {#provisioning-volume-snapshot}
 
-快照可以通过两种方式进行配置：预配置或动态配置。
+快照可以通过两种方式进行制备：预制备或动态制备。
 
 <!--
 #### Pre-provisioned {#static}
 A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real volume snapshot on the storage system which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
 -->
-#### 预配置 {#static}
-集群管理员创建多个 `VolumeSnapshotContents`。它们带有存储系统上实际卷快照的详细信息，可以供集群用户使用。它们存在于 Kubernetes API 中，并且能够被使用。
+#### 预制备 {#static}
+
+集群管理员创建多个 `VolumeSnapshotContents`。它们带有存储系统上实际卷快照的详细信息，可以供集群用户使用。
+它们存在于 Kubernetes API 中，并且能够被使用。
 
 <!--
 #### Dynamic
 
 Instead of using a pre-existing snapshot, you can request that a snapshot to be dynamically taken from a PersistentVolumeClaim. The [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) specifies storage provider-specific parameters to use when taking a snapshot.
 -->
-#### 动态的 {#dynamic}
+#### 动态制备 {#dynamic}
 
 可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。
 在获取快照时，[卷快照类](/zh-cn/docs/concepts/storage/volume-snapshot-classes/)
@@ -128,12 +131,13 @@ The snapshot controller handles the binding of a `VolumeSnapshot` object with an
 -->
 ### 绑定 {#binding}
 
-在预配置和动态配置场景下，快照控制器处理绑定 `VolumeSnapshot` 对象和其合适的 `VolumeSnapshotContent` 对象。绑定关系是一对一的。
+在预制备和动态制备场景下，快照控制器处理绑定 `VolumeSnapshot` 对象和其合适的 `VolumeSnapshotContent` 对象。
+绑定关系是一对一的。
 
 <!--
 In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound until the requested VolumeSnapshotContent object is created.
 -->
-在预配置快照绑定场景下，`VolumeSnapshotContent` 对象创建之后，才会和 `VolumeSnapshot` 进行绑定。
+在预制备快照绑定场景下，`VolumeSnapshotContent` 对象创建之后，才会和 `VolumeSnapshot` 进行绑定。
 
 <!--
 ### Persistent Volume Claim as Snapshot Source Protection
@@ -146,16 +150,20 @@ API objects are not removed from the system while a snapshot is being taken from
 ### 快照源的持久性卷声明保护
 
 这种保护的目的是确保在从系统中获取快照时，不会将正在使用的
- {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} 
+ {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
  API 对象从系统中删除（因为这可能会导致数据丢失）。
 
 <!--
 
 While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
 -->
-如果一个 PVC 正在被快照用来作为源进行快照创建，则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象，则 PVC 对象不会立即被删除掉。相反，PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时，PVC 将不再用作快照源。
+如果一个 PVC 正在被快照用来作为源进行快照创建，则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象，
+则 PVC 对象不会立即被删除掉。相反，PVC 对象的删除将推迟到任何快照不在主动使用它为止。
+当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时，PVC 将不再用作快照源。
 
-当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反，删除 `PersistentVolumeClaim` 对象的动作会被放弃，或者推迟到快照的 Status 为 ReadyToUse时再执行。
+当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。
+如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。
+相反，删除 `PersistentVolumeClaim` 对象的动作会被放弃，或者推迟到快照的 Status 为 ReadyToUse 时再执行。
 
 <!--
 ### Delete
@@ -164,7 +172,9 @@ Deletion is triggered by deleting the `VolumeSnapshot` object, and the `Deletion
 -->
 ### 删除 {#delete}
 
-删除 `VolumeSnapshot` 对象触发删除 `VolumeSnapshotContent` 操作，并且 `DeletionPolicy` 会紧跟着执行。如果 `DeletionPolicy` 是 `Delete`，那么底层存储快照会和 `VolumeSnapshotContent` 一起被删除。如果 `DeletionPolicy` 是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 都会被保留。
+删除 `VolumeSnapshot` 对象触发删除 `VolumeSnapshotContent` 操作，并且 `DeletionPolicy` 会紧跟着执行。
+如果 `DeletionPolicy` 是 `Delete`，那么底层存储快照会和 `VolumeSnapshotContent` 一起被删除。
+如果 `DeletionPolicy` 是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 都会被保留。
 
 <!--
 ## VolumeSnapshots
@@ -173,7 +183,7 @@ Each VolumeSnapshot contains a spec and a status.
 -->
 ## 卷快照 {#volume-snapshots}
 
-每个 `VolumeSnapshot` 包含一个 spec 和一个状态。
+每个 `VolumeSnapshot` 包含一个 spec 和一个 status。
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1
@@ -194,7 +204,7 @@ A volume snapshot can request a particular class by specifying the name of a
 using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
 -->
 `persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。
-这个字段是动态配置快照中的必填字段。
+这个字段是动态制备快照中的必填字段。
 
 卷快照可以通过指定 [VolumeSnapshotClass](/zh-cn/docs/concepts/storage/volume-snapshot-classes/)
 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
@@ -202,8 +212,8 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
 <!--
 For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
 -->
-如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。
-对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
+如下面例子所示，对于预制备的快照，需要给快照指定 `volumeSnapshotContentName` 作为来源。
+对于预制备的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1
@@ -221,7 +231,8 @@ spec:
 Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
 Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
 -->
-每个 VolumeSnapshotContent 对象包含 spec 和 status。在动态配置时，快照通用控制器创建 `VolumeSnapshotContent` 对象。下面是例子：
+每个 VolumeSnapshotContent 对象包含 spec 和 status。
+在动态制备时，快照通用控制器创建 `VolumeSnapshotContent` 对象。下面是例子：
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1
@@ -248,7 +259,7 @@ For pre-provisioned snapshots, you (as cluster administrator) are responsible fo
 -->
 `volumeHandle` 是存储后端创建卷的唯一标识符，在卷创建期间由 CSI 驱动程序返回。动态设置快照需要此字段。它指出了快照的卷源。
 
-对于预配置快照，你（作为集群管理员）要按如下命令来创建 `VolumeSnapshotContent` 对象。
+对于预制备快照，你（作为集群管理员）要按如下命令来创建 `VolumeSnapshotContent` 对象。
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1
@@ -268,7 +279,8 @@ spec:
 <!--
 `snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.
 -->
-`snapshotHandle` 是存储后端创建卷的唯一标识符。对于预设置快照，这个字段是必须的。它指定此 `VolumeSnapshotContent` 表示的存储系统上的 CSI 快照 id。
+`snapshotHandle` 是存储后端创建卷的唯一标识符。对于预设置快照，这个字段是必须的。
+它指定此 `VolumeSnapshotContent` 表示的存储系统上的 CSI 快照 ID。
 
 <!--
 `sourceVolumeMode` is the mode of the volume whose snapshot is taken. The value 
@@ -315,7 +327,7 @@ by the cluster administrator.
 
 An example `VolumeSnapshotContent` resource with this feature enabled would look like:
 -->
-对于预配置的快照，`Spec.SourceVolumeMode` 需要由集群管理员填充。
+对于预制备的快照，`Spec.SourceVolumeMode` 需要由集群管理员填充。
 
 启用此特性的 `VolumeSnapshotContent` 资源示例如下所示：
 
@@ -340,13 +352,13 @@ spec:
 <!--
 ## Provisioning Volumes from Snapshots
 -->
-## 从快照供应卷
+## 从快照制备卷 {#provisioning-volumes-from-snapshots}
 
 <!--
 You can provision a new volume, pre-populated with data from a snapshot, by using
 the *dataSource* field in the `PersistentVolumeClaim` object.
 -->
-你可以配置一个新卷，该卷预填充了快照中的数据，在 `持久卷声明` 对象中使用 *dataSource* 字段。
+你可以制备一个新卷，该卷预填充了快照中的数据，在 `持久卷声明` 对象中使用 **dataSource** 字段。
 
 <!--
 For more details, see

content/zh-cn/docs/concepts/windows/user-guide.md

@@ -157,17 +157,17 @@ port 80 of the container directly to the Service.
 -->
 1. 检查部署是否成功。请验证：
 
-   * 使用 `kubectl get pods` 从 Linux 控制平面节点能够列出两个 Pod
-   * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点上执行 `curl` 访问
-     Pod IP 的 80 端口以检查 Web 服务器响应
+   * 当执行 `kubectl get pods` 命令时，能够从 Linux 控制平面所在的节点上列出两个 Pod。
+   * 跨网络的节点到 Pod 通信，从 Linux 控制平面所在的节点上执行 `curl` 命令来访问
+     Pod IP 的 80 端口以检查 Web 服务器响应。
    * Pod 间通信，使用 `docker exec` 或 `kubectl exec`
-     在 Pod 之间（以及跨主机，如果你有多个 Windows 节点）互 ping
-   * Service 到 Pod 的通信，在 Linux 控制平面节点以及独立的 Pod 中执行 `curl`
-     访问虚拟的服务 IP（在 `kubectl get services` 下查看）
-   * 服务发现，使用 Kubernetes [默认 DNS 后缀](/zh-cn/docs/concepts/services-networking/dns-pod-service/#services)的服务名称，
-     用 `curl` 访问服务名称
-   * 入站连接，在 Linux 控制平面节点或集群外的机器上执行 `curl` 来访问 NodePort 服务
-   * 出站连接，使用 `kubectl exec`，从 Pod 内部执行 `curl` 访问外部 IP
+     命令进入容器，并在 Pod 之间（以及跨主机，如果你有多个 Windows 节点）相互进行 ping 操作。
+   * Service 到 Pod 的通信，在 Linux 控制平面所在的节点以及独立的 Pod 中执行 `curl`
+     命令来访问虚拟的服务 IP（在 `kubectl get services` 命令下查看）。
+   * 服务发现，执行 `curl` 命令来访问带有 Kubernetes 
+     [默认 DNS 后缀](/zh-cn/docs/concepts/services-networking/dns-pod-service/#services)的服务名称。
+   * 入站连接，在 Linux 控制平面所在的节点上或集群外的机器上执行 `curl` 命令来访问 NodePort 服务。
+   * 出站连接，使用 `kubectl exec`，从 Pod 内部执行 `curl` 访问外部 IP。
 
 {{< note >}}
 <!-- 

content/zh-cn/docs/concepts/workloads/pods/_index.md

@@ -609,7 +609,7 @@ in the Pod Lifecycle documentation.
   The {{< api-reference page="workload-resources/pod-v1" >}}
   object definition describes the object in detail.
 * [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
-* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints//).
 -->
 * 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
 * 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它
@@ -621,7 +621,7 @@ in the Pod Lifecycle documentation.
   对象的定义中包含了更多的细节信息。
 * 博客 [分布式系统工具箱：复合容器模式](/blog/2015/06/the-distributed-system-toolkit-patterns/)
   中解释了在同一 Pod 中包含多个容器时的几种常见布局。
-* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints//)。
 
 <!--
 To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:

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

@@ -1,688 +0,0 @@
----
-title: Pod 拓扑分布约束
-content_type: concept
-weight: 40
----
-
-<!--
-title: Pod Topology Spread Constraints
-content_type: concept
-weight: 40
--->
-
-<!-- overview -->
-
-<!--
-You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
--->
-你可以使用 _拓扑分布约束（Topology Spread Constraints）_ 来控制
-{{< glossary_tooltip text="Pod" term_id="Pod" >}} 在集群内故障域之间的分布，
-例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。
-这样做有助于实现高可用并提升资源利用率。
-
-<!-- body -->
-
-<!--
-## Prerequisites
-
-### Node Labels
--->
-## 先决条件   {#prerequisites}
-
-### 节点标签   {#node-labels}
-
-<!--
-Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: `node=node1,zone=us-east-1a,region=us-east-1`
--->
-拓扑分布约束依赖于节点标签来标识每个节点所在的拓扑域。
-例如，某节点可能具有标签：`node=node1,zone=us-east-1a,region=us-east-1`
-
-<!--
-Suppose you have a 4-node cluster with the following labels:
--->
-假设你拥有具有以下标签的一个 4 节点集群：
-
-```
-NAME    STATUS   ROLES    AGE     VERSION   LABELS
-node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
-node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
-node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
-node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
-```
-
-<!--
-Then the cluster is logically viewed as below:
--->
-那么，从逻辑上看集群如下：
-
-{{<mermaid>}}
-graph TB
-    subgraph "zoneB"
-        n3(Node3)
-        n4(Node4)
-    end
-    subgraph "zoneA"
-        n1(Node1)
-        n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4 k8s;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-<!--
-Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
--->
-你可以复用在大多数集群上自动创建和填充的[常用标签](/zh-cn/docs/reference/labels-annotations-taints/)，
-而不是手动添加标签。
-
-<!--
-## Spread Constraints for Pods
--->
-## Pod 的分布约束    {#spread-constraints-for-pods}
-
-### API
-
-<!--
-The API field `pod.spec.topologySpreadConstraints` is defined as below:
--->
-`pod.spec.topologySpreadConstraints` 字段定义如下所示：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  topologySpreadConstraints:
-    - maxSkew: <integer>
-      topologyKey: <string>
-      whenUnsatisfiable: <string>
-      labelSelector: <object>
-```
-
-<!--
-You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are:
--->
-你可以定义一个或多个 `topologySpreadConstraint` 来指示 kube-scheduler
-如何根据与现有的 Pod 的关联关系将每个传入的 Pod 部署到集群中。字段包括：
-
-<!--
-- **maxSkew** describes the degree to which Pods may be unevenly distributed.
-  It's the maximum permitted difference between the number of matching Pods in
-  any two topology domains of a given topology type. It must be greater than
-  zero. Its semantics differs according to the value of `whenUnsatisfiable`:
-  - when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
-    permitted difference between the number of matching pods in the target
-    topology and the global minimum.
-    (the minimum number of pods that match the label selector in a topology domain.
-    For example, if you have 3 zones with 0, 2 and 3 matching pods respectively,
-    The global minimum is 0).
-  - when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
-    precedence to topologies that would help reduce the skew.
--->
-
-- **maxSkew** 描述 Pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中匹配的
-  Pod 之间的最大允许差值。它必须大于零。取决于 `whenUnsatisfiable` 的取值，
-  其语义会有不同。
-  - 当 `whenUnsatisfiable` 等于 "DoNotSchedule" 时，`maxSkew` 是目标拓扑域中匹配的
-    Pod 数与全局最小值（一个拓扑域中与标签选择器匹配的 Pod 的最小数量。例如，如果你有
-    3 个区域，分别具有 0 个、2 个 和 3 个匹配的 Pod，则全局最小值为 0。）之间可存在的差异。
-  - 当 `whenUnsatisfiable` 等于 "ScheduleAnyway" 时，调度器会更为偏向能够降低偏差值的拓扑域。
-
-<!--
-- **minDomains** indicates a minimum number of eligible domains.
-  A domain is a particular instance of a topology. An eligible domain is a domain whose
-  nodes match the node selector.
-
-  - The value of `minDomains` must be greater than 0, when specified.
-  - When the number of eligible domains with match topology keys is less than `minDomains`,
-    Pod topology spread treats "global minimum" as 0, and then the calculation of `skew` is performed.
-    The "global minimum" is the minimum number of matching Pods in an eligible domain,
-    or zero if the number of eligible domains is less than `minDomains`.
-  - When the number of eligible domains with matching topology keys equals or is greater than 
-    `minDomains`, this value has no effect on scheduling.
-  - When `minDomains` is nil, the constraint behaves as if `minDomains` is 1.
-  - When `minDomains` is not nil, the value of `whenUnsatisfiable` must be "`DoNotSchedule`".
--->
-- **minDomains** 表示符合条件的域的最小数量。域是拓扑的一个特定实例。
-  符合条件的域是其节点与节点选择器匹配的域。
-
-  - 指定的 `minDomains` 的值必须大于 0。
-  - 当符合条件的、拓扑键匹配的域的数量小于 `minDomains` 时，Pod 拓扑分布将“全局最小值”
-    （global minimum）设为 0，然后进行 `skew` 计算。“全局最小值”是一个符合条件的域中匹配
-    Pod 的最小数量，如果符合条件的域的数量小于 `minDomains`，则全局最小值为零。
-  - 当符合条件的拓扑键匹配域的个数等于或大于 `minDomains` 时，该值对调度没有影响。
-  - 当 `minDomains` 为 nil 时，约束的行为等于 `minDomains` 为 1。
-  - 当 `minDomains` 不为 nil 时，`whenUnsatisfiable` 的值必须为 "`DoNotSchedule`" 。
-
-  {{< note >}}
-  <!--
-  The `minDomains` field is an alpha field added in 1.24. You have to enable the
-  `MinDomainsInPodToplogySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-  in order to use it.
-  -->
-  `minDomains` 字段是在 1.24 版本中新增的 alpha 字段。你必须启用
-  `MinDomainsInPodToplogySpread` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。
-  {{< /note >}}
-
-<!--
-- **topologyKey** is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain.
-
-- **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
-    - `DoNotSchedule` (default) tells the scheduler not to schedule it.
-    - `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
-
-- **labelSelector** is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) for more details.
--->
-- **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值，
-  则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量均衡的 Pod。
-
-- **whenUnsatisfiable** 指示如果 Pod 不满足分布约束时如何处理：
-  - `DoNotSchedule`（默认）告诉调度器不要调度。
-  - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对节点进行排序。
-
-- **labelSelector** 用于查找匹配的 Pod。匹配此标签的 Pod 将被统计，
-  以确定相应拓扑域中 Pod 的数量。
-  有关详细信息，请参考[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
-
-<!--
-When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
--->
-当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。
-kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。
-
-<!--
-You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
--->
-你可以执行 `kubectl explain Pod.spec.topologySpreadConstraints`
-命令以了解关于 topologySpreadConstraints 的更多信息。
-
-<!--
-### Example: One TopologySpreadConstraint
-
-Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
--->
-### 例子：单个 TopologySpreadConstraint
-
-假设你拥有一个 4 节点集群，其中标记为 `foo:bar` 的 3 个 Pod 分别位于
-node1、node2 和 node3 中：
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p3(Pod) --> n3(Node3)
-        n4(Node4)
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-<!--
-If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:
--->
-如果希望新来的 Pod 均匀分布在现有的可用区域，则可以按如下设置其规约：
-
-{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
-
-<!--
-`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:&lt;any value&gt;" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
--->
-`topologyKey: zone` 意味着均匀分布将只应用于存在标签键值对为
-"zone:&lt;任何值&gt;" 的节点。
-`whenUnsatisfiable: DoNotSchedule` 告诉调度器如果新的 Pod 不满足约束，
-则让它保持悬决状态。
-
-<!--
-If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
--->
-如果调度器将新的 Pod 放入 "zoneA"，Pods 分布将变为 [3, 1]，因此实际的偏差为
-2（3 - 1）。这违反了 `maxSkew: 1` 的约定。此示例中，新 Pod 只能放置在
-"zoneB" 上：
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p3(Pod) --> n3(Node3)
-        p4(mypod) --> n4(Node4)
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
-    class p4 plain;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-或者
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p3(Pod) --> n3(Node3)
-        p4(mypod) --> n3
-        n4(Node4)
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
-    class p4 plain;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-<!--
-You can tweak the Pod spec to meet various kinds of requirements:
--->
-你可以调整 Pod 规约以满足各种要求：
-
-<!--
-- Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed onto "zoneA" as well.
-- Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4".
-- Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it’s preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.)
--->
-- 将 `maxSkew` 更改为更大的值，比如 "2"，这样新的 Pod 也可以放在 "zoneA" 上。
-- 将 `topologyKey` 更改为 "node"，以便将 Pod 均匀分布在节点上而不是区域中。
-  在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 Pod 只能放在 "node4" 上。
-- 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`，
-  以确保新的 Pod 始终可以被调度（假设满足其他的调度 API）。
-  但是，最好将其放置在匹配 Pod 数量较少的拓扑域中。
-  （请注意，这一优先判定会与其他内部调度优先级（如资源使用率等）排序准则一起进行标准化。）
-
-<!--
-### Example: Multiple TopologySpreadConstraints
--->
-### 例子：多个 TopologySpreadConstraints
-
-<!--
-This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
--->
-下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，其中 3 个标记为 `foo:bar` 的
-Pod 分别位于 node1、node2 和 node3 上：
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p3(Pod) --> n3(Node3)
-        n4(Node4)
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
-    class p4 plain;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-<!--
-You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:
--->
-可以使用 2 个 TopologySpreadConstraint 来控制 Pod 在 区域和节点两个维度上的分布：
-
-{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
-
-<!--
-In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4".
--->
-在这种情况下，为了匹配第一个约束，新的 Pod 只能放置在 "zoneB" 中；而在第二个约束中，
-新的 Pod 只能放置在 "node4" 上。最后两个约束的结果加在一起，唯一可行的选择是放置在
-"node4" 上。
-
-<!--
-Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
--->
-多个约束之间可能存在冲突。假设有一个跨越 2 个区域的 3 节点集群：
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p4(Pod) --> n3(Node3)
-        p5(Pod) --> n3
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n1
-        p3(Pod) --> n2(Node2)
-    end
-
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
-    class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-<!--
-If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put onto "node2". Then a joint result of "zoneB" and "node2" returns nothing.
--->
-如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。
-这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求
-"mypod" 只能放在 "node2" 上。Pod 调度无法满足两种约束。
-
-<!--
-To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`.
--->
-为了克服这种情况，你可以增加 `maxSkew` 或修改其中一个约束，让其使用
-`whenUnsatisfiable: ScheduleAnyway`。
-
-<!--
-### Interaction With Node Affinity and Node Selectors
-
-The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
--->
-### 节点亲和性与节点选择器的相互作用   {#interaction-with-node-affinity-and-node-selectors}
-
-如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，
-调度器将在偏差计算中跳过不匹配的节点。
-
-<!--
-### Example: TopologySpreadConstraints with NodeAffinity
-
-Suppose you have a 5-node cluster ranging from zoneA to zoneC:
--->
-### 示例：TopologySpreadConstraints 与 NodeAffinity
-
-假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneB"
-        p3(Pod) --> n3(Node3)
-        n4(Node4)
-    end
-    subgraph "zoneA"
-        p1(Pod) --> n1(Node1)
-        p2(Pod) --> n2(Node2)
-    end
-
-classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-class n1,n2,n3,n4,p1,p2,p3 k8s;
-class p4 plain;
-class zoneA,zoneB cluster;
-{{< /mermaid >}}
-
-{{<mermaid>}}
-graph BT
-    subgraph "zoneC"
-        n5(Node5)
-    end
-
-classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-class n5 k8s;
-class zoneC cluster;
-{{< /mermaid >}}
-
-
-<!--
-and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed into "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
--->
-而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML，
-以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
-也要一样处理。
-
-{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
-
-<!--
-The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.
--->
-调度器不会预先知道集群拥有的所有区域和其他拓扑域。拓扑域由集群中存在的节点确定。
-在自动伸缩的集群中，如果一个节点池（或节点组）的节点数量为零，
-而用户正期望其扩容时，可能会导致调度出现问题。
-因为在这种情况下，调度器不会考虑这些拓扑域信息，因为它们是空的，没有节点。
-
-<!--
-### Other Noticeable Semantics
-
-There are some implicit conventions worth noting here:
--->
-### 其他值得注意的语义   {#other-noticeable-semantics}
-
-这里有一些值得注意的隐式约定：
-
-<!--
-- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
-
-- The scheduler will bypass the nodes without `topologySpreadConstraints[*].topologyKey` present. This implies that:
-
-  1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA".
-  2. the incoming Pod has no chances to be scheduled onto such nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
--->
-- 只有与新的 Pod 具有相同命名空间的 Pod 才能作为匹配候选者。
-- 调度器会忽略没有 `topologySpreadConstraints[*].topologyKey` 的节点。这意味着：
-  1. 位于这些节点上的 Pod 不影响 `maxSkew` 的计算。
-     在上面的例子中，假设 "node1" 没有标签 "zone"，那么 2 个 Pod 将被忽略，
-     因此传入的 Pod 将被调度到 "zoneA" 中。
-
-  2. 新的 Pod 没有机会被调度到这类节点上。
-     在上面的例子中，假设一个带有标签 `{zone-typo: zoneC}` 的 "node5" 加入到集群，
-     它将由于没有标签键 "zone" 而被忽略。
-
-<!--
-- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
--->
-- 注意，如果新 Pod 的 `topologySpreadConstraints[*].labelSelector`
-  与自身的标签不匹配，将会发生什么。
-  在上面的例子中，如果移除新 Pod 上的标签，Pod 仍然可以调度到 "zoneB"，因为约束仍然满足。
-  然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 Pod，
-  zoneB 有 1 个带有 {foo:bar} 标签的 Pod。
-  因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector`
-  与其自身的标签匹配。
-
-<!--
-### Cluster-level default constraints
-
-It is possible to set default topology spread constraints for a cluster. Default
-topology spread constraints are applied to a Pod if, and only if:
-
-- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
-- It belongs to a service, replication controller, replica set or stateful set.
--->
-### 集群级别的默认约束   {#cluster-level-default-constraints}
-
-为集群设置默认的拓扑分布约束也是可能的。
-默认拓扑分布约束在且仅在以下条件满足时才会被应用到 Pod 上：
-
-- Pod 没有在其 `.spec.topologySpreadConstraints` 设置任何约束；
-- Pod 隶属于某个服务、副本控制器、ReplicaSet 或 StatefulSet。
-
-<!--
-Default constraints can be set as part of the `PodTopologySpread` plugin args
-in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
-The constraints are specified with the same [API above](#api), except that
-`labelSelector` must be empty. The selectors are calculated from the services,
-replication controllers, replica sets or stateful sets that the Pod belongs to.
-
-An example configuration might look like follows:
--->
-你可以在 [调度方案（Scheduling Profile）](/zh-cn/docs/reference/scheduling/config/#profiles)
-中将默认约束作为 `PodTopologySpread` 插件参数的一部分来设置。
-约束的设置采用[如前所述的 API](#api)，只是 `labelSelector` 必须为空。
-选择算符是根据 Pod 所属的服务、副本控制器、ReplicaSet 或 StatefulSet 来设置的。
-
-配置的示例可能看起来像下面这个样子：
-
-```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta3
-kind: KubeSchedulerConfiguration
-
-profiles:
-  - schedulerName: default-scheduler
-    pluginConfig:
-      - name: PodTopologySpread
-        args:
-          defaultConstraints:
-            - maxSkew: 1
-              topologyKey: topology.kubernetes.io/zone
-              whenUnsatisfiable: ScheduleAnyway
-          defaultingType: List
-```
-
-{{< note >}}
-<!--
-[`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
-is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar
-behavior.
--->
-[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。
-建议使用 `PodTopologySpread` 来实现类似的行为。
-{{< /note >}}
-
-<!--
-#### Internal default constraints
--->
-#### 内部默认约束    {#internal-default-constraints}
-
-{{< feature-state for_k8s_version="v1.24" state="stable" >}}
-
-<!--
-If you don't configure any cluster-level default constraints for pod topology spreading,
-then kube-scheduler acts as if you specified the following default topology constraints:
--->
-如果你没有为 Pod 拓扑分布配置任何集群级别的默认约束，
-kube-scheduler 的行为就像你指定了以下默认拓扑约束一样：
-
-```yaml
-defaultConstraints:
-  - maxSkew: 3
-    topologyKey: "kubernetes.io/hostname"
-    whenUnsatisfiable: ScheduleAnyway
-  - maxSkew: 5
-    topologyKey: "topology.kubernetes.io/zone"
-    whenUnsatisfiable: ScheduleAnyway
-```
-
-<!--
-Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
-is disabled by default.
--->
-此外，原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。
-
-{{< note >}}
-<!--
-The `PodTopologySpread` plugin does not score the nodes that don't have
-the topology keys specified in the spreading constraints. This might result
-in a different default behavior compared to the legacy `SelectorSpread` plugin when
-using the default topology constraints.
--->
-对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些主键的节点评分。
-这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同，
-
-<!--
-If your nodes are not expected to have **both** `kubernetes.io/hostname` and
-`topology.kubernetes.io/zone` labels set, define your own constraints
-instead of using the Kubernetes defaults.
--->
-如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和
-`topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用
-Kubernetes 的默认约束。
-{{< /note >}}
-
-<!--
-If you don't want to use the default Pod spreading constraints for your cluster,
-you can disable those defaults by setting `defaultingType` to `List` and leaving
-empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
--->
-如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List`
-并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
-
-```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta3
-kind: KubeSchedulerConfiguration
-
-profiles:
-  - schedulerName: default-scheduler
-    pluginConfig:
-      - name: PodTopologySpread
-        args:
-          defaultConstraints: []
-          defaultingType: List
-```
-
-<!--
-## Comparison with PodAffinity/PodAntiAffinity
-
-In Kubernetes, directives related to "Affinity" control how Pods are
-scheduled - more packed or more scattered.
--->
-## 与 PodAffinity/PodAntiAffinity 相比较
-
-在 Kubernetes 中，与“亲和性”相关的指令控制 Pod 的调度方式（更密集或更分散）。
-
-<!--
-- For `PodAffinity`, you can try to pack any number of Pods into qualifying
-  topology domain(s)
-- For `PodAntiAffinity`, only one Pod can be scheduled into a
-  single topology domain.
--->
-- 对于 `PodAffinity`，你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
-- 对于 `PodAntiAffinity`，只能将一个 Pod 调度到某个拓扑域中。
-
-<!--
-For finer control, you can specify topology spread constraints to distribute
-Pods across different topology domains - to achieve either high availability or
-cost-saving. This can also help on rolling update workloads and scaling out
-replicas smoothly. See
-[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
-for more details.
--->
-要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，
-从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。
-有关详细信息，请参考
-[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)文档。
-
-<!--
-## Known Limitations
-
-- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
-You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
-
-- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
--->
-## 已知局限性
-
-- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时，
-  Pod 的分布可能不再均衡。
-  你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler)
-  来重新实现 Pod 分布的均衡。
-
-- 具有污点的节点上匹配的 Pods 也会被统计。
-  参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
-
-## {{% heading "whatsnext" %}}
-
-<!--
-- [Blog: Introducing PodTopologySpread](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)
-  explains `maxSkew` in details, as well as bringing up some advanced usage examples.
--->
-- [博客: PodTopologySpread介绍](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)
-  详细解释了 `maxSkew`，并给出了一些高级的使用示例。

content/zh-cn/docs/contribute/style/diagram-guide.md

@@ -723,12 +723,12 @@ Note that the live editor doesn't recognize Hugo shortcodes.
 ### Example 1 - Pod topology spread constraints
 
 Figure 6 shows the diagram appearing in the
-[Pod topology pread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
+[Pod topology pread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/#node-labels)
 page.
 -->
 ### 示例 1 - Pod 拓扑分布约束
 
-图 6 展示的是 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
+图 6 展示的是 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/#node-labels)
 页面所出现的图表。
 
 {{< mermaid >}}

content/zh-cn/docs/reference/_index.md

@@ -135,7 +135,7 @@ operator to use or manage a cluster.
 * [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
 * [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/)
 * [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
-* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1/)
+* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
 * [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) and
   [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
 * [kubelet credential providers (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
@@ -158,7 +158,7 @@ operator to use or manage a cluster.
 * [kube-apiserver 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/)
 * [kube-apiserver 配置 (v1)](/zh-cn/docs/reference/config-api/apiserver-config.v1/)
 * [kube-apiserver 加密 (v1)](/zh-cn/docs/reference/config-api/apiserver-encryption.v1/)
-* [kube-apiserver 事件速率限制 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1/)
+* [kube-apiserver 事件速率限制 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
 * [kubelet 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/) 和
   [kubelet 配置 (v1beta1)](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
 * [kubelet 凭据驱动 (v1alpha1)](/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)

content/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz.md

@@ -1,18 +1,18 @@
 ---
 title: Kubelet 认证/鉴权
 ---
-<!-- 
+<!--
 reviewers:
 - liggitt
 title: Kubelet authentication/authorization
 -->
 
-<!-- 
-## Overview 
+<!--
+## Overview
 -->
-## 概述
+## 概述  {#overview}
 
-<!--  
+<!--
 A kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity,
 and allow you to perform operations with varying levels of power on the node and within containers.
 -->
@@ -20,17 +20,17 @@ kubelet 的 HTTPS 端点公开了 API，
 这些 API 可以访问敏感度不同的数据，
 并允许你在节点上和容器内以不同级别的权限执行操作。
 
-<!--  
+<!--
 This document describes how to authenticate and authorize access to the kubelet's HTTPS endpoint.
 -->
 本文档介绍了如何对 kubelet 的 HTTPS 端点的访问进行认证和鉴权。
 
-<!-- 
-## Kubelet authentication 
+<!--
+## Kubelet authentication
 -->
-## Kubelet 身份认证 
+## Kubelet 身份认证   {#kubelet-authentication}
 
-<!-- 
+<!--
 By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured
 authentication methods are treated as anonymous requests, and given a username of `system:anonymous`
 and a group of `system:unauthenticated`.
@@ -38,62 +38,62 @@ and a group of `system:unauthenticated`.
 默认情况下，未被已配置的其他身份认证方法拒绝的对 kubelet 的 HTTPS 端点的请求会被视为匿名请求，
 并被赋予 `system:anonymous` 用户名和 `system:unauthenticated` 组。
 
-<!--  
+<!--
 To disable anonymous access and send `401 Unauthorized` responses to unauthenticated requests:
 -->
 要禁用匿名访问并向未经身份认证的请求发送 `401 Unauthorized` 响应，请执行以下操作：
 
-<!-- 
-* start the kubelet with the `--anonymous-auth=false` flag 
+<!--
+* start the kubelet with the `--anonymous-auth=false` flag
 -->
 * 带 `--anonymous-auth=false` 标志启动 kubelet
 
-<!-- 
+<!--
 To enable X509 client certificate authentication to the kubelet's HTTPS endpoint:
 -->
 要对 kubelet 的 HTTPS 端点启用 X509 客户端证书认证：
 
-<!--  
+<!--
 * start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
 * start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
 * see the [apiserver authentication documentation](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
 -->
 * 带 `--client-ca-file` 标志启动 kubelet，提供一个 CA 证书包以供验证客户端证书
-* 带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 标志启动 apiserver
+* 带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 标志启动 API 服务器
 * 有关更多详细信息，请参见
-  [apiserver 身份验证文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs)
+  [API 服务器身份验证文档](/zh-cn/docs/reference/access-authn-authz/authentication/#x509-client-certs)
 
-<!--  
+<!--
 To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
 -->
 要启用 API 持有者令牌（包括服务帐户令牌）以对 kubelet 的 HTTPS 端点进行身份验证，请执行以下操作：
 
-<!--  
+<!--
 * ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
-* start the kubelet with the `--authentication-token-webhook` and the `--kubeconfig` flags
+* start the kubelet with the `--authentication-token-webhook` and `--kubeconfig` flags
 * the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
 -->
 * 确保在 API 服务器中启用了 `authentication.k8s.io/v1beta1` API 组
 * 带 `--authentication-token-webhook` 和 `--kubeconfig` 标志启动 kubelet
 * kubelet 调用已配置的 API 服务器上的 `TokenReview` API，以根据持有者令牌确定用户信息
 
-<!-- 
-## Kubelet authorization 
+<!--
+## Kubelet authorization
 -->
-## Kubelet 鉴权 
+## Kubelet 鉴权   {#kubelet-authorization}
 
-<!--  
+<!--
 Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
 -->
-任何成功通过身份验证的请求（包括匿名请求）之后都会被鉴权。 
+任何成功通过身份验证的请求（包括匿名请求）之后都会被鉴权。
 默认的鉴权模式为 `AlwaysAllow`，它允许所有请求。
 
-<!--  
+<!--
 There are many possible reasons to subdivide access to the kubelet API:
 -->
 细分对 kubelet API 的访问权限可能有多种原因：
 
-<!--  
+<!--
 * anonymous auth is enabled, but anonymous users' ability to call the kubelet API should be limited
 * bearer token auth is enabled, but arbitrary API users' (like service accounts) ability to call the kubelet API should be limited
 * client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
@@ -102,12 +102,12 @@ There are many possible reasons to subdivide access to the kubelet API:
 * 启用了持有者令牌认证，但应限制任意 API 用户（如服务帐户）调用 kubelet API 的能力
 * 启用了客户端证书身份验证，但仅应允许已配置的 CA 签名的某些客户端证书使用 kubelet API
 
-<!--  
+<!--
 To subdivide access to the kubelet API, delegate authorization to the API server:
 -->
 要细分对 kubelet API 的访问权限，请将鉴权委派给 API 服务器：
 
-<!--  
+<!--
 * ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
 * start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags
 * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
@@ -117,19 +117,19 @@ To subdivide access to the kubelet API, delegate authorization to the API server
 * kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，
   以确定每个请求是否得到鉴权
 
-<!--  
+<!--
 The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver.
 -->
-kubelet 使用与 apiserver 相同的
-[请求属性](/zh/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)
+kubelet 使用与 API 服务器相同的
+[请求属性](/zh-cn/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)
 方法对 API 请求执行鉴权。
 
-<!--  
+<!--
 The verb is determined from the incoming request's HTTP verb:
 -->
 请求的动词根据传入请求的 HTTP 动词确定：
 
-<!-- 
+<!--
 HTTP verb | request verb
 -->
 HTTP 动词 | 请求动词
@@ -140,13 +140,13 @@ PUT       | update
 PATCH     | patch
 DELETE    | delete
 
-<!--  
+<!--
 The resource and subresource is determined from the incoming request's path:
 -->
 资源和子资源是根据传入请求的路径确定的：
 
 <!--
-Kubelet API  | resource | subresource  
+Kubelet API  | resource | subresource
 -->
 Kubelet API  | 资源 | 子资源
 -------------|----------|------------
@@ -154,20 +154,20 @@ Kubelet API  | 资源 | 子资源
 /metrics/\*   | nodes    | metrics
 /logs/\*      | nodes    | log
 /spec/\*      | nodes    | spec
-*其它所有* | nodes    | proxy
+**其它所有**  | nodes    | proxy
 
-<!--  
+<!--
 The namespace and API group attributes are always an empty string, and
 the resource name is always the name of the kubelet's `Node` API object.
 -->
 名字空间和 API 组属性始终是空字符串，
 资源名称始终是 kubelet 的 `Node` API 对象的名称。
 
-<!--  
+<!--
 When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
 flags passed to the apiserver is authorized for the following attributes:
 -->
-在此模式下运行时，请确保传递给 apiserver 的由 `--kubelet-client-certificate` 和
+在此模式下运行时，请确保传递给 API 服务器的由 `--kubelet-client-certificate` 和
 `--kubelet-client-key` 标志标识的用户具有以下属性的鉴权：
 
 * verb=\*, resource=nodes, subresource=proxy

content/zh-cn/docs/reference/config-api/apiserver-audit.v1.md

@@ -743,12 +743,12 @@ PolicyRule 包含一个映射，基于元数据将请求映射到某审计级别
    <!--Namespaces that this rule matches.
    The empty string &quot;&quot; matches non-namespaced resources.
    An empty list implies every namespace.-->
-   </td>
    <p>
    此规则所适用的名字空间列表。
    空字符串（&quot;&quot;）意味着适用于非名字空间作用域的资源。
    空列表意味着适用于所有名字空间。
    </p>
+</td>
 </tr>
 
 <tr><td><code>nonResourceURLs</code><br/>

content/zh-cn/docs/reference/glossary/event.md

@@ -2,9 +2,9 @@
 title: 事件（Event）
 id: event
 date: 2022-01-16
-full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/
+full_link: /zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1/
 short_description: >
-   对集群中周处发生的事件的报告。通常用来表述系统中某种状态变更。
+   对集群中某处所发生事件的报告。通常用来表述系统中某种状态变更。
 aka: 
 tags:
 - core-object
@@ -25,11 +25,11 @@ tags:
 -->
 
 <!--
-Each Event is a report of an event somewhere in the {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
+Each Event is a report of an event somewhere in the {{< glossary_tooltip text="cluster" term_id="cluster" >}}. 
 It generally denotes some state change in the system.
 -->
-每个 Event 是{{< glossary_tooltip text="集群" term_id="cluster" >}}中某处发生的事件的报告。
-它通常用来表述系统中的某种状态变化。
+每个 Event 是{{< glossary_tooltip text="集群" term_id="cluster" >}}中某处所发生事件的报告。
+它通常用来表述系统中的某种状态变更。
 
 <!--more-->
 
@@ -40,7 +40,7 @@ or the continued existence of events with that reason.
 -->
 事件的保留时间有限，随着时间推进，其触发方式和消息都可能发生变化。
 事件用户不应该对带有给定原因（反映下层触发源）的时间特征有任何依赖，
-也不要寄希望于对应该原因的事件会一直存在。
+也不要寄希望于该原因所造成的事件会一直存在。
 
 <!--
 Events should be treated as informative, best-effort, supplemental data.
@@ -52,5 +52,5 @@ In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a di
 Event record (API group `audit.k8s.io`).
 -->
 在 Kubernetes 中，[审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/)
-机制会生成一种不同种类的 Event 记录（API 组为 `audit.k8s.io`）。
+机制会生成一种不同类别的 Event 记录（API 组为 `audit.k8s.io`）。
 

content/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-template-v1.md

@@ -0,0 +1,779 @@
+---
+api_metadata:
+  apiVersion: "v1"
+  import: "k8s.io/api/core/v1"
+  kind: "PodTemplate"
+content_type: "api_reference"
+description: "PodTemplate 描述一种模板，用来为预定义的 Pod 生成副本。"
+title: "PodTemplate"
+weight: 2
+---
+
+<!--
+api_metadata:
+  apiVersion: "v1"
+  import: "k8s.io/api/core/v1"
+  kind: "PodTemplate"
+content_type: "api_reference"
+description: "PodTemplate describes a template for creating copies of a predefined pod."
+title: "PodTemplate"
+weight: 2
+auto_generated: true
+-->
+
+`apiVersion: v1`
+
+`import "k8s.io/api/core/v1"`
+
+## PodTemplate {#PodTemplate}
+
+<!--
+PodTemplate describes a template for creating copies of a predefined pod.
+-->
+PodTemplate 描述一种模板，用来为预定义的 Pod 生成副本。
+
+<hr>
+
+- **apiVersion**: v1
+
+- **kind**: PodTemplate
+
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+
+  <!--
+  Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+  -->
+  标准的对象元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec</a>)
+
+  <!--
+  Template defines the pods that will be created from this pod template. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+  -->
+  template 定义将基于此 Pod 模板所创建的 Pod。
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+## PodTemplateSpec {#PodTemplateSpec}
+
+<!--
+PodTemplateSpec describes the data a pod should have when created from a template
+-->
+PodTemplateSpec 描述基于某模板所创建的 Pod 所应具有的数据。
+
+<hr>
+
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+
+  <!--
+  Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+  -->
+  标准的对象元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **spec** (<a href="{{< ref "../workload-resources/pod-v1#PodSpec" >}}">PodSpec</a>)
+
+  <!--
+  Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+  -->
+  Pod 预期行为的规约。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+## PodTemplateList {#PodTemplateList}
+
+<!--
+PodTemplateList is a list of PodTemplates.
+-->
+PodTemplateList 是 PodTemplate 对象的列表。
+
+<hr>
+
+- **apiVersion**: v1
+
+- **kind**: PodTemplateList
+
+- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
+
+  <!--
+  Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+  -->
+  标准的列表元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+<!--
+- **items** ([]<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>), required
+-->
+- **items** ([]<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>)，必需
+
+  <!--
+  List of pod templates
+  -->
+  PodTemplate 对象列表。
+
+<!--
+## Operations {#Operations}
+
+<hr>
+-->
+## 操作 {#Operations}
+
+<hr>
+
+<!--
+### `get` read the specified PodTemplate
+
+#### HTTP Request
+-->
+### `get` 读取指定的 PodTemplate
+
+#### HTTP 请求
+
+GET /api/v1/namespaces/{namespace}/podtemplates/{name}
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **name** (*in path*): string, required
+
+  name of the PodTemplate
+-->
+- **name** （**路径参数**）：string，必需
+
+  PodTemplate 的名称
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind PodTemplate
+
+#### HTTP Request
+-->
+### `list` 列出或监视 PodTemplate 类型的对象
+
+#### HTTP 请求
+
+GET /api/v1/namespaces/{namespace}/podtemplates
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+<!--
+- **allowWatchBookmarks** (*in query*): boolean
+-->
+- **allowWatchBookmarks** （**查询参数**）：boolean
+
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+<!--
+- **continue** (*in query*): string
+-->
+- **continue** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+<!--
+- **fieldSelector** (*in query*): string
+-->
+- **fieldSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+<!--
+- **labelSelector** (*in query*): string
+-->
+- **labelSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+<!--
+- **limit** (*in query*): integer
+-->
+- **limit** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+- **resourceVersion** (*in query*): string
+-->
+- **resourceVersion** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+<!--
+- **resourceVersion** (*in query*): string
+-->
+- **resourceVersion** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+<!--
+- **timeoutSeconds** (*in query*): integer
+-->
+- **timeoutSeconds** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+<!--
+- **watch** (*in query*): boolean
+-->
+- **watch** （**查询参数**）：boolean
+
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateList" >}}">PodTemplateList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind PodTemplate
+
+#### HTTP Request
+-->
+### `list` 列出或监视 PodTemplate 类型的对象
+
+#### HTTP 请求
+
+GET /api/v1/podtemplates
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **allowWatchBookmarks** (*in query*): boolean
+-->
+- **allowWatchBookmarks** （**查询参数**）：boolean
+
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+<!--
+- **continue** (*in query*): string
+-->
+- **continue** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+<!--
+- **fieldSelector** (*in query*): string
+-->
+- **fieldSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+<!--
+- **labelSelector** (*in query*): string
+-->
+- **labelSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+<!--
+- **limit** (*in query*): integer
+-->
+- **limit** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+- **resourceVersion** (*in query*): string
+-->
+- **resourceVersion** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+<!--
+- **resourceVersionMatch** (*in query*): string
+-->
+- **resourceVersionMatch** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+<!--
+- **timeoutSeconds** (*in query*): integer
+-->
+- **timeoutSeconds** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+<!--
+- **watch** (*in query*): boolean
+-->
+- **watch** （**查询参数**）：boolean
+
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateList" >}}">PodTemplateList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `create` create a PodTemplate
+
+#### HTTP Request
+-->
+### `create` 创建一个 PodTemplate
+
+#### HTTP 请求
+
+POST /api/v1/namespaces/{namespace}/podtemplates
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+<!--
+- **body**: <a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>, required
+-->
+- **body**: <a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>，必需
+
+<!--
+- **dryRun** (*in query*): string
+-->
+- **dryRun** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+<!--
+- **fieldManager** (*in query*): string
+-->
+- **fieldManager** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+<!--
+- **fieldValidation** (*in query*): string
+-->
+- **fieldValidation** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): Created
+
+202 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `update` replace the specified PodTemplate
+
+#### HTTP Request
+-->
+### `update` 替换指定的 PodTemplate
+
+#### HTTP 请求
+
+PUT /api/v1/namespaces/{namespace}/podtemplates/{name}
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **name** (*in path*): string, required
+
+  name of the PodTemplate
+-->
+- **name** （**路径参数**）：string，必需
+
+  PodTemplate 的名称
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+<!--
+- **body**: <a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>, required
+-->
+- **body**: <a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>，必需
+
+<!--
+- **dryRun** (*in query*): string
+-->
+- **dryRun** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+<!--
+- **fieldManager** (*in query*): string
+-->
+- **fieldManager** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+<!--
+- **fieldValidation** (*in query*): string
+-->
+- **fieldValidation** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): Created
+
+401: Unauthorized
+
+<!--
+### `patch` partially update the specified PodTemplate
+
+#### HTTP Request
+-->
+### `patch` 部分更新指定的 PodTemplate
+
+#### HTTP 请求
+
+PATCH /api/v1/namespaces/{namespace}/podtemplates/{name}
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **name** (*in path*): string, required
+
+  name of the PodTemplate
+-->
+- **name** （**路径参数**）：string，必需
+
+  PodTemplate 的名称
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+<!--
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>, required
+-->
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>，必需
+
+<!--
+- **dryRun** (*in query*): string
+-->
+- **dryRun** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+<!--
+- **fieldManager** (*in query*): string
+-->
+- **fieldManager** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+<!--
+- **fieldValidation** (*in query*): string
+-->
+- **fieldValidation** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+<!--
+- **force** (*in query*): boolean
+-->
+- **force** （**查询参数**）：boolean
+
+  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): Created
+
+401: Unauthorized
+
+<!--
+### `delete` delete a PodTemplate
+
+#### HTTP Request
+-->
+### `delete` 删除一个 PodTemplate
+
+#### HTTP 请求
+
+DELETE /api/v1/namespaces/{namespace}/podtemplates/{name}
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **name** (*in path*): string, required
+
+  name of the PodTemplate
+-->
+- **name** （**路径参数**）：string，必需
+
+  PodTemplate 的名称
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+<!--
+- **dryRun** (*in query*): string
+-->
+- **dryRun** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+<!--
+- **gracePeriodSeconds** (*in query*): integer
+-->
+- **gracePeriodSeconds** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+- **propagationPolicy** (*in query*): string
+-->
+- **propagationPolicy** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): OK
+
+202 (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplate" >}}">PodTemplate</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `deletecollection` delete collection of PodTemplate
+
+#### HTTP Request
+-->
+### `deletecollection` 删除 PodTemplate 的集合
+
+#### HTTP 请求
+
+DELETE /api/v1/namespaces/{namespace}/podtemplates
+
+<!--
+#### Parameters
+-->
+#### 参数
+
+<!--
+- **namespace** (*in path*): string, required
+-->
+- **namespace** （**路径参数**）：string，必需
+
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+<!--
+- **continue** (*in query*): string
+-->
+- **continue** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+<!--
+- **dryRun** (*in query*): string
+-->
+- **dryRun** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+<!--
+- **fieldSelector** (*in query*): string
+-->
+- **fieldSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+<!--
+- **gracePeriodSeconds** (*in query*): integer
+-->
+- **gracePeriodSeconds** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+<!--
+- **labelSelector** (*in query*): string
+-->
+- **labelSelector** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+<!--
+- **limit** (*in query*): integer
+-->
+- **limit** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+<!--
+- **pretty** (*in query*): string
+-->
+- **pretty** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+- **propagationPolicy** (*in query*): string
+-->
+- **propagationPolicy** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+<!--
+- **resourceVersion** (*in query*): string
+-->
+- **resourceVersion** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+<!--
+- **resourceVersionMatch** (*in query*): string
+-->
+- **resourceVersionMatch** （**查询参数**）：string
+
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+<!--
+- **timeoutSeconds** (*in query*): integer
+-->
+- **timeoutSeconds** （**查询参数**）：integer
+
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): OK
+
+401: Unauthorized
+

content/zh-cn/docs/reference/kubernetes-api/workload-resources/replica-set-v1.md

@@ -0,0 +1,979 @@
+---
+api_metadata:
+  apiVersion: "apps/v1"
+  import: "k8s.io/api/apps/v1"
+  kind: "ReplicaSet"
+content_type: "api_reference"
+description: "ReplicaSet 确保在任何给定的时刻都在运行指定数量的 Pod 副本。"
+title: "ReplicaSet"
+weight: 4
+---
+<!--
+api_metadata:
+  apiVersion: "apps/v1"
+  import: "k8s.io/api/apps/v1"
+  kind: "ReplicaSet"
+content_type: "api_reference"
+description: "ReplicaSet ensures that a specified number of pod replicas are running at any given time."
+title: "ReplicaSet"
+weight: 4
+auto_generated: true
+-->
+
+`apiVersion: apps/v1`
+
+`import "k8s.io/api/apps/v1"`
+
+## ReplicaSet {#ReplicaSet}
+
+<!--
+ReplicaSet ensures that a specified number of pod replicas are running at any given time.
+-->
+ReplicaSet 确保在任何给定的时刻都在运行指定数量的 Pod 副本。
+
+<hr>
+
+- **apiVersion**: apps/v1
+
+- **kind**: ReplicaSet
+
+<!--
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+
+  If the Labels of a ReplicaSet are empty, they are defaulted to be the same as the Pod(s) that the ReplicaSet manages. Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **spec** (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetSpec" >}}">ReplicaSetSpec</a>)
+
+  Spec defines the specification of the desired behavior of the ReplicaSet. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+-->
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+  
+  如果 ReplicaSet 的标签为空，则这些标签默认为与 ReplicaSet 管理的 Pod 相同。
+  标准的对象元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **spec** (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetSpec" >}}">ReplicaSetSpec</a>)
+  
+  spec 定义 ReplicaSet 预期行为的规约。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+<!--
+- **status** (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetStatus" >}}">ReplicaSetStatus</a>)
+
+  Status is the most recently observed status of the ReplicaSet. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+-->
+- **status** (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetStatus" >}}">ReplicaSetStatus</a>)
+  
+  status 是最近观测到的 ReplicaSet 状态。此数据可能在某个时间窗之后过期。
+  该值由系统填充，只读。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+## ReplicaSetSpec {#ReplicaSetSpec}
+
+<!--
+ReplicaSetSpec is the specification of a ReplicaSet.
+-->
+ReplicaSetSpec 是 ReplicaSet 的规约。
+
+<hr>
+
+<!--
+- **selector** (<a href="{{< ref "../common-definitions/label-selector#LabelSelector" >}}">LabelSelector</a>), required
+
+  Selector is a label query over pods that should match the replica count. Label keys and values that must match in order to be controlled by this replica set. It must match the pod template's labels. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
+
+- **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec</a>)
+
+  Template is the object that describes the pod that will be created if insufficient replicas are detected. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
+-->
+- **selector** (<a href="{{< ref "../common-definitions/label-selector#LabelSelector" >}}">LabelSelector</a>)，必需
+  
+  selector 是针对 Pod 的标签查询，应与副本计数匹配。标签的主键和取值必须匹配，
+  以便由这个 ReplicaSet 进行控制。它必须与 Pod 模板的标签匹配。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors
+
+- **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec</a>)
+  
+  template 是描述 Pod 的一个对象，将在检测到副本不足时创建此对象。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller#pod-template
+
+<!--
+- **replicas** (int32)
+
+  Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
+
+- **minReadySeconds** (int32)
+
+  Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)
+-->
+- **replicas** (int32)
+  
+  replicas 是预期副本的数量。这是一个指针，用于辨别显式零和未指定的值。默认为 1。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
+
+- **minReadySeconds** (int32)
+  
+  新建的 Pod 在没有任何容器崩溃的情况下就绪并被系统视为可用的最短秒数。
+  默认为 0（Pod 就绪后即被视为可用）。
+
+## ReplicaSetStatus {#ReplicaSetStatus}
+
+<!--
+ReplicaSetStatus represents the current status of a ReplicaSet.
+-->
+ReplicaSetStatus 表示 ReplicaSet 的当前状态。
+
+<hr>
+
+<!--
+- **replicas** (int32), required
+
+  Replicas is the most recently oberved number of replicas. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
+
+- **availableReplicas** (int32)
+
+  The number of available replicas (ready for at least minReadySeconds) for this replica set.
+-->
+- **replicas** (int32)，必需
+  
+  replicas 是最近观测到的副本数量。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
+
+- **availableReplicas** (int32)
+  
+  此副本集可用副本（至少 minReadySeconds 才能就绪）的数量。
+
+<!--
+- **readyReplicas** (int32)
+
+  readyReplicas is the number of pods targeted by this ReplicaSet with a Ready Condition.
+
+- **fullyLabeledReplicas** (int32)
+
+  The number of pods that have labels matching the labels of the pod template of the replicaset.
+-->
+- **readyReplicas** (int32)
+  
+  readyReplicas 是此 ReplicaSet 在就绪状况下处理的目标 Pod 数量。
+
+- **fullyLabeledReplicas** (int32)
+  
+  标签与 ReplicaSet 的 Pod 模板标签匹配的 Pod 数量。
+
+<!--
+- **conditions** ([]ReplicaSetCondition)
+
+  *Patch strategy: merge on key `type`*
+  
+  Represents the latest available observations of a replica set's current state.
+
+  <a name="ReplicaSetCondition"></a>
+  *ReplicaSetCondition describes the state of a replica set at a certain point.*
+-->
+- **conditions** ([]ReplicaSetCondition)
+  
+  **补丁策略：按照键 `type` 合并**
+  
+  表示副本集当前状态的最新可用观测值。
+  
+  <a name="ReplicaSetCondition"></a> 
+  **ReplicaSetCondition 描述某个点的副本集状态。**
+  
+  <!--
+  - **conditions.status** (string), required
+
+    Status of the condition, one of True, False, Unknown.
+
+  - **conditions.type** (string), required
+
+    Type of replica set condition.
+  -->
+
+  - **conditions.status** (string)，必需
+    
+    状况的状态，取值为 True、False 或 Unknown 之一。
+  
+  - **conditions.type** (string)，必需
+    
+    副本集状况的类型。
+  
+  <!--
+  - **conditions.lastTransitionTime** (Time)
+
+    The last time the condition transitioned from one status to another.
+
+    <a name="Time"></a>
+    *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON.  Wrappers are provided for many of the factory methods that the time package offers.*
+  -->
+
+  - **conditions.lastTransitionTime** (Time)
+    
+    状况上次从一个状态转换为另一个状态的时间。
+    
+    <a name="Time"></a>
+    **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。
+    为 time 包的许多函数方法提供了封装器。**
+  
+  <!--
+  - **conditions.message** (string)
+
+    A human readable message indicating details about the transition.
+
+  - **conditions.reason** (string)
+
+    The reason for the condition's last transition.
+  -->
+
+  - **conditions.message** (string)
+    
+    这是一条人类可读的消息，指示有关上次转换的详细信息。
+  
+  - **conditions.reason** (string)
+    
+    状况上次转换的原因。
+
+<!--
+- **observedGeneration** (int64)
+
+  ObservedGeneration reflects the generation of the most recently observed ReplicaSet.
+-->
+- **observedGeneration** (int64)
+  
+  observedGeneration 反映了最近观测到的 ReplicaSet 生成情况。
+
+## ReplicaSetList {#ReplicaSetList}
+
+<!--
+ReplicaSetList is a collection of ReplicaSets.
+-->
+ReplicaSetList 是多个 ReplicaSet 的集合。
+
+<hr>
+
+- **apiVersion**: apps/v1
+
+- **kind**: ReplicaSetList
+
+<!--
+- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
+
+  Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+- **items** ([]<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>), required
+
+  List of ReplicaSets. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller
+-->
+- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
+  
+  标准的列表元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+- **items** ([]<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>)，必需
+  
+  ReplicaSet 的列表。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller
+
+<!--
+## Operations {#Operations}
+
+<hr>
+
+### `get` read the specified ReplicaSet
+
+#### HTTP Request
+-->
+## 操作 {#Operations}
+
+<hr>
+
+### `get` 读取指定的 ReplicaSet
+
+#### HTTP 请求
+
+GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+401: Unauthorized
+
+<!--
+### `get` read status of the specified ReplicaSet
+
+#### HTTP Request
+-->
+### `get` 读取指定的 ReplicaSet 的状态
+
+#### HTTP 请求
+
+GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind ReplicaSet
+
+#### HTTP Request
+-->
+### `list` 列出或监视 ReplicaSet 类别的对象
+
+#### HTTP 请求
+
+GET /apis/apps/v1/namespaces/{namespace}/replicasets
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **allowWatchBookmarks** (*in query*): boolean
+- **continue** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+- **watch** (*in query*): boolean
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **allowWatchBookmarks** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+- **watch** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetList" >}}">ReplicaSetList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind ReplicaSet
+
+#### HTTP Request
+-->
+### `list` 列出或监视 ReplicaSet 类别的对象
+
+#### HTTP 请求
+
+GET /apis/apps/v1/replicasets
+
+<!--
+#### Parameters
+- **allowWatchBookmarks** (*in query*): boolean
+- **continue** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+- **watch** (*in query*): boolean
+-->
+#### 参数
+
+- **allowWatchBookmarks** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+- **watch** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSetList" >}}">ReplicaSetList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `create` create a ReplicaSet
+
+#### HTTP Request
+-->
+### `create` 创建 ReplicaSet
+
+#### HTTP 请求
+
+POST /apis/apps/v1/namespaces/{namespace}/replicasets
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Created
+
+202 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `update` replace the specified ReplicaSet
+
+#### HTTP Request
+-->
+### `update` 替换指定的 ReplicaSet
+
+#### HTTP 请求
+
+PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Created
+
+401: Unauthorized
+
+<!--
+### `update` replace status of the specified ReplicaSet
+
+#### HTTP Request
+-->
+### `update` 替换指定的 ReplicaSet 的状态
+
+#### HTTP 请求
+
+PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Created
+
+401: Unauthorized
+
+<!--
+### `patch` partially update the specified ReplicaSet
+
+#### HTTP Request
+-->
+### `patch` 部分更新指定的 ReplicaSet
+
+#### HTTP 请求
+
+PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **force** (*in query*): boolean
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **force** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Created
+
+401: Unauthorized
+
+<!--
+### `patch` partially update status of the specified ReplicaSet
+
+#### HTTP Request
+-->
+### `patch` 部分更新指定的 ReplicaSet 的状态
+
+#### HTTP 请求
+
+PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **force** (*in query*): boolean
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **force** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replica-set-v1#ReplicaSet" >}}">ReplicaSet</a>): Created
+
+401: Unauthorized
+
+<!--
+### `delete` delete a ReplicaSet
+
+#### HTTP Request
+-->
+### `delete` 删除 ReplicaSet
+
+#### HTTP 请求
+
+DELETE /apis/apps/v1/namespaces/{namespace}/replicasets/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicaSet
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+- **dryRun** (*in query*): string
+- **gracePeriodSeconds** (*in query*): integer
+- **pretty** (*in query*): string
+- **propagationPolicy** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicaSet 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **gracePeriodSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **propagationPolicy** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): OK
+
+202 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `deletecollection` delete collection of ReplicaSet
+
+#### HTTP Request
+-->
+### `deletecollection` 删除 ReplicaSet 的集合
+
+#### HTTP 请求
+
+DELETE /apis/apps/v1/namespaces/{namespace}/replicasets
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+- **continue** (*in query*): string
+- **dryRun** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **gracePeriodSeconds** (*in query*): integer
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **propagationPolicy** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **gracePeriodSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **propagationPolicy** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): OK
+
+401: Unauthorized

content/zh-cn/docs/reference/kubernetes-api/workload-resources/replication-controller-v1.md

@@ -0,0 +1,969 @@
+---
+api_metadata:
+  apiVersion: "v1"
+  import: "k8s.io/api/core/v1"
+  kind: "ReplicationController"
+content_type: "api_reference"
+description: "ReplicationController 表示一个副本控制器的配置。"
+title: "ReplicationController"
+weight: 3
+---
+<!--
+api_metadata:
+  apiVersion: "v1"
+  import: "k8s.io/api/core/v1"
+  kind: "ReplicationController"
+content_type: "api_reference"
+description: "ReplicationController represents the configuration of a replication controller."
+title: "ReplicationController"
+weight: 3
+auto_generated: true
+-->
+
+`apiVersion: v1`
+
+`import "k8s.io/api/core/v1"`
+
+## ReplicationController {#ReplicationController}
+
+<!--
+ReplicationController represents the configuration of a replication controller.
+-->
+ReplicationController 表示一个副本控制器的配置。
+
+<hr>
+
+- **apiVersion**: v1
+
+- **kind**: ReplicationController
+
+<!--
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+
+  If the Labels of a ReplicationController are empty, they are defaulted to be the same as the Pod(s) that the replication controller manages. Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **spec** (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerSpec" >}}">ReplicationControllerSpec</a>)
+
+  Spec defines the specification of the desired behavior of the replication controller. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+-->
+- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
+  
+  如果 ReplicationController 的标签为空，则这些标签默认为与副本控制器管理的 Pod 相同。
+  标准的对象元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+- **spec** (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerSpec" >}}">ReplicationControllerSpec</a>)
+  
+  spec 定义副本控制器预期行为的规约。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+<!--
+- **status** (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerStatus" >}}">ReplicationControllerStatus</a>)
+
+  Status is the most recently observed status of the replication controller. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+-->
+- **status** (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerStatus" >}}">ReplicationControllerStatus</a>)
+  
+  status 是最近观测到的副本控制器的状态。此数据可能在某个时间窗之后过期。
+  该值由系统填充，只读。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
+
+## ReplicationControllerSpec {#ReplicationControllerSpec}
+
+<!--
+ReplicationControllerSpec is the specification of a replication controller.
+-->
+ReplicationControllerSpec 表示一个副本控制器的规约。
+
+<hr>
+
+<!--
+- **selector** (map[string]string)
+
+  Selector is a label query over pods that should match the Replicas count. If Selector is empty, it is defaulted to the labels present on the Pod template. Label keys and values that must match in order to be controlled by this replication controller, if empty defaulted to labels on Pod template. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
+
+- **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec</a>)
+
+  Template is the object that describes the pod that will be created if insufficient replicas are detected. This takes precedence over a TemplateRef. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
+-->
+- **selector** (map[string]string)
+  
+  selector 是针对 Pod 的标签查询，符合条件的 Pod 个数应与 replicas 匹配。
+  如果 selector 为空，则默认为出现在 Pod 模板中的标签。
+  如果置空以表示默认使用 Pod 模板中的标签，则标签的主键和取值必须匹配，以便由这个副本控制器进行控制。
+  更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors
+
+- **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec</a>)
+  
+  template 是描述 Pod 的一个对象，将在检测到副本不足时创建此对象。
+  此字段优先于 templateRef。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller#pod-template
+
+<!--
+- **replicas** (int32)
+
+  Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller
+
+- **minReadySeconds** (int32)
+
+  Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)
+-->
+- **replicas** (int32)
+  
+  replicas 是预期副本的数量。这是一个指针，用于辨别显式零和未指定的值。默认为 1。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller
+
+- **minReadySeconds** (int32)
+  
+  新建的 Pod 在没有任何容器崩溃的情况下就绪并被系统视为可用的最短秒数。
+  默认为 0（Pod 就绪后即被视为可用）。
+
+## ReplicationControllerStatus {#ReplicationControllerStatus}
+
+<!--
+ReplicationControllerStatus represents the current status of a replication controller.
+-->
+ReplicationControllerStatus 表示一个副本控制器的当前状态。
+
+<hr>
+
+<!--
+- **replicas** (int32), required
+
+  Replicas is the most recently oberved number of replicas. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller
+
+- **availableReplicas** (int32)
+
+  The number of available replicas (ready for at least minReadySeconds) for this replication controller.
+-->
+- **replicas** (int32)，必需
+  
+  replicas 是最近观测到的副本数量。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller
+
+- **availableReplicas** (int32)
+  
+  这个副本控制器可用副本（至少 minReadySeconds 才能就绪）的数量。
+
+<!--
+- **readyReplicas** (int32)
+
+  The number of ready replicas for this replication controller.
+
+- **fullyLabeledReplicas** (int32)
+
+  The number of pods that have labels matching the labels of the pod template of the replication controller.
+-->
+- **readyReplicas** (int32)
+  
+  此副本控制器所用的就绪副本的数量。
+
+- **fullyLabeledReplicas** (int32)
+  
+  标签与副本控制器的 Pod 模板标签匹配的 Pod 数量。
+
+<!--
+- **conditions** ([]ReplicationControllerCondition)
+
+  *Patch strategy: merge on key `type`*
+  
+  Represents the latest available observations of a replication controller's current state.
+
+  <a name="ReplicationControllerCondition"></a>
+  *ReplicationControllerCondition describes the state of a replication controller at a certain point.*
+-->
+- **conditions** ([]ReplicationControllerCondition)
+  
+  **补丁策略：按照键 `type` 合并**
+  
+  表示副本控制器当前状态的最新可用观测值。
+  
+  <a name="ReplicationControllerCondition"></a>
+  **ReplicationControllerCondition 描述某个点的副本控制器的状态。**
+  
+  <!--
+  - **conditions.status** (string), required
+
+    Status of the condition, one of True, False, Unknown.
+
+  - **conditions.type** (string), required
+
+    Type of replication controller condition.
+  -->
+
+  - **conditions.status** (string)，必需
+    
+    状况的状态，取值为 True、False 或 Unknown 之一。
+  
+  - **conditions.type** (string)，必需
+    
+    副本控制器状况的类型。
+  
+  <!--
+  - **conditions.lastTransitionTime** (Time)
+
+    The last time the condition transitioned from one status to another.
+
+    <a name="Time"></a>
+    *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON.  Wrappers are provided for many of the factory methods that the time package offers.*
+  -->
+
+  - **conditions.lastTransitionTime** (Time)
+    
+    状况上次从一个状态转换为另一个状态的时间。
+    
+    <a name="Time"></a>
+    **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。
+    为 time 包的许多函数方法提供了封装器。**
+  
+  <!--
+  - **conditions.message** (string)
+
+    A human readable message indicating details about the transition.
+
+  - **conditions.reason** (string)
+
+    The reason for the condition's last transition.
+  -->
+  - **conditions.message** (string)
+    
+    这是一条人类可读的消息，指示有关上次转换的详细信息。
+  
+  - **conditions.reason** (string)
+    
+    状况上次转换的原因。
+
+<!--
+- **observedGeneration** (int64)
+
+  ObservedGeneration reflects the generation of the most recently observed replication controller.
+
+## ReplicationControllerList {#ReplicationControllerList}
+
+ReplicationControllerList is a collection of replication controllers.
+-->
+- **observedGeneration** (int64)
+  
+  observedGeneration 反映了最近观测到的副本控制器的生成情况。
+
+## ReplicationControllerList {#ReplicationControllerList}
+
+ReplicationControllerList 是副本控制器的集合。
+
+<hr>
+
+- **apiVersion**: v1
+
+- **kind**: ReplicationControllerList
+
+<!--
+- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
+
+  Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+- **items** ([]<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>), required
+
+  List of replication controllers. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller
+-->
+- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
+  
+  标准的列表元数据。更多信息：
+  https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+- **items** ([]<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>)，必需
+  
+  副本控制器的列表。更多信息：
+  https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller
+
+<!--
+## Operations {#Operations}
+<hr>
+### `get` read the specified ReplicationController
+#### HTTP Request
+-->
+## 操作 {#Operations}
+
+<hr>
+
+### `get` 读取指定的 ReplicationController
+
+#### HTTP 请求
+
+GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+401: Unauthorized
+
+<!--
+### `get` read status of the specified ReplicationController
+#### HTTP Request
+-->
+### `get` 读取指定的 ReplicationController 的状态
+
+#### HTTP 请求
+
+GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind ReplicationController
+#### HTTP Request
+-->
+### `list` 列出或监视 ReplicationController 类别的对象
+
+#### HTTP 请求
+
+GET /api/v1/namespaces/{namespace}/replicationcontrollers
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **allowWatchBookmarks** (*in query*): boolean
+- **continue** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+- **watch** (*in query*): boolean
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **allowWatchBookmarks** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+- **watch** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerList" >}}">ReplicationControllerList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `list` list or watch objects of kind ReplicationController
+#### HTTP Request
+-->
+### `list` 列出或监视 ReplicationController 类别的对象
+
+#### HTTP 请求
+
+GET /api/v1/replicationcontrollers
+
+<!--
+#### Parameters
+- **allowWatchBookmarks** (*in query*): boolean
+- **continue** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+- **watch** (*in query*): boolean
+-->
+#### 参数
+
+- **allowWatchBookmarks** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+- **watch** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationControllerList" >}}">ReplicationControllerList</a>): OK
+
+401: Unauthorized
+
+<!--
+### `create` create a ReplicationController
+#### HTTP Request
+-->
+### `create` 创建 ReplicationController
+
+#### HTTP 请求
+
+POST /api/v1/namespaces/{namespace}/replicationcontrollers
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Created
+
+202 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `update` replace the specified ReplicationController
+#### HTTP Request
+-->
+### `update` 替换指定的 ReplicationController
+
+#### HTTP 请求
+
+PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Created
+
+401: Unauthorized
+
+<!--
+### `update` replace status of the specified ReplicationController
+#### HTTP Request
+-->
+### `update` 替换指定的 ReplicationController 的状态
+
+#### HTTP 请求
+
+PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Created
+
+401: Unauthorized
+
+<!--
+### `patch` partially update the specified ReplicationController
+#### HTTP Request
+-->
+### `patch` 部分更新指定的 ReplicationController
+
+#### HTTP 请求
+
+PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **force** (*in query*): boolean
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **force** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Created
+
+401: Unauthorized
+
+<!--
+### `patch` partially update status of the specified ReplicationController
+#### HTTP Request
+-->
+### `patch` 部分更新指定的 ReplicationController 的状态
+
+#### HTTP 请求
+
+PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>, required
+- **dryRun** (*in query*): string
+- **fieldManager** (*in query*): string
+- **fieldValidation** (*in query*): string
+- **force** (*in query*): boolean
+- **pretty** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch</a>，必需
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldManager** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
+
+- **fieldValidation** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
+
+- **force** (**查询参数**): boolean
+  
+  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): OK
+
+201 (<a href="{{< ref "../workload-resources/replication-controller-v1#ReplicationController" >}}">ReplicationController</a>): Created
+
+401: Unauthorized
+
+<!--
+### `delete` delete a ReplicationController
+#### HTTP Request
+-->
+### `delete` 删除 ReplicationController
+
+#### HTTP 请求
+
+DELETE /api/v1/namespaces/{namespace}/replicationcontrollers/{name}
+
+<!--
+#### Parameters
+- **name** (*in path*): string, required
+  name of the ReplicationController
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+- **dryRun** (*in query*): string
+- **gracePeriodSeconds** (*in query*): integer
+- **pretty** (*in query*): string
+- **propagationPolicy** (*in query*): string
+-->
+#### 参数
+
+- **name** (**路径参数**): string，必需
+  
+  ReplicationController 的名称
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **gracePeriodSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **propagationPolicy** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): OK
+
+202 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): Accepted
+
+401: Unauthorized
+
+<!--
+### `deletecollection` delete collection of ReplicationController
+#### HTTP Request
+-->
+### `deletecollection` 删除 ReplicationController 的集合
+
+#### HTTP 请求
+
+DELETE /api/v1/namespaces/{namespace}/replicationcontrollers
+
+<!--
+#### Parameters
+- **namespace** (*in path*): string, required
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+- **continue** (*in query*): string
+- **dryRun** (*in query*): string
+- **fieldSelector** (*in query*): string
+- **gracePeriodSeconds** (*in query*): integer
+- **labelSelector** (*in query*): string
+- **limit** (*in query*): integer
+- **pretty** (*in query*): string
+- **propagationPolicy** (*in query*): string
+- **resourceVersion** (*in query*): string
+- **resourceVersionMatch** (*in query*): string
+- **timeoutSeconds** (*in query*): integer
+-->
+#### 参数
+
+- **namespace** (**路径参数**): string，必需
+  
+  <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace</a>
+
+- **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions</a>
+
+- **continue** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue</a>
+
+- **dryRun** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
+
+- **fieldSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector</a>
+
+- **gracePeriodSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds</a>
+
+- **labelSelector** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector</a>
+
+- **limit** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit</a>
+
+- **pretty** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
+
+- **propagationPolicy** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy</a>
+
+- **resourceVersion** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion</a>
+
+- **resourceVersionMatch** (**查询参数**): string
+  
+  <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch</a>
+
+- **timeoutSeconds** (**查询参数**): integer
+  
+  <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds</a>
+
+<!--
+#### Response
+-->
+#### 响应
+
+200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status</a>): OK
+
+401: Unauthorized

content/zh-cn/docs/reference/labels-annotations-taints/_index.md

@@ -1261,6 +1261,30 @@ for more information.
 
 请参阅[在名字空间级别实施 Pod 安全性](/zh-cn/docs/concepts/security/pod-security-admission)了解更多信息。
 
+
+<!--
+### kubernetes.io/psp (deprecated) {#kubernetes-io-psp}
+
+Example: `kubernetes.io/psp: restricted`
+
+This annotation is only relevant if you are using [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
+
+When the PodSecurityPolicy admission controller admits a Pod, the admission controller
+modifies the Pod to have this annotation.
+The value of the annotation is the name of the PodSecurityPolicy that was used for validation.
+
+-->
+
+### kubernetes.io/psp（已弃用） {#kubernetes-io-psp}
+
+例如：`kubernetes.io/psp: restricted`
+
+这个注解只在你使用 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/) 时才有意义。
+
+当 PodSecurityPolicy 准入控制器接受一个 Pod 时，会修改该 Pod，
+并给这个 Pod 添加此注解。
+注解的值是用来对 Pod 进行验证检查的 PodSecurityPolicy 的名称。
+
 <!--
 ### seccomp.security.alpha.kubernetes.io/pod (deprecated) {#seccomp-security-alpha-kubernetes-io-pod}
 

content/zh-cn/docs/reference/scheduling/config.md

@@ -229,10 +229,10 @@ extension points:
   实现的扩展点：`filter`，`score`.
 <!--  
 - `PodTopologySpread`: Implements
-  [Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+  [Pod topology spread](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
   Extension points: `preFilter`, `filter`, `preScore`, `score`.
 -->
-- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)。
 
   实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。
 <!--  

content/zh-cn/docs/reference/using-api/deprecation-guide.md

@@ -723,13 +723,13 @@ For example:
 <!--
 ### Locate use of deprecated APIs
 
-Use [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings)
+Use [client warnings, metrics, and audit information available in 1.19+](/blog/2020/09/03/warnings/#deprecation-warnings)
 to locate use of deprecated APIs.
 -->
 ### 定位何处使用了已弃用的 API
 
-使用 [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings)
-来定位在何处使用了已启用的 API。
+使用 [client warnings, metrics, and audit information available in 1.19+](/blog/2020/09/03/warnings/#deprecation-warnings)
+来定位在何处使用了已弃用的 API。
 
 <!--
 ### Migrate to non-deprecated APIs
@@ -755,7 +755,7 @@ to automatically convert an existing object:
 <!--
 For example, to convert an older Deployment to `apps/v1`, you can run:
 -->
-例如，要将较老的 Deployment 转换为 `apps/v1` 版本，你可以运行
+例如，要将较老的 Deployment 版本转换为 `apps/v1` 版本，你可以运行
 
 `kubectl-convert -f ./my-deployment.yaml --output-version apps/v1`
 
@@ -763,5 +763,5 @@ For example, to convert an older Deployment to `apps/v1`, you can run:
 Note that this may use non-ideal default values. To learn more about a specific
 resource, check the Kubernetes [API reference](/docs/reference/kubernetes-api/).
 -->
-注意这种操作生成的结果中可能使用的默认值并不理想。
+需要注意的是这种操作使用的默认值可能并不理想。
 要进一步了解某个特定资源，可查阅 Kubernetes [API 参考](/zh-cn/docs/reference/kubernetes-api/)。

content/zh-cn/docs/setup/best-practices/multiple-zones.md

@@ -113,7 +113,7 @@ These labels can include
 <!--
 If your cluster spans multiple zones or regions, you can use node labels
 in conjunction with
-[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 to control how Pods are spread across your cluster among fault domains:
 regions, zones, and even specific nodes.
 These hints enable the
@@ -122,7 +122,7 @@ Pods for better expected availability, reducing the risk that a correlated
 failure affects your whole workload.
 -->
 如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合
-[Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+[Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是
 地理区域、可用区甚至是特定节点。
 这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}

content/zh-cn/docs/setup/production-environment/_index.md

@@ -101,12 +101,12 @@ by managing [policies](/docs/concepts/policy/) and
 Before building a Kubernetes production environment on your own, consider
 handing off some or all of this job to 
 [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) 
-providers or other [Kubernetes Partners](https://kubernetes.io/partners/).
+providers or other [Kubernetes Partners](/partners/).
 Options include:
 -->
-在自行构造 Kubernetes 生产环境之前，请考虑将这一任务的部分或者全部交给
+在自行构建 Kubernetes 生产环境之前，请考虑将这一任务的部分或者全部交给
 [云方案承包服务](/zh-cn/docs/setup/production-environment/turnkey-solutions)
-提供商或者其他 [Kubernetes 合作伙伴](https://kubernetes.io/partners/)。
+提供商或者其他 [Kubernetes 合作伙伴](/zh-cn/partners/)。
 选项有：
 
 <!--
@@ -137,8 +137,8 @@ to your cluster’s *control plane*, *worker nodes*, *user access*, and
 *workload resources*.
 -->
 无论你是自行构造一个生产用 Kubernetes 集群还是与合作伙伴一起协作，请审阅
-下面章节以评估你的需求，因为这关系到你的集群的 *控制面*、*工作节点*、
-*用户访问* 以及 *负载资源*。
+下面章节以评估你的需求，因为这关系到你的集群的**控制面**、**工作节点**、
+**用户访问**以及**负载资源**。
 
 <!--
 ## Production cluster setup
@@ -167,7 +167,7 @@ discarded if something goes seriously wrong, this might meet your needs.
 ### 生产用控制面  {#production-control-plane}
 
 最简单的 Kubernetes 集群中，整个控制面和工作节点服务都运行在同一台机器上。
-你可以通过添加工作节点来提升环境能力，正如
+你可以通过添加工作节点来提升环境运算能力，正如
 [Kubernetes 组件](/zh-cn/docs/concepts/overview/components/)示意图所示。
 如果只需要集群在很短的一段时间内可用，或者可以在某些事物出现严重问题时直接丢弃，
 这种配置可能符合你的需要。
@@ -182,7 +182,7 @@ consider these steps:
 -->
 如果你需要一个更为持久的、高可用的集群，那么就需要考虑扩展控制面的方式。
 根据设计，运行在一台机器上的单机控制面服务不是高可用的。
-如果保持集群处于运行状态并且需要确保在出现问题时能够被修复这点很重要，
+如果你认为保持集群的正常运行的并需要确保它在出错时可以被修复是很重要的，
 可以考虑以下步骤：
 
 <!--
@@ -338,7 +338,7 @@ then add and run the appropriate
   - The demands of your workloads when you set up nodes by having appropriate memory, CPU, and disk speed and storage capacity available.
   - Whether generic computer systems will do or you have workloads that need GPU processors, Windows nodes, or VM isolation.
   -->
-  - 在安装节点时要通过配置适当的内存、CPU 和磁盘速度、存储容量来满足
+  - 在安装节点时要通过配置适当的内存、CPU 和磁盘读写速率、存储容量来满足
     你的负载的需求。
   - 是否通用的计算机系统即足够，还是你有负载需要使用 GPU 处理器、Windows 节点
     或者 VM 隔离。
@@ -583,7 +583,7 @@ for information on creating a new service account. For example, you might want t
 <!--
 - Decide if you want to build your own production Kubernetes or obtain one from
 available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/)
-or [Kubernetes Partners](https://kubernetes.io/partners/).
+or [Kubernetes Partners](/partners/).
 - If you choose to build your own cluster, plan how you want to
 handle [certificates](/docs/setup/best-practices/certificates/)
 and set up high availability for features such as
@@ -593,7 +593,7 @@ and the
 -->
 - 决定你是想自行构造自己的生产用 Kubernetes 还是从某可用的
   [云服务外包厂商](/zh-cn/docs/setup/production-environment/turnkey-solutions/)
-  或 [Kubernetes 合作伙伴](https://kubernetes.io/partners/)获得集群。
+  或 [Kubernetes 合作伙伴](/zh-cn/partners/)获得集群。
 - 如果你决定自行构造集群，则需要规划如何处理
   [证书](/zh-cn/docs/setup/best-practices/certificates/)
   并为类似

content/zh-cn/docs/tasks/access-application-cluster/access-cluster-services.md

@@ -25,7 +25,7 @@ their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a
 routable, so they will not be reachable from a machine outside the cluster,
 such as your desktop machine.
 -->
-## 访问集群上运行的服务
+## 访问集群上运行的服务  {#accessing-services-running-on-the-cluster}
 
 在 Kubernetes 里，[节点](/zh-cn/docs/concepts/architecture/nodes/)、
 [Pod](/zh-cn/docs/concepts/workloads/pods/) 和
@@ -186,22 +186,22 @@ URL 的 `<service_name>` 段支持的格式为：
 
 * To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:
 -->
-##### 示例
+##### 示例   {#examples}
 
-* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`，你可以使用：
+* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`，你可以使用以下地址：
 
-    ```
-    http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
-    ```
+  ```
+  http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
+  ```
 
 <!--
 * To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:
 -->
-* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`，你会使用：
+* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`，你可以使用以下地址：
 
-    ```
-    https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
-    ```
+  ```
+  https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
+  ```
 
     <!--
     The health information is similar to this:
@@ -226,18 +226,18 @@ URL 的 `<service_name>` 段支持的格式为：
 <!--
 * To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use:
 -->
-* 要访问 *https* Elasticsearch 服务健康信息 `_cluster/health?pretty=true`，你会使用：
+* 如要访问 **https** Elasticsearch 服务健康信息 `_cluster/health?pretty=true`，你可以使用以下地址：
 
-    ```
-    https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
-    ```
+  ```
+  https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
+  ```
 
 <!--
 #### Using web browsers to access services running on the cluster
 
 You may be able to put an apiserver proxy URL into the address bar of a browser. However:
 -->
-#### 通过 Web 浏览器访问集群中运行的服务
+#### 通过 Web 浏览器访问集群中运行的服务    {#uusing-web-browsers-to-access-services-running-on-the-cluster}
 
 你或许能够将 API 服务器代理的 URL 放入浏览器的地址栏，然而：
 

content/zh-cn/docs/tasks/administer-cluster/access-cluster-api.md

@@ -69,7 +69,8 @@ kubectl handles locating and authenticating to the API server. If you want to di
 -->
 ### 直接访问 REST API
 
-kubectl 处理对 API 服务器的定位和身份验证。如果你想通过 http 客户端（如 `curl` 或 `wget`，或浏览器）直接访问 REST API，你可以通过多种方式对 API 服务器进行定位和身份验证：
+kubectl 处理对 API 服务器的定位和身份验证。如果你想通过 http 客户端（如 `curl` 或 `wget`，
+或浏览器）直接访问 REST API，你可以通过多种方式对 API 服务器进行定位和身份验证：
 
  <!--
 1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
@@ -235,8 +236,8 @@ Kubernetes officially supports client libraries for [Go](#go-client), [Python](#
 Kubernetes 官方支持 [Go](#go-client)、[Python](#python-client)、[Java](#java-client)、
 [dotnet](#dotnet-client)、[JavaScript](#javascript-client) 和 [Haskell](#haskell-client)
 语言的客户端库。还有一些其他客户端库由对应作者而非 Kubernetes 团队提供并维护。
-参考[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)了解如何使用其他语言
-来访问 API 以及如何执行身份认证。
+参考[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)了解如何使用其他语言来访问 API
+以及如何执行身份认证。
 
 <!-- #### Go client -->
 
@@ -280,12 +281,12 @@ import (
 )
 
 func main() {
-  // uses the current context in kubeconfig
-  // path-to-kubeconfig -- for example, /root/.kube/config
+  // 在 kubeconfig 中使用当前上下文
+  // path-to-kubeconfig -- 例如 /root/.kube/config
   config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
-  // creates the clientset
+  // 创建 clientset
   clientset, _ := kubernetes.NewForConfig(config)
-  // access the API to list pods
+  // 访问 API 以列出 Pod
   pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{})
   fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
 }
@@ -305,7 +306,7 @@ To use [Python client](https://github.com/kubernetes-client/python), run the fol
 -->
 要使用 [Python 客户端](https://github.com/kubernetes-client/python)，运行下列命令：
 `pip install kubernetes`。
-参见 [Python 客户端库主页](https://github.com/kubernetes-client/python) 了解更多安装选项。
+参见 [Python 客户端库主页](https://github.com/kubernetes-client/python)了解更多安装选项。
 
 <!--
 The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
@@ -349,7 +350,7 @@ mvn install
 See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.
 
 The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-15/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
 -->
 参阅[https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)
 了解当前支持的版本。
@@ -357,7 +358,7 @@ as the kubectl CLI does to locate and authenticate to the API server. See this [
 Java 客户端可以使用 kubectl 命令行所使用的
 [kubeconfig 文件](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 以定位 API 服务器并向其认证身份。
-参看此[示例](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)：
+参看此[示例](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-15/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)：
 
 ```java
 package io.kubernetes.client.examples;
@@ -519,4 +520,4 @@ exampleWithKubeConfig = do
 <!--
 * [Accessing the Kubernetes API from a Pod](/docs/tasks/run-application/access-api-from-pod/)
 -->
-* [从 Pod 中访问 API](/zh-cn/docs/tasks/run-application/access-api-from-pod/)
+* [从 Pod 中访问 Kubernetes API](/zh-cn/docs/tasks/run-application/access-api-from-pod/)

content/zh-cn/docs/tasks/administer-cluster/kubelet-config-file.md

@@ -36,7 +36,8 @@ struct.
 -->
 ## 创建配置文件
 
-[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 结构体定义了可以通过文件配置的 Kubelet 配置子集，
+[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
+结构体定义了可以通过文件配置的 Kubelet 配置子集，
 
 <!--
 The configuration file must be a JSON or YAML representation of the parameters
@@ -48,35 +49,33 @@ Here is an example of what this file might look like:
 确保 kubelet 可以读取该文件。
 
 下面是一个 Kubelet 配置文件示例：
-```
+
+```yaml
 apiVersion: kubelet.config.k8s.io/v1beta1
 kind: KubeletConfiguration
-address: "192.168.0.8",
-port: 20250,
-serializeImagePulls: false,
+address: "192.168.0.8"
+port: 20250
+serializeImagePulls: false
 evictionHard:
     memory.available:  "200Mi"
 ```
 
-
 <!--
 In the example, the Kubelet is configured to serve on IP address 192.168.0.8 and port 20250, pull images in parallel,
 and evict Pods when available memory drops below 200Mi.
 All other Kubelet configuration values are left at their built-in defaults, unless overridden
 by flags. Command line flags which target the same value as a config file will override that value.
 -->
-在这个示例中, Kubelet 被设置为在地址 192.168.0.8 端口 20250 上提供服务，以并行方式拖拽镜像，
-当可用内存低于 200Mi 时, kubelet 将会开始驱逐 Pods。
-没有声明的其余配置项都将使用默认值，除非使用命令行参数来重载。 
+在这个示例中, Kubelet 被设置为在地址 192.168.0.8 端口 20250 上提供服务，以并行方式拉取镜像，
+当可用内存低于 200Mi 时, kubelet 将会开始驱逐 Pod。
+没有声明的其余配置项都将使用默认值，除非使用命令行参数来重载。
 命令行中的参数将会覆盖配置文件中的对应值。
 
 <!--
 ## Start a Kubelet process configured via the config file
 
-{{< note >}}
 If you use kubeadm to initialize your cluster, use the kubelet-config while creating your cluster with `kubeadmin init`.
 See [configuring kubelet using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/) for details.
-{{< /note >}}
 
 Start the Kubelet with the `--config` flag set to the path of the Kubelet's config file.
 The Kubelet will then load its config from this file.

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

@@ -18,7 +18,7 @@ a container. Containers cannot use more CPU than the configured limit.
 Provided the system has CPU time free, a container is guaranteed to be
 allocated as much CPU as it requests.
 -->
-本页面展示如何为容器设置 CPU *request（请求）* 和 CPU *limit（限制）*。
+本页面展示如何为容器设置 CPU **request（请求）** 和 CPU **limit（限制）**。
 容器使用的 CPU 不能超过所配置的限制。
 如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。
 
@@ -43,7 +43,7 @@ following command to enable metrics-server:
 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。
 
-如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
+如果你正在运行 {{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
 
 ```shell
 minikube addons enable metrics-server
@@ -53,7 +53,7 @@ minikube addons enable metrics-server
 To see whether metrics-server (or another provider of the resource metrics
 API, `metrics.k8s.io`) is running, type the following command:
 -->
-查看 metrics-server（或者其他资源度量 API `metrics.k8s.io` 服务提供者）是否正在运行，
+查看 metrics-server（或者其他资源指标 API `metrics.k8s.io` 服务提供者）是否正在运行，
 请键入以下命令：
 
 ```shell
@@ -79,7 +79,7 @@ v1beta1.metrics.k8s.io
 Create a {{< glossary_tooltip term_id="namespace" >}} so that the resources you
 create in this exercise are isolated from the rest of your cluster.
 -->
-## 创建一个名字空间
+## 创建一个名字空间 {#create-a-namespace}
 
 创建一个{{< glossary_tooltip text="名字空间" term_id="namespace" >}}，以便将
 本练习中创建的资源与集群的其余部分资源隔离。
@@ -104,7 +104,7 @@ The `-cpus "2"` argument tells the Container to attempt to use 2 CPUs.
 
 Create the Pod:
 -->
-## 指定 CPU 请求和 CPU 限制
+## 指定 CPU 请求和 CPU 限制 {#specify-a-CPU-request-and-a-CPU-limit}
 
 要为容器指定 CPU 请求，请在容器资源清单中包含 `resources: requests` 字段。
 要指定 CPU 限制，请包含 `resources:limits`。
@@ -145,7 +145,7 @@ kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
 The output shows that the one container in the Pod has a CPU request of 500 milliCPU
 and a CPU limit of 1 CPU.
 -->
-输出显示 Pod 中的一个容器的 CPU 请求为 500 milli CPU，并且 CPU 限制为 1 个 CPU。
+输出显示 Pod 中的一个容器的 CPU 请求为 500 milliCPU，并且 CPU 限制为 1 个 CPU。
 
 ```yaml
 resources:
@@ -158,7 +158,7 @@ resources:
 <!-- 
 Use `kubectl top` to fetch the metrics for the pod:
 -->
-使用 `kubectl top` 命令来获取该 Pod 的度量值数据：
+使用 `kubectl top` 命令来获取该 Pod 的指标：
 
 ```shell
 kubectl top pod cpu-demo --namespace=cpu-example
@@ -207,7 +207,7 @@ The CPU resource is measured in *CPU* units. One CPU, in Kubernetes, is equivale
 -->
 ## CPU 单位  {#cpu-units}
 
-CPU 资源以 *CPU* 单位度量。Kubernetes 中的一个 CPU 等同于：
+CPU 资源以 **CPU** 单位度量。Kubernetes 中的一个 CPU 等同于：
 
 * 1 个 AWS vCPU 
 * 1 个 GCP核心
@@ -256,7 +256,7 @@ capacity of any Node in your cluster.
 
 Create the Pod:
 -->
-## 设置超过节点能力的 CPU 请求
+## 设置超过节点能力的 CPU 请求 {#specify-a-CPU-request-that-is-too-big-for-your-nodes}
 
 CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。
 Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。
@@ -341,7 +341,7 @@ Container is automatically assigned the default limit. Cluster administrators ca
 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
 to specify a default value for the CPU limit.
 -->
-## 如果不指定 CPU 限制
+## 如果不指定 CPU 限制 {#if-you-do-not-specify-a-cpu-limit}
 
 如果你没有为容器指定 CPU 限制，则会发生以下情况之一：
 
@@ -360,7 +360,7 @@ assigns a CPU request that matches the limit. Similarly, if a Container specifie
 but does not specify a memory request, Kubernetes automatically assigns a memory request that matches
 the limit.
 -->
-## 如果你设置了 CPU 限制但未设置 CPU 请求
+## 如果你设置了 CPU 限制但未设置 CPU 请求 {#if-you-specify-a-CPU-limit-but-do-not-specify-a-CPU-request}
 
 如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其
 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置
@@ -377,13 +377,14 @@ scheduled. By having a CPU limit that is greater than the CPU request, you accom
 * The Pod can have bursts of activity where it makes use of CPU resources that happen to be available.
 * The amount of CPU resources a Pod can use during a burst is limited to some reasonable amount.
 -->
-## CPU 请求和限制的初衷
+## CPU 请求和限制的初衷 {#motivation-for-CPU-requests-and-limits}
 
 通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。
 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。
 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：
 
 * Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。
+
 * Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。	
 
 <!-- 
@@ -391,9 +392,9 @@ scheduled. By having a CPU limit that is greater than the CPU request, you accom
 
 Delete your namespace:
 -->
-## 清理
+## 清理 {#clean-up}
 
-删除名称空间：
+删除名字空间：
 
 ```shell
 kubectl delete namespace cpu-example
@@ -410,9 +411,10 @@ kubectl delete namespace cpu-example
 * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
 
 -->
-### 针对应用开发者
+### 针对应用开发者 {#for-app-developers}
 
 * [将内存资源分配给容器和 Pod](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)
+
 * [配置 Pod 服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)
 
 <!-- 
@@ -427,13 +429,12 @@ kubectl delete namespace cpu-example
 * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
 
 -->
-### 针对集群管理员
+### 针对集群管理员 {for-cluster-administrators}
 
-* [配置名称空间的默认内存请求和限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [配置名字空间的默认内存请求和限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
 * [为名字空间配置默认 CPU 请求和限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
 * [为名字空间配置最小和最大内存限制](/zh-cn/docs/tasks/administer-cluster//manage-resources/memory-constraint-namespace/)
 * [为名字空间配置最小和最大 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
 * [为名字空间配置内存和 CPU 配额](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
 * [为名字空间配置 Pod 配额](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
 * [配置 API 对象的配额](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)
-

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

@@ -570,7 +570,7 @@ for it, and that containers are restarted when they fail.
 HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同。
 
 就绪和存活探测可以在同一个容器上并行使用。
-两者都可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。
+两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。
 
 <!--
 ## Configure Probes

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

@@ -13,7 +13,7 @@ weight: 60
 <!-- overview -->
 
 <!--
-This page shows how to configure a Pod to use a
+This page shows you how to configure a Pod to use a
 {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
 for storage.
 Here is a summary of the process:
@@ -27,7 +27,7 @@ PersistentVolume.
 
 1. You create a Pod that uses the above PersistentVolumeClaim for storage.
 -->
-本文介绍如何配置 Pod 使用 
+本文将向你介绍如何配置 Pod 使用 
 {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
 作为存储。
 以下是该过程的总结：
@@ -42,7 +42,8 @@ PersistentVolume.
 ## {{% heading "prerequisites" %}}
 
 <!--
-* You need to have a Kubernetes cluster that has only one Node, and the kubectl
+* You need to have a Kubernetes cluster that has only one Node, and the
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
 command-line tool must be configured to communicate with your cluster. If you
 do not already have a single-node cluster, you can create one by using
 [Minikube](https://minikube.sigs.k8s.io/docs/).
@@ -51,7 +52,8 @@ do not already have a single-node cluster, you can create one by using
 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
 -->
 
-* 你需要一个包含单个节点的 Kubernetes 集群，并且必须配置 kubectl 命令行工具以便与集群交互。
+* 你需要一个包含单个节点的 Kubernetes 集群，并且必须配置
+  {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 命令行工具以便与集群交互。
   如果还没有单节点集群，可以使用
   [Minikube](https://minikube.sigs.k8s.io/docs/) 创建一个。
 .
@@ -62,19 +64,19 @@ do not already have a single-node cluster, you can create one by using
 <!--
 ## Create an index.html file on your Node
 
-Open a shell to the Node in your cluster. How you open a shell depends on how
-you set up your cluster. For example, if you are using Minikube, you can open a
-shell to your Node by entering `minikube ssh`.
+Open a shell to the single Node in your cluster. How you open a shell depends
+on how you set up your cluster. For example, if you are using Minikube, you
+can open a shell to your Node by entering `minikube ssh`.
 
-In your shell, create a `/mnt/data` directory:
+In your shell on that Node, create a `/mnt/data` directory:
 -->
 ## 在你的节点上创建一个 index.html 文件
 
-打开集群中节点的一个 Shell。
+打开集群中的某个节点的 Shell。
 如何打开 Shell 取决于集群的设置。
 例如，如果你正在使用 Minikube，那么可以通过输入 `minikube ssh` 来打开节点的 Shell。
 
-在 Shell 中，创建一个 `/mnt/data` 目录：
+在该节点的 Shell 中，创建一个 `/mnt/data` 目录：
 
 <!--
 # This assumes that your Node uses "sudo" to run commands
@@ -94,7 +96,7 @@ In the `/mnt/data` directory, create an `index.html` file:
 # This again assumes that your Node uses "sudo" to run commands
 # as the superuser
 -->
-```
+```shell
 # 这里再次假定你的节点使用 "sudo" 来以超级用户角色执行命令
 sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
 ```
@@ -139,7 +141,7 @@ PersistentVolume uses a file or directory on the Node to emulate network-attache
 -->
 ## 创建 PersistentVolume
 
-在本练习中，你将创建一个 *hostPath* 类型的 PersistentVolume。
+在本练习中，你将创建一个 **hostPath** 类型的 PersistentVolume。
 Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。
 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟网络附加存储。
 
@@ -149,18 +151,36 @@ would provision a network resource like a Google Compute Engine persistent disk,
 an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also
 use [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)
 to set up
-[dynamic provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes).
+[dynamic provisioning](/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes).
 
 Here is the configuration file for the hostPath PersistentVolume:
 -->
 在生产集群中，你不会使用 hostPath。
 集群管理员会提供网络存储资源，比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。
-集群管理员还可以使用 [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage) 来设置[动态提供存储](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)。
+集群管理员还可以使用
+[StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)
+来设置[动态提供存储](/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)。
 
 下面是 hostPath PersistentVolume 的配置文件：
 
 {{< codenew file="pods/storage/pv-volume.yaml" >}}
 
+<!--
+The configuration file specifies that the volume is at `/mnt/data` on the
+cluster's Node. The configuration also specifies a size of 10 gibibytes and
+an access mode of `ReadWriteOnce`, which means the volume can be mounted as
+read-write by a single Node. It defines the [StorageClass name](/docs/concepts/storage/persistent-volumes/#class)
+`manual` for the PersistentVolume, which will be used to bind
+PersistentVolumeClaim requests to this PersistentVolume.
+-->
+配置文件指定卷位于集群节点上的 `/mnt/data` 路径。
+配置还指定了卷的容量大小为 10 GB，
+访问模式为 `ReadWriteOnce`，
+这意味着该卷可以被单个节点以读写方式安装。
+配置文件还在 PersistentVolume 中定义了
+[StorageClass 的名称](/zh-cn/docs/concepts/storage/persistent-volumes/#class)
+为 `manual`。它将用于将 PersistentVolumeClaim 的请求绑定到此 PersistentVolume。
+
 <!--
 Create the PersistentVolume:
 -->
@@ -216,7 +236,7 @@ Create the PersistentVolumeClaim:
 创建 PersistentVolumeClaim：
 
 ```shell
-kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
 ```
 
 <!--
@@ -252,7 +272,7 @@ Look at the PersistentVolumeClaim:
 -->
 查看 PersistentVolumeClaim：
 
-```
+```shell
 kubectl get pvc task-pv-claim
 ```
 
@@ -299,7 +319,7 @@ kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
 ```
 
 <!--
-Verify that the Container in the Pod is running;
+Verify that the container in the Pod is running;
 -->
 检查 Pod 中的容器是否运行正常：
 
@@ -308,7 +328,7 @@ kubectl get pod task-pv-pod
 ```
 
 <!--
-Get a shell to the Container running in your Pod:
+Get a shell to the container running in your Pod:
 -->
 打开一个 Shell 访问 Pod 中的容器：
 
@@ -326,11 +346,11 @@ hostPath volume:
 # Be sure to run these 3 commands inside the root shell that comes from
 # running "kubectl exec" in the previous step
 -->
-```
+```shell
 # 一定要在上一步 "kubectl exec" 所返回的 Shell 中执行下面三个命令
-root@task-pv-pod:/# apt-get update
-root@task-pv-pod:/# apt-get install curl
-root@task-pv-pod:/# curl localhost
+apt update
+apt install curl
+curl http://localhost/
 ```
 
 <!--
@@ -374,7 +394,10 @@ In the shell on your Node, remove the file and directory that you created:
 如果你还没有连接到集群中节点的 Shell，可以按之前所做操作，打开一个新的 Shell。
 
 在节点的 Shell 上，删除你所创建的目录和文件：
-
+<!--
+# This assumes that your Node uses "sudo" to run commands
+# as the superuser
+-->
 
 ```shell
 # 这里假定你使用 "sudo" 来以超级用户的角色执行命令
@@ -390,7 +413,6 @@ You can now close the shell to your Node.
 <!--
 ## Mounting the same persistentVolume in two places
 -->
-
 ## 在两个地方挂载相同的 persistentVolume
 
 {{< codenew file="pods/storage/pv-duplicate.yaml" >}}
@@ -427,8 +449,8 @@ GID 不匹配或缺失将会导致无权访问错误。
 这样 GID 就能自动添加到使用 PersistentVolume 的任何 Pod 中。
 
 使用 `pv.beta.kubernetes.io/gid` 注解的方法如下所示：
-
 ```yaml
+apiVersion: v1
 kind: PersistentVolume
 apiVersion: v1
 metadata:
@@ -439,10 +461,10 @@ metadata:
 
 <!--
 When a Pod consumes a PersistentVolume that has a GID annotation, the annotated GID
-is applied to all Containers in the Pod in the same way that GIDs specified in the
+is applied to all containers in the Pod in the same way that GIDs specified in the
 Pod's security context are. Every GID, whether it originates from a PersistentVolume
 annotation or the Pod's specification, is applied to the first process run in
-each Container.
+each container.
 -->
 当 Pod 使用带有 GID 注解的 PersistentVolume 时，注解的 GID 会被应用于 Pod 中的所有容器，
 应用的方法与 Pod 的安全上下文中指定的 GID 相同。
@@ -476,5 +498,3 @@ PersistentVolume are not present on the Pod resource itself.
 * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
 * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
 * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
-
-

content/zh-cn/docs/tasks/inject-data-application/distribute-credentials-secure.md

@@ -12,8 +12,10 @@ encryption keys, into Pods.
 -->
 本文展示如何安全地将敏感数据（如密码和加密密钥）注入到 Pods 中。
 
+
 ## {{% heading "prerequisites" %}}
 
+
 {{< include "task-tutorial-prereqs.md" >}}
 
 
@@ -69,8 +71,10 @@ username and password:
    kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
    ```
 
-1. <!-- View information about the Secret -->
-   查看 Secret 相关信息：
+<!--
+1. View information about the Secret:
+-->
+2. 查看 Secret 相关信息：
 
    ```shell
    kubectl get secret test-secret
@@ -79,12 +83,12 @@ username and password:
    <!-- Output: -->
     输出：
 	
-   ```shell
+   ```
    NAME          TYPE      DATA      AGE
    test-secret   Opaque    2         1m
    ```
 
-1. <!-- View more detailed information about the Secret -->
+1. <!-- View more detailed information about the Secret:-->
    查看 Secret 相关的更多详细信息：
 
    ```shell
@@ -94,7 +98,7 @@ username and password:
    <!-- Output: -->
    输出：
 
-   ```shell
+   ```
    Name:       test-secret
    Namespace:  default
    Labels:     <none>
@@ -105,7 +109,7 @@ username and password:
    Data
    ====
    password:   13 bytes
-   username:   7  bytes
+   username:   7 bytes
    ```
 
 <!--
@@ -130,6 +134,7 @@ through each step explicitly to demonstrate what is happening.
 这是一种更为方便的方法。
 前面展示的详细分解步骤有助于了解究竟发生了什么事情。
 
+
 <!--
 ## Create a Pod that has access to the secret data through a Volume
 
@@ -145,7 +150,7 @@ Here is a configuration file you can use to create a Pod:
    创建 Pod：
 
    ```shell
-   kubectl create -f secret-pod.yaml
+   kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
    ```
 
 1. <!-- Verify that your Pod is running: -->
@@ -155,9 +160,9 @@ Here is a configuration file you can use to create a Pod:
    kubectl get pod secret-test-pod
    ```
 
+   <!-- Output: -->
    输出：
-
-   ```shell
+   ```
    NAME              READY     STATUS    RESTARTS   AGE
    secret-test-pod   1/1       Running   0          42m
    ```
@@ -166,7 +171,7 @@ Here is a configuration file you can use to create a Pod:
    获取一个 shell 进入 Pod 中运行的容器：
 
    ```shell
-   kubectl exec -it secret-test-pod -- /bin/bash
+   kubectl exec -i -t secret-test-pod -- /bin/bash
    ```
 
 1. <!-- The secret data is exposed to the Container through a Volume mounted under
@@ -179,6 +184,7 @@ Here is a configuration file you can use to create a Pod:
    在 shell 中，列举 `/etc/secret-volume` 目录下的文件：
 
    ```shell
+   # 在容器中 Shell 运行下面命令
    ls /etc/secret-volume
    ```
 
@@ -195,11 +201,10 @@ Here is a configuration file you can use to create a Pod:
    In your shell, display the contents of the `username` and `password` files:
    -->
    在 Shell 中，显示 `username` 和 `password` 文件的内容：
-
    ```shell
    # 在容器中 Shell 运行下面命令
-   echo "$(cat /etc/secret-volume/username)"
-   echo "$(cat /etc/secret-volume/password)"
+   echo "$( cat /etc/secret-volume/username )"
+   echo "$( cat /etc/secret-volume/password )"
    ```
 
    <!--
@@ -207,7 +212,7 @@ Here is a configuration file you can use to create a Pod:
    -->
    输出为用户名和密码：
 
-   ```shell
+   ```
    my-app
    39528$vdg7Jb
    ```
@@ -256,11 +261,14 @@ Here is a configuration file you can use to create a Pod:
    kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
    ```
 
+   <!--
+   The output is
+   -->
    输出为：
-
    ```
    backend-admin
    ```
+   
 <!--
 ### Define container environment variables with data from multiple Secrets
 -->
@@ -300,13 +308,16 @@ Here is a configuration file you can use to create a Pod:
    ```shell
    kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
    ```
-
+   <!--
+   The output is
+   -->
    输出：
    ```
    DB_USERNAME=db-admin
    BACKEND_USERNAME=backend-admin
    ```
 
+
 <!--
 ## Configure all key-value pairs in a Secret as container environment variables
 -->
@@ -353,7 +364,10 @@ This functionality is available in Kubernetes v1.6 and later.
   ```shell
   kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
   ```
-
+  
+   <!--
+   The output is
+   -->
   输出为：
 
   ```
@@ -364,10 +378,9 @@ This functionality is available in Kubernetes v1.6 and later.
 <!-- ### References -->
 ### 参考
 
-* [Secret](/docs/api-reference/{{< param "version" >}}/#secret-v1-core)
-* [Volume](/docs/api-reference/{{< param "version" >}}/#volume-v1-core)
-* [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core)
-
+* [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 
 ## {{% heading "whatsnext" %}}
 

content/zh-cn/docs/tasks/tools/install-kubectl-linux.md

@@ -171,49 +171,65 @@ Or use this for detailed view of version:
 ### 用原生包管理工具安装 {#install-using-native-package-management}
 
 {{< tabs name="kubectl_install" >}}
-{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
+{{% tab name="基于 Debian 的发行版" %}}
 
-  <!--
-  1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
-  -->
-  1. 更新 `apt` 包索引，并安装使用 Kubernetes `apt` 仓库所需要的包：
+<!--
+1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
+-->
+1. 更新 `apt` 包索引，并安装使用 Kubernetes `apt` 仓库所需要的包：
 
-     ```shell
-     sudo apt-get update
-     sudo apt-get install -y apt-transport-https ca-certificates curl
-     ```
-  <!--
-  2. Download the Google Cloud public signing key:
-  -->
-  2. 下载 Google Cloud 公开签名秘钥：
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y ca-certificates curl
+   ```
+   <!--
+   If you use Debian 9 (stretch) or earlier you would also need to install `apt-transport-https`:
+   -->
+   {{< note >}}
 
-     ```shell
-     sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
-     ```
+   如果你使用 Debian 9（stretch）或更早版本，则你还需要安装 `apt-transport-https`：
 
-  <!--
-  3. Add the Kubernetes `apt` repository:
-  -->
-  3. 添加 Kubernetes `apt` 仓库：
+   ```shell
+    sudo apt-get install -y apt-transport-https
+   ```
 
-     ```shell
-     echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
-     ```
+   {{< /note >}}
+   
+<!--
+2. Download the Google Cloud public signing key:
+-->
 
-  <!--
-  4. Update `apt` package index with the new repository and install kubectl:
-  -->
-  4. 更新 `apt` 包索引，使之包含新的仓库并安装 kubectl：
+2. 下载 Google Cloud 公开签名秘钥：
+
+   ```shell
+   sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
+   ```
+
+<!--
+3. Add the Kubernetes `apt` repository:
+-->
+
+3. 添加 Kubernetes `apt` 仓库：
+
+   ```shell
+   echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
+   ```
+
+<!--
+4. Update `apt` package index with the new repository and install kubectl:
+-->
+
+4. 更新 `apt` 包索引，使之包含新的仓库并安装 kubectl：
+
+   ```shell
+   sudo apt-get update
+   sudo apt-get install -y kubectl
+   ```
 
-     ```shell
-     sudo apt-get update
-     sudo apt-get install -y kubectl
-     ```
 {{% /tab %}}
 
-{{% tab name="基于 Red Hat 的发行版" %}}
+{{< tab name="基于 Red Hat 的发行版" codelang="bash" >}}
 
-```shell
 cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
 name=Kubernetes
@@ -223,9 +239,7 @@ gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
 EOF
 sudo yum install -y kubectl
-```
-
-{{% /tab %}}
+{{< /tab >}}
 {{< /tabs >}}
 
 <!-- 
@@ -352,6 +366,7 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以
    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    ```
+
    {{< note >}}
    <!--
    Download the same version of the binary and checksum.

content/zh-cn/examples/service/networking/dual-stack-default-svc.yaml

@@ -3,10 +3,10 @@ kind: Service
 metadata:
   name: my-service
   labels:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
 spec:
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   ports:
     - protocol: TCP
       port: 80

content/zh-cn/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml

@@ -3,12 +3,12 @@ kind: Service
 metadata:
   name: my-service
   labels:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
 spec:
   ipFamilies:
   - IPv6
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   ports:
     - protocol: TCP
       port: 80

content/zh-cn/examples/service/networking/dual-stack-ipv6-svc.yaml

@@ -5,7 +5,7 @@ metadata:
 spec:
   ipFamily: IPv6
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   ports:
     - protocol: TCP
       port: 80

content/zh-cn/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml

@@ -3,14 +3,14 @@ kind: Service
 metadata:
   name: my-service
   labels:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
 spec:
   ipFamilyPolicy: PreferDualStack
   ipFamilies:
   - IPv6
   type: LoadBalancer
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   ports:
     - protocol: TCP
       port: 80

content/zh-cn/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml

@@ -3,14 +3,14 @@ kind: Service
 metadata:
   name: my-service
   labels:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
 spec:
   ipFamilyPolicy: PreferDualStack
   ipFamilies:
   - IPv6
   - IPv4
   selector:
-    app: MyApp
+    app.kubernetes.io/name: MyApp
   ports:
     - protocol: TCP
       port: 80