一、kubernetes架构

kubernetes的架构包括控制平面和数据平面，如下图
初识kubernetes - 图1

1、控制平面

在kubernetes的控制平面中，主要包括kube-apiserver、kube-controller-manager、kube-scheduler和etcd这四大组件。

  • kube-apiserver：kubernetes集群的唯一入口。
  • kube-contreller-manager：运行控制器进程的控制平面组件。此组件管理的控制器包括节点控制器（Node Controller）、任务控制器（Job controller）、端点控制器（Endpoints Controller）、服务帐户和令牌控制器（Service Account & Token Controllers）等。
  • kube-scheduler：控制平面组件，负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

  • etcd：etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

    2、数据平面

  • 在kubernetes的数据平面运行组件包括kubelet、kube-proxy、runtime这三个组件。

  • kubelet：一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
  • kube-proxy：kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
  • runtime：容器运行环境是负责运行容器的软件。Kubernetes 支持多个容器运行环境:，包括Docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI (容器运行环境接口)。

二、kubernetes的 list-watch 机制

1、Informer机制

Informer机制是kubernetes统一的异步消息处理机制，各个组件间的协同均是通过该机制进行通信的。这一机制确保了消息的可靠性，实时性，顺序性，高性能。
在kubernetes中，数据是存储在etcd中的，kubernetes会定时通过apiserver，以http的短链接，调用list api，从etcd中获取全部的资源信息，并维护在缓存中，同时list也是watch的补偿机制，定期的执行list api 避免watch时发生遗漏。而watch机制则是通过http长链接，以watch api来监听kubernetes中的pod的事件，当有事件触发时，产生一个watch event。
下图来自于kubernetes的sample-controller库
初识kubernetes - 图2

  • Reflector：用于watch 指定资源类型的kubernetes api。当Reflector 通过watch API接收到实例资源变更的信息时，会使用相应的list API获取新创建的object，并将object放置于DeltaFifo队列中。
  • DeltaFIFO：FIFO是一个先进先出的队列，可以实现Add、Update、Delete、List、Pop、Close操作，而Delta是一个资源对象存储，可以保存资源对象的操作类型
  • Informer：informer会从Delta Fifo中取走object
  • Indexer：用来提供存储资源对象并提供对象的索引功能的本地存储，indexer中的数据和etcd中数据是一致的
  • Informer reference：informer模板
  • Indexer reference：indexer模板
  • Resource Event Handlers：这是informer想要将object交付给你的controller。编写这些function的典型模式是获取这些object的key，并添加到work queue中。
  • Work queue：这是用你开发的controller去创建一个work queue，从processing中解耦object。Resource Event Handlers提取object的key，将object添加到work queue中。
  • Process Item：这是在代码中创建的处理work queue中process item的功能。这些功能通常会使用indexer或或通过list wrapping 去检索key和object

Informer机制在kubernetes中是非常核心的，后续会单独分析informer机制。

2、list-watch机制

list-watch机制是kubernetes中的一个重要设计，通过这一机制保证了kubernetes资源更新的可靠性，实时性，顺序性，高性能。
List：这个是kubernetes通过调用List API来获取kubernetes资源的全量数据，并将数据维护在了内存中。
Watch：这个是通过client-go及Informer模块，调用Watch API来watch apiserver中的资源变更事件，并将变更维护到缓存中。
LIst-Watch机制中，List通过http短链接获取全部资源数据后，会定时调用Listapi获取全量数据，这样可以最大限度的降低apiserver和etcd的交互，降低了apiserver及etcd的压力，同时也可以补全数据，避免watch遗漏事件。而watch机制可以理解为一个增量变更，每次会根据事件来更新缓存中对应资源的数据，同时又有list API的补全，可以保证数据的可靠性。
下图是结合pod的完整生命周期来讲述list-watch机制：
初识kubernetes - 图3
在整个生命周期中，List API获取了ETCD中kubernetes集群的全部资源信息，并且watch API以长链接的形式监听apiserver。当kubectl 触发事件创建pod后，apiserver和etcd交互，将事件写入etcd中，kube-controller-manager watch到这一事件后，与apiserver交互更新pod状态，并写入etcd中。kube-scheduler watch到这一事件后，同apiserver交互，筛选出node后于pod绑定，并于apiserver交互，更新到etcd中。kubelet watch这一事件更新后，调用OCI接口创建pod，并不断同apiserver交互更新pod运行状态并写入到etcd中。
后续我将逐一介绍kubernetes组件。