diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md index 29dbd3e895..daa5b679e2 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md @@ -2,19 +2,16 @@ - ### 概要 - 为其他用户输出 kubeconfig 文件。 - Alpha 免责声明：此命令当前为 Alpha 功能。 ``` @@ -23,19 +20,22 @@ kubeadm alpha kubeconfig user [flags] +``` + # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar + kubeadm alpha kubeconfig user --client-name=foo --config=bar +``` +--> ### 示例 ``` -# 为名为 foo 的其他用户输出 kubeconfig 文件 -kubeadm alpha kubeconfig user --client-name=foo +# 使用名为 bar 的 kubeadm 配置文件为名为 foo 的另一用户输出 kubeconfig 文件 +kubeadm alpha kubeconfig user --client-name=foo --config=bar ``` - ### 选项 @@ -45,52 +45,6 @@ kubeadm alpha kubeconfig user --client-name=foo - - - - - - - - - - - - - - - - - - - - - @@ -99,7 +53,19 @@ The path where certificates are stored -用户名。如果创建了客户端证书，它将用作 CN。 +用户名。如果生成客户端证书，则用作其 CN。 + + + + + + + + @@ -123,13 +89,14 @@ user 操作的帮助命令 -客户端证书的组织。如果创建了客户端证书，它将用作 O。 +客户端证书的组织。如果创建客户端证书，此值将用作其 O 字段值。 +
--apiserver-advertise-address string
- -可通过以下网址访问 API 服务器的 IP 地址 -
- ---apiserver-bind-port int32     默认值: 6443 -
- -可通过其访问 API 服务器的端口 -
- ---cert-dir string     默认值: "/etc/kubernetes/pki" -
- -证书存储的路径 -
--client-name string
--config string
+ +指向 kubeadm 配置文件的路径
--token string
- ### 从父命令继承的选项 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md index fe02e3d078..c4eb30e987 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md @@ -2,13 +2,11 @@ - ### 概要 - 生成所有的静态 Pod 清单文件 ``` @@ -17,27 +15,27 @@ kubeadm init phase control-plane all [flags] - - ### 示例 ``` -# 为 etcd 生成静态 Pod 清单文件，其功能等效于 kubeadm init 生成的文件。 +# 为控制平面组件生成静态 Pod 清单文件，其功能等效于 kubeadm init 生成的文件。 kubeadm init phase control-plane all -# 使用从配置文件读取的选项为 etcd 生成静态 Pod 清单文件。 +# 使用从某配置文件中读取的选项为生成静态 Pod 清单文件。 kubeadm init phase control-plane all --config config.yaml ``` - ### 选项
@@ -60,19 +58,15 @@ API 服务器所公布的其正在监听的 IP 地址。如果未设置，将使 - + + @@ -84,7 +78,8 @@ Port for the API Server to bind to. -传递给 API 服务器一组额外的参数或者以 <flagname>=<value> 的形式覆盖默认值。 +形式为 <flagname>=<value> 的一组额外参数，用来传递给 API 服务器， +或者覆盖其默认配置值 @@ -137,7 +132,25 @@ Specify a stable IP address or DNS name for the control plane. -传递给控制管理器（Controller Manager）一组额外的标志或者以 <flagname>=<value> 的形式覆盖默认值。 +一组形式为 <flagname>=<value> 的额外参数，用来传递给控制管理器（Controller Manager） +或覆盖其默认设置值 + + + + + + + + @@ -149,7 +162,7 @@ A set of extra flags to pass to the Controller Manager or override default ones -一组用来描述各种功能特性的键值（key=value）对。选项是： +一组用来描述各种特性门控的键值（key=value）对。选项是：
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false) @@ -209,7 +222,7 @@ Choose a specific Kubernetes version for the control plane. -指定 Pod 网络的 IP 地址范围。如果已设置，控制平面将自动地为每个节点分配 CIDR。 +指定 Pod 网络的 IP 地址范围。如果设置了此标志，控制平面将自动地为每个节点分配 CIDR。 @@ -221,6 +234,9 @@ Specify range of IP addresses for the pod network. If set, the control plane wil +一组形式为 <flagname>=<value> 的额外参数，用来传递给调度器（Scheduler） +或覆盖其默认设置值 + 传递给调度器（scheduler）一组额外的参数或者以 <flagname>=<value> 形式覆盖其默认值。 @@ -248,7 +264,6 @@ Use alternative range of IP address for service VIPs. - ### 从父指令继承的选项
- ---apiserver-bind-port int32     默认值：6443 ---apiserver-bind-port int32     默认值：6443
-要绑定到 API 服务器的端口。 +API 服务器要绑定的端口。
--experimental-patches string
+ +包含名为 "target[suffix][+patchtype].extension" 的文件的目录。 +例如，"kube-apiserver0+merge.yaml" 或者 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，分别与 kubectl +所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。 +"extension" 必须是 "json" 或 "yaml"。 +"suffix" 是一个可选的字符串，用来确定按字母顺序排序时首先应用哪些 patch。
@@ -272,3 +287,4 @@ Use alternative range of IP address for service VIPs.
+ diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md index e480efd952..39d9316717 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md @@ -1,13 +1,11 @@ - ### 概要 - 生成 kube-apiserver 静态 Pod 清单 ``` @@ -17,7 +15,6 @@ kubeadm init phase control-plane apiserver [flags] - ### 选项 @@ -64,7 +61,8 @@ Port for the API Server to bind to. -一组额外的参数以 <flagname>=<value> 形式传递给 API 服务器或者覆盖默认参数 +一组 <flagname>=<value> 形式的额外参数，用来传递给 API 服务器 +或者覆盖其默认参数配置 @@ -109,6 +107,18 @@ Specify a stable IP address or DNS name for the control plane. + + + + @@ -117,7 +127,7 @@ Specify a stable IP address or DNS name for the control plane. -一组键值对，用于描述各种特征的特征事项。选项是： +一组键值对，用于描述各种功能特性的特性门控。选项是：
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false) diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md index f13f966676..d35b86f363 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md @@ -2,13 +2,11 @@ - ### 概要 - 生成 kube-controller-manager 静态 Pod 清单 ``` @@ -18,7 +16,6 @@ kubeadm init phase control-plane controller-manager [flags] - ### 选项
+ +包含名为 "target[suffix][+patchtype].extension" 的文件的目录。 +例如，"kube-apiserver0+merge.yaml" 或者 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，分别与 kubectl +所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。 +"extension" 必须是 "json" 或 "yaml"。 +"suffix" 是一个可选的字符串，用来确定按字母顺序排序时首先应用哪些 patch。 +
--feature-gates string
@@ -29,12 +26,8 @@ kubeadm init phase control-plane controller-manager [flags] - + + + + + + @@ -123,7 +129,7 @@ Choose a specific Kubernetes version for the control plane. -指定 Pod 网络的 IP 地址范围。如果已设置，控制平面将自动为每个节点分配 CIDR。 +指定 Pod 网络的 IP 地址范围。如果设置，控制平面将自动为每个节点分配 CIDR。 @@ -133,7 +139,6 @@ Specify range of IP addresses for the pod network. If set, the control plane wil - ### 从父命令继承的选项
- ---cert-dir string     默认值："/etc/kubernetes/pki" ---cert-dir string     默认值："/etc/kubernetes/pki"
@@ -65,7 +58,20 @@ kubeadm 配置文件的路径。 -一组额外的参数以 <flagname>=< 形式传递给 Controller Manager 或者覆盖默认参数 +一组 <flagname>=< 形式的额外参数，传递给控制器管理器（Controller Manager） +或者覆盖其默认配置值 +
+ +包含名为 "target[suffix][+patchtype].extension" 的文件的目录。 +例如，"kube-apiserver0+merge.yaml" 或者 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，分别与 kubectl +所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。 +"extension" 必须是 "json" 或 "yaml"。 +"suffix" 是一个可选的字符串，用来确定按字母顺序排序时首先应用哪些 patch。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md index fea8bf741a..ce801ff399 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md @@ -2,13 +2,11 @@ - ### 概要 - 生成 kube-scheduler 静态 Pod 清单 ``` @@ -18,7 +16,6 @@ kubeadm init phase control-plane scheduler [flags] - ### 选项
@@ -57,6 +54,22 @@ kubeadm 配置文件的路径。 + + + + + + + + @@ -111,7 +124,8 @@ Choose a specific Kubernetes version for the control plane. -一组额外的参数以 <flagname>=<value> 形式传递给 Scheduler 或者覆盖默认参数 +一组 <flagname>=<value> 形式的额外参数，用来传递给调度器 +或者覆盖其默认参数配置 @@ -121,7 +135,6 @@ A set of extra flags to pass to the Scheduler or override default ones in form o - ### 继承于父命令的选项
--experimental-patches string
+ +包含名为 "target[suffix][+patchtype].extension" 的文件的目录。 +例如，"kube-apiserver0+merge.yaml" 或者 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，分别与 kubectl +所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。 +"extension" 必须是 "json" 或 "yaml"。 +"suffix" 是一个可选的字符串，用来确定按字母顺序排序时首先应用哪些 patch。 +
-h, --help
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md index b6c1567677..bf88802947 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md @@ -2,13 +2,11 @@ - ### 概要 - 此命令并非设计用来单独运行。请参阅可用子命令列表。 ``` @@ -18,7 +16,6 @@ kubeadm init phase upload-certs [flags] - ### 选项
@@ -64,6 +61,18 @@ upload-certs 操作的帮助命令 + + + + + + + + + @@ -94,7 +103,6 @@ Upload control-plane certificates to the kubeadm-certs Secret. - ### 从父命令继承的选项
--kubeconfig string     默认值："/etc/kubernetes/admin.conf"
+用来与集群通信的 kubeconfig 文件。 +如果此标志未设置，则可以在一组标准的位置搜索现有的 kubeconfig 文件。 +
--skip-certificate-key-print
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md index 4d8ea53fa3..ee17bb699a 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -4,14 +4,12 @@ content_type: concept weight: 100 --- @@ -31,11 +29,13 @@ with the aim of sharing knowledge on Kubernetes cluster best practices. 本文档提供了更多幕后的详细信息，旨在分享有关 Kubernetes 集群最佳实践的知识。 - + ## 核心设计原则 {#core-design-principles} -`kubeadm init` 和 `kubeadm join` 设置的集群应为： +`kubeadm init` 和 `kubeadm join` 设置的集群该是： - - **安全**：它应采用最新的最佳实践，例如： - - 应用 RBAC - - 使用节点鉴权机制（Node Authorizer） - - 在控制平面组件之间使用安全通信 - - 在 API 服务器和 kubelet 之间使用安全通信 - - 锁定 kubelet API - - 锁定对系统组件（例如 kube-proxy 和 CoreDNS）的 API 的访问 - - 锁定启动引导令牌（Bootstrap Token）可以访问的内容 - - **易用**：用户只需要运行几个命令即可： - - `kubeadm init` - - `export KUBECONFIG=/etc/kubernetes/admin.conf` - - `kubectl apply -f ` - - `kubeadm join --token :` - - **可扩展**： - - _不_ 应偏向任何特定的网络提供商。不涉及配置集群网络 - - 应该可以使用配置文件来自定义各种参数 +--> +- **安全的**：它应采用最新的最佳实践，例如： + - 实施 RBAC 访问控制 + - 使用节点鉴权机制（Node Authorizer） + - 在控制平面组件之间使用安全通信 + - 在 API 服务器和 kubelet 之间使用安全通信 + - 锁定 kubelet API + - 锁定对系统组件（例如 kube-proxy 和 CoreDNS）的 API 的访问 + - 锁定启动引导令牌（Bootstrap Token）可以访问的内容 +- **易用的**：用户只需要运行几个命令即可： + - `kubeadm init` + - `export KUBECONFIG=/etc/kubernetes/admin.conf` + - `kubectl apply -f <所选网络.yaml>` + - `kubeadm join --token <令牌> <端点>:<端口>` +- **可扩展的**： + - _不_ 应偏向任何特定的网络提供商。不涉及配置集群网络 + - 应该可以使用配置文件来自定义各种参数 - + ## 常量以及众所周知的值和路径 {#constants-and-well-known-values-and-paths} -为了降低复杂性并简化基于 kubeadm 的高级工具的开发，对于众所周知的路径和文件名，它使用了一组有限的常量值。 +为了降低复杂性并简化基于 kubeadm 的高级工具的开发，对于众所周知的路径和文件名， +kubeadm 使用了一组有限的常量值。 -Kubernetes 目录 `/etc/kubernetes` 在应用程序中是一个常量，因为在大多数情况下它显然是给定的路径，并且是最直观的位置； -其他路径常量和文件名有： +Kubernetes 目录 `/etc/kubernetes` 在应用程序中是一个常量，因为在大多数情况下 +它显然是给定的路径，并且是最直观的位置；其他路径常量和文件名有： - `/etc/kubernetes/manifests` 作为 kubelet 查找静态 Pod 清单的路径。静态 Pod 清单的名称为： - - `etcd.yaml` - - `kube-apiserver.yaml` - - `kube-controller-manager.yaml` - - `kube-scheduler.yaml` + - `etcd.yaml` + - `kube-apiserver.yaml` + - `kube-controller-manager.yaml` + - `kube-scheduler.yaml` - `/etc/kubernetes/` 作为带有控制平面组件身份标识的 kubeconfig 文件的路径。kubeconfig 文件的名称为： - - `kubelet.conf` (在 TLS 引导时名称为 `bootstrap-kubelet.conf` ) - - `controller-manager.conf` - - `scheduler.conf` - - `admin.conf` 用于集群管理员和 kubeadm 本身 + - `kubelet.conf` (在 TLS 引导时名称为 `bootstrap-kubelet.conf` ) + - `controller-manager.conf` + - `scheduler.conf` + - `admin.conf` 用于集群管理员和 kubeadm 本身 - 证书和密钥文件的名称： - - `ca.crt`, `ca.key` 用于 Kubernetes 证书颁发机构 - - `apiserver.crt`, `apiserver.key` 用于 API 服务器证书 - - `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` 用于 API 服务器安全地连接到 kubelet 的客户端证书 - - `sa.pub`, `sa.key` 用于签署 ServiceAccount 时 控制器管理器使用的密钥 - - `front-proxy-ca.crt`, `front-proxy-ca.key` 用于前端代理证书颁发机构 - - `front-proxy-client.crt`, `front-proxy-client.key` 用于前端代理客户端 + - `ca.crt`, `ca.key` 用于 Kubernetes 证书颁发机构 + - `apiserver.crt`, `apiserver.key` 用于 API 服务器证书 + - `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` + 用于 API 服务器安全地连接到 kubelet 的客户端证书 + - `sa.pub`, `sa.key` 用于控制器管理器签署 ServiceAccount 时使用的密钥 + - `front-proxy-ca.crt`, `front-proxy-ca.key` 用于前端代理证书颁发机构 + - `front-proxy-client.crt`, `front-proxy-client.key` 用于前端代理客户端 - + ## kubeadm init 工作流程内部设计 {#kubeadm-init-workflow-internal-design} -`kubeadm init` [内部工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow)包含一系列要执行的原子工作任务， -如 `kubeadm init` 中所述。 +`kubeadm init` [内部工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow) +包含一系列要执行的原子性工作任务，如 `kubeadm init` 中所述。 -[`kubeadm init phase`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) 命令允许用户分别调用每个任务， -并最终提供可重用且可组合的 API 或工具箱，其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它用来创建的自定义集群。 +[`kubeadm init phase`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) +命令允许用户分别调用每个任务，并最终提供可重用且可组合的 API 或工具箱， +其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它来 +创建自定义集群。 - + ### 预检 {#preflight-checks} -- [警告] 如果要使用的 Kubernetes 版本（由 `--kubernetes-version` 标志指定）比 kubeadm CLI 版本至少高一个小版本。 +- [警告] 如果要使用的 Kubernetes 版本（由 `--kubernetes-version` 标志指定）比 kubeadm CLI + 版本至少高一个小版本。 - Kubernetes 系统要求： - 如果在 linux上运行： - [错误] 如果内核早于最低要求的版本 @@ -242,16 +253,18 @@ Kubeadm 在启动 init 之前执行一组预检，目的是验证先决条件并 -1. 可以使用 [`kubeadm init phase preflight`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-preflight) 命令单独触发预检。 +1. 可以使用 [`kubeadm init phase preflight`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-preflight) + 命令单独触发预检。 - - + ### 生成必要的证书 {#generate-the-necessary-certificate} Kubeadm 生成用于不同目的的证书和私钥对： - - - Kubernetes 集群的自签名证书颁发机构已保存到 `ca.crt` 文件和 `ca.key` 私钥文件中 - - 用于 API 服务器的服务证书，使用 `ca.crt` 作为 CA 生成，并将证书保存到 `apiserver.crt` 文件中，私钥保存到 `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`， - - 节点名称 - - `--apiserver-advertise-address` - - 用户指定的其他备用名称 - - API 服务器用于安全连接到 kubelet 的客户端证书，使用 `ca.crt` 作为 CA 生成，并保存到 `apiserver-kubelet-client.key`， - 私钥保存到 `apiserver-kubelet-client.crt` 文件中。该证书应该在 `system:masters` 组织中 - - 用于签名 ServiceAccount 令牌的私钥保存到 `sa.key` 文件中，公钥保存到 `sa.pub` 文件中 - - 用于前端代理的证书颁发机构保存到 `front-proxy-ca.crt` 文件中，私钥保存到 `front-proxy-ca.key` 文件中 - - 前端代理客户端的客户端证书，使用 `front-proxy-ca.crt` 作为 CA 生成，并保存到 `front-proxy-client.crt` 文件中， - 私钥保存到 `front-proxy-client.key` 文件中 +- Kubernetes 集群的自签名证书颁发机构会保存到 `ca.crt` 文件和 `ca.key` 私钥文件中 +- 用于 API 服务器的服务证书，使用 `ca.crt` 作为 CA 生成，并将证书保存到 `apiserver.crt` + 文件中，私钥保存到 `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`， + - 节点名称 + - `--apiserver-advertise-address` + - 用户指定的其他备用名称 + +- 用于 API 服务器安全连接到 kubelet 的客户端证书，使用 `ca.crt` 作为 CA 生成， + 并保存到 `apiserver-kubelet-client.crt`，私钥保存到 `apiserver-kubelet-client.key` + 文件中。该证书应该在 `system:masters` 组织中。 +- 用于签名 ServiceAccount 令牌的私钥保存到 `sa.key` 文件中，公钥保存到 `sa.pub` 文件中 +- 用于前端代理的证书颁发机构保存到 `front-proxy-ca.crt` 文件中，私钥保存到 + `front-proxy-ca.key` 文件中 +- 前端代理客户端的客户端证书，使用 `front-proxy-ca.crt` 作为 CA 生成，并保存到 + `front-proxy-client.crt` 文件中，私钥保存到 `front-proxy-client.key` 文件中 证书默认情况下存储在 `/etc/kubernetes/pki` 中，但是该目录可以使用 `--cert-dir` 标志进行配置。 - - 请注意： + +请注意： -1. 如果证书和私钥对都存在，并且其内容经过评估符合上述规范，将使用现有文件，并且跳过给定证书的生成阶段。 - 这意味着用户可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.{crt,key}`，kubeadm 将使用这些文件对其余证书进行签名。 - 请参阅[使用自定义证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#custom-certificates) -2. 仅对 CA 来说，如果所有其他证书和 kubeconfig 文件都已就位，则可以只提供 `ca.crt` 文件，而不提供 `ca.key` 文件。 - kubeadm 已经识别出这种情况并启用 ExternalCA，这也意味着了控制器管理器中的 `csrsigner` 控制器将不会启动 -3. 如果 kubeadm 在[外部 CA 模式](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#external-ca-mode)下运行； - 所有证书必须由用户提供，因为 kubeadm 无法自行生成它们 +1. 如果证书和私钥对都存在，并且其内容经过评估符合上述规范，将使用现有文件， + 并且跳过给定证书的生成阶段。 + 这意味着用户可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.{crt,key}`， + kubeadm 将使用这些文件对其余证书进行签名。 + 请参阅[使用自定义证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#custom-certificates)。 +2. 仅对 CA 来说，如果所有其他证书和 kubeconfig 文件都已就位，则可以只提供 `ca.crt` 文件， + 而不提供 `ca.key` 文件。 + kubeadm 能够识别出这种情况并启用 ExternalCA，这也意味着了控制器管理器中的 + `csrsigner` 控制器将不会启动 +3. 如果 kubeadm 在 + [外部 CA 模式](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#external-ca-mode) + 下运行，所有证书必须由用户提供，因为 kubeadm 无法自行生成它们。 4. 如果在 `--dry-run` 模式下执行 kubeadm，证书文件将写入一个临时文件夹中 5. 可以使用 [`kubeadm init phase certs all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs) 命令单独生成证书。 - + ### 为控制平面组件生成 kubeconfig 文件 {#generate-kubeconfig-files-for-control-plane-components} -- 供 kubelet 在 TLS 引导期间使用的 kubeconfig 文件——`/etc/kubernetes/bootstrap-kubelet.conf`。在此文件中， - 有一个引导令牌或内嵌的客户端证书，向集群表明此节点身份。 +- 供 kubelet 在 TLS 引导期间使用的 kubeconfig 文件 —— `/etc/kubernetes/bootstrap-kubelet.conf`。 + 在此文件中，有一个引导令牌或内嵌的客户端证书，向集群表明此节点身份。 此客户端证书应： - - 根据[节点鉴权](/zh/docs/reference/access-authn-authz/node/)模块的要求，属于 `system:nodes` 组织 - - 具有通用名称（CN）：`system:node:` -- 控制器管理器的 kubeconfig 文件——`/etc/kubernetes/controller-manager.conf`； + + - 根据[节点鉴权](/zh/docs/reference/access-authn-authz/node/)模块的要求，属于 `system:nodes` 组织 + - 具有通用名称（CN）：`system:node:<小写主机名>` + +- 控制器管理器的 kubeconfig 文件 —— `/etc/kubernetes/controller-manager.conf`； 在此文件中嵌入了一个具有控制器管理器身份标识的客户端证书。 此客户端证书应具有 CN：`system:kube-controller-manager`， - 这是由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles)默认定义的。 -- 调度器的 kubeconfig 文件——`/etc/kubernetes/scheduler.conf`；在此文件中嵌入了具有调度器身份标识的客户端证书。 - 此客户端证书应具有 CN：`system:kube-scheduler`， - 这是由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles)默认定义的。 + 该 CN 由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles) + 默认定义的。 + +- 调度器的 kubeconfig 文件 —— `/etc/kubernetes/scheduler.conf`； + 此文件中嵌入了具有调度器身份标识的客户端证书。此客户端证书应具有 CN：`system:kube-scheduler`， + 该 CN 由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles) + 默认定义的。 -另外，一个用于 kubeadm 本身和 admin 的 kubeconfig 文件也被生成并保存到 `/etc/kubernetes/admin.conf` 文件中。 +另外，用于 kubeadm 本身和 admin 的 kubeconfig 文件也被生成并保存到 +`/etc/kubernetes/admin.conf` 文件中。 此处的 admin 定义为正在管理集群并希望完全控制集群（**root**）的实际人员。 内嵌的 admin 客户端证书应是 `system:masters` 组织的成员， -这是由默认的 [RBAC 面向用户的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#user-facing-roles)定义的。 -它还应包括一个 CN。 Kubeadm 使用 `kubernetes-admin` CN。 +这一组织名由默认的 [RBAC 面向用户的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#user-facing-roles) +定义。它还应包括一个 CN。kubeadm 使用 `kubernetes-admin` CN。 请注意： @@ -372,14 +407,18 @@ CN. Kubeadm uses the `kubernetes-admin` CN. 5. Kubeconfig files generation can be invoked individually with the [`kubeadm init phase kubeconfig all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig) command --> 1. `ca.crt` 证书内嵌在所有 kubeconfig 文件中。 -2. 如果给定的 kubeconfig 文件存在且其内容经过评估符合上述规范，则 kubeadm 将使用现有文件，并跳过给定 kubeconfig 的生成阶段 -3. 如果 kubeadm 以 [ExternalCA 模式](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode)运行， - 则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 不能自己生成 +2. 如果给定的 kubeconfig 文件存在且其内容经过评估符合上述规范，则 kubeadm 将使用现有文件， + 并跳过给定 kubeconfig 的生成阶段 +3. 如果 kubeadm 以 [ExternalCA 模式](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode) + 运行，则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 不能自己生成 4. 如果在 `--dry-run` 模式下执行 kubeadm，则 kubeconfig 文件将写入一个临时文件夹中 -5. 可以使用 [`kubeadm init phase kubeconfig all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig) - 命令分别生成 Kubeconfig 文件。 +5. 可以使用 + [`kubeadm init phase kubeconfig all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig) + 命令分别生成 kubeconfig 文件。 - + ### 为控制平面组件生成静态 Pod 清单 {#generate-static-pod-manifests-for-control-plane-components} -- 所有静态 Pod 都部署在 `kube-system` 命名空间 -- 所有静态 Pod 都打上 `tier:ontrol-plane` 和 `component:{component-name}` 标签 +- 所有静态 Pod 都部署在 `kube-system` 名字空间 +- 所有静态 Pod 都打上 `tier:ontrol-plane` 和 `component:{组件名称}` 标签 - 所有静态 Pod 均使用 `system-node-critical` 优先级 - 所有静态 Pod 都设置了 `hostNetwork:true`，使得控制平面在配置网络之前启动；结果导致： - * 控制器管理器和调度器用来调用 API 服务器的地址为 127.0.0.1。 - * 如果使用本地 etcd 服务器，则 `etcd-servers` 地址将设置为 `127.0.0.1:2379` + + * 控制器管理器和调度器用来调用 API 服务器的地址为 127.0.0.1。 + * 如果使用本地 etcd 服务器，则 `etcd-servers` 地址将设置为 `127.0.0.1:2379` + - 同时为控制器管理器和调度器启用了领导者选举 - 控制器管理器和调度器将引用 kubeconfig 文件及其各自的唯一标识 -- 如[将自定义参数传递给控制平面组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)中所述， - 所有静态 Pod 都会获得用户指定的额外标志 +- 如[将自定义参数传递给控制平面组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/) + 中所述，所有静态 Pod 都会获得用户指定的额外标志 - 所有静态 Pod 都会获得用户指定的额外卷（主机路径） @@ -420,21 +461,23 @@ Kubelet 启动后会监视这个目录以便创建 Pod。 1. 所有镜像默认从 k8s.gcr.io 拉取。 - 关于自定义镜像仓库，请参阅[使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) -2. 如果在 `--dry-run` 模式下执行 kubeadm，则静态 Pod 文件写入一个临时文件夹中 + 关于自定义镜像仓库，请参阅 + [使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)。 +2. 如果在 `--dry-run` 模式下执行 kubeadm，则静态 Pod 文件写入一个临时文件夹中。 3. 可以使用 [`kubeadm init phase control-plane all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) 命令分别生成主控组件的静态 Pod 清单。 - -#### API 服务器 {#api-server} + +#### API 服务器 {#api-server} + API 服务器的静态 Pod 清单会受到用户提供的以下参数的影响: -- 要绑定的 `apiserver-advertise-address` 和 `apiserver-bind-port`；如果未提供，则这些值默认为机器上默认网络接口的 IP 地址和 6443 端口。 - - `service-cluster-ip-range` 给 service 使用 - - 如果指定了外部 etcd 服务器，则应指定 `etcd-servers` 地址和相关的 TLS 设置（`etcd-cafile`，`etcd-certfile`，`etcd-keyfile`）； - 如果未提供外部 etcd 服务器，则将使用本地 etcd（通过主机网络） - - 如果指定了云提供商，则配置相应的 `--cloud-provider`，如果该路径存在，则配置 `--cloud-config` - （这是实验性的，是 Alpha 版本，将在以后的版本中删除） +- 要绑定的 `apiserver-advertise-address` 和 `apiserver-bind-port`； + 如果未提供，则这些值默认为机器上默认网络接口的 IP 地址和 6443 端口。 +- `service-cluster-ip-range` 给 service 使用 +- 如果指定了外部 etcd 服务器，则应指定 `etcd-servers` 地址和相关的 TLS 设置 + （`etcd-cafile`，`etcd-certfile`，`etcd-keyfile`）； + 如果未提供外部 etcd 服务器，则将使用本地 etcd（通过主机网络） +- 如果指定了云提供商，则配置相应的 `--cloud-provider`，如果该路径存在，则配置 `--cloud-config` + （这是实验性的，是 Alpha 版本，将在以后的版本中删除） 无条件设置的其他 API 服务器标志有： @@ -462,6 +507,14 @@ API 服务器的静态 Pod 清单会受到用户提供的以下参数的影响: See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details - `--allow-privileged` to `true` (required e.g. by kube proxy) - `--requestheader-client-ca-file` to `front-proxy-ca.crt` +--> +- `--insecure-port=0` 禁止到 API 服务器不安全的连接 +- `--enable-bootstrap-token-auth=true` 启用 `BootstrapTokenAuthenticator` 身份验证模块。 + 更多细节请参见 [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)。 +- `--allow-privileged` 设为 `true`（诸如 kube-proxy 这些组件有此要求） +- `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt` + + +- `--enable-admission-plugins` 设为： + - [`NamespaceLifecycle`](/zh/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) + 例如，避免删除系统保留的名字空间 + - [`LimitRanger`](/zh/docs/reference/access-authn-authz/admission-controllers/#limitranger) 和 + [`ResourceQuota`](/zh/docs/reference/access-authn-authz/admission-controllers/#resourcequota) + 对名字空间实施限制 + - [`ServiceAccount`](/zh/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) + 实施服务账户自动化 + - [`PersistentVolumeLabel`](/zh/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) + 将区域（Region）或区（Zone）标签附加到由云提供商定义的 PersistentVolumes + （此准入控制器已被弃用并将在以后的版本中删除）。 + 如果未明确选择使用 `gce` 或 `aws` 作为云提供商，则默认情况下，v1.9 以后的版本 kubeadm 都不会部署。 + - [`DefaultStorageClass`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) + 在 `PersistentVolumeClaim` 对象上强制使用默认存储类型 + - [`DefaultTolerationSeconds`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds) + - [`NodeRestriction`](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction) + 限制 kubelet 可以修改的内容（例如，仅此节点上的 pod） + - - `--insecure-port=0` 禁止到 API 服务器不安全的连接 - - `--enable-bootstrap-token-auth=true` 启用 `BootstrapTokenAuthenticator` 身份验证模块 - 更多细节请参见 [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - - `--allow-privileged` 设为 `true`（必要，例如 kube-proxy） - - `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt` - - `--enable-admission-plugins` 设为： - - [`NamespaceLifecycle`](/zh/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) - 例如，避免删除系统保留的命名空间 - - [`LimitRanger`](/zh/docs/reference/access-authn-authz/admission-controllers/#limitranger) 和 - [`ResourceQuota`](/zh/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 对命名空间实施限制 - - [`ServiceAccount`](/zh/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) 实施服务账户自动化 - - [`PersistentVolumeLabel`](/zh/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) - 将区域（Region）或区（Zone）标签附加到由云提供商定义的 PersistentVolumes（此准入控制器已被弃用并将在以后的版本中删除）。 - 如果未明确选择使用 `gce` 或 `aws` 作为云提供商，则默认情况下，v1.9 以后的版本 kubeadm 都不会部署。 - - [`DefaultStorageClass`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) - 在 `PersistentVolumeClaim` 对象上强制使用默认存储类型 - - [`DefaultTolerationSeconds`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds) - - [`NodeRestriction`](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction) - 限制 kubelet 可以修改的内容（例如，仅此节点上的 pod） - - `--kubelet-preferred-address-types` 设为 `InternalIP,ExternalIP,Hostname;` - 这使得在节点的主机名无法解析的环境中，`kubectl log` 和 API 服务器与 kubelet 的其他通信可以工作 - - 使用在前面步骤中生成的证书的标志： - - `--client-ca-file` 设为 `ca.crt` - - `--tls-cert-file` 设为 `apiserver.crt` - - `--tls-private-key-file` 设为 `apiserver.key` - - `--kubelet-client-certificate` 设为 `apiserver-kubelet-client.crt` - - `--kubelet-client-key` 设为 `apiserver-kubelet-client.key` - - `--service-account-key-file` 设为 `sa.pub` - - `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt` - - `--proxy-client-cert-file` 设为 `front-proxy-client.crt` - - `--proxy-client-key-file` 设为 `front-proxy-client.key` - - 其他用于保护前端代理（[API 聚合](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)）通信的标志: - - `--requestheader-username-headers=X-Remote-User` - - `--requestheader-group-headers=X-Remote-Group` - - `--requestheader-extra-headers-prefix=X-Remote-Extra-` - - `--requestheader-allowed-names=front-proxy-client` +- `--kubelet-preferred-address-types` 设为 `InternalIP,ExternalIP,Hostname;` + 这使得在节点的主机名无法解析的环境中，`kubectl log` 和 API 服务器与 kubelet + 的其他通信可以工作 +- 使用在前面步骤中生成的证书的标志： - + - `--client-ca-file` 设为 `ca.crt` + - `--tls-cert-file` 设为 `apiserver.crt` + - `--tls-private-key-file` 设为 `apiserver.key` + - `--kubelet-client-certificate` 设为 `apiserver-kubelet-client.crt` + - `--kubelet-client-key` 设为 `apiserver-kubelet-client.key` + - `--service-account-key-file` 设为 `sa.pub` + - `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt` + - `--proxy-client-cert-file` 设为 `front-proxy-client.crt` + - `--proxy-client-key-file` 设为 `front-proxy-client.key` + +- 其他用于保护前端代理（ + [API 聚合层](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)） + 通信的标志: + + - `--requestheader-username-headers=X-Remote-User` + - `--requestheader-group-headers=X-Remote-Group` + - `--requestheader-extra-headers-prefix=X-Remote-Extra-` + - `--requestheader-allowed-names=front-proxy-client` + + #### 控制器管理器 {#controller-manager} -- 如果调用 kubeadm 时指定了 `--pod-network-cidr` 参数，则可以通过以下方式启用某些 CNI 网络插件所需的子网管理器功能： - - 设置 `--allocate-node-cidrs=true` - - 根据给定 CIDR 设置 `--cluster-cidr` 和 `--node-cidr-mask-size` 标志 - - 如果指定了云提供商，则指定相应的 `--cloud-provider`，如果存在这样的配置文件，则指定 `--cloud-config` 路径 - （这是试验性的，是Alpha 版本，将在以后的版本中删除） +- 如果调用 kubeadm 时指定了 `--pod-network-cidr` 参数，则可以通过以下方式启用 + 某些 CNI 网络插件所需的子网管理器功能： + - 设置 `--allocate-node-cidrs=true` + - 根据给定 CIDR 设置 `--cluster-cidr` 和 `--node-cidr-mask-size` 标志 +- 如果指定了云提供商，则指定相应的 `--cloud-provider`，如果存在这样的配置文件， + 则指定 `--cloud-config` 路径（此为试验性功能，是 Alpha 版本，将在以后的版本中删除）。 其他无条件设置的标志包括： @@ -564,31 +626,37 @@ The static Pod manifest for the controller-manager is affected by following para - `--cluster-signing-key-file` to `ca.key`, if External CA mode is disabled, otherwise to `""` - `--service-account-private-key-file` to `sa.key` --> -- `--controllers` 为 TLS 引导程序启用所有默认控制器以及 `BootstrapSigner` 和 `TokenCleaner` 控制器。 - 详细信息请参阅 [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - - `--use-service-account-credentials` 设为 `true` - - 使用先前步骤中生成的证书的标志： - -`--root-ca-file` 设为 `ca.crt` - - 如果禁用了 External CA 模式，则 `--cluster-signing-cert-file` 设为 `ca.crt`，否则设为 `""` - - 如果禁用了 External CA 模式，则 `--cluster-signing-key-file` 设为 `ca.key`，否则设为 `""` - - `--service-account-private-key-file` 设为 `sa.key` +- `--controllers` 为 TLS 引导程序启用所有默认控制器以及 `BootstrapSigner` 和 + `TokenCleaner` 控制器。详细信息请参阅 + [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +- `--use-service-account-credentials` 设为 `true` +- 使用先前步骤中生成的证书的标志： - -#### 调度器 {#scheduler} + -`--root-ca-file` 设为 `ca.crt` + - 如果禁用了 External CA 模式，则 `--cluster-signing-cert-file` 设为 `ca.crt`，否则设为 `""` + - 如果禁用了 External CA 模式，则 `--cluster-signing-key-file` 设为 `ca.key`，否则设为 `""` + - `--service-account-private-key-file` 设为 `sa.key` + + +#### 调度器 {#scheduler} + 调度器的静态 Pod 清单不受用户提供的参数的影响。 - + ### 为本地 etcd 生成静态 Pod 清单 {#generate-static-pod-manifest-for-local-etcd} -如果用户指定了外部 etcd，则将跳过此步骤，否则 kubeadm 会生成静态 Pod 清单文件，以创建在 Pod 中运行的具有以下属性的本地 etcd 实例： +如果用户指定了外部 etcd，则将跳过此步骤，否则 kubeadm 会生成静态 Pod 清单文件， +以创建在 Pod 中运行的具有以下属性的本地 etcd 实例： -1. etcd 镜像默认从 `k8s.gcr.io` 拉取。有关自定义镜像仓库，请参阅[使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) -2. 如果 kubeadm 以 `--dry-run` 模式执行，etcd 静态 Pod 清单将写入一个临时文件夹 -3. 可以使用 ['kubeadm init phase etcd local'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) 命令 - 单独为本地 etcd 生成静态 Pod 清单 +1. etcd 镜像默认从 `k8s.gcr.io` 拉取。有关自定义镜像仓库，请参阅 + [使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)。 +2. 如果 kubeadm 以 `--dry-run` 模式执行，etcd 静态 Pod 清单将写入一个临时文件夹。 +3. 可以使用 + ['kubeadm init phase etcd local'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) + 命令单独为本地 etcd 生成静态 Pod 清单 - + ### 可选的动态 Kubelet 配置 {#optional-dynamic-kubelet-configuration} -要使用这个功能，请调用 `kubeadm alpha kubelet config enable-dynamic`。 -它将 kubelet 的 init 配置写入 `/var/lib/kubelet/config/init/kubelet` 文件。 +要使用这个功能，请执行 `kubeadm alpha kubelet config enable-dynamic`。 +它将 kubelet 的初始化配置写入 `/var/lib/kubelet/config/init/kubelet` 文件。 -init 配置用于在这个特定节点上启动 kubelet，从而为 kubelet 插件文件提供了一种替代方法。 -如以下步骤中所述，这种配置将由 kubelet 基本配置所替代。 -请参阅[通过配置文件设置 Kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file)了解更多信息。 +初始化配置用于在这个特定节点上启动 kubelet，从而为 kubelet 插件文件提供了 +一种替代方法。如以下步骤中所述，这种配置将由 kubelet 基本配置所替代。 +请参阅[通过配置文件设置 Kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file) +了解更多信息。 请注意： @@ -642,12 +715,15 @@ init 配置用于在这个特定节点上启动 kubelet，从而为 kubelet 插 as `InitConfiguration` using the `---` separator. For more details have a look at the `kubeadm config print-default` command. --> 1. 要使动态 kubelet 配置生效，应在 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` - 中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志 -2. 通过使用配置文件 `--config some-file.yaml` 将 `KubeletConfiguration` 对象传递给 `kubeadm init` 或 `kubeadm join` - 来更改 kubelet 配置。可以使用 `---` 分隔符将 `KubeletConfiguration` 对象与其他对象（例如 `InitConfiguration`）分开。 - 有关更多详细信息，请查看 `kubeadm config print-default` 命令。 + 中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志。 +2. 通过使用配置文件 `--config some-file.yaml` 将 `KubeletConfiguration` 对象传递给 + `kubeadm init` 或 `kubeadm join` 来更改 kubelet 配置。 + 可以使用 `---` 分隔符将 `KubeletConfiguration` 对象与其他对象（例如 `InitConfiguration`） + 分开。更多的详细信息，请查看 `kubeadm config print-default` 命令。 - + ### 等待控制平面启动 {#wait-for-the-control-plane-to-come-up} kubeadm 等待（最多 4m0s），直到 `localhost:6443/healthz`（kube-apiserver 存活）返回 `ok`。 但是为了检测死锁条件，如果 `localhost:10255/healthz`（kubelet 存活）或 -`localhost:10255/healthz/syncloop`（kubelet 就绪）未能在 40s 和 60s 内未返回 `ok`，则 kubeadm 会快速失败。 +`localhost:10255/healthz/syncloop`（kubelet 就绪）未能在 40s 和 60s 内未返回 `ok`， +则 kubeadm 会快速失败。 + ### （可选）编写基本 kubelet 配置 {#write-base-kubelet-configuration} {{< feature-state for_k8s_version="v1.9" state="alpha" >}} - -如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm： + +如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm，则 kubeadm： -1. 将 kubelet 基本配置写入 `kube-system` 命名空间的 `kubelet-base-config-v1.9` ConfigMap 中。 +1. 将 kubelet 基本配置写入 `kube-system` 名字空间的 `kubelet-base-config-v1.9` ConfigMap 中。 2. 创建 RBAC 规则，以授予对所有引导令牌和所有 kubelet 实例对该 ConfigMap 的读取访问权限 （即 `system:bootstrappers:kubeadm:default-node-token` 组和 `system:nodes` 组） -3. 通过将 `Node.spec.configSource` 指向新创建的 ConfigMap，为初始控制平面节点启用动态 kubelet 配置功能。 +3. 通过将 `Node.spec.configSource` 指向新创建的 ConfigMap，为初始控制平面节点启用动态 + kubelet 配置功能。 - + ### 将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考 {#save-the-kubeadm-clusterConfiguration-in-a-configMap-for-later-reference} -kubeadm 将传递给 `kubeadm init` 的配置保存在 `kube-system` 命名空间下名为 `kubeadm-config` 的 ConfigMap 中。 +kubeadm 将传递给 `kubeadm init` 的配置保存在 `kube-system` 名字空间下名为 +`kubeadm-config` 的 ConfigMap 中。 -这将确保将来执行的 kubeadm 操作（例如 `kubeadm upgrade`）将能够确定实际/当前集群状态，并根据该数据做出新的决策。 +这将确保将来执行的 kubeadm 操作（例如 `kubeadm upgrade`）将能够确定实际/当前集群状态， +并根据该数据做出新的决策。 请注意： 1. 在保存 ClusterConfiguration 之前，从配置中删除令牌等敏感信息。 -2. 可以使用 [`kubeadm init phase upload-config`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) +2. 可以使用 + [`kubeadm init phase upload-config`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) 命令单独上传主控节点配置。 - + ### 将节点标记为控制平面 {#mark-the-node-as-control-plane} - + 一旦控制平面可用，kubeadm 将执行以下操作： -- 给节点打上 `node-role.kubernetes.io/master=""` 标签，标记为控制平面 +- 给节点打上 `node-role.kubernetes.io/master=""` 标签，标记其为控制平面 - 给节点打上 `node-role.kubernetes.io/master:NoSchedule` 污点 请注意： -1. 可以使用 [`kubeadm init phase mark-control-plane`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-master) +1. 可以使用 [`kubeadm init phase mark-control-plane`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) 命令单独触发控制平面标记 -c + ### 为即将加入的节点加入 TLS 启动引导 {#configure-tls-bootstrapping-for-node-joining} -Kubeadm 使用[引导令牌认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)将新节点连接到现有集群； -有关更多详细信息，请参见[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md)。 +Kubeadm 使用[引导令牌认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +将新节点连接到现有集群； +更多的详细信息，请参见 +[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md)。 -`kubeadm init` 确保为该过程正确配置了所有内容，这包括以下步骤以及设置 API 服务器和控制器标志，如前几段所述。 +`kubeadm init` 确保为该过程正确配置了所有内容，这包括以下步骤以及设置 API 服务器 +和控制器标志，如前几段所述。 请注意： @@ -756,20 +852,28 @@ setting API server and controller flags as already described in previous paragra 1. TLS bootstrapping for nodes can be configured with the [`kubeadm init phase bootstrap-token`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) command, executing all the configuration steps described in following paragraphs; alternatively, each step can be invoked individually --> -1. 可以使用 [`kubeadm init phase bootstrap-token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) - 命令配置节点的 TLS 引导，执行以下段落中描述的所有配置步骤；或者每个步骤都单独触发。 +1. 可以使用 + [`kubeadm init phase bootstrap-token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) + 命令配置节点的 TLS 引导，执行以下段落中描述的所有配置步骤； + 或者每个步骤都单独触发。 - + #### 创建引导令牌 {#create-a-bootstrap-token} -`kubeadm init` 创建第一个引导令牌，该令牌是自动生成的或由用户提供的 `--token` 标志的值；如引导令牌规范中记录的那样， -令牌应保存在 `kube-system` 命名空间下名为 `bootstrap-token-` 的 secret 中。 +`kubeadm init` 创建第一个引导令牌，该令牌是自动生成的或由用户提供的 `--token` +标志的值；如引导令牌规范中记录的那样， +令牌应保存在 `kube-system` 名字空间下名为 `bootstrap-token-<令牌-id>` +的 Secret 中。 - + 请注意： 1. 由 `kubeadm init` 创建的默认令牌将用于在 TLS 引导过程中验证临时用户； - 这些用户会成为 `system:bootstrappers:kubeadm:default-node-token` 组的成员 + 这些用户会成为 `system:bootstrappers:kubeadm:default-node-token` 组的成员。 2. 令牌的有效期有限，默认为 24 小时（间隔可以通过 `-token-ttl` 标志进行更改） -3. 可以使用 [`kubeadm token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 命令创建其他令牌， - 这些令牌还提供其他有用的令牌管理功能 +3. 可以使用 [`kubeadm token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) + 命令创建其他令牌，这些令牌还提供其他有用的令牌管理功能 - + #### 允许加入的节点调用 CSR API {#allow-joining-nodes-to-call-csr-api} - -Kubeadm 确保 `system:bootstrappers:kubeadm:default-node-token` 组中的用户能够访问证书签名 API。 + +Kubeadm 确保 `system:bootstrappers:kubeadm:default-node-token` 组中的用户 +能够访问证书签名 API。 -这是通过在上述组与默认 RBAC 角色 `system:node-bootstrapper` 之间创建名为 `kubeadm:kubelet-bootstrap` 的 ClusterRoleBinding 来实现的。 +这是通过在上述组与默认 RBAC 角色 `system:node-bootstrapper` 之间创建名为 +`kubeadm:kubelet-bootstrap` 的 ClusterRoleBinding 来实现的。 - - + #### 为新的引导令牌设置自动批准 {#setup-auto-approval-for-new-bootstrap-tokens} - + Kubeadm 确保 csrapprover 控制器自动批准引导令牌的 CSR 请求。 -这是通过在 `system:bootstrappers:kubeadm:default-node-token` 组和 `system:certificates.k8s.io:certificatesigningrequests:nodeclient` 默认角色之间 +这是通过在 `system:bootstrappers:kubeadm:default-node-token` 用户组和 +`system:certificates.k8s.io:certificatesigningrequests:nodeclient` 默认角色之间 创建名为 `kubeadm:node-autoapprove-bootstrap` 的 ClusterRoleBinding 来实现的。 还应创建 `system:certificates.k8s.io:certificatesigningrequests:nodeclient` 角色， -对 `/apis/certificates.k8s.io/certificatesigningrequests/nodeclient` 授予的 POST 权限。 +授予对 `/apis/certificates.k8s.io/certificatesigningrequests/nodeclient` +执行 POST 的权限。 - + #### 通过自动批准设置节点证书轮换 {#setup-nodes-certificate-rotation-with-auto-approval} -Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准节点的新证书的 CSR 请求。 +Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准节点的 +新证书的 CSR 请求。 -这是通过在 `system:nodes` 组和 `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient` 默认角色之间创建名叫 -`kubeadm:node-autoapprove-certificate-rotation` 的 ClusterRoleBinding 实现的。 +这是通过在 `system:nodes` 组和 +`system:certificates.k8s.io:certificatesigningrequests:selfnodeclient` +默认角色之间创建名为 `kubeadm:node-autoapprove-certificate-rotation` 的 +ClusterRoleBinding 来实现的。 - + #### 创建公共 cluster-info ConfigMap - -本步骤在 `kube-public` 命名空间中创建名为 `cluster-info` 的 ConfigMap。 + +本步骤在 `kube-public` 名字空间中创建名为 `cluster-info` 的 ConfigMap。 -另外，它创建一个 Role 和一个 RoleBinding，为未经身份验证的用户授予对 ConfigMap 的访问权限 -（即 RBAC 组 `system:unauthenticated` 中的用户）。 +另外，它创建一个 Role 和一个 RoleBinding，为未经身份验证的用户授予对 ConfigMap +的访问权限（即 RBAC 组 `system:unauthenticated` 中的用户）。 - + 请注意： -1. 对 `cluster-info` ConfigMap 的访问 _不受_ 速率限制。如果你把主控节点暴露到外网，这可能是一个问题，也可能不是； -这里最坏的情况是 DoS 攻击，攻击者使用 kube-apiserver 能够处理的所有动态请求来为 `cluster-info` ConfigMap 提供服务。 +1. 对 `cluster-info` ConfigMap 的访问 _不受_ 速率限制。 + 如果你把 API 服务器暴露到外网，这可能是一个问题，也可能不是； + 这里最坏的情况是 DoS 攻击，攻击者使用 kube-apiserver 能够处理的所有动态请求 + 来为 `cluster-info` ConfigMap 提供服务。 - + ### 安装插件 {##install-addons} - + Kubeadm 通过 API 服务器安装内部 DNS 服务器和 kube-proxy 插件。 - + 请注意： +1. 此步骤可以调用 + ['kubeadm init phase addon all'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) + 命令单独执行。 -1. 此步骤可以调用 ['kubeadm init phase addon all'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) 命令单独调用。 + -#### 代理 {#proxy} - - -在 `kube-system` 命名空间中创建一个用于 `kube-proxy` 的 ServiceAccount；然后以 DaemonSet 的方式部署 kube-proxy： +#### 代理 {#proxy} + +在 `kube-system` 名字空间中创建一个用于 `kube-proxy` 的 ServiceAccount； +然后以 DaemonSet 的方式部署 kube-proxy： - 主控节点凭据（`ca.crt` 和 `token`）来自 ServiceAccount -- 主控节点的位置来自 ConfigMap -- `kube-proxy` 的 ServiceAccount 绑定了 `system:node-proxier` ClusterRole 中的特权 +- API 服务器节点的位置（URL）来自 ConfigMap +- `kube-proxy` 的 ServiceAccount 绑定了 `system:node-proxier` ClusterRole + 中的特权 #### DNS {#dns} @@ -900,13 +1038,18 @@ the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubea - A ServiceAccount for CoreDNS/kube-dns is created in the `kube-system` namespace. - The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole --> -- 在 Kubernetes 1.18 版本中，通过 kubeadm 部署 kube-dns 这一操作已经弃用，将在未来的版本中删除 -- CoreDNS 服务的名称为 `kube-dns`。这样做是为了防止当用户将集群 DNS 从 kube-dns 切换到 CoreDNS 或者反过来时，出现服务中断。 - `--config` 方法在[这里](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)有描述 -- 在 `kube-system` 命名空间中创建 CoreDNS/kube-dns 的 ServiceAccount +- 在 Kubernetes 1.18 版本中，通过 kubeadm 部署 kube-dns 这一操作已经弃用， + 将在未来的版本中删除。 +- CoreDNS 服务的名称为 `kube-dns`。这样做是为了防止当用户将集群 DNS 从 kube-dns + 切换到 CoreDNS 或者反过来时，出现服务中断。`--config` 方法在 + [这里](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) + 有描述。 +- 在 `kube-system` 名字空间中创建 CoreDNS/kube-dns 的 ServiceAccount - `kube-dns` 的 ServiceAccount 绑定了 `system:kube-dns` ClusterRole 中的特权 - + ## kubeadm join 步骤内部设计 {#kubeadm-join-phases-internal-design} -这分为发现（让该节点信任 Kubernetes 的主控节点）和 TLS 引导（让 Kubernetes 的主控节点信任该节点）。 +这分为发现（让该节点信任 Kubernetes 的主控节点）和 TLS 引导 +（让 Kubernetes 的主控节点信任该节点）。 + ### 预检 {#preflight-checks} 1. `kubeadm join` 预检基本上是 `kubeadm init` 预检的一个子集 -2. 从 1.9 开始，kubeadm 为 CRI 通用的功能提供了更好的支持；在这种情况下，docker 特定的控制参数将跳过或替换为 crictl 中与之相似的控制参数。 -3. 从 1.9 开始，kubeadm 支持加入在 Windows 上运行的节点；在这种情况下，将跳过 linux 特定的控制参数。 -4. 在任何情况下，用户都可以通过 `--ignore-preflight-errors` 选项跳过特定的预检（或者进而跳过所有预检）。 +2. 从 1.9 开始，kubeadm 为 CRI 通用的功能提供了更好的支持；在这种情况下， + Docker 特定的控制参数将跳过或替换为 crictl 中与之相似的控制参数。 +3. 从 1.9 开始，kubeadm 支持加入在 Windows 上运行的节点；在这种情况下， + 将跳过 Linux 特定的控制参数。 +4. 在任何情况下，用户都可以通过 `--ignore-preflight-errors` 选项跳过 + 特定的预检（或者进而跳过所有预检）。 - + ### 发现 cluster-info {#discovery-cluster-info} + #### 共享令牌发现 {#shared-token-discovery} 如果带 `--discovery-token` 参数调用 `kubeadm join`，则使用了令牌发现功能； -在这种情况下，节点基本上从 `kube-public` 命名空间中的 `cluster-info` ConfigMap 中检索集群 CA 证书。 +在这种情况下，节点基本上从 `kube-public` 名字空间中的 `cluster-info` ConfigMap +中检索集群 CA 证书。 为了防止“中间人”攻击，采取了以下步骤： @@ -981,7 +1135,8 @@ the cluster CA certificates from the `cluster-info` ConfigMap in the `kube-publ The `--discovery-token-ca-cert-hash flag` may be repeated multiple times to allow more than one public key. - As a additional validation, the CA certificate is retrieved via secure connection and then compared with the CA retrieved initially --> -- 首先，通过不安全连接检索 CA 证书（这是可能的，因为 `kubeadm init` 授予 `system:unauthenticated` 的用户对 `cluster-info` 访问权限） +- 首先，通过不安全连接检索 CA 证书（这是可能的，因为 `kubeadm init` 授予 + `system:unauthenticated` 的用户对 `cluster-info` 访问权限） - 然后 CA 证书通过以下验证步骤： - 基本验证：使用令牌 ID 而不是 JWT 签名 - 公钥验证：使用提供的 `--discovery-token-ca-cert-hash`。这个值来自 `kubeadm init` 的输出， @@ -999,44 +1154,54 @@ the cluster CA certificates from the `cluster-info` ConfigMap in the `kube-publ 1. 通过 `--discovery-token-unsafe-skip-ca-verification` 标志可以跳过公钥验证； 这削弱了 kubeadm 安全模型，因为其他人可能冒充 Kubernetes 主控节点。 - + #### 文件/HTTPS 发现 {#file-or-https-discovery} 如果带 `--discovery-file` 参数调用 `kubeadm join`，则使用文件发现功能； -该文件可以是本地文件或通过 HTTPS URL 下载；对于 HTTPS，主机安装的 CA 包用于验证连接。 +该文件可以是本地文件或通过 HTTPS URL 下载；对于 HTTPS，主机安装的 CA 包 +用于验证连接。 -通过文件发现，集群 CA 证书是文件本身提供；事实上，这个发现文件是一个 kubeconfig 文件，只设置了 `server` 和 `certificate-authority-data` 属性， -如 [`kubeadm join`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#file-or-https-based-discovery) 参考文档中所述; -当与集群建立连接时，kubeadm 尝试访问 `cluster-info` ConfigMap，如果可用，就使用它。 +通过文件发现，集群 CA 证书是文件本身提供；事实上，这个发现文件是一个 kubeconfig 文件， +只设置了 `server` 和 `certificate-authority-data` 属性， +如 [`kubeadm join`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#file-or-https-based-discovery) +参考文档中所述，当与集群建立连接时，kubeadm 尝试访问 `cluster-info` ConfigMap， +如果可用，就使用它。 - + ## TLS 引导 {#tls-boostrap} -知道集群信息后，将写入文件 `bootstrap-kubelet.conf`，从而允许 kubelet 执行 TLS 引导（相反，在 v1.7 之前 TLS 引导都是由 kubeadm 管理）。 +知道集群信息后，将写入文件 `bootstrap-kubelet.conf`，从而允许 kubelet 执行 +TLS 引导（相反，在 v1.7 之前 TLS 引导都是由 kubeadm 管理）。 -TLS 引导机制使用共享令牌对 Kubernetes 主控节点进行临时身份验证，以便为本地创建的密钥对提交证书签名请求（CSR）。 +TLS 引导机制使用共享令牌对 Kubernetes 主控节点进行临时身份验证，以便 +为本地创建的密钥对提交证书签名请求（CSR）。 -该请求会被自动批准，并且该操作保存 `ca.crt` 文件和 `kubelet.conf` 文件，用于 kubelet 加入集群，同时删除 `bootstrap-kubelet.conf`。 +该请求会被自动批准，并且该操作保存 `ca.crt` 文件和 `kubelet.conf` 文件，用于 +kubelet 加入集群，同时删除 `bootstrap-kubelet.conf`。 请注意： @@ -1048,18 +1213,23 @@ by kubelet for joining the cluster, while`bootstrap-kubelet.conf` is deleted. access to CSR api during the `kubeadm init` process - The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process --> -- 临时身份验证根据 `kubeadm init` 过程中保存的令牌进行验证（或者使用 `kubeadm token` 创建的其他令牌） +- 临时身份验证根据 `kubeadm init` 过程中保存的令牌进行验证（或者使用 `kubeadm token` + 创建的其他令牌） - 临时身份验证解析到 `system:bootstrappers:kubeadm:default-node-token` 组的一个用户成员， 该成员在 `kubeadm init` 过程中被授予对 CSR API 的访问权 - 根据 `kubeadm init` 过程的配置，自动 CSR 审批由 csrapprover 控制器管理 - + ### （可选）编写 init kubelet 配置 {#write-init-kubelet-configuration} {{< feature-state for_k8s_version="v1.9" state="alpha" >}} - -如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm： + +如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm，则 kubeadm： -1. 使用引导令牌凭证从 `kube-system` 命名空间中 `kubelet-base-config-v1.9` ConfigMap 中读取 kubelet 基本配置， +1. 使用引导令牌凭证从 `kube-system` 名字空间中 ConfigMap `kubelet-base-config-v1.9` + 中读取 kubelet 基本配置， 并将其作为 kubelet init 配置文件 `/var/lib/kubelet/config/init/kubelet` 写入磁盘。 2. 一旦 kubelet 开始使用节点自己的凭据（`/etc/kubernetes/kubelet.conf`）， 就更新当前节点配置，指定该节点或 kubelet 配置来自上述 ConfigMap。 @@ -1078,4 +1249,6 @@ by kubelet for joining the cluster, while`bootstrap-kubelet.conf` is deleted. -1. 要使动态 kubelet 配置生效，应在 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志。 +1. 要使动态 kubelet 配置生效，应在 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` + 中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志。 + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md index 1d8dcad951..82d4f88024 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md @@ -4,11 +4,6 @@ content_type: concept weight: 90 --- -`kubeadm alpha` 提供了一组可用于收集社区反馈的功能的预览。 -请尝试一下这些功能并给我们反馈！ +`kubeadm alpha` 提供了一组可用于收集社区反馈的预览性质功能。 +请试用这些功能并给我们提供反馈！ {{< /caution >}} -## kubeadm alpha certs {#cmd-certs} - - -Kubernetes 证书的操作集合。 - -{{< tabs name="tab-certs" >}} -{{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} -{{< /tabs >}} - -## kubeadm alpha certs renew {#cmd-certs-renew} - - -使用 `all` 子命令来更新所有 Kubernetes 证书或有选择性地更新它们。 -有关证书到期和续订的更多详细信息， -请参见[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 - -{{< tabs name="tab-certs-renew" >}} -{{< tab name="renew" include="generated/kubeadm_alpha_certs_renew.md" />}} -{{< tab name="all" include="generated/kubeadm_alpha_certs_renew_all.md" />}} -{{< tab name="admin.conf" include="generated/kubeadm_alpha_certs_renew_admin.conf.md" />}} -{{< tab name="apiserver-etcd-client" include="generated/kubeadm_alpha_certs_renew_apiserver-etcd-client.md" />}} -{{< tab name="apiserver-kubelet-client" include="generated/kubeadm_alpha_certs_renew_apiserver-kubelet-client.md" />}} -{{< tab name="apiserver" include="generated/kubeadm_alpha_certs_renew_apiserver.md" />}} -{{< tab name="controller-manager.conf" include="generated/kubeadm_alpha_certs_renew_controller-manager.conf.md" />}} -{{< tab name="etcd-healthcheck-client" include="generated/kubeadm_alpha_certs_renew_etcd-healthcheck-client.md" />}} -{{< tab name="etcd-peer" include="generated/kubeadm_alpha_certs_renew_etcd-peer.md" />}} -{{< tab name="etcd-server" include="generated/kubeadm_alpha_certs_renew_etcd-server.md" />}} -{{< tab name="front-proxy-client" include="generated/kubeadm_alpha_certs_renew_front-proxy-client.md" />}} -{{< tab name="scheduler.conf" include="generated/kubeadm_alpha_certs_renew_scheduler.conf.md" />}} -{{< /tabs >}} - -## kubeadm alpha certs certificate-key {#cmd-certs-certificate-key} - - -该命令可用于生成新的控制平面证书密钥。 -密钥可以作为 `--certificate-key` 参数传递给 `kubeadm init` 和 `kubeadm join` 操作， -以在加入其他控制平面节点时启用证书的自动复制。 - -{{< tabs name="tab-certs-certificate-key" >}} -{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} -{{< /tabs >}} - -## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} - - -该命令可用于生成证书签名请求（CSR），CSR 可以将其提交给证书颁发机构（CA）进行签名。 - -{{< tabs name="tab-certs-generate-csr" >}} -{{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} -{{< /tabs >}} - -## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} - - -此命令检查 kubeadm 管理的本地 PKI 中证书的到期时间。 -有关证书到期和续订的更多详细信息，请参见 -[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 - -{{< tabs name="tab-certs-check-expiration" >}} -{{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}} -{{< /tabs >}} - ## kubeadm alpha kubeconfig user {#cmd-phase-kubeconfig} - {{< tabs name="selfhosting" >}} {{< tab name="selfhosting" include="generated/kubeadm_alpha_selfhosting.md" />}} {{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}} @@ -149,6 +67,13 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> -* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 -* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 -* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 会还原 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改。 +* 用来启动引导 Kubernetes 控制平面节点的 + [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) + 命令 +* 用来将节点连接到集群的 + [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) + 命令 +* 用来还原 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改的 + [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) + 命令 + diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 9d0e64bec5..f7e4bb9bf1 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -6,7 +6,6 @@ weight: 20 此命令初始化一个 Kubernetes 控制平面节点。 - {{< include "generated/kubeadm_init.md" >}} @@ -44,7 +42,7 @@ following steps: --> 1. 在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告， 其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了 - `--ignore-preflight-errors=` 参数。 + `--ignore-preflight-errors=<错误列表>` 参数。 6. 生成令牌，将来其他节点可使用该令牌向控制平面注册自己。 - 如文档 [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 所述， + 如 [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 文档所述， 用户可以选择通过 `--token` 提供令牌。 ### 在 kubeadm 中使用 init phases {#init-phases} - Kubeadm 允许你使用 `kubeadm init phase` 命令分阶段创建控制平面节点。 -可以使用 [kubeadm config print](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)命令打印出默认配置。 +可以使用 [kubeadm config print](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/) +命令打印出默认配置。 如果你的配置没有使用最新版本， **推荐**使用 [kubeadm config migrate](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/) 命令进行迁移。 有关配置的字段和用法的更多信息， -你可以导航到我们的 API 参考页面并从 -[列表](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories)中选择一个版本。 +你可以访问 API 参考页面并从 +[列表](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories) +中选择一个版本。 @@ -379,7 +378,8 @@ For detailed information on certificate management with kubeadm see The document includes information about using external CA, custom certificates and certificate renewal. --> -有关使用 kubeadm 进行证书管理的详细信息，请参阅[使用 kubeadm 进行证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 +有关使用 kubeadm 进行证书管理的详细信息，请参阅 +[使用 kubeadm 进行证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 该文档包括有关使用外部 CA，自定义证书和证书更新的信息。 -kubeadm 需要的所有镜像，例如 `k8s.gcr.io/kube-*`、`k8s.gcr.io/etcd` 和 `k8s.gcr.io/pause` 都支持多种架构。 +kubeadm 需要的所有镜像，例如 `k8s.gcr.io/kube-*`、`k8s.gcr.io/etcd` 和 `k8s.gcr.io/pause` +都支持多种架构。 -不必像文档[kubeadm 基础教程](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)所述， -将从 `kubeadm init` 取得的令牌复制到每个节点，你可以并行地分发令牌以实现简单自动化。要实现自动化， -你必须知道控制平面节点启动后将拥有的 IP 地址，或使用 DNS 名称或负载均衡器的地址。 +除了像文档 [kubeadm 基础教程](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) +中所描述的那样，将从 `kubeadm init` 取得的令牌复制到每个节点， +你还可以并行地分发令牌以实现简单自动化。 +要实现自动化，你必须知道控制平面节点启动后将拥有的 IP 地址，或使用 DNS 名称或负载均衡器的地址。 +kubeadm can generate a token for you: +--> 1. 生成一个令牌。这个令牌必须具有以下格式：`< 6 个字符的字符串>.< 16 个字符的字符串>`。 更加正式的说法是，它必须符合以下正则表达式：`[a-z0-9]{6}\.[a-z0-9]{16}`。 @@ -494,7 +497,7 @@ As they come up they should find each other and form the cluster. The same `-tok 3. 当加入其他控制平面节点时，可以对 `--certificate-key` 执行类似的操作。可以使用以下方式生成密钥： ```shell - kubeadm alpha certs certificate-key + kubeadm certs certificate-key ``` 注意这种搭建集群的方式在安全保证上会有一些宽松，因为这种方式不允许使用 `--discovery-token-ca-cert-hash` 来验证根 CA 的哈希值（因为当配置节点的时候，它还没有被生成）。 -更多信息请参阅[kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档。 +更多信息请参阅 [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档。 ## {{% heading "whatsnext" %}} @@ -523,8 +526,11 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> -* 进一步阅读了解[kubeadm init phase](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) -* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)启动一个 Kubernetes 工作节点并且将其加入到集群 -* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/)将 Kubernetes 集群升级到新版本 -* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)使用 `kubeadm init` 或 `kubeadm join` 来恢复对节点的变更 +* 进一步阅读了解 [kubeadm init phase](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) + 启动一个 Kubernetes 工作节点并且将其加入到集群 +* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) + 将 Kubernetes 集群升级到新版本 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) + 恢复 `kubeadm init` 或 `kubeadm join` 命令对节点所作的变更 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md index b2afa2124b..7290cc11df 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-version.md @@ -1,21 +1,23 @@ --- -reviewers: -- mikedanese -- luxas -- jbeda title: kubeadm version content_type: concept weight: 80 --- + + - -此命令用来查询 kubeadm 的版本。 - - +此命令用来输出 kubeadm 的版本。 {{< include "generated/kubeadm_version.md" >}}