rc 控制器监控informer pod

Pod Informer通过Reflector Watch监听API Server上的Pod CRUD操作,并将Pod信息放入队列。独立的协程从队列中取出Pod信息并传递给监听者处理。RC控制器在初始化时注册为监听者,当Pod状态发生变化时,RC控制器会根据RC的设定参数调整副本数量。

pod是很多控制器都需要监听的资源,所以,pod的informer是一个share的

他通过reflector watch监听apiserver pod的crud,然后将pod传入queue中,一个协成不断从队列中pop 出pod,传递个listener处理,我们的rc控制器在初始化时会向pod informer中去挂载处理函数,注册listener,有pod更新,rc控制器就做相应处理。

rc控制器用pod获取其rc,根据rc创建时的参数,来更新rc,比如创建了pod,那么rc控制器就减一,表示原来期待建立4个副本,现在再建立3个就行了

### Kubernetes Pod Informer 使用指南 #### 创建 Pod Informer 实例 为了创建一个 `PodInformer`,通常会使用客户端库提供的工厂方法。这涉及到初始化一个新的共享索引通知器,并指定所需的资源类型,在这种情况下是 `v1.Pod`。 ```go import ( "k8s.io/client-go/informers" "k8s.io/client-go/tools/cache" ) factory := informers.NewSharedInformerFactory(clientset, time.Minute*30) podInformer := factory.Core().V1().Pods() ``` 此代码片段展示了如何设置一个针对核心 API 组下 v1 版本 Pods 资源的通知器实例[^1]。 #### 添加事件处理器 一旦有了 `PodInformer` 对象,就可以向其注册回调函数以响应不同类型的生命周期事件(新增、更新或删除)。这些处理器将在每次检测到变化时被调用: ```go podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { pod := obj.(*corev1.Pod) fmt.Printf("Added Pod %s\n", pod.Name) }, UpdateFunc: func(oldObj, newObj interface{}) { oldPod := oldObj.(*corev1.Pod) newPod := newObj.(*corev1.Pod) if oldPod.Status.Phase != newPod.Status.Phase { fmt.Printf("Updated Pod Phase from %s to %s\n", oldPod.Status.Phase, newPod.Status.Phase) } }, DeleteFunc: func(obj interface{}) { pod := obj.(*corev1.Pod) fmt.Printf("Deleted Pod %s\n", pod.Name) }, }) ``` 这段 Go 语言代码定义了一个简单的事件处理程序集合,用于打印有关已添加、修改或移除的 Pod 的信息。 #### 启动并同步 Informer 最后一步是在应用程序启动期间开始运行所有已配置的信息收集者,并等待它们完成初始列表/监视周期的数据填充过程: ```go stopCh := make(chan struct{}) defer close(stopCh) // Start all registered informers. factory.Start(stopCh) // Wait for the initial synchronization of the local cache before proceeding with other operations. if !cache.WaitForCacheSync(stopCh, podInformer.Informer().HasSynced) { log.Fatal("Failed to sync caches.") } ``` 上述代码确保了在执行任何依赖于最新状态的操作之前,本地缓存已经完全加载完毕。 #### 解决常见问题 - **延迟接收变更通知**:如果遇到这种情况,请确认是否正确设置了 Resync Period 参数;过短的时间间隔可能导致频繁重试而影响性能,反之则可能造成消息滞后。 - **丢失某些特定类型的事件**:检查是否有多个组件竞争相同的资源版本号 (ResourceVersion),从而引发冲突。尝试调整 Watch 请求参数或者增加唯一标识符来区分不同的消费者群体。 - **内存泄漏风险**:长时间运行的应用可能会因为不断累积未释放的对象而导致 OOM 错误。定期清理不再使用的监听句柄以及合理控制并发数量有助于缓解此类状况的发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值