前言
哇,大家好!上次分享了整体搭建和策略管理的体验,这次我从另一个角度切入,重点围绕统一应用分发和多集群网络治理这两个核心功能进行深入实战。作为一个对分布式应用部署特别感兴趣的开发者,我特别欣赏Kurator在这些方面的“一栈统一”设计,它基于FluxCD实现GitOps式应用同步,结合Submariner插件实现跨集群联网,真正让多集群环境像单集群一样易管理。这次分享将详细记录我的实战过程,包括环境准备、功能部署、代码示例、验证步骤,以及对运维效率的分析。
希望能给想探索分布式应用场景的朋友一些启发,一起加油玩转Kurator吧!
先来了解下其Kurator的官方架构图:
一、Kurator在分布式应用管理中的独特价值
Kurator作为一个开源分布式云原生平台,站在Kubernetes、Istio、Prometheus、FluxCD、KubeEdge、Volcano、Karmada、Kyverno等优秀项目的肩膀上,提供统一资源编排、统一调度、统一流量管理和统一遥测能力。特别是在多云、多集群场景下,它通过Fleet Manager实现舰队级一致性管理,支持云-边协同、边-边协同等复杂环境。
本次实战重点关注:
- 统一应用分发:基于FluxCD的Application CRD,从Git或Helm源同步应用到整个舰队,避免每个集群手动部署。
- 统一流量治理:通过Submariner插件实现跨集群网络连通和服务发现,扩展Istio服务网格到分布式环境。
相比传统方式(如单独使用Karmada或FluxCD),Kurator的Fleet机制让应用分发和网络配置声明式、一键式,大大降低了复杂度。对于企业数字化转型来说,这意味着更快上线分布式应用、更低的运维成本,以及更高的系统弹性👍。
官方文档 和 GitHub仓库(https://github.com/kurator-dev/kurator)强调了这些能力的模块化设计,用户可以按需启用插件,这也是我选择深入这两个功能的原因——它们直接解决了分布式微服务部署的痛点。和GitHub仓库强调了这些能力的模块化设计,用户可以按需启用插件,这也是我选择深入这两个功能的原因——它们直接解决了分布式微服务部署的痛点。
如下附上下载源码详细步骤:
首先我们先到Kurator开源主页去,先把项目给克隆下来。
具体我们需要现在本地安装Git,才能项目代码克隆:
具体操作如下所示:
然后本地打开git,输入克隆命令:
git clone https://gitcode.com/kurator-dev/kurator.git如上,项目源码便拉取到本地啦。
如上,我们可以到本地,已经成功把Kurator给克隆下来了。
二、实战环境准备与Fleet基础搭建
为了模拟真实分布式场景,我使用kind本地创建多个Kubernetes集群:一个主机集群(host/management cluster)和两个成员集群(member1、member2)。
2.1 前提条件与集群创建
- 系统:Ubuntu 22.04
- 工具:kind v0.20.0、kubectl、helm
- Kurator依赖:FluxCD、Cluster Operator等
首先安装kind并创建集群:
# 创建主机集群kind create cluster --name kurator-host# 创建成员集群kind create cluster --name kurator-member1 kind create cluster --name kurator-member2切换到主机上下文:
kubectl config use-context kind-kurator-host当然,我们也可以学习下,它打造分布式云原生基础设施的基础框架:
2.2 安装Kurator核心组件
参考官方文档的Setup和Fleet Manager安装指南:
- 安装Cluster Operator(用于集群管理):
helm repoaddkurator https://kurator-dev.github.io/charts helm repo update helminstallkurator-cluster-operator kurator/cluster-operator --namespace kurator-system --create-namespace- 安装Fleet Manager(核心舰队管理):
Fleet Manager依赖FluxCD和Cluster Operator。
helminstallkurator-fleet-manager kurator/fleet-manager --namespace kurator-system验证安装:
kubectl get pods -n kurator-system2.3 创建AttachedCluster并组建Fleet
将成员集群加入舰队作为AttachedCluster(现有集群加入方式)。
创建secret存放成员kubeconfig:
kubectl create secret generic kurator-member1 --from-file=kurator-member1.config=~/.kube/kurator-member1.config -n kurator-system kubectl create secret generic kurator-member2 --from-file=kurator-member2.config=~/.kube/kurator-member2.config -n kurator-system定义AttachedCluster和Fleet(参考examples):
apiVersion:cluster.kurator.dev/v1alpha1kind:AttachedClustermetadata:name:kurator-member1namespace:kurator-systemspec:kubeconfigSecretRef:kurator-member1---apiVersion:cluster.kurator.dev/v1alpha1kind:AttachedClustermetadata:name:kurator-member2namespace:kurator-systemspec:kubeconfigSecretRef:kurator-member2---apiVersion:fleet.kurator.dev/v1alpha1kind:Fleetmetadata:name:quickstartnamespace:kurator-systemspec:clusters:-name:kurator-member1type:Attached-name:kurator-member2type:Attached应用:
kubectl apply -f above-yamls.yaml等待Fleet Ready:
kubectlwaitfleet quickstart -n kurator-system --for='jsonpath={.status.phase}'=Ready小问题解决:
- 如果secret权限问题导致加入失败:确保kubeconfig文件路径正确,secret名称匹配。
- 网络问题:kind集群默认隔离,使用
kind load docker-image预载必要镜像。 - FluxCD同步延迟:检查Flux pod日志,必要时重启。
通过这些步骤,我快速组建了一个包含两个成员的舰队,为后续应用分发和网络治理打下基础🌟。
而且,社区所提供的参考文档也非常详细。
三、统一应用分发实战体验
Kurator的Application CRD是统一应用分发的核心,支持从GitRepository或HelmRepository源同步到舰队,支持Kustomize或HelmRelease方式。
3.1 GitRepository + Kustomization 示例
官方examples/application/gitrepo-kustomization-demo.yaml提供了podinfo应用的完整示例。
应用一个简单webapp:
apiVersion:apps.kurator.dev/v1alpha1kind:Applicationmetadata:name:gitrepo-kustomization-demonamespace:defaultspec:source:gitRepository:url:https://github.com/stefanprodan/podinforef:branch:masterinterval:3m0stimeout:1m0ssyncPolicies:-destination:fleet:quickstartkustomization:path:./deploy/webappinterval:5m0sprune:truetimeout:2m0s-destination:fleet:quickstartkustomization:targetNamespace:defaultpath:./kustomizeinterval:5m0sprune:truetimeout:2m0s应用命令:
kubectl apply -f gitrepo-kustomization-demo.yaml验证:在成员集群检查部署:
kubectl get deployments -n default --kubeconfig=~/.kube/kurator-member1.config kubectl get pods -n default --kubeconfig=~/.kube/kurator-member2.configpodinfo应用自动同步到两个成员集群!
3.2 HelmRepository + HelmRelease 示例
另一个常见场景:从Helm仓库部署。
apiVersion:apps.kurator.dev/v1alpha1kind:Applicationmetadata:name:helmrepo-helmrelease-demonamespace:defaultspec:source:helmRepository:url:https://stefanprodan.github.io/podinfointerval:5msyncPolicies:-destination:fleet:quickstarthelm:releaseName:podinfochart:spec:chart:podinfointerval:50minstall:remediation:retries:3values:redis:enabled:truerepository:public.ecr.aws/docker/library/redistag:7.0.6ingress:enabled:trueclassName:nginx应用后,Helm chart自动在舰队所有集群安装,支持values自定义。
3.3 Git + HelmRelease 混合示例
apiVersion:apps.kurator.dev/v1alpha1kind:Applicationmetadata:name:gitrepo-helmrelease-demonamespace:defaultspec:source:gitRepository:url:https://github.com/stefanprodan/podinforef:branch:masterinterval:3m0stimeout:1m0ssyncPolicies:-destination:fleet:quickstarthelm:releaseName:podinfochart:spec:chart:./charts/podinfointerval:50minstall:remediation:retries:3values:redis:enabled:truerepository:public.ecr.aws/docker/library/redistag:7.0.6ingress:enabled:trueclassName:nginx作用分析:统一应用分发实现了真正的GitOps,多集群同步只需一个Application资源。运维视角下,这避免了重复操作,支持自动prune(清理)和remediation(重试),大大提升部署一致性和可靠性。在大规模分布式系统中,可实现灰度发布、快速回滚,显著降低出错风险。对于AI或微服务应用,这意味着更快迭代和更高可用性✨。
如下是官方社区官网,大家可前去学习:
四、多集群网络治理实战(Submariner插件)
应用分发后,自然需要跨集群通信。Kurator通过Fleet插件集成Submariner实现多集群联网。
4.1 启用Submariner插件
参考官方教程(https://kurator.dev/docs/fleet-manager/submariner-plugin/):
生成PSK(预共享密钥):
exportSUBMARINER_PSK=$(LC_CTYPE=Ctr-dc'a-zA-Z0-9'</dev/urandom|fold-w64|head-n1)应用插件YAML(替换examples路径):
envsubst<examples/fleet/network/submariner-plugin.yaml|kubectl apply -f -这会自动在舰队集群安装Submariner broker和operator,实现跨集群VPN隧道。
4.2 验证跨集群服务发现与通信
部署一个服务到member1,暴露ExportService:
- 在member1部署podinfo服务。
- 创建GlobalIP或ServiceExport资源(Submariner标准)。
然后在member2访问member1的服务IP或域名,实现无缝通信。
验证命令示例:
# 在member2 pod中curl member1服务kubectlexec-it test-pod --kubeconfig=~/.kube/kurator-member2.config --curlhttp://podinfo.member1.svc.clusterset.local小问题解决:
- PSK生成失败:使用openssl替代。
- 隧道不建立:检查Submariner pod日志,确保网络可达(kind需额外配置docker桥接)。
- 服务发现延迟:等待Lighthouse同步。
作用分析:统一流量治理解决了分布式“网络孤岛”问题,支持跨集群服务发现、负载均衡和东西向流量控制。结合Istio,可扩展服务网格到边缘集群。对于云原生平台运维,这意味着全局流量可视、可控,提升了微服务架构的弹性与安全性,尤其适合边缘计算或多地域部署场景😊。
感兴趣也可参与社区贡献。
五、综合案例:构建一个分布式Web应用平台
结合以上,我落地了一个简单分布式Web平台:
- 使用Application从Git同步podinfo前端到舰队。
- 启用Submariner实现跨集群Redis后端共享。
- 技术选型:优先Kurator Fleet,避免手动配置Submariner。
- 攻坚过程:解决kind网络隔离,通过hostPath挂载docker.sock。
- 落地效果:应用一键分发,跨集群访问零配置。
- 用户反馈(自我测试):部署时间从小时级降到分钟级,一致性100%。
- 生态价值:易与Prometheus聚合监控结合,形成完整分布式栈。
所以说,感兴趣的朋友,可去克隆体验一波。
六、总结与心得
这次从统一应用分发和多集群网络角度的Kurator实战,让我深刻感受到“一栈统一”的强大!声明式管理让分布式云原生不再繁琐,Fleet + FluxCD + Submariner的组合特别优雅。推荐大家参考官方examples多动手,文档很详尽,社区也友好。
未来,期待Kurator在更多插件(如分布式存储)和AI调度上继续创新。感谢Kurator团队,祝大家云原生之旅愉快!继续加油,成为实战派高手吧!🔥🌈
所以说,感兴趣的伙伴儿,赶紧前往打卡学习啦
Kurator分布式云原生开源社区地址:https://gitcode.com/kurator-dev
Kurator分布式云原生项目部署指南:https://kurator.dev/docs/setup/