From 2aba8adcfc91b29f5958eb3c917f69f04471ae99 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 1 Aug 2022 18:33:07 +0800 Subject: [PATCH] [zh-cn] updated /kubeadm/implementation-details.md --- .../kubeadm/implementation-details.md | 129 +++++++++--------- 1 file changed, 62 insertions(+), 67 deletions(-) diff --git a/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md index 3c9063d687..82e317ca60 100644 --- a/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -20,7 +20,7 @@ weight: 100 However, it might not be obvious _how_ kubeadm does that. --> `kubeadm init` 和 `kubeadm join` 结合在一起提供了良好的用户体验，因为从头开始创建实践最佳而配置最基本的 Kubernetes 集群。 -但是，kubeadm _如何_ 做到这一点可能并不明显。 +但是，kubeadm **如何** 做到这一点可能并不明显。 -Kubernetes 目录 `/etc/kubernetes` 在应用程序中是一个常量，因为在大多数情况下 -它显然是给定的路径，并且是最直观的位置；其他路径常量和文件名有： +Kubernetes 目录 `/etc/kubernetes` 在应用程序中是一个常量， +因为在大多数情况下它显然是给定的路径，并且是最直观的位置；其他路径常量和文件名有： [`kubeadm init phase`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) 命令允许用户分别调用每个任务，并最终提供可重用且可组合的 API 或工具箱， -其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它来 -创建自定义集群。 +其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它来创建自定义集群。 Kubeadm 在启动 init 之前执行一组预检，目的是验证先决条件并避免常见的集群启动问题。 -用户可以使用 `--ignore-preflight-errors` 选项跳过特定的预检查或全部检查。 +用户可以使用 `--ignore-preflight-errors` 选项跳过特定的预检或全部检查。 - Kubernetes 集群的自签名证书颁发机构会保存到 `ca.crt` 文件和 `ca.key` 私钥文件中 - 用于 API 服务器的服务证书，使用 `ca.crt` 作为 CA 生成，并将证书保存到 `apiserver.crt` - 文件中，私钥保存到 `apiserver.key` 文件中 + 文件中，私钥保存到 `apiserver.key` 文件中。 该证书应包含以下备用名称： - Kubernetes 服务的内部 clusterIP（服务 CIDR 的第一个地址。 例如：如果服务的子网是 `10.96.0.0/12`，则为 `10.96.0.1`） - Kubernetes DNS 名称，例如：如果 `--service-dns-domain` 标志值是 `cluster.local`， 则为 `kubernetes.default.svc.cluster.local`； - 加上默认的 DNS 名称 `kubernetes.default.svc`、`kubernetes.default` 和 `kubernetes`， + 加上默认的 DNS 名称 `kubernetes.default.svc`、`kubernetes.default` 和 `kubernetes` - 节点名称 - `--apiserver-advertise-address` - - 用户指定的其他备用名称 + - 用户指定的其他备用名称 - 用于 API 服务器安全连接到 kubelet 的客户端证书，使用 `ca.crt` 作为 CA 生成， 并保存到 `apiserver-kubelet-client.crt`，私钥保存到 `apiserver-kubelet-client.key` @@ -295,7 +294,7 @@ Kubeadm 生成用于不同目的的证书和私钥对： `front-proxy-client.crt` 文件中，私钥保存到 `front-proxy-client.key` 文件中 证书默认情况下存储在 `/etc/kubernetes/pki` 中，但是该目录可以使用 `--cert-dir` 标志进行配置。 @@ -325,12 +324,12 @@ Please note that: 2. 仅对 CA 来说，如果所有其他证书和 kubeconfig 文件都已就位，则可以只提供 `ca.crt` 文件， 而不提供 `ca.key` 文件。 kubeadm 能够识别出这种情况并启用 ExternalCA，这也意味着了控制器管理器中的 - `csrsigner` 控制器将不会启动 + `csrsigner` 控制器将不会启动。 3. 如果 kubeadm 在 [外部 CA 模式](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#external-ca-mode) - 下运行，所有证书必须由用户提供，因为 kubeadm 无法自行生成它们。 -4. 如果在 `--dry-run` 模式下执行 kubeadm，证书文件将写入一个临时文件夹中 -5. 可以使用 [`kubeadm init phase certs all`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs) + 下运行，所有证书必须由用户提供，因为 kubeadm 无法自行生成证书。 +4. 如果在 `--dry-run` 模式下执行 kubeadm，证书文件将写入一个临时文件夹中。 +5. 可以使用 [`kubeadm init phase certs all`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs) 命令单独生成证书。 1. `ca.crt` 证书内嵌在所有 kubeconfig 文件中。 2. 如果给定的 kubeconfig 文件存在且其内容经过评估符合上述规范，则 kubeadm 将使用现有文件， - 并跳过给定 kubeconfig 的生成阶段 + 并跳过给定 kubeconfig 的生成阶段。 3. 如果 kubeadm 以 [ExternalCA 模式](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode) - 运行，则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 不能自己生成 -4. 如果在 `--dry-run` 模式下执行 kubeadm，则 kubeconfig 文件将写入一个临时文件夹中 + 运行，则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 不能自己生成。 +4. 如果在 `--dry-run` 模式下执行 kubeadm，则 kubeconfig 文件将写入一个临时文件夹中。 5. 可以使用 [`kubeadm init phase kubeconfig all`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig) 命令分别生成 kubeconfig 文件。 @@ -437,7 +436,7 @@ Kubelet 启动后会监视这个目录以便创建 Pod。 - 所有静态 Pod 均使用 `system-node-critical` 优先级 - 所有静态 Pod 都设置了 `hostNetwork:true`，使得控制平面在配置网络之前启动；结果导致： - * 控制器管理器和调度器用来调用 API 服务器的地址为 127.0.0.1。 + * 控制器管理器和调度器用来调用 API 服务器的地址为 `127.0.0.1` * 如果使用本地 etcd 服务器，则 `etcd-servers` 地址将设置为 `127.0.0.1:2379` - 同时为控制器管理器和调度器启用了领导者选举 @@ -451,14 +450,14 @@ Kubelet 启动后会监视这个目录以便创建 Pod。 -1. 所有镜像默认从 k8s.gcr.io 拉取。 +1. 所有镜像默认从 k8s.gcr.io 拉取。 关于自定义镜像仓库，请参阅 [使用自定义镜像](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)。 2. 如果在 `--dry-run` 模式下执行 kubeadm，则静态 Pod 文件写入一个临时文件夹中。 -3. 可以使用 [`kubeadm init phase control-plane all`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) +3. 可以使用 [`kubeadm init phase control-plane all`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) 命令分别生成主控组件的静态 Pod 清单。 - `--enable-admission-plugins` 设为： - - [`NamespaceLifecycle`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) + - [`NamespaceLifecycle`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) 例如，避免删除系统保留的名字空间 - [`LimitRanger`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#limitranger) 和 [`ResourceQuota`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 对名字空间实施限制 - [`ServiceAccount`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) 实施服务账户自动化 - - [`PersistentVolumeLabel`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) + - [`PersistentVolumeLabel`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) 将区域（Region）或区（Zone）标签附加到由云提供商定义的 PersistentVolumes （此准入控制器已被弃用并将在以后的版本中删除）。 如果未明确选择使用 `gce` 或 `aws` 作为云提供商，则默认情况下，v1.9 以后的版本 kubeadm 都不会部署。 - - [`DefaultStorageClass`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) + - [`DefaultStorageClass`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) 在 `PersistentVolumeClaim` 对象上强制使用默认存储类型 - [`DefaultTolerationSeconds`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds) - - [`NodeRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction) + - [`NodeRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 限制 kubelet 可以修改的内容（例如，仅此节点上的 pod） -- `--kubelet-preferred-address-types` 设为 `InternalIP,ExternalIP,Hostname;` +- `--kubelet-preferred-address-types` 设为 `InternalIP,ExternalIP,Hostname;` 这使得在节点的主机名无法解析的环境中，`kubectl log` 和 API 服务器与 kubelet 的其他通信可以工作 - 使用在前面步骤中生成的证书的标志： @@ -596,8 +595,8 @@ The static Pod manifest for the controller manager is affected by following para - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the `--cloud-config` path if such configuration file exists (this is experimental, alpha and will be removed in a future version) --> -- 如果调用 kubeadm 时指定了 `--pod-network-cidr` 参数，则可以通过以下方式启用 - 某些 CNI 网络插件所需的子网管理器功能： +- 如果调用 kubeadm 时指定了 `--pod-network-cidr` 参数， + 则可以通过以下方式启用某些 CNI 网络插件所需的子网管理器功能： - 设置 `--allocate-node-cidrs=true` - 根据给定 CIDR 设置 `--cluster-cidr` 和 `--node-cidr-mask-size` 标志 - 如果指定了云提供商，则指定相应的 `--cloud-provider`，如果存在这样的配置文件， @@ -670,7 +669,7 @@ a local etcd instance running in a Pod with following attributes: 2. 如果 kubeadm 以 `--dry-run` 模式执行，etcd 静态 Pod 清单将写入一个临时文件夹。 3. 可以使用 ['kubeadm init phase etcd local'](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) - 命令单独为本地 etcd 生成静态 Pod 清单 + 命令单独为本地 etcd 生成静态 Pod 清单。 -kubeadm 等待（最多 4m0s），直到 `localhost:6443/healthz`（kube-apiserver 存活）返回 `ok`。 +kubeadm 等待（最多 4m0s），直到 `localhost:6443/healthz`（kube-apiserver 存活）返回 `ok`。 但是为了检测死锁条件，如果 `localhost:10255/healthz`（kubelet 存活）或 `localhost:10255/healthz/syncloop`（kubelet 就绪）未能在 40s 和 60s 内未返回 `ok`， 则 kubeadm 会快速失败。 @@ -721,7 +720,7 @@ state and make new decisions based on that data. --> 1. 在保存 ClusterConfiguration 之前，从配置中删除令牌等敏感信息。 2. 可以使用 - [`kubeadm init phase upload-config`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) + [`kubeadm init phase upload-config`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) 命令单独上传主控节点配置。 1. `node-role.kubernetes.io/master` 污点是已废弃的，将会在 kubeadm 1.25 版本中移除 -1. 可以使用 [`kubeadm init phase mark-control-plane`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) +1. 可以使用 [`kubeadm init phase mark-control-plane`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) 命令单独触发控制平面标记 -`kubeadm init` 确保为该过程正确配置了所有内容，这包括以下步骤以及设置 API 服务器 -和控制器标志，如前几段所述。 +`kubeadm init` 确保为该过程正确配置了所有内容，这包括以下步骤以及设置 API 服务器和控制器标志，如前几段所述。 请注意： @@ -782,7 +780,7 @@ setting API server and controller flags as already described in previous paragra command, executing all the configuration steps described in following paragraphs; alternatively, each step can be invoked individually --> 1. 可以使用 - [`kubeadm init phase bootstrap-token`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) + [`kubeadm init phase bootstrap-token`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) 命令配置节点的 TLS 引导，执行以下段落中描述的所有配置步骤； 或者每个步骤都单独触发。 @@ -814,9 +812,9 @@ Please note that: --> 1. 由 `kubeadm init` 创建的默认令牌将用于在 TLS 引导过程中验证临时用户； 这些用户会成为 `system:bootstrappers:kubeadm:default-node-token` 组的成员。 -2. 令牌的有效期有限，默认为 24 小时（间隔可以通过 `-token-ttl` 标志进行更改） +2. 令牌的有效期有限，默认为 24 小时（间隔可以通过 `-token-ttl` 标志进行更改）。 3. 可以使用 [`kubeadm token`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-token/) - 命令创建其他令牌，这些令牌还提供其他有用的令牌管理功能 + 命令创建其他令牌，这些令牌还提供其他有用的令牌管理功能。 -Kubeadm 确保 `system:bootstrappers:kubeadm:default-node-token` 组中的用户 -能够访问证书签名 API。 +Kubeadm 确保 `system:bootstrappers:kubeadm:default-node-token` 组中的用户能够访问证书签名 API。 -Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准节点的 -新证书的 CSR 请求。 +Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准节点的新证书的 CSR 请求。 -1. 对 `cluster-info` ConfigMap 的访问 _不受_ 速率限制。 +1. 对 `cluster-info` ConfigMap 的访问 **不受** 速率限制。 如果你把 API 服务器暴露到外网，这可能是一个问题，也可能不是； - 这里最坏的情况是 DoS 攻击，攻击者使用 kube-apiserver 能够处理的所有动态请求 - 来为 `cluster-info` ConfigMap 提供服务。 + 这里最坏的情况是 DoS 攻击，攻击者使用 kube-apiserver 能够处理的所有动态请求来为 + `cluster-info` ConfigMap 提供服务。 请参阅[使用引导令牌进行身份验证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) -或相应的[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md)。 +或相应的[设计提案](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md)。 - 首先，通过不安全连接检索 CA 证书（这是可能的，因为 `kubeadm init` 授予 - `system:unauthenticated` 的用户对 `cluster-info` 访问权限） + `system:unauthenticated` 的用户对 `cluster-info` 访问权限）。 - 然后 CA 证书通过以下验证步骤： - 基本验证：使用令牌 ID 而不是 JWT 签名 - 公钥验证：使用提供的 `--discovery-token-ca-cert-hash`。这个值来自 `kubeadm init` 的输出， 或者可以使用标准工具计算（哈希值是按 RFC7469 中主体公钥信息（SPKI）对象的字节计算的） `--discovery-token-ca-cert-hash` 标志可以重复多次，以允许多个公钥。 - - 作为附加验证，通过安全连接检索 CA 证书，然后与初始检索的 CA 进行比较 + - 作为附加验证，通过安全连接检索 CA 证书，然后与初始检索的 CA 进行比较。 请注意： @@ -1094,8 +1090,7 @@ the cluster CA certificates from the `cluster-info` ConfigMap in the `kube-publ If `kubeadm join` is invoked with `--discovery-file`, file discovery is used; this file can be a local file or downloaded via an HTTPS URL; in case of HTTPS, the host installed CA bundle is used to verify the connection. --> 如果带 `--discovery-file` 参数调用 `kubeadm join`，则使用文件发现功能； -该文件可以是本地文件或通过 HTTPS URL 下载；对于 HTTPS，主机安装的 CA 包 -用于验证连接。 +该文件可以是本地文件或通过 HTTPS URL 下载；对于 HTTPS，主机安装的 CA 包用于验证连接。 -TLS 引导机制使用共享令牌对 Kubernetes API 服务器进行临时身份验证，以便 -为本地创建的密钥对提交证书签名请求（CSR）。 +TLS 引导机制使用共享令牌对 Kubernetes API 服务器进行临时身份验证， +以便为本地创建的密钥对提交证书签名请求（CSR）。