基于ETCD的Kubernetes基本原理解析

ETCD概念

ETCD是一种高可用的键值对类型的数据库，提供可靠的分布式的状态存储，可以配置多节点群集，群集之间做数据同步来保证数据可靠性，当一台因为故障挂点，会从剩余的节点通过选举算法选举出一个几点来代替故障节点，从而实现高可用性。

ETCD与Kubernetes的关系

ETCD为Kubernetes提供了可靠的数据存储机制，和基于watch机制的订阅发布机制，实现了核心数据的存储，和核心的基于watch-list的informer机制，当ETCD数据变化通过watch机制触发相应的核心操作，如pod创建，deployment构建等 。

在分布式系统中，最为适用的组件间通信的方式是消息发布和订阅机制。当应用在启动的时候主动从ETCD中拉取一次完整的列表信息，并在ETCD节点上注册一个watcher，以后每次列表中的数据有变化，ETCD都会实时通知订阅者，订阅者就可以获取最新的数据并且利用这些数据和行为（增删改）作为参数执行相应的预定义方法。Kubernetes核心的基于watch-list的informer机制就是基于ETCD的订阅机制实现的。

Kubernetes概念化理解

为了方便大家理解，这里引入两个概念虚拟世界，真实世界。虚拟世界是指Kubernetes ETCD中存储的资源定义结构和状态（如：pod rs demployment）真实世界是指实际运行的计算资源，如镜像、虚拟机、网络、存储等。

1. 从虚拟世界创建和管理真实世界：
   客户使用预定义的yaml格式资源描述领域语言，来描述想要的资源，如一次具体的部署，要采用什么样的镜像，要什么样的规模等，通过Kubernetes预定应接口（如kubectl helm chart等方式）发送需求到Kubernetes系统，Kubernetes系统会解析这些yaml格式的资源定义进行编码转换然后存在ETCD中，通过watch机制触发实际（现实世界的）的deployment构建流程。

2. 从虚拟世界恢复出健康的真实世界：
   真实世界的脆弱性允许各种不可控事件发生，由ETCD定义的虚拟世界是一个理想状态（目标状态）其中的一切认为都是可控的，虚拟世界不能保证真实世界不会有意外发生，但是可以为真实世界提供蓝图，让真实世界可以随时从意外中恢复，其实是虚拟世界和真实世界的同步问题。虚拟资源的创建和修改是可以瞬间完成的（ETCD数据操作）真实世界中各种资源的创建则是需要时间的一个过程，如容器的启动和停止都是需要时间，为了系统的稳定性和特定逻辑故意让一些资源操作延时发生，所以同步过程是需要时间的。资源状态也是需要实时监控的，通过控制循环（control loop)实现实时监控，保证虚拟世界和真实世界的同步。

Kubernetes通过ETCD管理全局状态，在Kubernetes这种分布式系统中，任何组件都可能随时出现故障。当组件恢复时，需从一个错误状态恢复（部分主机崩溃，部分pod崩溃），ETCD充当这个恢复的数据源。

Kubernetes ETCD ORM系统

Kubernetes 针对ETCD定义了一套orm系统 ，实现了资源对象和ETCD存储对象的映射、资源对象之间关联关系（如某个pod属于某个rs某个rs属于某个deployment， 用OwnerReference字段定义所属的object）、定义了对应的缓存机制，callback机制，验证机制等等，实现了查询操作集合。

RESTful与Kubernetes

RESTful的核心概念是资源，通过增删改查实现资源管理，这一点是和Kubernetes的设计理念是一致的，Kubernetes是将计算资源看做可以增删改查的资源来进行管理的。

资源是一个概念实体描述，它向客户端公开，也就是说客户知道资源的具体规则，可以利用预定义规则构建资源结构，并通过预定义标准接口实现资源的增删改查等标准操作，来实现资源状态的转移。Kubernetes定义了一套基于yaml的资源描述的领域语言，来构建具体的资源需求描述。

restful api 的增删改查，对应了ETCD对应数据的增删改查，ETCD数据的增删改查，对应了实际的Kubernetes计算资源的增删改查（如：对应deployment生命周期，创建更改删除）。

Kubernetes watch 机制

Kubernetes api利用http stream机制（基于http 1.1分块编码(Transfer-Encoding: chunked)或者websckect ，实现持续长连接。服务器端的store对象利用ETCD的watch机制，当watch机制触发时将数据的变化信息封装成event对象并打包成chunk，发送出去，客户端则通过不停的监听尝试来读取这个event chunk。

简单理解就是Kubernetes利用websckect 或者 http stream长连接机制，建立一个管道（队列）api 服务器端负责发送数据（生产数据），api 客户端负责读数据(消费数据)。相当于一个建立一个基于http的消息队列机制。

Kubernetes 任务编排机制概述

development controller 定义自己的development Informer，通过development Informer同步和监听ETCD的development 资源的变化，当用户定义一个development yaml 并通过命令行发送到Kubernetes，实质是将用户定义好的development文件编码解析存储到ETCD数据库中，这会直接触发Informer中预先定义的watch机制，将触发预定义好的add事件，这个过程可以简单理解为数据库的after create callback，当数据插入数据库触发回调函数执行预定义功能。ETCD更新对应资源数据，Informer更新本地缓存，然后根据development定义的资源编排，调用相关api执行相关资源的创建更新删除等，最终达到development定义状态。

Informer 会通过list watch机制建立一套本地缓存，减少服务器调用，减轻对ETCD压力，提高程序运行速度。list-watch是Kubernetes很核心的概念，先通过api获取对象列表，再利用ETCD的watch机制保证本地缓存的一致性。

访问minikube etcd方法

kubectl exec -it --namespace kube-system etcd-minikube sh

cd /var/lib/minikube/certs
 
export ETCDCTL_API=3

etcdctl --endpoints 127.0.0.1:2379 --cacert "etcd/ca.crt" --cert etcd/server.crt --key etcd/server.key get / --prefix --keys-only

echo L3JlZ2lzdHJ5L25hbWVzcGFjZXMvYXV0b21vZGVs|base64 -D

etcdctl --endpoints 127.0.0.1:2379 --cacert "etcd/ca.crt" --cert etcd/server.crt --key etcd/server.key get /registry/deployments/default/hello-minikube -w=json

公众号：王司技术谈

免费星球号：