kubernetes的TLS 启动引导（二进制方式、kubeadm）

忍冬行者

已于 2022-06-02 09:51:45 修改

阅读量739

点赞数 1

分类专栏： k8s 文章标签： kubernetes 容器 docker

于 2022-06-02 09:48:11 首次发布

本文链接：https://blog.csdn.net/rendongxingzhe/article/details/125094200

版权

k8s 专栏收录该内容

52 篇文章 6 订阅

订阅专栏

在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与 Kubernetes 控制平面组件通信，尤其是 kube-apiserver。为了确保通信本身是私密的、不被干扰，并且确保集群的每个组件都在与另一个可信的组件通信。

在安装 k8s worker node 时，基本上 worker 的初始状态仅仅是安装了 docker 和 kubelet，worker 需要一种机制跟 master 通信。但网络通信的基本假设是通信双方谁也不信任谁。所以，kubelet bootstrap要以自动化的方式解决如下几个问题：

在只知道 api server IP 地址的情况下，worker node 如何获取 api server 的 CA 证书？
如何让 api server 信任 worker？因为在 api server 信任 worker 之前，worker 没有途径拿到自己的证书

初始化过程

当工作节点启动时，kubelet 执行以下操作：

寻找自己的 kubeconfig 文件
检索 API 服务器的 URL 和凭据，通常是来自 kubeconfig 文件中的 TLS 密钥和已签名证书
尝试使用这些凭据来与 API 服务器通信

启动引导初始化

在启动引导初始化过程中，会发生以下事情：

kubelet 启动
kubelet 看到自己没有对应的 kubeconfig 文件
kubelet 搜索并发现 bootstrap-kubeconfig 文件
kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的一个“令牌（Token）”
kubelet 建立与 API 服务器的连接，使用上述令牌执行身份认证
kubelet 现在拥有受限制的凭据来创建和取回证书签名请求（CSR）
kubelet 为自己创建一个 CSR，并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
CSR 被以如下两种方式之一批复：kube-controller-manager 会自动批复该 CSR和用 Kubernetes API 或者使用 kubectl 来批复该 CSR
kubelet 所需要的证书被创建
证书被发放给 kubelet
kubelet 取回该证书
kubelet 创建一个合适的 kubeconfig，其中包含密钥和已签名的证书
kubelet 开始正常操作
可选地，如果配置了，kubelet 在证书接近于过期时自动请求更新证书
更新的证书被批复并发放；取决于配置，这一过程可能是自动的或者手动完成

什么是 bootstrap token

要让 api server 信任 worker，worker 得需要先过 master 认证鉴权这一关。k8s 以插件化的方式支持很多种认证方式，比如 token 文件，x509证书，service account 等等，其中就包含一个名为“Bootstrap Token Authentication”的认证方式，基本上 k8s 的默认安装就默认支持这种认证方式。这种方式最初就是设计用来给添加 worker node 用的。使用 Bootstrap Token Authentication 时，只需告诉 kubelet 一个特殊的 token，kubelet 自然就能通过 api server 的认证。所以，首先得保证 k8s 中定义了这个 token

apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-c8ad9c
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  description: "The default bootstrap token generated by 'kubelet '."
  token-id: c8ad9c
  token-secret: 2e4d610cf3e7426e
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"
  auth-extra-groups:  system:bootstrappers:default-node-token,system:bootstrappers:worker,system:bootstrappers:ingress

token 的 name 必须是 bootstrap-token-<token-id> 的格式
token 的 type 必须是 bootstrap.kubernetes.io/token
token 的 token-id 和 token-secret 分别是6位和16位数字和字母的组合
auth-extra-groups 定义了 token 代表的用户所属的额外的 group，而默认 group 名为 system:bootstrappers
这种类型 token 代表的用户名为 system:bootstrap:<token-id>，在本文中就是 system:bootstrap:c8ad9c

配置

要配置 TLS 启动引导及可选的自动批复，你必须配置以下组件的选项：

kube-apiserver
kube-controller-manager
kubelet
集群内的资源：ClusterRoleBinding 以及可能需要的 ClusterRole

此外，你需要有 Kubernetes 证书机构（Certificate Authority，CA）。就像在没有启动引导的情况下，你会需要证书机构（CA）密钥和证书。这些数据会被用来对 kubelet 证书进行签名。通过kubeadm安装的kubernetes集群默认证书路径/etc/kubernetes/目录下

kube-apiserver 配置

启用 TLS 启动引导对 kube-apiserver 有若干需求：

能够识别对客户端证书进行签名的 CA
能够对启动引导的 kubelet 执行身份认证，并将其置入 system:bootstrappers 组
能够对启动引导的 kubelet 执行鉴权操作，允许其创建证书签名请求（CSR）。

kube-apiserver 命令添加 --client-ca-file=FILENAME 标志来启用客户端证书认证，在标志中引用一个包含用来签名的证书的证书机构包，例如：-- client-ca-file=/etc/kubernetes/ca.pem

初始启动引导认证

为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书，它必须首先在服务器上认证自身身份。你可以使用任何一种能够对 kubelet 执行身份认证的身份认证组件。

尽管所有身份认证策略都可以用来对 kubelet 的初始启动凭据来执行认证，出于容易准备的因素，建议使用如下两个身份认证组件：启动引导令牌和

启动引导令牌是一种对 kubelet 进行身份认证的方法，相对简单且容易管理，且不需要在启动 kube-apiserver 时设置额外的标志。

无论选择哪种方法，这里的需求是 kubelet 能够被身份认证为某个具有如下权限的用户：

创建和读取 CSR
在启用了自动批复时，能够在请求节点客户端证书时得到自动批复

使用启动引导令牌执行身份认证的 kubelet 会被认证为 system:bootstrappers 组中的用户。这是使用启动引导令牌的一种标准方法。

启动引导令牌在 Kubernetes 集群中存储为 Secret 对象，被发放给各个 kubelet。你可以在整个集群中使用同一个令牌，也可以为每个节点发放单独的令牌。

这一过程有两个方面：

基于令牌 ID、机密数据和范畴信息创建 Kubernetes Secret
将令牌发放给 kubelet

从 kubelet 的角度，所有令牌看起来都很像，没有特别的含义。从 kube-apiserver 服务器的角度，启动引导令牌是很特殊的。根据其 type、namespace 和 name，kube-apiserver 能够将认作特殊的令牌，并授予携带该令牌的任何人特殊的启动引导权限，换言之，将其视为 system:bootstrappers 组的成员。这就满足了 TLS 启动引导的基本需求。

如果你希望使用启动引导令牌，你必须在 kube-apiserver 上使用下面的标志启用之：

--enable-bootstrap-token-auth=true

令牌认证文件

kube-apiserver 能够将令牌视作身份认证依据。这些令牌可以是任意数据，但必须表示为基于某安全的随机数生成器而得到的至少 128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的 /dev/urandom。生成令牌的方式有很多种。例如：

head -c 16 /dev/urandom | od -An -t x | tr -d ' '

上面的命令会生成类似于 02b50b05283e98dd0fd71db496ef01e8 这样的令牌。

令牌文件看起来是下面的例子这样，其中前面三个值可以是任何值，用引号括起来的组名称则只能用例子中给的值。

02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"

向 kube-apiserver 添加 --token-auth-file=FILENAME 标志。

授权 kubelet 创建 CSR

现在启动引导节点被身份认证为 system:bootstrapping 组的成员，它需要被授权创建证书签名请求（CSR）并在证书被签名之后将其取回。幸运的是，Kubernetes 提供了一个 ClusterRole，名称为system:node-bootstrapper，其中精确地封装了这些许可： system:node-bootstrapper。

为了实现这一点，你只需要创建 ClusterRoleBinding，将 system:bootstrappers 组绑定到集群角色 system:node-bootstrapper。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-bootstrap
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:bootstrappers:default-node-token

kube-controller-manager 配置

API 服务器从 kubelet 收到证书请求并对这些请求执行身份认证，但真正负责发放签名证书的是kube-controller-manager 控制器管理器。

控制器管理器通过一个证书发放的控制回路来执行此操作。该操作的执行方式是使用磁盘上的文件用 cfssl 本地签名组件来完成。目前，所发放的所有证书都有一年的有效期，并设定了默认的一组密钥用法。

为了让控制器管理器对证书签名，它需要：

能够访问你之前所创建并分发的“Kubernetes CA 密钥和证书”
启用 CSR 签名

访问密钥和证书

如前所述，你需要创建一个 Kubernetes CA 密钥和证书，并将其发布到控制平面节点。这些数据会被控制器管理器来对 kubelet 证书进行签名。

由于这些被签名的证书反过来会被 kubelet 用来在 kube-apiserver 执行普通的 kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA 也被 kube-apiserver 信任用来执行身份认证。CA 密钥和证书是通过 kube-apiserver 的标志 --client-ca-file=FILENAME

要将 Kubernetes CA 密钥和证书提供给 kube-controller-manager，可使用以下标志：

--cluster-signing-cert-file="/etc//kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/kubernetes/ca/ca.key"

所签名的证书的合法期限可以通过下面的标志来配置

--cluster-signing-duration 87600h0m0s

为了对 CSR 进行批复，你需要告诉控制器管理器批复这些 CSR 是可接受的。这是通过将 RBAC 访问权限授予正确的组来实现的。

许可权限有两组：

nodeclient：如果节点在为节点创建新的证书，则该节点还没有证书。该节点使用前文所列的令牌之一来执行身份认证，因此是组 system:bootstrappers 组的成员。
selfnodeclient：如果节点在对证书执行续期操作，则该节点已经拥有一个证书。节点持续使用现有的证书将自己认证为 system:nodes 组的成员。

要允许 kubelet 请求并接收新的证书，可以创建一个 ClusterRoleBinding 将启动引导节点所处的组 system:bootstrappers 绑定到为其赋予访问权限的 ClusterRole system:certificates.k8s.io:certificatesigningrequests:nodeclient：

# 批复 "system:bootstrappers" 组的所有 CSR
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
  apiGroup: rbac.authorization.k8s.io

要允许 kubelet 对其客户端证书执行续期操作，可以创建一个 ClusterRoleBinding 将正常工作的节点所处的组 system:nodes 绑定到为其授予访问许可的 ClusterRole system:certificates.k8s.io:certificatesigningrequests:selfnodeclient

# 批复 "system:nodes" 组的 CSR 续约请求
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
  apiGroup: rbac.authorization.k8s.io

作为 kube-controller-manager 的一部分的 csrapproving 控制器是自动被启用的。该控制器使用 SubjectAccessReview API 来确定是否某给定用户被授权请求 CSR，之后基于鉴权结果执行批复操作。为了避免与其它批复组件发生冲突，内置的批复组件不会显式地拒绝任何 CSRs。该组件仅是忽略未被授权的请求。控制器也会作为垃圾收集的一部分清除已过期的证书。

kubelet 配置

最后，当控制平面节点被正确配置并且所有必要的身份认证和鉴权机制都就绪时，我们可以配置 kubelet。

kubelet 需要以下配置来执行启动引导：

一个用来存储所生成的密钥和证书的路径（可选，可以使用默认配置）
一个用来指向尚不存在的 kubeconfig 文件的路径；kubelet 会将启动引导配置文件放到这个位置
一个指向启动引导 kubeconfig 文件的路径，用来提供 API 服务器的 URL 和启动引导凭据，例如，启动引导令牌
可选的：轮换证书的指令

启动引导 kubeconfig 文件应该放在一个 kubelet 可访问的路径下，例如 /var/lib/kubelet/bootstrap-kubeconfig。

其格式与普通的 kubeconfig 文件完全相同。实例文件可能看起来像这样：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQ1RENDQXN5Z0F3SUJBZ0lVUFUyOFUvaWxaQWJUV3ltRVkzbnRHa2Eycytnd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2R6RUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFXcHBibWN4RURBT0JnTlZCQWNUQjBKbAphV3BwYm1jeEV6QVJCZ05WQkFvVENrdDFZbVZ5Ym1WMFpYTXhHakFZQmdOVkJBc1RFVXQxWW1WeWJtVjBaWE10CmJXRnVkV0ZzTVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1DQVhEVEl5TURNd05EQXhNVEF3TUZvWUR6SXgKTWpJd01qQTRNREV4TURBd1dqQjNNUXN3Q1FZRFZRUUdFd0pEVGpFUU1BNEdBMVVFQ0JNSFFtVnBhbWx1WnpFUQpNQTRHQTFVRUJ4TUhRbVZwYW1sdVp6RVRNQkVHQTFVRUNoTUtTM1ZpWlhKdVpYUmxjekVhTUJnR0ExVUVDeE1SClMzVmlaWEp1WlhSbGN5MXRZVzUxWVd3eEV6QVJCZ05WQkFNVENtdDFZbVZ5Ym1WMFpYTXdnZ0VpTUEwR0NTcUcKU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ2lEY0N5QW1EbXRRU1RVZlZmY0p0VkdPbEFBVmtjUDNBVQo0M2tucmo2UlpRTDY0UU1qOVErUk1oT0tuNjVIcC9QaUdCYmE2QytFUUEvcy8xdWt5b3lBNy8xYnQvM3VBclB1CjlUd2cyMDFFS1l1a0k5M3Z1ZEhWSUc1K2xWNVViR1N1VTNXSmJZbVdOOWkvaDQ2aGVwMm94MTk3NytNRndzcE0KV2lyb0RFSE1NS0JoWElTMWtFR2xZTnVqMGJ3ckJDblBWMXNrak5jTnZYR1JTSUt3UTJZZUszbmRGN2VpaVBMbQp5NDFzaUhsTXZMY0VKTGt2ZEZ1RGhLRUN3T2ZzMGJPTXJNdTZQa3kwbU4zOElhK2JQWE5ZajJBdW1qdHVpNEtwCjI5V3crT0hnL3hUTVNNNVREQWg1UjNCalhqMnVDMDN0Wm1kbU5KWFlxSDRML0lpZlBFYUpBZ01CQUFHalpqQmsKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFTQmdOVkhSTUJBZjhFQ0RBR0FRSC9BZ0VDTUIwR0ExVWREZ1FXQkJSagpnQUJBbDg1STF0cXNZTkhCbEc5aHR4emp4akFmQmdOVkhTTUVHREFXZ0JSamdBQkFsODVJMXRxc1lOSEJsRzloCnR4emp4akFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBS0lpNjBEMTJRZUdFaG9aVjBUZm0ybE5laVlQSU1xaUUKQW1rQWIwclpEMVRzeHRsTDFrQ3E5KzN2eXM4U3JtMVVhVzl0SlN1bnNqL0pZdHdFYTZkdVU1NHJwVzNQUjh1dwp3aUovTXZKWk9zb0xQZ0wwWkplejVORHRhU21rdzltckdWa25qOFlGd0hzOVFrczZPNXkyMnlZVnBTUWhERzBqClQ3UG5wbXU2Y0VDZGhQRTZuQk9DQ2FPNmxzcUl2bHBPRFlUbjJuVXBYclV0YW44d3g2S2VuN2IrRXMrK3pYNXMKRnRrMUZ2enhoVGNWazZ4b3BHNldUQXVIVnBPaVQ1eEgvaUlUb3pIMnR3U0pGRHpSbHV4ZGg3L3VmMTlqRFdiLwpKYkF1T0ZIREl0Tk43OHlLWkxtaFdZTUg0NmNaYk1wMXpybmZkRyttVWpLL1Q1OVNML2J2dmc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    #certificate-authority: /etc/kubernetes/ca.pem
    server: https://10.10.20.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: tls-bootstrap-token-user
  name: tls-bootstrap-token-user@kubernetes
current-context: tls-bootstrap-token-user@kubernetes
kind: Config
preferences: {}
users:
- name: tls-bootstrap-token-user
  user:
    token: c8ad9c.2e4d610cf3e7426e

需要额外注意的一些因素有：

certificate-authority：指向 CA 文件的路径，用来对 kube-apiserver 所出示的服务器证书进行验证
server：用来访问 kube-apiserver 的 URL
token：要使用的令牌

因为启动引导 kubeconfig 文件是一个标准的 kubeconfig 文件，你可以使用 kubectl 来生成该文件。要生成上面的示例文件：

kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/etc/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap

要指示 kubelet 使用启动引导 kubeconfig 文件，可以使用下面的 kubelet 标志：

--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"

在启动 kubelet 时，如果 --kubeconfig 标志所指定的文件并不存在，会使用通过标志 --bootstrap-kubeconfig 所指定的启动引导 kubeconfig 配置来向 API 服务器请求客户端证书。在证书请求被批复并被 kubelet 收回时，一个引用所生成的密钥和所获得证书的 kubeconfig 文件会被写入到通过 --kubeconfig 所指定的文件路径下。证书和密钥文件会被放到 --cert-dir 所指定的目录中.

客户和服务证书

前文所述的内容都与 kubelet 客户端 证书相关，尤其是 kubelet 用来向 kube-apiserver 认证自身身份的证书。

kubelet 也可以使用 服务（Serving） 证书。kubelet 自身向外提供一个 HTTPS 末端，包含若干功能特性。要保证这些末端的安全性，kubelet 可以执行以下操作之一：

使用通过 --tls-private-key-file 和 --tls-cert-file 所设置的密钥和证书
如果没有提供密钥和证书，则创建自签名的密钥和证书
通过 CSR API 从集群服务器请求服务证书

TLS 启动引导所提供的客户端证书默认被签名为仅用于 client auth（客户端认证），因此不能作为提供服务的证书，或者 server auth。

证书轮换

RotateKubeletClientCertificate 会导致 kubelet 在其现有凭据即将过期时通过创建新的 CSR 来轮换其客户端证书。要启用此功能特性，可将下面的标志传递给 kubelet：

--rotate-certificates

RotateKubeletServerCertificate 会让 kubelet 在启动引导其客户端凭据之后请求一个服务证书且对该服务证书执行轮换操作。要启用此功能特性，将下面的标志传递给 kubelet：

--rotate-server-certificates

kubectl 批复

CSRs 可以在控制器管理其内置的批复工作流之外被批复。

签名控制器并不会立即对所有证书请求执行签名操作。相反，它会等待这些请求被某具有适当特权的用户标记为 “Approved（已批准）”状态。这一流程有意允许由外部批复控制器来自动执行的批复，或者由控制器管理器内置的批复控制器来自动批复。不过，集群管理员也可以使用 kubectl 来手动批准证书请求。管理员可以通过 kubectl get csr 来列举所有的 CSR，使用 kubectl descsribe csr <name> 来描述某个 CSR 的细节。管理员可以使用 kubectl certificate approve <name 来批准某 CSR，或者 kubectl certificate deny <name> 来拒绝某 CSR。

总结一下 kubelet 的 bootstrap 流程：

引导kubelet(二进制方式)

引导 kubelet

有了上述背景知识，在一个新的 worker node 上配置 kubelet service 就比较简单了。先总结一下我们都创建了什么东西：

创建了 bootstrap token
给 bootstrap token 代表的用户 system:bootstrap:赋予 clusterole certificatesigningrequests.certificates.k8s.io/nodeclient 和 system:node-bootstrapper，让该用户可以访问 csr API 以及自动审批其创建的 csr
给新的 work node 代表的用户 system:node 赋予 clusterrole system:certificates.k8s.io:certificatesigningrequests:selfnodeclient，让它发送的证书 renew 的请求能被自动审批

接下来，需要生成 bootstrap 配置文件，这里假设我们已经知道 api server 的地址以及 ca 证书(关于如何获取这些信息后续会补充)，你可以在 master node 执行如下命令生成 bootstrap-kubeconfig 文件并拷贝到 node 上

kubectl config set-cluster k8s --server https://10.10.20.200:6443 --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig
kubectl config set-credentials node --token=c8ad9c.2e4d610cf3e7426e --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig
kubectl config set-context node-bootstrap --cluster k8s --user node --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig
kubectl config use-context node-bootstrap --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig

配置 kubelet systemd 配置文件，需要指定 --kubeconfig 以存放 bootstrap token 获取的证书信息，kubelet 会动态创建该文件，而证书文件本身默认存放在 /var/lib/kubelet/pki 目录下，可以指定 --cert-dir 自定义证书路径。

cat <<EOF > /etc/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=docker.service
Requires=docker.service

[Service]
ExecStart=/usr/bin/kubelet \\
  --bootstrap-kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig \\
  --kubeconfig=/var/lib/kubelet/kubeconfig \\
  --network-plugin=cni \\
  --rotate-certificates=true \\
  --register-node=true \\
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

重启 kubelet 服务：

systemctl daemon-reload; systemctl restart kubelet

待 kubelet 服务启动后，你可以在 worker node 上 /var/lib/kubelet/pki 目录下看到生成的证书，并且 kubelet 自动生成了 /var/lib/kubelet/kubeconfig 文件。

使用 kubeadm引导kubelet

1.在 master node 生成一个新的 token

因为 bootstrap token 有效期默认是24小时，所以当你考虑向 cluster 中新增 node 时，原来创建的 token 可能早已过期，你需要创建一个新的 bootstrap token。

kubeadm token list
#token默认24小时到期，生产新的token并打印加入集群的kubeadm join 命令
kubeadm token create --print-join-command

2. 在新 worker node 上

kubeadm join 10.10.20.200:6443 --token 1dwb0v.hgsacqug9obl4msa     --discovery-token-ca-cert-hash sha256:7870e51c939e00105bf6d8d3869d47441aced12329788f81a7e58715d1f6b912