Merge branch 'kubernetes:main' into pod-configmap-env-var-valueFrom

2022-03-29 19:02:58 +08:00 · 2022-03-29 19:02:58 +08:00 · fb58df71c6
parent 41336b8c06 bfca5b112f
commit fb58df71c6
34 changed files with 2473 additions and 1712 deletions
--- a/content/en/docs/concepts/architecture/garbage-collection.md
+++ b/content/en/docs/concepts/architecture/garbage-collection.md
@ -13,7 +13,7 @@ allows the clean up of resources like the following:
  * [Objects without owner references](#owners-dependents)
  * [Unused containers and container images](#containers-images)
  * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
-  * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
+  * [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
  * {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
    * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
    * On-premises when the cluster uses an addon similar to a cloud controller
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@ -134,7 +134,7 @@ Mi, Ki. For example, the following represent roughly the same value:
 128974848, 129e6, 129M,  128974848000m, 123Mi
 ```
-Take care about case for suffixes. If you request `400m` of memory, this is a request
+Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request
 for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
 or 400 megabytes (`400M`).
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@ -75,7 +75,7 @@ different Kubernetes components.
 | `CSIInlineVolume` | `true` | Beta | 1.16 | - |
 | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
 | `CSIMigration` | `true` | Beta | 1.17 | |
-| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
+| `CSIMigrationAWS` | `false` | Alpha | 1.14 | 1.16 |
 | `CSIMigrationAWS` | `false` | Beta | 1.17 | 1.22 |
 | `CSIMigrationAWS` | `true` | Beta | 1.23 | |
 | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 |
@ -580,39 +580,47 @@ Each feature gate is designed for enabling/disabling a specific feature:
  See [AppArmor Tutorial](/docs/tutorials/security/apparmor/) for more details.
 - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes
  that can be attached to a node.
-  See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) for more details.
+  See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)
- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for balanced resource allocation
+  for more details.
-  while scheduling. A node which has closer CPU, memory utilization, and volume count is favored by the scheduler
+- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for
-  while making decisions.
+  balanced resource allocation while scheduling. A node which has closer CPU,
  memory utilization, and volume count is favored by the scheduler while making decisions.
 - `BlockVolume`: Enable the definition and consumption of raw block devices in Pods.
  See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
  for more details.
- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a
+- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume
-  ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to
+  consisting of a ServiceAccountTokenVolumeProjection. Cluster admins can use metric
-  monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off
+  `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended
-  extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`.
+  tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with
  flag `--service-account-extend-token-expiration=false`.
  Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
-   for more details.
+  for more details.
 - `ControllerManagerLeaderMigration`: Enables Leader Migration for
  [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and
-  [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate
+  [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)
  which allows a cluster operator to live migrate
  controllers from the kube-controller-manager into an external controller-manager
  (e.g. the cloud-controller-manager) in an HA cluster without downtime.
 - `CPUManager`: Enable container level CPU affinity support, see
  [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies, experimental, Alpha-quality options
+- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies,
  experimental, Alpha-quality options
  This feature gate guards *a group* of CPUManager options whose quality level is alpha.
  This feature gate will never graduate to beta or stable.
- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies, experimental, Beta-quality options
+- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies,
  experimental, Beta-quality options
  This feature gate guards *a group* of CPUManager options whose quality level is beta.
  This feature gate will never graduate to stable.
 - `CPUManagerPolicyOptions`: Allow fine-tuning of CPUManager policies.
- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the
+- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime.
-  default max number of log files allowed for a container is 5. These values can be configured in the kubelet config.
+  The default max size of a log file is 10MB and the default max number of
-  See the [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) documentation for more details.
+  log files allowed for a container is 5.
  These values can be configured in the kubelet config.
  See [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
  for more details.
 - `CSIBlockVolume`: Enable external CSI volume drivers to support block storage.
-  See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)
+  See [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)
-  documentation for more details.
+  for more details.
 - `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in
  csi.storage.k8s.io.
 - `CSIInlineVolume`: Enable CSI Inline volumes support for pods.
@ -644,7 +652,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
  AzureDisk CSI plugin. Requires CSIMigration and CSIMigrationAzureDisk feature
  flags enabled and AzureDisk CSI plugin installed and configured on all nodes
  in the cluster. This flag has been deprecated in favor of the
-  `InTreePluginAzureDiskUnregister` feature flag which prevents the registration of in-tree AzureDisk plugin.
+  `InTreePluginAzureDiskUnregister` feature flag which prevents the registration
  of in-tree AzureDisk plugin.
 - `CSIMigrationAzureFile`: Enables shims and translation logic to route volume
  operations from the Azure-File in-tree plugin to AzureFile CSI plugin.
  Supports falling back to in-tree AzureFile plugin for mount operations to
@ -667,19 +676,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
  Does not support falling back for provision operations, for those the CSI
  plugin must be installed and configured. Requires CSIMigration feature flag
  enabled.
 - `csiMigrationRBD`: Enables shims and translation logic to route volume
  operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
  CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
  installed and configured in the cluster. This flag has been deprecated in
  favor of the
  `InTreePluginRBDUnregister` feature flag which prevents the registration of
  in-tree RBD plugin.
 - `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in
  kubelet and volume controllers and enables shims and translation logic to
  route volume operations from the GCE-PD in-tree plugin to PD CSI plugin.
  Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI
  plugin installed and configured on all nodes in the cluster. This flag has
-  been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which prevents the registration of in-tree GCE PD plugin.
+  been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which
  prevents the registration of in-tree GCE PD plugin.
 - `CSIMigrationOpenStack`: Enables shims and translation logic to route volume
  operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports
  falling back to in-tree Cinder plugin for mount operations to nodes that have
@ -692,7 +695,14 @@ Each feature gate is designed for enabling/disabling a specific feature:
  volume operations from the Cinder in-tree plugin to Cinder CSI plugin.
  Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder
  CSI plugin installed and configured on all nodes in the cluster. This flag has
-  been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag which prevents the registration of in-tree openstack cinder plugin.
+  been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag
  which prevents the registration of in-tree openstack cinder plugin.
 - `csiMigrationRBD`: Enables shims and translation logic to route volume
  operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
  CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
  installed and configured in the cluster. This flag has been deprecated in
  favor of the `InTreePluginRBDUnregister` feature flag which prevents the registration of
  in-tree RBD plugin.
 - `CSIMigrationvSphere`: Enables shims and translation logic to route volume operations
  from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back
  to in-tree vSphere plugin for mount operations to nodes that have the feature
@ -705,11 +715,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
  from the vSphere in-tree plugin to vSphere CSI plugin. Requires CSIMigration and
  CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and
  configured on all nodes in the cluster. This flag has been deprecated in favor
-  of the `InTreePluginvSphereUnregister` feature flag which prevents the registration of in-tree vsphere plugin.
+  of the `InTreePluginvSphereUnregister` feature flag which prevents the
  registration of in-tree vsphere plugin.
 - `CSIMigrationPortworx`: Enables shims and translation logic to route volume operations
  from the Portworx in-tree plugin to Portworx CSI plugin.
-  Requires Portworx CSI driver to be installed and configured in the cluster, and feature gate set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet configs.
+  Requires Portworx CSI driver to be installed and configured in the cluster.
- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
+- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in `csi.storage.k8s.io`.
 - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
  [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
  compatible volume plugin.
@ -737,7 +748,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
  version 1 of the same controller is selected.
 - `CustomCPUCFSQuotaPeriod`: Enable nodes to change `cpuCFSQuotaPeriod` in
  [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/).
- `CustomResourceValidationExpressions`: Enable expression language validation in CRD which will validate customer resource based on validation rules written in `x-kubernetes-validations` extension.
+- `CustomResourceValidationExpressions`: Enable expression language validation in CRD
  which will validate customer resource based on validation rules written in
  the `x-kubernetes-validations` extension.
 - `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
  Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
  for more details.
@ -820,7 +833,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
  host mounts, or containers that are privileged or using specific non-namespaced
  capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled
  if user namespace remapping is enabled in the Docker daemon.
- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs.
+- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not
  applied to Service ExternalIPs.
 - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
 - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features
  of normal volumes (can be provided by third-party storage vendors, storage capacity tracking,
@ -833,8 +847,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
  for more details.
 - `GracefulNodeShutdownBasedOnPodPriority`: Enables the kubelet to check Pod priorities
  when shutting down a node gracefully.
- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
+- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe.
- `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete` irrespective of PV-PVC deletion ordering.
+  See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
 - `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete`
  irrespective of PV-PVC deletion ordering.
 - `HPAContainerMetrics`: Enable the `HorizontalPodAutoscaler` to scale based on
  metrics from individual containers in target pods.
 - `HPAScaleToZero`: Enables setting `minReplicas` to 0 for `HorizontalPodAutoscaler`
@ -846,10 +862,19 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `HyperVContainer`: Enable
  [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
  for Windows containers.
- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying the OS of the pod
+- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying
-  authoritatively during the API server admission time. In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name` are `windows` and `linux`.
+  the OS of the pod authoritatively during the API server admission time.
  In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name`
  are `windows` and `linux`.
 - `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as
  immutable for better safety and performance.
 - `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
  controller to manage Pod completions per completion index.
 - `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
  `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
  to `IngressClass.spec.parameters`.
 - `Initializers`: Allow asynchronous coordination of object creation using the
  Initializers admission plugin.
 - `InTreePluginAWSUnregister`: Stops registering the aws-ebs in-tree plugin in kubelet
  and volume controllers.
 - `InTreePluginAzureDiskUnregister`: Stops registering the azuredisk in-tree plugin in kubelet
@ -866,13 +891,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
  and volume controllers.
 - `InTreePluginvSphereUnregister`: Stops registering the vSphere in-tree plugin in kubelet
  and volume controllers.
 - `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
  controller to manage Pod completions per completion index.
 - `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
  `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
  to `IngressClass.spec.parameters`.
 - `Initializers`: Allow asynchronous coordination of object creation using the
  Initializers admission plugin.
 - `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/)
  support for IPv6.
 - `JobMutableNodeSchedulingDirectives`: Allows updating node scheduling directives in
@ -890,17 +908,21 @@ Each feature gate is designed for enabling/disabling a specific feature:
  a file specified using a config file.
  See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
  for more details.
- `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials.
+- `KubeletCredentialProviders`: Enable kubelet exec credential providers for
- `KubeletInUserNamespace`: Enables support for running kubelet in a {{<glossary_tooltip text="user namespace" term_id="userns">}}.
+  image pull credentials.
 - `KubeletInUserNamespace`: Enables support for running kubelet in a
  {{<glossary_tooltip text="user namespace" term_id="userns">}}.
   See [Running Kubernetes Node Components as a Non-root User](/docs/tasks/administer-cluster/kubelet-in-userns/).
 - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
  to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
 - `KubeletPodResources`: Enable the kubelet's pod resources gRPC endpoint. See
  [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)
  for more details.
- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources `GetAllocatableResources` functionality.
+- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources
-  This API augments the [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)
+  `GetAllocatableResources` functionality. This API augments the
-  with informations about the allocatable resources, enabling clients to properly track the free compute resources on a node.
+  [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)
  with informations about the allocatable resources, enabling clients to properly
  track the free compute resources on a node.
 - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and
  node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the
  feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
@ -919,18 +941,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
  based on logarithmic bucketing of pod timestamps.
 - `MemoryManager`: Allows setting memory affinity for a container based on
  NUMA topology.
- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using cgroup v2 memory controller.
+- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using
  cgroup v2 memory controller.
 - `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type
  Service instance.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
 - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
  For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable {{< glossary_tooltip text="label" term_id="label" >}}
+- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable
-  `kubernetes.io/metadata.name` on all namespaces, containing the namespace name.
+  {{< glossary_tooltip text="label" term_id="label" >}} `kubernetes.io/metadata.name`
- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port.
+  on all namespaces, containing the namespace name.
 - `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects,
  allowing the selection of a port range instead of a single port.
 - `NodeDisruptionExclusion`: Enable use of the Node label `node.kubernetes.io/exclude-disruption`
  which prevents nodes from being evacuated during zone failures.
- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
+- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used
  as a node health signal.
 - `NodeSwap`: Enable the kubelet to allocate swap memory for Kubernetes workloads on a node.
  Must be used with `KubeletConfiguration.failSwapOn` set to false.
  For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory)
@ -938,23 +964,23 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the 
  spec returned from the API server.
 - `OpenAPIV3`: Enables the API server to publish OpenAPI v3.
 - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
  being deleted when it is still used by any Pod.
 - `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
   feature which allows users to influence ReplicaSet downscaling order.
 - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
  Pod affinity has to be specified if requesting a `local` volume.
- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and pod stats from the CRI container runtime
+- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and
-   rather than gathering them from cAdvisor.
+  pod stats from the CRI container runtime rather than gathering them from cAdvisor.
 - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature.
- `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
+- `PodAffinityNamespaceSelector`: Enable the
-  and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features.
+  [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
  and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota)
  quota scope features.
 - `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/)
  feature to account for pod overheads.
 - `PodPriority`: Enable the descheduling and preemption of Pods based on their
  [priorities](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
 - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending
-  Pod readiness evaluation.  See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
+  Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
  for more details.
 - `PodSecurity`: Enables the `PodSecurity` admission plugin.
 - `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
@ -965,25 +991,27 @@ Each feature gate is designed for enabling/disabling a specific feature:
  the cluster.
 - `ProbeTerminationGracePeriod`: Enable [setting probe-level
  `terminationGracePeriodSeconds`](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)
-   on pods.  See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period) for more details.
+  on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)
  for more details.
 - `ProcMountType`: Enables control over the type proc mounts for containers
  by setting the `procMount` field of a SecurityContext.
 - `ProxyTerminatingEndpoints`: Enable the kube-proxy to handle terminating
  endpoints when `ExternalTrafficPolicy=Local`.
 - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
  being deleted when it is still used by any Pod.
 - `QOSReserved`: Allows resource reservations at the QoS level preventing pods
  at lower QoS levels from bursting into resources requested at higher QoS levels
  (memory only for now).
 - `ReadWriteOncePod`: Enables the usage of `ReadWriteOncePod` PersistentVolume
  access mode.
- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller sizes so as they can recover from previously issued
+- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller
-  volume expansion failures. See
+  sizes so as they can recover from previously issued volume expansion failures.
-  [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)
+  See [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)
  for more details.
 - `RemainingItemCount`: Allow the API servers to show a count of remaining
  items in the response to a
  [chunking list request](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks).
- `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and
+- `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and ListMeta.
  ListMeta.
 - `RequestManagement`: Enables managing request concurrency with prioritization and fairness
  at each API server. Deprecated by `APIPriorityAndFairness` since 1.17.
 - `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that
@ -998,7 +1026,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
  [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
  for more details.
 - `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
-  See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
+  See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
  for more details.
 - `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
  See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
  for more details.
@ -1010,7 +1039,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
  instead of the DaemonSet controller.
 - `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service,
  Endpoints, EndpointSlice, and NetworkPolicy definitions.
- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile for all workloads.
+- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile
  for all workloads.
  The seccomp profile is specified in the `securityContext` of a Pod and/or a Container.
 - `SelectorIndex`: Allows label and field based indexes in API server watch
  cache to accelerate list operations.
@ -1024,7 +1054,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ServiceInternalTrafficPolicy`: Enables the `internalTrafficPolicy` field on Services
 - `ServiceLBNodePortControl`: Enables the `allocateLoadBalancerNodePorts` field on Services.
 - `ServiceLoadBalancerClass`: Enables the `loadBalancerClass` field on Services. See
-  [Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class) for more details.
+  [Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class)
  for more details.
 - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
 - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers
  created by a cloud provider. A node is eligible for exclusion if labelled with
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@ -126,7 +126,6 @@ of provisioning.
 2. [Token authentication file](#token-authentication-file)
 Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
 Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
 Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that:
   * For external metrics, this is the `external.metrics.k8s.io` API.  It may be provided by the custom metrics adapters provided above.
 For more information on these different metrics paths and how they differ please see the relevant design proposals for
-[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
+[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
-[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
+[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
-and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
+and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
 For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
 and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
--- a/content/ja/docs/tasks/debug-application-cluster/audit.md
+++ b/content/ja/docs/tasks/debug-application-cluster/audit.md
@ -149,6 +149,7 @@ volumeMounts:
 最後に`hostPath`を設定します:
 ```yaml
 ...
 volumes:
 - name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
@ -158,7 +159,6 @@ volumeMounts:
  hostPath:
    path: /var/log/audit.log
    type: FileOrCreate
 ```
 ### Webhookバックエンド
--- a/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md
+++ b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md
@ -3,7 +3,6 @@ layout: blog
 title: "Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim"
 date: 2022-02-17
 slug: dockershim-faq
 aliases: [ '/dockershim' ]
 ---
 **Esta é uma atualização do artigo original [FAQ sobre a depreciação do Dockershim](/blog/2020/12/02/dockershim-faq/),
--- a/content/ru/community/static/community-values.md
+++ b/content/ru/community/static/community-values.md
@ -25,4 +25,4 @@
 Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.
-**"Culture eats strategy for breakfast."   --Peter Drucker**
+**"Культура съедает стратегию на завтрак" — Питер Друкер**
--- a/content/ru/docs/concepts/architecture/_index.md
+++ b/content/ru/docs/concepts/architecture/_index.md
@ -2,6 +2,5 @@
 title: "Кластерная Архитектура"
 weight: 30
 description: >
-  The architectural concepts behind Kubernetes.
+  Архитектурные концепции, лежащие в основе Kubernetes.
---
+---
--- a/content/ru/docs/concepts/architecture/cloud-controller.md
+++ b/content/ru/docs/concepts/architecture/cloud-controller.md
@ -8,7 +8,7 @@ weight: 40
 {{< feature-state state="beta" for_k8s_version="v1.11" >}}
-Технологии облачной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
+Технологии облачной инфраструктуры позволяют запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облачных контроллеров">}} 
@ -33,7 +33,7 @@ weight: 40
 Контроллеры внутри диспетчера облачных контроллеров включают в себя:
-### Контролер узла
+### Контроллер узла
 Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облачной инфраструктуре. Контроллер узла получает информацию о работающих хостах внутри вашей арендуемой инфраструктуры облачного провайдера.
 Контроллер узла выполняет следующие функции:
@ -41,13 +41,13 @@ weight: 40
 1. Инициализация объектов узла для каждого сервера, которые контроллер получает через API облачного провайдера.
 2. Аннотирование и маркировка объектов узла специфичной для облака информацией, такой как регион узла и доступные ему ресурсы (процессор, память и т.д.).
 3. Получение имени хоста и сетевых адресов.
-4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удлаяет объект узла из вашего Kubernetes кластера.
+4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удаляет объект узла из вашего Kubernetes кластера.
 Некоторые облачные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла.
-### Контролер маршрута
+### Контроллер маршрута
-Контролер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
+Контроллер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
 В зависимости от облачного провайдера, контроллер маршрута способен также выделять блоки IP-адресов для сети Pod-ов.
@ -61,7 +61,7 @@ weight: 40
 ### Контроллер узла {#authorization-node-controller}
-Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла.
+Контроллер узла работает только с объектом узла. Он требует полного доступа на чтение и изменение объектов узла.
 `v1/Node`:
@ -73,9 +73,9 @@ weight: 40
 - Watch
 - Delete
-### Контролер маршрута {#authorization-route-controller}
+### Контроллер маршрута {#authorization-route-controller}
-Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
+Контроллер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
 `v1/Node`:
@ -99,7 +99,7 @@ weight: 40
 ### Другие {#authorization-miscellaneous}
-Реализация ядра диспетчера облачных контроллеров требует доступ для создания создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
+Реализация ядра диспетчера облачных контроллеров требует доступ для создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
 `v1/Event`:
@ -111,7 +111,7 @@ weight: 40
 - Create
-The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
+{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@ -179,7 +179,7 @@ rules:
 ## {{% heading "whatsnext" %}}
 [Администрирование диспетчера облачных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
-содержит инструкции по запуску и управлению диспетером облачных контроллеров.
+содержит инструкции по запуску и управлению диспетчером облачных контроллеров.
 Хотите знать, как реализовать свой собственный диспетчер облачных контроллеров или расширить проект?
--- a/content/ru/docs/concepts/architecture/garbage-collection.md
+++ b/content/ru/docs/concepts/architecture/garbage-collection.md
@ -23,7 +23,7 @@ weight: 50
 Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). 
 Ссылки владельцев сообщают плоскости управления какие объекты зависят от других.
 Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API
-клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
+клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
 Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/)
 которые также используют некоторые ресурсы. Например, рассмотрим
@ -36,15 +36,15 @@ Kubernetes использует ссылки владельцев, чтобы п
 {{< note >}}
 Ссылки на владельцев перекрестных пространств имен запрещены по дизайну.
 Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен.
-Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости.
+Владелец пространства имен **должен** быть в том же пространстве имен, что и зависимости.
-Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
+Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
 Зависимости области действия кластер может указывать только владельцев области действия кластера.
 В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, 
 тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.
 В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`,
-или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости.
+или зависящие от области действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающее о недействительной зависимости.
 Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
 {{< /note >}}
@ -52,22 +52,22 @@ Kubernetes использует ссылки владельцев, чтобы п
 Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: 
-  * Каскадное удалени Foreground
+  * Каскадное удаление Foreground
  * Каскадное удаление Background
 Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}. 
-### Каскадное удалени Foreground {#foreground-deletion}
+### Каскадное удаление Foreground {#foreground-deletion}
-В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: 
+В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: 
  * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp`
    время, когда объект был помечен для удаления.
  * Сервер Kubernetes API так же устанавливает метку  `metadata.finalizers`для поля
    `foregroundDeletion`. 
-  * Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться
+  * Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться
-После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. 
+После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. 
 Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`.
 Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).
@ -80,16 +80,16 @@ Kubernetes проверяет и удаляет объекты, на котор
 ### Осиротевшие зависимости
-Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
+Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшими* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
-## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images}
+## Сбор мусора из неиспользуемых контейнеров и изображений {#containers-images}
 {{<glossary_tooltip text="kubelet" term_id="kubelet">}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут
 нарушить поведение kubelet и удалить контейнеры, которые должны существовать. 
-Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте 
+Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте 
 kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/)
-и измените параметры, связанные со сборшиком мусора используя тип ресурса
+и измените параметры, связанные со сборщиком мусора используя тип ресурса
 [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration).
 ### Жизненный цикл контейнерных образов Container image lifecycle
@ -99,19 +99,19 @@ Kubernetes управляет жизненным циклом всех обра
  * `HighThresholdPercent`
  * `LowThresholdPercent`
-Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения  `LowThresholdPercent`.
+Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения  `LowThresholdPercent`.
 ### Сборщик мусора контейнерных образов {#container-image-garbage-collection}
-kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: 
+Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: 
  * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`.
-  * `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`.
+  * `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`.
  * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. 
 В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. 
-`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
+`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
 Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`.
 {{<note>}}
@ -120,7 +120,7 @@ Kubelet собирает мусор только у контейнеров, ко
 ## Настройка сборщик мусора {#configuring-gc}
-Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора:
+Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора:
  * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/)
  * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/)
--- a/content/ru/docs/concepts/architecture/nodes.md
+++ b/content/ru/docs/concepts/architecture/nodes.md
@ -32,7 +32,7 @@ Kubernetes запускает ваши приложения, помещая ко
 1. Kubelet на узле саморегистрируется в плоскости управления
 2. Вы или другой пользователь вручную добавляете объект Узла
-После того, как вы создадите объект Узла или kubelet на узле самозарегистируется,
+После того как вы создадите объект Узла или kubelet на узле самозарегистируется,
 плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы
 попробуете создать Узел при помощи следующего JSON манифеста:
@ -50,9 +50,9 @@ Kubernetes запускает ваши приложения, помещая ко
 ```
 Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет,
-что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла.
+что kubelet зарегистрировался на API сервере, который совпадает со значением поля `metadata.name` Узла.
 Если узел здоров (если все необходимые сервисы запущены),
-он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера
+он имеет право на запуск Пода. В противном случае этот узел игнорируется для любой активности кластера
 до тех пор, пока он не станет здоровым.
 {{< note >}}
@ -62,13 +62,13 @@ Kubernetes сохраняет объект для невалидного Узл
 остановить проверку доступности узла.
 {{< /note >}}
-Имя объекта Узла дожно быть валидным
+Имя объекта Узла должно быть валидным
 [именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns).
 ### Саморегистрация Узлов
 Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться
-зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов.
+зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большинством дистрибутивов.
 Для саморегистрации kubelet запускается со следующими опциями:
@ -94,16 +94,16 @@ kubelet'ы имеют право только создавать/изменят
 Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`.
 Вы можете изменять объекты Узла независимо от настройки  `--register-node`.
-Например, вы можете установить метки на существующем Узле или пометить его неназначаемым.
+Например, вы можете установить метки на существующем Узле или пометить его не назначаемым.
 Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием.
-Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов.
+Например, вы можете ограничить Под, иметь право на запуск только на группе доступных узлов.
-Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле,
+Маркировка узла как не назначаемого предотвращает размещение планировщиком новых подов на этом Узле,
 но не влияет на существующие Поды на Узле. Это полезно в качестве
 подготовительного шага перед перезагрузкой узла или другим обслуживанием.
-Чтобы отметить Узел неназначемым, выполните:
+Чтобы отметить Узел не назначаемым, выполните:
 ```shell
 kubectl cordon $NODENAME
@ -111,7 +111,7 @@ kubectl cordon $NODENAME
 {{< note >}}
 Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают
-запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла,
+запуск на не назначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла,
 которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений.
 {{< /note >}}
@ -157,7 +157,7 @@ kubectl describe node <insert-node-name-here>
 {{< note >}}
 Если вы используете инструменты командной строки для вывода сведений об блокированном узле,
 то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API;
-вместо этого блокированные узлы помечены как Неназначемые в их спецификации.
+вместо этого блокированные узлы помечены как Не назначаемые в их спецификации.
 {{< /note >}}
 Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел:
@ -203,8 +203,8 @@ kubectl describe node <insert-node-name-here>
 Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов,
 которые могут быть запланированы на узле.
-Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле.
+Поля в блоке capacity указывают общее количество ресурсов, которые есть на Узле.
-Блок allocatable указывает количество ресурсовна Узле,
+Блок allocatable указывает количество ресурсов на Узле,
 которые доступны для использования обычными Подами.
 Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле.
@ -212,7 +212,7 @@ kubectl describe node <insert-node-name-here>
 ### Информация (Info)
 Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС.
-Эта информация соберается Kubelet'ом на узле.
+Эта информация собирается Kubelet'ом на узле.
 ### Контроллер узла
@ -247,16 +247,16 @@ ConditionUnknown, когда узел становится недоступны
 [Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
 Каждый узел имеет связанный с ним Lease объект в `kube-node-lease`
 {{< glossary_tooltip term_id="namespace" text="namespace">}}.
-Lease - это легковестный ресурс, который улучшает производительность
+Lease - это легковесный ресурс, который улучшает производительность
 сердцебиений узла при масштабировании кластера.
-Kubelet отвечает за создание и обновление `NodeStatus` и  Lease объекта.
+Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта.
 - Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса,
-  либо если в течение настронного интервала обновления не было. По умолчанию
+  либо если в течение настроенного интервала обновления не было. По умолчанию
  интервал для обновлений `NodeStatus` составляет 5 минут (намного больше,
  чем 40-секундный стандартный таймаут для недоступных узлов).
- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд
+- Kubelet создает и затем обновляет свой Lease объект каждый 10 секунд
  (интервал обновления по умолчанию). Lease обновления происходят независимо от
  `NodeStatus` обновлений. Если обновление Lease завершается неудачно,
  kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами.
@ -265,7 +265,7 @@ Kubelet отвечает за создание и обновление `NodeStat
 В большинстве случаев контроллер узла ограничивает скорость выселения
 до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает,
-что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд.
+что он не выселяет поды с узлов быстрее чем с одного узла в 10 секунд.
 Поведение выселения узла изменяется, когда узел в текущей зоне доступности
 становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне
@ -288,26 +288,26 @@ Kubelet отвечает за создание и обновление `NodeStat
 выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны
 полностью нездоровы (т.е. в кластере нет здоровых узлов).  В таком случае
 контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру,
-и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено.
+и останавливает все выселения, пока какое-нибудь подключение не будет восстановлено.
 Контроллер узла также отвечает за выселение подов, запущенных на узлах с
 `NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям.
 Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}}
-соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает,
+соответствующие проблемам узла, таким как узел недоступен или не готов. Это означает,
 что планировщик не будет размещать поды на нездоровых узлах.
 {{< caution >}}
-`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов,
+`kubectl cordon` помечает узел как 'не назначаемый', что имеет побочный эффект от контроллера сервисов,
 удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право,
-эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов).
+эффективно убирая входящий трафик балансировщика нагрузки с блокированного узла(ов).
 {{< /caution >}}
 ### Емкость узла
 Объекты узла отслеживают информацию о емкости ресурсов узла (например,
 объем доступной памяти и количество CPU).
-Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают
+Узлы, которые [самостоятельно зарегистрировались](#саморегистрация-узлов), сообщают
-о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла)
+о своей емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла)
 добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении.
 {{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует,
@ -318,7 +318,7 @@ Kubelet отвечает за создание и обновление `NodeStat
 а также исключает любые процессы, запущенные вне контроля kubelet.
 {{< note >}}
-Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел
+Если вы явно хотите зарезервировать ресурсы для процессов, не связанных с Подами, смотрите раздел
 [зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
 {{< /note >}}
@ -339,4 +339,4 @@ Kubelet отвечает за создание и обновление `NodeStat
 * Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
 of the architecture design document.
 * Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/).
-* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
+* Подробнее про [авто масштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
--- a/content/ru/docs/concepts/cluster-administration/_index.md
+++ b/content/ru/docs/concepts/cluster-administration/_index.md
@ -11,7 +11,7 @@ no_list: true
 ---
 <!-- overview -->
-Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями] (/docs/concepts/) Kubernetes. 
+Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями](/docs/concepts/) Kubernetes. 
 <!-- body -->
@ -19,19 +19,19 @@ no_list: true
 См. Руководства в разделе [настройка](/docs/setup/) для получения примеров того, как планировать, устанавливать и настраивать кластеры Kubernetes. Решения, перечисленные в этой статье, называются *distros*.
-   {{< note  >}}
+   {{< note >}}
   не все дистрибутивы активно поддерживаются. Выбирайте дистрибутивы, протестированные с последней версией Kubernetes.
   {{< /note >}}
 Прежде чем выбрать руководство, вот некоторые соображения:
- - Вы хотите опробовать Kubernetes на вашем компьюторе или собрать многоузловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд.
+ - Вы хотите опробовать Kubernetes на вашем компьютере или собрать много узловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд.
- - будете ли вы использовать **размещенный кластер Kubernetes**, такой как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**?
+ - Будете ли вы использовать **размещенный кластер Kubernetes**, такой, как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**?
- - Будет ли ваш кластер **в помещений** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров.
+ - Будет ли ваш кластер **в помещении** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров.
- - **Если вы будете настроаивать Kubernetes в помещений (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего.
+ - **Если вы будете настраивать Kubernetes в помещении (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего.
- - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **вирутальных машинах (VMs)**?
+ - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **виртуальных машинах (VMs)**?
- - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают болле широкий выбор.
+ - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают более широкий выбор.
- - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходивые для запуска кластера.
+ - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходимые для запуска кластера.
 ## Управление кластером
@ -54,7 +54,7 @@ no_list: true
 * [Использование контроллеров допуска](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
-* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctlинструмент командной строки для установки параметров ядра.
+* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctl инструмент командной строки для установки параметров ядра.
 * [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes.
--- a/content/ru/docs/concepts/cluster-administration/addons.md
+++ b/content/ru/docs/concepts/cluster-administration/addons.md
@ -13,33 +13,33 @@ content_type: concept
 <!-- body -->
-## Сеть и сетевыя политика
+## Сеть и сетевая политика
 * [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI.
 * [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных.
 * [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer).
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политик.
+* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политику.
 * [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI.
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave.
-* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric are интегрированы с системами оркестровки, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/pod-ов и рабочих нагрузок без операционной системы.
+* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric интегрированы с системами оркестрации, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/подов и рабочих нагрузок без операционной системы.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes.
-* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes pod-ов.
+* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes подов.
-* Multus - это плагин Multi для поддержки нексольких сетейв Kubernetes для поддержки всех CNI плагинов (наприме: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes.
+* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) - это плагин Multi для работы с несколькими сетями в Kubernetes, который поддерживает большинство самых популярных [CNI](https://github.com/containernetworking/cni) (например: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes.
-* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуалной сети a появившейся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS.
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуальной сети, появившийся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS.
-* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложеных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами.
+* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложенных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift.
-* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes Pod-ами и не Kubernetes окружением с отображением и мониторингом безопасности.
+* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes подами и не Kubernetes окружением, с отображением и мониторингом безопасности.
-* [Romana](https://romana.io) - это сетевое решение уровня 3 для pod сетей, которое также поддерживает  [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](https://romana.io) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize).
-* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) обеспечивает сетевуюи политику сетей, будет работать в сетевого раздела и не требует внешней базы данных.
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) предоставляет сеть и обеспечивает сетевую политику, будет работать на обеих сторонах сетевого раздела и не требует внешней базы данных.
 ## Обнаружение служб
-* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для pod-ов.
+* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для подов.
 ## Визуализация и контроль
 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes.
-* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, pod-ов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно.
+* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, подов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно.
 ## Инфраструктура
@ -49,4 +49,4 @@ content_type: concept
 В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений.
-Ссылки на те, в хорошем состоянии, должны быть здесь. PR приветствуются!
+Ссылки на те, в хорошем состоянии, должны быть здесь. Пул реквесты приветствуются!
--- a/content/ru/docs/concepts/overview/kubernetes-api.md
+++ b/content/ru/docs/concepts/overview/kubernetes-api.md
@ -36,7 +36,7 @@ Kubernetes как таковой состоит из множества комп
 Все детали API документируется с использованием [OpenAPI](https://www.openapis.org/).
 Начиная с Kubernetes 1.10, API-сервер Kubernetes основывается на спецификации OpenAPI через конечную точку `/openapi/v2`.
-Нужный формат устанавливается через HTTP-заголовоки:
+Нужный формат устанавливается через HTTP-заголовки:
 Заголовок | Возможные значения
 ------ | ---------------
@ -61,11 +61,11 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
 Чтобы упростить удаления полей или изменение ресурсов, Kubernetes поддерживает несколько версий API, каждая из которых доступна по собственному пути, например, `/api/v1` или `/apis/extensions/v1beta1`.
-Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются   и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата.
+Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата.
-Обратите внимание, что версиоирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения.
+Обратите внимание, что версионирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения.
-Разные версии API имеют характеризуются разной уровнем стабильностью и поддержкой. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение:
+Разные версии API характеризуются разными уровнями стабильности и поддержки. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение:
 - Альфа-версии:
  - Названия версий включают надпись `alpha` (например, `v1alpha1`).
@ -79,7 +79,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
  - Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться.
  - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность.
  - Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение.
-  - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
+  - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
 - Стабильные версии:
  - Имя версии `vX`, где `vX` — целое число.
  - Стабильные версии функциональностей появятся в новых версиях.
@ -113,5 +113,3 @@ DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies и Re
 Например: чтобы включить deployments и daemonsets, используйте флаг `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
 {{< note >}}Включение/отключение отдельных ресурсов поддерживается только в API-группе `extensions/v1beta1` по историческим причинам.{{< /note >}}
--- a/content/ru/docs/contribute/advanced.md
+++ b/content/ru/docs/contribute/advanced.md
@ -1,5 +1,5 @@
 ---
-title: Участие для опытных
+title: Существенный вклад
 slug: advanced
 content_type: concept
 weight: 30
@ -22,20 +22,20 @@ weight: 30
 - Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/).
    - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`).
    - Проверяйте столько пулреквестов, сколько сможете.
- Проследить, что CLA подписан каждым участником.
+- Проследите, что CLA подписан каждым участником.
    - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
-    - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA.
+    - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, подписать его.
 - Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп.
    - Предложить исправления для измененного контента в PR.
    - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы.
-    - Добавьте нужны метки с `sig/`.
+    - Добавьте нужные метки с `sig/`.
-    - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла.
+    - Если нужно, то назначьте рецензентов из секции `reviewers:` в верхней части файла.
    - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR.
    - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены.
    - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием.
    - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты.
 - Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты.
- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs.
+- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использованию метаданных SIG Docs.
 ### Полезные ссылки на GitHub для дежурных
@ -43,9 +43,9 @@ weight: 30
 - [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA.
 **Не проверяйте PR, если их авторы не подписали CLA!**
- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста.
+- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужна проверка с технической точки зрения, попросите её провести одного из рецензентов, которого предложил бот. Если требуется просмотр пулреквеста со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста.
- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`.
+- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слиянию, оставьте комментарий с текстом `/approve`.
- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]).
+- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]).
 - [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @<meister's_github-username>`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку.
 ### Когда закрывать пулреквесты
@ -57,7 +57,7 @@ weight: 30
 - Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель.
-Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад.
+Не бойтесь закрывать пулреквесты. Участники с лёгкостью могут открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулирует автора возобновить и завершить свою работу до конца.
 Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR.
@ -71,8 +71,8 @@ weight: 30
 [Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения.
-После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+Если вы давно начали работать над документацией Kubernetes, у вас наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по содержанию](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com).
+Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их в канале `#sig-docs` в [официальном Slack](https://kubernetes.slack.com).
 Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing.
@ -84,11 +84,11 @@ weight: 30
 Представитель SIG Docs для данного выпуска координирует следующие задачи:
- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск.
+- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивающих документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск.
- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске.
+- Регулярное посещение встречи sig-release и обновление информации о статусе документации к выпуску.
 - Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности.
 - Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска.
- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing).
+- Консультирование других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing).
 - Публикация изменений в документации, связанные с выпуском при размещении артефактов.
 Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs.
@ -101,10 +101,10 @@ weight: 30
 Обязанности амбассадоров новых участников включают в себя:
- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com).
+- Отвечать на вопросы новых участников в [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com).
 - Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками.
 - Консультировать новых участников в их PR.
- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes.
+- Помогать новым участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes.
 - [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes.
 Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com).
@ -115,7 +115,7 @@ weight: 30
 Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами.
-Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes.
+Новые участники документации могут найти спонсоров в канале #sig-docs [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes.
 ## Сопредседатель SIG
@ -125,9 +125,9 @@ weight: 30
 Сопредседатели должны соответствовать следующим требованиям:
- Быть утверждающим SIG Docs не меньше 6 месяцев
+- Быть утверждающими SIG Docs не меньше 6 месяцев.
- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска
+- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопроводить два выпуска.
- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог
+- Понимать рабочие процессы и инструменты SIG Docs: git, Hugo, локализация, блог.
 - Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
 - Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей.
@ -137,13 +137,13 @@ weight: 30
 Обязанности включают в себя:
- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию
+- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию.
- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG
+- Быть примером соблюдения [норм поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG.
- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию
+- Изучать и внедрять передовые практики для SIG-группы, обновляя рекомендации по участию.
- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое
+- Планировать и проверять встречи SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое.
- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях
+- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях.
 - Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei.
- Поддерживать нормальную работу SIG
+- Поддерживать нормальную работу SIG.
 ### Проведение продуктивных встреч
@ -155,33 +155,33 @@ weight: 30
 **Сформулируйте четкую повестку дня**:
- Определите конкретную цель встречи
+- Определите конкретную цель встречи.
- Опубликуйте программу дня заранее
+- Опубликуйте программу дня заранее.
 Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings".
 **Работайте вместе для создания точных примечания**:
- Запишите обсуждение встречи
+- Запишите обсуждение встречи.
- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому
+- Подумайте над тем, чтобы делегировать роль стенографиста кому-нибудь другому.
 **Определяйте решения по пунктам повестки четко и точно**:
- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения
+- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения.
 **Руководите обсуждением, когда это необходимо**:
- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему
+- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему.
- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей
+- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей.
 **Уважайте время людей**:
- Начинайте и заканчивайте встречи своевременно
+- Начинайте и заканчивайте встречи своевременно.
 **Используйте Zoom эффективно**:
- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md)
+- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md).
- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего
+- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего.
 <img src="/images/docs/contribute/claim-host.png" width="75%" alt="Исполнение роли ведущего в Zoom" />
@ -192,5 +192,3 @@ weight: 30
 Если нужно остановить запись, нажмите на кнопку Stop.
 Запись автоматически загрузится на YouTube.
--- a/content/ru/docs/contribute/style/content-guide.md
+++ b/content/ru/docs/contribute/style/content-guide.md
@ -25,72 +25,72 @@ card:
 ### Контент, полученный из двух источников
-Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двумя источниками**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность.
+Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двух источников**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность.
 Перед добавлением контента, задайте себе вопрос:
- Новая информация относится к действующему проекту CNCF ИЛИ проекту в организациях на GitHub kubernetes или kubernetes-sigs?
+- Новая информация относится к действующему проекту CNCF или проекту в организациях на GitHub kubernetes или kubernetes-sigs?
    - Если да, то:
        - У этого проекта есть собственная документация?
-            - если да, то укажите ссылку на документацию проекта в документации Kubernetes
+            - если да, то укажите ссылку на документацию проекта в документации Kubernetes.
-            - если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes
+            - если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes.
    - Если нет, то:
        - Остановитесь!
-            - Добавление информации по продуктам от других разработчиков не допускается
+            - Добавление информации о продуктах от других разработчиков не допускается.
            - Не разрешено ссылаться на документацию и сайты сторонних разработчиков.
 ### Разрешенная и запрещённая информация
 Есть несколько условий, когда в документации Kubernetes может быть информация, относящиеся не к проектам Kubernetes.
-Ниже перечислены основные категории по содержанию проектов, не касающихся к Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет:
+Ниже перечислены основные категории по содержанию проектов, не касающихся Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет:
-1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes
+1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes.
    - Разрешено:
-        - Ссылаться на документацию на CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs
+        - Ссылаться на документацию CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs.
-            - Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube
+            - Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube.
-        - Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций
+        - Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций.
-            - Пример: добавление инструкций по установке и решению неполадок [kubadm](https://github.com/kubernetes/kubeadm)
+            - Пример: добавление инструкций по установке и решению неполадок [kubeadm](https://github.com/kubernetes/kubeadm).
    - Запрещено:
-        - Добавление информацию, которая повторяет документацию в другом репозитории
+        - Добавление информации, которая дублирует документацию в другом репозитории.
            - Примеры:
-                - Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции
+                - Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции.
-                - Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах
+                - Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах.
                - Добавление инструкций по установке Kubernetes в промышленных окружениях, используя разные проекты:
-                     -Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому все содержимое находится репозитории разработчика.
+                    - Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому всё содержимое находится в репозитории разработчика.
                    - У проекта [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) есть инструкции по установке и руководства в GitHub-репозитории.
-                    - У проекта [Kubespray](https://kubespray.io) есть собственная документация
+                    - У проекта [Kubespray](https://kubespray.io) есть собственная документация.
-        - Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs.
+        - Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектами или проектом в GitHub-организациях kubernetes, или kubernetes-sigs.
-        - Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubnetes-sigs, если у проекта есть собственная документация
+        - Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubernetes-sigs, если у проекта есть собственная документация.
-1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан
+1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан.
    Добавление такого типа информации в документацию Kubernetes не допускается.
-1. Информация стороннему проекту
+1. Информация стороннему проекту.
    - Разрешено:
-        - Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект
+        - Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект.
    - Запрещено:
-        - Добавление информации по продукту определённого разработчика
+        - Добавление информации по продукту определённого разработчика.
-        - Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs
+        - Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubernetes-sigs.
-        - Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория
+        - Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория.
-            - Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes
+            - Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes.
-1. Только ссылки на сторонний проект
+1. Только ссылки на сторонний проект.
    - Разрешено:
-        - Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs
+        - Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs.
-            - Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs
+            - Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs.
-        - Добавление ссылок на действующие CNCF-проекты
+        - Добавление ссылок на действующие CNCF-проекты.
-            - Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF
+            - Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF.
    - Запрещено:
-        - Ссылаться на продукты стороннего разработчика
+        - Ссылаться на продукты стороннего разработчика.
-        - Ссылаться на архивированные проекты CNCF
+        - Ссылаться на прекращенные проекты CNCF.
-        - Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs
+        - Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs.
-        - Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes или kubernetes-sigs.
+        - Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes, или kubernetes-sigs.
-1. Содержание учебных курсов
+1. Содержание учебных курсов.
    - Разрешено:
-        - Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation)
+        - Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation).
-            - Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) в [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
+            - Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) и [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/).
    - Запрещено:
-        - Ссылаться на учебныЕе онлайн-курсы, вне CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент
+        - Ссылаться на учебные онлайн-курсы, не относящиеся к CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент.
            - Пример: добавление ссылок на учебные руководства или курсы Kubernetes на Medium, KodeKloud, Udacity, Coursera, learnk8s и т.д.
-        - Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации
+        - Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации.
-            - Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)
+            - Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) и [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)
 Если у вас есть вопросы по поводу допустимого контента, присоединяйтесь к каналу #sig-docs в [Slack Kubernetes](http://slack.k8s.io/)!
--- a/content/ru/docs/reference/kubectl/cheatsheet.md
+++ b/content/ru/docs/reference/kubectl/cheatsheet.md
@ -235,7 +235,7 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl
 kubectl label pods my-pod new-label=awesome                      # Добавить метку
 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Добавить аннотацию
-kubectl autoscale deployment foo --min=2 --max=10                # Автоматически промасштабировать развёртывание "foo"
+kubectl autoscale deployment foo --min=2 --max=10                # Автоматически масштабировать развёртывание "foo" в диапазоне от 2 до 10 подов
 ```
 ## Обновление ресурсов
@ -269,10 +269,10 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Использовать
 ## Масштабирование ресурсов
 ```bash
-kubectl scale --replicas=3 rs/foo                                 # Промасштабировать набор реплик (replicaset) 'foo' до 3
+kubectl scale --replicas=3 rs/foo                                 # Масштабирование набора реплик (replicaset) 'foo' до 3
-kubectl scale --replicas=3 -f foo.yaml                            # Промасштабировать ресурс в "foo.yaml" до 3
+kubectl scale --replicas=3 -f foo.yaml                            # Масштабирование ресурса в "foo.yaml" до 3
-kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Если количество реплик в развёртывании mysql равен 2, промасштабировать его до 3
+kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3
-kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Промасштабировать несколько контроллеров репликации
+kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Масштабирование нескольких контроллеров репликации до 5
 ```
 ## Удаление ресурсов
@ -362,7 +362,7 @@ kubectl api-resources --api-group=extensions # Все ресурсы в API-гр
 ### Уровни детальности вывода и отладки в Kubectl
-Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированиия Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
+Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
 Уровень детальности | Описание
--- a/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md
@ -70,7 +70,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
 ```
 В отличие от `docker run ...`, если вы укажете `--attach`, то присоедините `stdin`, `stdout` and `stderr`. Нельзя проконтролировать, какие потоки прикрепляются (`docker -a ...`).
-Чтобы отсоединиться от контейнера воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q.
+Чтобы отсоединиться от контейнера, воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q.
 Так как команда kubectl run запускает развёртывание для контейнера, то оно начнет перезапускаться, если завершить прикрепленный процесс по нажатию Ctrl+C, в отличие от команды `docker run -it`.
 Для удаления объекта Deployment вместе с подами, необходимо выполнить команду `kubectl delete deployment <name>`.
--- a/content/ru/docs/reference/kubectl/jsonpath.md
+++ b/content/ru/docs/reference/kubectl/jsonpath.md
@ -90,7 +90,7 @@ kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.st
 ```
 {{< note >}}
-В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонов нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например:
+В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонах нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например:
 ```cmd
 kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
--- a/content/ru/docs/reference/kubectl/kubectl.md
+++ b/content/ru/docs/reference/kubectl/kubectl.md
@ -158,14 +158,14 @@ kubectl [flags]
 <td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: 300</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.</td>
 </tr>
 <tr>
 <td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: 300</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.</td>
 </tr>
 <tr>
@ -221,7 +221,7 @@ kubectl [flags]
 <td colspan="2">--docker-tls-cert string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: "cert.pem"</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">путь к клиентскому сертификату</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к клиентскому сертификату</td>
 </tr>
 <tr>
@ -277,7 +277,7 @@ kubectl [flags]
 <td colspan="2">--insecure-skip-tls-verify</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверятся на достоверность. Это сделает подключения через HTTPS небезопасными.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверяться на достоверность. Это сделает подключения через HTTPS небезопасными.</td>
 </tr>
 <tr>
@ -333,7 +333,7 @@ kubectl [flags]
 <td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: true</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок вместо сохранения логов в файлы</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Вывод логов в стандартный поток ошибок вместо сохранения их в файлы</td>
 </tr>
 <tr>
@ -521,48 +521,48 @@ kubectl [flags]
 ## {{% heading "seealso" %}}
-* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	 - Обновить аннотации ресурса
+* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	- Обновить аннотации ресурса.
-* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources)	 - Вывести доступные API-ресурсы на сервере
+* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - Вывести доступные API-ресурсы на сервере.
-* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	 - Вывести доступные API-версии на сервере в виде "group/version".
+* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	- Вывести доступные API-версии на сервере в виде "group/version".
-* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply)	 - Внести изменения в конфигурацию ресурса из файла или потока stdin.
+* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply)	- Внести изменения в конфигурацию ресурса из файла или потока stdin.
-* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach)	 - Присоединиться к запущенному контейнеру
+* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach)	- Присоединиться к запущенному контейнеру.
-* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth)	 - Проверить разрешение на выполнение определённых действий
+* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth)	- Проверить разрешение на выполнение определённых действий.
-* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)	 - Автоматически промасштабировать Deployment, ReplicaSet или ReplicationController
+* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)	- Автоматически масштабировать Deployment, ReplicaSet или ReplicationController.
-* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate)	 - Изменить сертификаты ресурсов.
+* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate)	- Изменить сертификаты ресурсов.
-* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info)	 - Показать информацию по кластеру
+* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info)	- Показать информацию по кластеру.
-* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion)	 - Вывод кода автодополнения указанной командной оболочки (bash или zsh)
+* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion)	- Вывод кода автодополнения указанной командной оболочки (bash или zsh).
-* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)	 - Изменить файлы kubeconfig
+* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)	- Изменить файлы kubeconfig.
-* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert)	 - Конвертировать конфигурационные файлы в различные API-версии
+* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert)	- Конвертировать конфигурационные файлы в различные API-версии.
-* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon)	 - Отметить узел как неназначаемый
+* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon)	- Отметить узел как неназначаемый.
-* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp)	 - Копировать файлы и директории в/из контейнеров.
+* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp)	- Копировать файлы и директории в/из контейнеров.
-* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create)	 - Создать ресурс из файла или потока stdin.
+* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create)	- Создать ресурс из файла или потока stdin.
-* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete)	 - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов
+* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete)	- Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов.
-* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe)	 - Показать подробную информацию о конкретном ресурсе или группе ресурсов
+* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe)	- Показать подробную информацию о конкретном ресурсе или группе ресурсов.
-* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff)	 - Сравнить действующую версию с новой (применяемой)
+* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff)	- Сравнить действующую версию с новой (применяемой).
-* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain)	 - Вытеснить узел для подготовки к эксплуатации
+* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain)	- Вытеснить узел для подготовки к эксплуатации.
-* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit)	 - Отредактировать ресурс на сервере
+* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit)	- Отредактировать ресурс на сервере.
-* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec)	 - Выполнить команду в контейнере
+* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec)	- Выполнить команду в контейнере.
-* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain)	 - Получить документацию ресурсов
+* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain)	- Получить документацию ресурсов.
-* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose)	 - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода
+* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose)	- Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода.
-* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get)	 - Вывести один или несколько ресурсов
+* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get)	- Вывести один или несколько ресурсов.
-* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize)	 - Собрать ресурсы kustomization из директории или URL-адреса.
+* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize)	- Собрать ресурсы kustomization из директории или URL-адреса.
-* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label)	 - Обновить метки ресурса
+* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label)	- Обновить метки ресурса.
-* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs)	 - Вывести логи контейнера в поде
+* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs)	- Вывести логи контейнера в поде.
-* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options)	 - Вывести список флагов, применяемых ко всем командам
+* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options)	- Вывести список флагов, применяемых ко всем командам.
-* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - Обновить один или несколько полей ресурса, используя стратегию слияния патча
+* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	- Обновить один или несколько полей ресурса, используя стратегию слияния патча.
-* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin)	 - Команда для работы с плагинами.
+* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin)	- Команда для работы с плагинами.
-* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward)	 - Переадресовать один или несколько локальных портов в под
+* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward)	- Переадресовать один или несколько локальных портов в под.
-* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy)	 - Запустить прокси на API-сервер Kubernetes
+* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy)	- Запустить прокси на API-сервер Kubernetes.
-* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace)	 - Заменить ресурс из определения в файле или потоке stdin.
+* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace)	- Заменить ресурс из определения в файле или потоке stdin.
-* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout)	 - Управление плавающим обновлением ресурса
+* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout)	- Управление плавающим обновлением ресурса.
-* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run)	 -  Запустить указанный образ в кластере
+* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run)	- Запустить указанный образ в кластере.
-* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale)	 - Задать новый размер для Deployment, ReplicaSet или Replication Controller.
+* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale)	- Задать новый размер для Deployment, ReplicaSet или Replication Controller.
-* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set)	 - Конфигурировать ресурсы в объектах
+* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set)	- Конфигурировать ресурсы в объектах.
-* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)	 - Обновить ограничения для одного или нескольких узлов
+* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)	- Обновить ограничения для одного или нескольких узлов.
-* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top)	 - Показать информацию по использованию системных ресурсов (процессор, память, диск)
+* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top)	- Показать информацию по использованию системных ресурсов (процессор, память, диск).
-* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon)	 - Отметить узел как назначаемый
+* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon)	- Отметить узел как назначаемый.
-* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version)	 - Вывести информацию о версии клиента и сервера
+* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Вывести информацию о версии клиента и сервера.
-* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait)	 - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.
+* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.
--- a/content/ru/docs/reference/kubectl/overview.md
+++ b/content/ru/docs/reference/kubectl/overview.md
@ -52,7 +52,7 @@ kubectl [command] [TYPE] [NAME] [flags]
   * Выбор ресурсов по одному или нескольким файлов:  `-f file1 -f file2 -f file<#>`
-      * [Используйте YAML вместо JSON](/docs/concepts/configuration/overview/#general-configuration-tips), так так YAML удобнее для пользователей, особенно в конфигурационных файлов.<br/>
+      * [Используйте YAML вместо JSON](/docs/concepts/configuration/overview/#general-configuration-tips), так как YAML удобнее для пользователей, особенно в конфигурационных файлах.<br/>
     Пример: `kubectl get pod -f ./pod.yaml`
 * `flags`: определяет дополнительные флаги. Например, вы можете использовать флаги `-s` или `--server`, чтобы указать адрес и порт API-сервера Kubernetes.<br/>
@ -162,7 +162,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 ### Форматирование вывода
-Стандартный формат вывода всех команд `kubectl` представлен в человекочитаемом текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги `-o` или `--output` к команде `kubectl`.
+Стандартный формат вывода всех команд `kubectl` представлен в понятном для человека текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги `-o` или `--output` к команде `kubectl`.
 #### Синтаксис
@ -229,7 +229,7 @@ submit-queue   610995
 `kubectl` может получать информацию об объектах с сервера.
 Это означает, что для любого указанного ресурса сервер вернет столбцы и строки по этому ресурсу, которые отобразит клиент.
-Благодаря тому, что сервер инкапсулирует реализацию вывода, гарантируется единообразный и человекочитаемый вывод на всех клиентах, использующих один и тот же кластер.
+Благодаря тому, что сервер инкапсулирует реализацию вывода, гарантируется единообразный и понятный для человека вывод на всех клиентах, использующих один и тот же кластер.
 Эта функциональность включена по умолчанию, начиная с `kubectl` 1.11 и выше. Чтобы отключить ее, добавьте флаг `--server-print=false` в команду `kubectl get`.
@ -340,7 +340,7 @@ kubectl delete pods,services -l name=<label-name>
 kubectl delete pods --all
 ```
-`kubectl exec` - Выполнить команду в контейнера пода.
+`kubectl exec` - Выполнить команду в контейнере пода.
 ```shell
 # Получить вывод от запущенной команды 'date' в поде <pod-name>. По умолчанию отображается вывод из первого контейнера.
--- a/content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md
+++ b/content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md
@ -0,0 +1,154 @@
 ---
 layout: blog
 title: 'Kubernetes 1.23：IPv4/IPv6 双协议栈网络达到 GA'
 date: 2021-12-08
 slug: dual-stack-networking-ga
 ---
 <!--
 layout: blog
 title: 'Kubernetes 1.23: Dual-stack IPv4/IPv6 Networking Reaches GA'
 date: 2021-12-08
 slug: dual-stack-networking-ga
 -->
 <!--
 **Author:** Bridget Kromhout (Microsoft)
 -->
 **作者:** Bridget Kromhout (微软)
 <!--
 "When will Kubernetes have IPv6?" This question has been asked with increasing frequency ever since alpha support for IPv6 was first added in k8s v1.9. While Kubernetes has supported IPv6-only clusters since v1.18, migration from IPv4 to IPv6 was not yet possible at that point. At long last, [dual-stack IPv4/IPv6 networking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/) has reached general availability (GA) in Kubernetes v1.23.
 What does dual-stack networking mean for you? Let’s take a look…
 -->
 “Kubernetes 何时支持 IPv6？” 自从 k8s v1.9 版本中首次添加对 IPv6 的 alpha 支持以来，这个问题的讨论越来越频繁。
 虽然 Kubernetes 从 v1.18 版本开始就支持纯 IPv6 集群，但当时还无法支持 IPv4 迁移到 IPv6。
 [IPv4/IPv6 双协议栈网络](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/)
 在 Kubernetes v1.23 版本中进入正式发布（GA）阶段。
 让我们来看看双协议栈网络对你来说意味着什么？
 <!--
 ## Service API updates
 -->
 ## 更新 Service API
 <!--
 [Services](/docs/concepts/services-networking/service/) were single-stack before 1.20, so using both IP families meant creating one Service per IP family. The user experience was simplified in 1.20, when Services were re-implemented to allow both IP families, meaning a single Service can handle both IPv4 and IPv6 workloads. Dual-stack load balancing is possible between services running any combination of IPv4 and IPv6.
 -->
 [Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的，
 因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化，
 重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。
 对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。
 <!--
 The Service API now has new fields to support dual-stack, replacing the single ipFamily field.
 * You can select your choice of IP family by setting `ipFamilyPolicy` to one of three options: SingleStack, PreferDualStack, or RequireDualStack. A service can be changed between single-stack and dual-stack (within some limits).
 * Setting `ipFamilies` to a list of families assigned allows you to set the order of families used.
 * `clusterIPs` is inclusive of the previous `clusterIP` but allows for multiple entries, so it’s no longer necessary to run duplicate services, one in each of the two IP families. Instead, you can assign cluster IP addresses in both IP families.
 -->
 Service API 现在有了支持双协议栈的新字段，取代了单一的 ipFamily 字段。
 * 你可以通过将 `ipFamilyPolicy` 字段设置为 `SingleStack`、`PreferDualStack` 或
 `RequireDualStack` 来设置 IP 协议族。Service 可以在单协议栈和双协议栈之间进行转换(在某些限制内)。
 * 设置 `ipFamilies` 为指定的协议族列表，可用来设置使用协议族的顺序。
 * 'clusterIPs' 的能力在涵盖了之前的 'clusterIP'的情况下，还允许设置多个 IP 地址。
 所以不再需要运行重复的 Service，在两个 IP 协议族中各运行一个。你可以在两个 IP 协议族中分配集群 IP 地址。
 <!--
 Note that Pods are also dual-stack. For a given pod, there is no possibility of setting multiple IP addresses in the same family.
 -->
 请注意，Pods 也是双协议栈的。对于一个给定的 Pod，不可能在同一协议族中设置多个 IP 地址。
 <!--
 ## Default behavior remains single-stack
 -->
 ## 默认行为仍然是单协议栈
 <!--
 Starting in 1.20 with the re-implementation of dual-stack services as alpha, the underlying networking for Kubernetes has included dual-stack whether or not a cluster was configured with the feature flag to enable dual-stack.
 -->
 从 1.20 版本开始，重新实现的双协议栈服务处于 Alpha 阶段，无论集群是否配置了启用双协议栈的特性标志，
 Kubernetes 的底层网络都已经包括了双协议栈。
 <!--
 Kubernetes 1.23 removed that feature flag as part of graduating the feature to stable. Dual-stack networking is always available if you want to configure it. You can set your cluster network to operate as single-stack IPv4, as single-stack IPv6, or as dual-stack IPv4/IPv6.
 -->
 Kubernetes 1.23 删除了这个特性标志，说明该特性已经稳定。
 如果你想要配置双协议栈网络，这一能力总是存在的。
 你可以将集群网络设置为 IPv4 单协议栈 、IPv6 单协议栈或 IPV4/IPV6 双协议栈 。
 <!--
 While Services are set according to what you configure, Pods default to whatever the CNI plugin sets. If your CNI plugin assigns single-stack IPs, you will have single-stack unless `ipFamilyPolicy` specifies PreferDualStack or RequireDualStack. If your CNI plugin assigns dual-stack IPs, `pod.status.PodIPs` defaults to dual-stack.
 -->
 虽然 Service 是根据你的配置设置的，但 Pod 默认是由 CNI 插件设置的。
 如果你的 CNI 插件分配单协议栈 IP，那么就是单协议栈，除非 `ipFamilyPolicy` 设置为 `PreferDualStack` 或 `RequireDualStack`。
 如果你的 CNI 插件分配双协议栈 IP，则 `pod.status.PodIPs` 默认为双协议栈。
 <!--
 Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios).
 -->
 尽管双协议栈是可用的，但并不强制你使用它。
 在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios)
 文档中的示例列出了可能出现的各种场景.
 <!--
 ## Try dual-stack right now
 -->
 ## 现在尝试双协议栈
 <!--
 While upstream Kubernetes now supports [dual-stack networking](/docs/concepts/services-networking/dual-stack/) as a GA or stable feature, each provider’s support of dual-stack Kubernetes may vary. Nodes need to be provisioned with routable IPv4/IPv6 network interfaces. Pods need to be dual-stack. The [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) is what assigns the IP addresses to the Pods, so it's the network plugin being used for the cluster that needs to support dual-stack. Some Container Network Interface (CNI) plugins support dual-stack, as does kubenet.
 -->
 虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/)
 作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。
 Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。
 <!--
 Ecosystem support of dual-stack is increasing; you can create [dual-stack clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), try a [dual-stack cluster locally with KIND](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family), and deploy dual-stack clusters in cloud providers (after checking docs for CNI or kubenet availability).
 -->
 支持双协议栈的生态系统在不断壮大；你可以使用
 [kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/),
 在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)，
 还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后）
 <!--
 ## Get involved with SIG Network
 -->
 ## 加入 Network SIG
 <!--
 SIG-Network wants to learn from community experiences with dual-stack networking to find out more about evolving needs and your use cases. The [SIG-network update video from KubeCon NA 2021](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4) summarizes the SIG’s recent updates, including dual-stack going to stable in 1.23.
 -->
 SIG-Network 希望从双协议栈网络的社区体验中学习，以了解更多不断变化的需求和你的用例信息。
 [SIG-network 更新了来自 KubeCon 2021 北美大会的视频](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4)
 总结了 SIG 最近的更新，包括双协议栈将在 1.23 版本中稳定。
 <!--
 The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) and [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) on GitHub illustrate the SIG’s areas of emphasis. The [dual-stack API server](https://github.com/kubernetes/enhancements/issues/2438) is one place to consider contributing.
 -->
 当前 SIG-Network 在 GitHub 上的 [KEPs](https://github.com/orgs/kubernetes/projects/10) 和
 [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork)
 说明了该 SIG 的重点领域。[双协议栈 API 服务器](https://github.com/kubernetes/enhancements/issues/2438)
 是一个考虑贡献的方向。
 <!--
 [SIG-Network meetings](https://github.com/kubernetes/community/tree/master/sig-network#meetings) are a friendly, welcoming venue for you to connect with the community and share your ideas. Looking forward to hearing from you!
 -->
 [SIG-Network 会议](https://github.com/kubernetes/community/tree/master/sig-network#meetings)
 是一个友好、热情的场所，你可以与社区联系并分享你的想法。期待你的加入！
 <!--
 ## Acknowledgments
 -->
 ## 致谢
 <!--
 The dual-stack networking feature represents the work of many Kubernetes contributors. Thanks to all who contributed code, experience reports, documentation, code reviews, and everything in between. Bridget Kromhout details this community effort in [Dual-Stack Networking in Kubernetes](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/). KubeCon keynotes by Tim Hockin & Khaled (Kal) Henidak in 2019 ([The Long Road to IPv4/IPv6 Dual-stack Kubernetes](https://www.youtube.com/watch?v=o-oMegdZcg4)) and by Lachlan Evenson in 2021 ([And Here We Go: Dual-stack Networking in Kubernetes](https://www.youtube.com/watch?v=lVrt8F2B9CM)) talk about the dual-stack journey, spanning five years and a great many lines of code.
 -->
 许多 Kubernetes 贡献者为双协议栈网络做出了贡献。感谢所有贡献了代码、经验报告、文档、代码审查以及其他工作的人。
 Bridget Kromhout 在 [Kubernetes的双协议栈网络](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/)
 中详细介绍了这项社区工作。Tim Hockin 和 Khaled (Kal) Henidak 在 2019 年的 KubeCon 大会演讲
 （[Kubernetes 通往 IPv4/IPv6 双协议栈的漫漫长路](https://www.youtube.com/watch?v=o-oMegdZcg4)）
 和 Lachlan Evenson 在 2021 年演讲（[我们来啦，Kubernetes 双协议栈网络](https://www.youtube.com/watch?v=o-oMegdZcg4)）
 中讨论了双协议栈的发展旅程，耗时 5 年和海量代码。
--- a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
+++ b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
@ -3,7 +3,6 @@ layout: blog
 title: "更新：弃用 Dockershim 的常见问题"
 date: 2022-02-17
 slug: dockershim-faq
 aliases: [ '/dockershim' ]
 ---
 <!-- 
 layout: blog
--- a/content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md
+++ b/content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md
@ -0,0 +1,180 @@
 ---
 layout: blog
 title: "认识我们的贡献者 - 亚太地区（澳大利亚-新西兰地区）"
 date: 2022-03-16T12:00:00+0000
 slug: meet-our-contributors-au-nz-ep-02
 canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
 ---
 <!--
 layout: blog
 title: "Meet Our Contributors - APAC (Aus-NZ region)"
 date: 2022-03-16T12:00:00+0000
 slug: meet-our-contributors-au-nz-ep-02
 canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
 -->
 <!--
 **Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Brad McCoy](https://github.com/bradmccoydev), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Priyanka Saggu](github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
 -->
 **作者和采访者：**
 [Anubhav Vardhan](https://github.com/anubha-v-ardhan),
 [Atharva Shinde](https://github.com/Atharva-Shinde),
 [Avinesh Tripathi](https://github.com/AvineshTripathi),
 [Brad McCoy](https://github.com/bradmccoydev),
 [Debabrata Panigrahi](https://github.com/Debanitrkl),
 [Jayesh Srivastava](https://github.com/jayesh-srivastava),
 [Kunal Verma](https://github.com/verma-kunal),
 [Pranshu Srivastava](https://github.com/PranshuSrivastava),
 [Priyanka Saggu](github.com/Priyankasaggu11929/),
 [Purneswar Prasad](https://github.com/PurneswarPrasad),
 [Vedant Kakde](https://github.com/vedant-kakde)
 ---
 <!--
 Good day, everyone 👋
 -->
 大家好👋
 <!--
 Welcome back to the second episode of the "Meet Our Contributors" blog post series for APAC.
 -->
 欢迎来到亚太地区的”认识我们的贡献者”博文系列第二期。
 <!--
 This post will feature four outstanding contributors from the Australia and New Zealand regions, who have played diverse leadership and community roles in the Upstream Kubernetes project.
 -->
 这篇文章将介绍来自澳大利亚和新西兰地区的四位杰出贡献者，
 他们在上游 Kubernetes 项目中承担着不同子项目的领导者和社区贡献者的角色。
 <!--
 So, without further ado, let's get straight to the blog.
 -->
 闲话少说，让我们直接进入主题。
 ## [Caleb Woodbine](https://github.com/BobyMCbobs)
 <!--
 Caleb Woodbine is currently a member of the ii.nz organisation.
 -->
 Caleb Woodbine 目前是 ii.nz 组织的成员。
 <!--
 He began contributing to the Kubernetes project in 2018 as a member of the Kubernetes Conformance working group. His experience was positive, and he benefited from early guidance from [Hippie Hacker](https://github.com/hh), a fellow contributor from New Zealand.
 -->
 他于 2018 年作为 Kubernetes Conformance 工作组的成员开始为 Kubernetes 项目做贡献。
 他积极向上，他从一位来自新西兰的贡献者 [Hippie Hacker](https://github.com/hh) 的早期指导中受益匪浅。
 <!--
 He has made major contributions to Kubernetes project since then through `SIG k8s-infra` and `k8s-conformance` working group.
 -->
 他在 `SIG k8s-infra` 和 `k8s-conformance` 工作组为 Kubernetes 项目做出了重大贡献。
 <!--
 Caleb is also a co-organizer of the [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) community events, which aim to expand the reach of Kubernetes project throughout New Zealand in order to encourage technical education and improved employment opportunities.
 -->
 Caleb 也是 [CloudNative NZ](https://www.meetup.com/cloudnative-nz/)
 社区活动的联合组织者，该活动旨在扩大 Kubernetes 项目在整个新西兰的影响力，以鼓励科技教育和改善就业机会。
 <!--
 > _There need to be more outreach in APAC and the educators and universities must pick up Kubernetes, as they are very slow and about 8+ years out of date. NZ tends to rather pay overseas than educate locals on the latest cloud tech Locally._
 -->
 > _亚太地区需要更多的外联活动，教育工作者和大学必须学习 Kubernetes，因为他们非常缓慢，
 而且已经落后了8年多。新西兰倾向于在海外付费，而不是教育当地人最新的云技术。_
 ## [Dylan Graham](https://github.com/DylanGraham)
 <!--
 Dylan Graham is a cloud engineer from Adeliade, Australia. He has been contributing to the upstream Kubernetes project since 2018.
 -->
 Dylan Graham 是来自澳大利亚 Adeliade 的云计算工程师。自 2018 年以来，他一直在为上游 Kubernetes 项目做出贡献。
 <!--
 He stated that being a part of such a large-scale project was initially overwhelming, but that the community's friendliness and openness assisted him in getting through it.
 -->
 他表示，成为如此大项目的一份子，最初压力是比较大的，但社区的友好和开放帮助他度过了难关。
 <!--
 He began by contributing to the project documentation and is now mostly focused on the community support for the APAC region.
 -->
 开始在项目文档方面做贡献，现在主要致力于为亚太地区提供社区支持。
 <!--
 He believes that consistent attendance at community/project meetings, taking on project tasks, and seeking community guidance as needed can help new aspiring developers become effective contributors.
 -->
 他相信，持续参加社区/项目会议，承担项目任务，并在需要时寻求社区指导，可以帮助有抱负的新开发人员成为有效的贡献者。
 <!--
 > _The feeling of being a part of a large community is really special. I've met some amazing people, even some before the pandemic in real life :)_
 -->
 > _成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人，甚至是在现实生活中疫情发生之前。_
 ## [Hippie Hacker](https://github.com/hh)
 <!--
 Hippie has worked for the CNCF.io as a Strategic Initiatives contractor from New Zealand for almost 5+ years. He is an active contributor to k8s-infra, API conformance testing, Cloud provider conformance submissions, and apisnoop.cncf.io domains of the upstream Kubernetes & CNCF projects.
 -->
 Hippie 来自新西兰，曾在 CNCF.io 作为战略计划承包商工作 5 年多。他是 k8s-infra、
 API 一致性测试、云提供商一致性提交以及上游 Kubernetes 和 CNCF 项目 apisnoop.cncf.io 域的积极贡献者。
 <!--
 He recounts their early involvement with the Kubernetes project, which began roughly 5 years ago when their firm, ii.nz, demonstrated [network booting from a Raspberry Pi using PXE and running Gitlab in-cluster to install Kubernetes on servers](https://ii.nz/post/bringing-the-cloud-to-your-community/).
 -->
 他讲述了他们早期参与 Kubernetes 项目的情况，该项目始于大约 5 年前，当时他们的公司 ii.nz
 演示了[使用 PXE 从 Raspberry Pi 启动网络，并在集群中运行Gitlab，以便在服务器上安装 Kubernetes ](https://ii.nz/post/bringing-the-cloud-to-your-community/)
 <!--
 He describes their own contributing experience as someone who, at first, tried to do all of the hard lifting on their own, but eventually saw the benefit of group contributions which reduced burnout and task division which allowed folks to keep moving forward on their own momentum.
 -->
 他描述了自己的贡献经历：一开始，他试图独自完成所有艰巨的任务，但最终看到了团队协作贡献的好处，
 分工合作减少了过度疲劳，这让人们能够凭借自己的动力继续前进。
 <!--
 He recommends that new contributors use pair programming.
 -->
 他建议新的贡献者结对编程。
 <!--
 > _The cross pollination of approaches and two pairs of eyes on the same work can often yield a much more amplified effect than a PR comment / approval alone can afford._
 -->
 > _针对一个项目，多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。_
 ## [Nick Young](https://github.com/youngnick)
 <!--
 Nick Young works at VMware as a technical lead for Contour, a CNCF ingress controller. He was active with the upstream Kubernetes project from the beginning, and eventually became the chair of the LTS working group, where he advocated user concerns. He is currently the SIG Network Gateway API subproject's maintainer.
 -->
 Nick Young 在 VMware 工作，是 CNCF 入口控制器 Contour 的技术负责人。
 他从一开始就积极参与上游 Kubernetes 项目，最终成为 LTS 工作组的主席，
 他提倡关注用户。他目前是 SIG Network Gateway API 子项目的维护者。
 <!--
 His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.
 -->
 他的贡献之路是引人注目的，因为他很早就在 Kubernetes 项目的主要领域工作，这改变了他的轨迹。
 <!--
 He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions. 
 -->
 他断言，一个新贡献者能做的最好的事情就是“开始贡献”。当然，如果与他的工作息息相关，那好极了;
 然而，把非工作时间投入到贡献中去，从长远来看可以在工作上获得回报。
 他认为，应该鼓励新的贡献者，特别是那些目前是 Kubernetes 用户的人，参与到更高层次的项目讨论中来。
 <!--
 > _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._
 -->
 > _只要积极主动，做出贡献，你就可以走很远。一旦你活跃了一段时间，你会发现你能够解答别人的问题，
 这意味着会有人请教你或和你讨论，在你意识到这一点之前，你就已经是专家了。_
 ---
 <!--
 If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
 -->
 如果你对我们接下来应该采访的人有任何意见/建议，请在 #sig-contribex 中告知我们。
 非常感谢你的建议。我们很高兴有更多的人帮助我们接触到社区中更优秀的人。
 <!--
 We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
 -->
 我们下期再见。祝你有个愉快的贡献之旅!👋
--- a/content/zh/docs/concepts/configuration/secret.md
+++ b/content/zh/docs/concepts/configuration/secret.md
--- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -75,7 +75,7 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
 <!--
 Then the cluster is logically viewed as below:
 -->
-然后从逻辑上看集群如下：
+那么，从逻辑上看集群如下：
 {{<mermaid>}}
 graph TB
@ -96,11 +96,9 @@ graph TB
 {{< /mermaid >}}
 <!--
 Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
 -->
-你可以复用在大多数集群上自动创建和填充的
+你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)，
 [常用标签](/zh/docs/reference/labels-annotations-taints/)，
 而不是手动添加标签。
 <!--
@ -169,6 +167,12 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
  拓扑域中 Pod 的数量。
  有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
 <!--
 When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
 -->
 当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。
 kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。
 <!--
 You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
 -->
@ -353,7 +357,6 @@ graph BT
    class zoneA,zoneB cluster;
 {{< /mermaid >}}
 <!--
 If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
 -->
@ -374,54 +377,59 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
 -->
 ### 节点亲和性与节点选择器的相互作用   {#interaction-with-node-affinity-and-node-selectors}
-如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，调度器将从倾斜计算中跳过不匹配的节点。
+如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，
 调度器将在偏差计算中跳过不匹配的节点。
 <!--
-    Suppose you have a 5-node cluster ranging from zoneA to zoneC:
+### Example: TopologySpreadConstraints with NodeAffinity
-    and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
+Suppose you have a 5-node cluster ranging from zoneA to zoneC:
    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
 -->
-    假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
+### 示例：TopologySpreadConstraints 与 NodeAffinity
-    {{<mermaid>}}
+假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
    graph BT
        subgraph "zoneB"
            p3(Pod) --> n3(Node3)
            n4(Node4)
        end
        subgraph "zoneA"
            p1(Pod) --> n1(Node1)
            p2(Pod) --> n2(Node2)
        end
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+{{<mermaid>}}
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+graph BT
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    subgraph "zoneB"
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
+        p3(Pod) --> n3(Node3)
-    class p4 plain;
+        n4(Node4)
-    class zoneA,zoneB cluster;
+    end
-    {{< /mermaid >}}
+    subgraph "zoneA"
        p1(Pod) --> n1(Node1)
        p2(Pod) --> n2(Node2)
    end
-    {{<mermaid>}}
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    graph BT
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-        subgraph "zoneC"
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-            n5(Node5)
+class n1,n2,n3,n4,p1,p2,p3 k8s;
-        end
+class p4 plain;
 class zoneA,zoneB cluster;
 {{< /mermaid >}}
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+{{<mermaid>}}
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+graph BT
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    subgraph "zoneC"
-    class n5 k8s;
+        n5(Node5)
-    class zoneC cluster;
+    end
    {{< /mermaid >}}
-    而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    也要一样处理。
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
 class n5 k8s;
 class zoneC cluster;
 {{< /mermaid >}}
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+
 <!--
 and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
 -->
 而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML，
 以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
 也要一样处理。
 {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
 <!--
 The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.
@ -503,7 +511,7 @@ An example configuration might look like follows:
 配置的示例可能看起来像下面这个样子：
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
@ -565,20 +573,24 @@ is disabled.
 -->
 此外，原来用于提供等同行为的 `SelectorSpread` 插件也会被禁用。
 {{< note >}}
 <!--
 The `PodTopologySpread` plugin does not score the nodes that don't have
 the topology keys specified in the spreading constraints. This might result
 in a different default behavior compared to the legacy `SelectorSpread` plugin when
 using the default topology constraints.
 -->
 对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些主键的节点评分。
 这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同，
 <!--
 If your nodes are not expected to have **both** `kubernetes.io/hostname` and
 `topology.kubernetes.io/zone` labels set, define your own constraints
 instead of using the Kubernetes defaults.
 The `PodTopologySpread` plugin does not score the nodes that don't have
 the topology keys specified in the spreading constraints.
 -->
 {{< note >}}
 如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和
 `topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用
 Kubernetes 的默认约束。
 插件 `PodTopologySpread` 不会为未设置分布约束中所给拓扑键的节点评分。
 {{< /note >}}
 <!--
@ -586,11 +598,11 @@ If you don't want to use the default Pod spreading constraints for your cluster,
 you can disable those defaults by setting `defaultingType` to `List` and leaving
 empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
 -->
-如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List` 和
+如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List`
-将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
+并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
@ -613,9 +625,9 @@ scheduled - more packed or more scattered.
 <!--
 - For `PodAffinity`, you can try to pack any number of Pods into qualifying
-topology domain(s)
+  topology domain(s)
 - For `PodAntiAffinity`, only one Pod can be scheduled into a
-single topology domain.
+  single topology domain.
 -->
 - 对于 `PodAffinity`，你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
 - 对于 `PodAntiAffinity`，只能将一个 Pod 调度到某个拓扑域中。
@ -627,12 +639,6 @@ cost-saving. This can also help on rolling update workloads and scaling out
 replicas smoothly. See
 [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
 for more details.
 The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
 topology domains - to achieve high availability or cost-saving. This can also help on rolling update
 workloads and scaling out replicas smoothly.
 See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
 -->
 要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，
 从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。
@ -642,13 +648,19 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig
 <!--
 ## Known Limitations
- Scaling down a Deployment may result in imbalanced Pods distribution.
+- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
 You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
 - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
 -->
 ## 已知局限性
- Deployment 缩容操作可能导致 Pod 分布不平衡。
+- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时，
- 具有污点的节点上的 Pods 也会被统计。
+  Pod 的分布可能不再均衡。
  你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler)
  来重新实现 Pod 分布的均衡。
 - 具有污点的节点上匹配的 Pods 也会被统计。
  参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
 ## {{% heading "whatsnext" %}}
--- a/content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md
+++ b/content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md
@ -0,0 +1,135 @@
 ---
 api_metadata:
  apiVersion: ""
  import: "k8s.io/apimachinery/pkg/api/resource"
  kind: "Quantity"
 content_type: "api_reference"
 description: "数量（Quantity）是数字的定点表示。"
 title: "Quantity"
 weight: 10
 auto_generated: true
 ---
 <!-- 
 api_metadata:
  apiVersion: ""
  import: "k8s.io/apimachinery/pkg/api/resource"
  kind: "Quantity"
 content_type: "api_reference"
 description: "Quantity is a fixed-point representation of a number."
 title: "Quantity"
 weight: 10
 auto_generated: true
 -->
 <!--
 The file is auto-generated from the Go source code of the component using a generic
 [generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
 to generate the reference documentation, please read
 [Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
 To update the reference content, please follow the 
 [Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
 guide. You can file document formatting bugs against the
 [reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
 -->
 `import "k8s.io/apimachinery/pkg/api/resource"`
 <!-- 
 Quantity is a fixed-point representation of a number. 
 It provides convenient marshaling/unmarshaling in JSON and YAML, 
 in addition to String() and AsInt64() accessors.
 The serialization format is:
 -->
 数量（Quantity）是数字的定点表示。
 除了 String() 和 AsInt64() 的访问接口之外，
 它以 JSON 和 YAML形式提供方便的打包和解包方法。
 序列化格式如下：
 <!-- 
 \<quantity>        ::= \<signedNumber>\<suffix>
  (Note that \<suffix> may be empty, from the "" case in \<decimalSI>.)
 \<digit>           ::= 0 | 1 | ... | 9 
 \<digits>          ::= \<digit> | \<digit>\<digits> 
 \<number>          ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits> 
 \<sign>            ::= "+" | "-" 
 \<signedNumber>    ::= \<number> | \<sign>\<number> 
 \<suffix>          ::= \<binarySI> | \<decimalExponent> | \<decimalSI> 
 \<binarySI>        ::= Ki | Mi | Gi | Ti | Pi | Ei
  (International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
 \<decimalSI>       ::= m | "" | k | M | G | T | P | E
  (Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
 \<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>
 -->
 ```
 <quantity>        ::= <signedNumber><suffix>
  (注意 <suffix> 可能为空, 例如 <decimalSI> 的 "" 情形。) </br>
 <digit>           ::= 0 | 1 | ... | 9 </br>
 <digits>          ::= <digit> | <digit><digits> </br>
 <number>          ::= <digits> | <digits>.<digits> | <digits>. | .<digits> </br>
 <sign>            ::= "+" | "-" </br>
 <signedNumber>    ::= <number> | <sign><number> </br>
 <suffix>          ::= <binarySI> | <decimalExponent> | <decimalSI> </br>
 <binarySI>        ::= Ki | Mi | Gi | Ti | Pi | Ei 
  (国际单位制度；查阅：http://physics.nist.gov/cuu/Units/binary.html) </br>
 <decimalSI>       ::= m | "" | k | M | G | T | P | E 
  (注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。) </br>
 <decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber> </br>
 ```
 <!-- 
 No matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.
 When a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.
 -->
 无论使用三种指数形式中哪一种，没有数量可以表示大于 2<sup>63</sup>-1 的数，也不可能超过 3 个小数位。
 更大或更精确的数字将被截断或向上取整。（例如：0.1m 将向上取整为 1m。）
 如果将来我们需要更大或更小的数量，可能会扩展。
 当从字符串解析数量时，它将记住它具有的后缀类型，并且在序列化时将再次使用相同类型。
 <!-- 
 Before serializing, Quantity will be put in "canonical form". 
 This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:
  a. No precision is lost
  b. No fractional digits will be emitted
  c. The exponent (or suffix) is as large as possible.
 The sign will be omitted unless the number is negative.
 -->
 在序列化之前，数量将以“规范形式”放置。这意味着指数或者后缀将被向上或向下调整（尾数相应增加或减少），并确保：
  1. 没有精度丢失
  2. 不会输出小数数字
  3. 指数（或后缀）尽可能大。
 除非数量是负数，否则将省略正负号。
 <!-- 
 Examples:
  1.5 will be serialized as "1500m"
  1.5Gi will be serialized as "1536Mi"
 -->
 例如：
  - 1.5 将会被序列化成 “1500m”
  - 1.5Gi 将会被序列化成 “1536Mi”
 <!-- 
 Note that the quantity will NEVER be internally represented by a floating point number. 
 That is the whole point of this exercise.
 Non-canonical values will still parse as long as they are well formed, 
 but will be re-emitted in their canonical form. (So always use canonical form, or don't diff.)
 This format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.
 -->
 请注意，数量永远**不会**在内部以浮点数表示。这是本设计的重中之重。
 只要它们格式正确，非规范值仍将解析，但将以其规范形式重新输出。（所以应该总是使用规范形式，否则不要执行 diff 比较。）
 这种格式旨在使得很难在不撰写某种特殊处理代码的情况下使用这些数字，进而希望实现者也使用定点实现。
 <hr>
--- a/content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md
+++ b/content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md
@ -0,0 +1,62 @@
 ---
 api_metadata:
  apiVersion: ""
  import: "k8s.io/api/core/v1"
  kind: "ResourceFieldSelector"
 content_type: "api_reference"
 description: "ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。"
 title: "ResourceFieldSelector"
 weight: 11
 auto_generated: true
 ---
 <!-- 
 api_metadata:
  apiVersion: ""
  import: "k8s.io/api/core/v1"
  kind: "ResourceFieldSelector"
 content_type: "api_reference"
 description: "ResourceFieldSelector represents container resources (cpu, memory) and their output format."
 title: "ResourceFieldSelector"
 weight: 11
 auto_generated: true
 -->
 <!--
 The file is auto-generated from the Go source code of the component using a generic
 [generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
 to generate the reference documentation, please read
 [Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
 To update the reference content, please follow the 
 [Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
 guide. You can file document formatting bugs against the
 [reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
 -->
 `import "k8s.io/api/core/v1"`
 <!-- ResourceFieldSelector represents container resources (cpu, memory) and their output format -->
 ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。
 <hr>
 - **resource** (string), 必选
  <!-- Required: resource to select -->
  必选：选择的资源
 - **containerName** (string)
  <!-- Container name: required for volumes, optional for env vars -->
  容器名称：对卷必选，对环境变量可选
 - **divisor** (<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity</a>)
  <!-- Specifies the output format of the exposed resources, defaults to "1" -->
  指定所曝光资源的输出格式，默认值为“1”
--- a/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md
+++ b/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md
@ -26,24 +26,19 @@ source <(kubectl completion zsh)
 ```
 <!-- 
-If you have an alias for kubectl, you can extend shell completion to work with that alias:
+If you have an alias for kubectl, kubectl autocompletion will automatically work with it.
 -->
-如果你为 kubectl 定义了别名，可以扩展脚本补全，以兼容该别名。
+如果你为 kubectl 定义了别名，kubectl 自动补全将自动使用它。
 ```zsh
 echo 'alias k=kubectl' >>~/.zshrc
 echo 'compdef __start_kubectl k' >>~/.zshrc
 ```
 <!-- 
 After reloading your shell, kubectl autocompletion should be working.
 If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
 If you get an error like `2: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
 -->
 重新加载 shell 后，kubectl 自动补全功能将立即生效。
-如果你收到 `complete:13: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头：
+如果你收到 `2: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头：
 ```zsh
 autoload -Uz compinit
 compinit
--- a/content/zh/docs/tasks/tools/install-kubectl-windows.md
+++ b/content/zh/docs/tasks/tools/install-kubectl-windows.md
@ -71,20 +71,20 @@ The following methods exist for installing kubectl on Windows:
   <!-- 
   1. Validate the binary (optional)
-      Download the kubectl checksum file:
+      Download the `kubectl` checksum file:
   -->
 1. 验证该可执行文件（可选步骤）
-   下载 kubectl 校验和文件：
+   下载 `kubectl` 校验和文件：
   ```powershell
   curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256"
   ```
   <!-- 
-   Validate the kubectl binary against the checksum file:
+   Validate the `kubectl` binary against the checksum file:
   -->
-   基于校验和文件，验证 kubectl 的可执行文件：
+   基于校验和文件，验证 `kubectl` 的可执行文件：
   <!-- 
   - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
@ -106,12 +106,12 @@ The following methods exist for installing kubectl on Windows:
     ```
   <!-- 
-   1. Append or prepend the kubectl binary folder to your `PATH` environment variable.
+   1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable.
   1. Test to ensure the version of `kubectl` is the same as downloaded:
      Or use this for detailed view of version:
   -->
-1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
+1. 将 `kubectl` 二进制文件夹追加或插入到你的 `PATH` 环境变量中。
 1. 测试一下，确保此 `kubectl` 的版本和期望版本一致：
@ -261,22 +261,22 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以
 <!--
 1. Validate the binary (optional)
-   Download the kubectl-convert checksum file:
+   Download the `kubectl-convert` checksum file:
 -->
 1. 验证该可执行文件（可选步骤）
-   下载 kubectl-convert 校验和文件：
+   下载 `kubectl-convert` 校验和文件：
   ```powershell
   curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
   ```
   <!--
-   Validate the kubectl-convert binary against the checksum file:
+   Validate the `kubectl-convert` binary against the checksum file:
   - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
   -->
-   基于校验和，验证 kubectl-convert 的可执行文件：
+   基于校验和，验证 `kubectl-convert` 的可执行文件：
   - 用提示的命令对 `CertUtil` 的输出和下载的校验和文件进行手动比较。
@ -295,11 +295,11 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以
     ```
 <!--
-1.  Append or prepend the kubectl binary folder to your `PATH` environment variable.
+1.  Append or prepend the `kubectl-convert` binary folder to your `PATH` environment variable.
 1. Verify plugin is successfully installed
 -->
-1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
+1. 将 `kubectl-convert` 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
 1. 验证插件是否安装成功
--- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md
+++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md
@ -2,3 +2,9 @@
 title: 创建集群
 weight: 10
 ---
 <!--
 Learn about Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}} and create a simple cluster using Minikube.
 -->
 了解 Kubernetes {{<glossary_tooltip text="集群" term_id="cluster" length="all" >}}并使用 Minikube
 创建一个简单的集群。
--- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@ -72,7 +72,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
                <p><b> Master 负责管理整个集群。</b> Master 协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。</p>
-                <p><b> Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色</b> 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node 。</p>
+                <p><b> Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色</b> 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node，因为如果一个 Node 出现故障其对应的 etcd 成员和控制平面实例都会丢失，并且冗余会受到影响。 你可以通过添加更多控制平面节点来降低这种风险 。</p>
            </div>
            <div class="col-md-4">
--- a/content/zh/docs/tutorials/security/cluster-level-pss.md
+++ b/content/zh/docs/tutorials/security/cluster-level-pss.md
@ -19,7 +19,7 @@ Pod Security admission (PSA) is enabled by default in v1.23 and later, as it has
 [graduated to beta](/blog/2021/12/09/pod-security-admission-beta/).
 Pod Security
 is an admission controller that carries out checks against the Kubernetes
-[Pod Security Standards](docs/concepts/security/pod-security-standards/) when new pods are
+[Pod Security Standards](/docs/concepts/security/pod-security-standards/) when new pods are
 created. This tutorial shows you how to enforce the `baseline` Pod Security
 Standard at the cluster level which applies a standard configuration
 to all namespaces in a cluster.
@ -406,14 +406,14 @@ following:
 <!-- 
 ## Clean up
-Run `kind delete cluster -name psa-with-cluster-pss` and
+Run `kind delete cluster --name psa-with-cluster-pss` and
-`kind delete cluster -name psa-wo-cluster-pss` to delete the clusters you
+`kind delete cluster --name psa-wo-cluster-pss` to delete the clusters you
 created.
 -->
 ## 清理  {#clean-up}
-运行 `kind delete cluster -name psa-with-cluster-pss` 和
+运行 `kind delete cluster --name psa-with-cluster-pss` 和
-`kind delete cluster -name psa-wo-cluster-pss` 来删除你创建的集群。
+`kind delete cluster --name psa-wo-cluster-pss` 来删除你创建的集群。
 ## {{% heading "whatsnext" %}}
`@ -25,4 +25,4 @@`

	Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.	Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.

	`"Culture eats strategy for breakfast." --Peter Drucker`	`"Культура съедает стратегию на завтрак" — Питер Друкер`