【云原生系列】第一篇为什么Etcd的Watch不会丢数据？

本文链接：https://blog.youkuaiyun.com/mike_learns_to_rock/article/details/124312106

本文深入探讨Etcd的Watch机制，解释为何在云原生环境中Watch不会丢数据。从Etcd v2的轮询模式到v3的流式推送，详细阐述了Watch的工作原理和可靠性保障，包括异常处理机制、历史事件推送，以及在网络抖动时如何保证数据的完整性。此外，还提及了Kubernetes中Watch的重要性及其在面对Etcd数据丢失时的处理策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

云原生系列文章目录

第一篇为什么Etcd的Watch不会丢数据？

前言

K8s中Deployment, StatefulSet, Job等功能强大的Workload，背后都有相应的控制器。

控制器的核心是监听，比较期望状态和实际状态的一致性，若不一致则进行协调工作，达到最终一致。

当你修改一个Deployment的镜像时，Deployment控制器如何高效感知到期望状态发生变化呢？

Etcd的Watch特性是控制器工作的基础。但是如果Watch机制本身不可靠，控制器就无法感知到期望状态的变化。

特别是网络抖动的情况，我们肯定不希望Watch的数据丢失。

你是否思考过如下几个问题

Watch为什么不会丢数据么？
Watch如何保证自身的可靠性呢？
Watch数据丢失后，K8s会如何处理呢？`

一、Watch是什么？

Watch是一种监听机制，客户端创建一个watcher后，指定监听某个key或者一组key，便会持续从服务端获取key的数据变化；

在使用上，Watch既可以监听某个key，还可以通过指定前缀的方式来监听一组key，甚至还可以指定从哪个版本号revision开始监听。

下面示例中，在一个etcd集群中演示如何使用watch。

操作如下

获取集群初始revision，查看header中的revision
对k0进行两次数据更新
从初始revision开始，监听k0
查看监听记录中的两次数据修改，反解base 64来查看两次更新的value

两个事件记录对应上面两次的修改，可以比较事件中的create_revision和mod_revision区分此事件是add还是update事件；

这次演示中，都是update事件；这说明k0在演示之前就已经创建好了；

要知道Etcd中的数据内容，可以通过反解 base 64 的方式(base64 -d)来实现。

[root@k8s-node1 ~]# etcdctl endpoint status -w json | json_pp
[
   {
   
      "Status" : {
   
         "leader" : 15667974710379825923,
         "version" : "3.4.13",
         "dbSize" : 7729152,
         "dbSizeInUse" : 3887104,
         "raftTerm" : 26,
         "raftAppliedIndex" : 59580404<