Merge branch 'main' into main

2021-08-17 14:19:44 +02:00
parent d7f3eeb214 a5c98695b7
commit 457fd23848
103 changed files with 705 additions and 1056 deletions
@@ -8,7 +8,9 @@ approvers:
 emeritus_approvers:
 # - chenopis, commented out to disable PR assignments
 # - irvifa, commented out to disable PR assignments
 # - jaredbhatti, commented out to disable PR assignments
 # - kbarnard10, commented out to disable PR assignments
 # - steveperry-53, commented out to disable PR assignments
 - stewart-yu 
 # - zacharysarah, commented out to disable PR assignments
@@ -1,10 +1,8 @@
 aliases:
  sig-docs-blog-owners: # Approvers for blog content
    - kbarnard10
    - onlydole
    - mrbobbytables
  sig-docs-blog-reviewers: # Reviewers for blog content
    - kbarnard10
    - mrbobbytables
    - onlydole
    - sftim
@@ -20,9 +18,7 @@ aliases:
    - annajung
    - bradtopol
    - celestehorgan
    - irvifa
    - jimangel
    - kbarnard10
    - kbhawkey
    - onlydole
    - pi-victor
@@ -35,7 +31,6 @@ aliases:
    - celestehorgan
    - daminisatya
    - jimangel
    - kbarnard10
    - kbhawkey
    - onlydole
    - rajeshdeshpande02
@@ -88,7 +83,6 @@ aliases:
    - danninov
    - girikuncoro
    - habibrosyad
    - irvifa
    - phanama
    - wahyuoi
  sig-docs-id-reviews: # PR reviews for Indonesian content
@@ -96,7 +90,6 @@ aliases:
    - danninov
    - girikuncoro
    - habibrosyad
    - irvifa
    - phanama
    - wahyuoi
  sig-docs-it-owners: # Admins for Italian content
@@ -138,9 +131,7 @@ aliases:
    - yoonian
    - ysyukr
  sig-docs-leads: # Website chairs and tech leads
    - irvifa
    - jimangel
    - kbarnard10
    - kbhawkey
    - onlydole
    - sftim
@@ -18,7 +18,7 @@ Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować:
 - [npm](https://www.npmjs.com/)
 - [Go](https://golang.org/)
 - [Hugo (Extended version)](https://gohugo.io/)
- Środowisko obsługi kontenerów, np. [Docker-a](https://www.docker.com/).
+- Środowisko obsługi kontenerów, np. [Dockera](https://www.docker.com/).
 Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu:
@@ -43,7 +43,9 @@ make container-image
 make container-serve
 ```
-Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
+Jeśli widzisz błędy, prawdopodobnie kontener z Hugo nie dysponuje wystarczającymi zasobami. Aby rozwiązać ten problem, zwiększ ilość dostępnych zasobów CPU i pamięci dla Dockera na Twojej maszynie ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) i [Windows](https://docs.docker.com/docker-for-windows/#resources)).
 Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
 ## Jak uruchomić lokalną kopię strony przy pomocy Hugo?
@@ -10,7 +10,5 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 irvifa
 jimangel
 kbarnard10
 sftim
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="de">
 <body>
@@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can
-Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).&nbsp;
+Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).&nbsp;
@@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance
 [ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below.  
 **Creating a ZooKeeper Ensemble**  
-Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest.  
+Creating an ensemble is as simple as using [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) to generate the objects stored in the manifest.  
 ```
@@ -297,7 +297,7 @@ zk-0      0/1       Terminating   0         15m
-You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble.
+You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble.
@@ -122,6 +122,9 @@ To mark a Node unschedulable, run:
 kubectl cordon $NODENAME
 ```
 See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
 for more details.
 {{< note >}}
 Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate
 being run on an unschedulable Node. DaemonSets typically provide node-local services
@@ -162,8 +165,8 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
 | Node Condition       | Description |
 |----------------------|-------------|
 | `Ready`              | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
-| `DiskPressure`       | `True` if pressure exists on the disk size--that is, if the disk capacity is low; otherwise `False` |
+| `DiskPressure`       | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` |
-| `MemoryPressure`     | `True` if pressure exists on the node memory--that is, if the node memory is low; otherwise `False` |
+| `MemoryPressure`     | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` |
 | `PIDPressure`        | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` |
 | `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
 {{< /table >}}
@@ -174,7 +177,8 @@ If you use command-line tools to print details of a cordoned Node, the Condition
 cordoned nodes are marked Unschedulable in their spec.
 {{< /note >}}
-The node condition is represented as a JSON object. For example, the following structure describes a healthy node:
+In the Kubernetes API, a node's condition is represented as part of the `.status`
 of the Node resource. For example, the following JSON structure describes a healthy node:
 ```json
 "conditions": [
@@ -189,7 +193,17 @@ The node condition is represented as a JSON object. For example, the following s
 ]
 ```
-If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
+If the `status` of the Ready condition remains `Unknown` or `False` for longer
 than the `pod-eviction-timeout` (an argument passed to the
 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager"
 >}}), then the [node controller](#node-controller) triggers
 {{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
 for all Pods assigned to that node. The default eviction timeout duration is
 **five minutes**.
 In some cases when the node is unreachable, the API server is unable to communicate
 with the kubelet on the node. The decision to delete the pods cannot be communicated to
 the kubelet until communication with the API server is re-established. In the meantime,
 the pods that are scheduled for deletion may continue to run on the partitioned node.
 The node controller does not force delete pods until it is confirmed that they have stopped
 running in the cluster. You can see the pods that might be running on an unreachable node as
@@ -199,10 +213,12 @@ may need to delete the node object by hand. Deleting the node object from Kubern
 all the Pod objects running on the node to be deleted from the API server and frees up their
 names.
-The node lifecycle controller automatically creates
+When problems occur on nodes, the Kubernetes control plane automatically creates
-[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions.
+[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions
 affecting the node.
 The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
-Pods can also have tolerations which let them tolerate a Node's taints.
+Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let
 them run on a Node even though it has a specific taint.
 See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)
 for more details.
@@ -222,10 +238,43 @@ on a Node.
 ### Info
-Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
+Describes general information about the node, such as kernel version, Kubernetes
-This information is gathered by Kubelet from the node.
+version (kubelet and kube-proxy version), container runtime details, and which
 operating system the node uses.
 The kubelet gathers this information from the node and publishes it into
 the Kubernetes API.
-### Node controller
+## Heartbeats
 Heartbeats, sent by Kubernetes nodes, help your cluster determine the
 availability of each node, and to take action when failures are detected.
 For nodes there are two forms of heartbeats:
 * updates to the `.status` of a Node
 * [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) objects
  within the `kube-node-lease`
  {{< glossary_tooltip term_id="namespace" text="namespace">}}.
  Each Node has an associated Lease object.
 Compared to updates to `.status` of a Node, a Lease is a lightweight resource.
 Using Leases for heartbeats reduces the performance impact of these updates
 for large clusters.
 The kubelet is responsible for creating and updating the `.status` of Nodes,
 and for updating their related Leases.
 - The kubelet updates the node's `.status` either when there is change in status
  or if there has been no update for a configured interval. The default interval
  for `.status` updates to Nodes is 5 minutes, which is much longer than the 40
  second default timeout for unreachable nodes.
 - The kubelet creates and then updates its Lease object every 10 seconds
  (the default update interval). Lease updates occur independently from
  updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
  using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
 ## Node controller
 The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
 Kubernetes control plane component that manages various aspects of nodes.
@@ -241,39 +290,18 @@ controller deletes the node from its list of nodes.
 The third is monitoring the nodes' health. The node controller is
 responsible for:
- Updating the NodeReady condition of NodeStatus to ConditionUnknown when a node
+- In the case that a node becomes unreachable, updating the NodeReady condition
-  becomes unreachable, as the node controller stops receiving heartbeats for some
+  of within the Node's `.status`. In this case the node controller sets the
-  reason such as the node being down.
+  NodeReady condition to `ConditionUnknown`.
- Evicting all the pods from the node using graceful termination if
+- If a node remains unreachable: triggering
-  the node continues to be unreachable. The default timeouts are 40s to start
+  [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/)
-  reporting ConditionUnknown and 5m after that to start evicting pods.
+  for all of the Pods on the unreachable node. By default, the node controller
  waits 5 minutes between marking the node as `ConditionUnknown` and submitting
  the first eviction request.
 The node controller checks the state of each node every `--node-monitor-period` seconds.
-#### Heartbeats
+### Rate limits on eviction
 Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
 There are two forms of heartbeats: updates of `NodeStatus` and the
 [Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io).
 Each Node has an associated Lease object in the `kube-node-lease`
 {{< glossary_tooltip term_id="namespace" text="namespace">}}.
 Lease is a lightweight resource, which improves the performance
 of the node heartbeats as the cluster scales.
 The kubelet is responsible for creating and updating the `NodeStatus` and
 a Lease object.
 - The kubelet updates the `NodeStatus` either when there is change in status
  or if there has been no update for a configured interval. The default interval
  for `NodeStatus` updates is 5 minutes, which is much longer than the 40 second default
  timeout for unreachable nodes.
 - The kubelet creates and then updates its Lease object every 10 seconds
  (the default update interval). Lease updates occur independently from the
  `NodeStatus` updates. If the Lease update fails, the kubelet retries with
  exponential backoff starting at 200 milliseconds and capped at 7 seconds.
 #### Reliability
 In most cases, the node controller limits the eviction rate to
 `--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
@@ -281,7 +309,7 @@ from more than 1 node per 10 seconds.
 The node eviction behavior changes when a node in a given availability zone
 becomes unhealthy. The node controller checks what percentage of nodes in the zone
-are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at
+are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
 the same time:
 - If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
  (default 0.55), then the eviction rate is reduced.
@@ -293,15 +321,17 @@ the same time:
 The reason these policies are implemented per availability zone is because one
 availability zone might become partitioned from the master while the others remain
 connected. If your cluster does not span multiple cloud provider availability zones,
-then there is only one availability zone (i.e. the whole cluster).
+then the eviction mechanism does not take per-zone unavailability into account.
 A key reason for spreading your nodes across availability zones is so that the
 workload can be shifted to healthy zones when one entire zone goes down.
 Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at
 the normal rate of `--node-eviction-rate`.  The corner case is when all zones are
-completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
+completely unhealthy (none of the nodes in the cluster are healthy). In such a
-case, the node controller assumes that there is some problem with master
+case, the node controller assumes that there is some problem with connectivity
-connectivity and stops all evictions until some connectivity is restored.
+between the control plane and the nodes, and doesn't perform any evictions.
 (If there has been an outage and some nodes reappear, the node controller does
 evict pods from the remaining nodes that are unhealthy or unreachable).
 The node controller is also responsible for evicting pods running on nodes with
 `NoExecute` taints, unless those pods tolerate that taint.
@@ -309,7 +339,7 @@ The node controller also adds {{< glossary_tooltip text="taints" term_id="taint"
 corresponding to node problems like node unreachable or not ready. This means
 that the scheduler won't place Pods onto unhealthy nodes.
-### Node capacity
+## Resource capacity tracking {#node-capacity}
 Node objects track information about the Node's resource capacity: for example, the amount
 of memory available and the number of CPUs.
@@ -81,7 +81,7 @@ rotate an application's logs automatically.
 As an example, you can find detailed information about how `kube-up.sh` sets
 up logging for COS image on GCP in the corresponding
-[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).
+[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh).
 When using a **CRI container runtime**, the kubelet is responsible for rotating the logs and managing the logging directory structure.
 The kubelet sends this information to the CRI container runtime and the runtime writes the container logs to the given location.
@@ -160,7 +160,7 @@ If you're interested in learning more about `kubectl`, go ahead and read [kubect
 The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.
-For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
+For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
 ```yaml
     labels:
@@ -21,7 +21,7 @@ This is a living document. If you think of something that is not on this list bu
 - Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
+- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
 - Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
@@ -63,7 +63,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
 ## Using Labels
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
+- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
 A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/).
@@ -52,7 +52,7 @@ FOO_SERVICE_PORT=<the port the service is running on>
 ```
 Services have dedicated IP addresses and are available to the Container via DNS,
-if [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled. 
+if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/) is enabled. 
@@ -133,7 +133,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
 Kubernetes supports 2 primary modes of finding a Service - environment variables
 and DNS. The former works out of the box while the latter requires the
-[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
+[CoreDNS cluster addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns).
 {{< note >}}
 If the service environment variables are not desired (because possible clashing with expected program ones,
 too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
@@ -231,7 +231,7 @@ Till now we have only accessed the nginx server from within the cluster. Before
 * An nginx server configured to use the certificates
 * A [secret](/docs/concepts/configuration/secret/) that makes the certificates accessible to pods
-You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short:
+You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short:
 ```shell
 make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -303,7 +303,7 @@ Now modify your nginx replicas to start an https server using the certificate in
 Noteworthy points about the nginx-secure-app manifest:
 - It contains both Deployment and Service specification in the same file.
- The [nginx server](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
+- The [nginx server](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
  serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service
  exposes both ports.
 - Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`.
@@ -252,7 +252,7 @@ spec:
      endPort: 32768
 ```
-The above rule allows any Pod with label `db` on the namespace `default` to communicate 
+The above rule allows any Pod with label `role=db` on the namespace `default` to communicate 
 with any IP within the range `10.0.0.0/24` over TCP, provided that the target 
 port is between the range 32000 and 32768.
@@ -428,8 +428,7 @@ variables and DNS.
 When a Pod is run on a Node, the kubelet adds a set of environment variables
 for each active Service.  It supports both [Docker links
-compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
+compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72))
 [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72))
 and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
 where the Service name is upper-cased and dashes are converted to underscores.
@@ -130,7 +130,7 @@ and the kubelet, set the `InTreePluginAWSUnregister` flag to `true`.
 The `azureDisk` volume type mounts a Microsoft Azure [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) into a pod.
-For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md).
+For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md).
 #### azureDisk CSI migration
@@ -148,7 +148,7 @@ features must be enabled.
 The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0)
 into a pod.
-For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md).
+For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md).
 #### azureFile CSI migration
@@ -176,7 +176,7 @@ writers simultaneously.
 You must have your own Ceph server running with the share exported before you can use it.
 {{< /note >}}
-See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details.
+See the [CephFS example](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) for more details.
 ### cinder
@@ -347,7 +347,7 @@ You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to th
 beforehand so that Kubernetes hosts can access them.
 {{< /note >}}
-See the [fibre channel example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
+See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details.
 ### flocker (deprecated) {#flocker}
@@ -365,7 +365,7 @@ can be shared between pods as required.
 You must have your own Flocker installation running before you can use it.
 {{< /note >}}
-See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details.
+See the [Flocker example](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) for more details.
 ### gcePersistentDisk
@@ -533,7 +533,7 @@ simultaneously.
 You must have your own GlusterFS installation running before you can use it.
 {{< /note >}}
-See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details.
+See the [GlusterFS example](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) for more details.
 ### hostPath {#hostpath}
@@ -661,7 +661,7 @@ and then serve it in parallel from as many Pods as you need. Unfortunately,
 iSCSI volumes can only be mounted by a single consumer in read-write mode.
 Simultaneous writers are not allowed.
-See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details.
+See the [iSCSI example](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) for more details.
 ### local
@@ -749,7 +749,7 @@ writers simultaneously.
 You must have your own NFS server running with the share exported before you can use it.
 {{< /note >}}
-See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details.
+See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) for more details.
 ### persistentVolumeClaim {#persistentvolumeclaim}
@@ -797,7 +797,7 @@ Make sure you have an existing PortworxVolume with name `pxvol`
 before using it in the Pod.
 {{< /note >}}
-For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) examples.
+For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) examples.
 ### projected
@@ -811,7 +811,7 @@ Currently, the following types of volume sources can be projected:
 * `serviceAccountToken`
 All sources are required to be in the same namespace as the Pod. For more details,
-see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md).
+see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
 #### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
@@ -972,7 +972,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately,
 RBD volumes can only be mounted by a single consumer in read-write mode.
 Simultaneous writers are not allowed.
-See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)
+See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd)
 for more details.
 ### secret
@@ -632,7 +632,7 @@ of custom controller for those Pods.  This allows the most flexibility, but may
 complicated to get started with and offers less integration with Kubernetes.
 One example of this pattern would be a Job which starts a Pod which runs a script that in turn
-starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark
+starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), runs a spark
 driver, and then cleans up.
 An advantage of this approach is that the overall process gets the completion guarantee of a Job
@@ -39,7 +39,7 @@ that provides a set of stateless replicas.
 ## Limitations
-* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
+* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
 * Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
 * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
 * StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion.
@@ -127,7 +127,7 @@ up the verbosity:
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
    ```
-[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+[Complete file example](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
 ## A quick note on service accounts
@@ -70,7 +70,7 @@ controller on the controller manager.
 Each valid token is backed by a secret in the `kube-system` namespace.  You can
 find the full design doc
-[here](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
+[here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
 Here is what the secret looks like.
@@ -165,8 +165,8 @@ different Kubernetes components.
 | `PreferNominatedNode` | `true` | Beta | 1.22 | |
 | `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 |
 | `ProbeTerminationGracePeriod` | `false` | Beta | 1.22 | |
 | `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `ReadWriteOncePod` | `false` | Alpha | 1.22 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 |
@@ -789,10 +789,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
  and volume controllers.
 - `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
  controller to manage Pod completions per completion index.
 - `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job)
  completions without relying on Pods remaining in the cluster indefinitely.
  The Job controller uses Pod finalizers and a field in the Job status to keep
  track of the finished Pods to count towards completion.
 - `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
  `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
  to `IngressClass.spec.parameters`.
@@ -800,10 +796,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
  Initializers admission plugin.
 - `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/)
  support for IPv6.
- `JobTrackingWithFinalizers`: Enables the tracking of Job completion without
+- `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job)
-  relying on Pods remaining in the cluster indefinitely. Pod finalizers, in
+  completions without relying on Pods remaining in the cluster indefinitely.
-  addition to a field in the Job status, allow the Job controller to track
+  The Job controller uses Pod finalizers and a field in the Job status to keep
-  Pods that it didn't account for yet.
+  track of the finished Pods to count towards completion.
 - `KubeletConfigFile`: Enable loading kubelet configuration from
  a file specified using a config file.
  See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
@@ -1012,18 +1008,16 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `WatchBookmark`: Enable support for watch bookmark events.
 - `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
 - `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
 - `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows
  will use EndpointSlices as the primary data source instead of Endpoints,
  enabling scalability and performance improvements. See
  [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
 - `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes.
 - `WindowsHostProcessContainers`: Enables support for Windows HostProcess containers.
 - `WindowsRunAsUserName` : Enable support for running applications in Windows containers
  with as a non-default user. See
  [Configuring RunAsUserName](/docs/tasks/configure-pod-container/configure-runasusername)
  for more details.
 - `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows
  will use EndpointSlices as the primary data source instead of Endpoints,
  enabling scalability and performance improvements. See
  [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
 - `WindowsHostProcessContainers`: Enables the support for `HostProcess`
  containers on Windows nodes.
 ## {{% heading "whatsnext" %}}
@@ -55,7 +55,7 @@ You can access Dashboard using the kubectl command-line tool by running the foll
 kubectl proxy
 ```
-Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/).
+Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:https/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:https/proxy/).
 The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
@@ -30,7 +30,7 @@ Check the location and credentials that kubectl knows about with this command:
 kubectl config view
 ```
-Many of the [examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) provide an introduction to using
+Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using
 kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
 ### Directly accessing the REST API
@@ -66,7 +66,8 @@ The flag takes a comma-separated list of `key=value` policy options.
 The `none` policy explicitly enables the existing default CPU
 affinity scheme, providing no affinity beyond what the OS scheduler does
 automatically.  Limits on CPU usage for
-[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/)
+[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) and
 [Burstable pods](/docs/tasks/configure-pod-container/quality-service-pod/)
 are enforced using CFS quota.
 ### Static policy
@@ -28,7 +28,7 @@ explains how to use `kubeadm` to migrate from `kube-dns`.
 DNS is a built-in Kubernetes service launched automatically
 using the _addon manager_
-[cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md).
+[cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md).
 As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster
 originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS.
@@ -314,7 +314,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
 * Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
 * Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
-* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md).
+* See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md).
@@ -145,7 +145,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
 other code indicates failure.
 You can see the source code for the server in
-[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
+[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
 For the first 10 seconds that the container is alive, the `/healthz` handler
 returns a status of 200. After that, the handler returns a status of 500.
@@ -83,5 +83,5 @@ kubectl delete secret user pass
 ## {{% heading "whatsnext" %}}
 * Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
-* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
+* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
@@ -94,7 +94,7 @@ rules:
 ```
 If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
-[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
 script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script.
 You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
@@ -18,7 +18,7 @@ learn how to run multiple schedulers in Kubernetes with an example.
 A detailed description of how to implement a scheduler is outside the scope of this
 document. Please refer to the kube-scheduler implementation in
-[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
+[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)
 in the Kubernetes source directory for a canonical example.
 ## {{% heading "prerequisites" %}}
@@ -202,7 +202,7 @@ spec:
    plural: crontabs
    # singular name to be used as an alias on the CLI and for display
    singular: crontab
-    # kind is normally the CamelCased singular type. Your resource manifests use this.
+    # kind is normally the PascalCased singular type. Your resource manifests use this.
    kind: CronTab
    # shortNames allow shorter string to match your resource on the CLI
    shortNames:
@@ -26,7 +26,7 @@ following Kubernetes concepts:
 * [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 * [Headless Services](/docs/concepts/services-networking/service/#headless-services)
 * [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
-* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
 * [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
 * The [kubectl](/docs/reference/kubectl/kubectl/) command line tool
@@ -27,7 +27,7 @@ Kubernetes concepts:
 - [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 - [Headless Services](/docs/concepts/services-networking/service/#headless-services)
 - [PersistentVolumes](/docs/concepts/storage/volumes/)
- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
 - [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
 - [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
 - [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="es">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="es">
 <body>
@@ -1,4 +1,51 @@
 ---
 title: Workloads
 weight: 50
 description: >
  Comprendre les Pods, le plus petit objet déployable sur Kubernetes, et les abstractions de haut niveaux vous permettant de les lancer.
 no_list: true
 ---
 <!-- definition -->
 Un workload (charge de travail) est une application fonctionnant sur Kubernetes. Que votre workload soit un composant unique ou un agrégat de composants, sur Kubernetes celui-ci fonctionnera dans une série de pods. Dans Kubernetes, un Pod represente un ensemble de conteneur (containers) en fonctionnement sur votre cluster.
 Les pods Kubernetes ont un cycle de vie définit (defined lifecycle). Par exemple, quand un pod est en fonction sur votre cluster et qu’une panne critique survient sur le noeud (node) où se situe ce pod, tous les pods du noeud seront en échec. Kubernetes traite ce niveau d’échec comme un état final :
 Vous devez créer un nouveau Pod pour retrouver l’état initial même si le noeud redevient sain.
 Cependant, pour vous simplifier la vie, vous n’avez pas a gérer chaque Pod directement. Vous pouvez utiliser une ressource workload qui gère votre groupe de pods à votre place. Ces ressources configurent des controleurs (controllers) qui s’assurent que le bon nombre et le bon type de pod soit en fonction pour égaler l’état que vous avez spécifié.
 Kubernetes fournit plusieurs ressources workload pré-faites :
 * [`Deployment`](/docs/concepts/workloads/controllers/deployment/) et [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 
 (qui remplacent l’ancienne ressource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}})).
 Le `Deployment` (déploiement) est une bonne approche pour manager une application stateless sur votre cluster, tous les `Pods` d’un `Deployment` sont interchangeables et peuvent être remplacés si besoin.
 * Le [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/)  vous permet de lancer un ou plusieurs Pods en relation qui garde plus ou moins la trace de leurs état.
 Par exemple si votre workload enregistre des données de façon persistente, vous pouvez lancer un `StatefulSet` qui fera le lien entre les `Pods` et un volume persistent ([`PersistentVolume`](/docs/concepts/storage/persistent-volumes/)).
 Votre code, présent dans les `Pods` du `StatefulSet`, peut répliquer des données dans les autres `Pods` qui sont dans le même `StatefulSet`,
 pour améliorer la résilience global.
 * Le [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) permet de définir les `Pods` qui effectuent des actions sur le noeud local.
 Ceux-ci peuvent être fondamental aux opérations de votre cluster, comme un outil d’aide réseau, ou peuvent faire part d’un module complémentaire (add-on).
 Pour chaque nouveau noeud ajouté au cluster, le controle plane organise l'ajout d'un `Pod` pour ce `DaemonSet` sur le nouveau noeud.
 * Les [`Job`](/docs/concepts/workloads/controllers/job/) et  [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) sont des taches lancées jusqu’à accomplissement puis s’arrêtent. Les `Jobs` réprésentent une tâche ponctuelle, les `CronJob` sont des tâches récurrentes planifiés.
 Dans l’écosystème étendu de Kubernetes, vous pouvez trouver des ressources workload de fournisseurs tiers qui offrent des fonctionnalités supplémentaires.
 L’utilisation d’un [`CustomResourceDefinition`](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) permet d’ajouter une ressource workload d’un fournisseur tiers si vous souhaitez rajouter une fonctionnalité ou un comportement spécifique qui ne fait pas partie du noyau de Kubernetes.
 Par exemple, si vous voulez lancer un groupe de `Pods` pour votre application mais que vous devez arrêter leurs fonctionnement tant qu’ils ne sont pas tous disponibles, alors vous pouvez implémenter ou installer une extension qui permet cette fonctionnalité.
 ## {{% heading "whatsnext" %}}
 Vous pouvez continuer la lecture des ressources, vous pouvez aussi apprendre à connaitre les taches qui leurs sont liées :
 * Lancer une [application stateless en utilisant un `Deployment`](/docs/tasks/run-application/run-stateless-application-deployment/).
 * Lancer une application statefull, soit comme [instance unique](/docs/tasks/run-application/run-single-instance-stateful-application/)
  ou alors comme un [ensemble répliqué](/docs/tasks/run-application/run-replicated-stateful-application/).
 * Lancer une [tâche automatisée avec un `CronJob`](/docs/tasks/job/automated-tasks-with-cron-jobs/).
 Pour en apprendre plus sur les méchanismes de Kubernetes, de séparation du code et de la configuration,
 allez voir [Configuration](/docs/concepts/configuration/).
 Il y a deux concepts supportés qui fournissent un contexte sur le sujet : comment Kubernetes gère les pods pour les applications :
 * Le [ramasse-miettes](/docs/concepts/workloads/controllers/garbage-collection/), fait le ménage dans votre cluster après qu’une de _vos ressource_ soit supprimé.
 * Le [temps de vie d’un controlleur éteint](/docs/concepts/workloads/controllers/ttlafterfinished/) supprime les Jobs une fois qu’un temps définit soit passé après son accomplissement.
 Une fois que votre application est lancée, vous souhaitez peut etre la rendre disponible sur internet comme un [Service](/docs/concepts/services-networking/service/) ou comme une application web uniquement en utilsant un [Ingress](/docs/concepts/services-networking/ingress).
@@ -135,7 +135,6 @@ hack/update-generated-swagger-docs.sh
 hack/update-swagger-spec.sh
 hack/update-openapi-spec.sh
 hack/update-generated-protobuf.sh
 hack/update-api-reference-docs.sh
 ```
 Exécutez `git status` pour voir ce qui a été généré.
@@ -144,8 +143,6 @@ Exécutez `git status` pour voir ce qui a été généré.
 On branch master
 ...
    modified:   api/openapi-spec/swagger.json
    modified:   api/swagger-spec/apps_v1.json
    modified:   docs/api-reference/apps/v1/definitions.html
    modified:   staging/src/k8s.io/api/apps/v1/generated.proto
    modified:   staging/src/k8s.io/api/apps/v1/types.go
    modified:   staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
@@ -19,7 +19,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex
 ## Répertorier toutes les images de conteneurs dans tous les namespaces
 - Récupérez tous les pods dans tous les namespace à l'aide de `kubectl get pods --all-namespaces`
- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={..image}`.
+- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={.items[*].spec.containers[*].image}`.
  Cela analysera récursivement le champ `image` du json retourné.
  - Voir la [reference jsonpath](/docs/reference/kubectl/jsonpath/) pour plus d'informations sur l'utilisation de jsonpath.
 - Formatez la sortie à l'aide des outils standard: `tr`, `sort`, `uniq`
@@ -28,7 +28,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex
  - Utilisez `uniq` pour agréger le nombre d'images
 ```shell
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -69,7 +69,7 @@ Pour cibler uniquement les pods correspondant à un label spécifique, utilisez
 Les éléments suivants correspondent uniquement aux pods avec les labels `app=nginx`.
 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```
 ## Filtrage des images de conteneur de liste par namespace de pod
@@ -78,7 +78,7 @@ Pour cibler uniquement les pods dans un namespace spécifique, utilisez l'indica
 Ce qui suit correspond uniquement aux pods du namespace `kube-system`.
 ```shell
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 ## Répertorier les images de conteneurs en utilisant un go-template au lieu de jsonpath
@@ -0,0 +1,6 @@
 ---
 linktitle: कुबेरनेट्स प्रलेखन
 title: प्रलेखन
 sitemap:
  priority: 1.0
 ---
@@ -28,7 +28,7 @@ Container untuk masing-masing Pod.
 - Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces`
 - Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container
-  dengan menggunakan perintah `-o jsonpath={..image}`.  Perintah ini akan mem-_parsing field_
+  dengan menggunakan perintah `-o jsonpath={.items[*].spec.containers[*].image}`.  Perintah ini akan mem-_parsing field_
  `image` dari keluaran json yang dihasilkan.
  - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/)
    untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`.
@@ -38,7 +38,7 @@ Container untuk masing-masing Pod.
  - Gunakan `uniq` untuk mengumpulkan jumlah _image_
 ```sh
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -86,7 +86,7 @@ Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda
 dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`.
 ```sh
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```
 ## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod
@@ -95,7 +95,7 @@ Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace.
 dibawah ini hanya menyaring Pod pada Namespace `kube-system`.
 ```sh
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 ## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
@@ -47,7 +47,7 @@ Podをスケジュールできない理由に関するスケジューラーか
 クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。
 この場合、いくつかのことを試すことができます。
-* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。
+* クラスターにノードを追加します。
 * [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、
  `Pending`状態のPodのための空きリソースを作ります。
@@ -105,9 +105,9 @@ CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다.
 컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은
 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은
 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
-`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 로 변환되며,
+`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, 
-`1m` 도 허용되지 않게 정밀하다. 이러한 이유로, `100m` 형식이
+`1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로, 
-선호될 수 있다.
+`100m` 과 같은 형식이 선호될 수 있다.
 CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
 0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다.
@@ -77,7 +77,7 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
 힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨.
 {{< /note >}}
-자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
+자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다.
 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
@@ -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-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon NA, 17-20.11.2020</a>
+        <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 11-15.10.2021</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Weź udział w wirtualnym KubeCon EU 4–7.05.2021</a>
+        <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 wirtualnym KubeCon Europe 17-20.5.2022</a>
 </div>
 <div id="videoPlayer">
@@ -27,7 +27,7 @@ Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego r
 Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik).
-Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*.
+Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach wirtualnych.
 ### kube-apiserver
@@ -45,10 +45,11 @@ Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klas
 {{< glossary_definition term_id="kube-controller-manager" length="all" >}}
-Kontrolerami są:
+Przykładowe kontrolery:
 * Node controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny.
-* Replication controller: Odpowiada za utrzymanie prawidłowej liczby podów dla każdego obiektu typu *ReplicationController* w systemie.
+* Job controller: Czeka na obiekty typu *Job*, które definiują zadania uruchamiane jednorazowo
  i startuje Pody, odpowiadające za ich wykonanie tych zadań.
 * Endpoints controller: Dostarcza informacji do obiektów typu *Endpoints* (tzn. łączy ze sobą Serwisy i Pody).
 * Service Account & Token controllers: Tworzy domyślne konta i tokeny dostępu API dla nowych przestrzeni nazw (*namespaces*).
@@ -14,11 +14,10 @@ sitemap:
 <!-- overview -->
 Na tej stronie znajdziesz ogólne informacje o Kubernetesie.
 <!-- body -->
 Kubernetes to przenośna, rozszerzalna platforma oprogramowania *open-source* służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach, która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija. Serwisy Kubernetesa, wsparcie i narzędzia są szeroko dostępne.
-Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
+Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s" .Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
 ## Trochę historii
@@ -1,48 +0,0 @@
 ---
 title: Narzędzia
 content_type: concept
 ---
 <!-- overview -->
 Kubernetes zawiera różne wbudowane narzędzia służące do pracy z systemem:
 <!-- body -->
 ## Kubectl
 [`kubectl`](/docs/tasks/tools/install-kubectl/) to narzędzie tekstowe (linii poleceń) do Kubernetes. Służy do zarządzania klastrem Kubernetes.
 ## Kubeadm
 [`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) to narzędzie tekstowe do łatwej instalacji klastra Kubernetes w bezpiecznej konfiguracji, uruchamianego na infrastrukturze serwerów fizycznych, serwerów w chmurze bądź na maszynach wirtualnych (aktualnie w fazie rozwojowej alfa).
 ## Minikube
 [`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do uruchamiania jednowęzłowego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów.
 ## Pulpit *(Dashboard)*
 [`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/) - graficzny interfejs użytkownika w przeglądarce web, który umożliwia instalację aplikacji w kontenerach na klastrze Kubernetes, rozwiązywanie problemów z nimi związanych oraz zarządzanie samym klastrem i jego zasobami.
 ## Helm
 [`Kubernetes Helm`](https://github.com/kubernetes/helm) — narzędzie do zarządzania pakietami wstępnie skonfigurowanych zasobów Kubernetes (nazywanych *Kubernetes charts*).
 Helm-a można używać do:
 * Wyszukiwania i instalowania popularnego oprogramowania dystrybuowanego jako Kubernetes *charts*
 * Udostępniania własnych aplikacji w postaci pakietów Kubernetes *charts*
 * Definiowania powtarzalnych instalacji aplikacji na Kubernetes
 * Inteligentnego zarządzania plikami list (*manifests*) Kubernetes
 * Zarządzaniem kolejnymi wydaniami pakietów Helm
 ## Kompose
 [`Kompose`](https://github.com/kubernetes/kompose) to narzędzie, które ma pomóc użytkownikom Docker Compose przenieść się na Kubernetes.
 Kompose można używać do:
 * Tłumaczenia plików Docker Compose na obiekty Kubernetes
 * Zmiany sposóbu zarządzania twoimi aplikacjami z lokalnego środowiska Docker na system Kubernetes
 * Zamiany plików `yaml` Docker Compose v1 lub v2 oraz [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
@@ -1,9 +1,9 @@
 ---
 no_issue: true
 title: Od czego zacząć
 main_menu: true
 weight: 20
 content_type: concept
 no_list: true
 card:
  name: setup
  weight: 20
@@ -19,16 +19,44 @@ card:
 Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa.
 Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem.
-Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym albo skorzystać z klastra Kubernetes udostępnianego jako usługa. Inną możliwością jest budowa własnego systemu opartego o różnych dostawców usług chmurowych, bądź bazującego bezpośrednio na sprzęcie fizycznym.
+Możesz [pobrać Kubernetesa](/releases/download/), aby zainstalować klaster
 na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym.
 Jeśli nie chcesz zarządzać klastrem Kubernetesa samodzielnie, możesz wybrać serwis zarządzany przez zewnętrznego dostawcę,
 wybierając na przykład spośród [certyfikowanych platform](/docs/setup/production-environment/turnkey-solutions/).
 Dostępne są także inne standardowe i specjalizowane rozwiązania dla różnych środowisk chmurowych
 bądź bazujące bezpośrednio na sprzęcie fizycznym.
 <!-- body -->
 ## Środowisko do nauki {#srodowisko-do-nauki}
-Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym.
+Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa
 lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym.
 Zapoznaj się z [narzędziami instalacyjnymi](/docs/tasks/tools/).
 ## Środowisko produkcyjne {#srodowisko-produkcyjne}
-Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora.
+Wybierając rozwiązanie dla
 [środowiska produkcyjnego](/docs/setup/production-environment/) musisz zdecydować,
 którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam,
 a które będą realizowane po stronie zewnętrznego operatora.
-Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes).
+Do instalacji klastra Kubernetesa zarządzanego samodzielnie oficjalnym narzędziem
 jest [kubeadm](/docs/setup/production-environment/tools/kubeadm/).
 ## {{% heading "whatsnext" %}}
 - [Pobierz Kubernetesa](/releases/download/)
 - Pobierz i [zainstaluj narzędzia](/docs/tasks/tools/), w tym `kubectl`
 - Wybierz [środowisko uruchomieniowe dla kontenerów](/docs/setup/production-environment/container-runtimes/) w nowym klastrze
 - Naucz się [najlepszych praktyk](/docs/setup/best-practices/) przy konfigurowaniu klastra
 Na stronie [Partnerów Kubernetesa](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających
 [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes).
 Kubernetes zaprojektowano w ten sposób, że {{< glossary_tooltip term_id="control-plane" text="warstwa sterowania" >}}
 wymaga do działania systemu Linux. W ramach klastra aplikacje mogą być uruchamiane na systemie Linux i innych,
 w tym Windows.
 - Naucz się, [jak zbudować klaster z węzłami Windows](/docs/setup/production-environment/windows/)
@@ -1,4 +0,0 @@
 ---
 title: "Informacje o wydaniach i dozwolonych różnicach wersji"
 weight: 10
 ---
@@ -11,7 +11,7 @@ card:
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="pl">
 <body>
@@ -24,4 +24,4 @@ Więcej informacji można z znaleźć w dokumencie [version skew policy](/releas
 Zajrzyj na [harmonogram](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) nadchodzącego wydania Kubernetesa numer **{{< skew nextMinorVersion >}}**!
-## Przydatne zasoby
+## Przydatne zasoby
@@ -10,7 +10,7 @@ card:
 <!DOCTYPE html>
-<html lang="en">
+<html lang="vi">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="vi">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="vi">
 <body>
@@ -5,7 +5,7 @@ weight: 20
 <!DOCTYPE html>
-<html lang="en">
+<html lang="vi">
 <body>
@@ -5,7 +5,7 @@ weight: 10
 <!DOCTYPE html>
-<html lang="en">
+<html lang="vi">
 <body>
@@ -78,12 +78,14 @@ If your extension API server cannot achieve that latency requirement, consider m
 <!--
 * To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
 * Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
-* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
+* Read about [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) in the API reference
-* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
+
 Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
 -->
 * 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档，
  了解如何在自己的环境中启用聚合器。
 * 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
  开始使用聚合层。
-* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。
-* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
+
 或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
@@ -579,7 +579,7 @@ must be satisfied for the pod to be scheduled onto a node.
 -->
 #### 名字空间选择算符
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 <!--
 Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
@@ -595,14 +595,14 @@ null `namespaceSelector` means "this pod's namespace".
 `namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
 <!--
-This feature is alpha and disabled by default. You can enable it by setting the
+This feature is beta and enabled by default. You can disable it via the
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler.
 -->
-此功能特性是 Alpha 版本的，默认是被禁用的。你可以通过针对 kube-apiserver 和
+此功能特性是 Beta 版本的，默认是被启用的。你可以通过针对 kube-apiserver 和
 kube-scheduler 设置
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 来启用此特性。
+`PodAffinityNamespaceSelector` 来禁用此特性。
 <!--
 #### More Practical Use-cases
@@ -1,47 +0,0 @@
 ---
 title: 驱逐策略
 content_type: concept
 weight: 60
 ---
 <!--
 title: Eviction Policy
 content_type: concept
 weight: 60
 -->
 <!-- overview -->
 <!--
 This page is an overview of Kubernetes' policy for eviction.
 -->
 本页提供 Kubernetes 驱逐策略的概览。
 <!-- body -->
 <!--
 ## Eviction Policy
 The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for
 and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim
 the starved resource by failing one or more Pods. When the `kubelet` fails
 a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
 If the evicted Pod is managed by a Deployment, the Deployment creates another Pod
 to be scheduled by Kubernetes.
 -->
 ## 驱逐策略  {#eviction-policy}
 {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 主动监测和防止
 计算资源的全面短缺。在资源短缺时，`kubelet` 可以主动地结束一个或多个 Pod
 以回收短缺的资源。
 当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase`
 将变为 `Failed`。
 如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给
 Kubernetes 来调度。
 ## {{% heading "whatsnext" %}}
 <!--
 - Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds.
 -->
 - 阅读[配置资源不足的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，
  进一步了解驱逐信号和阈值。
@@ -95,7 +95,7 @@ the API server about this decision in a process called _binding_.
 kube-apiserver，这个过程叫做 _绑定_。
 <!--
-Factors that need taken into account for scheduling decisions include
+Factors that need to be taken into account for scheduling decisions include
 individual and collective resource requirements, hardware / software /
 policy constraints, affinity and anti-affinity specifications, data
 locality, inter-workload interference, and so on.
@@ -173,7 +173,7 @@ of the scheduler:
 * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
-* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
+* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
 * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
@@ -181,7 +181,7 @@ of the scheduler:
 * 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
-* 阅读 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* 阅读 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 * 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
 * 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
@@ -432,17 +432,17 @@ the Node is not considered for preemption.
 {{< /note >}}
 <!-- 
-If a pending Pod has inter-pod affinity to one or more of the lower-priority
+If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}}
-Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence
+to one or more of the lower-priority Pods on the Node, the inter-Pod affinity
-of those lower-priority Pods. In this case, the scheduler does not preempt any
+rule cannot be satisfied in the absence of those lower-priority Pods. In this case, 
-Pods on the Node. Instead, it looks for another Node. The scheduler might find a
+the scheduler does not preempt any Pods on the Node. Instead, it looks for another
-suitable Node or it might not. There is no guarantee that the pending Pod can be
+Node. The scheduler might find a suitable Node or it might not. There is no 
-scheduled.
+guarantee that the pending Pod can be scheduled.
 Our recommended solution for this problem is to create inter-Pod affinity only
 towards equal or higher priority Pods.
 -->
-如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间亲和性，
+如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间{{< glossary_tooltip text="亲和性" term_id="affinity" >}}，
 则在没有这些较低优先级 Pod 的情况下，无法满足 Pod 间亲和性规则。
 在这种情况下，调度程序不会抢占节点上的任何 Pod。
 相反，它寻找另一个节点。调度程序可能会找到合适的节点，
@@ -620,7 +620,7 @@ Pod 优先级和 {{<glossary_tooltip text="QoS 类" term_id="qos-class" >}}
 或者最低优先级的 Pod 受 PodDisruptionBudget 保护时，才会考虑优先级较高的 Pod。
 <!-- 
-The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
+The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
 You can use the QoS class to estimate the order in which pods are most likely
 to get evicted. The kubelet ranks pods for eviction based on the following factors:
@@ -628,25 +628,26 @@ to get evicted. The kubelet ranks pods for eviction based on the following facto
  1. Pod Priority
  1. Amount of resource usage relative to requests 
-See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
+See [evicting end-user pods](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)
 for more details.
-kubelet out-of-resource eviction does not evict Pods when their
+kubelet node-pressure eviction does not evict Pods when their
 usage does not exceed their requests. If a Pod with lower priority is not
 exceeding its requests, it won't be evicted. Another Pod with higher priority
 that exceeds its requests may be evicted.
 -->
 kubelet 使用优先级来确定
-[资源不足时驱逐](/zh/docs/tasks/administer-cluster/out-of-resource/) Pod 的顺序。
+[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) Pod 的顺序。
 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名：
  1. 对紧俏资源的使用是否超过请求值
  1. Pod 优先级
  1. 相对于请求的资源使用量
-有关更多详细信息，请参阅[驱逐最终用户的 Pod](/zh/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)。
+有关更多详细信息，请参阅
 [kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。
-当某 Pod 的资源用量未超过其请求时，kubelet 资源不足驱逐不会驱逐该 Pod。
+当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。
 如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。
 另一个优先级高于其请求的 Pod 可能会被驱逐。
@@ -32,60 +32,70 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
 <!--
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
+Kubernetes allows the users to specify the resources along with weights for
-consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
+each resource to score nodes based on the request to capacity ratio. This
 allows users to bin pack extended resources by using appropriate parameters
 and improves the utilization of scarce resources in large clusters. The
 behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
 can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. 
 This argument consists of two parameters `shape` and `resources`. The `shape` 
 parameter allows the user to tune the function as least requested or most 
 requested based on `utilization` and `score` values.  The `resources` parameter 
 consists of `name` of the resource to be considered during scoring and `weight` 
 specify the weight of each resource.
 -->
 ## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
-在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）
+Kubernetes 允许用户指定资源以及每类资源的权重，
 的请求数量和可用容量 之比率对节点评分。
 Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
 以便根据请求数量与可用容量之比率为节点评分。
 这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
 `RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
-`requestedToCapacityRatioArguments` 的配置选项进行控制。
+`RequestedToCapacityRatioArgs` 的配置选项进行控制。
 该标志由两个参数 `shape` 和 `resources` 组成。
-`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求
+`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为
-（least requested）或
+最少请求（least requested）或最多请求（most requested）计算。
 最多请求（most requested）计算。
 `resources` 包含由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，
 `weight` 指定每种资源的权重。
 <!--
-Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
+Below is an example configuration that sets
 `requestedToCapacityRatioArguments` to bin packing behavior for extended
 resources `intel.com/foo` and `intel.com/bar`.
 -->
 以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源
 `intel.com/foo` 和 `intel.com/bar` 的装箱行为
-```json
+```yaml
-{
+apiVersion: kubescheduler.config.k8s.io/v1beta1
-  "kind": "Policy",
+kind: KubeSchedulerConfiguration
-  "apiVersion": "v1",
+profiles:
-  ...
+# ...
-  "priorities": [
+  pluginConfig:
-     ...
+  - name: RequestedToCapacityRatio
-    {
+    args: 
-      "name": "RequestedToCapacityRatioPriority",
+      shape:
-      "weight": 2,
+      - utilization: 0
-      "argument": {
+        score: 10
-        "requestedToCapacityRatioArguments": {
+      - utilization: 100
-          "shape": [
+        score: 0
-            {"utilization": 0, "score": 0},
+      resources:
-            {"utilization": 100, "score": 10}
+      - name: intel.com/foo
-          ],
+        weight: 3
-          "resources": [
+      - name: intel.com/bar
-            {"name": "intel.com/foo", "weight": 3},
+        weight: 5
            {"name": "intel.com/bar", "weight": 5}
          ]
        }
      }
    }
  ],
 }
 ```
 <!--
 Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler 
 flag `--config=/path/to/config/file` will pass the configuration to the 
 scheduler.
 -->
 使用 kube-scheduler 标志 `--config=/path/to/config/file` 
 引用 `KubeSchedulerConfiguration` 文件将配置传递给调度器。
 <!--
 **This feature is disabled by default**
 -->
@@ -81,11 +81,11 @@ kube-scheduler 的表现等价于设置值为 100。
 <!--
 To change the value, edit the
-[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 and then restart the scheduler.
 In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`
 -->
-要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 然后重启调度器。
 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。
@@ -298,6 +298,6 @@ After going over all the Nodes, it goes back to Node 1.
 ## {{% heading "whatsnext" %}}
-<!-- * Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -->
+<!-- * Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) -->
-* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
@@ -16,7 +16,7 @@ weight: 90
 <!-- overview -->
-{{< feature-state for_k8s_version="1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="1.19" state="stable" >}}
 <!--
 The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
@@ -476,10 +476,43 @@ This ensures that DaemonSet pods are never evicted due to these problems.
 ## 基于节点状态添加污点
 <!--
-The node lifecycle controller automatically creates taints corresponding to
+The control plane, using the node {{<glossary_tooltip text="controller" term_id="controller">}},
-Node conditions with `NoSchedule` effect.
+automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions).
 Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
 The scheduler checks taints, not node conditions, when it makes scheduling
 decisions. This ensures that node conditions don't directly affect scheduling.
 For example, if the `DiskPressure` node condition is active, the control plane
 adds the `node.kubernetes.io/disk-pressure` taint and does not schedule new pods
 onto the affected node. If the `MemoryPressure` node condition is active, the
 control plane adds the `node.kubernetes.io/memory-pressure` taint. 
 -->
 控制平面使用节点{{<glossary_tooltip text="控制器" term_id="controller">}}自动创建
 与[节点状况](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。
 调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。
 例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面
 添加 `node.kubernetes.io/disk-pressure` 污点并且不会调度新的 pod
 到受影响的节点。如果 `MemoryPressure` 节点状况处于活跃状态，则
 控制平面添加 `node.kubernetes.io/memory-pressure` 污点。
 <!--
 You can ignore node conditions for newly created pods by adding the corresponding
 Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure` 
 toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}} 
 other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed` 
 or `Burstable` QoS classes (even pods with no memory request set) as if they are
 able to cope with memory pressure, while new `BestEffort` pods are not scheduled
 onto the affected node. 
 -->
 对于新创建的 Pod，可以通过添加相应的 Pod 容忍度来忽略节点状况。
 控制平面还在具有除 `BestEffort` 之外的 {{<glossary_tooltip text="QoS 类" term_id="qos-class" >}}的 pod 上
 添加 `node.kubernetes.io/memory-pressure` 容忍度。
 这是因为 Kubernetes 将 `Guaranteed` 或 `Burstable` QoS 类中的 Pod（甚至没有设置内存请求的 Pod）
 视为能够应对内存压力，而新创建的 `BestEffort` Pod 不会被调度到受影响的节点上。
 <!--
 The DaemonSet controller automatically adds the
 following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
 breaking.
@@ -490,9 +523,6 @@ breaking.
  * `node.kubernetes.io/unschedulable` (1.10 or later)
  * `node.kubernetes.io/network-unavailable` (*host network only*)
 -->
 Node 生命周期控制器会自动创建与 Node 条件相对应的带有 `NoSchedule` 效应的污点。
 同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。
 用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。
 DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍度以防 DaemonSet 崩溃：
@@ -512,8 +542,8 @@ arbitrary tolerations to DaemonSets.
 ## {{% heading "whatsnext" %}}
 <!--
-* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
+* Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it
-* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
+* Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
 -->
-* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
+* 阅读[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)，以及如何配置其行为
-* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* 阅读 [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
@@ -92,10 +92,10 @@ options ndots:5
 <!--
 In summary, a pod in the _test_ namespace can successfully resolve either
-`data.prod` or `data.prod.cluster.local`.
+`data.prod` or `data.prod.svc.cluster.local`.
 -->
 概括起来，名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者
-`data.prod.cluster.local`。
+`data.prod.svc.cluster.local`。
 <!--
 ### DNS Records
@@ -336,11 +336,11 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
 <!--
 ### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
-{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
 -->
 ### Pod 的 setHostnameAsFQDN 字段  {#pod-sethostnameasfqdn-field}
-{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
 <!--
 When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and  the `hostname -fqdn` command returns the FQDN.
@@ -454,6 +454,8 @@ spec:
 <!--
 ### Pod's DNS Config
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 Pod's DNS Config allows users more control on the DNS settings for a Pod.
 The `dnsConfig` field is optional and it can work with any `dnsPolicy` settings.
@@ -464,6 +466,8 @@ Below are the properties a user can specify in the `dnsConfig` field:
 -->
 ### Pod 的 DNS 配置  {#pod-dns-config}
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
 `dnsConfig` 字段是可选的，它可以与任何 `dnsPolicy` 设置一起使用。
@@ -541,6 +545,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
 options ndots:5
 ```
 <!--
 #### Expanded DNS Configuration
 {{< feature-state for_k8s_version="1.22" state="alpha" >}}
 By default, for Pod's DNS Config, Kubernetes allows at most 6 search domains and
 a list of search domains of up to 256 characters.
 If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and
 the kubelet, it is allowed for Kubernetes to have at most 32 search domains and
 a list of search domains of up to 2048 characters.
 -->
 #### 扩展 DNS 配置  {#expanded-dns-configuration}
 {{< feature-state for_k8s_version="1.22" state="alpha" >}}
 对于 Pod DNS 配置，Kubernetes 默认允许最多 6 个 搜索域（ Search Domain） 
 以及一个最多 256 个字符的搜索域列表。
 如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个 
 搜索域以及一个最多 2048 个字符的搜索域列表。
 <!--
 ### Feature availability
@@ -458,9 +458,7 @@ implementation in `kube-proxy`.
 ## {{% heading "whatsnext" %}}
 <!--
 * [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->
 * 了解[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
 * 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
@@ -421,7 +421,7 @@ IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该
 -->
 #### 名字空间域的参数
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 <!--
 `Parameters` field has a `scope` and `namespace` field that can be used to
@@ -429,6 +429,11 @@ reference a namespace-specific resource for configuration of an Ingress class.
 `Scope` field defaults to `Cluster`, meaning, the default is cluster-scoped
 resource. Setting `Scope` to `Namespace` and setting the `Namespace` field
 will reference a parameters resource in a specific namespace:
 Namespace-scoped parameters avoid the need for a cluster-scoped CustomResourceDefinition
 for a parameters resource. This further avoids RBAC-related resources
 that would otherwise be required to grant permissions to cluster-scoped
 resources.
 -->
 `parameters` 字段有一个 `scope` 和 `namespace` 字段，可用来引用特定
 于名字空间的资源，对 Ingress 类进行配置。
@@ -436,6 +441,9 @@ will reference a parameters resource in a specific namespace:
 将 `scope` 设置为 `Namespace` 并设置 `namespace` 字段就可以引用某特定
 名字空间中的参数资源。
 有了名字空间域的参数，就不再需要为一个参数资源配置集群范围的 CustomResourceDefinition。
 除此之外，之前对访问集群范围的资源进行授权，需要用到 RBAC 相关的资源，现在也不再需要了。
 {{< codenew file="service/networking/namespaced-params.yaml" >}}
 <!-- 
@@ -290,6 +290,7 @@ Pod 的连接，*或* 来自任何名字空间中标有 `user=alice` 的任何 P
 <!--
 When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.
 <a name="behavior-of-ipblock-selectors"></a>
 __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.
 Cluster ingress and egress mechanisms often require rewriting the source or destination IP
@@ -415,13 +416,13 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
 -->
 ## SCTP 支持
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 <!--
-As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=SCTPSupport=false,...`.
+As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
 When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
 -->
-作为一个 Beta 特性，SCTP 支持默认是被启用的。
+作为一个稳定特性，SCTP 支持默认是被启用的。
 要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定
 `--feature-gates=SCTPSupport=false,...`
 来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
@@ -439,7 +440,7 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
 -->
 ## 针对某个端口范围   {#targeting-a-range-of-ports}
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 <!--
 When writing a NetworkPolicy, you can target a range of ports instead of a single port.
@@ -473,23 +474,25 @@ spec:
 ```
 <!--
-The above rule allows any Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` over TCP, provided that the target port is between the range 32000 and 32768.
+The above rule allows any Pod with label `db` on the namespace `default` to communicate 
 with any IP within the range `10.0.0.0/24` over TCP, provided that the target 
 port is between the range 32000 and 32768.
 -->
 上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议
 与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。
 <!--
 The following restrictions apply when using this field:
-* As an alpha feature, this is disabled by default. To enable the `endPort` field at a cluster level, you (or your cluster administrator) need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=NetworkPolicyEndPort=true,…`.
+* As a beta feature, this is enabled by default. To disable the `endPort` field at a cluster level, you (or your cluster administrator) need to disable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=NetworkPolicyEndPort=false,…`.
 * The `endPort` field must be equal than or greater to the `port` field.
 * `endPort` can only be defined if `port` is also defined.
 * Both ports must be numeric.
 -->
 使用此字段时存在以下限制：
-* 作为一种 Alpha 阶段的特性，端口范围设定默认是被禁用的。要在整个集群
+* 作为一种 Beta 阶段的特性，端口范围设定默认是被启用的。要在整个集群
-  范围内允许使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
+  范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
-  服务器设置 `-feature-gates=NetworkPolicyEndPort=true,...` 以启用
+  服务器设置 `-feature-gates=NetworkPolicyEndPort=false,...` 以禁用
  `NetworkPolicyEndPort` 
  [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
 * `endPort` 字段必须等于或者大于 `port` 字段的值。
@@ -499,9 +502,15 @@ The following restrictions apply when using this field:
 <!--
 Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that
 supports the `endPort` field in NetworkPolicy specifications.
 If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 
 does not support the `endPort` field and you specify a NetworkPolicy with that,
 the policy will be applied only for the single `port` field.
 -->
 你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件
 必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。
 如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy，
 策略只对单个 `port` 字段生效。
 {{< /note >}}
 <!--
@@ -127,7 +127,7 @@ A Service in Kubernetes is a REST object, similar to a Pod.  Like all of the
 REST objects, you can `POST` a Service definition to the API server to create
 a new instance.
 The name of a Service object must be a valid
-[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
+[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names).
 For example, suppose you have a set of Pods where each listens on TCP port 9376
 and contains a label `app=MyApp`:
@@ -138,7 +138,7 @@ and contains a label `app=MyApp`:
 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。
 像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。
 Service 对象的名称必须是合法的
-[DNS 标签名称](/zh/docs/concepts/overview/working-with-objects/names#dns-label-names)。
+[RFC 1035 标签名称](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names).。
 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签：
@@ -315,16 +315,17 @@ ExternalName Service 是 Service 的特例，它没有选择算符，但是使
 <!--
 ### Over Capacity Endpoints
-If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21 (or later)
+If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.22 (or later)
-cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: warning`.
+cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: truncated`.
-This annotation indicates that the affected Endpoints object is over capacity.
+This annotation indicates that the affected Endpoints object is over capacity and that
 the endpoints controller has truncated the number of endpoints to 1000.
 -->
 ### 超出容量的 Endpoints    {#over-capacity-endpoints}
-如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.21 版本
+如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.22 版本
 （及更新版本）的集群会将为该 Endpoints 添加注解
-`endpoints.kubernetes.io/over-capacity: warning`。
+`endpoints.kubernetes.io/over-capacity: truncated`。
-这一注解表明所影响到的 Endpoints 对象已经超出容量。
+这一注解表明所影响到的 Endpoints 对象已经超出容量，此外 Endpoints 控制器还会将 Endpoints 对象数量截断到 1000。
 <!--
 ### EndpointSlices
@@ -660,6 +661,82 @@ server will return a 422 HTTP status code to indicate that there's a problem.
 这对 API 服务器来说是通过一个标识来指定的。
 如果 IP 地址不合法，API 服务器会返回 HTTP 状态码 422，表示值不合法。
 <!--
 ## Traffic policies
 -->
 ## 流量策略  {#traffic-policies}
 <!--
 ### External traffic policy
 -->
 ### 外部流量策略    {#external-traffic-policy}
 <!--
 You can set the `spec.externalTrafficPolicy` field to control how traffic from external sources is routed.
 Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route external traffic to all ready endpoints
 and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are are no node-local
 endpoints, the kube-proxy does not forward any traffic for the relevant Service.
 -->
 你可以通过设置 `spec.externalTrafficPolicy` 字段来控制来自于外部的流量是如何路由的。
 可选值有 `Cluster` 和 `Local`。字段设为 `Cluster` 会将外部流量路由到所有就绪的端点，
 设为 `Local` 会只路由到当前节点上就绪的端点。
 如果流量策略设置为 `Local`，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。
 {{< note >}}
 {{< feature-state for_k8s_version="v1.22" state="alpha" >}}
 <!--
 If you enable the `ProxyTerminatingEndpoints`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `ProxyTerminatingEndpoints` for the kube-proxy, the kube-proxy checks if the node
 has local endpoints and whether or not all the local endpoints are marked as terminating.
 -->
 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints`
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
 kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。
 <!--
 If there are local endpoints and **all** of those are terminating, then the kube-proxy ignores
 any external traffic policy of `Local`. Instead, whilst the node-local endpoints remain as all
 terminating, the kube-proxy forwards traffic for that Service to healthy endpoints elsewhere,
 as if the external traffic policy were set to `Cluster`.
 -->
 如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 `Local` 的外部流量策略。
 在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的
 状态健康的端点，如同外部流量策略设为 `Cluster`。
 <!--
 This forwarding behavior for terminating endpoints exists to allow external load balancers to
 gracefully drain connections that are backed by `NodePort` Services, even when the health check
 node port starts to fail. Otherwise, traffic can be lost between the time a node is still in the node pool of a load
 balancer and traffic is being dropped during the termination period of a pod.
 -->
 针对处于正被终止状态的端点这一转发行为使得外部负载均衡器可以优雅地排出由
 `NodePort` 服务支持的连接，就算是健康检查节点端口开始失败也是如此。
 否则，当节点还在负载均衡器的节点池内，在 Pod 终止过程中的流量会被丢掉，这些流量可能会丢失。
 {{< /note >}}
 <!--
 ### Internal traffic policy
 -->
 ### 内部流量策略    {#internal-traffic-policy}
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 <!--
 You can set the `spec.internalTrafficPolicy` field to control how traffic from internal sources is routed.
 Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route internal traffic to all ready endpoints
 and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local
 endpoints, traffic is dropped by kube-proxy.
 -->
 你可以设置 `spec.internalTrafficPolicy` 字段来控制内部来源的流量是如何转发的。可设置的值有 `Cluster` 和 `Local`。
 将字段设置为 `Cluster` 会将内部流量路由到所有就绪端点，设置为 `Local` 只会路由到当前节点上就绪的端点。
 如果流量策略是 `Local`，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。
 <!--
 ## Discovering services
@@ -1124,13 +1201,13 @@ LoadBalancer 类型的服务继续分配节点端口。
 -->
 #### 设置负载均衡器实现的类别 {#load-balancer-class}
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 <!--
-Starting in v1.21, you can optionally specify the class of a load balancer implementation for
+`spec.loadBalancerClass` enables you to use a load balancer implementation other than the cloud provider default. This feature is available from v1.21, you must enable the `ServiceLoadBalancerClass` feature gate to use this field in v1.21, and the feature gate is enabled by default from v1.22 onwards.
 `LoadBalancer` type of Service by setting the field `spec.loadBalancerClass`.
 By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses
-the cloud provider's default load balancer implementation. 
+the cloud provider's default load balancer implementation if the cluster is configured with
 a cloud provider using the `--cloud-provider` component flag. 
 If `spec.loadBalancerClass` is specified, it is assumed that a load balancer
 implementation that matches the specified class is watching for Services.
 Any default load balancer implementation (for example, the one provided by
@@ -1138,10 +1215,11 @@ the cloud provider) will ignore Services that have this field set.
 `spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only.
 Once set, it cannot be changed. 
 -->
-从 v1.21 开始，你可以有选择地为 `LoadBalancer` 类型的服务设置字段
+`spec.loadBalancerClass` 允许你不使用云提供商的默认负载均衡器实现，转而使用指定的负载均衡器实现。
-`.spec.loadBalancerClass`，以指定其负载均衡器实现的类别。
+这个特性从 v1.21 版本开始可以使用，你在 v1.21 版本中使用这个字段必须启用 `ServiceLoadBalancerClass` 
-默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，`LoadBalancer` 类型
+特性门控，这个特性门控从 v1.22 版本及以后默认打开。
-服务会使用云提供商的默认负载均衡器实现。
+默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，如果集群使用 `--cloud-provider` 配置了云提供商，
 `LoadBalancer` 类型服务会使用云提供商的默认负载均衡器实现。
 如果设置了 `.spec.loadBalancerClass`，则假定存在某个与所指定的类相匹配的
 负载均衡器实现在监视服务变化。
 所有默认的负载均衡器实现（例如，由云提供商所提供的）都会忽略设置了此字段
@@ -1152,12 +1230,10 @@ Once set, it cannot be changed.
 The value of `spec.loadBalancerClass` must be a label-style identifier,
 with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`".
 Unprefixed names are reserved for end-users.
 You must enable the `ServiceLoadBalancerClass` feature gate to use this field.
 -->
 `.spec.loadBalancerClass` 的值必须是一个标签风格的标识符，
 可以有选择地带有类似 "`internal-vip`" 或 "`example.com/internal-vip`" 这类
 前缀。没有前缀的名字是保留给最终用户的。
 你必须启用 `ServiceLoadBalancerClass` 特性门控才能使用此字段。
 <!--
 #### Internal load balancer
@@ -115,7 +115,7 @@ It acts synchronously to modify pods as they are created or updated. When this p
 1. 如果该 Pod 没有设置 `ServiceAccount`，将其 `ServiceAccount` 设为 `default`。
 1. 保证 Pod 所引用的 `ServiceAccount` 确实存在，否则拒绝该 Pod。
 1. 如果服务账号的 `automountServiceAccountToken` 或 Pod 的
-   `automountServiceAccountToken` 都为设置为 `false`，则为 Pod 创建一个
+   `automountServiceAccountToken` 都未显示设置为 `false`，则为 Pod 创建一个
   `volume`，在其中包含用来访问 API 的令牌。
 1. 如果前一步中为服务账号令牌创建了卷，则为 Pod 中的每个容器添加一个
   `volumeSource`，挂载在其 `/var/run/secrets/kubernetes.io/serviceaccount`
@@ -384,7 +384,7 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是：
 | Package name | Description |
 |--------------|-------------|
 | `kubeadm`    | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 的 systemd 文件](#the-kubelet-drop-in-file-for-systemd)。 |
-| `kubelet`    | 安装 kublet 可执行文件到 `/usr/bin` 路径，安装 CNI 可执行文件到 `/opt/cni/bin` 路径。 |
+| `kubelet`    | 安装 kubelet 可执行文件到 `/usr/bin` 路径，安装 CNI 可执行文件到 `/opt/cni/bin` 路径。 |
 | `kubectl`    | 安装 `/usr/bin/kubectl` 可执行文件。 |
 | `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-sigs/cri-tools)中安装 `/usr/bin/crictl` 可执行文件。 |
@@ -36,7 +36,7 @@ of Containers for each.
 - Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
 - Format the output to include only the list of Container image names
-  using `-o jsonpath={..image}`.  This will recursively parse out the
+  using `-o jsonpath={.items[*].spec.containers[*].image}`.  This will recursively parse out the
  `image` field from the returned json.
  - See the [jsonpath reference](/docs/user-guide/jsonpath/)
    for further information on how to use jsonpath.
@@ -48,7 +48,7 @@ of Containers for each.
 ## 列出所有命名空间下的所有容器
 - 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
- 使用 `-o jsonpath={..image}` 来格式化输出，以仅包含容器镜像名称。
+- 使用 `-o jsonpath={.items[*].spec.containers[*].image}` 来格式化输出，以仅包含容器镜像名称。
  这将以递归方式从返回的 json 中解析出 `image` 字段。
  - 参阅 [jsonpath 说明](/zh/docs/reference/kubectl/jsonpath/)
    获取更多关于如何使用 jsonpath 的信息。
@@ -58,7 +58,7 @@ of Containers for each.
  - 使用 `uniq` 来聚合镜像计数
 ```shell
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -132,7 +132,7 @@ following matches only Pods with labels matching `app=nginx`.
 要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```
 <!--
@@ -146,7 +146,7 @@ following matches only Pods in the `kube-system` namespace.
 要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
 ```shell
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 <!--
@@ -1,629 +0,0 @@
 ---
 title: 使用 Stackdriver 生成日志
 content_type: concept
 ---
 <!--
 reviewers:
 - piosz
 - x13n
 title: Logging Using Stackdriver
 content_type: concept
 -->
 <!-- overview -->
 <!--
 Before reading this page, it's highly recommended to familiarize yourself
 with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
 -->
 在阅读这篇文档之前，强烈建议你先熟悉一下 [Kubernetes 日志概况](/zh/docs/concepts/cluster-administration/logging)
 <!--
 By default, Stackdriver logging collects only your container's standard output and
 standard error streams. To collect any logs your application writes to a file (for example),
 see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
 in the Kubernetes logging overview.
 -->
 {{< note >}}
 默认情况下，Stackdriver 日志机制仅收集容器的标准输出和标准错误流。
 如果要收集你的应用程序写入一个文件（例如）的任何日志，请参见 Kubernetes 日志概述中的 [sidecar 方式](/zh/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
 {{< /note >}}
 <!-- body -->
 <!--
 ## Deploying
 -->
 ## 部署  {#deploying}
 <!--
 To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster.
 The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap`
 and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the
 `ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup.
 -->
 为了接收日志，你必须将 Stackdriver 日志代理部署到集群中的每个节点。
 此代理是一个已配置的 `fluentd`，其配置存在一个 `ConfigMap` 中，且实例使用 Kubernetes 的 `DaemonSet` 进行管理。
 `ConfigMap` 和 `DaemonSet` 的实际部署，取决你的集群设置。
 <!--
 ### Deploying to a new cluster
 -->
 ### 部署到一个新的集群
 #### Google Kubernetes Engine
 <!--
 Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
 Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
 -->
 对于部署在 Google Kubernetes Engine 上的集群，Stackdriver 是默认的日志解决方案。
 Stackdriver 日志机制会默认部署到你的新集群上，除非你明确地不选择。
 <!--
 #### Other platforms
 -->
 #### 其他平台
 <!--
 To deploy Stackdriver Logging on a *new* cluster that you're
 creating using `kube-up.sh`, do the following:
 -->
 为了将 Stackdriver 日志机制部署到你正在使用 `kube-up.sh` 创建的*新*集群上，执行如下操作：
 <!--
 1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`.
 1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true`
 in the `KUBE_NODE_LABELS` variable.
 -->
 1. 设置环境变量 `KUBE_LOGGING_DESTINATION` 为 `gcp`。
 1. **如果不是跑在 GCE 上**，在 `KUBE_NODE_LABELS` 变量中包含 `beta.kubernetes.io/fluentd-ds-ready=true`。
 <!--
 Once your cluster has started, each node should be running the Stackdriver Logging agent.
 The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`,
 consider starting a cluster without a pre-configured logging solution and then deploying
 Stackdriver Logging agents to the running cluster.
 -->
 集群启动后，每个节点都应该运行 Stackdriver 日志代理。
 `DaemonSet` 和 `ConfigMap` 作为附加组件进行配置。
 如果你不是使用 `kube-up.sh`，可以考虑不使用预先配置的日志方案启动集群，然后部署 Stackdriver 日志代理到正在运行的集群。
 <!--
 The Stackdriver logging daemon has known issues on platforms other
 than Google Kubernetes Engine. Proceed at your own risk.
 -->
 {{< warning >}}
 除了 Google Kubernetes Engine，Stackdriver 日志守护进程在其他的平台有已知的问题。
 请自行承担风险。
 {{< /warning >}}
 <!--
 ### Deploying to an existing cluster
 -->
 ### 部署到一个已知集群
 <!--
 1. Apply a label on each node, if not already present.
 -->
 1. 在每个节点上打标签（如果尚未存在）
   <!--
   The Stackdriver Logging agent deployment uses node labels to determine to which nodes
   it should be allocated. These labels were introduced to distinguish nodes with the
   Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging
   configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node
   cannot have more than one instance of fluentd, therefore only apply labels to the nodes
   that don't have fluentd pod allocated already. You can ensure that your node is labelled
   properly by running `kubectl describe` as follows:
   -->
   Stackdriver 日志代理部署使用节点标签来确定应该将其分配到给哪些节点。
   引入这些标签是为了区分 Kubernetes 1.6 或更高版本的节点。
   如果集群是在配置了 Stackdriver 日志机制的情况下创建的，并且节点的版本为 1.5.X 或更低版本，则它将使用 fluentd 用作静态容器。
   节点最多只能有一个 fluentd 实例，因此只能将标签打在未分配过 fluentd pod 的节点上。
   你可以通过运行 `kubectl describe` 来确保你的节点被正确标记，如下所示：
   ```
   kubectl describe node $NODE_NAME
   ```
   <!--
   The output should be similar to this:
   -->
   输出应类似于如下内容：
   ```
   Name:           NODE_NAME
   Role:
   Labels:         beta.kubernetes.io/fluentd-ds-ready=true
   ...
   ```
   <!--
   Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it
   is not present, you can add it using the `kubectl label` command as follows:
   -->
   确保输出内容包含 `beta.kubernetes.io/fluentd-ds-ready=true` 标签。
   如果不存在，则可以使用 `kubectl label` 命令添加，如下所示：
   ```
   kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
   ```
   <!--
   If a node fails and has to be recreated, you must re-apply the label to
   the recreated node. To make this easier, you can use Kubelet's command-line parameter
   for applying node labels in your node startup script.
   -->
   {{< note >}}
   如果节点发生故障并且必须重新创建，则必须将标签重新打在重新创建了的节点。
   为了让此操作更便捷，你可以在节点启动脚本中使用 Kubelet 的命令行参数给节点添加标签。
   {{< /note >}}
 <!--
 1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
 -->
 2. 通过运行以下命令，部署一个带有日志代理配置的 `ConfigMap`：
   ```
   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
   ```
   <!--
   The command creates the `ConfigMap` in the `default` namespace. You can download the file
   manually and change it before creating the `ConfigMap` object.
   -->
   该命令在 `default` 命名空间中创建 `ConfigMap`。你可以在创建 `ConfigMap` 对象之前手动下载文件并进行更改。
 <!--
 1. Deploy the logging agent `DaemonSet` by running the following command:
 -->
 3. 通过运行以下命令，部署日志代理的 `DaemonSet`：
   ```
   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
   ```
   <!--
   You can download and edit this file before using it as well.
   -->
   你也可以在使用前下载和编辑此文件。
 <!--
 ## Verifying your Logging Agent Deployment
 -->
 ## 验证日志代理部署
 <!--
 After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status
 by running the following command:
 -->
 部署 Stackdriver `DaemonSet` 之后，你可以通过运行以下命令来查看日志代理的部署状态：
 ```shell
 kubectl get ds --all-namespaces
 ```
 <!--
 If you have 3 nodes in the cluster, the output should looks similar to this:
 -->
 如果你的集群中有 3 个节点，则输出应类似于如下：
 ```
 NAMESPACE     NAME               DESIRED   CURRENT   READY     NODE-SELECTOR                              AGE
 ...
 default       fluentd-gcp-v2.0   3         3         3         beta.kubernetes.io/fluentd-ds-ready=true   5m
 ...
 ```
 <!--
 To understand how logging with Stackdriver works, consider the following
 synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml):
 -->
 要了解使用 Stackdriver 进行日志记录的工作方式，请考虑以下具有日志生成的 pod 定义 [counter-pod.yaml](/examples/debug/counter-pod.yaml)：
 {{< codenew file="debug/counter-pod.yaml" >}}
 <!--
 This pod specification has one container that runs a bash script
 that writes out the value of a counter and the datetime once per
 second, and runs indefinitely. Let's create this pod in the default namespace.
 -->
 这个 pod 定义里有一个容器，该容器运行一个 bash 脚本，脚本每秒写一次计数器的值和日期时间，并无限期地运行。
 让我们在默认命名空间中创建此 pod。
 ```shell
 kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
 ```
 <!--
 You can observe the running pod:
 -->
 你可以观察到正在运行的 pod：
 ```shell
 kubectl get pods
 ```
 ```
 NAME                                           READY     STATUS    RESTARTS   AGE
 counter                                        1/1       Running   0          5m
 ```
 <!--
 For a short period of time you can observe the 'Pending' pod status, because the kubelet
 has to download the container image first. When the pod status changes to `Running`
 you can use the `kubectl logs` command to view the output of this counter pod.
 -->
 在短时间内，你可以观察到 "pending" 的 pod 的状态，因为 kubelet 必须先下载容器镜像。
 当 pod 状态变为 `Running` 时，你可以使用 `kubectl logs` 命令查看此 counter pod 的输出。
 ```shell
 kubectl logs counter
 ```
 ```
 0: Mon Jan  1 00:00:00 UTC 2001
 1: Mon Jan  1 00:00:01 UTC 2001
 2: Mon Jan  1 00:00:02 UTC 2001
 ...
 ```
 <!--
 As described in the logging overview, this command fetches log entries
 from the container log file. If the container is killed and then restarted by
 Kubernetes, you can still access logs from the previous container. However,
 if the pod is evicted from the node, log files are lost. Let's demonstrate this
 by deleting the currently running counter container:
 -->
 正如日志概览所述，此命令从容器日志文件中获取日志项。
 如果该容器被 Kubernetes 杀死然后重新启动，你仍然可以访问前一个容器的日志。
 但是，如果将 Pod 从节点中驱逐，则日志文件会丢失。让我们通过删除当前运行的 counter 容器来演示这一点：
 ```shell
 kubectl delete pod counter
 ```
 ```
 pod "counter" deleted
 ```
 <!--
 and then recreating it:
 -->
 然后重建它：
 ```shell
 kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
 ```
 ```
 pod/counter created
 ```
 <!--
 After some time, you can access logs from the counter pod again:
 -->
 一段时间后，你可以再次从 counter pod 访问日志：
 ```shell
 kubectl logs counter
 ```
 ```
 0: Mon Jan  1 00:01:00 UTC 2001
 1: Mon Jan  1 00:01:01 UTC 2001
 2: Mon Jan  1 00:01:02 UTC 2001
 ...
 ```
 <!--
 As expected, only recent log lines are present. However, for a real-world
 application you will likely want to be able to access logs from all containers,
 especially for the debug purposes. This is exactly when the previously enabled
 Stackdriver Logging can help.
 -->
 如预期的那样，日志中仅出现最近的日志记录。
 但是，对于实际应用程序，你可能希望能够访问所有容器的日志，特别是出于调试的目的。
 这就是先前启用的 Stackdriver 日志机制可以提供帮助的地方。
 <!--
 ## Viewing logs
 -->
 ## 查看日志
 <!--
 Stackdriver Logging agent attaches metadata to each log entry, for you to use later
 in queries to select only the messages you're interested in: for example,
 the messages from a particular pod.
 -->
 Stackdriver 日志代理为每个日志项关联元数据，供你在后续的查询中只选择感兴趣的消息：
 例如，来自某个特定 Pod 的消息。
 <!--
 The most important pieces of metadata are the resource type and log name.
 The resource type of a container log is `container`, which is named
 `GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
 The log name is the name of the container, so that if you have a pod with
 two containers, named `container_1` and `container_2` in the spec, their logs
 will have log names `container_1` and `container_2` respectively.
 -->
 元数据最重要的部分是资源类型和日志名称。
 容器日志的资源类型为 `container`，在用户界面中名为 `GKE Containers`（即使 Kubernetes 集群不在 Google Kubernetes Engine 上）。
 日志名称是容器的名称，因此，如果你有一个包含两个容器的 pod，在 spec 中名称定义为 `container_1` 和 `container_2`，则它们的日志的名称分别为 `container_1` 和 `container_2`。
 <!--
 System components have resource type `compute`, which is named
 `GCE VM Instance` in the interface. Log names for system components are fixed.
 For a Google Kubernetes Engine node, every log entry from a system component has one of the following
 log names:
 -->
 系统组件的资源类型为 `compute`，在接口中名为 `GCE VM Instance`。
 系统组件的日志名称是固定的。
 对于 Google Kubernetes Engine 节点，系统组件中的每个日志项都具有以下日志名称之一：
 * docker
 * kubelet
 * kube-proxy
 <!--
 You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
 -->
 你可以在[Stackdriver 专用页面](https://cloud.google.com/logging/docs/view/overview)
 上了解有关查看日志的更多信息。
 <!--
 One of the possible ways to view logs is using the
 [`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
 command line interface from the [Google Cloud SDK].
 It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
 to query specific logs. For example, you can run the following command:
 -->
 查看日志的一种可能方法是使用 [Google Cloud SDK](https://cloud.google.com/sdk/)
 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging)
 命令行接口。
 它使用 Stackdriver 日志机制的
 [过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
 例如，你可以运行以下命令：
 ```none
 gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
 ```
 ```
 ...
 "2: Mon Jan  1 00:01:02 UTC 2001\n"
 "1: Mon Jan  1 00:01:01 UTC 2001\n"
 "0: Mon Jan  1 00:01:00 UTC 2001\n"
 ...
 "2: Mon Jan  1 00:00:02 UTC 2001\n"
 "1: Mon Jan  1 00:00:01 UTC 2001\n"
 "0: Mon Jan  1 00:00:00 UTC 2001\n"
 ```
 <!--
 As you can see, it outputs messages for the count container from both
 the first and second runs, despite the fact that the kubelet already deleted
 the logs for the first container.
 -->
 如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter
 容器第一次和第二次运行时输出的消息。
 <!--
 ### Exporting logs
 -->
 ### 导出日志
 <!--
 You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
 or to [BigQuery](https://cloud.google.com/bigquery/) to run further
 analysis. Stackdriver Logging offers the concept of sinks, where you can
 specify the destination of log entries. More information is available on
 the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
 -->
 你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或
 [BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。
 Stackdriver 日志机制提供了接收器（Sink）的概念，你可以在其中指定日志项的存放地。
 可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)
 上获得更多信息。
 <!--
 ## Configuring Stackdriver Logging Agents
 -->
 ## 配置 Stackdriver 日志代理
 <!--
 Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:
 -->
 有时默认的 Stackdriver 日志机制安装可能无法满足你的需求，例如：
 <!--
 * You may want to add more resources because default performance doesn't suit your needs.
 * You may want to introduce additional parsing to extract more metadata from your log messages,
 like severity or source code reference.
 * You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
 -->
 * 你可能需要添加更多资源，因为默认的行为表现无法满足你的需求。
 * 你可能需要引入额外的解析机制以便从日志消息中提取更多元数据，例如严重性或源代码引用。
 * 你可能想要将日志不仅仅发送到 Stackdriver 或仅将部分日志发送到 Stackdriver。
 <!--
 In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`.
 -->
 在这种情况下，你需要更改 `DaemonSet` 和 `ConfigMap` 的参数。
 <!--
 ### Prerequisites
 -->
 ### 先决条件
 <!--
 If you're using GKE and Stackdriver Logging is enabled in your cluster, you
 cannot change its configuration, because it's managed and supported by GKE.
 However, you can disable the default integration and deploy your own.
 -->
 如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，
 因为它是由 GKE 管理和支持的。
 但是，你可以禁用默认集成的日志机制并部署自己的。
 <!--
 You will have to support and maintain a newly deployed configuration
 yourself: update the image and configuration, adjust the resources and so on.
 -->
 {{< note >}}
 你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。
 {{< /note >}}
 <!--
 To disable the default logging integration, use the following command:
 -->
 若要禁用默认的日志记录集成，请使用以下命令：
 ```
 gcloud beta container clusters update --logging-service=none CLUSTER
 ```
 <!--
 You can find notes on how to then install Stackdriver Logging agents into
 a running cluster in the [Deploying section](#deploying).
 -->
 你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到
 正在运行的集群中的说明。
 <!--
 ### Changing `DaemonSet` parameters
 -->
 ### 更改 `DaemonSet` 参数    {#changing-daemonset-parameters}
 <!--
 When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the
 `template` field in its spec. The DaemonSet controller manages the pods for you.
 For example, assume you've installed the Stackdriver Logging as described above. Now you want to
 change the memory limit to give fluentd more memory to safely process more logs.
 -->
 当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的
 `template` 字段，DaemonSet 控制器将为你管理 Pod。
 例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
 现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。
 <!--
 Get the spec of `DaemonSet` running in your cluster:
 -->
 获取集群中运行的 `DaemonSet` 的 spec：
 ```shell
 kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
 ```
 <!--
 Then edit resource requirements in the spec file and update the `DaemonSet` object
 in the apiserver using the following command:
 -->
 然后在 spec 文件中编辑资源需求，并使用以下命令更新 apiserver 中的 `DaemonSet` 对象：
 ```shell
 kubectl replace -f fluentd-gcp-ds.yaml
 ```
 <!--
 After some time, Stackdriver Logging agent pods will be restarted with the new configuration.
 -->
 一段时间后，Stackdriver 日志代理的 pod 将使用新配置重新启动。
 <!--
 ### Changing fluentd parameters
 -->
 ### 更改 fluentd 参数
 <!--
 Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
 files that are merged together. You can learn about fluentd configuration on the
 [official site](https://docs.fluentd.org).
 -->
 Fluentd 的配置存在 `ConfigMap` 对象中。
 它实际上是一组合并在一起的配置文件。
 你可以在[官方网站](https://docs.fluentd.org)上了解 fluentd 的配置。
 <!--
 Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
 default Python logging format. An appropriate fluentd filter looks similar to this:
 -->
 假设你要向配置添加新的解析逻辑，以便 fluentd 可以理解默认的 Python 日志记录格式。
 一个合适的 fluentd 过滤器类似如下：
 ```
 <filter reform.**>
  type parser
  format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
  reserve_data true
  suppress_parse_error_log true
  key_name log
 </filter>
 ```
 <!--
 Now you have to put it in the configuration and make Stackdriver Logging agents pick it up.
 Get the current version of the Stackdriver Logging `ConfigMap` in your cluster
 by running the following command:
 -->
 现在，你需要将其放入配置中，并使 Stackdriver 日志代理感知它。
 通过运行以下命令，获取集群中当前版本的 Stackdriver 日志机制的 `ConfigMap`：
 ```shell
 kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
 ```
 <!--
 Then in the value of the key `containers.input.conf` insert a new filter right after
 the `source` section.
 -->
 然后在 `containers.input.conf` 键的值中，在 `source` 部分之后插入一个新的过滤器。
 <!--
 Order is important.
 -->
 {{< note >}}
 顺序很重要。
 {{< /note >}}
 <!--
 Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
 to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
 create `ConfigMap` with a new name and then change `DaemonSet` to point to it
 using [guide above](#changing-daemonset-parameters).
 -->
 在 apiserver 中更新 `ConfigMap` 比更新 `DaemonSet` 更复杂。
 最好考虑 `ConfigMap` 是不可变的。
 如果是这样，要更新配置，你应该使用新名称创建 `ConfigMap`，然后使用
 [上面的指南](#changing-daemonset-parameters)将 `DaemonSet` 更改为指向它。
 <!--
 ### Adding fluentd plugins
 -->
 ### 添加 fluentd 插件
 <!--
 Fluentd is written in Ruby and allows to extend its capabilities using
 [plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
 in the default Stackdriver Logging container image, you have to build a custom image. Imagine
 you want to add Kafka sink for messages from a particular container for additional processing.
 You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
 with minor changes:
 -->
 Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plugins) 扩展其功能。
 如果要使用默认的 Stackdriver 日志机制容器镜像中未包含的插件，则必须构建自定义镜像。
 假设你要为来自特定容器添加 Kafka 信息接收器，以进行其他处理。
 你可以复用默认的[容器镜像源](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)，并仅添加少量更改：
 <!--
 * Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
 * Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
 -->
 * 将 Makefile 更改为指向你的容器仓库，例如 `PREFIX=gcr.io/<your-project-id>`。
 * 将你的依赖项添加到 Gemfile 中，例如 `gem 'fluent-plugin-kafka'`。
 <!--
 Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
 new image, you can use the plugin you installed in the fluentd configuration.
 -->
 然后在该目录运行 `make build push`。
 在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
@@ -139,7 +139,7 @@ Removing an old version:
   If this occurs, switch back to using `served:true` on the old version, migrate the 
   remaining clients to the new version and repeat this step.
 1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed.
-    1. Verify that the `stored` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
+    1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
    1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`.
 1. Remove the old version from the CustomResourceDefinition `spec.versions` list.
 1. Drop conversion support for the old version in conversion webhooks.
@@ -156,7 +156,7 @@ Removing an old version:
 1. 确保已完成[将现有对象升级到新存储版本](#upgrade-existing-objects-to-a-new-stored-version)
   的步骤。
   1. 在 CustomResourceDefinition 的 `spec.versions` 列表中，确认新版本的
-      `stored` 已被设置为 `true`。
+      `storage` 已被设置为 `true`。
   2. 确认旧版本不在 CustomResourceDefinition `status.storedVersions` 中。
 1. 从 CustomResourceDefinition `spec.versions` 列表中删除旧版本。
 1. 在转换 Webhooks 中放弃对旧版本的转换支持。
@@ -302,7 +302,7 @@ spec:
    plural: crontabs
    # 名称的单数形式，用于在命令行接口和显示时作为其别名
    singular: crontab
-    # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中
+    # kind 通常是大驼峰编码（PascalCased）的单数形式，用于资源清单中
    kind: CronTab
    # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源
    shortNames:
@@ -1244,8 +1244,8 @@ If conversion fails, a webhook should return a `response` stanza containing the
 -->
 如果转换失败，则 Webhook 应该返回包含以下字段的 `response` 节：
-*`uid`，从发送到 Webhook 的 `request.uid` 复制而来
+* `uid`，从发送到 Webhook 的 `request.uid` 复制而来
-*`result`，设置为 `{"status": "Failed"}`
+* `result`，设置为 `{"status": "Failed"}`
 {{< warning >}}
 <!--
@@ -99,11 +99,11 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成
 <!--
 ## Clusters
-* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
 -->
 ## 集群
-* [AppArmor](/zh/docs/tutorials/clusters/apparmor/)
+* [seccomp](/zh/docs/tutorials/clusters/seccomp/)
 <!--
 ## Services
@@ -447,6 +447,15 @@ node with the required profile. -->
 <!-- ### Restricting profiles with the PodSecurityPolicy -->
 ### 使用 PodSecurityPolicy 限制配置文件
 {{< note >}}
 <!-- 
 PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25.
 See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information.
 -->
 PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版本移除。
 查看 [PodSecurityPolicy 文档](/zh/docs/concepts/policy/pod-security-policy/)获取更多信息。
 {{< /note >}}
 <!-- If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
 enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: -->
 如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。要启用 PodSecurityPolicy，必须在“apiserver”上设置以下标志：
@@ -2,6 +2,7 @@
 title: 使用 Seccomp 限制容器的系统调用
 content_type: tutorial
 weight: 20
 min-kubernetes-server-version: v1.22
 ---
 <!-- overview -->
@@ -10,7 +11,7 @@ weight: 20
 <!--
 Seccomp stands for secure computing mode and has been a feature of the Linux
-kernel since version 2.6.12.  It can be used to sandbox the privileges of a
+kernel since version 2.6.12. It can be used to sandbox the privileges of a
 process, restricting the calls it is able to make from userspace into the
 kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a
 Node to your Pods and containers.
@@ -49,20 +50,118 @@ Kubernetes 允许你将加载到节点上的 seccomp 配置文件自动应用于
 ## {{% heading "prerequisites" %}}
 {{< version-check >}}
 <!--
 In order to complete all steps in this tutorial, you must install
 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
 [kubectl](/docs/tasks/tools/). This tutorial will show examples
-with both alpha (pre-v1.19) and generally available seccomp functionality, so
+both alpha (new in v1.22) and generally available seccomp functionality. You should
 make sure that your cluster is [configured
 correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
 for the version you are using.
 -->
 为了完成本教程中的所有步骤，你必须安装 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) 
-和 [kubectl](/zh/docs/tasks/tools/)。本教程将显示同时具有 alpha（v1.19 之前的版本）
+和 [kubectl](/zh/docs/tasks/tools/)。本教程将显示同时具有 alpha（v1.22 新版本）
-和通常可用的 seccomp 功能的示例，因此请确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。
+和通常可用的 seccomp 功能的示例。
 你应该确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。
 <!-- steps -->
 <!-- 
 ## Enable the use of `RuntimeDefault` as the default seccomp profile for all workloads
 {{< feature-state state="alpha" for_k8s_version="v1.22" >}}
 `SeccompDefault` is an optional kubelet
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates) as
 well as corresponding `--seccomp-default`
 [command line flag](/docs/reference/command-line-tools-reference/kubelet).
 Both have to be enabled simultaneously to use the feature.
 -->
 ## 启用 `RuntimeDefault` 作为所有工作负载的默认 seccomp 配置文件
 {{< feature-state state="alpha" for_k8s_version="v1.22" >}}
 `SeccompDefault` 是一个可选的 kubelet
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)，
 相应地，`--seccomp-default` 是此特性门控的
 [命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)。
 必须同时启用两者才能使用该功能。
 <!-- 
 If enabled, the kubelet will use the `RuntimeDefault` seccomp profile by default, which is 
 defined by the container runtime, instead of using the `Unconfined` (seccomp disabled) mode. 
 The default profiles aim to provide a strong set
 of security defaults while preserving the functionality of the workload. It is
 possible that the default profiles differ between container runtimes and their
 release versions, for example when comparing those from CRI-O and containerd.
 -->
 如果启用，kubelet 将默认使用 `RuntimeDefault` seccomp 配置，
 而不是使用 `Unconfined`（禁用 seccomp）模式，该配置由容器运行时定义。
 默认配置旨在提供一组强大的安全默认值设置，同时避免影响工作负载的功能。
 不同的容器运行时之间及其不同的发布版本之间的默认配置可能不同，
 例如在比较 CRI-O 和 containerd 的配置文件时（就会发现这点）。
 <!-- 
 Some workloads may require a lower amount of syscall restrictions than others.
 This means that they can fail during runtime even with the `RuntimeDefault`
 profile. To mitigate such a failure, you can:
 - Run the workload explicitly as `Unconfined`.
 - Disable the `SeccompDefault` feature for the nodes. Also making sure that
  workloads get scheduled on nodes where the feature is disabled.
 - Create a custom seccomp profile for the workload.
 -->
 某些工作负载可能相比其他工作负载需要更少的系统调用限制。
 这意味着即使使用 `RuntimeDefault` 配置文件，它们也可能在运行时失败。
 要处理此类失效，你可以：
 - 将工作负载显式运行为 `Unconfined`。
 - 禁用节点的 `SeccompDefault` 功能。
  还要确保工作负载被安排在禁用该功能的节点上。
 - 为工作负载创建自定义 seccomp 配置文件。
 <!-- 
 If you were introducing this feature into production-like cluster, the Kubernetes project
 recommends that you enable this feature gate on a subset of your nodes and then
 test workload execution before rolling the change out cluster-wide.
 More detailed information about a possible upgrade and downgrade strategy can be
 found in the [related Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy).
 -->
 如果你将此功能引入到类似生产的集群中，
 Kubernetes 项目建议你在节点的子集上启用此特性门控，
 然后在集群范围内推出更改之前测试工作负载的执行情况。
 有关可能的升级和降级策略的更多详细信息，
 请参见[相关 Kubernetes 增强提案 (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy)。
 <!-- 
 Since the feature is in alpha state it is disabled per default. To enable it,
 pass the flags `--feature-gates=SeccompDefault=true --seccomp-default` to the
 `kubelet` CLI or enable it via the [kubelet configuration
 file](/docs/tasks/administer-cluster/kubelet-config-file/). To enable the
 feature gate in [kind](https://kind.sigs.k8s.io), ensure that `kind` provides
 the minimum required Kubernetes version and enables the `SeccompDefault` feature
 [in the kind configuration](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster):
 -->
 由于该功能处于 alpha 状态，因此默认情况下是被禁用的。要启用它，
 请将标志 `--feature-gates=SeccompDefault=true --seccomp-default` 
 传递给 `kubelet` CLI 或通过
 [kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)启用它。
 要在 [kind](https://kind.sigs.k8s.io) 中启用特性门控，
 请确保 `kind` 提供所需的最低 Kubernetes 版本并
 [在 kind 配置中](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster)
 启用 `SeccompDefault` 功能：
 ```yaml
 kind: Cluster
 apiVersion: kind.x-k8s.io/v1alpha4
 featureGates:
  SeccompDefault: true
 ```
 <!--
 ## Create Seccomp Profiles
@@ -151,14 +250,14 @@ audit.json  fine-grained.json  violation.json
 ```
 <!--
-## Create a Pod with a Seccomp profile for syscall auditing
+## Create a Pod with a seccomp profile for syscall auditing
 To start off, apply the `audit.json` profile, which will log all syscalls of the
 process, to a new Pod.
 Download the correct manifest for your Kubernetes version:
 -->
-## 使用 Seccomp 配置文件创建 Pod 以进行系统调用审核
+## 使用 seccomp 配置文件创建 Pod 以进行系统调用审核
 首先，将 `audit.json` 配置文件应用到新的 Pod 中，该配置文件将记录该进程的所有系统调用。
@@ -297,14 +396,14 @@ kubectl delete svc/audit-pod
 ```
 <!--
-## Create Pod with Seccomp Profile that Causes Violation
+## Create Pod with seccomp Profile that Causes Violation
 For demonstration, apply a profile to the Pod that does not allow for any
 syscalls.
 Download the correct manifest for your Kubernetes version:
 -->
-## 使用导致违规的 Seccomp 配置文件创建 Pod
+## 使用导致违规的 seccomp 配置文件创建 Pod
 为了进行演示，请将不允许任何系统调用的配置文件应用于 Pod。
@@ -364,7 +463,7 @@ kubectl delete svc/violation-pod
 ```
 <!--
-## Create Pod with Seccomp Profile that Only Allows Necessary Syscalls
+## Create Pod with seccomp Profile that Only Allows Necessary Syscalls
 If you take a look at the `fine-pod.json`, you will notice some of the syscalls
 seen in the first example where the profile set `"defaultAction":
@@ -375,7 +474,7 @@ sent to `syslog`.
 Download the correct manifest for your Kubernetes version:
 -->
-## 使用设置仅允许需要的系统调用的配置文件来创建 Pod
+## 使用设置仅允许需要的系统调用的 seccomp 配置文件来创建 Pod
 如果你看一下 `fine-pod.json` 文件，你会注意到在第一个示例中配置文件设置为 `"defaultAction": "SCMP_ACT_LOG"` 的一些系统调用。
 现在，配置文件设置为 `"defaultAction": "SCMP_ACT_ERRNO"`，但是在 `"action": "SCMP_ACT_ALLOW"` 块中明确允许一组系统调用。
@@ -482,7 +581,7 @@ kubectl delete svc/fine-pod
 ```
 <!--
-## Create Pod that uses the Container Runtime Default Seccomp Profile
+## Create Pod that uses the Container Runtime Default seccomp Profile
 Most container runtimes provide a sane set of default syscalls that are allowed
 or not. The defaults can easily be applied in Kubernetes by using the
@@ -491,7 +590,7 @@ of a pod or container to `RuntimeDefault`.
 Download the correct manifest for your Kubernetes version:
 -->
-## 使用容器运行时默认的 Seccomp 配置文件创建 Pod
+## 使用容器运行时默认的 seccomp 配置文件创建 Pod
 大多数容器运行时都提供一组允许或不允许的默认系统调用。通过使用 `runtime/default` 注释
 或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 `RuntimeDefault`，可以轻松地在 Kubernetes 中应用默认值。
@@ -518,10 +617,10 @@ The default seccomp profile should provide adequate access for most workloads.
 <!--
 Additional resources:
-* [A Seccomp Overview](https://lwn.net/Articles/656307/)
+* [A seccomp Overview](https://lwn.net/Articles/656307/)
 * [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/)
 -->
 额外的资源：
-* [Seccomp 概要](https://lwn.net/Articles/656307/)
+* [seccomp 概要](https://lwn.net/Articles/656307/)
 * [Seccomp 在 Docker 中的安全配置](https://docs.docker.com/engine/security/seccomp/)
@@ -79,7 +79,7 @@ Apply the ConfigMap created above, along with a Redis pod manifest:
 ```shell
 kubectl apply -f example-redis-config.yaml
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://k8s.io/examples/pods/config/redis-pod.yaml
 ```
 <!--
@@ -298,7 +298,7 @@ values from associated ConfigMaps. Let's delete and recreate the Pod:
 ```shell
 kubectl delete pod redis
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://k8s.io/examples/pods/config/redis-pod.yaml
 ```
 <!--
@@ -110,19 +110,32 @@ This tutorial provides a container image that uses NGINX to echo back all the re
 4. 仅限 Katacoda 环境：输入“30000”，然后单击 **显示端口**。
 <!--
-The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service.
+The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. 
 You can create Kubernetes resources on the dashboard such as Deployment and Service.
 If you are running in an environment as root, see [Open Dashboard with URL](#open-dashboard-with-url).
-To stop the proxy, run `Ctrl+C` to exit the process. The dashboard remains running.
+By default, the dashboard is only accessible from within the internal Kubernetes virtual network.
 The `dashboard` command creates a temporary proxy to make the dashboard accessible from outside the Kubernetes virtual network.
 To stop the proxy, run `Ctrl+C` to exit the process.
 After the command exits, the dashboard remains running in Kubernetes cluster.
 You can run the `dashboard` command again to create another proxy to access the dashboard.
 -->
 {{< note >}}
-`dashboard` 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。
+`dashboard` 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。
 你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。
 如果你以 root 用户身份在环境中运行，
 请参见[使用 URL 打开仪表板](#open-dashboard-with-url)。
 默认情况下，仪表板只能从内部 Kubernetes 虚拟网络中访问。
 `dashboard` 命令创建一个临时代理，使仪表板可以从 Kubernetes 虚拟网络外部访问。
 要停止代理，请运行 `Ctrl+C` 退出该进程。仪表板仍在运行中。
 命令退出后，仪表板仍然在 Kubernetes 集群中运行。
 你可以再次运行 `dashboard` 命令创建另一个代理来访问仪表板。
 {{< /note >}}
 <!--
@@ -387,7 +400,7 @@ Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons"
   输出结果类似于这样：
   ```
-   metrics-server was successfully enabled
+   The 'metrics-server' addon is enabled
   ```
 <!--
@@ -1239,16 +1239,16 @@ kubectl get pods -w -l app=nginx
 <!--
 Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the
-StatefulSet. Make sure to supply the `--cascade=false` parameter to the
+StatefulSet. Make sure to supply the `--cascade=orphan` parameter to the
 command. This parameter tells Kubernetes to only delete the StatefulSet, and to
 not delete any of its Pods.
 -->
 使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet。
-请确保提供了 `--cascade=false` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。
+请确保提供了 `--cascade=orphan` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。
 ```shell
-kubectl delete statefulset web --cascade=false
+kubectl delete statefulset web --cascade=orphan
 ```
 ```
 statefulset.apps "web" deleted
@@ -1416,9 +1416,10 @@ kubectl get pods -w -l app=nginx
 <!--
 In another terminal, delete the StatefulSet again. This time, omit the
 `--cascade=orphan` parameter.
 -->
-在另一个窗口中再次删除这个 StatefulSet。这次省略 `--cascade=false` 参数。
+在另一个窗口中再次删除这个 StatefulSet。这次省略 `--cascade=orphan` 参数。
 ```shell
 kubectl delete statefulset web
@@ -87,14 +87,14 @@ To complete this tutorial, you should already have a basic familiarity with
 ### Additional Minikube setup instructions
 {{< caution >}}
-[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU.
+[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 2048MB of memory and 2 CPU.
 Running Minikube with the default resource configuration results in insufficient resource
 errors during this tutorial. To avoid these errors, start Minikube with the following settings:
 -->
 ### 额外的 Minikube 设置说明
 {{< caution >}}
-[Minikube](https://minikube.sigs.k8s.io/docs/)默认为 1024MiB 内存和 1 个 CPU。
+[Minikube](https://minikube.sigs.k8s.io/docs/)默认为 2048MB 内存和 2 个 CPU。
 在本教程中，使用默认资源配置运行 Minikube 会导致资源不足的错误。为避免这些错误，请使用以下设置启动 Minikube：
 ```shell
--- a/Show More
+++ b/Show More
`@@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can`



	`Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/). `	`Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-). `
`@@ -24,4 +24,4 @@ Więcej informacji można z znaleźć w dokumencie [version skew policy](/releas`

	`Zajrzyj na [harmonogram](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) nadchodzącego wydania Kubernetesa numer {{< skew nextMinorVersion >}}!`	`Zajrzyj na [harmonogram](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) nadchodzącego wydania Kubernetesa numer {{< skew nextMinorVersion >}}!`

	`## Przydatne zasoby`	`## Przydatne zasoby`