使用 kubeadm 进行证书管理
Kubernetes v1.15 [稳定版]
由 kubeadm 生成的客户端证书会在 1 年后过期。此页面说明如何使用 kubeadm 管理证书续订。它还涵盖与 kubeadm 证书管理相关的其他任务。
Kubernetes 项目建议及时升级到最新的补丁版本,并确保你正在运行 Kubernetes 的受支持的次要版本。遵循此建议有助于你保持安全。
开始之前
你应该熟悉 Kubernetes 中的 PKI 证书和要求。
你应该熟悉如何将 配置文件传递给 kubeadm 命令。
本指南涵盖 `openssl` 命令的用法(用于手动证书签名,如果你选择这种方法),但你可以使用你喜欢的工具。
这里的一些步骤使用 `sudo` 来获取管理员访问权限。你可以使用任何等效的工具。
使用自定义证书
默认情况下,kubeadm 会生成运行集群所需的所有证书。你可以通过提供自己的证书来覆盖此行为。
为此,你必须将它们放置在 `--cert-dir` 标志或 kubeadm 的 `ClusterConfiguration` 的 `certificatesDir` 字段指定的任何目录中。默认情况下,这是 `/etc/kubernetes/pki`。
如果在运行 `kubeadm init` 之前存在给定的证书和私钥对,则 kubeadm 不会覆盖它们。这意味着,例如,你可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和 `/etc/kubernetes/pki/ca.key`,kubeadm 将使用此 CA 来签署其余的证书。
选择加密算法
kubeadm 允许你选择用于创建公钥和私钥的加密算法。可以通过使用 kubeadm 配置的 `encryptionAlgorithm` 字段来完成。
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
encryptionAlgorithm: <ALGORITHM>
`<ALGORITHM>` 可以是 `RSA-2048`(默认)、`RSA-3072`、`RSA-4096` 或 `ECDSA-P256` 之一。
选择证书有效期
kubeadm 允许你选择 CA 和叶证书的有效期。这可以通过使用 kubeadm 配置的 `certificateValidityPeriod` 和 `caCertificateValidityPeriod` 字段来完成
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
certificateValidityPeriod: 8760h # Default: 365 days × 24 hours = 1 year
caCertificateValidityPeriod: 87600h # Default: 365 days × 24 hours * 10 = 10 years
字段的值遵循 Go 的 `time.Duration` 值的可接受格式,最长支持的单位是 `h`(小时)。
外部 CA 模式
也可以只提供 `ca.crt` 文件,而不提供 `ca.key` 文件(这仅适用于根 CA 文件,而不适用于其他证书对)。如果所有其他证书和 kubeconfig 文件都到位,则 kubeadm 会识别此情况并激活“外部 CA”模式。kubeadm 将在没有磁盘上的 CA 密钥的情况下继续进行。
相反,请使用 `--controllers=csrsigner` 独立运行控制器管理器,并指向 CA 证书和密钥。
当使用外部 CA 模式时,有多种方法可以准备组件凭据。
手动准备组件凭据
PKI 证书和要求包含有关如何手动准备 kubeadm 所需的所有组件凭据的信息。
本指南涵盖 `openssl` 命令的用法(用于手动证书签名,如果你选择这种方法),但你可以使用你喜欢的工具。
通过签署由 kubeadm 生成的 CSR 来准备凭据
kubeadm 可以生成 CSR 文件,你可以使用 `openssl` 等工具和你的外部 CA 手动签名。这些 CSR 文件将包括 kubeadm 部署的组件所需的所有凭据规范。
通过使用 kubeadm 阶段自动准备组件凭据
或者,可以使用 kubeadm 阶段命令来自动化此过程。
- 转到你要准备为具有外部 CA 的 kubeadm 控制平面节点的宿主机。
- 将你拥有的外部 CA 文件 `ca.crt` 和 `ca.key` 复制到节点上的 `/etc/kubernetes/pki`。
- 准备一个临时的 kubeadm 配置文件,名为 `config.yaml`,可与 `kubeadm init` 一起使用。确保此文件包含任何可能包含在证书中的相关集群范围或特定于宿主机的信息,例如 `ClusterConfiguration.controlPlaneEndpoint`、`ClusterConfiguration.certSANs` 和 `InitConfiguration.APIEndpoint`。
- 在同一主机上执行命令 `kubeadm init phase kubeconfig all --config config.yaml` 和 `kubeadm init phase certs all --config config.yaml`。这将在 `/etc/kubernetes/` 及其 `pki` 子目录下生成所有必需的 kubeconfig 文件和证书。
- 检查生成的文件。删除 `/etc/kubernetes/pki/ca.key`,删除或移动到安全位置的文件 `/etc/kubernetes/super-admin.conf`。
- 在将调用 `kubeadm join` 的节点上,也删除 `/etc/kubernetes/kubelet.conf`。此文件仅在将调用 `kubeadm init` 的第一个节点上是必需的。
- 请注意,某些文件(如 `pki/sa.*`、`pki/front-proxy-ca.*` 和 `pki/etc/ca.*`)在控制平面节点之间共享。你可以生成一次,然后手动将它们分发到将调用 `kubeadm join` 的节点,或者你可以使用 `--upload-certs` 功能(`kubeadm init`)和 `--certificate-key` 功能(`kubeadm join`)来自动化此分发。
在所有节点上准备好凭据后,调用 `kubeadm init` 和 `kubeadm join` 以使这些节点加入集群。kubeadm 将使用 `/etc/kubernetes/` 及其 `pki` 子目录下的现有 kubeconfig 和证书文件。
证书过期和管理
注意
`kubeadm` 无法管理由外部 CA 签名的证书。你可以使用 `check-expiration` 子命令来检查证书何时过期
kubeadm certs check-expiration
输出类似于这样
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Dec 30, 2020 23:36 UTC 364d no
apiserver Dec 30, 2020 23:36 UTC 364d ca no
apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no
controller-manager.conf Dec 30, 2020 23:36 UTC 364d no
etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no
etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no
front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no
scheduler.conf Dec 30, 2020 23:36 UTC 364d no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Dec 28, 2029 23:36 UTC 9y no
etcd-ca Dec 28, 2029 23:36 UTC 9y no
front-proxy-ca Dec 28, 2029 23:36 UTC 9y no
该命令显示 `/etc/kubernetes/pki` 文件夹中客户端证书以及 kubeadm 使用的 kubeconfig 文件(`admin.conf`、`controller-manager.conf` 和 `scheduler.conf`)中嵌入的客户端证书的过期时间/剩余时间。
此外,kubeadm 会通知用户证书是否由外部管理;在这种情况下,用户应负责手动/使用其他工具管理证书续订。
上面的列表中不包含 `kubelet.conf` 配置文件,因为 kubeadm 配置 kubelet 以使用 `/var/lib/kubelet/pki` 下的可轮换证书进行自动证书续订。要修复过期的 kubelet 客户端证书,请参阅 Kubelet 客户端证书轮换失败。
注意
在从 kubeadm 1.17 版本之前的版本使用 `kubeadm init` 创建的节点上,存在一个 bug,你需要手动修改 `kubelet.conf` 的内容。在 `kubeadm init` 完成后,你应该通过将 `client-certificate-data` 和 `client-key-data` 替换为来更新 `kubelet.conf`,以指向轮换的 kubelet 客户端证书
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
自动证书续订
kubeadm 在控制平面升级期间更新所有证书。
此功能旨在解决最简单的用例;如果你对证书续订没有特定要求,并且定期执行 Kubernetes 版本升级(每次升级之间不到 1 年),kubeadm 将负责使你的集群保持最新且合理安全。
如果你对证书续订有更复杂的要求,你可以通过将 `--certificate-renewal=false` 传递给 `kubeadm upgrade apply` 或 `kubeadm upgrade node` 来选择退出默认行为。
手动证书续订
你可以随时使用 `kubeadm certs renew` 命令以及适当的命令行选项手动更新你的证书。如果你正在运行具有复制的控制平面的集群,则需要在所有控制平面节点上执行此命令。
此命令使用存储在 `/etc/kubernetes/pki` 中的 CA(或 front-proxy-CA)证书和密钥执行续订。
`kubeadm certs renew` 使用现有证书作为属性(通用名称、组织、主题备用名称)的权威来源,而不依赖于 `kubeadm-config` ConfigMap。即便如此,Kubernetes 项目建议保持服务的证书和该 ConfigMap 中的关联值同步,以避免任何混淆风险。
运行命令后,您应该重启控制平面 Pod。这是必需的,因为目前并非所有组件和证书都支持动态证书重载。 静态 Pod 由本地 kubelet 管理,而不是由 API Server 管理,因此无法使用 kubectl 删除和重启它们。要重启静态 Pod,您可以暂时将其清单文件从 /etc/kubernetes/manifests/
中移除,并等待 20 秒(请参阅 KubeletConfiguration 结构体 中的 fileCheckFrequency
值)。如果 Pod 不再位于清单目录中,kubelet 将终止该 Pod。然后,您可以将文件移回,并在另一个 fileCheckFrequency
周期后,kubelet 将重新创建该 Pod,并且组件的证书续订可以完成。
kubeadm certs renew
可以续订任何特定的证书,或者使用子命令 all
,它可以续订所有证书。
# If you are running cluster with a replicated control plane, this command
# needs to be executed on all the control-plane nodes.
kubeadm certs renew all
复制管理员证书(可选)
使用 kubeadm 构建的集群通常会将 admin.conf
证书复制到 $HOME/.kube/config
中,如 使用 kubeadm 创建集群 中所述。在此类系统上,要在续订 admin.conf
后更新 $HOME/.kube/config
的内容,您可以运行以下命令
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
使用 Kubernetes 证书 API 续订证书
本节提供了有关如何使用 Kubernetes 证书 API 执行手动证书续订的更多详细信息。
注意
这些是针对需要将其组织证书基础设施集成到 kubeadm 构建的集群中的高级用户的主题。如果默认的 kubeadm 配置满足您的需求,您应该让 kubeadm 管理证书。设置签名者
Kubernetes 证书颁发机构 (CA) 不开箱即用。您可以配置外部签名者,例如 cert-manager,或者您可以使用内置签名者。
内置签名者是 kube-controller-manager
的一部分。
要激活内置签名者,您必须传递 --cluster-signing-cert-file
和 --cluster-signing-key-file
标志。
如果您正在创建一个新的集群,您可以使用 kubeadm 配置文件
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
extraArgs:
- name: "cluster-signing-cert-file"
value: "/etc/kubernetes/pki/ca.crt"
- name: "cluster-signing-key-file"
value: "/etc/kubernetes/pki/ca.key"
创建证书签名请求 (CSR)
有关使用 Kubernetes API 创建 CSR 的信息,请参阅 创建 CertificateSigningRequest。
使用外部 CA 续订证书
本节提供了有关如何使用外部 CA 执行手动证书续订的更多详细信息。
为了更好地与外部 CA 集成,kubeadm 还可以生成证书签名请求 (CSR)。CSR 表示向 CA 请求用于客户端的签名证书。在 kubeadm 术语中,通常由磁盘 CA 签名的任何证书都可以改为生成为 CSR。但是,CA 不能生成为 CSR。
通过使用证书签名请求 (CSR) 进行续订
可以通过生成新的 CSR 并使用外部 CA 对其进行签名来续订证书。有关使用 kubeadm 生成的 CSR 的更多详细信息,请参阅签名 kubeadm 生成的证书签名请求 (CSR)部分。
证书颁发机构 (CA) 轮换
Kubeadm 不支持开箱即用的 CA 证书轮换或替换。
有关手动轮换或替换 CA 的更多信息,请参阅手动轮换 CA 证书。
启用已签名的 kubelet 服务证书
默认情况下,kubeadm 部署的 kubelet 服务证书是自签名的。这意味着来自外部服务(例如 metrics-server)到 kubelet 的连接无法使用 TLS 进行保护。
要在新的 kubeadm 集群中配置 kubelet 以获取正确签名的服务证书,您必须将以下最小配置传递给 kubeadm init
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true
如果您已经创建了集群,您必须通过执行以下操作进行适配
- 在
kube-system
命名空间中查找并编辑kubelet-config-1.32
ConfigMap。在该 ConfigMap 中,kubelet
键具有一个 KubeletConfiguration 文档作为其值。编辑 KubeletConfiguration 文档以设置serverTLSBootstrap: true
。 - 在每个节点上,在
/var/lib/kubelet/config.yaml
中添加serverTLSBootstrap: true
字段,并使用systemctl restart kubelet
重启 kubelet
字段 serverTLSBootstrap: true
将通过从 certificates.k8s.io
API 请求它们来启用 kubelet 服务证书的引导。一个已知的限制是,这些证书的 CSR(证书签名请求)无法由 kube-controller-manager 中的默认签名者自动批准 - kubernetes.io/kubelet-serving
。这将需要用户或第三方控制器的操作。
可以使用以下命令查看这些 CSR
kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending
csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending
要批准它们,您可以执行以下操作
kubectl certificate approve <CSR-name>
默认情况下,这些服务证书将在一年后过期。Kubeadm 将 KubeletConfiguration
字段 rotateCertificates
设置为 true
,这意味着在接近过期时,将创建一组新的服务证书 CSR,并且必须批准它们才能完成轮换。要了解更多信息,请参阅证书轮换。
如果您正在寻找自动批准这些 CSR 的解决方案,建议您联系您的云提供商,并询问他们是否具有使用带外机制验证节点身份的 CSR 签名者。
可以使用第三方自定义控制器
除非它不仅验证 CSR 中的 CommonName,还验证请求的 IP 和域名,否则此类控制器不是安全的机制。这将阻止有权访问 kubelet 客户端证书的恶意行为者创建请求任何 IP 或域名的服务证书的 CSR。
为其他用户生成 kubeconfig 文件
在集群创建期间,kubeadm init
会对 super-admin.conf
中的证书进行签名,使其具有 Subject: O = system:masters, CN = kubernetes-super-admin
。 system:masters
是一个应急的超级用户组,它绕过授权层(例如,RBAC)。admin.conf
文件也是由 kubeadm 在控制平面节点上创建的,它包含一个具有 Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin
的证书。kubeadm:cluster-admins
是一个逻辑上属于 kubeadm 的组。如果您的集群使用 RBAC(kubeadm 默认设置),则 kubeadm:cluster-admins
组绑定到 cluster-admin
ClusterRole。
警告
避免共享super-admin.conf
或 admin.conf
文件。相反,即使对于作为管理员工作的人员,也应创建最小权限访问,并将此最小权限替代方案用于紧急访问以外的任何其他用途。您可以使用 kubeadm kubeconfig user
命令为其他用户生成 kubeconfig 文件。该命令接受命令行标志和 kubeadm 配置选项的混合。生成的 kubeconfig 将写入 stdout,并可以使用 kubeadm kubeconfig user ... > somefile.conf
管道传输到文件。
可与 --config
一起使用的示例配置文件
# example.yaml
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
# Will be used as the target "cluster" in the kubeconfig
clusterName: "kubernetes"
# Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig
controlPlaneEndpoint: "some-dns-address:6443"
# The cluster CA key and certificate will be loaded from this local directory
certificatesDir: "/etc/kubernetes/pki"
确保这些设置与所需的目标集群设置匹配。要查看现有集群的设置,请使用
kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"
以下示例将为一个新用户 johndoe
生成一个有效期为 24 小时的 kubeconfig 文件,该用户是 appdevs
组的成员
kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h
以下示例将生成一个有效期为 1 周的管理员凭据的 kubeconfig 文件
kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h
签名 kubeadm 生成的证书签名请求 (CSR)
您可以使用 kubeadm certs generate-csr
创建证书签名请求。调用此命令将为常规证书生成 .csr
/ .key
文件对。对于嵌入在 kubeconfig 文件中的证书,该命令将生成一个 .csr
/ .conf
对,其中密钥已嵌入到 .conf
文件中。
CSR 文件包含 CA 签名证书的所有相关信息。kubeadm 对其所有证书和 CSR 使用定义完善的规范。
默认的证书目录是 /etc/kubernetes/pki
,而 kubeconfig 文件的默认目录是 /etc/kubernetes
。这些默认值可以使用 --cert-dir
和 --kubeconfig-dir
标志分别覆盖。
要将自定义选项传递给 kubeadm certs generate-csr
,请使用 --config
标志,该标志接受 kubeadm 配置文件,类似于 kubeadm init
等命令。任何规范(例如额外的 SAN 和自定义 IP 地址)都必须存储在同一配置文件中,并通过将其作为 --config
传递给所有相关的 kubeadm 命令。
注意
本指南使用默认的 Kubernetes 目录 /etc/kubernetes
,这需要超级用户。如果您正在遵循本指南并使用您可以写入的目录(通常,这意味着使用 --cert-dir
和 --kubeconfig-dir
运行 kubeadm
),则可以省略 sudo
命令)。
然后,您必须将生成的文件复制到 /etc/kubernetes
目录中,以便 kubeadm init
或 kubeadm join
可以找到它们。
准备 CA 和服务帐户文件
在将执行 kubeadm init
的主控制平面节点上,调用以下命令
sudo kubeadm init phase certs ca
sudo kubeadm init phase certs etcd-ca
sudo kubeadm init phase certs front-proxy-ca
sudo kubeadm init phase certs sa
这将使用 kubeadm 需要的用于控制平面节点的所有自签名 CA 文件(证书和密钥)和服务帐户(公钥和私钥)填充文件夹 /etc/kubernetes/pki
和 /etc/kubernetes/pki/etcd
。
注意
如果您正在使用外部 CA,则必须带外生成相同的文件,并手动将其复制到 /etc/kubernetes
中的主控制平面节点。
一旦所有 CSR 都已签名,您可以删除根 CA 密钥(ca.key
),如外部 CA 模式部分所述。
对于辅助控制平面节点(kubeadm join --control-plane
),无需调用上述命令。根据您如何设置高可用性集群,您必须手动从主控制平面节点复制相同的文件,或者使用 kubeadm init
的自动 --upload-certs
功能。
生成 CSR
kubeadm certs generate-csr
命令为 kubeadm 管理的所有已知证书生成 CSR。命令完成后,您必须手动删除您不需要的 .csr
、.conf
或 .key
文件。
kubelet.conf 的注意事项
本节适用于控制平面节点和工作节点。
如果您已从控制平面节点中删除 ca.key
文件(外部 CA 模式),则此集群中的活动 kube-controller-manager 将无法签名 kubelet 客户端证书。如果您的设置中不存在签名这些证书的外部方法(例如外部签名者),您可以按照本指南中的说明手动签名 kubelet.conf.csr
。
请注意,这也意味着自动kubelet客户端证书轮换将被禁用。如果是这样,在证书即将过期时,您必须生成新的 kubelet.conf.csr
,签署证书,将其嵌入到 kubelet.conf
中,并重启 kubelet。
如果这不适用于您的设置,您可以跳过在辅助控制平面和工作节点(所有调用 kubeadm join ...
的节点)上处理 kubelet.conf.csr
的步骤。这是因为活动的 kube-controller-manager 将负责签署新的 kubelet 客户端证书。
注意
您必须在主控制平面节点(最初运行kubeadm init
的主机)上处理 kubelet.conf.csr
文件。这是因为 kubeadm
将其视为引导集群的节点,因此需要预先填充的 kubelet.conf
。控制平面节点
在主(kubeadm init
)和辅助(kubeadm join --control-plane
)控制平面节点上执行以下命令以生成所有 CSR 文件
sudo kubeadm certs generate-csr
如果要使用外部 etcd,请遵循使用 kubeadm 的外部 etcd 指南,以了解在 kubeadm 和 etcd 节点上需要哪些 CSR 文件。可以删除 /etc/kubernetes/pki/etcd
下的其他 .csr
和 .key
文件。
根据 kubelet.conf 的注意事项中的说明,保留或删除 kubelet.conf
和 kubelet.conf.csr
文件。
工作节点
根据 kubelet.conf 的注意事项中的说明,可以选择调用
sudo kubeadm certs generate-csr
并仅保留 kubelet.conf
和 kubelet.conf.csr
文件。或者,完全跳过工作节点的步骤。
为所有证书签署 CSR
注意
如果您正在使用外部 CA,并且已经拥有用于 openssl
的 CA 序列号文件 (.srl
),您可以将这些文件复制到将要处理 CSR 的 kubeadm 节点。要复制的 .srl
文件是 /etc/kubernetes/pki/ca.srl
、/etc/kubernetes/pki/front-proxy-ca.srl
和 /etc/kubernetes/pki/etcd/ca.srl
。然后,可以将这些文件移动到将要处理 CSR 文件的新节点。
如果节点上某个 CA 缺少 .srl
文件,下面的脚本将生成一个新的 SRL 文件,其中包含一个随机的起始序列号。
要了解更多关于 .srl
文件的信息,请参阅 openssl
文档中关于 --CAserial
标志的说明。
对所有包含 CSR 文件的节点重复此步骤。
在 /etc/kubernetes
目录中编写以下脚本,导航到该目录并执行该脚本。该脚本将为 /etc/kubernetes
树中存在的所有 CSR 文件生成证书。
#!/bin/bash
# Set certificate expiration time in days
DAYS=365
# Process all CSR files except those for front-proxy and etcd
find ./ -name "*.csr" | grep -v "pki/etcd" | grep -v "front-proxy" | while read -r FILE;
do
echo "* Processing ${FILE} ..."
FILE=${FILE%.*} # Trim the extension
if [ -f "./pki/ca.srl" ]; then
SERIAL_FLAG="-CAserial ./pki/ca.srl"
else
SERIAL_FLAG="-CAcreateserial"
fi
openssl x509 -req -days "${DAYS}" -CA ./pki/ca.crt -CAkey ./pki/ca.key ${SERIAL_FLAG} \
-in "${FILE}.csr" -out "${FILE}.crt"
sleep 2
done
# Process all etcd CSRs
find ./pki/etcd -name "*.csr" | while read -r FILE;
do
echo "* Processing ${FILE} ..."
FILE=${FILE%.*} # Trim the extension
if [ -f "./pki/etcd/ca.srl" ]; then
SERIAL_FLAG=-CAserial ./pki/etcd/ca.srl
else
SERIAL_FLAG=-CAcreateserial
fi
openssl x509 -req -days "${DAYS}" -CA ./pki/etcd/ca.crt -CAkey ./pki/etcd/ca.key ${SERIAL_FLAG} \
-in "${FILE}.csr" -out "${FILE}.crt"
done
# Process front-proxy CSRs
echo "* Processing ./pki/front-proxy-client.csr ..."
openssl x509 -req -days "${DAYS}" -CA ./pki/front-proxy-ca.crt -CAkey ./pki/front-proxy-ca.key -CAcreateserial \
-in ./pki/front-proxy-client.csr -out ./pki/front-proxy-client.crt
将证书嵌入到 kubeconfig 文件中
对所有包含 CSR 文件的节点重复此步骤。
在 /etc/kubernetes
目录中编写以下脚本,导航到该目录并执行该脚本。该脚本将获取上一步中为 kubeconfig 文件从 CSR 签署的 .crt
文件,并将其嵌入到 kubeconfig 文件中。
#!/bin/bash
CLUSTER=kubernetes
find ./ -name "*.conf" | while read -r FILE;
do
echo "* Processing ${FILE} ..."
KUBECONFIG="${FILE}" kubectl config set-cluster "${CLUSTER}" --certificate-authority ./pki/ca.crt --embed-certs
USER=$(KUBECONFIG="${FILE}" kubectl config view -o jsonpath='{.users[0].name}')
KUBECONFIG="${FILE}" kubectl config set-credentials "${USER}" --client-certificate "${FILE}.crt" --embed-certs
done
执行清理
在所有包含 CSR 文件的节点上执行此步骤。
在 /etc/kubernetes
目录中编写以下脚本,导航到该目录并执行该脚本。
#!/bin/bash
# Cleanup CSR files
rm -f ./*.csr ./pki/*.csr ./pki/etcd/*.csr # Clean all CSR files
# Cleanup CRT files that were already embedded in kubeconfig files
rm -f ./*.crt
(可选)将 .srl
文件移动到下一个要处理的节点。
(可选)如果使用外部 CA,请删除 /etc/kubernetes/pki/ca.key
文件,如 外部 CA 节点 部分所述。
kubeadm 节点初始化
在 CSR 文件已签名,并且所需证书已在要用作节点的 hosts 上就位后,您可以使用命令 kubeadm init
和 kubeadm join
从这些节点创建 Kubernetes 集群。在 init
和 join
期间,kubeadm 使用它在主机本地文件系统的 /etc/kubernetes
树中找到的现有证书、加密密钥和 kubeconfig 文件。
此页面上的项目引用了第三方产品或项目,它们提供了 Kubernetes 所需的功能。Kubernetes 项目的作者不对这些第三方产品或项目负责。有关更多详细信息,请参阅 CNCF 网站指南。
在提出添加额外的第三方链接的更改之前,您应该阅读内容指南。