实施细节

kubeadm init 和 kubeadm join 一起为从头创建裸 Kubernetes 集群提供了一个良好的用户体验，这符合最佳实践。然而，可能不清楚 kubeadm 是如何做到的。

本文档提供了关于底层发生情况的更多细节，目的是分享关于 Kubernetes 集群最佳实践的知识。

核心设计原则

kubeadm init 和 kubeadm join 设置的集群应是

• 安全：它应采用最新的最佳实践，例如
  • 强制执行 RBAC
  • 使用节点授权器
  • 在控制平面组件之间使用安全通信
  • 在 API 服务器和 kubelet 之间使用安全通信
  • 锁定 kubelet API
  • 锁定对 kube-proxy 和 CoreDNS 等系统组件的 API 访问
  • 锁定引导令牌可以访问的内容
• 用户友好：用户不应运行超过几个命令
  • kubeadm init
  • export KUBECONFIG=/etc/kubernetes/admin.conf
  • kubectl apply -f <network-plugin-of-choice.yaml>
  • kubeadm join --token <token> <endpoint>:<port>
• 可扩展:
  • 它不应偏袒任何特定的网络提供商。配置集群网络超出范围
  • 它应提供使用配置文件自定义各种参数的可能性

常量和众所周知的值和路径

为了降低复杂性并简化构建在 kubeadm 之上的更高级工具的开发，它对众所周知的路径和文件名使用有限的一组常量值。

Kubernetes 目录 /etc/kubernetes 是应用程序中的常量，因为它在大多数情况下显然是给定的路径，也是最直观的位置；其他常量路径和文件名是

• /etc/kubernetes/manifests 作为 kubelet 应该查找静态 Pod 清单的路径。静态 Pod 清单的名称是

  • 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 本身
  • super-admin.conf 用于可以绕过 RBAC 的集群超级管理员

• 证书和密钥文件的名称

  • ca.crt, ca.key 用于 Kubernetes 证书颁发机构
  • apiserver.crt, apiserver.key 用于 API 服务器证书
  • apiserver-kubelet-client.crt, apiserver-kubelet-client.key 用于 API 服务器安全连接 kubelet 的客户端证书
  • sa.pub, sa.key 用于 controller manager 在签署 ServiceAccount 时使用的密钥
  • front-proxy-ca.crt, front-proxy-ca.key 用于前置代理证书颁发机构
  • front-proxy-client.crt, front-proxy-client.key 用于前置代理客户端

kubeadm 配置文件格式

大多数 kubeadm 命令支持 --config 标志，允许从磁盘传递配置文件。配置文件格式遵循常见的 Kubernetes API apiVersion / kind 方案，但被视为组件配置格式。一些 Kubernetes 组件（例如 kubelet）也支持基于文件的配置。

不同的 kubeadm 子命令需要不同 kind 的配置文件。例如，InitConfiguration 用于 kubeadm init，JoinConfiguration 用于 kubeadm join，UpgradeConfiguration 用于 kubeadm upgrade，以及 ResetConfiguration 用于 kubeadm reset。

命令 kubeadm config migrate 可以用于将旧格式的配置文件迁移到较新（当前）的配置格式。kubeadm 工具仅支持将已弃用的配置格式迁移到当前格式。

有关更多详细信息，请参阅kubeadm 配置参考页面。

kubeadm init 工作流程内部设计

kubeadm init 由一系列要执行的原子工作任务组成，如 kubeadm init 内部工作流程中所述。

kubeadm init phase 命令允许用户单独调用每个任务，并最终提供可重用和可组合的 API/工具箱，供其他 Kubernetes 引导工具、任何 IT 自动化工具或高级用户用于创建自定义集群。

预检

Kubeadm 在启动初始化之前执行一组预检，目的是验证前提条件并避免常见的集群启动问题。用户可以使用 --ignore-preflight-errors 选项跳过特定的预检或所有预检。

• [警告] 如果要使用的 Kubernetes 版本（使用 --kubernetes-version 标志指定）比 kubeadm CLI 版本至少高一个次要版本。
• Kubernetes 系统要求
  • 如果在 Linux 上运行
    • [错误] 如果内核版本低于最低要求版本
    • [错误] 如果所需的 cgroups 子系统未设置
• [错误] 如果 CRI 端点没有响应
• [错误] 如果用户不是 root 用户
• [错误] 如果机器主机名不是有效的 DNS 子域
• [警告] 如果无法通过网络查找访问主机名
• [错误] 如果 kubelet 版本低于 kubeadm 支持的最低 kubelet 版本（当前次要版本 -1）
• [错误] 如果 kubelet 版本比所需的控制平面版本至少高一个次要版本（不支持的版本偏差）
• [警告] 如果 kubelet 服务不存在或被禁用
• [警告] 如果 firewalld 处于活动状态
• [错误] 如果 API 服务器 bindPort 或端口 10250/10251/10252 被使用
• [错误] 如果 /etc/kubernetes/manifest 文件夹已存在且不为空
• [错误] 如果启用了交换分区
• [错误] 如果命令路径中不存在 ip、iptables、mount、nsenter 命令
• [警告] 如果命令路径中不存在 ethtool、tc、touch 命令
• [警告] 如果 API 服务器、控制器管理器、调度器的额外参数标志包含一些无效选项
• [警告] 如果连接到 https://API.AdvertiseAddress:API.BindPort 通过代理
• [警告] 如果连接到服务子网通过代理（仅检查第一个地址）
• [警告] 如果连接到 Pods 子网通过代理（仅检查第一个地址）
• 如果提供了外部 etcd
  • [错误] 如果 etcd 版本低于最低要求版本
  • [错误] 如果指定了 etcd 证书或密钥，但未提供
• 如果未提供外部 etcd（因此将安装本地 etcd）
  • [错误] 如果端口 2379 被使用
  • [错误] 如果 Etcd.DataDir 文件夹已存在且不为空
• 如果授权模式为 ABAC
  • [错误] 如果 abac_policy.json 不存在
• 如果授权模式为 WebHook
  • [错误] 如果 webhook_authz.conf 不存在

生成必要的证书

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.crt 文件及其私钥 apiserver-kubelet-client.key 中。此证书应位于 system:masters 组织中

• 用于签署 ServiceAccount 令牌的私钥，与公钥 sa.pub 一起保存到 sa.key 文件中

• 用于前端代理的证书颁发机构，保存到 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 将使用这些文件来签署其余证书。另请参阅 使用自定义证书
2. 对于 CA，可以提供 ca.crt 文件，但不提供 ca.key 文件。如果所有其他证书和 kubeconfig 文件都已经到位，kubeadm 会识别此条件并激活 ExternalCA，这也意味着控制器管理器中的 csrsigner 控制器不会启动
3. 如果 kubeadm 在外部 CA 模式下运行；则所有证书必须由用户提供，因为 kubeadm 无法自行生成它们
4. 如果 kubeadm 在 --dry-run 模式下执行，则证书文件将写入临时文件夹
5. 可以使用 kubeadm init phase certs all 命令单独调用证书生成

为控制平面组件生成 kubeconfig 文件

Kubeadm 生成具有控制平面组件身份的 kubeconfig 文件

• kubelet 在 TLS 引导期间使用的 kubeconfig 文件 - /etc/kubernetes/bootstrap-kubelet.conf。在此文件中，有一个引导令牌或嵌入式客户端证书，用于向集群验证此节点的身份。

  此客户端证书应

  • 位于 节点授权模块要求的 system:nodes 组织中
  • 具有通用名称 (CN) system:node:<hostname-lowercased>

• 控制器管理器的 kubeconfig 文件，/etc/kubernetes/controller-manager.conf；此文件中嵌入了一个具有控制器管理器身份的客户端证书。根据默认的 RBAC 核心组件角色定义，此客户端证书应具有 CN system:kube-controller-manager

• 调度器的 kubeconfig 文件，/etc/kubernetes/scheduler.conf；此文件中嵌入了一个具有调度器身份的客户端证书。根据默认的 RBAC 核心组件角色定义，此客户端证书应具有 CN system:kube-scheduler

此外，还会生成一个作为管理实体的 kubeadm 的 kubeconfig 文件，并存储在 /etc/kubernetes/admin.conf 中。此文件包含一个证书，其中 Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin。kubeadm:cluster-admins 是一个由 kubeadm 管理的组。通过使用不需要 RBAC 的 super-admin.conf 文件，在 kubeadm init 期间，它被绑定到 cluster-admin ClusterRole。此 admin.conf 文件必须保留在控制平面节点上，并且不应与其他用户共享。

在 kubeadm init 期间，还会生成另一个 kubeconfig 文件并存储在 /etc/kubernetes/super-admin.conf 中。此文件包含一个证书，其中 Subject: O = system:masters, CN = kubernetes-super-admin。system:masters 是一个绕过 RBAC 的超级用户组，这使得 super-admin.conf 在由于 RBAC 错误配置导致集群被锁定时很有用。super-admin.conf 文件必须存储在安全的位置，并且不应与其他用户共享。

有关 RBAC 和内置 ClusterRole 和组的其他信息，请参阅 RBAC 用户角色绑定。

您可以运行 kubeadm kubeconfig user 为其他用户生成 kubeconfig 文件。

另请注意

1. ca.crt 证书嵌入在所有 kubeconfig 文件中。
2. 如果给定的 kubeconfig 文件存在，并且其内容被评估为符合上述规范，则将使用现有文件，并且将跳过给定 kubeconfig 的生成阶段
3. 如果 kubeadm 在 ExternalCA 模式下运行，则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 无法自行生成任何 kubeconfig
4. 如果 kubeadm 在 --dry-run 模式下执行，则 kubeconfig 文件将写入临时文件夹
5. 可以使用 kubeadm init phase kubeconfig all 命令单独调用 kubeconfig 文件的生成

为控制平面组件生成静态 Pod 清单

Kubeadm 将控制平面组件的静态 Pod 清单文件写入 /etc/kubernetes/manifests。kubelet 监视此目录以在启动时创建 Pod。

静态 Pod 清单共享一组通用属性

• 所有静态 Pod 都部署在 kube-system 命名空间中

• 所有静态 Pod 都获得 tier:control-plane 和 component:{component-name} 标签

• 所有静态 Pod 都使用 system-node-critical 优先级类

• 在所有静态 Pod 上设置 hostNetwork: true，以允许在配置网络之前启动控制平面；因此

  • 控制器管理器和调度器用于引用 API 服务器的 address 是 127.0.0.1
  • 如果本地设置了 etcd 服务器，则 etcd-server 地址将设置为 127.0.0.1:2379

• 控制器管理器和调度器都启用了领导者选举

• 控制器管理器和调度器将使用各自唯一的身份引用 kubeconfig 文件

• 所有静态 Pod 都获得您指定的任何额外标志或补丁，如 将自定义参数传递给控制平面组件 中所述

• 所有静态 Pod 都获得用户指定的任何额外卷（主机路径）

请注意

1. 默认情况下，所有映像都将从 registry.k8s.io 中拉取。有关自定义映像存储库的信息，请参阅 使用自定义映像
2. 如果 kubeadm 在 --dry-run 模式下执行，则静态 Pod 文件将写入临时文件夹
3. 可以使用 kubeadm init phase control-plane all 命令单独调用控制平面组件的静态 Pod 清单生成

API 服务器

API 服务器的静态 Pod 清单受用户提供的以下参数影响

• 要绑定的 apiserver-advertise-address 和 apiserver-bind-port；如果未提供，则这些值默认为计算机上默认网络接口的 IP 地址和端口 6443
• 用于服务的 service-cluster-ip-range
• 如果指定了外部 etcd 服务器，则为 etcd-servers 地址和相关的 TLS 设置（etcd-cafile、etcd-certfile、etcd-keyfile）；如果未提供外部 etcd 服务器，则将使用本地 etcd（通过主机网络）
• 如果指定了云提供商，则配置相应的 --cloud-provider 参数以及 --cloud-config 路径（如果存在此类文件）（这是实验性的，alpha 版本，将在未来的版本中删除）

无条件设置的其他 API 服务器标志是

• --insecure-port=0 以避免与 api 服务器的不安全连接

• --enable-bootstrap-token-auth=true 以启用 BootstrapTokenAuthenticator 身份验证模块。有关更多详细信息，请参阅 TLS 引导

• --allow-privileged 为 true（例如，kube 代理需要）

• --requestheader-client-ca-file 为 front-proxy-ca.crt

• --enable-admission-plugins 为

  • NamespaceLifecycle，例如，避免删除系统保留的命名空间
  • LimitRanger 和 ResourceQuota，以强制执行命名空间上的限制
  • ServiceAccount，以强制执行服务帐户自动化
  • PersistentVolumeLabel 将区域或区域标签附加到云提供商定义的 PersistentVolumes（此准入控制器已弃用，将在未来的版本中删除。当不明确选择使用 gce 或 aws 作为云提供商时，默认情况下 kubeadm 从 v1.9 开始不会部署此准入控制器）
  • DefaultStorageClass，以在 PersistentVolumeClaim 对象上强制执行默认存储类
  • DefaultTolerationSeconds
  • NodeRestriction，以限制 kubelet 可以修改的内容（例如，仅此节点上的 pod）

• --kubelet-preferred-address-types 为 InternalIP,ExternalIP,Hostname;，这使得 kubectl logs 和其他 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 聚合）通信的其他标志

  • --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

控制器管理器

控制器管理器的静态 Pod 清单受用户提供的以下参数影响

• 如果调用 kubeadm 时指定了 --pod-network-cidr，则通过设置启用某些 CNI 网络插件所需的子网管理器功能

  • --allocate-node-cidrs=true
  • 根据给定的 CIDR 设置 --cluster-cidr 和 --node-cidr-mask-size 标志

无条件设置的其他标志是

• --controllers 启用所有默认控制器以及用于 TLS 引导的 BootstrapSigner 和 TokenCleaner 控制器。有关更多详细信息，请参阅 TLS 引导。

• 将 --use-service-account-credentials 设置为 true

• 用于使用先前步骤中生成的证书的标志

  • 将 --root-ca-file 设置为 ca.crt
  • 将 --cluster-signing-cert-file 设置为 ca.crt，如果禁用外部 CA 模式，否则设置为 ""
  • 将 --cluster-signing-key-file 设置为 ca.key，如果禁用外部 CA 模式，否则设置为 ""
  • 将 --service-account-private-key-file 设置为 sa.key

调度器

调度器的静态 Pod 清单不受用户提供的参数的影响。

为本地 etcd 生成静态 Pod 清单

如果您指定了外部 etcd，则会跳过此步骤，否则 kubeadm 将生成一个静态 Pod 清单文件，用于创建一个在 Pod 中运行的本地 etcd 实例，该实例具有以下属性

• 监听 localhost:2379 并使用 HostNetwork=true
• 从 dataDir 到主机的文件系统创建一个 hostPath 挂载
• 用户指定的任何额外标志

请注意

1. 默认情况下，etcd 容器镜像将从 registry.gcr.io 拉取。有关自定义镜像仓库的信息，请参阅使用自定义镜像。
2. 如果您在 --dry-run 模式下运行 kubeadm，etcd 静态 Pod 清单将被写入一个临时文件夹。
3. 您可以使用 kubeadm init phase etcd local 命令直接调用本地 etcd 的静态 Pod 清单生成。

等待控制平面启动

在控制平面节点上，kubeadm 会等待最多 4 分钟，直到控制平面组件和 kubelet 可用。它通过对各自组件的 /healthz 或 /livez 端点执行健康检查来实现这一点。

控制平面启动后，kubeadm 将完成以下段落中描述的任务。

将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考

kubeadm 将传递给 kubeadm init 的配置保存在 kube-system 命名空间下的名为 kubeadm-config 的 ConfigMap 中。

这将确保将来执行的 kubeadm 操作（例如 kubeadm upgrade）能够确定实际/当前的集群状态，并根据该数据做出新的决策。

请注意

1. 在保存 ClusterConfiguration 之前，会从配置中剥离诸如令牌之类的敏感信息
2. 可以使用命令 kubeadm init phase upload-config 单独调用控制平面节点配置的上传。

将节点标记为控制平面

一旦控制平面可用，kubeadm 将执行以下操作

• 使用 node-role.kubernetes.io/control-plane="" 将节点标记为控制平面
• 使用 node-role.kubernetes.io/control-plane:NoSchedule 污点节点

请注意，可以使用 kubeadm init phase mark-control-plane 命令单独调用标记控制平面的阶段。

配置用于节点加入的 TLS 引导

Kubeadm 使用使用引导令牌进行身份验证将新节点加入现有集群；有关更多详细信息，另请参阅设计提案。

kubeadm init 确保为此过程正确配置一切，这包括以下步骤以及设置 API 服务器和控制器标志，如前几段所述。

创建一个引导令牌

kubeadm init 创建第一个引导令牌，该令牌可以是自动生成的，也可以是由用户使用 --token 标志提供的；如引导令牌规范中所述，令牌应保存为 kube-system 命名空间下名为 bootstrap-token-<token-id> 的 Secret。

请注意

1. kubeadm init 创建的默认令牌将用于在 TLS 引导过程中验证临时用户；这些用户将是 system:bootstrappers:kubeadm:default-node-token 组的成员
2. 令牌具有有限的有效期，默认 24 小时（可以使用 —token-ttl 标志更改间隔）
3. 可以使用 kubeadm token 命令创建其他令牌，该命令还为令牌管理提供其他有用的功能。

允许加入节点调用 CSR API

Kubeadm 确保 system:bootstrappers:kubeadm:default-node-token 组中的用户能够访问证书签名 API。

这是通过在上述组和默认 RBAC 角色 system:node-bootstrapper 之间创建名为 kubeadm:kubelet-bootstrap 的 ClusterRoleBinding 来实现的。

设置新引导令牌的自动批准

Kubeadm 确保引导令牌的 CSR 请求将由 csrapprover 控制器自动批准。

这是通过在 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 权限。

设置具有自动批准的节点证书轮换

Kubeadm 确保为节点启用证书轮换，并且节点的新证书请求将由 csrapprover 控制器自动批准其 CSR 请求。

这是通过在 system:nodes 组和默认角色 system:certificates.k8s.io:certificatesigningrequests:selfnodeclient 之间创建名为 kubeadm:node-autoapprove-certificate-rotation 的 ClusterRoleBinding 来实现的。

创建公共 cluster-info ConfigMap

此阶段在 kube-public 命名空间中创建 cluster-info ConfigMap。

此外，它还会创建一个 Role 和一个 RoleBinding，授予未经身份验证的用户（即 RBAC 组 system:unauthenticated 中的用户）访问 ConfigMap 的权限。

安装插件

Kubeadm 通过 API 服务器安装内部 DNS 服务器和 kube-proxy 插件组件。

代理

在 kube-system 命名空间中为 kube-proxy 创建一个 ServiceAccount；然后将 kube-proxy 部署为 DaemonSet

• 控制平面的凭据（ca.crt 和 token）来自 ServiceAccount
• API 服务器的位置（URL）来自 ConfigMap
• kube-proxy ServiceAccount 被绑定到 system:node-proxier ClusterRole 中的权限

DNS

• CoreDNS 服务被命名为 kube-dns，以与传统的 kube-dns 插件兼容。

• 在 kube-system 命名空间中为 CoreDNS 创建一个 ServiceAccount。

• coredns ServiceAccount 被绑定到 system:coredns ClusterRole 中的权限

在 Kubernetes 1.21 版本中，删除了 kubeadm 对使用 kube-dns 的支持。即使相关服务被命名为 kube-dns，您也可以将 CoreDNS 与 kubeadm 一起使用。

kubeadm join 阶段的内部设计

与 kubeadm init 类似，kubeadm join 的内部工作流程也由一系列要执行的原子工作任务组成。

这分为发现（让节点信任 Kubernetes API 服务器）和 TLS 引导（让 Kubernetes API 服务器信任节点）。

请参阅使用引导令牌进行身份验证或相应的设计提案。

预检

在开始加入之前，kubeadm 会执行一组预检，目的是验证先决条件并避免常见的集群启动问题。

另请注意

1. kubeadm join 预检基本上是 kubeadm init 预检的子集
2. 如果要加入 Windows 节点，则会跳过特定于 Linux 的控件。
3. 在任何情况下，用户都可以使用 --ignore-preflight-errors 选项跳过特定的预检（或最终跳过所有预检）。

发现 cluster-info

有两种主要的发现方案。第一种是使用共享令牌以及 API 服务器的 IP 地址。第二种是提供一个文件（它是标准 kubeconfig 文件的子集）。

共享令牌发现

如果使用 --discovery-token 调用 kubeadm join，则使用令牌发现；在这种情况下，节点基本上从 kube-public 命名空间中的 cluster-info ConfigMap 中检索集群 CA 证书。

为了防止“中间人”攻击，采取了几个步骤

• 首先，通过不安全的连接检索 CA 证书（这是可能的，因为 kubeadm init 被授予对 system:unauthenticated 的用户访问 cluster-info 的权限）

• 然后，CA 证书将经过以下验证步骤

  • 基本验证：使用令牌 ID 对 JWT 签名进行验证
  • 公钥验证：使用提供的 --discovery-token-ca-cert-hash。此值在 kubeadm init 的输出中可用，或者可以使用标准工具计算（哈希是根据 RFC7469 中的主题公钥信息 (SPKI) 对象的字节计算的）。 --discovery-token-ca-cert-hash 标志可以重复多次，以允许多个公钥。
  • 作为额外的验证，CA 证书通过安全连接检索，然后与最初检索的 CA 进行比较

文件/https 发现

如果使用 --discovery-file 调用 kubeadm join，则使用文件发现；此文件可以是本地文件，也可以通过 HTTPS URL 下载；对于 HTTPS，使用主机安装的 CA 捆绑包来验证连接。

通过文件发现，集群 CA 证书在文件本身中提供；实际上，发现文件是一个 kubeconfig 文件，其中仅设置了 server 和 certificate-authority-data 属性，如kubeadm join 参考文档中所述；当与集群建立连接后，kubeadm 会尝试访问 cluster-info ConfigMap，如果可用，则会使用它。

TLS 引导

一旦知道集群信息，就会写入文件 bootstrap-kubelet.conf，从而允许 kubelet 执行 TLS 引导。

TLS 引导机制使用共享令牌临时向 Kubernetes API 服务器进行身份验证，以提交本地创建的密钥对的证书签名请求 (CSR)。

然后，该请求会自动获得批准，并且操作完成，保存 ca.crt 文件和 kubelet.conf 文件以供 kubelet 加入集群时使用，同时删除 bootstrap-kubelet.conf。

kubeadm 升级工作流内部设计

kubeadm upgrade 具有子命令，用于处理由 kubeadm 创建的 Kubernetes 集群的升级。 你必须在控制平面节点上运行 kubeadm upgrade apply （你可以选择其中一个）；这将启动升级过程。 然后，在所有剩余节点（包括工作节点和控制平面节点）上运行 kubeadm upgrade node。

kubeadm upgrade apply 和 kubeadm upgrade node 都具有 phase 子命令，该子命令提供对升级过程内部阶段的访问。 有关详细信息，请参阅 kubeadm upgrade phase。

其他实用升级命令包括 kubeadm upgrade plan 和 kubeadm upgrade diff。

所有升级子命令都支持传递配置文件。

kubeadm upgrade plan

你可以选择在运行 kubeadm upgrade apply 之前运行 kubeadm upgrade plan。plan 子命令会检查哪些版本可用于升级，并验证你当前的集群是否可升级。

kubeadm upgrade diff

这会显示将对控制平面节点现有静态 Pod 清单应用哪些差异。 执行相同操作的更详细方法是运行 kubeadm upgrade apply --dry-run 或 kubeadm upgrade node --dry-run。

kubeadm upgrade apply

kubeadm upgrade apply 准备集群以升级所有节点，并升级运行它的控制平面节点。 它执行的步骤是：

• 运行类似于 kubeadm init 和 kubeadm join 的预检检查，确保已下载容器镜像，并且集群处于良好的升级状态。
• 升级磁盘上 /etc/kubernetes/manifests 中的控制平面清单文件，如果文件已更改，则等待 kubelet 重启组件。
• 将更新的 kubeadm 和 kubelet 配置上传到集群的 kubeadm-config 和 kubelet-config ConfigMap 中（都在 kube-system 命名空间中）。
• 在此节点的 /var/lib/kubelet/config.yaml 中写入更新的 kubelet 配置。
• 为 RBAC 规则配置引导令牌和 cluster-info ConfigMap。 这与 kubeadm init 阶段相同，并确保集群继续支持使用引导令牌加入的节点。
• 如果集群中所有现有的 kube-apiservers 都已升级到目标版本，则有条件地升级 kube-proxy 和 CoreDNS 插件。
• 执行任何升级后任务，例如清理特定于版本的已弃用功能。

kubeadm upgrade node

在集群升级开始后（通过运行 kubeadm upgrade apply），kubeadm upgrade node 升级单个控制平面或工作节点。 该命令通过检查文件 /etc/kubernetes/manifests/kube-apiserver.yaml 是否存在来检测节点是否为控制平面节点。 找到该文件后，kubeadm 工具会推断此节点上正在运行 kube-apiserver Pod。

• 运行类似于 kubeadm upgrade apply 的预检检查。
• 对于控制平面节点，升级磁盘上 /etc/kubernetes/manifests 中的控制平面清单文件，如果文件已更改，则等待 kubelet 重启组件。
• 在此节点的 /var/lib/kubelet/config.yaml 中写入更新的 kubelet 配置。
• （对于控制平面节点）有条件地升级 kube-proxy 和 CoreDNS 插件，前提是集群中所有现有的 API 服务器都已升级到目标版本。
• 执行任何升级后任务，例如清理特定于版本的已弃用功能。

kubeadm reset 工作流内部设计

你可以在先前执行 kubeadm 命令的节点上使用 kubeadm reset 子命令。 此子命令对节点执行**尽力而为**的清理。 如果某些操作失败，你必须进行干预并执行手动清理。

该命令支持阶段。 有关详细信息，请参阅 kubeadm reset phase。

该命令支持配置文件。

此外

• IPVS、iptables 和 nftables 规则**不会**被清理。
• CNI（网络插件）配置**不会**被清理。
• 用户主目录中的 .kube/**不会**被清理。

该命令具有以下阶段：

• 在节点上运行预检检查以确定其是否健康。
• 对于控制平面节点，删除任何本地 etcd 成员数据。
• 停止 kubelet。
• 停止正在运行的容器。
• 卸载 /var/lib/kubelet 中任何已挂载的目录。
• 删除 /var/lib/kubelet 和 /etc/kubernetes 中由 kubeadm 管理的任何文件和目录。