企业官网建设流程全解析

1. 问题背景与核心需求

当Rancher管理平台出现故障无法恢复时，下游Kubernetes集群的管理会面临一个棘手问题：如何获取集群的kubeconfig配置文件。这个文件是访问和管理Kubernetes集群的关键凭证，通常由Rancher统一生成和管理。在Rancher不可用的情况下，我们需要通过其他途径获取这个关键文件。

重要提示：kubeconfig文件包含集群的CA证书、API Server地址和用户认证信息，相当于集群的"钥匙串"，必须妥善保管。

2. 常规获取方式与故障场景分析

2.1 Rancher正常情况下的kubeconfig获取

在Rancher正常工作时，获取kubeconfig的标准流程是：

1. 登录Rancher UI
2. 进入"集群管理"页面
3. 找到目标集群，点击右侧菜单按钮
4. 选择"下载KubeConfig"
5. 将文件保存为~/.kube/config或通过--kubeconfig参数指定路径

2.2 Rancher故障时的受限场景

当Rancher出现以下故障时，上述方法将失效：

• Rancher服务完全不可用
• 数据库损坏导致集群信息丢失
• 认证服务故障无法生成新凭证
• 网络隔离导致无法连接Rancher Server

3. 应急解决方案：从下游集群直接获取配置

3.1 通过控制节点直接获取

如果能够SSH登录到集群的控制节点（controlplane节点），可以执行以下步骤：

# 查看kubeconfig路径（通常为/etc/kubernetes/admin.conf） sudo find /etc/kubernetes -name "*.conf" # 复制配置文件到本地 sudo cp /etc/kubernetes/admin.conf ~/kubeconfig-backup.conf # 修改文件权限 sudo chown $(id -u):$(id -g) ~/kubeconfig-backup.conf # 验证配置有效性 kubectl --kubeconfig=~/kubeconfig-backup.conf get nodes

3.2 使用kubectl命令生成配置

如果能够通过其他方式访问集群（如已有有效凭证），可以使用kubectl生成新配置：

# 获取当前上下文 kubectl config current-context # 查看现有配置 kubectl config view --raw > kubeconfig-backup.yaml # 创建新用户凭证（需集群管理员权限） kubectl create serviceaccount emergency-admin -n kube-system kubectl create clusterrolebinding emergency-admin --clusterrole=cluster-admin --serviceaccount=kube-system:emergency-admin # 获取新用户的token SECRET_NAME=$(kubectl get serviceaccount emergency-admin -n kube-system -o jsonpath='{.secrets[0].name}') TOKEN=$(kubectl get secret $SECRET_NAME -n kube-system -o jsonpath='{.data.token}' | base64 --decode) # 生成新的kubeconfig kubectl config set-credentials emergency-admin --token=$TOKEN kubectl config set-context emergency-context --cluster=$(kubectl config current-context) --user=emergency-admin kubectl config use-context emergency-context # 验证新配置 kubectl get nodes

4. 授权集群端点（ACE）方案

4.1 ACE工作原理

授权集群端点（Authorized Cluster Endpoint）是RKE2/K3s集群的内置功能，允许绕过Rancher直接访问下游集群。其核心组件包括：

• 内嵌的kube-apiserver
• 集成的认证代理
• 自动生成的直接访问上下文

4.2 启用和配置ACE

对于RKE2/K3s集群，需要在创建时或通过修改配置启用ACE：

# RKE2集群配置文件示例（/etc/rancher/rke2/config.yaml） apiVersion: rke2.io/v1 kind: Cluster spec: authorizedClusterEndpoint: enabled: true fqdn: "mycluster.example.com" port: 6443

4.3 使用ACE上下文访问

在已下载的kubeconfig中查找ACE上下文：

kubectl config get-contexts

输出示例：

CURRENT NAME CLUSTER * my-cluster my-cluster my-cluster-controlplane-1 my-cluster-controlplane-1

使用ACE上下文访问（不依赖Rancher）：

kubectl --context my-cluster-controlplane-1 get nodes

5. 常见问题排查与解决

5.1 证书验证失败

错误现象：

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

解决方案：

# 获取集群CA证书 kubectl get secret -n kube-system -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.crt # 在kubeconfig中更新CA证书 kubectl config set-cluster <cluster_name> --certificate-authority=ca.crt --server=https://<api_server>:6443

5.2 连接被拒绝

错误现象：

Unable to connect to the server: dial tcp <IP>:6443: connect: connection refused

检查步骤：

1. 确认API Server服务状态：

   sudo systemctl status rke2-server (RKE2) 或 sudo systemctl status k3s (K3s)

2. 检查防火墙规则：

   sudo iptables -L -n | grep 6443

3. 验证网络连通性：

   telnet <API_SERVER_IP> 6443

5.3 权限不足

错误现象：

Error from server (Forbidden): nodes is forbidden: User "system:serviceaccount:kube-system:emergency-admin" cannot list resource "nodes" in API group "" at the cluster scope

解决方案：

# 检查现有权限 kubectl auth can-i --list # 添加必要权限 kubectl create clusterrole emergency-full-access --verb=* --resource=* kubectl create clusterrolebinding emergency-access-binding --clusterrole=emergency-full-access --serviceaccount=kube-system:emergency-admin

6. 预防措施与最佳实践

6.1 定期备份kubeconfig

建议将以下命令加入定期任务：

# 每周备份一次kubeconfig cp ~/.kube/config ~/.kube/backups/config_$(date +%Y%m%d) find ~/.kube/backups -name "config_*" -mtime +30 -delete

6.2 多因素认证配置

对于生产环境，建议：

1. 为直接访问配置客户端证书认证
2. 启用OIDC集成
3. 使用vault等工具管理敏感凭证

6.3 高可用架构设计

关键组件部署建议：

• Rancher Server采用3节点高可用部署
• 下游集群至少3个控制节点
• 为API Server配置负载均衡器
• 启用etcd定期快照

7. 恢复后的后续处理

当Rancher恢复后，建议执行以下操作：

# 将ACE上下文合并回主配置 KUBECONFIG=~/.kube/config:~/.kube/emergency.config kubectl config view --flatten > ~/.kube/merged.config mv ~/.kube/merged.config ~/.kube/config # 清理临时凭证 kubectl delete serviceaccount emergency-admin -n kube-system kubectl delete clusterrolebinding emergency-admin

在实际运维中，我强烈建议为关键集群配置至少两种独立的访问方式。曾经在一次数据中心网络隔离事故中，正是提前配置的ACE上下文让我们能够在Rancher不可用的情况下，仍然保持了集群的基本运维能力。