K8s 运维系列 | 第 12 天：证书与多集群——kubeconfig 与集群切换

在生产环境里，运维人员很少只面对一个 Kubernetes 集群。开发、测试、预发、生产，再加上不同机房或云厂商的集群，少则两三个，多则十几个。面对这么多集群，如何安全地保存访问凭证、如何在它们之间快速切换、如何理解背后那套证书体系，就成了每一个 K8s 运维工程师的必修课。本篇我们就围绕「证书与多集群」展开，把 kubeconfig 的来龙去脉、证书签发机制以及集群切换的最佳实践一次讲透。

为什么需要 kubeconfig

当我们执行 kubectl get pods 时，kubectl 首先要解决两个问题：第一，我要连的是哪个集群（API Server 地址在哪）；第二，我以什么身份去连（用什么证书、Token 或用户名密码）。这些信息的载体，就是 kubeconfig 文件。

默认情况下，kubectl 会读取 $HOME/.kube/config 这个文件。它的本质是一个 YAML 文件，里面包含三类核心要素：

clusters：集群列表，每个集群记录了 API Server 地址、CA 证书数据或路径；
users：用户列表，每个用户记录了客户端证书、私钥，或 Token、用户名密码等凭证；
contexts：上下文列表，把「某个集群」和「某个用户」绑定在一起，还可以附带命名空间，代表一次完整的访问组合。

下面是一个典型的 kubeconfig 结构示例：

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTi...
    server: https://10.0.0.10:6443
  name: prod-cluster
users:
- name: prod-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTi...
    client-key-data: LS0tLS1CRUdJTi...
contexts:
- context:
    cluster: prod-cluster
    user: prod-admin
    namespace: default
  name: prod
current-context: prod

深入理解集群证书体系

kubeconfig 背后牵涉到一整套证书。Kubernetes 集群几乎所有的组件通信都依赖 TLS，理解证书签发链路是排查「x509: certificate signed by unknown authority」这类报错的基础。

集群侧的 CA 与组件证书

用 kubeadm 部署的集群，证书统一存放在 Master 节点的 /etc/kubernetes/pki/ 目录下：

ls -l /etc/kubernetes/pki/
# ca.crt / ca.key                集群根证书与私钥
# apiserver.crt / apiserver.key  API Server 服务端证书
# front-proxy-ca.crt             front-proxy 代理证书
# sa.pub / sa.key                ServiceAccount 签名密钥

这里的 ca.crt 就是整个集群的信任锚点，它签发了 apiserver、kubelet、etcd 等所有内部组件证书。kubeconfig 中的 certificate-authority-data 正是 ca.crt 的 base64 编码，客户端用它来校验 API Server 的身份。

查看证书有效期

证书过期是生产环境的高频故障。可以通过 openssl 直接解析证书内容：

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
# notBefore=...
# notAfter=...

也可以用 kubeadm 自带的命令统一检查：

kubeadm certs check-expiration

如果发现证书即将过期，kubeadm 提供了续期命令 kubeadm certs renew all，执行后记得重启 kube-apiserver、kube-controller-manager、kube-scheduler 等相关组件让新证书生效。

多集群切换的三种方式

方式一：kubectl config 命令族

如果所有集群信息都合并在同一个 kubeconfig 文件里，切换集群其实就是切换 context：

# 查看所有上下文
kubectl config get-contexts

# 切换到指定上下文
kubectl config use-context prod

# 查看当前上下文
kubectl config current-context

方式二：KUBECONFIG 环境变量

当多个集群的 kubeconfig 分散在不同文件时，可以用 KUBECONFIG 环境变量把它们合并起来：

export KUBECONFIG=~/.kube/config-dev:~/.kube/config-staging:~/.kube/config-prod
kubectl config view --flatten > ~/.kube/config-merged

这样一条命令就能同时管理三个集群，--flatten 会输出合并后的完整配置，方便备份或分发给团队成员。

方式三：临时指定 –kubeconfig

对于偶尔访问的集群，直接在命令里指定文件最省事：

kubectl --kubeconfig ~/.kube/config-prod get nodes

实战：用 context 管理多集群

下面演示一个完整的场景：把新加入的生产集群 kubeconfig 合并到本地，并规范命名。假设新集群凭证文件为 /tmp/prod.yaml：

# 1. 合并到现有配置
export KUBECONFIG=~/.kube/config:/tmp/prod.yaml
kubectl config view --flatten > ~/.kube/config.new
mv ~/.kube/config.new ~/.kube/config

# 2. 给 context 起一个语义化名字，方便记忆
kubectl config rename-context kubernetes-admin@prod prod

# 3. 切换并验证
kubectl config use-context prod
kubectl cluster-info

常见问题：证书不匹配报错

切换到新集群后，最常见的报错就是证书信任问题：

Unable to connect to the server: x509: certificate signed by unknown authority

原因通常是 kubeconfig 里缺少 CA 证书，或者 CA 数据与实际集群不一致。解决办法是确认 certificate-authority-data 指向正确的集群 CA，必要时用 --insecure-skip-tls-verify: true 临时排查，但严禁在生产环境长期使用该参数。

另一个高频问题是客户端证书过期或与用户名不匹配，报错类似 x509: certificate has expired。此时需要重新签发用户证书，并把新的证书与私钥更新到 kubeconfig 对应 user 下。

多集群管理的最佳实践

统一命名规范：context 名称建议包含环境信息，例如 prod-shanghai、staging-beijing，一眼就能看出集群归属。
权限最小化：不同环境使用不同的 user 凭证，生产集群只给必要权限，避免一把 root 证书打天下。
定期轮换证书：把证书有效期纳入监控，提前告警，避免到期当天手忙脚乱。
版本化管理 kubeconfig：团队内通过密钥管理系统分发凭证，不要把含私钥的 kubeconfig 提交到 Git 仓库。
借助工具：规模再大一些，可以引入 kubectx / kubens 这类工具，以及 Rancher、Lens 等图形化管理平台，降低误操作风险。