[zh-cn] Update /zh/ to /zh-cn/ for some pages
Sean Wei
parent
27bc9e925b
commit
35462abc89
|
|
@ -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
|
||||
|
||||
Retrieve the certificate from the CSR.
|
||||
Retrieve the certificate from the CSR:
|
||||
-->
|
||||
### 取得证书 {#get-the-certificate}
|
||||
|
||||
|
|
@ -535,7 +535,7 @@ kubectl get csr/myuser -o yaml
|
|||
```
|
||||
|
||||
<!--
|
||||
The Certificate value is in Base64-encoded format under `status.certificate`.
|
||||
The certificate value is in Base64-encoded format under `status.certificate`.
|
||||
|
||||
Export the issued certificate from the CertificateSigningRequest.
|
||||
|
||||
|
|
@ -614,7 +614,7 @@ kubectl config use-context myuser
|
|||
```
|
||||
|
||||
<!--
|
||||
## Approval or rejection {#approval-rejection}
|
||||
## Approval or rejection {#approval-rejection}
|
||||
|
||||
### Control plane automated approval {#approval-rejection-control-plane}
|
||||
|
||||
|
|
@ -699,6 +699,7 @@ status:
|
|||
reason: ApprovedByMyPolicy # You can set this to any string
|
||||
type: Approved
|
||||
```
|
||||
|
||||
<!--
|
||||
For `Denied` CSRs:
|
||||
-->
|
||||
|
|
@ -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节
|
||||
|
|
|
|||
|
|
@ -35,14 +35,14 @@ This in turn, can make it challenging to initialize or scale a cluster.
|
|||
这也使得初始化或者扩缩一个集群的操作变得具有挑战性。
|
||||
|
||||
<!--
|
||||
In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be
|
||||
In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API. The proposal can be
|
||||
found [here](https://github.com/kubernetes/kubernetes/pull/20439).
|
||||
|
||||
This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for
|
||||
kubelets, and how it works.
|
||||
-->
|
||||
为了简化这一过程，从 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/)。
|
||||
|
||||
<!--
|
||||
While any authentication strategy can be used for the kubelet's initial
|
||||
|
|
@ -303,7 +303,7 @@ tokens to a group allows for great flexibility. For example, you could disable a
|
|||
particular bootstrap group's access when you are done provisioning the nodes.
|
||||
-->
|
||||
随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的访问控制（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)
|
||||
的文档以了解进一步的细节。
|
||||
|
||||
<!--
|
||||
|
|
@ -501,7 +501,7 @@ kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA
|
|||
```
|
||||
|
||||
<!--
|
||||
For example:
|
||||
for example:
|
||||
-->
|
||||
例如：
|
||||
|
||||
|
|
@ -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。
|
||||
该组件仅是忽略未被授权的请求。
|
||||
|
|
|
|||
|
|
@ -15,13 +15,16 @@ weight: 95
|
|||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
|
||||
-->
|
||||
WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
|
||||
WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST
|
||||
发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
When specified, mode `Webhook` causes Kubernetes to query an outside REST
|
||||
service when determining user privileges.
|
||||
|
|
@ -37,14 +40,16 @@ service when determining user privileges.
|
|||
Mode `Webhook` requires a file for HTTP configuration, specify by the
|
||||
`--authorization-webhook-config-file=SOME_FILENAME` flag.
|
||||
-->
|
||||
`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
|
||||
`Webhook` 模式需要一个 HTTP 配置文件，通过
|
||||
`--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
|
||||
|
||||
<!--
|
||||
The configuration file uses the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
file format. Within the file "users" refers to the API Server webhook and
|
||||
"clusters" refers to the remote service.
|
||||
-->
|
||||
配置文件的格式使用 [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” 代表着远程服务。
|
||||
|
||||
<!--
|
||||
|
|
@ -135,7 +140,8 @@ compatibility promises for beta objects and check the "apiVersion" field of the
|
|||
request to ensure correct deserialization. Additionally, the API Server must
|
||||
enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
|
||||
-->
|
||||
需要注意的是 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)。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 组件的更多信息。
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Reference in New Issue