From 35462abc89e52209425d1637aa10db4faebc2d52 Mon Sep 17 00:00:00 2001 From: Sean Wei Date: Thu, 28 Jul 2022 09:09:00 +0800 Subject: [PATCH] [zh-cn] Update /zh/ to /zh-cn/ for some pages --- .../certificate-signing-requests.md | 15 ++++++++------- .../kubelet-tls-bootstrapping.md | 18 +++++++++--------- .../reference/access-authn-authz/webhook.md | 17 ++++++++++++----- .../kube-scheduler.md | 4 ++-- .../zh-cn/docs/reference/glossary/affinity.md | 2 +- 5 files changed, 32 insertions(+), 24 deletions(-) diff --git a/content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md index 503818b5ba..2af972ff80 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -447,7 +447,7 @@ O is the group that this user will belong to. You can refer to 下面的脚本展示了如何生成 PKI 私钥和 CSR。 设置 CSR 的 CN 和 O 属性很重要。CN 是用户名，O 是该用户归属的组。 -你可以参考 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。 +你可以参考 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。 ```shell openssl genrsa -out myuser.key 2048 @@ -524,7 +524,7 @@ kubectl certificate approve myuser ### 取得证书 {#get-the-certificate} @@ -535,7 +535,7 @@ kubectl get csr/myuser -o yaml ``` @@ -744,7 +745,7 @@ were marked as approved. ### 控制平面签名者 {#signer-control-plane} Kubernetes 控制平面实现了每一个 -[Kubernetes 签名者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)， +[Kubernetes 签名者](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)， 每个签名者的实现都是 kube-controller-manager 的一部分。 {{< note >}} @@ -780,7 +781,7 @@ Example certificate content: REST API 的用户可以通过向待签名的 CSR 的 `status` 子资源提交更新请求来对 CSR 进行签名。 -作为这个请求的一部分， `status.certificate` 字段应设置为已签名的证书。 +作为这个请求的一部分，`status.certificate` 字段应设置为已签名的证书。 此字段可包含一个或多个 PEM 编码的证书。 所有的 PEM 块必须具备 "CERTIFICATE" 标签，且不包含文件头，且编码的数据必须是 @@ -841,7 +842,7 @@ status: * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986) --> -* 参阅 [管理集群中的 TLS 认证](/zh/docs/tasks/tls/managing-tls-in-a-cluster/) +* 参阅 [管理集群中的 TLS 认证](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/) * 查看 kube-controller-manager 中[签名者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)部分的源代码 * 查看 kube-controller-manager 中[批准者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)部分的源代码 * 有关 X.509 本身的详细信息，请参阅 [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) 第3.1节 diff --git a/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md index 05a3a8d81b..81f08541f0 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md +++ b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md @@ -35,14 +35,14 @@ This in turn, can make it challenging to initialize or scale a cluster. 这也使得初始化或者扩缩一个集群的操作变得具有挑战性。 为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书请求和签名 -API 以便简化此过程。该提案可在 +API。该提案可在 [这里](https://github.com/kubernetes/kubernetes/pull/20439)看到。 本文档描述节点初始化的过程，如何为 kubelet 配置 TLS 客户端证书启动引导， @@ -255,7 +255,7 @@ You can use any [authenticator](/docs/reference/access-authn-authz/authenticatio 为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书， 它必须首先在服务器上认证自身身份。你可以使用任何一种能够对 kubelet 执行身份认证的 -[身份认证组件](/zh/docs/reference/access-authn-authz/authentication/)。 +[身份认证组件](/zh-cn/docs/reference/access-authn-authz/authentication/)。 随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的访问控制（RBAC） -策略上，从而严格限制请求（使用[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)） +策略上，从而严格限制请求（使用[启动引导令牌](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)） 仅限于客户端申请提供证书。当 RBAC 被配置启用时，可以将令牌限制到某个组， 从而提高灵活性。例如，你可以在准备节点期间禁止某特定启动引导组的访问。 @@ -315,7 +315,7 @@ and then issued to the individual kubelet. You can use a single token for an ent --> #### 启动引导令牌 {#bootstrap-tokens} -启动引导令牌的细节在[这里](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +启动引导令牌的细节在[这里](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) 详述。启动引导令牌在 Kubernetes 集群中存储为 Secret 对象，被发放给各个 kubelet。 你可以在整个集群中使用同一个令牌，也可以为每个节点发放单独的令牌。 @@ -347,7 +347,7 @@ The details for creating the secret are available [here](/docs/reference/access- If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag: --> -关于创建 Secret 的进一步细节可访问[这里](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)。 +关于创建 Secret 的进一步细节可访问[这里](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)。 如果你希望使用启动引导令牌，你必须在 kube-apiserver 上使用下面的标志启用之： @@ -397,7 +397,7 @@ further details. --> 向 kube-apiserver 添加 `--token-auth-file=FILENAME` 标志（或许这要对 systemd 的单元文件作修改）以启用令牌文件。参见 -[这里](/zh/docs/reference/access-authn-authz/authentication/#static-token-file) +[这里](/zh-cn/docs/reference/access-authn-authz/authentication/#static-token-file) 的文档以了解进一步的细节。 例如： @@ -603,7 +603,7 @@ collection. --> 作为 [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 的一部分的 `csrapproving` 控制器是自动被启用的。 -该控制器使用 [`SubjectAccessReview` API](/zh/docs/reference/access-authn-authz/authorization/#checking-api-access) +该控制器使用 [`SubjectAccessReview` API](/zh-cn/docs/reference/access-authn-authz/authorization/#checking-api-access) 来确定给定用户是否被授权请求 CSR，之后基于鉴权结果执行批复操作。 为了避免与其它批复组件发生冲突，内置的批复组件不会显式地拒绝任何 CSRs。 该组件仅是忽略未被授权的请求。 diff --git a/content/zh-cn/docs/reference/access-authn-authz/webhook.md b/content/zh-cn/docs/reference/access-authn-authz/webhook.md index 29032a7353..564eee2978 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/webhook.md +++ b/content/zh-cn/docs/reference/access-authn-authz/webhook.md @@ -15,13 +15,16 @@ weight: 95 --> + -WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。 +WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST +发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。 + -`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。 +`Webhook` 模式需要一个 HTTP 配置文件，通过 +`--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。 -配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 +配置文件的格式使用 +[kubeconfig](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。 -需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。 +需要注意的是 webhook API 对象与其他 Kubernetes API +对象一样都同样都遵从[版本兼容规则](/zh-cn/docs/concepts/overview/kubernetes-api/)。 实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。 此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 @@ -267,5 +273,6 @@ to the REST api. For further documentation refer to the authorization.v1beta1 API objects and [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). --> -更多信息可以参考 authorization.v1beta1 API 对象和 [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。 +更多信息可以参考 authorization.v1beta1 API 对象和 +[webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md index 28fb4f2a61..530cf647ff 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -19,14 +19,14 @@ each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. -See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) +See [scheduling](/docs/concepts/scheduling-eviction/) for more information about scheduling and the kube-scheduler component. --> Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。 调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。 调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。 在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。 -参阅[调度](/zh/docs/concepts/scheduling-eviction/)以获得关于调度和 +参阅[调度](/zh-cn/docs/concepts/scheduling-eviction/)以获得关于调度和 kube-scheduler 组件的更多信息。 ``` diff --git a/content/zh-cn/docs/reference/glossary/affinity.md b/content/zh-cn/docs/reference/glossary/affinity.md index 44aa0ab6ca..67da7e05e9 100644 --- a/content/zh-cn/docs/reference/glossary/affinity.md +++ b/content/zh-cn/docs/reference/glossary/affinity.md @@ -2,7 +2,7 @@ title: 亲和性（Affinity） id: affinity date: 2019-01-11 -full_link: zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity +full_link: /zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity short_description: > 调度程序用于确定在何处放置 Pods（亲和性）的规则 aka: