Merge branch 'main' into feature/docs-tools-kubectl-macos

2023-04-26 21:47:46 +02:00 · 2023-04-26 21:47:46 +02:00 · 603018575b
parent 9ec08bf2d3 770b345343
commit 603018575b
11 changed files with 865 additions and 279 deletions
--- a/2
+++ b/2
@ -167,7 +167,6 @@ aliases:
    - edsoncelio
    - femrtnz
    - jcjesus
-    - rikatz
    - stormqueen1990
    - yagonobre
  sig-docs-pt-reviews: # PR reviews for Portugese content
@ -176,7 +175,6 @@ aliases:
    - femrtnz
    - jcjesus
    - mrerlison
-    - rikatz
    - stormqueen1990
    - yagonobre
  sig-docs-vi-owners: # Admins for Vietnamese content
--- a/content/en/blog/_posts/2022-12-27-cpumanager-goes-GA.md
+++ b/content/en/blog/_posts/2022-12-27-cpumanager-goes-GA.md
@ -40,7 +40,7 @@ compatible behavior when disabled, and to document how to interact with each oth

 This enabled the Kubernetes project to graduate to GA the CPU Manager core component and core CPU allocation algorithms to GA,
 while also enabling a new age of experimentation in this area.
-In Kubernetes v1.26, the CPU Manager supports [three different policy options](/docs/tasks/administer-cluster/cpu-management-policies.md#static-policy-options):
+In Kubernetes v1.26, the CPU Manager supports [three different policy options](/docs/tasks/administer-cluster/cpu-management-policies#static-policy-options):

 `full-pcpus-only`
 : restrict the CPU Manager core allocation algorithm to full physical cores only, reducing noisy neighbor issues from hardware technologies that allow sharing cores.
--- a/content/en/blog/_posts/2023-04-28-statefulset-migration.md
+++ b/content/en/blog/_posts/2023-04-28-statefulset-migration.md
@ -0,0 +1,223 @@
+---
+layout: blog
+title: "Kubernetes 1.27: StatefulSet Start Ordinal Simplifies Migration"
+date: 2023-04-28
+slug: statefulset-start-ordinal
+---
+
+**Author**: Peter Schuurman (Google)
+
+Kubernetes v1.26 introduced a new, alpha-level feature for
+[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) that controls
+the ordinal numbering of Pod replicas. As of Kubernetes v1.27, this feature is
+now beta. Ordinals can start from arbitrary
+non-negative numbers. This blog post will discuss how this feature can be
+used.
+
+## Background
+
+StatefulSets ordinals provide sequential identities for pod replicas. When using
+[`OrderedReady` Pod management](/docs/tutorials/stateful-application/basic-stateful-set/#orderedready-pod-management)
+Pods are created from ordinal index `0` up to `N-1`.
+
+With Kubernetes today, orchestrating a StatefulSet migration across clusters is
+challenging. Backup and restore solutions exist, but these require the
+application to be scaled down to zero replicas prior to migration. In today's
+fully connected world, even planned application downtime may not allow you to
+meet your business goals. You could use
+[Cascading Delete](/docs/tutorials/stateful-application/basic-stateful-set/#cascading-delete)
+or
+[On Delete](/docs/tutorials/stateful-application/basic-stateful-set/#on-delete)
+to migrate individual pods, however this is error prone and tedious to manage.
+You lose the self-healing benefit of the StatefulSet controller when your Pods
+fail or are evicted.
+
+Kubernetes v1.26 enables a StatefulSet to be responsible for a range of ordinals
+within a range {0..N-1} (the ordinals 0, 1, ... up to N-1).
+With it, you can scale down a range
+{0..k-1} in a source cluster, and scale up the complementary range {k..N-1}
+in a destination cluster, while maintaining application availability. This
+enables you to retain *at most one* semantics (meaning there is at most one Pod
+with a given identity running in a StatefulSet) and
+[Rolling Update](/docs/tutorials/stateful-application/basic-stateful-set/#rolling-update)
+behavior when orchestrating a migration across clusters.
+
+## Why would I want to use this feature?
+
+Say you're running your StatefulSet in one cluster, and need to migrate it out
+to a different cluster. There are many reasons why you would need to do this:
+ * **Scalability**: Your StatefulSet has scaled too large for your cluster, and
+   has started to disrupt the quality of service for other workloads in your
+   cluster.
+ * **Isolation**: You're running a StatefulSet in a cluster that is accessed 
+   by multiple users, and namespace isolation isn't sufficient.
+ * **Cluster Configuration**: You want to move your StatefulSet to a different
+   cluster to use some environment that is not available on your current
+   cluster.
+ * **Control Plane Upgrades**: You want to move your StatefulSet to a cluster
+   running an upgraded control plane, and can't handle the risk or downtime of
+   in-place control plane upgrades.
+
+## How do I use it?
+
+Enable the `StatefulSetStartOrdinal` feature gate on a cluster, and create a
+StatefulSet with a customized `.spec.ordinals.start`.
+
+## Try it out
+
+In this demo, I'll use the new mechanism to migrate a
+StatefulSet from one Kubernetes cluster to another. The
+[redis-cluster](https://github.com/bitnami/charts/tree/main/bitnami/redis-cluster)
+Bitnami Helm chart will be used to install Redis.
+
+Tools Required:
+ * [yq](https://github.com/mikefarah/yq)
+ * [helm](https://helm.sh/docs/helm/helm_install/)
+
+### Pre-requisites {#demo-pre-requisites}
+
+To do this, I need two Kubernetes clusters that can both access common
+networking and storage; I've named my clusters `source` and `destination`.
+Specifically, I need:
+
+* The `StatefulSetStartOrdinal` feature gate enabled on both clusters.
+* Client configuration for `kubectl` that lets me access both clusters as an
+  administrator.
+* The same `StorageClass` installed on both clusters, and set as the default
+  StorageClass for both clusters. This `StorageClass` should provision
+  underlying storage that is accessible from either or both clusters.
+* A flat network topology that allows for pods to send and receive packets to
+  and from Pods in either clusters. If you are creating clusters on a cloud
+  provider, this configuration may be called private cloud or private network.
+
+1. Create a demo namespace on both clusters:
+
+   ```
+   kubectl create ns kep-3335
+   ```
+
+2. Deploy a Redis cluster with six replicas in the source cluster:
+
+   ```
+   helm repo add bitnami https://charts.bitnami.com/bitnami
+   helm install redis --namespace kep-3335 \
+     bitnami/redis-cluster \
+     --set persistence.size=1Gi \
+     --set cluster.nodes=6
+   ```
+
+3. Check the replication status in the source cluster:
+
+   ```
+   kubectl exec -it redis-redis-cluster-0 -- /bin/bash -c \
+     "redis-cli -c -h redis-redis-cluster -a $(kubectl get secret redis-redis-cluster -o jsonpath="{.data.redis-password}" | base64 -d) CLUSTER NODES;"
+   ```
+
+   ```
+   2ce30362c188aabc06f3eee5d92892d95b1da5c3 10.104.0.14:6379@16379 myself,master - 0 1669764411000 3 connected 10923-16383                                                                                                                                              
+   7743661f60b6b17b5c71d083260419588b4f2451 10.104.0.16:6379@16379 slave 2ce30362c188aabc06f3eee5d92892d95b1da5c3 0 1669764410000 3 connected                                                                                             
+   961f35e37c4eea507cfe12f96e3bfd694b9c21d4 10.104.0.18:6379@16379 slave a8765caed08f3e185cef22bd09edf409dc2bcc61 0 1669764411000 1 connected                                                                                                             
+   7136e37d8864db983f334b85d2b094be47c830e5 10.104.0.15:6379@16379 slave 2cff613d763b22c180cd40668da8e452edef3fc8 0 1669764412595 2 connected                                                                                                                    
+   a8765caed08f3e185cef22bd09edf409dc2bcc61 10.104.0.19:6379@16379 master - 0 1669764411592 1 connected 0-5460                                                                                                                                                   
+   2cff613d763b22c180cd40668da8e452edef3fc8 10.104.0.17:6379@16379 master - 0 1669764410000 2 connected 5461-10922
+   ```
+
+4. Deploy a Redis cluster with zero replicas in the destination cluster:
+
+   ```
+   helm install redis --namespace kep-3335 \
+     bitnami/redis-cluster \
+     --set persistence.size=1Gi \
+     --set cluster.nodes=0 \
+     --set redis.extraEnvVars\[0\].name=REDIS_NODES,redis.extraEnvVars\[0\].value="redis-redis-cluster-headless.kep-3335.svc.cluster.local" \
+     --set existingSecret=redis-redis-cluster
+   ```
+
+5. Scale down the `redis-redis-cluster` StatefulSet in the source cluster by 1,
+   to remove the replica `redis-redis-cluster-5`:
+
+   ```
+   kubectl patch sts redis-redis-cluster -p '{"spec": {"replicas": 5}}'
+   ```
+
+6. Migrate dependencies from the source cluster to the destination cluster:
+
+   The following commands copy resources from `source` to `destionation`. Details
+   that are not relevant in `destination` cluster are removed (eg: `uid`,
+   `resourceVersion`, `status`).
+
+   **Steps for the source cluster**
+
+   Note: If using a `StorageClass` with `reclaimPolicy: Delete` configured, you
+         should patch the PVs in `source` with `reclaimPolicy: Retain` prior to
+         deletion to retain the underlying storage used in `destination`. See
+         [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)
+         for more details.
+
+   ```
+   kubectl get pvc redis-data-redis-redis-cluster-5 -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.annotations, .metadata.finalizers, .status)' > /tmp/pvc-redis-data-redis-redis-cluster-5.yaml
+   kubectl get pv $(yq '.spec.volumeName' /tmp/pvc-redis-data-redis-redis-cluster-5.yaml) -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.annotations, .metadata.finalizers, .spec.claimRef, .status)' > /tmp/pv-redis-data-redis-redis-cluster-5.yaml
+   kubectl get secret redis-redis-cluster -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion)' > /tmp/secret-redis-redis-cluster.yaml
+   ```
+
+   **Steps for the destination cluster**
+
+   Note: For the PV/PVC, this procedure only works if the underlying storage system
+         that your PVs use can support being copied into `destination`. Storage
+         that is associated with a specific node or topology may not be supported.
+         Additionally, some storage systems may store addtional metadata about
+         volumes outside of a PV object, and may require a more specialized
+         sequence to import a volume.
+
+   ```
+   kubectl create -f /tmp/pv-redis-data-redis-redis-cluster-5.yaml
+   kubectl create -f /tmp/pvc-redis-data-redis-redis-cluster-5.yaml
+   kubectl create -f /tmp/secret-redis-redis-cluster.yaml
+   ```
+
+7. Scale up the `redis-redis-cluster` StatefulSet in the destination cluster by
+   1, with a start ordinal of 5:
+
+   ```
+   kubectl patch sts redis-redis-cluster -p '{"spec": {"ordinals": {"start": 5}, "replicas": 1}}'
+   ```
+
+8. Check the replication status in the destination cluster:
+
+   ```
+   kubectl exec -it redis-redis-cluster-5 -- /bin/bash -c \
+     "redis-cli -c -h redis-redis-cluster -a $(kubectl get secret redis-redis-cluster -o jsonpath="{.data.redis-password}" | base64 -d) CLUSTER NODES;"
+   ```
+
+   I should see that the new replica (labeled `myself`) has joined the Redis
+   cluster (the IP address belongs to a different CIDR block than the
+   replicas in the source cluster).
+
+   ```
+   2cff613d763b22c180cd40668da8e452edef3fc8 10.104.0.17:6379@16379 master - 0 1669766684000 2 connected 5461-10922
+   7136e37d8864db983f334b85d2b094be47c830e5 10.108.0.22:6379@16379 myself,slave 2cff613d763b22c180cd40668da8e452edef3fc8 0 1669766685609 2 connected
+   2ce30362c188aabc06f3eee5d92892d95b1da5c3 10.104.0.14:6379@16379 master - 0 1669766684000 3 connected 10923-16383
+   961f35e37c4eea507cfe12f96e3bfd694b9c21d4 10.104.0.18:6379@16379 slave a8765caed08f3e185cef22bd09edf409dc2bcc61 0 1669766683600 1 connected
+   a8765caed08f3e185cef22bd09edf409dc2bcc61 10.104.0.19:6379@16379 master - 0 1669766685000 1 connected 0-5460
+   7743661f60b6b17b5c71d083260419588b4f2451 10.104.0.16:6379@16379 slave 2ce30362c188aabc06f3eee5d92892d95b1da5c3 0 1669766686613 3 connected
+   ```
+
+9. Repeat steps #5 to #7 for the remainder of the replicas, until the
+   Redis StatefulSet in the source cluster is scaled to 0, and the Redis
+   StatefulSet in the destination cluster is healthy with 6 total replicas.
+
+## What's Next?
+
+This feature provides a building block for a StatefulSet to be split up across
+clusters, but does not prescribe the mechanism as to how the StatefulSet should
+be migrated. Migration requires coordination of StatefulSet replicas, along with
+orchestration of the storage and network layer. This is dependent on the storage
+and connectivity requirements of the application installed by the StatefulSet.
+Additionally, many StatefulSets are managed by
+[operators](/docs/concepts/extend-kubernetes/operator/), which adds another
+layer of complexity to migration.
+
+If you're interested in building enhancements to make these processes easier,
+get involved with
+[SIG Multicluster](https://github.com/kubernetes/community/blob/master/sig-multicluster)
+to contribute!
--- a/content/en/blog/_posts/2023-05-08-volume-group-snapshot-alpha.md
+++ b/content/en/blog/_posts/2023-05-08-volume-group-snapshot-alpha.md
@ -0,0 +1,285 @@
+---
+layout: blog
+title: "Kubernetes 1.27: Introducing An API For Volume Group Snapshots"
+date: 2023-05-08
+slug: kubernetes-1-27-volume-group-snapshot-alpha
+---
+
+**Author:** Xing Yang (VMware)
+
+Volume group snapshot is introduced as an Alpha feature in Kubernetes v1.27.
+This feature introduces a Kubernetes API that allows users to take crash consistent
+snapshots for multiple volumes together. It uses a label selector to group multiple
+`PersistentVolumeClaims` for snapshotting.
+This new feature is only supported for [CSI](https://kubernetes-csi.github.io/docs/) volume drivers.
+
+## An overview of volume group snapshots
+
+Some storage systems provide the ability to create a crash consistent snapshot of
+multiple volumes. A group snapshot represents “copies” from multiple volumes that
+are taken at the same point-in-time. A group snapshot can be used either to rehydrate
+new volumes (pre-populated with the snapshot data) or to restore existing volumes to
+a previous state (represented by the snapshots).
+
+## Why add volume group snapshots to Kubernetes?
+
+The Kubernetes volume plugin system already provides a powerful abstraction that
+automates the provisioning, attaching, mounting, resizing, and snapshotting of block
+and file storage.
+
+Underpinning all these features is the Kubernetes goal of workload portability:
+Kubernetes aims to create an abstraction layer between distributed applications and
+underlying clusters so that applications can be agnostic to the specifics of the
+cluster they run on and application deployment requires no cluster specific knowledge.
+
+There is already a [VolumeSnapshot](/docs/concepts/storage/volume-snapshots/) API
+that provides the ability to take a snapshot of a persistent volume to protect against
+data loss or data corruption. However, there are other snapshotting functionalities
+not covered by the VolumeSnapshot API.
+
+Some storage systems support consistent group snapshots that allow a snapshot to be
+taken from multiple volumes at the same point-in-time to achieve write order consistency.
+This can be useful for applications that contain multiple volumes. For example,
+an application may have data stored in one volume and logs stored in another volume.
+If snapshots for the data volume and the logs volume are taken at different times,
+the application will not be consistent and will not function properly if it is restored
+from those snapshots when a disaster strikes.
+
+It is true that you can quiesce the application first, take an individual snapshot from
+each volume that is part of the application one after the other, and then unquiesce the
+application after all the individual snapshots are taken. This way, you would get
+application consistent snapshots.
+
+However, sometimes it may not be possible to quiesce an application or the application
+quiesce can be too expensive so you want to do it less frequently. Taking individual
+snapshots one after another may also take longer time compared to taking a consistent
+group snapshot. Some users may not want to do application quiesce very often for these
+reasons. For example, a user may want to run weekly backups with application quiesce
+and nightly backups without application quiesce but with consistent group support which
+provides crash consistency across all volumes in the group.
+
+## Kubernetes Volume Group Snapshots API
+
+Kubernetes Volume Group Snapshots introduce [three new API
+objects](https://github.com/kubernetes-csi/external-snapshotter/blob/master/client/apis/volumegroupsnapshot/v1alpha1/types.go)
+for managing snapshots:
+
+`VolumeGroupSnapshot`
+: Created by a Kubernetes user (or perhaps by your own automation) to request
+creation of a volume group snapshot for multiple persistent volume claims.
+It contains information about the volume group snapshot operation such as the
+timestamp when the volume group snapshot was taken and whether it is ready to use.
+The creation and deletion of this object represents a desire to create or delete a
+cluster resource (a group snapshot).
+
+`VolumeGroupSnapshotContent`
+: Created by the snapshot controller for a dynamically created VolumeGroupSnapshot.
+It contains information about the volume group snapshot including the volume group
+snapshot ID.
+This object represents a provisioned resource on the cluster (a group snapshot).
+The VolumeGroupSnapshotContent object binds to the VolumeGroupSnapshot for which it
+was created with a one-to-one mapping.
+
+`VolumeGroupSnapshotClass`
+: Created by cluster administrators to describe how volume group snapshots should be
+created. including the driver information, the deletion policy, etc.
+
+These three API kinds are defined as CustomResourceDefinitions (CRDs).
+These CRDs must be installed in a Kubernetes cluster for a CSI Driver to support
+volume group snapshots.
+
+## How do I use Kubernetes Volume Group Snapshots
+
+Volume group snapshots are implemented in the
+[external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter) repository. Implementing volume
+group snapshots meant adding or changing several components:
+
+* Added new CustomResourceDefinitions for VolumeGroupSnapshot and two supporting APIs.
+* Volume group snapshot controller logic is added to the common snapshot controller.
+* Volume group snapshot validation webhook logic is added to the common snapshot validation webhook.
+* Adding logic to make CSI calls into the snapshotter sidecar controller.
+
+The volume snapshot controller, CRDs, and validation webhook are deployed once per
+cluster, while the sidecar is bundled with each CSI driver.
+
+Therefore, it makes sense to deploy the volume snapshot controller, CRDs, and validation
+webhook as a cluster addon. I strongly recommend that Kubernetes distributors
+bundle and deploy the volume snapshot controller, CRDs, and validation webhook as part
+of their Kubernetes cluster management process (independent of any CSI Driver).
+
+### Creating a new group snapshot with Kubernetes
+
+Once a VolumeGroupSnapshotClass object is defined and you have volumes you want to
+snapshot together, you may request a new group snapshot by creating a VolumeGroupSnapshot
+object.
+
+The source of the group snapshot specifies whether the underlying group snapshot
+should be dynamically created or if a pre-existing VolumeGroupSnapshotContent
+should be used.
+
+A pre-existing VolumeGroupSnapshotContent is created by a cluster administrator.
+It contains the details of the real volume group snapshot on the storage system which
+is available for use by cluster users.
+
+One of the following members in the source of the group snapshot must be set.
+
+* `selector` - a label query over PersistentVolumeClaims that are to be grouped
+  together for snapshotting. This labelSelector will be used to match the label
+  added to a PVC.
+* `volumeGroupSnapshotContentName` - specifies the name of a pre-existing
+  VolumeGroupSnapshotContent object representing an existing volume group snapshot.
+
+In the following example, there are two PVCs.
+
+```yaml
+NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
+pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
+pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
+```
+
+Label the PVCs.
+```yaml
+% kubectl label pvc pvc-0 group=myGroup
+persistentvolumeclaim/pvc-0 labeled
+
+% kubectl label pvc pvc-1 group=myGroup
+persistentvolumeclaim/pvc-1 labeled
+```
+
+For dynamic provisioning, a selector must be set so that the snapshot controller can
+find PVCs with the matching labels to be snapshotted together.
+
+```yaml
+apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
+kind: VolumeGroupSnapshot
+metadata:
+  name: new-group-snapshot-demo
+  namespace: demo-namespace
+spec:
+  volumeGroupSnapshotClassName: csi-groupSnapclass
+  source:
+    selector:
+      matchLabels:
+        group: myGroup
+```
+
+In the VolumeGroupSnapshot spec, a user can specify the VolumeGroupSnapshotClass which
+has the information about which CSI driver should be used for creating the group snapshot.
+
+Two individual volume snapshots will be created as part of the volume group snapshot creation.
+
+```yaml
+snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2:20:4
+snapshot-2026811eb9f0787466171fe189c805a22cdb61a326235cd067dc3a1ac0104900-2023-04-26-2:20:4
+```
+
+### How to use group snapshot for restore in Kubernetes
+
+At restore time, the user can request a new PersistentVolumeClaim to be created from
+a VolumeSnapshot object that is part of a VolumeGroupSnapshot. This will trigger
+provisioning of a new volume that is pre-populated with data from the specified
+snapshot. The user should repeat this until all volumes are created from all the
+snapshots that are part of a group snapshot.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: pvc0-restore
+  namespace: demo-namespace
+spec:
+  storageClassName: csi-hostpath-sc
+  dataSource:
+    name: snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2:20:4
+    kind: VolumeSnapshot
+    apiGroup: snapshot.storage.k8s.io
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+```
+
+## As a storage vendor, how do I add support for group snapshots to my CSI driver?
+
+To implement the volume group snapshot feature, a CSI driver **must**:
+
+* Implement a new group controller service.
+* Implement group controller RPCs: `CreateVolumeGroupSnapshot`, `DeleteVolumeGroupSnapshot`, and `GetVolumeGroupSnapshot`.
+* Add group controller capability `CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT`.
+
+See the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/)
+for more details.
+
+a CSI Volume Driver as possible, it provides a suggested mechanism to deploy a
+containerized CSI driver to simplify the process.
+
+As part of this recommended deployment process, the Kubernetes team provides a number of
+sidecar (helper) containers, including the
+[external-snapshotter sidecar container](https://kubernetes-csi.github.io/docs/external-snapshotter.html)
+which has been updated to support volume group snapshot.
+
+The external-snapshotter watches the Kubernetes API server for the
+`VolumeGroupSnapshotContent` object and triggers `CreateVolumeGroupSnapshot` and
+`DeleteVolumeGroupSnapshot` operations against a CSI endpoint.
+
+## What are the limitations?
+
+The alpha implementation of volume group snapshots for Kubernetes has the following
+limitations:
+
+* Does not support reverting an existing PVC to an earlier state represented by
+  a snapshot (only supports provisioning a new volume from a snapshot).
+* No application consistency guarantees beyond any guarantees provided by the storage system
+  (e.g. crash consistency). See this [doc](https://github.com/kubernetes/community/blob/master/wg-data-protection/data-protection-workflows-white-paper.md#quiesce-and-unquiesce-hooks)
+  for more discussions on application consistency.
+
+## What’s next?
+
+Depending on feedback and adoption, the Kubernetes team plans to push the CSI
+Group Snapshot implementation to Beta in either 1.28 or 1.29.
+Some of the features we are interested in supporting include volume replication,
+replication group, volume placement, application quiescing, changed block tracking, and more.
+
+## How can I learn more?
+
+- The [design spec](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/3476-volume-group-snapshot)
+  for the volume group snapshot feature.
+- The [code repository](https://github.com/kubernetes-csi/external-snapshotter) for volume group
+  snapshot APIs and controller.
+- CSI [documentation](https://kubernetes-csi.github.io/docs/) on the group snapshot feature.
+
+## How do I get involved?
+
+This project, like all of Kubernetes, is the result of hard work by many contributors
+from diverse backgrounds working together. On behalf of SIG Storage, I would like to
+offer a huge thank you to the contributors who stepped up these last few quarters
+to help the project reach alpha:
+
+* Alex Meade ([ameade](https://github.com/ameade))
+* Ben Swartzlander ([bswartz](https://github.com/bswartz))
+* Humble Devassy Chirammal ([humblec](https://github.com/humblec))
+* James Defelice ([jdef](https://github.com/jdef))
+* Jan Šafránek ([jsafrane](https://github.com/jsafrane))
+* Jing Xu ([jingxu97](https://github.com/jingxu97))
+* Michelle Au ([msau42](https://github.com/msau42))
+* Niels de Vos ([nixpanic](https://github.com/nixpanic))
+* Rakshith R ([Rakshith-R](https://github.com/Rakshith-R))
+* Raunak Shah ([RaunakShah](https://github.com/RaunakShah))
+* Saad Ali ([saad-ali](https://github.com/saad-ali))
+* Thomas Watson ([rbo54](https://github.com/rbo54))
+* Xing Yang ([xing-yang](https://github.com/xing-yang))
+* Yati Padia ([yati1998](https://github.com/yati1998))
+
+We also want to thank everyone else who has contributed to the project, including others 
+who helped review the [KEP](https://github.com/kubernetes/enhancements/pull/1551)
+and the [CSI spec PR](https://github.com/container-storage-interface/spec/pull/519).
+
+For those interested in getting involved with the design and development of CSI or
+any part of the Kubernetes Storage system, join the
+[Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
+We always welcome new contributors.
+
+We also hold regular [Data Protection Working Group meetings](https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#).
+New attendees are welcome to join our discussions.
--- a/content/en/docs/reference/scheduling/config.md
+++ b/content/en/docs/reference/scheduling/config.md
@ -20,8 +20,7 @@ by implementing one or more of these extension points.

 You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
 using the
-KubeSchedulerConfiguration ([v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
-or [v1](/docs/reference/config-api/kube-scheduler-config.v1/))
+KubeSchedulerConfiguration [v1](/docs/reference/config-api/kube-scheduler-config.v1/)
 struct.

 A minimal configuration looks as follows:
@ -35,9 +34,10 @@ clientConnection:

  {{< note >}}
  KubeSchedulerConfiguration [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
-  is deprecated in v1.25 and will be removed in v1.26. Please migrate KubeSchedulerConfiguration to
-  [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/) or [v1](/docs/reference/config-api/kube-scheduler-config.v1/)
-  before upgrading Kubernetes to v1.25.
+  is deprecated in v1.25 and will be removed in v1.28. 
+  KubeSchedulerConfiguration [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+  is deprecated in v1.26 and will be removed in v1.29.
+  Please migrate KubeSchedulerConfiguration to [v1](/docs/reference/config-api/kube-scheduler-config.v1/).
  {{< /note >}}
 ## Profiles

--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@ -38,7 +38,7 @@ weight: 270
  clusters. Therefore, run etcd clusters on dedicated machines or isolated
  environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/).

-* The minimum recommended version of etcd to run in production is `3.2.10+`.
+* The minimum recommended etcd versions to run in production are `3.4.22+` and `3.5.6+`.

 ## Resource requirements

--- a/content/zh-cn/blog/_posts/2022-12-27-cpumanager-goes-GA.md
+++ b/content/zh-cn/blog/_posts/2022-12-27-cpumanager-goes-GA.md
@ -88,11 +88,11 @@ compatible behavior when disabled, and to document how to interact with each oth
 <!--
 This enabled the Kubernetes project to graduate to GA the CPU Manager core component and core CPU allocation algorithms to GA,
 while also enabling a new age of experimentation in this area.
-In Kubernetes v1.26, the CPU Manager supports [three different policy options](/docs/tasks/administer-cluster/cpu-management-policies.md#static-policy-options):
+In Kubernetes v1.26, the CPU Manager supports [three different policy options](/docs/tasks/administer-cluster/cpu-management-policies#static-policy-options):
 -->
 这使得 Kubernetes 项目能够将 CPU 管理器核心组件和核心 CPU 分配算法进阶至 GA，同时也开启了该领域新的实验时代。
 在 Kubernetes v1.26 中，CPU
-管理器支持[三个不同的策略选项](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies.md#static-policy-options)：
+管理器支持[三个不同的策略选项](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies#static-policy-options)：

 <!--
 `full-pcpus-only`
--- a/content/zh-cn/docs/concepts/services-networking/service-topology.md
+++ b/content/zh-cn/docs/concepts/services-networking/service-topology.md
@ -20,12 +20,12 @@ weight: 150
 <!--
 This feature, specifically the alpha `topologyKeys` API, is deprecated since
 Kubernetes v1.21.
-[Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/),
+[Topology Aware Routing](/docs/concepts/services-networking/topology-aware-routing/),
 introduced in Kubernetes v1.21, provide similar functionality.
 -->
 此功能特性，尤其是 Alpha 阶段的 `topologyKeys` API，在 Kubernetes v1.21
 版本中已被废弃。Kubernetes v1.21 版本中引入的
-[拓扑感知的提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/),
+[拓扑感知路由](/zh-cn/docs/concepts/services-networking/topology-aware-routing/),
 提供类似的功能。
 {{</ note >}}

--- a/content/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers.md
@ -3,8 +3,14 @@ title: 动态准入控制
 content_type: concept
 weight: 40
 ---
-
 <!--
+reviewers:
+- smarterclayton
+- lavalamp
+- caesarxuchao
+- deads2k
+- liggitt
+- jpbetz
 title: Dynamic Admission Control
 content_type: concept
 weight: 40
@ -21,6 +27,7 @@ This page describes how to build, configure, use, and monitor admission webhooks
 此页面描述了如何构建、配置、使用和监视准入 Webhook。

 <!-- body -->
+
 <!--
 ## What are admission webhooks?
 -->
@ -29,16 +36,16 @@ This page describes how to build, configure, use, and monitor admission webhooks
 <!--
 Admission webhooks are HTTP callbacks that receive admission requests and do
 something with them. You can define two types of admission webhooks,
-[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
+[validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
 and
 [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
-Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
+Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
 -->
 准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
 可以定义两种类型的准入 webhook，即
 [验证性质的准入 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和
 [修改性质的准入 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
-修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API 
+修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API
 服务器的对象以执行自定义的设置默认值操作。

 <!--
@ -48,24 +55,25 @@ validating admission webhooks are invoked and can reject requests to enforce cus
 在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，
 验证性质的 Webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。

+{{< note >}}
 <!--
 Admission webhooks that need to guarantee they see the final state of the object in order to enforce policy
 should use a validating admission webhook, since objects can be modified after being seen by mutating webhooks.
 -->
-{{< note >}}
 如果准入 Webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。
 则应使用验证性质的准入 Webhook，因为对象被修改性质 Webhook 看到之后仍然可能被修改。
 {{< /note >}}

 <!--
-### Experimenting with admission webhooks
+## Experimenting with admission webhooks

-write and deploy them with great caution. Please read the [user
-guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) for
-instructions if you intend to write/deploy production-grade admission webhooks.
+Admission webhooks are essentially part of the cluster control-plane. You should
+write and deploy them with great caution. Please read the
+[user guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)
+for instructions if you intend to write/deploy production-grade admission webhooks.
 In the following, we describe how to quickly experiment with admission webhooks.
 -->
-### 尝试准入 Webhook {#experimenting-with-admission-webhooks}
+## 尝试准入 Webhook {#experimenting-with-admission-webhooks}

 准入 Webhook 本质上是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。
 如果你打算编写或者部署生产级准入 webhook，请阅读[用户指南](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
@ -101,19 +109,19 @@ that is validated in a Kubernetes e2e test. The webhook handles the
 as an `AdmissionReview` object in the same version it received.
 -->
 请参阅 Kubernetes e2e 测试中的
-[admission webhook 服务器](https://github.com/kubernetes/kubernetes/blob/release-1.21/test/images/agnhost/webhook/main.go)
+[Admission Webhook 服务器](https://github.com/kubernetes/kubernetes/blob/release-1.21/test/images/agnhost/webhook/main.go)
 的实现。webhook 处理由 API 服务器发送的 `AdmissionReview` 请求，并且将其决定
 作为 `AdmissionReview` 对象以相同版本发送回去。

 <!--
 See the [webhook request](#request) section for details on the data sent to webhooks.
 -->
-有关发送到 webhook 的数据的详细信息，请参阅 [webhook 请求](#request)。
+有关发送到 Webhook 的数据的详细信息，请参阅 [Webhook 请求](#request)。

 <!--
 See the [webhook response](#response) section for the data expected from webhooks.
 -->
-要获取来自 webhook 的预期数据，请参阅 [webhook 响应](#response)。
+要获取来自 Webhook 的预期数据，请参阅 [Webhook 响应](#response)。

 <!--
 The example admission webhook server leaves the `ClientAuth` field
@ -125,7 +133,7 @@ how to [authenticate API servers](#authenticate-apiservers).
 -->
 示例准入 Webhook 服务器置 `ClientAuth` 字段为
 [空](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39)，
-默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。
+默认为 `NoClientCert` 。这意味着 Webhook 服务器不会验证客户端的身份，认为其是 apiservers。
 如果你需要双向 TLS 或其他方式来验证客户端，请参阅
 如何[对 apiservers 进行身份认证](#authenticate-apiservers)。

@ -141,18 +149,18 @@ The test also creates a [service](/docs/reference/generated/kubernetes-api/{{< p
 as the front-end of the webhook server. See
 [code](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/e2e/apimachinery/webhook.go#L748).
 -->
-e2e 测试中的 webhook 服务器通过
+e2e 测试中的 Webhook 服务器通过
 [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps)
 部署在 Kubernetes 集群中。该测试还将创建一个
 [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
-作为 webhook 服务器的前端。参见
+作为 Webhook 服务器的前端。参见
 [相关代码](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/e2e/apimachinery/webhook.go#L748)。

 <!--
 You may also deploy your webhooks outside of the cluster. You will need to update
 your webhook configurations accordingly.
 -->
-你也可以在集群外部署 webhook。这样做需要相应地更新你的 webhook 配置。
+你也可以在集群外部署 Webhook。这样做需要相应地更新你的 Webhook 配置。

 <!--
 ### Configure admission webhooks on the fly
@ -166,15 +174,16 @@ webhooks via
 or
 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io).
 -->
-你可以通过 
+你可以通过
 [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io)
-或者 
+或者
 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 动态配置哪些资源要被哪些准入 Webhook 处理。
+
 <!--
 The following is an example `ValidatingWebhookConfiguration`, a mutating webhook configuration is similar.
 See the [webhook configuration](#webhook-configuration) section for details about each config field.
 -->
-以下是一个 `ValidatingWebhookConfiguration` 示例，mutating webhook 配置与此类似。有关每个配置字段的详细信息，请参阅 [webhook 配置](#webhook-configuration) 部分。
+以下是一个 `ValidatingWebhookConfiguration` 示例，Mutating Webhook 配置与此类似。有关每个配置字段的详细信息，请参阅 [Webhook 配置](#webhook-configuration) 部分。

 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
@ -184,11 +193,11 @@ metadata:
 webhooks:
 - name: "pod-policy.example.com"
  rules:
-  - apiGroups:   [""]
+  - apiGroups: [""]
    apiVersions: ["v1"]
-    operations:  ["CREATE"]
-    resources:   ["pods"]
-    scope:       "Namespaced"
+    operations: ["CREATE"]
+    resources: ["pods"]
+    scope: "Namespaced"
  clientConfig:
    service:
      namespace: "example-namespace"
@ -198,6 +207,7 @@ webhooks:
  sideEffects: None
  timeoutSeconds: 5
 ```
+
 {{< note >}}
 <!-- 
 You must replace the `<CA_BUNDLE>` in the above example by a valid CA bundle
@ -207,30 +217,30 @@ which is a PEM-encoded CA bundle for validating the webhook's server certificate
 这是一个用 PEM 编码的 CA 证书包，用于校验 Webhook 的服务器证书。
 {{< /note >}}

-<!-- 
+<!--
 The `scope` field specifies if only cluster-scoped resources ("Cluster") or namespace-scoped
 resources ("Namespaced") will match this rule. "&lowast;" means that there are no scope restrictions.
 -->
 `scope` 字段指定是仅集群范围的资源（Cluster）还是名字空间范围的资源资源（Namespaced）将与此规则匹配。
 `*` 表示没有范围限制。

+{{< note >}}
 <!--
 When using `clientConfig.service`, the server cert must be valid for
 `<svc_name>.<svc_namespace>.svc`.
 -->
-{{< note >}}
 当使用 `clientConfig.service` 时，服务器证书必须对 `<svc_name>.<svc_namespace>.svc` 有效。
 {{< /note >}}

+{{< note >}}
 <!--
 Default timeout for a webhook call is 10 seconds,
 You can set the `timeout` and it is encouraged to use a short timeout for webhooks.
 If the webhook call times out, the request is handled according to the webhook's
 failure policy.
 -->
-{{< note >}}
-Webhook 调用的默认超时是 10 秒，你可以设置 `timeout` 并建议对 webhook 设置较短的超时时间。
-如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。
+Webhook 调用的默认超时是 10 秒，你可以设置 `timeout` 并建议对 Webhook 设置较短的超时时间。
+如果 Webhook 调用超时，则根据 Webhook 的失败策略处理请求。
 {{< /note >}}

 <!--
@ -242,12 +252,12 @@ After you create the webhook configuration, the system will take a few seconds
 to honor the new configuration.
 -->
 当一个 API 服务器收到与 `rules` 相匹配的请求时，
-该 API 服务器将按照 `clientConfig` 中指定的方式向 webhook 发送一个 `admissionReview` 请求。
+该 API 服务器将按照 `clientConfig` 中指定的方式向 Webhook 发送一个 `admissionReview` 请求。

 创建 Webhook 配置后，系统将花费几秒钟使新配置生效。

 <!--
-### Authenticate API servers
+### Authenticate API servers   {#authenticate-apiservers}
 -->
 ### 对 API 服务器进行身份认证 {#authenticate-apiservers}

@ -322,71 +332,74 @@ For more information about `AdmissionConfiguration`, see the
 [AdmissionConfiguration (v1) reference](/docs/reference/config-api/apiserver-webhookadmission.v1/).
 See the [webhook configuration](#webhook-configuration) section for details about each config field.

-* In the kubeConfig file, provide the credentials:
+In the kubeConfig file, provide the credentials:
 -->
 有关 `AdmissionConfiguration` 的更多信息，请参见
 [AdmissionConfiguration (v1) reference](/docs/reference/config-api/apiserver-webhookadmission.v1/)。
-有关每个配置字段的详细信息，请参见 [webhook 配置](#webhook-配置)部分。
+有关每个配置字段的详细信息，请参见 [Webhook 配置](#webhook-配置)部分。

-* 在 kubeConfig 文件中，提供证书凭据：
+在 kubeConfig 文件中，提供证书凭据：
+
+```yaml
+apiVersion: v1
+kind: Config
+users:
+# 名称应设置为服务的 DNS 名称或配置了 Webhook 的 URL 的主机名（包括端口）。
+# 如果将非 443 端口用于服务，则在配置 1.16+ API 服务器时，该端口必须包含在名称中。
+#
+# 对于配置在默认端口（443）上与服务对话的 Webhook，请指定服务的 DNS 名称：
+# - name: webhook1.ns1.svc
+#   user: ...
+#
+# 对于配置在非默认端口（例如 8443）上与服务对话的 Webhook，请在 1.16+ 中指定服务的 DNS 名称和端口：
+# - name: webhook1.ns1.svc:8443
+#   user: ...
+# 并可以选择仅使用服务的 DNS 名称来创建第二节，以与 1.15 API 服务器版本兼容：
+# - name: webhook1.ns1.svc
+#   user: ...
+#
+# 对于配置为使用 URL 的 webhook，请匹配在 webhook 的 URL 中指定的主机（和端口）。
+# 带有 `url: https://www.example.com` 的 webhook：
+# - name: www.example.com
+#   user: ...
+#
+# 带有 `url: https://www.example.com:443` 的 webhook：
+# - name: www.example.com:443
+#   user: ...
+#
+# 带有 `url: https://www.example.com:8443` 的 webhook：
+# - name: www.example.com:8443
+#   user: ...
+#
+- name: 'webhook1.ns1.svc'
+  user:
+    client-certificate-data: "<pem encoded certificate>"
+    client-key-data: "<pem encoded key>"
+# `name` 支持使用 * 通配符匹配前缀段。
+- name: '*.webhook-company.org'
+  user:
+    password: "<password>"
+    username: "<name>"
+# '*' 是默认匹配项。
+- name: '*'
+  user:
+    token: "<token>"
+```

-    ```yaml
-    apiVersion: v1
-    kind: Config
-    users:
-    # 名称应设置为服务的 DNS 名称或配置了 Webhook 的 URL 的主机名（包括端口）。
-    # 如果将非 443 端口用于服务，则在配置 1.16+ API 服务器时，该端口必须包含在名称中。
-    #
-    # 对于配置在默认端口（443）上与服务对话的 Webhook，请指定服务的 DNS 名称：
-    # - name: webhook1.ns1.svc
-    #   user: ...
-    #
-    # 对于配置在非默认端口（例如 8443）上与服务对话的 Webhook，请在 1.16+ 中指定服务的 DNS 名称和端口：
-    # - name: webhook1.ns1.svc:8443
-    #   user: ...
-    # 并可以选择仅使用服务的 DNS 名称来创建第二节，以与 1.15 API 服务器版本兼容：
-    # - name: webhook1.ns1.svc
-    #   user: ...
-    #
-    # 对于配置为使用 URL 的 webhook，请匹配在 webhook 的 URL 中指定的主机（和端口）。
-    # 带有 `url: https://www.example.com` 的 webhook：
-    # - name: www.example.com
-    #   user: ...
-    #
-    # 带有 `url: https://www.example.com:443` 的 webhook：
-    # - name: www.example.com:443
-    #   user: ...
-    #
-    # 带有 `url: https://www.example.com:8443` 的 webhook：
-    # - name: www.example.com:8443
-    #   user: ...
-    #
-    - name: 'webhook1.ns1.svc'
-      user:
-        client-certificate-data: "<pem encoded certificate>"
-        client-key-data: "<pem encoded key>"
-    # `name` 支持使用 * 通配符匹配前缀段。
-    - name: '*.webhook-company.org'
-      user:
-        password: "<password>"
-        username: "<name>"
-    # '*' 是默认匹配项。
-    - name: '*'
-      user:
-        token: "<token>"
-    ```
 <!--
 Of course you need to set up the webhook server to handle these authentication requests.
 -->
 当然，你需要设置 Webhook 服务器来处理这些身份验证请求。

-<!-- ## Webhook request and response -->
+<!--
+## Webhook request and response
+-->
 ## Webhook 请求与响应 {#webhook-request-and-response}

 <!--
 ### Request

-Webhooks are sent as POST request, with `Content-Type: application/json`,
+Webhooks are sent as POST requests, with `Content-Type: application/json`,
 with an `AdmissionReview` API object in the `admission.k8s.io` API group
 serialized to JSON as the body.

@ -396,7 +409,8 @@ with the `admissionReviewVersions` field in their configuration:

 ### 请求 {#request}

-Webhook 发送 POST 请求时，请设置 `Content-Type: application/json` 并对 `admission.k8s.io`  API 组中的 `AdmissionReview` 对象进行序列化，将所得到的 JSON 作为请求的主体。
+Webhook 发送 POST 请求时，请设置 `Content-Type: application/json` 并对 `admission.k8s.io` API
+组中的 `AdmissionReview` 对象进行序列化，将所得到的 JSON 作为请求的主体。

 Webhook 可以在配置中的 `admissionReviewVersions` 字段指定可接受的 `AdmissionReview` 对象版本：

@ -414,7 +428,7 @@ webhooks:
 Webhooks are required to support at least one `AdmissionReview`
 version understood by the current and previous API server.
 -->
-创建 webhook 配置时，`admissionReviewVersions` 是必填字段。
+创建 Webhook 配置时，`admissionReviewVersions` 是必填字段。
 Webhook 必须支持至少一个当前和以前的 API 服务器都可以解析的 `AdmissionReview` 版本。

 <!--
@ -455,24 +469,24 @@ request:
  subResource: scale

  # 在对 API 服务器的原始请求中，传入对象的标准 group/version/kind
-  # 仅当 webhook 指定 `matchPolicy: Equivalent` 且将对 API 服务器的原始请求
-  # 转换为 webhook 注册的版本时，这才与 `kind` 不同。
+  # 仅当 Webhook 指定 `matchPolicy: Equivalent` 且将对 API 服务器的原始请求
+  # 转换为 Webhook 注册的版本时，这才与 `kind` 不同。
  requestKind:
    group: autoscaling
    version: v1
    kind: Scale

  # 在对 API 服务器的原始请求中正在修改的资源的标准 group/version/kind
-  # 仅当 webhook 指定了 `matchPolicy：Equivalent` 并且将对 API 服务器的原始请求转换为
-  # webhook 注册的版本时，这才与 `resource` 不同。
+  # 仅当 Webhook 指定了 `matchPolicy：Equivalent` 并且将对 API 服务器的原始请求转换为
+  # Webhook 注册的版本时，这才与 `resource` 不同。
  requestResource:
    group: apps
    version: v1
    resource: deployments

  # subResource（如果请求是针对 subResource 的）
-  # 仅当 webhook 指定了 `matchPolicy：Equivalent` 并且将对
-  # API 服务器的原始请求转换为该 webhook 注册的版本时，这才与 `subResource` 不同。
+  # 仅当 Webhook 指定了 `matchPolicy：Equivalent` 并且将对
+  # API 服务器的原始请求转换为该 Webhook 注册的版本时，这才与 `subResource` 不同。
  requestSubResource: scale

  # 被修改资源的名称
@ -585,9 +599,10 @@ Webhook 禁止请求的最简单响应示例：
 ```

 <!--
-When rejecting a request, the webhook can customize the http code and message returned to the user using the `status` field. 
-The specified status object is returned to the user.
-See the [API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#status-v1-meta) for details about the `status` type.
+When rejecting a request, the webhook can customize the http code and message returned to the user
+using the `status` field. The specified status object is returned to the user.
+See the [API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#status-v1-meta)
+for details about the `status` type.
 Example of a response to forbid a request, customizing the HTTP status code and message presented to the user:
 -->
 当拒绝请求时，Webhook 可以使用 `status` 字段自定义 http 响应码和返回给用户的消息。
@ -624,7 +639,8 @@ For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of
 对于 `patchType: JSONPatch`，`patch` 字段包含一个以 base64 编码的 JSON patch 操作数组。

 <!--
-As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]`
+As an example, a single patch operation that would set `spec.replicas` would be
+`[{"op": "add", "path": "/spec/replicas", "value": 3}]`

 Base64-encoded, this would be `W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=`
 -->
@ -652,18 +668,19 @@ So a webhook response to add that label would be:
 }
 ```

-<!-- 
-Admission webhooks can optionally return warning messages that are returned to the requesting client in HTTP `Warning` headers with a warning code of 299. Warnings can be sent with allowed or rejected admission responses. 
+<!--
+Admission webhooks can optionally return warning messages that are returned to the requesting client
+in HTTP `Warning` headers with a warning code of 299. Warnings can be sent with allowed or rejected admission responses.
 -->
 准入 Webhook 可以选择性地返回在 HTTP `Warning` 头中返回给请求客户端的警告消息，警告代码为 299。
 警告可以与允许或拒绝的准入响应一起发送。

-<!-- 
+<!--
 If you're implementing a webhook that returns a warning:

 * Don't include a "Warning:" prefix in the message
 * Use warning messages to describe problems the client making the API request should correct or be aware of
-* Limit warnings to 120 characters if possible 
+* Limit warnings to 120 characters if possible
 -->
 如果你正在实现返回一条警告的 webhook，则：

@ -674,7 +691,7 @@ If you're implementing a webhook that returns a warning:
 {{< caution >}}
 <!-- 
 Individual warning messages over 256 characters may be truncated by the API server before being returned to clients.
-If more than 4096 characters of warning messages are added (from all sources), additional warning messages are ignored. 
+If more than 4096 characters of warning messages are added (from all sources), additional warning messages are ignored.
 -->
 超过 256 个字符的单条警告消息在返回给客户之前可能会被 API 服务器截断。
 如果超过 4096 个字符的警告消息（来自所有来源），则额外的警告消息会被忽略。
@ -731,37 +748,44 @@ Webhook，则应为每个 Webhook 赋予一个唯一的名称。
 Each webhook must specify a list of rules used to determine if a request to the API server should be sent to the webhook.
 Each rule specifies one or more operations, apiGroups, apiVersions, and resources, and a resource scope:
 -->
-每个 webhook 必须指定用于确定是否应将对 apiserver 的请求发送到 webhook 的规则列表。
+每个 Webhook 必须指定用于确定是否应将对 apiserver 的请求发送到 webhook 的规则列表。
 每个规则都指定一个或多个 operations、apiGroups、apiVersions 和 resources 以及资源的 scope：

 <!--
-* `operations` lists one or more operations to match. Can be `"CREATE"`, `"UPDATE"`, `"DELETE"`, `"CONNECT"`, or `"*"` to match all.
+* `operations` lists one or more operations to match. Can be `"CREATE"`, `"UPDATE"`, `"DELETE"`, `"CONNECT"`,
+  or `"*"` to match all.
 * `apiGroups` lists one or more API groups to match. `""` is the core API group. `"*"` matches all API groups.
 * `apiVersions` lists one or more API versions to match. `"*"` matches all API versions.
 * `resources` lists one or more resources to match.
-    * `"*"` matches all resources, but not subresources.
-    * `"*/*"` matches all resources and subresources.
-    * `"pods/*"` matches all subresources of pods.
-    * `"*/status"` matches all status subresources.
-* `scope` specifies a scope to match. Valid values are `"Cluster"`, `"Namespaced"`, and `"*"`. Subresources match the scope of their parent resource. Default is `"*"`.
-    * `"Cluster"` means that only cluster-scoped resources will match this rule (Namespace API objects are cluster-scoped).
-    * `"Namespaced"` means that only namespaced resources will match this rule.
-    * `"*"` means that there are no scope restrictions.
+
+  * `"*"` matches all resources, but not subresources.
+  * `"*/*"` matches all resources and subresources.
+  * `"pods/*"` matches all subresources of pods.
+  * `"*/status"` matches all status subresources.
+
+* `scope` specifies a scope to match. Valid values are `"Cluster"`, `"Namespaced"`, and `"*"`.
+  Subresources match the scope of their parent resource. Default is `"*"`.
+
+  * `"Cluster"` means that only cluster-scoped resources will match this rule (Namespace API objects are cluster-scoped).
+  * `"Namespaced"` means that only namespaced resources will match this rule.
+  * `"*"` means that there are no scope restrictions.
 -->
 * `operations` 列出一个或多个要匹配的操作。
  可以是 `CREATE`、`UPDATE`、`DELETE`、`CONNECT` 或 `*` 以匹配所有内容。
 * `apiGroups` 列出了一个或多个要匹配的 API 组。`""` 是核心 API 组。`"*"` 匹配所有 API 组。
 * `apiVersions` 列出了一个或多个要匹配的 API 版本。`"*"` 匹配所有 API 版本。
 * `resources` 列出了一个或多个要匹配的资源。
-    * `"*"` 匹配所有资源，但不包括子资源。
-    * `"*/*"` 匹配所有资源，包括子资源。
-    * `"pods/*"` 匹配 pod 的所有子资源。
-    * `"*/status"` 匹配所有 status 子资源。
+
+  * `"*"` 匹配所有资源，但不包括子资源。
+  * `"*/*"` 匹配所有资源，包括子资源。
+  * `"pods/*"` 匹配 pod 的所有子资源。
+  * `"*/status"` 匹配所有 status 子资源。
 * `scope` 指定要匹配的范围。有效值为 `"Cluster"`、`"Namespaced"` 和 `"*"`。
  子资源匹配其父资源的范围。默认值为 `"*"`。
-    * `"Cluster"` 表示只有集群作用域的资源才能匹配此规则（API 对象 Namespace 是集群作用域的）。
-    * `"Namespaced"` 意味着仅具有名字空间的资源才符合此规则。
-    * `"*"` 表示没有作用域限制。
+
+  * `"Cluster"` 表示只有集群作用域的资源才能匹配此规则（API 对象 Namespace 是集群作用域的）。
+  * `"Namespaced"` 意味着仅具有名字空间的资源才符合此规则。
+  * `"*"` 表示没有作用域限制。

 <!--
 If an incoming request matches one of the specified `operations`, `groups`, `versions`,
@ -855,9 +879,10 @@ is not considered to match.
 被认为不匹配。

 <!--
-Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels.
+Use the object selector only if the webhook is opt-in, because end users may skip
+the admission webhook by setting the labels.
 -->
-仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来
+仅当选择使用 Webhook 时才使用对象选择器，因为最终用户可以通过设置标签来
 跳过准入 Webhook。

 <!--
@ -926,7 +951,7 @@ webhooks:
      matchExpressions:
        - key: runlevel
          operator: NotIn
-          values: ["0","1"]
+          values: ["0", "1"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
@ -936,8 +961,8 @@ webhooks:
 ```

 <!--
-This example shows a validating webhook that matches a `CREATE` of any namespaced resource inside a namespace
-that is associated with the "environment" of "prod" or "staging":
+This example shows a validating webhook that matches a `CREATE` of any namespaced resource inside
+a namespace that is associated with the "environment" of "prod" or "staging":
 -->
 此示例显示了一个验证性质的 Webhook，它将匹配到对某名字空间中的任何具名字空间的资源的
 `CREATE` 请求，前提是该名字空间具有值为 "prod" 或 "staging" 的 "environment" 标签：
@ -951,7 +976,7 @@ webhooks:
      matchExpressions:
        - key: environment
          operator: In
-          values: ["prod","staging"]
+          values: ["prod", "staging"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
@ -983,7 +1008,7 @@ For example, if a webhook only specified a rule for some API groups/versions
 and a request was made to modify the resource via another API group/version (like `extensions/v1beta1`),
 the request would not be sent to the webhook.
 -->
-例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如
+例如，如果一个 Webhook 仅为某些 API 组/版本指定了规则（例如
 `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求是通过另一个
 API 组/版本（例如 `extensions/v1beta1`）发出的，该请求将不会被发送到 Webhook。

@ -991,25 +1016,28 @@ API 组/版本（例如 `extensions/v1beta1`）发出的，该请求将不会被
 The `matchPolicy` lets a webhook define how its `rules` are used to match incoming requests.
 Allowed values are `Exact` or `Equivalent`.
 -->
-`matchPolicy` 允许 webhook 定义如何使用其 `rules` 匹配传入的请求。
+`matchPolicy` 允许 Webhook 定义如何使用其 `rules` 匹配传入的请求。
 允许的值为 `Exact` 或 `Equivalent`。

 <!--
 * `Exact` means a request should be intercepted only if it exactly matches a specified rule.
-* `Equivalent` means a request should be intercepted if modifies a resource listed in `rules`, even via another API group or version.
+* `Equivalent` means a request should be intercepted if modifies a resource listed in `rules`,
+  even via another API group or version.

 In the example given above, the webhook that only registered for `apps/v1` could use `matchPolicy`:
+
 * `matchPolicy: Exact` would mean the `extensions/v1beta1` request would not be sent to the webhook
-* `matchPolicy: Equivalent` means the `extensions/v1beta1` request would be sent to the webhook (with the objects converted to a version the webhook had specified: `apps/v1`)
+* `matchPolicy: Equivalent` means the `extensions/v1beta1` request would be sent to the webhook
+  (with the objects converted to a version the webhook had specified: `apps/v1`)
 -->
 * `Exact` 表示仅当请求与指定规则完全匹配时才应拦截该请求。
 * `Equivalent` 表示如果某个请求意在修改 `rules` 中列出的资源，
  即使该请求是通过其他 API 组或版本发起，也应拦截该请求。

-在上面给出的示例中，仅为 `apps/v1` 注册的 webhook 可以使用 `matchPolicy`：
+在上面给出的示例中，仅为 `apps/v1` 注册的 Webhook 可以使用 `matchPolicy`：
 * `matchPolicy: Exact` 表示不会将 `extensions/v1beta1` 请求发送到 Webhook
-* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 webhook
-  （将对象转换为 webhook 指定的版本：`apps/v1`）
+* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 Webhook
+  （将对象转换为 Webhook 指定的版本：`apps/v1`）

 <!--
 Specifying `Equivalent` is recommended, and ensures that webhooks continue to intercept the
@ -1019,7 +1047,8 @@ resources they expect when upgrades enable new versions of the resource in the A
 Webhook 继续拦截他们期望的资源。

 <!--
-When a resource stops being served by the API server, it is no longer considered equivalent to other versions of that resource that are still served.
+When a resource stops being served by the API server, it is no longer considered equivalent to
+other versions of that resource that are still served.
 For example, `extensions/v1beta1` deployments were first deprecated and then removed (in Kubernetes v1.16).

 Since that removal, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule
@ -1029,7 +1058,7 @@ for stable versions of resources.
 当 API 服务器停止提供某资源时，该资源不再被视为等同于该资源的其他仍在提供服务的版本。
 例如，`extensions/v1beta1` 中的 Deployment 已被废弃，计划在 v1.16 中移除。

-移除后，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]` 
+移除后，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]`
 规则的 Webhook 将不再拦截通过 `apps/v1` API 来创建的 Deployment。
 因此，Webhook 应该优先注册稳定版本的资源。

@ -1054,8 +1083,8 @@ webhooks:
    scope: "Namespaced"
 ```

-<!-- 
-The `matchPolicy` for an admission webhooks defaults to `Equivalent`. 
+<!--
+The `matchPolicy` for an admission webhooks defaults to `Equivalent`.
 -->
 准入 Webhook 所用的 `matchPolicy` 默认为 `Equivalent`。

@ -1144,7 +1173,7 @@ webhooks:
        expression: '!authorizer.group("admissionregistration.k8s.io").resource("validatingwebhookconfigurations").name("my-webhook.example.com").check("breakglass").allowed()'
 ```

-<!-- 
+<!--
 Match conditions have access to the following CEL variables:
 -->
 匹配条件可以访问以下 CEL 变量：
@ -1217,8 +1246,8 @@ stanza of the webhook configuration.
 Webhooks can either be called via a URL or a service reference,
 and can optionally include a custom CA bundle to use to verify the TLS connection.
 -->
-API 服务器确定请求应发送到 webhook 后，它需要知道如何调用 webhook。
-此信息在 webhook 配置的 `clientConfig` 节中指定。
+API 服务器确定请求应发送到 Webhook 后，它需要知道如何调用 webhook。
+此信息在 Webhook 配置的 `clientConfig` 节中指定。

 Webhook 可以通过 URL 或服务引用来调用，并且可以选择包含自定义 CA 包，以用于验证 TLS 连接。

@ -1231,7 +1260,7 @@ Webhook 可以通过 URL 或服务引用来调用，并且可以选择包含自
 `url` gives the location of the webhook, in standard URL form
 (`scheme://host:port/path`).
 -->
-`url` 以标准 URL 形式给出 webhook 的位置（`scheme://host:port/path`）。
+`url` 以标准 URL 形式给出 Webhook 的位置（`scheme://host:port/path`）。

 <!--
 The `host` should not refer to a service running in the cluster; use
@ -1247,12 +1276,12 @@ be a layering violation). `host` may also be an IP address.
 <!--
 Please note that using `localhost` or `127.0.0.1` as a `host` is
 risky unless you take great care to run this webhook on all hosts
-which run an apiserver which might need to make calls to this
-webhook. Such installations are likely to be non-portable, i.e., not easy
-to turn up in a new cluster.
+which run an API server which might need to make calls to this
+webhook. Such installations are likely to be non-portable or not readily
+run in a new cluster.
 -->
 请注意，将 `localhost` 或 `127.0.0.1` 用作 `host` 是有风险的，
-除非你非常小心地在所有运行 apiserver 的、可能需要对此 webhook 
+除非你非常小心地在所有运行 apiserver 的、可能需要对此 Webhook
 进行调用的主机上运行。这样的安装方式可能不具有可移植性，即很难在新集群中启用。

 <!--
@ -1261,8 +1290,8 @@ The scheme must be "https"; the URL must begin with "https://".
 scheme 必须为 "https"；URL 必须以 "https://" 开头。

 <!--
-Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
-Fragments ("#...") and query parameters ("?...") are also not allowed.
+Attempting to use a user or basic auth (for example `user:password@`) is not allowed.
+Fragments (`#...`) and query parameters (`?...`) are also not allowed.
 -->
 使用用户或基本身份验证（例如："user:password@"）是不允许的。
 使用片段（"#..."）和查询参数（"?..."）也是不允许的。
@ -1321,14 +1350,16 @@ webhooks:
      path: /my-path
      port: 1234
 ```
+
 {{< note >}}
 <!-- 
 You must replace the `<CA_BUNDLE>` in the above example by a valid CA bundle
-which is a PEM-encoded CA bundle for validating the webhook's server certificate. 
+which is a PEM-encoded CA bundle for validating the webhook's server certificate.
 -->
 你必须在以上示例中将 `<CA_BUNDLE>` 替换为一个有效的 VA 证书包，
 这是一个用 PEM 编码的 CA 证书包，用于校验 Webhook 的服务器证书。
 {{< /note >}}
+
 <!--
 ### Side effects
 -->
@ -1342,7 +1373,7 @@ Webhook 通常仅对发送给他们的 `AdmissionReview` 内容进行操作。
 但是，某些 Webhook 在处理 admission 请求时会进行带外更改。

 <!--
-Webhooks that make out-of-band changes ("side effects") must also have a reconcilation mechanism
+Webhooks that make out-of-band changes ("side effects") must also have a reconciliation mechanism
 (like a controller) that periodically determines the actual state of the world, and adjusts
 the out-of-band data modified by the admission webhook to reflect reality.
 This is because a call to an admission webhook does not guarantee the admitted object will be persisted as is, or at all.
@ -1372,16 +1403,16 @@ Webhooks indicate whether they have side effects using the `sideEffects` field i
  `dryRun: true` is sent to the webhook, the webhook will suppress the side effects (the webhook
  is `dryRun`-aware).
 -->
-Webhook 使用 webhook 配置中的 `sideEffects` 字段显示它们是否有副作用：
+Webhook 使用 Webhook 配置中的 `sideEffects` 字段显示它们是否有副作用：

-* `None`：调用 webhook 没有副作用。
-* `NoneOnDryRun`：调用 webhook 可能会有副作用，但是如果将带有 `dryRun: true`
-  属性的请求发送到 webhook，则 webhook 将抑制副作用（该 webhook 可识别 `dryRun`）。
+* `None`：调用 Webhook 没有副作用。
+* `NoneOnDryRun`：调用 Webhook 可能会有副作用，但是如果将带有 `dryRun: true`
+  属性的请求发送到 webhook，则 Webhook 将抑制副作用（该 Webhook 可识别 `dryRun`）。

 <!--
 Here is an example of a validating webhook indicating it has no side effects on `dryRun: true` requests:
 -->
-这是一个 validating webhook 的示例，表明它对 `dryRun: true` 请求没有副作用：
+这是一个 validating Webhook 的示例，表明它对 `dryRun: true` 请求没有副作用：

 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
@ -1427,8 +1458,8 @@ webhooks:
    timeoutSeconds: 2
 ```

-<!-- 
-The timeout for an admission webhook defaults to 10 seconds. 
+<!--
+The timeout for an admission webhook defaults to 10 seconds.
 -->
 准入 Webhook 所用的超时时间默认为 10 秒。

@ -1464,9 +1495,9 @@ and mutating webhooks can specify a `reinvocationPolicy` to control whether they
 可以将 `reinvocationPolicy` 设置为 `Never` 或 `IfNeeded`。 默认为 `Never`。

 <!--
-* `Never`: the webhook must not be called more than once in a single admission evaluation
+* `Never`: the webhook must not be called more than once in a single admission evaluation.
 * `IfNeeded`: the webhook may be called again as part of the admission evaluation if the object
-being admitted is modified by other admission plugins after the initial webhook call.
+  being admitted is modified by other admission plugins after the initial webhook call.
 -->
 * `Never`: 在一次准入测试中，不得多次调用 Webhook。
 * `IfNeeded`: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象，
@ -1479,9 +1510,11 @@ The important elements to note are:

 <!--
 * The number of additional invocations is not guaranteed to be exactly one.
-* If additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again.
+* If additional invocations result in further modifications to the object, webhooks are not
+  guaranteed to be invoked again.
 * Webhooks that use this option may be reordered to minimize the number of additional invocations.
-* To validate an object after all mutations are guaranteed complete, use a validating admission webhook instead (recommended for webhooks with side-effects).
+* To validate an object after all mutations are guaranteed complete, use a validating admission
+  webhook instead (recommended for webhooks with side-effects).
 -->
 * 不能保证附加调用的次数恰好是一。
 * 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 Webhook。
@ -1490,7 +1523,8 @@ The important elements to note are:
  （推荐用于有副作用的 Webhook）。

 <!--
-Here is an example of a mutating webhook opting into being re-invoked if later admission plugins modify the object:
+Here is an example of a mutating webhook opting into being re-invoked if later admission plugins
+modify the object:
 -->
 这是一个修改性质的 Webhook 的示例，该 Webhook 在以后的准入插件修改对象时被重新调用：

@ -1510,7 +1544,7 @@ in an object could already exist in the user-provided object, but it is essentia
 修改性质的 Webhook 必须具有[幂等](#idempotence)性，并且能够成功处理
 已被接纳并可能被修改的对象的修改性质的 Webhook。
 对于所有修改性质的准入 Webhook 都是如此，因为它们可以在对象中进行的
-任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 webhook
+任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 Webhook
 来说是必不可少的。

 <!--
@ -1527,10 +1561,10 @@ are handled. Allowed values are `Ignore` or `Fail`.

 Here is a mutating webhook configured to reject an API request if errors are encountered calling the admission webhook:
 -->
-`failurePolicy` 定义了如何处理准入 webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。
+`failurePolicy` 定义了如何处理准入 Webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。

-* `Ignore` 表示调用 webhook 的错误将被忽略并且允许 API 请求继续。
-* `Fail` 表示调用 webhook 的错误导致准入失败并且 API 请求被拒绝。
+* `Ignore` 表示调用 Webhook 的错误将被忽略并且允许 API 请求继续。
+* `Fail` 表示调用 Webhook 的错误导致准入失败并且 API 请求被拒绝。

 这是一个修改性质的 webhook，配置为在调用准入 Webhook 遇到错误时拒绝 API 请求：

@ -1542,8 +1576,8 @@ webhooks:
  failurePolicy: Fail
 ```

-<!-- 
-The default `failurePolicy` for an admission webhooks is `Fail`. 
+<!--
+The default `failurePolicy` for an admission webhooks is `Fail`.
 -->
 准入 Webhook 所用的默认 `failurePolicy` 是 `Fail`。

@ -1560,14 +1594,13 @@ monitoring mechanisms help cluster admins to answer questions like:

 2. What change did the mutating webhook applied to the object?

-3. Which webhooks are frequently rejecting API requests? What's the reason for a
-   rejection?
+3. Which webhooks are frequently rejecting API requests? What's the reason for a rejection?
 -->
 API 服务器提供了监视准入 Webhook 行为的方法。这些监视机制可帮助集群管理员回答以下问题：

-1. 哪个修改性质的 webhook 改变了 API 请求中的对象？
+1. 哪个修改性质的 Webhook 改变了 API 请求中的对象？
 2. 修改性质的 Webhook 对对象做了哪些更改？
-3. 哪些 webhook 经常拒绝 API 请求？是什么原因拒绝？
+3. 哪些 Webhook 经常拒绝 API 请求？是什么原因拒绝？

 <!--
 ### Mutating webhook auditing annotations
@ -1601,12 +1634,13 @@ The audit level of a event determines which annotations get recorded:

 <!--
 - At `Metadata` audit level or higher, an annotation with key
-  `mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` gets logged with JSON payload indicating
-  a webhook gets invoked for given request and whether it mutated the object or not.
+- At `Metadata` audit level or higher, an annotation with key
+  `mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` gets logged with JSON
+  payload indicating a webhook gets invoked for given request and whether it mutated the object or not.
 -->
 - 在 `Metadata` 或更高审计级别上，将使用 JSON 负载记录带有键名
-`mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
-该注解表示针对给定请求调用了 Webhook，以及该 Webhook 是否更改了对象。
+  `mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
+  该注解表示针对给定请求调用了 Webhook，以及该 Webhook 是否更改了对象。

  <!--
  For example, the following annotation gets recorded for a webhook being reinvoked. The webhook is
@ -1741,7 +1775,7 @@ API 服务器从 `/metrics` 端点公开 Prometheus 指标，这些指标可用
 Sometimes it's useful to know which admission webhooks are frequently rejecting API requests, and the
 reason for a rejection.

-In v1.16+, kube-apiserver exposes a Prometheus counter metric recording admission webhook rejections. The
+The API server exposes a Prometheus counter metric recording admission webhook rejections. The
 metrics are labelled to identify the causes of webhook rejection(s):
 -->
 有时，了解哪些准入 Webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
@ -1757,20 +1791,22 @@ metrics are labelled to identify the causes of webhook rejection(s):
 - `type`: the admission webhook type, can be one of `admit` and `validating`.
 - `error_type`: identifies if an error occurred during the webhook invocation
  that caused the rejection. Its value can be one of:
-   - `calling_webhook_error`: unrecognized errors or timeout errors from the admission webhook happened and the
-   webhook's [Failure policy](#failure-policy) is set to `Fail`.
-   - `no_error`: no error occurred. The webhook rejected the request with `allowed: false` in the admission
-   response. The metrics label `rejection_code` records the `.status.code` set in the admission response.
-   - `apiserver_internal_error`: an API server internal error happened.
+
+  - `calling_webhook_error`: unrecognized errors or timeout errors from the admission webhook happened and the
+    webhook's [Failure policy](#failure-policy) is set to `Fail`.
+  - `no_error`: no error occurred. The webhook rejected the request with `allowed: false` in the admission
+    response. The metrics label `rejection_code` records the `.status.code` set in the admission response.
+  - `apiserver_internal_error`: an API server internal error happened.
+
 - `rejection_code`: the HTTP status code set in the admission response when a
  webhook rejected a request.
 -->
 - `name`：拒绝请求 Webhook 的名称。
 - `operation`：请求的操作类型可以是 `CREATE`、`UPDATE`、`DELETE` 和 `CONNECT` 其中之一。
- `type`：Admission webhook 类型，可以是 `admit` 和 `validating` 其中之一。
- `error_type`：标识在 webhook 调用期间是否发生了错误并且导致了拒绝。其值可以是以下之一：
+- `type`：Admission Webhook 类型，可以是 `admit` 和 `validating` 其中之一。
+- `error_type`：标识在 Webhook 调用期间是否发生了错误并且导致了拒绝。其值可以是以下之一：
  - `calling_webhook_error`：发生了来自准入 Webhook 的无法识别的错误或超时错误，
-    并且 webhook 的 [失败策略](#failure-policy) 设置为 `Fail`。
+    并且 Webhook 的 [失败策略](#failure-policy) 设置为 `Fail`。
  - `no_error`：未发生错误。Webhook 在准入响应中以 `allowed: false` 值拒绝了请求。
    度量标签 `rejection_code` 记录了在准入响应中设置的 `.status.code`。
  - `apiserver_internal_error`：apiserver 发生内部错误。
@ -1815,7 +1851,8 @@ the initial application.
 2. For a `CREATE` pod request, if the field `.spec.containers[].resources.limits`
   of a container is not set, set default resource limits.

-3. For a `CREATE` pod request, inject a sidecar container with name `foo-sidecar` if no container with the name `foo-sidecar` already exists.
+3. For a `CREATE` pod request, inject a sidecar container with name `foo-sidecar` if no container
+   with the name `foo-sidecar` already exists.

 In the cases above, the webhook can be safely reinvoked, or admit an object that already has the fields set.
 -->
@ -1891,16 +1928,18 @@ versions. See [Matching requests: matchPolicy](#matching-requests-matchpolicy) f
 <!--
 ### Availability

-It is recommended that admission Webhooks should evaluate as quickly as possible (typically in milliseconds), since they add to API request latency.
+It is recommended that admission webhooks should evaluate as quickly as possible (typically in
+milliseconds), since they add to API request latency.
 It is encouraged to use a small timeout for webhooks. See [Timeouts](#timeouts) for more detail.

-It is recommended that admission webhooks should leverage some format of load-balancing, to provide high availability and
-performance benefits. If a webhook is running within the cluster, you can run multiple webhook backends behind a service
-to leverage the load-balancing that service supports.
+It is recommended that admission webhooks should leverage some format of load-balancing, to
+provide high availability and performance benefits. If a webhook is running within the cluster,
+you can run multiple webhook backends behind a service to leverage the load-balancing that service
+supports.
 -->
 ### 可用性   {#availability}

-建议准入 webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。
+建议准入 Webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。
 建议对 Webhook 使用较小的超时值。有关更多详细信息，请参见[超时](#timeouts)。

 建议 Admission Webhook 应该采用某种形式的负载均衡机制，以提供高可用性和高性能。
@ -1912,9 +1951,11 @@ to leverage the load-balancing that service supports.
 Admission webhooks that need to guarantee they see the final state of the object in order to enforce policy
 should use a validating admission webhook, since objects can be modified after being seen by mutating webhooks.

-For example, a mutating admission webhook is configured to inject a sidecar container with name "foo-sidecar" on every
-`CREATE` pod request. If the sidecar *must* be present, a validating admisson webhook should also be configured to intercept `CREATE` pod requests, and validate
-that a container with name "foo-sidecar" with the expected configuration exists in the to-be-created object.
+For example, a mutating admission webhook is configured to inject a sidecar container with name
+"foo-sidecar" on every `CREATE` pod request. If the sidecar *must* be present, a validating
+admisson webhook should also be configured to intercept `CREATE` pod requests, and validate that a
+container with name "foo-sidecar" with the expected configuration exists in the to-be-created
+object.
 -->

 ### 确保看到对象的最终状态 {#guaranteeing-the-final-state-of-the-object-is-seen}
@ -1923,7 +1964,7 @@ that a container with name "foo-sidecar" with the expected configuration exists
 则应该使用一个验证性质的 webhook，
 因为可以通过 mutating Webhook 看到对象后对其进行修改。

-例如，一个修改性质的准入Webhook 被配置为在每个 `CREATE` Pod 请求中
+例如，一个修改性质的准入 Webhook 被配置为在每个 `CREATE` Pod 请求中
 注入一个名称为 "foo-sidecar" 的 sidecar 容器。

 如果*必须*存在边车容器，则还应配置一个验证性质的准入 Webhook 以拦截
@ -1942,7 +1983,8 @@ When a node that runs the webhook server pods
 becomes unhealthy, the webhook deployment will try to reschedule the pods to another node. However the requests will
 get rejected by the existing webhook server since the `"env"` label is unset, and the migration cannot happen.

-It is recommended to exclude the namespace where your webhook is running with a [namespaceSelector](#matching-requests-namespaceselector).
+It is recommended to exclude the namespace where your webhook is running with a
+[namespaceSelector](#matching-requests-namespaceselector).
 -->
 ### 避免自托管的 Webhooks 中出现死锁 {#avoiding-deadlocks-in-self-hosted-webhooks}

@ -1971,7 +2013,7 @@ set to `NoneOnDryRun`. See [Side effects](#side-effects) for more detail.
 -->
 ### 副作用  {#side-effects}

-建议准入 Webhook 应尽可能避免副作用，这意味着该准入 webhook 仅对发送给他们的
+建议准入 Webhook 应尽可能避免副作用，这意味着该准入 Webhook 仅对发送给他们的
 `AdmissionReview` 的内容起作用，并且不要进行额外更改。
 如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为
 `None`。
--- a/content/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver.md
+++ b/content/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver.md
@ -782,9 +782,9 @@ CIDRs opened in GCE firewall for L7 LB traffic proxy & health checks
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-Enable lock contention profiling, if profiling is enabled
+Enable block profiling, if profiling is enabled
 -->
-如果启用了性能分析，则启用锁争用性能分析。
+如果启用了性能分析，则启用阻塞分析。
 </td>
 </tr>

@ -793,17 +793,33 @@ Enable lock contention profiling, if profiling is enabled
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
+<p>
 <!--
 List of allowed origins for CORS, comma separated.  
 An allowed origin can be a regular expression to support subdomain matching. 
-If this list is empty CORS will not be enabled.
+If this list is empty CORS will not be enabled. Please ensure each expression matches the entire hostname by anchoring to the start with '^' or including the '//' prefix, and by anchoring to the end with '$' or including the ':' port separator suffix. Examples of valid expressions are '//example.com(:|$)' and '^https://example.com(:|$)'
 -->
 CORS 允许的来源清单，以逗号分隔。
 允许的来源可以是支持子域匹配的正则表达式。
 如果此列表为空，则不会启用 CORS。
+请确保每个表达式与整个主机名相匹配，方法是用'^'锚定开始或包括'//'前缀，同时用'$'锚定结束或包括':'端口分隔符后缀。
+有效表达式的例子是'//example.com(:|$)'和'^https://example.com(:|$)'。
+</p>
 </td>
 </tr>

+<tr>
+<td colspan="2">--debug-socket-path string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>
+<!--
+Use an unprotected (no authn/authz) unix-domain socket for profiling with the given path
+-->
+使用位于给定路径的、未受保护的（无身份认证或鉴权的）UNIX 域套接字执行性能分析。
+</p></td>
+</tr>
+
 <tr>
 <td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default: -->默认值：300</td>
 </tr>
@ -853,13 +869,11 @@ Number of workers spawned for DeleteCollection call. These are used to speed up
 </td>
 <td style="line-height: 130%; word-wrap: break-word;">
 <!--
-admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota).
-Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook.
-The order of plugins in this flag does not matter.
+admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
 -->
 <p>
-尽管位于默认启用的插件列表中，仍须被禁用的准入插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook、ResourceQuota）。
-取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。
+尽管位于默认启用的插件列表中，仍须被禁用的准入插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、ClusterTrustBundleAttest、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook、ResourceQuota）。
+取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、ClusterTrustBundleAttest、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。
 该标志中插件的顺序无关紧要。
 </p>
 </td>
@ -900,11 +914,11 @@ File with apiserver egress selector configuration.
 </td>
 <td style="line-height: 130%; word-wrap: break-word;">
 <!--
-admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
+admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
 -->
 <p>
-除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的准入插件。
-取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。该标志中插件的顺序无关紧要。
+除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、ClusterTrustBundleAttest、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的准入插件。
+取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、ClusterTrustBundleAttest、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。该标志中插件的顺序无关紧要。
 </p>
 </td>
 </tr>
@ -1185,16 +1199,16 @@ comma-separated 'key=True|False' pairs
 <tr>
 <td>
 </td>
-<td style="line-height: 130%; word-wrap: break-word;">
+<td style="line-height: 130%; word-wrap: break-word;"><p>
 <!--
-A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>
-APIListChunking=true|false (BETA - default=true)<br/>
+A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>
 APIPriorityAndFairness=true|false (BETA - default=true)<br/>
 APIResponseCompression=true|false (BETA - default=true)<br/>
-APISelfSubjectReview=true|false (ALPHA - default=false)<br/>
+APISelfSubjectReview=true|false (BETA - default=true)<br/>
 APIServerIdentity=true|false (BETA - default=true)<br/>
-APIServerTracing=true|false (ALPHA - default=false)<br/>
-AggregatedDiscoveryEndpoint=true|false (ALPHA - default=false)<br/>
+APIServerTracing=true|false (BETA - default=true)<br/>
+AdmissionWebhookMatchConditions=true|false (ALPHA - default=false)<br/>
+AggregatedDiscoveryEndpoint=true|false (BETA - default=true)<br/>
 AllAlpha=true|false (ALPHA - default=false)<br/>
 AllBeta=true|false (BETA - default=false)<br/>
 AnyVolumeDataSource=true|false (BETA - default=true)<br/>
@ -1204,29 +1218,31 @@ CPUManagerPolicyBetaOptions=true|false (BETA - default=true)<br/>
 CPUManagerPolicyOptions=true|false (BETA - default=true)<br/>
 CSIMigrationPortworx=true|false (BETA - default=false)<br/>
 CSIMigrationRBD=true|false (ALPHA - default=false)<br/>
-CSINodeExpandSecret=true|false (ALPHA - default=false)<br/>
+CSINodeExpandSecret=true|false (BETA - default=true)<br/>
 CSIVolumeHealth=true|false (ALPHA - default=false)<br/>
-ComponentSLIs=true|false (ALPHA - default=false)<br/>
+CloudControllerManagerWebhook=true|false (ALPHA - default=false)<br/>
+CloudDualStackNodeIPs=true|false (ALPHA - default=false)<br/>
+ClusterTrustBundle=true|false (ALPHA - default=false)<br/>
+ComponentSLIs=true|false (BETA - default=true)<br/>
 ContainerCheckpoint=true|false (ALPHA - default=false)<br/>
 ContextualLogging=true|false (ALPHA - default=false)<br/>
-CronJobTimeZone=true|false (BETA - default=true)<br/>
 CrossNamespaceVolumeDataSource=true|false (ALPHA - default=false)<br/>
 CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>
 CustomResourceValidationExpressions=true|false (BETA - default=true)<br/>
 DisableCloudProviders=true|false (ALPHA - default=false)<br/>
 DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)<br/>
-DownwardAPIHugePages=true|false (BETA - default=true)<br/>
 DynamicResourceAllocation=true|false (ALPHA - default=false)<br/>
-EventedPLEG=true|false (ALPHA - default=false)<br/>
+ElasticIndexedJob=true|false (BETA - default=true)<br/>
+EventedPLEG=true|false (BETA - default=false)<br/>
 ExpandedDNSConfig=true|false (BETA - default=true)<br/>
 ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>
-GRPCContainerProbe=true|false (BETA - default=true)<br/>
-GracefulNodeShutdown=true|false (BETA - default=true)
+GracefulNodeShutdown=true|false (BETA - default=true)<br/>
 GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)<br/>
-HPAContainerMetrics=true|false (ALPHA - default=false)<br/>
+HPAContainerMetrics=true|false (BETA - default=true)<br/>
 HPAScaleToZero=true|false (ALPHA - default=false)<br/>
 HonorPVReclaimPolicy=true|false (ALPHA - default=false)<br/>
-IPTablesOwnershipCleanup=true|false (ALPHA - default=false)<br/>
+IPTablesOwnershipCleanup=true|false (BETA - default=true)<br/>
+InPlacePodVerticalScaling=true|false (ALPHA - default=false)<br/>
 InTreePluginAWSUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)<br/>
@ -1235,76 +1251,80 @@ InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginPortworxUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginRBDUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginvSphereUnregister=true|false (ALPHA - default=false)<br/>
-JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)<br/>
 JobPodFailurePolicy=true|false (BETA - default=true)<br/>
 JobReadyPods=true|false (BETA - default=true)<br/>
-KMSv2=true|false (ALPHA - default=false)<br/>
+KMSv2=true|false (BETA - default=true)<br/>
 KubeletInUserNamespace=true|false (ALPHA - default=false)<br/>
 KubeletPodResources=true|false (BETA - default=true)<br/>
+KubeletPodResourcesDynamicResources=true|false (ALPHA - default=false)<br/>
+KubeletPodResourcesGet=true|false (ALPHA - default=false)<br/>
 KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)<br/>
-KubeletTracing=true|false (ALPHA - default=false)<br/>
-LegacyServiceAccountTokenTracking=true|false (ALPHA - default=false)<br/>
+KubeletTracing=true|false (BETA - default=true)<br/>
+LegacyServiceAccountTokenTracking=true|false (BETA - default=true)<br/>
 LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>
 LogarithmicScaleDown=true|false (BETA - default=true)<br/>
 LoggingAlphaOptions=true|false (ALPHA - default=false)<br/>
 LoggingBetaOptions=true|false (BETA - default=true)<br/>
-MatchLabelKeysInPodTopologySpread=true|false (ALPHA - default=false)<br/>
+MatchLabelKeysInPodTopologySpread=true|false (BETA - default=true)<br/>
 MaxUnavailableStatefulSet=true|false (ALPHA - default=false)<br/>
 MemoryManager=true|false (BETA - default=true)<br/>
 MemoryQoS=true|false (ALPHA - default=false)<br/>
-MinDomainsInPodTopologySpread=true|false (BETA - default=false)<br/>
-MinimizeIPTablesRestore=true|false (ALPHA - default=false)<br/>
+MinDomainsInPodTopologySpread=true|false (BETA - default=true)<br/>
+MinimizeIPTablesRestore=true|false (BETA - default=true)<br/>
 MultiCIDRRangeAllocator=true|false (ALPHA - default=false)<br/>
+MultiCIDRServiceAllocator=true|false (ALPHA - default=false)<br/>
 NetworkPolicyStatus=true|false (ALPHA - default=false)<br/>
+NewVolumeManagerReconstruction=true|false (BETA - default=true)<br/>
 NodeInclusionPolicyInPodTopologySpread=true|false (BETA - default=true)<br/>
+NodeLogQuery=true|false (ALPHA - default=false)<br/>
 NodeOutOfServiceVolumeDetach=true|false (BETA - default=true)<br/>
 NodeSwap=true|false (ALPHA - default=false)<br/>
 OpenAPIEnums=true|false (BETA - default=true)<br/>
-OpenAPIV3=true|false (BETA - default=true)<br/>
-PDBUnhealthyPodEvictionPolicy=true|false (ALPHA - default=false)<br/>
+PDBUnhealthyPodEvictionPolicy=true|false (BETA - default=true)<br/>
 PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)<br/>
 PodDeletionCost=true|false (BETA - default=true)<br/>
 PodDisruptionConditions=true|false (BETA - default=true)<br/>
 PodHasNetworkCondition=true|false (ALPHA - default=false)<br/>
-PodSchedulingReadiness=true|false (ALPHA - default=false)<br/>
+PodSchedulingReadiness=true|false (BETA - default=true)<br/>
 ProbeTerminationGracePeriod=true|false (BETA - default=true)<br/>
 ProcMountType=true|false (ALPHA - default=false)<br/>
 ProxyTerminatingEndpoints=true|false (BETA - default=true)<br/>
 QOSReserved=true|false (ALPHA - default=false)<br/>
-ReadWriteOncePod=true|false (ALPHA - default=false)<br/>
+ReadWriteOncePod=true|false (BETA - default=true)<br/>
 RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)<br/>
 RemainingItemCount=true|false (BETA - default=true)<br/>
 RetroactiveDefaultStorageClass=true|false (BETA - default=true)<br/>
 RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>
-SELinuxMountReadWriteOncePod=true|false (ALPHA - default=false)<br/>
-SeccompDefault=true|false (BETA - default=true)<br/>
-ServerSideFieldValidation=true|false (BETA - default=true)<br/>
+SELinuxMountReadWriteOncePod=true|false (BETA - default=true)<br/>
+SecurityContextDeny=true|false (ALPHA - default=false)<br/>
+ServiceNodePortStaticSubrange=true|false (ALPHA - default=false)<br/>
 SizeMemoryBackedVolumes=true|false (BETA - default=true)<br/>
-StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)<br/>
-StatefulSetStartOrdinal=true|false (ALPHA - default=false)<br/>
+StableLoadBalancerNodeSet=true|false (BETA - default=true)<br/>
+StatefulSetAutoDeletePVC=true|false (BETA - default=true)<br/>
+StatefulSetStartOrdinal=true|false (BETA - default=true)<br/>
 StorageVersionAPI=true|false (ALPHA - default=false)<br/>
 StorageVersionHash=true|false (BETA - default=true)<br/>
 TopologyAwareHints=true|false (BETA - default=true)<br/>
-TopologyManager=true|false (BETA - default=true)<br/>
 TopologyManagerPolicyAlphaOptions=true|false (ALPHA - default=false)<br/>
 TopologyManagerPolicyBetaOptions=true|false (BETA - default=false)<br/>
 TopologyManagerPolicyOptions=true|false (ALPHA - default=false)<br/>
 UserNamespacesStatelessPodsSupport=true|false (ALPHA - default=false)<br/>
 ValidatingAdmissionPolicy=true|false (ALPHA - default=false)<br/>
 VolumeCapacityPriority=true|false (ALPHA - default=false)<br/>
+WatchList=true|false (ALPHA - default=false)<br/>
 WinDSR=true|false (ALPHA - default=false)<br/>
 WinOverlay=true|false (BETA - default=true)<br/>
 WindowsHostNetwork=true|false (ALPHA - default=true)
 -->
-<p>
 一组 key=value 对，用来描述测试性/试验性功能的特性门控。可选项有：<br/>
 APIListChunking=true|false (BETA - 默认值=true)<br/>
 APIPriorityAndFairness=true|false (BETA - 默认值=true)<br/>
 APIResponseCompression=true|false (BETA - 默认值=true)<br/>
-APISelfSubjectReview=true|false (ALPHA - 默认值=false)<br/>
+APISelfSubjectReview=true|false (BETA - 默认值=true)<br/>
 APIServerIdentity=true|false (BETA - 默认值=true)<br/>
-APIServerTracing=true|false (ALPHA - 默认值=false)<br/>
-AggregatedDiscoveryEndpoint=true|false (ALPHA - 默认值=false)<br/>
+APIServerTracing=true|false (BETA - 默认值=true)<br/>
+AdmissionWebhookMatchConditions=true|false (ALPHA - 默认值=false)<br/>
+AggregatedDiscoveryEndpoint=true|false (BETA - 默认值=true)<br/>
 AllAlpha=true|false (ALPHA - 默认值=false)<br/>
 AllBeta=true|false (BETA - 默认值=false)<br/>
 AnyVolumeDataSource=true|false (BETA - 默认值=true)<br/>
@ -1314,29 +1334,31 @@ CPUManagerPolicyBetaOptions=true|false (BETA - 默认值=true)<br/>
 CPUManagerPolicyOptions=true|false (BETA - 默认值=true)<br/>
 CSIMigrationPortworx=true|false (BETA - 默认值=false)<br/>
 CSIMigrationRBD=true|false (ALPHA - 默认值=false)<br/>
-CSINodeExpandSecret=true|false (ALPHA - 默认值=false)<br/>
+CSINodeExpandSecret=true|false (BETA - 默认值=true)<br/>
 CSIVolumeHealth=true|false (ALPHA - 默认值=false)<br/>
-ComponentSLIs=true|false (ALPHA - 默认值=false)<br/>
+CloudControllerManagerWebhook=true|false (ALPHA - 默认值=false)<br/>
+CloudDualStackNodeIPs=true|false (ALPHA - 默认值=false)<br/>
+ClusterTrustBundle=true|false (ALPHA - 默认值=false)<br/>
+ComponentSLIs=true|false (BETA - 默认值=true)<br/>
 ContainerCheckpoint=true|false (ALPHA - 默认值=false)<br/>
 ContextualLogging=true|false (ALPHA - 默认值=false)<br/>
-CronJobTimeZone=true|false (BETA - 默认值=true)<br/>
 CrossNamespaceVolumeDataSource=true|false (ALPHA - 默认值=false)<br/>
 CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)<br/>
 CustomResourceValidationExpressions=true|false (BETA - 默认值=true)<br/>
 DisableCloudProviders=true|false (ALPHA - 默认值=false)<br/>
 DisableKubeletCloudCredentialProviders=true|false (ALPHA - 默认值=false)<br/>
-DownwardAPIHugePages=true|false (BETA - 默认值=true)<br/>
 DynamicResourceAllocation=true|false (ALPHA - 默认值=false)<br/>
-EventedPLEG=true|false (ALPHA - 默认值=false)<br/>
+ElasticIndexedJob=true|false (BETA - 默认值=true)<br/>
+EventedPLEG=true|false (BETA - 默认值=false)<br/>
 ExpandedDNSConfig=true|false (BETA - 默认值=true)<br/>
 ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)<br/>
-GRPCContainerProbe=true|false (BETA - 默认值=true)<br/>
-GracefulNodeShutdown=true|false (BETA - 默认值=true)
+GracefulNodeShutdown=true|false (BETA - 默认值=true)<br/>
 GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - 默认值=true)<br/>
-HPAContainerMetrics=true|false (ALPHA - 默认值=false)<br/>
+HPAContainerMetrics=true|false (BETA - 默认值=true)<br/>
 HPAScaleToZero=true|false (ALPHA - 默认值=false)<br/>
 HonorPVReclaimPolicy=true|false (ALPHA - 默认值=false)<br/>
-IPTablesOwnershipCleanup=true|false (ALPHA - 默认值=false)<br/>
+IPTablesOwnershipCleanup=true|false (BETA - 默认值=true)<br/>
+InPlacePodVerticalScaling=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)<br/>
@ -1345,63 +1367,67 @@ InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginPortworxUnregister=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginRBDUnregister=true|false (ALPHA - 默认值=false)<br/>
 InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)<br/>
-JobMutableNodeSchedulingDirectives=true|false (BETA - 默认值=true)<br/>
 JobPodFailurePolicy=true|false (BETA - 默认值=true)<br/>
 JobReadyPods=true|false (BETA - 默认值=true)<br/>
-KMSv2=true|false (ALPHA - 默认值=false)<br/>
+KMSv2=true|false (BETA - 默认值=true)<br/>
 KubeletInUserNamespace=true|false (ALPHA - 默认值=false)<br/>
 KubeletPodResources=true|false (BETA - 默认值=true)<br/>
+KubeletPodResourcesDynamicResources=true|false (ALPHA - 默认值=false)<br/>
+KubeletPodResourcesGet=true|false (ALPHA - 默认值=false)<br/>
 KubeletPodResourcesGetAllocatable=true|false (BETA - 默认值=true)<br/>
-KubeletTracing=true|false (ALPHA - 默认值=false)<br/>
-LegacyServiceAccountTokenTracking=true|false (ALPHA - 默认值=false)<br/>
+KubeletTracing=true|false (BETA - 默认值=true)<br/>
+LegacyServiceAccountTokenTracking=true|false (BETA - 默认值=true)<br/>
 LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)<br/>
 LogarithmicScaleDown=true|false (BETA - 默认值=true)<br/>
 LoggingAlphaOptions=true|false (ALPHA - 默认值=false)<br/>
 LoggingBetaOptions=true|false (BETA - 默认值=true)<br/>
-MatchLabelKeysInPodTopologySpread=true|false (ALPHA - 默认值=false)<br/>
+MatchLabelKeysInPodTopologySpread=true|false (BETA - 默认值=true)<br/>
 MaxUnavailableStatefulSet=true|false (ALPHA - 默认值=false)<br/>
 MemoryManager=true|false (BETA - 默认值=true)<br/>
 MemoryQoS=true|false (ALPHA - 默认值=false)<br/>
-MinDomainsInPodTopologySpread=true|false (BETA - 默认值=false)<br/>
-MinimizeIPTablesRestore=true|false (ALPHA - 默认值=false)<br/>
+MinDomainsInPodTopologySpread=true|false (BETA - 默认值=true)<br/>
+MinimizeIPTablesRestore=true|false (BETA - 默认值=true)<br/>
 MultiCIDRRangeAllocator=true|false (ALPHA - 默认值=false)<br/>
+MultiCIDRServiceAllocator=true|false (ALPHA - 默认值=false)<br/>
 NetworkPolicyStatus=true|false (ALPHA - 默认值=false)<br/>
+NewVolumeManagerReconstruction=true|false (BETA - 默认值=true)<br/>
 NodeInclusionPolicyInPodTopologySpread=true|false (BETA - 默认值=true)<br/>
+NodeLogQuery=true|false (ALPHA - 默认值=false)<br/>
 NodeOutOfServiceVolumeDetach=true|false (BETA - 默认值=true)<br/>
 NodeSwap=true|false (ALPHA - 默认值=false)<br/>
 OpenAPIEnums=true|false (BETA - 默认值=true)<br/>
-OpenAPIV3=true|false (BETA - 默认值=true)<br/>
-PDBUnhealthyPodEvictionPolicy=true|false (ALPHA - 默认值=false)<br/>
+PDBUnhealthyPodEvictionPolicy=true|false (BETA - 默认值=true)<br/>
 PodAndContainerStatsFromCRI=true|false (ALPHA - 默认值=false)<br/>
 PodDeletionCost=true|false (BETA - 默认值=true)<br/>
 PodDisruptionConditions=true|false (BETA - 默认值=true)<br/>
 PodHasNetworkCondition=true|false (ALPHA - 默认值=false)<br/>
-PodSchedulingReadiness=true|false (ALPHA - 默认值=false)<br/>
+PodSchedulingReadiness=true|false (BETA - 默认值=true)<br/>
 ProbeTerminationGracePeriod=true|false (BETA - 默认值=true)<br/>
 ProcMountType=true|false (ALPHA - 默认值=false)<br/>
 ProxyTerminatingEndpoints=true|false (BETA - 默认值=true)<br/>
 QOSReserved=true|false (ALPHA - 默认值=false)<br/>
-ReadWriteOncePod=true|false (ALPHA - 默认值=false)<br/>
+ReadWriteOncePod=true|false (BETA - 默认值=true)<br/>
 RecoverVolumeExpansionFailure=true|false (ALPHA - 默认值=false)<br/>
 RemainingItemCount=true|false (BETA - 默认值=true)<br/>
 RetroactiveDefaultStorageClass=true|false (BETA - 默认值=true)<br/>
 RotateKubeletServerCertificate=true|false (BETA - 默认值=true)<br/>
-SELinuxMountReadWriteOncePod=true|false (ALPHA - 默认值=false)<br/>
-SeccompDefault=true|false (BETA - 默认值=true)<br/>
-ServerSideFieldValidation=true|false (BETA - 默认值=true)<br/>
+SELinuxMountReadWriteOncePod=true|false (BETA - 默认值=true)<br/>
+SecurityContextDeny=true|false (ALPHA - 默认值=false)<br/>
+ServiceNodePortStaticSubrange=true|false (ALPHA - 默认值=false)<br/>
 SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)<br/>
-StatefulSetAutoDeletePVC=true|false (ALPHA - 默认值=false)<br/>
-StatefulSetStartOrdinal=true|false (ALPHA - 默认值=false)<br/>
+StableLoadBalancerNodeSet=true|false (BETA - 默认值=true)<br/>
+StatefulSetAutoDeletePVC=true|false (BETA - 默认值=true)<br/>
+StatefulSetStartOrdinal=true|false (BETA - 默认值=true)<br/>
 StorageVersionAPI=true|false (ALPHA - 默认值=false)<br/>
 StorageVersionHash=true|false (BETA - 默认值=true)<br/>
 TopologyAwareHints=true|false (BETA - 默认值=true)<br/>
-TopologyManager=true|false (BETA - 默认值=true)<br/>
 TopologyManagerPolicyAlphaOptions=true|false (ALPHA - 默认值=false)<br/>
 TopologyManagerPolicyBetaOptions=true|false (BETA - 默认值=false)<br/>
 TopologyManagerPolicyOptions=true|false (ALPHA - 默认值=false)<br/>
 UserNamespacesStatelessPodsSupport=true|false (ALPHA - 默认值=false)<br/>
 ValidatingAdmissionPolicy=true|false (ALPHA - 默认值=false)<br/>
 VolumeCapacityPriority=true|false (ALPHA - 默认值=false)<br/>
+WatchList=true|false (ALPHA - 默认值=false)<br/>
 WinDSR=true|false (ALPHA - 默认值=false)<br/>
 WinOverlay=true|false (BETA - 默认值=true)<br/>
 WindowsHostNetwork=true|false (ALPHA - 默认值=true)
@ -2214,6 +2240,18 @@ in addition 'Connection: close' response header is set in order to tear down the
 </td>
 </tr>

+<tr>
+<td colspan="2">--shutdown-watch-termination-grace-period duration</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>
+<!--
+This option, if set, represents the maximum amount of grace period the apiserver will wait for active watch request(s) to drain during the graceful server shutdown window.
+-->
+此选项如果被设置了，则表示 API 服务器体面关闭服务器窗口内，等待活跃的监听请求耗尽的最长宽限期。
+</p></td>
+</tr>
+
 <tr>
 <td colspan="2">--storage-backend string</td>
 </tr>
--- a/content/zh-cn/docs/reference/kubernetes-api/common-definitions/status.md
+++ b/content/zh-cn/docs/reference/kubernetes-api/common-definitions/status.md
@ -158,10 +158,10 @@ guide. You can file document formatting bugs against the

    <!--
    UID of the resource. (when there is a single resource which can be described). 
-    More info: http://kubernetes.io/docs/user-guide/identifiers#uids 
+    More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#uids
    -->
    资源的 UID（当有单个可以描述的资源时）。
-    更多信息： http://kubernetes.io/docs/user-guide/identifiers#uids
+    更多信息： https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names#uids

 - **kind** (string)