云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载本文聚焦 Chaos Mesh 多集群Multi-cluster能力中的核心枢纽 ——controllers/multicluster/clusterregistry包。它负责为每一个配置的远程集群启动一个独立的 controller-runtime manager并统一管理这些远程 Fx 应用的创建、查找与销毁。读完本文你将掌握RemoteClusterRegistry的Spawn/Stop/WithClient三操作语义、远程 Fx 应用的依赖注入模型、管理集群与远程集群双 Client 的区分方法以及如何在远程 manager 中注册新的 reconciler。一、clusterregistry 在多集群控制流中的位置Chaos Mesh 的多集群功能允许在管理集群management cluster上定义RemoteCluster资源由管理集群把 Chaos Mesh 安装到远程集群并在远程集群中运行混沌实验。这套流程由四个组件协作完成clusterregistry是其中掌管远程运行时Fx 应用、manager、client的唯一持有者remotecluster读取RemoteCluster资源通过 Helm 在远程集群安装或升级 Chaos Mesh并负责启动/停止远程 manager详见 controller.goremotechaos监听管理集群中remote-cluster字段非空的混沌对象在远程集群中创建或删除其副本详见 controller.goclusterregistry拥有远程 Fx 应用、manager 与 client即本主题核心实现在 registry.goremotechaosmonitor运行在每个远程 manager 内部把远程对象的状态status与 finalizer 镜像回管理集群对象详见 controller.go。一个关键的过滤规则管理集群本地的通用混沌 pipeline 会过滤掉remote-cluster字段非空的对象而复制到远程的副本对象会被清空该字段从而由远程集群自己的 Chaos Mesh 控制器正常执行。这一本地不执行、远端执行的职责切分是理解整个多集群数据流的主线。二、Registry 生命周期Spawn、Stop、WithClientRemoteClusterRegistry向外界暴露三个操作所有注册条目都以远程集群名称remote-cluster name为键操作签名语义SpawnSpawn(name string, restConfig *rest.Config) error启动一个远程 manager 并登记StopStop(ctx context.Context, name string) error停止该 manager 并从注册表中移除WithClientWithClient(name string, f func(client.Client) error) error以该 manager 的远程 client 执行一次回调错误语义与先停后建约束对已存在的名称调用Spawn返回ErrAlreadyExist不会替换正在运行的 manager定义见 error.go对未知名称调用Stop或WithClient返回ErrNotExist变更后的 REST 配置不会应用到已有条目需要替换时调用方必须先Stop旧 manager再Spawn新的。这些语义在源码中有直接体现。Spawn先加锁检查r.clusters[name]是否已存在存在即返回ErrAlreadyExistStop调用cluster.app.Stop(ctx)后再从 map 中deleteregistry.goWithClient则在加锁状态下直接执行回调f(cluster.Client)registry.go。registry 的装配与调用方registry 由controllers.Module通过clusterregistry.New提供见 controllers/fx.go构造时接收主 manager 的 logger 与 client。remoteclusterreconciler 是主要调用方其典型流程见 controller.go从RemoteCluster.Spec.KubeConfig.SecretRef指向的 Secret 中读取 kubeconfig加载为clientcmd.ClientConfig若RemoteCluster正在删除则调用registry.Stop容忍ErrNotExist、卸载远程 Helm release、清空chaos-mesh/remotecluster-controllersfinalizer否则先ensureHelmRelease不存在则安装、存在则升级release 名为chaos-mesh可用ConfigOverride覆盖 Chart values再ensureClusterControllerManager—— 调用registry.Spawn(obj.Name, restConfig)并容忍ErrAlreadyExistcontroller.go即已存在则视为成功。三、远程 Fx 应用一次独立的依赖注入组装Spawn为每个远程集群构造一个独立的 Fx 应用fx.New其提供的依赖包括远程*rest.Config来自 kubeconfig远程集群名称以name:cluster-name标记提供主 manager 的 client以name:manage-client标记提供用于回写管理集群包含全部已注册 Chaos Mesh 对象的 controller-runtime schemetypes.ChaosObjects面向远程集群配置的未命名 manager 与 client通过controllerManagerOption、provider.NewClient、provider.NewManager提供。从源码看远程 manager 的选项刻意做了精简registry.go关闭 metrics 服务BindAddress: 0关闭 leader electionLeaderElection: false不注册 admission webhook加载remotechaosmonitor.Module以监听远程混沌对象。Fx 生命周期通过run函数衔接run创建一个可取消的 context在 goroutine 中执行mgr.Start(executionCtx)并注册fx.Hook的OnStop—— 取消 context 并等待 manager 退出registry.go。因此app.Stop(ctx)会真正等待远程 manager 优雅停止而不是直接丢弃。四、Client 身份标识不要搞混两个集群在远程控制器的 Fx 模块内部依赖按名称区分集群身份依赖指向的集群未命名的client.Client该 manager 所监听的远程集群client.Clientname:manage-client主管理集群stringname:cluster-name远程集群在 registry 中的键以remotechaosmonitor为例其Params结构同时注入ManageClient client.Clientname:manage-client、ClusterName string name:cluster-name与未命名的LocalClient见 fx.goNew中分别保存为localClient管理集群与remoteClient远程集群。在Reconcile中monitor 从远程读取 finalizer 与 status再写入管理集群对象 —— 一旦两个 client 混淆就可能在错误的集群创建或删除资源。因此在 Fx 注解中务必显式区分这些身份。从管理集群 reconciler 访问远程集群管理集群的 reconciler 不应直接持有远程 client而是通过WithClient做一次短操作err : registry.WithClient(clusterName, func(remoteClient client.Client) error { return remoteClient.Get(ctx, key, object) })remotechaos的Reconcile正是这种模式的范例它先用管理集群 client 读取本地对象若本地对象正在删除且远程副本存在则删除远程副本若远程副本不存在且本地对象被删除则清空本地 finalizer 以放行删除否则清空副本的RemoteCluster字段、打上chaos-mesh.org/controlled-by: remote-chaos标签后在远程创建见 controller.go。重要限制WithClient当前在整个回调期间持有 registry 互斥锁。回调内不要执行长时任务也不要再调用Spawn、Stop或另一个WithClient否则会阻塞 registry 或造成死锁。五、注册一个新的远程 reconciler若要为每个远程 manager 增加一个控制器原文档给出了清晰的五步流程创建一个包内含提供 reconciler 并 invoke 其 bootstrap 的 Fx 模块以未命名 client接收远程集群操作能力仅在需要时请求命名管理 clientmanage-client或集群名cluster-name在RemoteClusterRegistry.Spawn的 Fx 应用中与remotechaosmonitor.Module并列加入该模块见 registry.go 处fx.Option的注册位置补充测试证明资源被读写到预期的那一个集群。参考范例是 remotechaosmonitor/fx.go —— 它展示了如何在远程 manager 内为每一类 Chaos 对象构建builder.Default(mgr).For(obj.Object).Named(...)的控制器并完成builder.Complete(...)。值得注意的是remotepodreconciler.Module虽然存在于代码树中见 fx.go但并未被纳入Spawn其Reconciler.Reconcile也仅是打印日志的空实现见 remote_pod_reconciler.go。因此它不是活跃远程控制器的示例恰恰说明模块必须在Spawn中显式加入才会生效。依赖不会自动继承如果新控制器需要 webhooks、metrics、leader election、no-cache 读取器或其他类型化 client必须在远程 Fx 应用中显式提供—— 远程 manager 默认关闭这些能力不会从主 manager 自动继承。当前远程应用只提供了 scheme、manager、client 与remotechaosmonitor.Module新增能力需要像controllerManagerOption那样有意识地补充。六、安全与关闭权限最小化RemoteCluster.Spec.KubeConfig.SecretRef引用的 kubeconfig结构定义见 remote_cluster_types.go必须同时授权管理控制器执行的 Helm 操作以及远程 reconciler 的所有读写/监听操作。应当只授予配置的功能实际需要的权限避免使用宽泛的管理员凭据。优雅关闭停止 registry 条目会取消远程 manager 的 context 并等待其退出。因此远程控制器代码必须尊重 reconcile context、避免无界操作否则Stop将一直阻塞。聚焦验证可用下面的命令对多集群相关包做集中测试go test ./controllers/multicluster/...七、小结clusterregistry是 Chaos Mesh 多集群能力的运行时中枢它以远程集群名为键用三个精确语义的操作Spawn/Stop/WithClient管理一组独立的远程 Fx 应用每个远程应用通过命名依赖manage-client、cluster-name与未命名依赖严格区分管理集群与远程集群的身份保证混沌对象的本地过滤、远端执行、状态回写闭环不会串集群。理解这份注册表的设计是扩展多集群控制器、排查远程混沌实验故障的起点。赞分享云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载相关推荐FBShimmeringView生命周期管理iOS视图控制器中的动画控制FBShimmeringView生命周期管理iOS视图控制器中的动画控制 你是否曾为iOS应用中的加载状态设计感到困扰用户等待内容加载时静态的空白界面往往UI组件移动开发pig-mesh/pig 注册控制器实现深度解析pig mesh/pig 注册控制器实现深度解析 引言 在企业级微服务架构中用户注册功能是系统的基础核心模块。pig mesh/pig 作为基于 Spring后端微服务认证鉴权API网关任务调度代码生成服务注册发现Chaos Mesh 公共 Finalizer 生命周期chaos-mesh/records 的初始化、清理与强制清理机制Chaos Mesh 公共 Finalizer 生命周期chaos mesh/records 的初始化、清理与强制清理机制 在 Chaos Mesh 中一个云原生运维测试可观测性上一篇ExpressWorks静态文件服务教程使用Express.js托管静态资源的正确方法下一篇如何高效配置MediaCrawler7大平台自媒体数据采集终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考