本文是关于Kubernetes service解析的第一章
- 深入理解Kubernetes service - 你真的理解service吗?
- 深入理解Kubernetes service - EndpointSlices做了什么?
- 深入理解Kubernetes service - kube-proxy架构分析
- 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构
所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy
前景
对于了解kubernetes架构时,已知的是 service
是kubernetes在设计时为了避免Pod在频繁创建和销毁时IP变更问题,从而给集群内服务(一组Pod)提供访问的一个入口。而Pod在这里的角色是 『后端』( backend ) ,而 service 的角色是 『前端』( frontend )。本文将阐述service的生命周期
为什么需要了解这部分内容呢
对于 without kube-proxy来说,这部分是最重要的部分,因为service的生成不是kube-proxy来完成的,而这部分也就是service ip定义的核心。
控制器
service的资源创建很奇妙,继不属于 controller-manager
组件,也不属于 kube-proxy
组件,而是存在于 apiserver
中的一个被成为控制器的组件;而这个控制器又区别于准入控制器。更准确来说,准入控制器是位于kubeapiserver中的组件,而 控制器 则是存在于单独的一个包,这里包含了很多kubernetes集群的公共组件的功能,其中就有service。这也就是在操作kubernetes时 当 controller-manager
于 kube-proxy
未工作时,也可以准确的为service分配IP。
首先在构建出apiserver时,也就是代码 cmd/kube-apiserver/app/server.go
|
|
master.ServiceIPRange 承接了为service分配IP的功能,这部分逻辑就很简单了
|
|
而后kube-apiserver为service分为两类
- apiserver 地址在集群内的service,在代码中表示为 APIServerServiceIP
- Service,
--service-cluster-ip-range
配置指定的ip,通过『逗号』分割可以为两个
有了对 service 更好的理解后,接下来开始本系列第二节深入理解Kubernetes service - kube-proxy软件架构分析
Reference