本文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日

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

 

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

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

 

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐