double12gzh - Posts tagged k8s源码分析

client-go系列之3—restclient的使用

2020-10-14T00:00:00+00:00

摘要：介绍如何使用client-go中的restclient，可以结合“系列之1”来看。

0. 背景

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。问题或建议，请公众号留言。

首先我通过kind创建了一个6节点的集群，本文章中所有的操作都是在这个集群中进行的。

通过本文的讲解，希望您能了解如何使用client-go中的RESTClient来对资源进行操作，这里我只是举了最简单的例子—pod资源获取。

文中用到的软件的版本如下：

kind

[root@xxx-wsl ~/client-go-example] kind version
kind v0.9.0 go1.15.2 linux/amd64

1. 环境准备

通过kind创建多节点的k8s集群: 3个master节点 + 3个worker节点

[root@xxx-wsl ~/init_kind_clusters] kind create cluster --config=init_cluster.yaml
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.19.1) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦 📦 📦
 ✓ Configuring the external load balancer ⚖️
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
 ✓ Joining more control-plane nodes 🎮
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/

其中init_cluster.yaml内容如下：

[root@xxx-wsl ~/init_kind_clusters] cat init_cluster.yaml
# a cluster with 3 control-plane nodes and 3 workers
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker

2. RestClient使用示例

这段代码的作用：从namespace为kube-system中获取所有的pod并输出到屏幕

main.go

package main

import (
        "context"
        "fmt"

        corev1 "k8s.io/api/core/v1"
        metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

        "k8s.io/client-go/kubernetes/scheme"
        "k8s.io/client-go/rest"
        "k8s.io/client-go/tools/clientcmd"
)

func main() {
        fmt.Println("Prepare config object.")

        // 加载k8s配置文件，生成Config对象
        config, err := clientcmd.BuildConfigFromFlags("", "/root/.kube/config")
        if err != nil {
                panic(err)
        }

        config.APIPath = "api"
        config.GroupVersion = &corev1.SchemeGroupVersion
        config.NegotiatedSerializer = scheme.Codecs

        fmt.Println("Init RESTClient.")

        // 定义RestClient，用于与k8s API server进行交互
        restClient, err := rest.RESTClientFor(config)
        if err != nil {
                panic(err)
        }

        fmt.Println("Get Pods in cluster.")

        // 获取pod列表。这里只会从namespace为"kube-system"中获取指定的资源(pods)
        result := &corev1.PodList{}
        if err := restClient.
                Get().
                Namespace("kube-system").
                Resource("pods").
                VersionedParams(&metav1.ListOptions{Limit: 500}, scheme.ParameterCodec).
                Do(context.TODO()).
                Into(result); err != nil {
                panic(err)
        }

        fmt.Println("Print all listed pods.")

        // 打印所有获取到的pods资源，输出到标准输出
        for _, d := range result.Items {
                fmt.Printf("NAMESPACE: %v NAME: %v \t STATUS: %v \n", d.Namespace, d.Name, d.Status.Phase)
        }
}

go.mod

module main

go 1.15

require (
        github.com/go-logr/logr v0.2.1 // indirect
        github.com/google/gofuzz v1.2.0 // indirect
        github.com/imdario/mergo v0.3.11 // indirect
        golang.org/x/crypto v0.0.0-20201002170205-7f63de1d35b0 // indirect
        golang.org/x/net v0.0.0-20201010224723-4f7140c49acb // indirect
        golang.org/x/oauth2 v0.0.0-20200902213428-5d25da1a8d43 // indirect
        golang.org/x/sys v0.0.0-20201009025420-dfb3f7c4e634 // indirect
        golang.org/x/time v0.0.0-20200630173020-3af7569d3a1e // indirect
        k8s.io/api v0.19.2
        k8s.io/apimachinery v0.19.2
        //k8s.io/client-go v11.0.0+incompatible
        //      k8s.io/client-go v11.0.0+incompatible
        k8s.io/klog v1.0.0 // indirect
        k8s.io/klog/v2 v2.3.0 // indirect
        k8s.io/utils v0.0.0-20201005171033-6301aaf42dc7 // indirect
)

require k8s.io/client-go v0.19.2

3. 输出结果

[root@xxx-wsl ~/client-go-example] go run main.go
Prepare config object.
Init RESTClient.
Get Pods in cluster.
Print all listed pods.
NAMESPACE: kube-system NAME: coredns-f9fd979d6-rhzfd     STATUS: Running
NAMESPACE: kube-system NAME: coredns-f9fd979d6-whrj2     STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane     STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane2    STATUS: Running
NAMESPACE: kube-system NAME: etcd-kind-control-plane3    STATUS: Running
NAMESPACE: kube-system NAME: kindnet-bpsfl       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-ks6zv       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-pm6zl       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-qfhqt       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-s7qqn       STATUS: Running
NAMESPACE: kube-system NAME: kindnet-trk5l       STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane   STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane2          STATUS: Running
NAMESPACE: kube-system NAME: kube-apiserver-kind-control-plane3          STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane          STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane2         STATUS: Running
NAMESPACE: kube-system NAME: kube-controller-manager-kind-control-plane3         STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-7gz67    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-bvbkk    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-clf72    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-d8zpb    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-dsmsj    STATUS: Running
NAMESPACE: kube-system NAME: kube-proxy-fplkk    STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane   STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane2          STATUS: Running
NAMESPACE: kube-system NAME: kube-scheduler-kind-control-plane3          STATUS: Running

client-go系列之4—Indexer

2020-10-17T00:00:00+00:00

摘要：介绍client-go中Indexer机制。

1. 写在前面

在本系列教程的第一篇中，我们已经对如下这张图作了简单介绍。这张图非常重要，理解这张图对我们正确理解client-go及Controller非常有帮助(出处)。

client-go中对其实现的代码位于tools/cache，如下图：

除了上图中展示的Indexer的定义比较重要外，我们还需要关注Indexer比较重要的数据结构：

[root@xxxx-wsl /ACode/client-go] cat tools/cache/index.go| grep -B 1 -A 1 type

// IndexFunc knows how to compute the set of indexed values for an object.
type IndexFunc func(obj interface{}) ([]string, error)

--
// Index maps the indexed value to a set of keys in the store that match on that value
type Index map[string]sets.String

// Indexers maps a name to a IndexFunc
type Indexers map[string]IndexFunc

// Indices maps a name to an Index
type Indices map[string]Index

IndexFunc: 从接收的资源对象中，根据一系列的key来获取相应的值。
Index: 建立key与被索引值的对应关系并存储到Store中，即它里面的数据都是Key/Value的形式。
Indexers: 存储的是索引器的名字与索引器的实现函数。
Indices: 存储缓存数据，形式Key/Value，其中Key为缓存器的字，Value为缓存数据。

2. Custom Controller中的组件

如图中所示，Custom Controller是位于下半部分的内容。从图中可以很容易的看到，一个Custom Controller主要包含以下内容：

Indexer Reference
Informer Reference
Resource Event Handler
WorkQueue
ProcessItem

2.1 Indexer

2.1.1 简单介绍

它是一个知道如何使用CRD对象的 Indexer 实例的引用(reference)。当我们写自定义控制器(Custom Controller)代码时，将使用这个reference去做对象检索。

Indexer是client-go中实现的一个本地存储，它可以建立索引并存储Resource的对象。Reflector通过Delta FIFO Queue将资源对象存储到Indexer中。

需要注意的是，Indexer中的数据与etcd中的数据是完全一致的，这样client-go需要数据时，无须每次都从api-server获取，从而减少了请求过多造成对api-server的压力。

一句话总结：Indexer是用于存储+快速查找资源，即它的目的就是为了能够进行快速查找。

Indexer是如何实现“存储+快速查找资源”的呢？我们来看一下下面这张图，通过这张图方便我们理解一下Indexer的存储结构：

说明：图中的Indexers与Indices虽然都指向了相同的IndexFunc，这并不是说二者的数据是相同的，而是说二者使用的IndexFunc是相同的。

根据上面这个图，我们可以简单的规纳出与之对应的数据结构：

// 包含的所有索引器/分类以及对应的实现
Indexers: {  
    "namespace": NamespaceIndexFunc,
    "nodeName": NodeNameIndexFunc,
}

// 包含的所有索引分类中所有的索引数据
Indices: {
    //namespace 这个索引分类下的所有索引数据
    "namespace": {  
         // Index 就是一个索引键下所有的对象键列表
        "default": ["pod-1", "pod-2"], 
        // Index
        "kube-system": ["pod-3"]   
    },

    //nodeName 这个索引分类下的所有索引数据(对象键列表)
    "nodeName": {
         // Index
        "node1": ["pod-1"],
         // Index
        "node2": ["pod-2", "pod-3"]
    }
}

Indexers和Indices都是按照IndexFunc(名字)分组，每个IndexFunc输出多个IndexKey，产生相同IndexKey的多个对象存储在一个集合中。

IndexKey主要是用于快速查找ObjectKey; 而ObjectKey是对象存储时唯一命名的key(这个key方便在存储中快速找到相应的对象)。

2.1.2 代码位置

$GOPATH/pkg/mod/k8s.io/client-go@v0.19.0/tools/cache/index.go

2.1.3 类图展示

从下图我们可以很容易的看到Indexer与cache、Store及ThreadSafeStore之间的调用关系。

上图如果长时间无法显示，请参考这里

Store: 是一个通用对象存储和处理接口。

// Store is a generic object storage and processing interface.  A
// Store holds a map from string keys to accumulators, and has
// operations to add, update, and delete a given object to/from the
// accumulator currently associated with a given key.  A Store also
// knows how to extract the key from a given object, so many operations
// are given only the object.
//
// In the simplest Store implementations each accumulator is simply
// the last given object, or empty after Delete, and thus the Store's
// behavior is simple storage.
//
// Reflector knows how to watch a server and update a Store.  This
// package provides a variety of implementations of Store.
type Store interface {
40
   // Add adds the given object to the accumulator associated with the given object's key
   Add(obj interface{}) error
43
   // Update updates the given object in the accumulator associated with the given object's key
   Update(obj interface{}) error
46
   // Delete deletes the given object from the accumulator associated with the given object's key
   Delete(obj interface{}) error
49
   // List returns a list of all the currently non-empty accumulators
   List() []interface{}
52
   // ListKeys returns a list of all the keys currently associated with non-empty accumulators
   ListKeys() []string
55
   // Get returns the accumulator associated with the given object's key
   Get(obj interface{}) (item interface{}, exists bool, err error)
58
   // GetByKey returns the accumulator associated with the given key
   GetByKey(key string) (item interface{}, exists bool, err error)
61
   // Replace will delete the contents of the store, using instead the
   // given list. Store takes ownership of the list, you should not reference
   // it after calling this function.
   Replace([]interface{}, string) error
66
   // Resync is meaningless in the terms appearing here but has
   // meaning in some implementations that have non-trivial
   // additional behavior (e.g., DeltaFIFO).
   Resync() error
}

Indexer: 扩展了多个索引的 Store，并限制每个累加器只保存当前对象（删除后为空）。
ThreadSafeStore: 与Indexer类似，是一个允许对存储后端进行并发索引访问的接口

cache: 根据 ThreadSafeStore 和关联的 KeyFunc 实现的 Indexer。所有的对象都缓存在内存中，这不是一个外部可以调用的对象，在包的外部不能直接调用cache。它的定义也比较简单，如下：

// 代码位置：client-go/tools/cache/store.go
// `*cache` implements Indexer in terms of a ThreadSafeStore and an
// associated KeyFunc.
type cache struct {
   // cacheStorage bears the burden of thread safety for the cache
   cacheStorage ThreadSafeStore
   // keyFunc is used to make the key for objects stored in and retrieved from items, and
   // should be deterministic.
   keyFunc KeyFunc
}

我们可以使用NewStore或NewIndexer来实例化一个Store或Indexer。

threadSafeMap : 是 ThreadSafeStore的实现，它实现了并发安全的存储(它是一个内存中的存储)，具备CRUD等操作。它其中包含了三个比较重要的属性，见代码：
```
61 // 代码位置：client-go/tools/cache/thread_safe_store.go
62 // threadSafeMap implements ThreadSafeStore
63 type threadSafeMap struct {
64     lock  sync.RWMutex
65     items map[string]interface{} //用于保存数据
66
67     // indexers maps a name to an IndexFunc
68     indexers Indexers
69     // indices maps a name to an Index
70     indices Indices
71 }
```
对于threadSafeMap中各种索引的关系，我们可以用下图来表示：

threadSafeMap其实只会做两件事情：存储，索引。存储即存储runtime.object到items这个Map中；索引即为items这个Map建立三层索引：indices的Map类型的索引(如：namespace, nodeName等)；index Map的类型索引(如： namespace1, namespace2, …); runtime.object的索引。

如果我们需要向threadSafeMap中添加一个对象，只需要调用下以代码即可：
```
72 // 代码位置：client-go/tools/cache/thread_safe_store.go
73 func (c *threadSafeMap) Add(key string, obj interface{}) {
74     c.lock.Lock()
75     defer c.lock.Unlock()
76     oldObject := c.items[key]
77     c.items[key] = obj
78     c.updateIndices(oldObject, obj, key)
79 }
```
如果想了解更多的细节，请查看updateIndices()

另外，从图中我们也可以看出，Indexer实际上是对threadSafeMap的封装，它继承了后者的所有方法，同时也实现了IndexFunc。

2.2 Indexer索引器实现

在kubernetes中使用的比较多的索引函数是MetaNamespaceIndexFunc()（代码位置: client-go/tools/cache/index.go）。

Indexer索引的实现是通过index.ByIndex来完成的，index.ByIndex的代码如下：

// 代码位置：client-go/tools/cache/thread_safe_store.go
// ByIndex returns a list of the items whose indexed values in the given index include the given indexed value
func (c *threadSafeMap) ByIndex(indexName, indexedValue string) ([]interface{}, error) {
   c.lock.RLock()
   defer c.lock.RUnlock()
183
   indexFunc := c.indexers[indexName]  // 关键代码。获取索引器函数。
   if indexFunc == nil {
       return nil, fmt.Errorf("Index with name %s does not exist", indexName)
   }
188
   index := c.indices[indexName]   // 关键代码。获取缓存器函数。
190
   set := index[indexedValue]    // 关键代码。Index中的数据以Set类型存储在缓存中。
   list := make([]interface{}, 0, set.Len())
   for key := range set {
       list = append(list, c.items[key])
   }
196
   return list, nil
}

上述方法接收两个参数:

indexName: 索引器的名字
indexedValue: 需要索引的key

此方法的基本思路如下：

根据索引器名字查找指定的索引器函数(c.indexers[indexName])
根据索引器名字查找相应的缓存器函数(c.indices[indexName])
根据索引key(即：indexedValue)从缓存中进行数据查询，并返回查询结果

client-go系列之5—Informer

2020-10-21T00:00:00+00:00

摘要：介绍client-go informer及controller.

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。

问题或建议，请公众号（double12gzh）留言。

依然秉承本系列的传统，在文章开始都会再次上一下下面这经经典的图(足见其重要性，哈哈哈)。

在client-go系列之1—client-go代码结构讲解中简单介绍一个client-go中的相关的模块(即图中上半部分)，其实，在client-go中不只是有前面提到的模块，还包括上图中下半部分的内容，即自定义控制器部分，如：

informer reference：是一个Informer的实例，主要用于处理与CRD（自定义资源）对象相关的。当我们开发自定义控制器（custom controller）时，需要这个控制器开创建相匹配的Informer。
indexer reference：是一个Indexer的实例，主要用于处理与CRD（自定义资源）对象相关的。当我们开发自定义控制器时，需要创建Indexer的实例，这个实例主要作用是实现存储+索引。
WorkQueue：工作者队列。前面我们提到过Informer，它除了更新本地缓存之外，还要将数据同步给相应控制器，WorkQueue就是为了数据同步的问题而产生的。当有资源被添加、修改或删除，Informer/SharedInformer就会将相应的事件加入到WorkQueue中。其它所有的控制器需要排队对这个queue进行读取，如果某个控制器发现这个事件与自己相关，就执行相应的操作。如果操作失败，就会把刚才取出的事件再放回到WorkQueue中，等再轮到自己执行时会再去重试这次失败的操作。如果操作成功，就将该事件从队列中删除。
Resource Event Handler：这是一个回调函数，当一个Informer/SharedInformer要分发一个对象到控制器时，会调用此函数。例如：将对象的Key放在WorkQueue中并等待后续的处理。
Process Item：用户自定义的处理WorkQueue中的相应Item的函数。如，我们可以在这里面使用Indexer或Listing wrapper来根据相应的Key检索对象。

Item的内容如下：

queue中的内容如下：

在client-go的controller中给出了如何定义Indexer和Informer的方法，代码位置：client-go/tools/cache/controller.go，代码如下：

func NewIndexerInformer(
   lw ListerWatcher,                 // 用于获取/监控需要Informer处理的资源
   objType runtime.Object,           // 订阅的对象类型
   resyncPeriod time.Duration,       // 非0时，将会一直list我们所关心的对象； 0时，‘重新list’将会被推迟
   h ResourceEventHandler,           // 用于处理与resources相关的事件
   indexers Indexers,
) (Indexer, Controller) {
   // This will hold the client state, as we know it.
   clientState := NewIndexer(DeletionHandlingMetaNamespaceKeyFunc, indexers)
  353
   return clientState, newInformer(lw, objType, resyncPeriod, h, clientState)
}

ResourceEventHandler的定义如下。其代码位置: client-go/tools/cache/controller.go。这里的Evnet只是具有通知的作用，因为，我们不应该对这里收到的对象进行任何修改。

type ResourceEventHandler interface {
   OnAdd(obj interface{})                  // 当有新的对象被创建时，将会调用这个函数
   OnUpdate(oldObj, newObj interface{})    // 当对象被修改时，将会调用这个函数。除此之外，当有`re-list`操作时，这个函数也会被再次调用
   OnDelete(obj interface{})               // 当对象被删除时，将会调用这个函数。
}

2. Informer简介

一句话背景介绍：为了减少当多个控制器对k8s-api-server进行大量访问时对api-server造成压力。

2.1 产生的背景

随着Controller越来越多，如果Controller直接访问k8s-apiserver，那么将会导致其压力过大，于是在这样的背景下就有了Informer的概念。其发展到今天这个架构，大概可以总结出以下迭代思路：

第一阶段，Controller直接访问k8s-api-server。存在的问题：多个控制器大量访问k8s-apiserver时会对其造成巨大的压力。

第二阶段，Informer代替Controller去访问k8s-apiserver。而Controller的所有操作操作(如：查状态、对资源进行伸缩等）都和Informer进行交互。但Informer没有必要每次都去访问k8s-apiserver，它只要在需要的时候通过ListAndWatch(即通过k8s List API获取所有资源的最新状态；通过Wath API去监听这些资源状态的变化)与k8s-apiserver交互即可。

ListAndWatch的代码位置: client-go/tools/cache/reflector.go

func (r *Reflector) ListAndWatch(stopCh <-chan struct{}) error{ … }

第三阶段， Informer并没有直接访问k8s-api-server，而是通过一个叫Reflector的对象进行api-server的访问。上面所说的 ListAndWatch 事实上是由Reflector`实现的。

第四阶段, 通过指定资源类型来Watch特定资源。

// 代码位置: client-go/tools/cache/listwatch.go
// Watcher is any object that knows how to start a watch on a resource.
type Watcher interface {
   // Watch should begin a watch at the specified version.
   Watch(options metav1.ListOptions) (watch.Interface, error)
}

第五阶段，定义SharedInformer。如果Controller与Informer是一一对应的关系，那么k8s-api-server的压力也还是挺大的。但是类似于Pod这样的资源来说，Deployment和StatefulSet都能对它进行管理，当多个控制器同时想查Pod的状态时，实现上，只需要有一个Informer就能满足需求了，即: SharedInformered。

第六阶段，解决多个不同的控制器排除与重试问题，引入DeltaFIFOQueue。每当资源被修改时，Reflector就会收到事件通知，并将对应的事件放入DeltaFIFOQueue中。另外，SharedInformer会不断从DeltaFIFOQueue中读取事件并更新本地缓存(ThreadSafeStore)的状态。

2.2 主要功能

通过List()/Get()（代码位置：client-go/tools/cache/listwatch.go）获取资源对象
监听事件(OnAdd, OnUpdate, OnDelete)，并触发回调(ResourceEventHandler)
支持二级缓存(DeltaFIFOQueue和ThreadSafeStore，前者用于存储Watch返回的事件，后者是一个LocalStore，能够被Lister的List()和Getter的Get()方法访问)

需要注意的是，Informer与k8s-apiserver之间没有同步机制，但是Informer内部的二级缓存之间是有同步机制的。

上面提到的List()/Get()的定义位于：client-go/tools/cache/listwatch.go

// Lister is any object that knows how to perform an initial list.
type Lister interface {
   // List should return a list type object; the Items field will be extracted, and the
   // ResourceVersion field will be used to start the watch in the right place.
   List(options metav1.ListOptions) (runtime.Object, error)
}
... 
// Getter interface knows how to access Get method from RESTClient.
type Getter interface {
   Get() *restclient.Request
}

2.3 主要模块

Reflector
DeltaFIFO
ThreadSafeStore（LocalStore）
Controller
Lister
Processor

需要注意的是：

这里提到的Controller不是Kubernetes Controller（前几篇文章中我们实际上已经提到过，再次重审一下，这两个Controller并没有任何联系）

Reflector主要用于监听与指定资源类型相关的事件

DeltaFIFO和ThreadSafeStore（LocalStore）是Informer的二级缓存

Lister主要是被调用List/Get方法

Processor中记录了所有的回调函数（即 ResourceEventHandler）的实例，并负责触发之

2.4 类图

出处

2.5 SharedInformer实现机制

当同一个资源(如：pdod)的Informer被实例化多次后，将会产生多个Reflector，如果这些Reflector都去调用ListAndWatch来获取资源时，将会对k8s-apiserver造成巨大的压力。

SharedInformer的意思是指：对于属于同一类型的资源来说，他们将会共享同一个Informer和Reflector，其实现代码如下：

// 代码位置: client-go/informers/factory.go
type sharedInformerFactory struct {
   client           kubernetes.Interface
   namespace        string
   tweakListOptions internalinterfaces.TweakListOptionsFunc
   lock             sync.Mutex
   defaultResync    time.Duration
   customResync     map[reflect.Type]time.Duration
62
   informers map[reflect.Type]cache.SharedIndexInformer     // sharedInformer的数据都存放在这个map中。
   // startedInformers is used for tracking which informers have been started.
   // This allows Start() to be called multiple times safely.
   startedInformers map[reflect.Type]bool
}

2.6 不同资源的Informer定义

对于不同的资源(如：pods, deployments, …)都有一个与之相对应的xxxInformer存在，他们的位置为(以pod为例):

// 代码位置：clent-go/informers/core/v1/pod.go
// PodInformer 提供了与pod相关的shared informer及lister进行交互的途径 
// 每个k8s resource都会有这样一个Informer，且Informer中都有以下两个方法：Informer(), Lister()
type PodInformer interface {
   Informer() cache.SharedIndexInformer
   Lister() v1.PodLister
}
   41
type podInformer struct {
   factory          internalinterfaces.SharedInformerFactory
   tweakListOptions internalinterfaces.TweakListOptionsFunc
   namespace        string
}

调用不同资源的Informer的使用示例如下：

deployInformer = sharedInformer.
               apps().              // client-go/informers/apps
               V1().                // client-go/informers/apps/v1
               Deployments().       // client-go/informers/apps/v1/deployment.go
               Informer()           // client-go/informers/apps/v1/deployment.go: type DeploymentInformer interface{}

3. Controller

3.1 Controller定义

代码位置: client-go/tools/cache/controller.go

// 这是一个Base Controller, 是其它所有控制器的`基类`。在`SharedInformer`中将会被用到。
// 
type Controller interface {
    // Run 只做两件事情：
   // 1. 构建并启动一个`Reflector`。把从`Config.ListerWatcher`中抛出的对象或通知发送到`Config.Queue`中，另外也可能会触发队列同步`Resync`
   // 2. 不断的从queue中弹出item，并使用Config.ProcessFunc进行处理。
   // 
   // 当channel `stopCh`被关闭时，上面两个操作会停止。
   Run(stopCh <-chan struct{})
106
   // HasSynced Config的队列是否已经同步过了
   HasSynced() bool
109
   // LastSyncResourceVersion delegates to the Reflector when there
   // is one, otherwise returns the empty string
   LastSyncResourceVersion() string
}

Controller的具体实现如下：

type controller struct {
   config         Config
   reflector      *Reflector
   reflectorMutex sync.RWMutex
   clock          clock.Clock
}

从上面的实现中，我们可以看到，一个Controller实际上是一个以Config为参数，并将会被Informer使用到的一个low-level的控制器。

3.2 Controller关键方法

// 代码位置: client-go/tools/cache/controller.go
// Run 开始处理items，当stopCh被关闭或stopCh收到某个值是将会停止执行。
func (c *controller) Run(stopCh <-chan struct{}) {
   defer utilruntime.HandleCrash()
   go func() {
       <-stopCh
       c.config.Queue.Close()
   }()
   r := NewReflector(             // 创建一个Reflector， 用于ListAndWatch， 从而获取指定资源的当前状态
       c.config.ListerWatcher,    // List/Watch指定的资源对象
       c.config.ObjectType,
       c.config.Queue,
       c.config.FullResyncPeriod,
   )
   r.ShouldResync = c.config.ShouldResync
   r.WatchListPageSize = c.config.WatchListPageSize
   r.clock = c.clock
   if c.config.WatchErrorHandler != nil {
       r.watchErrorHandler = c.config.WatchErrorHandler
   }
145
   c.reflectorMutex.Lock()
   c.reflector = r
   c.reflectorMutex.Unlock()
149
   var wg wait.Group
151
   wg.StartWithChannel(stopCh, r.Run) // r.Run中的最主要的方法就是执行Reflector的ListAndWatch()获取资源对象的值
   // c.ProcessLoop(client-go/tools/cache/controller.go)会从queue中取出资源Delta并进行处理
   wait.Until(c.processLoop, time.Second, stopCh)
   wg.Wait()
}

c.processLoop的实现如下：

func (c *controller) processLoop() {
   for {
       obj, err := c.config.Queue.Pop(PopProcessFunc(c.config.Process))
       if err != nil {
           if err == ErrFIFOClosed {
               return
           }
           if c.config.RetryOnError {
               // This is the safe way to re-enqueue.
               c.config.Queue.AddIfNotPresent(obj)  // Queue是一个DeltaFIFO
           }
       }
   }
}

3.3 Controller小结

有一个FIFO Queue的索引
有一个ListWatcher的索引
通过Pop从FIFO queue中消费资源对象(即: items)
创建Reflector
提供一个proccessLoop处理资源对象以达到期望的状态

另外需要注意的是，不要把tools/cache/controller.go中的Controller与Cumstom Controller混为一谈，两者是完全不同的两个东西。

3.4 Controller示例

前面从“理论”方面对Controller/Informer做了简单的介绍，俗话说的好“纸上得来终觉浅，绝知此事要耕行”，建议学完上面的理论后，还是结合下面例子在实践中再体会一下。

Controller的工作流程：请参考: client-go/tools/cache/controller_test.go: Example()

欢迎关注我的微信公众号：

kubernetes内部机制

2020-11-08T00:00:00+00:00

摘要：kubernetes内部机制简介。

1. 写在前面

个人主页: https://gzh.readthedocs.io

关注容器技术、关注Kubernetes。

问题或建议，请公众号（double12gzh）留言。

Kubernetes是一个容器编排引擎，设计用于在一组节点（通常称为集群）上托管容器化应用。使用系统建模方法，本系列旨在推进对Kubernetes及其基础概念的理解。对于本篇博文，建议您需要提前对Kubernetes、Kubernetes对象和Kubernetes控制器有所理解。

Kubernetes的特点是声明式容器编排引擎：在声明式系统中，用户向系统提供系统的期望状态的表示。然后，系统考虑当前状态和期望状态，确定从当前状态过渡到期望状态的需要执行哪些命令序列。因此，”声明式系统 “这个术语激发了一个经过计算的、具有明确目的的协调工作的概念，其最终目的是以便从当前状态过渡到期望状态。

然而，这不是Kubernetes的实际工作方式!

Kubernetes并没有根据当前状态和期望状态确定一个经过计算、协调的命令执行序列。相反，Kubernetes仅根据当前状态迭代确定下一个要执行的命令。如果以及无法确定下一条命令时，Kubernetes就达到了稳定状态。

2. 状态转换机制

本段概述了Kubernetes的状态转换语义的抽象模型。接下来的段落概述了一个基于部署对象和部署控制器的具体示例。

fact {
    all k8s : K8s - last | let k8s' = k8s.next {
        some c : NextCommand[k8s] {
            command.source = k8s and command.target = k8s'
        }
    }
    NextCommand[k8s.last] = none
}

上述代码展示了Kubernetes的状态转换语义。给定下一个命令函数，系统将根据当前状态k8s确定下一个命令，将系统从当前状态k8s过渡到下一个状态k8s’。

上述代码中使用到的NextCommand()的实现逻辑如下：

fun NextCommand(k8s : K8s) : set Command {
  DeploymentController.NextCommand[k8s] +
  ReplicaSetController.NextCommand[k8s] +
  ...
}

从概念上讲，NextCommand函数是由每个Kubernetes控制器的NextCommand函数的组成。

pred Steady(k8s : K8s) { NextCommand[k8s] = none }

状态序列以一个状态k8s.last结束，对于这个状态，NextCommand函数没有产生下一条命令，这个状态通常称为稳态。

3. k8s对象

Kubernetes对象存储是一组Kubernetes对象。Kubernetes对象是一些有不同规格的数据记录，称为kind。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gzh-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: mydemo
        image: busybox:latest

如上所示即为一种k8s对象。

4. k8s控制器

每个Kubernetes Controller都会为下一条命令产生输入，一个Controller被实现为一个连续的过程，它根据Kubernetes的当前状态产生后续的命令。

process Controller = "Deployment Controller"
begin
    ControlLoop:
      while TRUE do
        \* The Deployment Controller monitors Deployment Objects
        with d ∈ {d ∈ k8s: d.kind = "Deployment"} do
          \* 1. Enabling Condition
          if Cardinality({r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)}) < 1 then
            \* Reconciling Command
            CREATE([kind |-> "ReplicaSet", spec |-> [replicas |-> d.spec.replicas, template |-> d.spec.template]]);
          end if;
          \* 2. Enabling Condition
          if Cardinality({r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)}) > 1 then
            \* Reconciling Command
            with r ∈ {r \in k8s: r.kind = "ReplicaSet" ∧ match(d.spec.labelSelector, r.meta.labels)} do
               DELETE(r);
            end with;
          end if;
        end with;
      end while;
end process;

上述代码5说明了deployment控制器。控制器监控deployment对象，并对每个对象执行一组条件语句。

条件

如果匹配的ReplicaSet对象少于1个

命令然后，deployment控制器将产生一个创建 ReplicaSet 命令。
条件

如果有超过1个匹配的ReplicaSet对象。

命令然后，deployment控制器将发出删除 ReplicaSet 命令。

从Controller的角度来看，如果Controller的条件都没有启用，Kubernetes就处于稳定状态，也就是说，Controller不会产生任何命令。

5. 级联指令

控制器（可以）级联地相互启用:

给定k8s的状态，如果Kubernetes控制器C被启用，C将执行一个过渡到k8s’的命令。
给定k8s’的状态，如果启用了Kubernetes控制器C’，C’将执行一个过渡到k8s’‘的命令。

图2显示了用户向API服务器提交deployment对象后产生的命令级联。

6. k8s是一个声明式系统吗？

fact {
    all sys : Sys - last | let sys' = sys.next {
        some c : Command {
            command.source = sys and command.target = sys'
        }
    }
    Desired[sys.last]
}

上述代码定义了声明式系统的状态转换机制。给定一个期望状态谓词，系统将确定一个命令序列，使系统从当前状态k8s.first过渡到期望状态k8s.last。

如果我们不把Kubernetes对象解释为事实的记录，而是解释为意图的记录，那么我们就可以认同Kubernetes是一个声明式系统的概念。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gzh-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: mydemo
      image: busybox:latest

例如，我们可以将代码中的deployment对象解释为存在一组3个副本对象的意图，因此对象的

.spec.container[0].image等于busyBox:latest

然而，这一概念并非没有微妙之处：如果将一个对象解释为意图记录，则会出现多个选项。例如，Deployment Object 可以解释为：

应有一个 ReplicaSet 或
有一些pods

根据解释，当前状态可能与所需状态相匹配，也可能不相匹配:

如果有ReplicaSet和可选的Pods或
如果有一个ReplicaSet，并且必须有一组Pods

与我们的解释无关

如果有ReplicaSet对象，K8s与部署对象的关系处于稳定状态（deployment控制器不会产生Commands）。
如果有一组pod对象，K8s与ReplicaSet对象的关系处于稳定状态（ReplicaSet控制器不会产生命令）。

7. 结论

Kubernetes可能被描述为一个声明式系统，而Kubernetes对象可能被描述为意向记录。然而，当你推理Kubernetes和Kubernetes的行为时，你应该记住，Kubernetes不会做出协调的努力来过渡到所需的状态。相反，Kubernetes会做出持续的、不协调的努力来过渡到稳定状态。

欢迎关注我的微信公众号：