ggaaooppeenngg

csi 是一个标准的容器存储接口，规定了如何实现一个容器的存储接口，CSI 本身的定义是基于 gRPC 的，所以有一套样例库可以使用，这里分析一下 kuberntes 实现 csi 的方式，为了兼容 CSI kubernete 其实搞得挺绕的，目前这个 CSI 还是定制中包括后期的 Snapshot 的接口怎么设计等等还在讨论中。kubernetes CSI 主要基于几个外部组件和内部功能的一些改动。

kube-proxy 是一层代理，主要用于实现 Service 这个 Object。

Service 有一个 ClusterIP，这是一个虚拟 IP 应对 Service 后面的 pod，pod 的销毁和创建会有 ip 不固定的问题。除了能够屏蔽后端的 pod 的 IP 之外，Service 还可以有负载均衡的作用。

Endpoint 维护的是 Service 和 Pod 的映射关系，如果 pods 变动，Endpoint 也会变动。Service 本身指定义了 ClusterIP 和 port 的映射。Endpoints 记录了 pod 的 ip 和端口。

主要的访问方式是通过 NAT 实现的，如果使用 iptables 的话，就设置匹配目标端口以后，DNAT 转发到目的地址。

我看代码的时候，发现有个函数叫 birth cry 挺有意思的，表示打程序启动的一条 log。

Kube-proxy 主要监听两个对象，一个是 Service，一个是 Endpoint

这些 Objects 对应的处理函数有不同的实现，现在先看一下 iptables 的实现

当 Service 有更新的时候就会更新对应的 iptables 规则。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func (c *ServiceConfig) Run(stopCh <-chan struct{}) {
        defer utilruntime.HandleCrash()

        glog.Info("Starting service config controller")
        defer glog.Info("Shutting down service config controller")

        if !controller.WaitForCacheSync("service config", stopCh, c.listerSynced) {
                return
        }

        for i := range c.eventHandlers {
                glog.V(3).Infof("Calling handler.OnServiceSynced()")
                c.eventHandlers[i].OnServiceSynced()
        }

        <-stopCh
}

会调用 OnServiceSynced，然后具体调用实现者的方法。

glusterfs 主要有以下几个组件

• gluster 命令行。
• glusterd 管理进程。
• glusterfsd 服务进程。
• glusterfs 客户端 fuse 进程。