使用 Rust 实现的基础的List 和 Watch 机制

本文分享自天翼云开发者社区《使用 Rust 实现的基础的List 和 Watch 机制》。作者：l****n
使用 Rust 实现的基础的List 和 Watch 机制

介绍

在日常的开发过程中，有一个很重要的任务是能够通过Rust语言实现K8s中的各种生态组件，在这个过程中，既需要能过够了解K8S的工作原理也需要能够知道rust的语言特性。因此，在这个过程中有很多值得探讨的知识点。
在这里，第一步，我们将探索如何使用 Rust 实现一个类似于 Kubernetes 的 list 和 watch 机制。我们将通过 WebSocket 实现实时的消息推送，并使用一些关键的 Rust 异步编程模型来处理事件和连接管理。
我们首先默认大家能够了解rust语言的基本特性。下文中，将针对rust的知识点展开进行探讨。
目标

• 理解 WebSocket 连接的建立和管理。
  
• 学习如何通过 WebSocket 推送消息。
  
• 掌握消息缓存和处理的实现方式。
  
• 了解如何使用 Rust 实现一个高效的事件分发系统。
  
• 理解K8S中的数据一致性保障方法
  
• 了解本机制的不足，以及后续如何进行改进
  

理解问题

什么是 list 和 watch？

• List：列出当前所有资源的状态。
  
• Watch：实时监控资源的变化，一旦有资源变化，就会立即通知客户端。
  

使用场景

• 自动化运维：实时监控系统资源状态，触发自动化运维操作。
  
• 应用监控：实时获取应用状态，及时处理异常，在很多的系统设计场景中，能够减少耦合。
  
• K8S中的相应设计：K8S中，对相应资源的通知的基础即为list and watch机制。本人在学习K8S源码的第一步就是学习这一套设计架构。
  

分析问题

\当然，通过简单的代码仅仅通过http进行主动连接也可实现这个功能。但在目前阶段，我们希望能够设计一个高效的、稳定的、可扩展的list and watch体系，因此我们需要考虑以下几个关键问题。
关键问题

• 如何建立和管理 我们服务器和客户端的连接？通过什么方式进行？
  
• 如何实现高效的消息推送机制？
  
• 如何处理消息缓存和订阅管理？
  

技术选型

• 语言：Rust
  
• Web 框架：warp框架
  
• WebSocket实现和框架：tokio-tungstenite、warp
  
• 异步编程：tokio、管道机制
  

设计代码结构

针对以上这个需求，结合目前kunos-system的需求我们阐释如下

• 有以下几个资源，Node、Task（Task是一个shell命令、镜像运行命令的载体）、Job（Task的上层资源，一个Job包含多个Task，类似于K8s中的replicaset）我们需要对这几个资源的状态进行推送。
  
• 能够在服务器建立起来一个watch and list服务器，能够推送各种事件
  
• 能够
  

组件设计

<ol>Broker：管理 WebSocket 订阅者和事件分发。

1. pub struct Broker<R: Resource + Clone + Serialize + Send + Sync  + 'static> {
2.     // 下游的订阅者列表，用于发送websocket信息
3.     subscribers: Arc<RwLock<HashMap<Topic, HashMap<Uuid, WsSender>>>>,
4.     // 事件的缓冲流
5.     event_sender: UnboundedSender<(Topic, WatchEvent<R>)>,
6. }

复制代码

使用验证

不足分析

经过上面的介绍，我们可以看到这个基础的list and watch机制能够正确运行。但是，和K8S、ETCD中广泛使用的list and watch相比仍然缺少一个机制来保证list和watch的一致性。
请考虑这样一种情况我们的服务器中会源源不断地产生数据d1,d2,d3,...,dn。当我们使用list时候，能够感知到d1,d2,d3，此时我们完成list，开始建立watch。加入在开始建立watch这个阶段，即使可能是几毫秒的时间但服务器生成了d4，而在watch建立起来后，只能接收到d5,d6,...。这就导致了数据的遗失。
在 Kubernetes 中，List 和 Watch 操作结合使用时，需要使用一个revision机制以确保资源的变更不会被遗漏。理解 List 和 Watch 操作时 revision（即 resourceVersion）的具体含义和管理方式对于保证一致性至关重要。revision的存在有着如下的意义：

• 数据版本控制：revision 是 Etcd 的全局递增计数器，用于标识数据的当前版本。当进行数据的修改、更新操作时候，revision会+1
  
• 一致性视图：确保返回的数据是一致的快照视图，表示在该 revision 之前的所有操作都已完成。
  

revision 与 List 和 Watch 的关系

• List 操作：
  
  
  
  • 返回资源列表和当前的全局 revision，作为 resourceVersion。
    
  • 确保获取到的资源是该 revision 时刻的一致视图。
    
  
  
• Watch 操作：
  
  
  
  • 使用 List 操作返回的resourceVersion` 作为起点。
    
  • 从该 resourceVersion 开始监听资源的变化，确保在List 和Watch` 之间的变更不会丢失。
    
  
  

List 操作的 revision

当进行 List 操作时，Kubernetes API Server 从 Etcd 获取当前资源的状态及其resourceVersion 。这个 resourceVersion 是 Etcd 当前的全局revision 。它表示在此 revision 之前的所有操作都已经完成，并确保返回的数据是这个revision` 时刻的一致视图。
Watch 操作的 revision

Watch 操作使用 List 操作返回的 resourceVersion 作为起点，从该版本开始监听资源的变化。这确保了从 List 到 Watch 之间的变更不会被遗漏。
示例流程

• List 操作：
  
  
  
  • API Server 从 Etcd 获取指定资源的当前状态。
    
  • Etcd 返回包含所有资源对象的列表和一个全局 revision ，这个 revision 将作为resourceVersion`。
    
  
  
• Watch 操作：
  
  
  
  • API Server 使用 List 操作返回的 resourceVersion（revision） 作为起点，开始监听资源的变化。
    
  • Etcd 返回从指定 revision` 开始的所有变更事件。
    
  
  

总结

• revision：标识数据版本，确保数据一致性。
  
• List 和 Watch：List 获取资源和 revision，Watch 从该 revision 开始监听变化，确保变更的连续性和一致性。
  

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