kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #32318 from my-git9/my_demo_branch 

[zh] Update kubelet-tls-bootstrapping.md
pull/32314/merge
Kubernetes Prow Robot 2022-03-17 03:37:20 -07:00 committed by GitHub
parent faf69fcb38 87f67c8a72
commit fc92346868
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/zh/docs/reference/access-authn-authz/authorization.md
View File

@ -263,7 +263,7 @@ no
```
<!--
Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
can list Pods in the Namespace `target`:
-->
类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账号是否可以列举名字空间 `target` 里的 Pod：

26
content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
View File

@ -15,12 +15,12 @@ content_type: concept
<!-- overview -->
<!--
In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver.
In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
recommend using client TLS certificates on nodes.
-->
在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与
Kubernetes 主控组件通信，尤其是 kube-apiserver。
Kubernetes 控制平面组件通信，尤其是 kube-apiserver。
为了确保通信本身是私密的、不被干扰，并且确保集群的每个组件都在与另一个
可信的组件通信，我们强烈建议使用节点上的客户端 TLS 证书。
@ -89,7 +89,7 @@ Note that the above process depends upon:
All of the following are responsibilities of whoever sets up and manages the cluster:
1. Creating the CA key and certificate
2. Distributing the CA certificate to the master nodes, where kube-apiserver is running
2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running
3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
4. Signing the kubelet certificate using the CA key
5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running
@ -100,7 +100,7 @@ a cluster.
负责部署和管理集群的人有以下责任：
1. 创建 CA 密钥和证书
2. 将 CA 证书发布到 kube-apiserver 运行所在的主控节点上
2. 将 CA 证书发布到 kube-apiserver 运行所在的控制平面节点上
3. 为每个 kubelet 创建密钥和证书；强烈建议为每个 kubelet 使用独一无二的、
CN 取值与众不同的密钥和证书
4. 使用 CA 密钥对 kubelet 证书签名
@ -191,21 +191,21 @@ In addition, you need your Kubernetes Certificate Authority (CA).
## Certificate Authority
As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes.
-->
## 证书机构 {#certificate-authority}
就像在没有启动引导的情况下，你会需要证书机构（CA）密钥和证书。
这些数据会被用来对 kubelet 证书进行签名。
如前所述，将证书机构密钥和证书发布到主控节点是你的责任。
如前所述，将证书机构密钥和证书发布到控制平面节点是你的责任。
<!--
For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
We will refer to these as "Kubernetes CA certificate and key".
All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
-->
就本文而言，我们假定这些数据被发布到主控节点上的
就本文而言，我们假定这些数据被发布到控制平面节点上的
`/var/lib/kubernetes/ca.pem`（证书）和
`/var/lib/kubernetes/ca-key.pem`（密钥）文件中。
我们将这两个文件称作“Kubernetes CA 证书和密钥”。
@ -360,7 +360,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t
<!--
#### Token authentication file
kube-apiserver has an ability to accept tokens as authentication.
kube-apiserver has the ability to accept tokens as authentication.
These tokens are arbitrary but should represent at least 128 bits of entropy derived
from a secure random number generator (such as `/dev/urandom` on most modern Linux
systems). There are multiple ways you can generate a token. For example:
@ -475,12 +475,12 @@ In order for the controller-manager to sign certificates, it needs the following
<!--
### Access to key and certificate
As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes.
As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes.
These will be used by the controller-manager to sign the kubelet certificates.
-->
### 访问密钥和证书 {#access-to-key-and-certificate}
如前所述，你需要创建一个 Kubernetes CA 密钥和证书，并将其发布到主控节点。
如前所述，你需要创建一个 Kubernetes CA 密钥和证书，并将其发布到控制平面节点。
这些数据会被控制器管理器来对 kubelet 证书进行签名。
<!--
@ -614,11 +614,11 @@ collection.
<!--
## kubelet configuration
Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
Finally, with the control plane properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
-->
## kubelet 配置 {#kubelet-configuration}
最后，当主控节点被正确配置并且所有必要的身份认证和鉴权机制都就绪时，
最后，当控制平面节点被正确配置并且所有必要的身份认证和鉴权机制都就绪时，
我们可以配置 kubelet。
<!--