我不允许谁还分不清这三种watch机制的区别

今天快速介绍目前市场面常见的三个watch机制的实现。
1.chunked transfer encoding

k8s控制面几个组件，核心枢纽是apiserver， 除etcd之外，其他组件都通过restful进行http通信。
上文提到的informer机制是controller的标准范式， 目的是实现声明式API的闭环控制，减少了对于apiserver的调用。
scheduler和kubelet、kubectl也有对于apiserver的调用，监听资源变更的方式都是watchAPI， 这是一种非标准的chunked transfer encoding，http1.1传输层编码。

分块传输编码（CTE）是一种 HTTP/1.1 机制，通过将数据分割为多个块来流式传输响应，每个块前面都带有其十六进制表示的大小，使得服务器可以在不知道总长度的情况下发送数据，适用于动态内容、实时更新和大文件传输，最后以一个长度为零的块结束。

2. grpc 流式通信

apiserver作为控制面组件的交互枢纽， 与底层存储etcd交互。
apiserver 也需要watch etcd的资源变动，这样才能接力反馈到上层组件（scheduler，kubectl）。

etcdv3 走的是grpc协议，天生支持双向实时通信。

http2.0 高性能rpc框架， 单个tcp连接上多路复用，二进制分帧、双向流式通信，头部压缩。

apiserver是作为grpc客户端与etcd交互，etcd 的 Watch 机制是一个集 MVCC 版本控制、高效内存索引、持久化存储和流式网络通信 于一体的复杂系统。其核心价值在于提供了 基于逻辑时钟的、可靠的、有序的变更通知，这正是 Kubernetes 等分布式系统能够构建出高效、一致的状态协调机制的基础。

3. 服务端发送事件SSE

目前火热的大模型在线推理，走的是SSE协议。
服务器发送事件（SSE）是一种基于HTTP 协议的单向通信协议，它允许服务器以事件流（Event Stream）的形式实时向客户端推送数据，而无需客户端明确请求。它建立在标准的 HTTP 协议之上，通过单向的持久连接，服务器可以主动向客户端发送事件和数据。

本质上，它是以应用层消息协议来实现的，由客户端向服务端发起建立连接请求，并保持连接打开，然后服务端主动推送消息给客户端，服务器给客户端发送的 SSE 数据，必须是 UTF-8 编码，且返回的内容类型是text/event-stream。
比如当你在使用DeepSeek 时，当你询问它问题时，你会看到它会逐字地将回答显示出来，实际上这是DeepSeek 将先计算出的数据主动的“推送”给你，采用 SSE 技术边计算边返回，避免接口等待时间过长而直接关闭页面。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

不错，里面软件多更新就更好了

新版吗？好像是停更了吧。