k8s源码分析-----kube-proxy(1)Config

说明:此文章为腾讯云机器自动从本人csdn博客搬迁过来。是本人授权操作。

申明:无本人授权,不可转载本文。如有转载,本人保留追究其法律责任的权利。

龚浩华,QQ 29185807,月牙寂 道长

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

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信息进行处理。接着触发事件,广播到事件监听者。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区