本文QQ空间链接：http://user.qzone.qq.com/29185807/blog/1460620187

本文csdn链接：http://blog.csdn.net/screscent/article/details/51152192

kube-proxy是kubernetes中 service的负载均衡器和服务代理器。kube-proxy运行在Minion上，本文主要讲解，proxy如何获取ServiceConfig 和EndpointsConfig

 

源码在k8s.io\kubernetes\cmd\kube-proxy\app中

func NewProxyServerDefault(config *ProxyServerConfig) (*ProxyServer, error) {

从上面的代码来看在NewProxyServerDefault中就构建了ServiceConfig与EndpointsConfig

在ServiceConfig注册了一个事件监听者serviceConfig.RegisterHandler(proxier)

在EndpointsConfig注册了一个事件监听者endpointsConfig.RegisterHandler(endpointsHandler)

 

那么我们现在就一步一步来拆解

 

1、构建serviceConfig

代码在k8s.io\kubernetes\pkg\proxy\config

  

从上面来看，有三个东西

mux bcaster：这两个的分析可以见文章（k8s源码分析-----Mux And Broadcaster）

 

 

下面我们看看serviceStore

我们看到serviceStore是一个Merge，被传进了mux

注：如果不了解mux的，请先看文章（k8s源码分析-----Mux And Broadcaster）

 

在NewServiceConfig的时候开启了一个协程运行函数

 

ok，我们再看看serviceStore

merge函数，用来合并生产者发送来的物品，并做处理。

那么在这里就是对service的信息做处理，有add，remove，set等操作

在处理完之后，则发送消息到了updates chan

现在回到函数watchForUpdates，接收到updates的信号，

则bcaster.Notify(accessor.MergedState())

其实这里就是广播了一个信号

将services广播给了所有监听的事件。

我们看看事件的注册

在源码在k8s.io\kubernetes\cmd\kube-proxy\app中

func NewProxyServerDefault(config *ProxyServerConfig) (*ProxyServer, error) {

serviceConfig.RegisterHandler(proxier)

 

小结：

serviceConfig是一个中间件，将生产者发送过来的service进行简单处理，然后通过广播告诉所有的事件来进行更新service信息。

 

2、构建EndpointsConfig

endpointConfig代码和serviceConfig类似的

上面依旧是三个成员mux bcaster endpointstore

 下面是endpointstore的merge

提供了add remove set操作

操作完之后发送updates信号

这个就是广播传送的东西

 

小结：

endpointConfig和serviceConfig一样也是一个中间件，将生产者发送过来的endpoint信息进行简单处理，然后通过广播告诉所有的事件来进行更新endpoint信息。

 

3、NewSourceAPI service和endpoint的生产者

 

上面我们讲解了serviceConfig和endpointConfig的中间件，下面我们讲下，真正的信息生产者

在k8s.io\kubernetes\cmd\kube-proxy\app中

func NewProxyServerDefault(config *ProxyServerConfig) (*ProxyServer, error) {

 

分别对serviceConfig和endpointConfig注册了两个chan

我们看看serviceConfig的这个函数，生成了一个chan，return了，并开了一个协，用于接收数据，并发送到了mux的chan中。如果不清楚mux的这个作用的，还请看之前文章

ok传送接口对号了

 

我们继续跟踪进去看

生成了两个listwatcher

 

然后继续跟踪

生成了一个NewReflector（这个之前的文章也有分析过）就是一个生产者。这里是service信息的生产者

这里是endpoint信息的生产者

 

 

小结：

通过构建两个listwatcher，然后构建了两个信息的生产者，通过向serviceConfig和endpointConfig注册的chan，来进行信息的传递。

 

 

4、总结

总体架构非常清晰，各司其职。通过listwatcher构建信息的生产者，然后通过chan将信息传递给中间件serviceConfig和endpointConfig，然后分别对service和endpoint信息进行处理。接着触发事件，广播到事件监听者。

 

 

龚浩华

QQ 月牙寂 道长 29185807

2016年4月14日

（版权声明：本文为作者原创，如需转载请通知本人，并标明出处和作者。擅自转载的，保留追究其侵权的权利。）

 

如果你觉得本文对你有帮助，可以转到你的朋友圈，让更多人一起学习。

第一时间获取文章，可以关注本人公众号：月牙寂道长，也可以扫码关注