笔记所对应活动链接:https://activity.csdn.net/writing?id=11040
在分布式云原生架构中,多集群应用分发一直是运维的核心痛点——不同集群的资源配置差异、应用版本不一致、分发流程繁琐等问题,往往导致运维效率低下且易出故障。Kurator作为一站式分布式云原生开源解决方案,基于Karmada等主流技术栈封装了统一应用分发能力,能实现跨集群应用的一键部署与生命周期管理。本文将从环境搭建、功能实战、问题排查三个维度,分享基于Kurator实现多集群应用分发的完整流程,为云原生运维人员提供可复用的实战指南。
Kurator的统一应用分发模块,本质是对Karmada应用分发能力的上层封装,其核心优势体现在三点:
本次实战模拟企业多集群运维场景:
# 下载并安装Karmada
curl -fsSL https://raw.githubusercontent.com/karmada-io/karmada/master/hack/local-up-karmada.sh | bash
# 配置Karmada集群上下文
export KUBECONFIG="$HOME/.kube/config:/etc/karmada/karmada-apiserver.config"
kubectl config use-context karmada-apiserver# 添加Kurator Helm仓库
helm repo add kurator https://kurator-dev.github.io/helm-charts/
helm repo update
# 安装Kurator核心组件
helm install kurator kurator/kurator --namespace kurator-system --create-namespace
# 验证安装结果
kubectl get pods -n kurator-system
# 预期输出:kurator-controller-manager等Pod状态为Running# 下载对应系统版本的kuratorctl(以Linux为例)
wget https://github.com/kurator-dev/kurator/releases/download/v0.5.0/kuratorctl-linux-amd64.tar.gz
tar -zxvf kuratorctl-linux-amd64.tar.gz
mv kuratorctl /usr/local/bin/
# 验证安装
kuratorctl version
# 预期输出:kuratorctl version v0.5.0# fleet.yaml
apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
name: demo-fleet
namespace: default
spec:
clusters:
- name: cluster-a # 生产集群名称
kubeconfig: |- # 生产集群kubeconfig内容(需base64解码后填入)
{{base64_decode "你的集群A kubeconfig base64编码"}}
- name: cluster-b # 测试集群名称
kubeconfig: |-
{{base64_decode "你的集群B kubeconfig base64编码"}}执行部署命令:
kubectl apply -f fleet.yaml
# 验证集群纳管状态
kuratorctl get fleet demo-fleet
# 预期输出:cluster-a与cluster-b状态为Ready# 通过kuratorctl查看集群列表
kuratorctl get clusters
# 在管理集群查看工作集群节点
kubectl --context karmada-apiserver get nodes --all-namespaces本次采用Helm Chart作为应用分发模板,先在管理集群创建Chart仓库并准备Nginx应用Chart:
# 初始化Nginx Chart
helm create nginx-demo修改nginx-demo/values.yaml,添加副本数配置项:
# values.yaml核心配置
replicaCount: 1 # 默认副本数
image:
repository: nginx
tag: 1.23-alpine
service:
type: NodePort
port: 80修改nginx-demo/templates/deployment.yaml,确保副本数引用配置项:
spec:
replicas: {{ .Values.replicaCount }}
# 其余配置省略# 打包Chart
helm package nginx-demo
# 安装Kurator ChartMuseum(内置Chart仓库)
helm install chartmuseum kurator/chartmuseum --namespace kurator-system
# 推送Chart到仓库
curl --data-binary "@nginx-demo-0.1.0.tgz" http://chartmuseum.kurator-system.svc.cluster.local:8080/api/charts通过Kurator的Application资源定义多集群分发策略,实现生产与测试集群的差异化配置:
# nginx-application.yaml
apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
name: nginx-app
namespace: default
spec:
# 指定分发的Fleet(即之前创建的demo-fleet)
fleet: demo-fleet
# 应用来源(Helm Chart)
source:
helm:
repo: http://chartmuseum.kurator-system.svc.cluster.local:8080
chart: nginx-demo
version: 0.1.0
# 多集群差异化配置
overrides:
- clusterName: cluster-a # 生产集群
values: |
replicaCount: 2 # 生产集群2副本
- clusterName: cluster-b # 测试集群
values: |
replicaCount: 1 # 测试集群1副本
# 分发策略
placement:
clusterAffinity:
clusterNames:
- cluster-a
- cluster-bkubectl apply -f nginx-application.yaml# 查看应用分发状态
kuratorctl get application nginx-app
# 查看Karmada分发的资源绑定状态
kubectl --context karmada-apiserver get resourcebindings# 验证生产集群(cluster-a)
kubectl --context cluster-a get pods -n default
# 预期输出:2个nginx pod,状态为Running
# 验证测试集群(cluster-b)
kubectl --context cluster-b get pods -n default
# 预期输出:1个nginx pod,状态为Running
# 验证服务可访问性
# 生产集群NodePort访问
curl http://<cluster-a-node-ip>:<node-port>
# 测试集群NodePort访问
curl http://<cluster-b-node-ip>:<node-port>
# 均应返回Nginx默认页面修改nginx-application.yaml的Chart版本与镜像配置:
spec:
source:
helm:
repo: http://chartmuseum.kurator-system.svc.cluster.local:8080
chart: nginx-demo
version: 0.1.1 # 升级后的Chart版本
overrides:
- clusterName: cluster-a
values: |
replicaCount: 2
image:
tag: 1.25-alpine # 升级镜像
- clusterName: cluster-b
values: |
replicaCount: 1
image:
tag: 1.25-alpine提交升级并验证:
kubectl apply -f nginx-application.yaml
# 验证升级后镜像版本
kubectl --context cluster-a describe pod <nginx-pod-name> | grep Image# 通过kuratorctl触发回滚
kuratorctl rollout undo application nginx-app --to-revision 1
# 验证回滚结果
kubectl --context cluster-b describe pod <nginx-pod-name> | grep Image
# 预期输出:镜像为1.23-alpineNotReady;cluster-admin角色;kubectl create clusterrolebinding admin-binding --clusterrole=cluster-admin --user=kubeconfig-userPending;kubectl describe pod查看事件,发现提示Insufficient CPU;overrides中添加资源限制:overrides:
- clusterName: cluster-b
values: |
replicaCount: 1
resources:
requests:
cpu: 100m # 降低CPU请求
memory: 128Mifailed to pull chart from repo;维度 | 原生Karmada | Kurator |
|---|---|---|
操作复杂度 | 需编写多个Karmada资源(如PropagationPolicy、OverridePolicy),配置繁琐 | 通过Application资源一键封装,配置简洁 |
模板支持 | 需手动集成Helm/Kustomize,无内置仓库 | 内置Chart仓库,支持模板化分发与差异化配置 |
运维体验 | 需切换多个命令行工具 | 统一通过kuratorctl管理,体验一致 |
Kurator分布式云原生开源社区地址: https://gitcode.com/kurator-dev Kurator分布式云原生项目部署指南: https://kurator.dev/docs/setup/