Merge branch 'main' of github.com:kubernetes/website

Signed-off-by: [email protected]

Author: kflynn

content/en/docs/concepts/workloads/controllers/replicaset.md

@@ -34,7 +34,7 @@ it should create to meet the number of replicas criteria. A ReplicaSet then fulf
 and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
 template.
 
-A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-and-dependents)
+A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-dependents)
 field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning
 ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet
 knows of the state of the Pods it is maintaining and plans accordingly.

content/zh-cn/docs/concepts/configuration/secret.md

@@ -373,7 +373,7 @@ The `DATA` column shows the number of data items stored in the Secret.
 In this case, `0` means you have created an empty Secret.
 -->
 `DATA` 列显示 Secret 中保存的数据条目个数。
-在这个例子种，`0` 意味着你刚刚创建了一个空的 Secret。
+在这个例子中，`0` 意味着你刚刚创建了一个空的 Secret。
 
 <!--
 ### Service account token Secrets

content/zh-cn/docs/concepts/security/rbac-good-practices.md

@@ -18,8 +18,8 @@ weight: 60
 <!-- overview -->
 
 <!--
-Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control 
-to ensure that cluster users and workloads have only the access to resources required to 
+Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control
+to ensure that cluster users and workloads have only the access to resources required to
 execute their roles. It is important to ensure that, when designing permissions for cluster
 users, the cluster administrator understands the areas where privilge escalation could occur,
 to reduce the risk of excessive access leading to security incidents.
@@ -48,28 +48,28 @@ Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}}
 ### 最小特权  {#least-privilege}
 
 <!--
-Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions 
-explicitly required for their operation should be used. While each cluster will be different, 
+Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions
+explicitly required for their operation should be used. While each cluster will be different,
 some general rules that can be applied are :
 -->
 理想情况下，分配给用户和服务帐户的 RBAC 权限应该是最小的。
 仅应使用操作明确需要的权限，虽然每个集群会有所不同，但可以应用的一些常规规则：
 
 <!--
- - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to 
+ - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to
    ClusterRoleBindings to give users rights only within a specific namespace.
  - Avoid providing wildcard permissions when possible, especially to all resources.
    As Kubernetes is an extensible system, providing wildcard access gives rights
    not just to all object types that currently exist in the cluster, but also to all object types
    which are created in the future.
- - Administrators should not use `cluster-admin` accounts except where specifically needed. 
+ - Administrators should not use `cluster-admin` accounts except where specifically needed.
    Providing a low privileged account with
    [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
    can avoid accidental modification of cluster resources.
- - Avoid adding users to the `system:masters` group. Any user who is a member of this group 
-   bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be 
-   revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is 
-   using an authorization webhook, membership of this group also bypasses that webhook (requests 
+ - Avoid adding users to the `system:masters` group. Any user who is a member of this group
+   bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be
+   revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is
+   using an authorization webhook, membership of this group also bypasses that webhook (requests
    from users who are members of that group are never sent to the webhook)
 -->
 - 尽可能在命名空间级别分配权限。授予用户在特定命名空间中的权限时使用 RoleBinding
@@ -92,20 +92,20 @@ some general rules that can be applied are :
 
 <!--
 Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions
-(for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)). 
+(for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)).
 In cases where a workload requires powerful permissions, consider the following practices:
 
- - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
+- Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
   are necessary and are run with least privilege to limit the blast radius of container escapes.
- - Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using 
-   [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/),
-   [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or
-   [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
-   to ensure pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
-   situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
+- Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using 
+  [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/),
+  [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or
+  [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+  to ensure pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
+  situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
 -->
-理想情况下，不应为 Pod 分配具有强大权限（例如，在[特权提级的风险](#privilege-escalation-risks)中列出的任一权限）的服务帐户。
-如果工作负载需要比较大的权限，请考虑以下做法：
+理想情况下，不应为 Pod 分配具有强大权限（例如，在[特权提级的风险](#privilege-escalation-risks)中列出的任一权限）
+的服务帐户。如果工作负载需要比较大的权限，请考虑以下做法：
 
 - 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的，
   并且以最小权限运行，以限制容器逃逸的影响范围。
@@ -119,9 +119,9 @@ In cases where a workload requires powerful permissions, consider the following
 <!--
 ### Hardening
 
-Kubernetes defaults to providing access which may not be required in every cluster. Reviewing 
+Kubernetes defaults to providing access which may not be required in every cluster. Reviewing
 the RBAC rights provided by default can provide opportunities for security hardening.
-In general, changes should not be made to rights provided to `system:` accounts some options 
+In general, changes should not be made to rights provided to `system:` accounts some options
 to harden cluster rights exist:
 -->
 ### 加固 {#hardening}
@@ -148,7 +148,7 @@ Kubernetes 默认提供访问权限并非是每个集群都需要的。
 <!--
 ### Periodic review
 
-It is vital to periodically review the Kubernetes RBAC settings for redundant entries and 
+It is vital to periodically review the Kubernetes RBAC settings for redundant entries and
 possible privilege escalations.
 If an attacker is able to create a user account with the same name as a deleted user,
 they can automatically inherit all the rights of the deleted user, especially the
@@ -166,7 +166,7 @@ rights assigned to that user.
 Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account
 to escalate their privileges in the cluster or affect systems outside the cluster.
 
-This section is intended to provide visibility of the areas where cluster operators 
+This section is intended to provide visibility of the areas where cluster operators
 should take care, to ensure that they do not inadvertently allow for more access to clusters than intended.
 -->
 ## Kubernetes RBAC - 权限提权的风险 {#privilege-escalation-risks}
@@ -222,8 +222,9 @@ or other (third party) mechanisms to implement that enforcement.
 可以运行特权 Pod 的用户可以利用该访问权限获得节点访问权限，
 并可能进一步提升他们的特权。如果你不完全信任某用户或其他主体，
 不相信他们能够创建比较安全且相互隔离的 Pod，你应该强制实施 **Baseline**
-或 **Restricted** Pod 安全标准。
-你可以使用 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
+或 **Restricted** Pod 安全标准。你可以使用
+[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或其他（第三方）
+机制来强制实施这些限制。
 
 <!-- 
 For these reasons, namespaces should be used to separate resources requiring different levels of
@@ -248,12 +249,13 @@ to the underlying host filesystem(s) on the associated node. Granting that abili
 这意味着 Pod 将可以访问对应节点上的下层主机文件系统。授予该能力会带来安全风险。
 
 <!--
-There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including 
+There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including
 reading data from other containers, and abusing the credentials of system services, such as Kubelet.
 
 You should only allow access to create PersistentVolume objects for:
 -->
-不受限制地访问主机文件系统的容器可以通过多种方式提升特权，包括从其他容器读取数据以及滥用系统服务（例如 Kubelet）的凭据。
+不受限制地访问主机文件系统的容器可以通过多种方式提升特权，包括从其他容器读取数据以及滥用系统服务
+（例如 kubelet）的凭据。
 
 你应该只允许以下实体具有创建 PersistentVolume 对象的访问权限：
 
@@ -268,7 +270,7 @@ You should only allow access to create PersistentVolume objects for:
   这通常由 Kubernetes 提供商或操作员在安装 CSI 驱动程序时进行设置。
 
 <!--
-Where access to persistent storage is required trusted administrators should create 
+Where access to persistent storage is required trusted administrators should create
 PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.
 -->
 在需要访问持久存储的地方，受信任的管理员应创建 PersistentVolume，而受约束的用户应使用
@@ -277,21 +279,21 @@ PersistentVolumeClaim 来访问该存储。
 <!--
 ### Access to `proxy` subresource of Nodes
 
-Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 
-which allows for command execution on every pod on the node(s) to which they have rights. 
-This access bypasses audit logging and admission control, so care should be taken before 
+Users with access to the proxy sub-resource of node objects have rights to the Kubelet API,
+which allows for command execution on every pod on the node(s) to which they have rights.
+This access bypasses audit logging and admission control, so care should be taken before
 granting rights to this resource.
 -->
 ### 访问 Node 的 `proxy` 子资源  {#access-to-proxy-subresource-of-nodes}
 
-有权访问 Node 对象的 proxy 子资源的用户有权访问 Kubelet API，
+有权访问 Node 对象的 proxy 子资源的用户有权访问 kubelet API，
 这允许在他们有权访问的节点上的所有 Pod 上执行命令。
 此访问绕过审计日志记录和准入控制，因此在授予对此资源的权限前应小心。
 
 <!--
 ### Escalate verb
 
-Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. 
+Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.
 The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
 users with this right can effectively escalate their privileges.
 -->
@@ -305,8 +307,8 @@ users with this right can effectively escalate their privileges.
 <!--
 ### Bind verb
 
-Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes 
-in-built protections against privilege escalation, allowing users to create bindings to 
+Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes
+in-built protections against privilege escalation, allowing users to create bindings to
 roles with rights they do not already have.
 -->
 ### bind 动词  {#bind-verb}
@@ -317,8 +319,8 @@ roles with rights they do not already have.
 <!--
 ### Impersonate verb
 
-This verb allows users to impersonate and gain the rights of other users in the cluster. 
-Care should be taken when granting it, to ensure that excessive permissions cannot be gained 
+This verb allows users to impersonate and gain the rights of other users in the cluster.
+Care should be taken when granting it, to ensure that excessive permissions cannot be gained
 via one of the impersonated accounts.
 -->
 ### impersonate 动词 {#impersonate-verb}
@@ -329,9 +331,9 @@ via one of the impersonated accounts.
 <!--
 ### CSRs and certificate issuing
 
-The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` 
-where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates 
-which allow users to authenticate to the cluster. Those client certificates can have arbitrary 
+The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval`
+where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates
+which allow users to authenticate to the cluster. Those client certificates can have arbitrary
 names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.
 -->
 ### CSR 和证书颁发 {#csrs-and-certificate-issuing}
@@ -346,8 +348,8 @@ CSR API 允许用户拥有 `create` CSR 的权限和 `update`
 <!--
 ### Token request
 
-Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue 
-tokens for existing service accounts. 
+Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue
+tokens for existing service accounts.
 -->
 ### 令牌请求 {#token-request}
 
@@ -357,8 +359,8 @@ TokenRequest 来发布现有服务帐户的令牌。
 <!--
 ### Control admission webhooks
 
-Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` 
-can control webhooks that can read any object admitted to the cluster, and in the case of 
+Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations`
+can control webhooks that can read any object admitted to the cluster, and in the case of
 mutating webhooks, also mutate admitted objects.
 -->
 ### 控制准入 Webhook {#control-admission-webhooks}
@@ -371,6 +373,7 @@ mutating webhooks, also mutate admitted objects.
 ## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
 
 ### Object creation denial-of-service {#object-creation-dos}
+
 Users who have rights to create objects in a cluster may be able to create sufficient large 
 objects to create a denial of service condition either based on the size or number of objects, as discussed in
 [etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be
@@ -397,4 +400,4 @@ to limit the quantity of objects which can be created.
 * To learn more about RBAC, see the [RBAC documentation](/docs/reference/access-authn-authz/rbac/).
 -->
 
-* 了解有关 RBAC 的更多信息，请参阅 [RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/)。
+* 了解有关 RBAC 的更多信息，请参阅 [RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/)。

content/zh-cn/docs/concepts/security/secrets-good-practices.md

@@ -203,10 +203,10 @@ repository means the secret is available to everyone who can read the manifest.
 同时将该 Secret 数据编码为 base64，
 那么共享此文件或将其检入一个源代码仓库就意味着有权读取该清单的所有人都能使用该 Secret。
 
-{{<caution>}}
+{{< caution >}}
 <!--
 Base64 encoding is _not_ an encryption method, it provides no additional
 confidentiality over plain text.
 -->
-Base64 编码 **不是** 一种加密方法，它没有为纯文本提供额外的保密机制。
-{{</caution>}}
+Base64 编码**不是**一种加密方法，它没有为纯文本提供额外的保密机制。
+{{< /caution >}}

content/zh-cn/docs/concepts/services-networking/ingress-controllers.md

@@ -92,7 +92,7 @@ Kubernetes 作为一个项目，目前支持和维护
 <!--
 * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
   lets you use an Ingress to configure F5 BIG-IP virtual servers.
-* [FortiADC Ingress Controller](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller-1-0/742835/fortiadc-ingress-controller-overview) support the Kubernetes Ingress resources and allows you to manage FortiADC objects from Kubernetes
+* [FortiADC Ingress Controller](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller/742835/fortiadc-ingress-controller-overview) support the Kubernetes Ingress resources and allows you to manage FortiADC objects from Kubernetes
 * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
   which offers API gateway functionality.
 * [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for
@@ -105,7 +105,7 @@ Kubernetes 作为一个项目，目前支持和维护
 * F5 BIG-IP 的
   [用于 Kubernetes 的容器 Ingress 服务](https://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)
   让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。
-* [FortiADC Ingress 控制器](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller-1-0/742835/fortiadc-ingress-controller-overview)
+* [FortiADC Ingress 控制器](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller/742835/fortiadc-ingress-controller-overview)
   支持 Kubernetes Ingress 资源，并允许你从 Kubernetes 管理 FortiADC 对象。
 * [Gloo](https://gloo.solo.io) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io) 的
   Ingress 控制器，能够提供 API 网关功能。