royliang
royliang
I think the `/etc/kubernetes/kube-scheduler` directory only exists in TKE cluster. If your cluster was built by edgeadm/kubeadm, the `/etc/kubernetes/` directory should be like this: ``` --manifests/ |----etcd.yaml |----kube-apiserver.yaml |----kube-controller-manager.yaml |----kube-scheduler.yaml...
> 因为这些操作都是异步的 合理的sync可以提高事件消费的容错性 感谢回答~ 能举个例子说说什么情况下会出现事件消费异常吗？
> > > 因为这些操作都是异步的 合理的sync可以提高事件消费的容错性 > > > > > > 感谢回答~ 能举个例子说说什么情况下会出现事件消费异常吗？ > > 嗯 ... 作为一个分布式的系统 排除代码之外 网络，基础设施等都有可能导致消费的异常，resync是一个很常规的操作（简单来说比如你的mq消费失败你会怎么做） 这里的消费者指的是从 FIFODelta 队列中取 event 的 workQueue 和从 workQueue 取 key...
## 一、Client-go 中的 Informer 工作流程图  Informer 中的 Reflector 通过 List/watch 从 apiserver 中获取到集群中所有资源对象的变化事件（event），将其放入 Delta FIFO 队列中（以 Key、Value 的形式保存），触发 onAdd、onUpdate、onDelete 回调将 Key 放入 WorkQueue 中。同时将 Key 更新 Indexer 本地缓存。Control Loop...
> @lianghao208 Hi "在处理 SharedInformer 事件回调时，**让处理失败的事件得到重新处理**"。 这里应该会将处理过的事件也进行了一次update处理吧？ 是的，准确的说时update处理，我改一下表述，感谢指正~
> 这个问题在《Programming Kubernetes》的第一章详细解释了一遍，我搬运一下。 > > 主要的目的是为了不丢数据，处理 `resync` 机制还有边缘触发与水平获取的设计，一起来保证不丢事件、数据同步并能及时响应事件。 > > 以下内容都摘抄自《Programming Kubernetes》 > > > 在分布式系统中，有许多操作在并行执行，事件可能会以任意顺序异步到达。 如果我们的 controller 逻辑有问题，状态机出现一些错误或外部服务故障时，就很容易丢失事件，导致我们没有处理所有事件。 因此，我们必须更深入地研究如何应对这些问题。 > > 在图中，您可以看到可用的不同方案： > > > > 1. 仅使用边缘驱动逻辑的示例，其中可能错过第二个的状态更改事件。 >...
上面的Pop方法的源码有写到，每次传一个 Deltas 进 process 中，而 Deltas 里面有 多个 Delta 对象（每个 Delta 对象对应一个 DeltaType，表示对一个资源对象的多次操作）。所以我认为应该是队列中每个资源对象(Deltas)做一次 process 操作，而每个资源对象(Deltas)会有多个 DeltaType，所以要进行遍历。从最老的 DeltaType 开始遍历到最新的 DeltaType。 ```go type DeltaFIFO struct { ... items map[string]Deltas queue []string ......
> > 上面的Pop方法的源码有写到，每次传一个 Deltas 进 process 中，而 Deltas 里面有 多个 Delta 对象（每个 Delta 对象对应一个 DeltaType，表示对一个资源对象的多次操作）。所以我认为应该是队列中每个资源对象(Deltas)做一次 process 操作，而每个资源对象(Deltas)会有多个 DeltaType，所以要进行遍历。从最老的 DeltaType 开始遍历到最新的 DeltaType。 > > ```go > > type DeltaFIFO struct {...
> ```go > customresource_discovery_controller > ``` 太感谢了！！之前一直没找到这段逻辑，一直在翻 apiserver 启动流程的代码，忽略了 crd 创建的时候会去动态创建 apisever 的路由。大佬你读源码的能力太强了！！！