[zh] Resync kubeadm files (3)
This commit is contained in:
Qiming Teng
@@ -61,10 +61,9 @@ and kubeadm will use this CA for signing the rest of the certificates.
|
||||
`/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。
|
||||
|
||||
<!--
|
||||
|
||||
## External CA mode {#external-ca-mode}
|
||||
|
||||
It is also possible to provide just the `ca.crt` file and not the
|
||||
It is also possible to provide only the `ca.crt` file and not the
|
||||
`ca.key` file (this is only available for the root CA file, not other cert pairs).
|
||||
If all other certificates and kubeconfig files are in place, kubeadm recognizes
|
||||
this condition and activates the "External CA" mode. kubeadm will proceed without the CA key on disk.
|
||||
@@ -72,27 +71,23 @@ this condition and activates the "External CA" mode. kubeadm will proceed withou
|
||||
|
||||
## 外部 CA 模式 {#external-ca-mode}
|
||||
|
||||
只提供了 `ca.crt` 文件但是不提供 `ca.key` 文件也是可以的（这只对 CA 根证书可用，其它证书不可用）。
|
||||
如果所有的其它证书和 kubeconfig 文件已就绪， kubeadm 检测到满足以上条件就会激活
|
||||
只提供了 `ca.crt` 文件但是不提供 `ca.key` 文件也是可以的
|
||||
（这只对 CA 根证书可用，其它证书不可用）。
|
||||
如果所有的其它证书和 kubeconfig 文件已就绪，kubeadm 检测到满足以上条件就会激活
|
||||
"外部 CA" 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。
|
||||
|
||||
<!--
|
||||
Instead, run the controller-manager standalone with `--controllers=csrsigner` and
|
||||
point to the CA certificate and key.
|
||||
-->
|
||||
否则, kubeadm 将独立运行 controller-manager，附加一个 `--controllers=csrsigner` 的参数，并且指明 CA 证书和密钥。
|
||||
否则, kubeadm 将独立运行 controller-manager，附加一个
|
||||
`--controllers=csrsigner` 的参数，并且指明 CA 证书和密钥。
|
||||
|
||||
<!--
|
||||
[PKI certificates and requirements](/docs/setup/best-practices/certificates/) includes guidance on
|
||||
setting up a cluster to use an external CA.
|
||||
-->
|
||||
[PKI证书和要求](/zh/docs/setup/best-practices/certificates/)包括集群使用外部CA的设置指南。
|
||||
|
||||
<!--
|
||||
[PKI certificates and requirements](/docs/setup/best-practices/certificates/) includes guidance on
|
||||
setting up a cluster to use an external CA.
|
||||
-->
|
||||
[PKI 证书和要求](/zh/docs/setup/best-practices/certificates/)包括关于用外部 CA 设置集群的指南。
|
||||
[PKI 证书和要求](/zh/docs/setup/best-practices/certificates/)包括集群使用外部 CA 的设置指南。
|
||||
|
||||
<!--
|
||||
## Check certificate expiration
|
||||
@@ -415,4 +410,137 @@ For more information about manual rotation or replacement of CA, see [manual rot
|
||||
kubeadm 并不直接支持对 CA 证书的轮换或者替换。
|
||||
|
||||
关于手动轮换或者置换 CA 的更多信息，可参阅
|
||||
[手动轮换 CA 证书](/zh/docs/tasks/tls/manual-rotation-of-ca-certificates/)。
|
||||
[手动轮换 CA 证书](/zh/docs/tasks/tls/manual-rotation-of-ca-certificates/)。
|
||||
|
||||
<!--
|
||||
## Enabling signed kubelet serving certificates {#kubelet-serving-certs}
|
||||
|
||||
By default the kubelet serving certificate deployed by kubeadm is self-signed.
|
||||
This means a connection from external services like the
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) to a
|
||||
kubelet cannot be secured with TLS.
|
||||
|
||||
To configure the kubelets in a new kubeadm cluster to obtain properly signed serving
|
||||
certificates you must pass the following minimal configuration to `kubeadm init`:
|
||||
-->
|
||||
## 启用已签名的 kubelet 服务证书 {#kubelet-serving-certs}
|
||||
|
||||
默认情况下，kubeadm 所部署的 kubelet 服务证书是自签名（Self-Signed））。
|
||||
这意味着从 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
|
||||
这类外部服务发起向 kubelet 的链接时无法使用 TLS 来完成保护。
|
||||
|
||||
要在新的 kubeadm 集群中配置 kubelet 以使用被正确签名的服务证书，
|
||||
你必须向 `kubeadm init` 传递如下最小配置数据：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
---
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
serverTLSBootstrap: true
|
||||
```
|
||||
|
||||
<!--
|
||||
If you have already created the cluster you must adapt it by doing the following:
|
||||
- Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
|
||||
In that ConfigMap, the `config` key has a
|
||||
[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.
|
||||
- On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`
|
||||
and restart the kubelet with `systemctl restart kubelet`
|
||||
-->
|
||||
如果你已经创建了集群，你必须通过执行下面的操作来完成适配：
|
||||
|
||||
- 找到 `kube-system` 名字空间中名为 `kubelet-config-{{< skew latestVersion >}}`
|
||||
的 ConfigMap 并编辑之。
|
||||
在该 ConfigMap 中，`config` 键下面有一个
|
||||
[KubeletConfiguration](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
文档作为其取值。编辑该 KubeletConfiguration 文档以设置
|
||||
`serverTLSBootstrap: true`。
|
||||
- 在每个节点上，在 `/var/lib/kubelet/config.yaml` 文件中添加
|
||||
`serverTLSBootstrap: true` 字段，并使用 `systemctl restart kubelet`
|
||||
来重启 kubelet。
|
||||
|
||||
<!--
|
||||
The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet serving
|
||||
certificates by requesting them from the `certificates.k8s.io` API. One known limitation
|
||||
is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically
|
||||
approved by the default signer in the kube-controller-manager -
|
||||
[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers).
|
||||
This will require action from the user or a third party controller.
|
||||
|
||||
These CSRs can be viewed using:
|
||||
-->
|
||||
字段 `serverTLSBootstrap` 将允许启动引导 kubelet 的服务证书，方式
|
||||
是从 `certificates.k8s.io` API 处读取。这种方式的一种局限在于这些
|
||||
证书的 CSR（证书签名请求）不能被 kube-controller-manager 中默认的
|
||||
签名组件
|
||||
[`kubernetes.io/kubelet-serving`](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)
|
||||
批准。需要用户或者第三方控制器来执行此操作。
|
||||
|
||||
可以使用下面的命令来查看 CSR：
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
```none
|
||||
NAME AGE SIGNERNAME REQUESTOR CONDITION
|
||||
csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending
|
||||
csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending
|
||||
```
|
||||
|
||||
<!--
|
||||
To approve them you can do the following:
|
||||
-->
|
||||
你可以执行下面的操作来批准这些请求：
|
||||
|
||||
```shell
|
||||
kubectl certificate approve <CSR-名称>
|
||||
```
|
||||
|
||||
<!--
|
||||
By default, these serving certificate will expire after one year. Kubeadm sets the
|
||||
`KubeletConfiguration` field `rotateCertificates` to `true`, which means that close
|
||||
to expiration a new set of CSRs for the serving certificates will be created and must
|
||||
be approved to complete the rotation. To understand more see
|
||||
[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation).
|
||||
-->
|
||||
默认情况下，这些服务证书上会在一年后过期。
|
||||
kubeadm 将 `KubeletConfiguration` 的 `rotateCertificates` 字段设置为
|
||||
`true`；这意味着证书快要过期时，会生成一组针对服务证书的新的 CSR，而
|
||||
这些 CSR 也要被批准才能完成证书轮换。
|
||||
要进一步了解这里的细节，可参阅
|
||||
[证书轮换](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)
|
||||
文档。
|
||||
|
||||
<!--
|
||||
If you are looking for a solution for automatic approval of these CSRs it is recommended
|
||||
that you contact your cloud provider and ask if they have a CSR signer that verifies
|
||||
the node identity with an out of band mechanism.
|
||||
-->
|
||||
如果你在寻找一种能够自动批准这些 CSR 的解决方案，建议你与你的云提供商
|
||||
联系，询问他们是否有 CSR 签名组件，用来以带外（out-of-band）的方式检查
|
||||
节点的标识符。
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
Third party custom controllers can be used:
|
||||
- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
|
||||
|
||||
Such a controller is not a secure mechanism unless it not only verifies the CommonName
|
||||
in the CSR but also verifies the requested IPs and domain names. This would prevent
|
||||
a malicious actor that has access to a kubelet client certificate to create
|
||||
CSRs requesting serving certificates for any IP or domain name.
|
||||
-->
|
||||
也可以使用第三方定制的控制器：
|
||||
|
||||
- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
|
||||
|
||||
除非既能够验证 CSR 中的 CommonName，也能检查请求的 IP 和域名，
|
||||
这类控制器还算不得安全的机制。
|
||||
只有完成彻底的检查，才有可能避免有恶意的、能够访问 kubelet 客户端证书的第三方
|
||||
为任何 IP 或域名请求服务证书。
|
||||
|
||||
|
||||
@@ -585,10 +585,10 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
|
||||
- Makes sure the control plane images are available or available to pull to the machine.
|
||||
- Generates replacements and/or uses user supplied overwrites if component configs require version upgrades.
|
||||
- Upgrades the control plane components or rollbacks if any of them fails to come up.
|
||||
- Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
|
||||
- Applies the new `CoreDNS` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
|
||||
- Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
|
||||
-->
|
||||
## 工作原理
|
||||
## 工作原理 {#how-it-works}
|
||||
|
||||
`kubeadm upgrade apply` 做了以下工作：
|
||||
|
||||
@@ -600,7 +600,7 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
|
||||
- 确保控制面的镜像是可用的或可拉取到服务器上。
|
||||
- 如果组件配置要求版本升级，则生成替代配置与/或使用用户提供的覆盖版本配置。
|
||||
- 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
|
||||
- 应用新的 `kube-dns` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。
|
||||
- 应用新的 `CoreDNS` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。
|
||||
- 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。
|
||||
|
||||
<!--
|
||||
|
||||
Reference in New Issue
Block a user