2. 环境准备：多集群 Kubernetes 环境搭建要求、kubeconfig 配置、集群连通性验证
跨集群调度的前提是拥有两个或更多可互相通信的 Kubernetes 集群。本章将明确环境搭建的最低要求、kubeconfig 文件的合并与隔离策略，以及验证集群间连通性的标准方法。
2.1 多集群环境搭建要求
为满足跨集群调度与版本漂移校准的实验需求，建议按以下规格准备集群环境：
| 集群角色 | Kubernetes 版本 | 节点数 | 容器运行时 | 网络插件 | 备注 |
|---|---|---|---|---|---|
| Cluster-A（主集群） | v1.28.x | 3（1 master + 2 worker） | containerd 1.7.x | Calico v3.27 | 运行调度器与 Deployment 源 |
| Cluster-B（目标集群） | v1.28.x | 3（1 master + 2 worker） | containerd 1.7.x | Calico v3.27 | 接收跨集群调度的 Pod |
| Cluster-C（备用集群） | v1.27.x | 2（1 master + 1 worker） | containerd 1.6.x | Flannel v0.24 | 用于版本差异场景测试 |
版本一致性建议： 主集群与目标集群的 Kubernetes 小版本差异应控制在 ±1 以内，避免因 API 版本不兼容导致调度失败。备用集群可故意使用低一个版本，用于验证版本漂移校准逻辑。
2.2 kubeconfig 配置策略
跨集群操作依赖 kubeconfig 文件管理多个集群的访问凭据。推荐采用 合并式配置 与 上下文切换 的方式，而非维护多个独立文件。
2.2.1 合并 kubeconfig
将三个集群的 kubeconfig 合并到单一文件 ~/.kube/config 中：
# 备份原有配置
cp ~/.kube/config ~/.kube/config.bak
# 合并 Cluster-B 配置
KUBECONFIG=~/.kube/config:/path/to/cluster-b-config.yaml \
kubectl config view --flatten > ~/.kube/config-new
# 合并 Cluster-C 配置
KUBECONFIG=~/.kube/config-new:/path/to/cluster-c-config.yaml \
kubectl config view --flatten > ~/.kube/config
# 清理临时文件
rm ~/.kube/config-new2.2.2 上下文命名规范
合并后需为每个集群设置清晰的上下文名称：
| 集群 | 上下文名称 | kubectl 切换命令 |
|---|---|---|
| Cluster-A | ctx-cluster-a |
kubectl config use-context ctx-cluster-a |
| Cluster-B | ctx-cluster-b |
kubectl config use-context ctx-cluster-b |
| Cluster-C | ctx-cluster-c |
kubectl config use-context ctx-cluster-c |
验证当前上下文： 执行
kubectl config current-context 确认当前操作的集群，避免误操作。
2.3 集群连通性验证
在开始跨集群调度之前，必须验证集群间的网络连通性与 API Server 可达性。以下为验证步骤与预期结果。
2.3.1 验证步骤
- API Server 连通性测试：从 Cluster-A 的 master 节点 curl Cluster-B 的 API Server 端点。
- Pod 网络互通测试：在 Cluster-A 中创建测试 Pod，尝试 ping Cluster-B 中 Pod 的 IP。
- kubeconfig 上下文切换测试：使用 kubectl 切换上下文并获取节点列表。
- Service 跨集群访问测试：通过 Cluster-A 中的 Pod 访问 Cluster-B 的 Service ClusterIP。
2.3.2 验证命令与预期输出
# 步骤1：API Server 连通性
curl -k https://<cluster-b-api-server>:6443/healthz
# 预期输出：ok
# 步骤2：Pod 网络互通
kubectl --context ctx-cluster-a run test-pod --image=busybox -- sleep 3600
kubectl --context ctx-cluster-a exec test-pod -- ping -c 3 <cluster-b-pod-ip>
# 预期输出：3 packets transmitted, 3 received, 0% packet loss
# 步骤3：上下文切换
kubectl config use-context ctx-cluster-b
kubectl get nodes
# 预期输出：显示 Cluster-B 的节点列表
# 步骤4：Service 跨集群访问
kubectl --context ctx-cluster-a run curl-pod --image=curlimages/curl -- sleep 3600
kubectl --context ctx-cluster-a exec curl-pod -- curl http://<cluster-b-service-ip>:<port>
# 预期输出：返回 Service 的响应内容
常见连通性故障： 如果 Pod 网络互通失败，请检查集群间防火墙规则、Calico/Flannel 的跨集群 BGP 配置或隧道模式（如 VXLAN/IPIP）是否启用。跨集群 Service 访问通常需要额外配置 CoreDNS 或使用 ExternalName Service。
2.4 多集群网络拓扑示意
下图展示了三个集群之间的网络连接关系与验证路径：
2.5 环境验证清单
完成上述配置与验证后，请逐项确认以下清单：
- kubeconfig 合并：三个集群的上下文均存在于
~/.kube/config中，且无重复条目。 - 上下文切换：
kubectl config get-contexts输出三个上下文，状态均为正常。 - API Server 健康：每个集群的
/healthz端点返回ok。 - Pod 网络互通：跨集群 Pod 间 ping 成功率 100%，延迟 < 10ms。
- kubectl 权限：当前用户在每个集群中至少拥有
cluster-admin或等效的跨命名空间操作权限。 - 存储与镜像：目标集群已预拉取实验所需的镜像（如
nginx:1.25、busybox），或配置了可访问的镜像仓库。