企业级运维之云原生与Kubernetes实战课程
第三章第4讲 阿里云ACK集群控制器
视频地址：https://developer.aliyun.com/learning/course/913/detail/14605
目录
- 控制器列表
- kube-controller-manager
- cloud-controller-manager
- kube-proxy
- 最佳实践
一、控制器列表
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件(例如：当不满足部署的replicas字段时，启动新的Pod)。
1. 控制器列表
2. 控制器分类
3. Kube-scheduler
Kube-scheduler是比较常用的控制器组件，负责监听Kube API server，比如新创建的、未指定运行节点(Node)的 Pods，并基于其约束和可用资源为这些Pods选择适合的节点。
调度决策需要考虑的因素：
- 如何保障每个节点都会被分配，使资源得以高效利用；
- 调度性能高，可尽快完成大批量调度工作；
- 允许用户根据自身需求设定调度策略。
二、Kube Controller Manager（KCM）
Kube Controller Manager是Kubernetes集群内部资源的管理器，通过API服务器监控集群的状态，确保集群处于预期的工作状态。
Kube Controller Manager由负责不同资源的多个控制器构成，包含：Node Controller、ReplicaSet、Endpoints Controller、Deployment Controller、ServiceAccount&TokenController等。
1. Node Controller
Node Controller负责在节点出现故障时进行通知和响应。
2. ReplicaSet Controller
ReplicaSet Controller负责为系统中的每个副本控制器对象维护正确数量的Pod。
3. Endpoints Controller
Endpoints Controller负责填充端点（Endpoints）对象（即加入Service与Pod），比如：如果监测到Pod事件（新建或更新），则更新它对应的Service Endpoints对象。
4. Deployment Controller
Deployment Controller负责管理Deployment资源。
5. ServiceAccount&TokenController
ServiceAccount&TokenController负责为新的命名空间创建默认账户和API访问令牌。
三、Cloud Controller Manager（CCM）
Cloud Controller Manager提供Kubernetes与阿里云基础产品的对接能力，例如CLB(原SLB)、VPC等。
1. CCM主要功能
CCM主要提供以下两方面功能：
- 管理负载均衡
当Service的类型设置为Type=LoadBalancer时，CCM组件会为该Service创建或配置阿里云负载均衡CLB，包括含CLB、监听、后端服务器组等资源。当Service对应的后端Endpoint或者集群节点发生变化时，CCM会自动更新CLB的后端虚拟服务器组；
- 实现跨节点通信
当集群网络组件为Flannel时，CCM组件负责打通容器与节点间网络，实现容器跨节点通信。CCM会将节点的Pod网段信息写入VPC的路由表中，从而实现跨节点的容器通信。该功能无需配置，安装即可使用。
2. CCM组件
a. Node Controller
Node Controller用于在节点发生变化时自动更新CLB的后端。
b. Route Controller
Route Controller用于在底层云基础架构中设置路由。
c. Service Controller
Service Controller用于创建、更新和删除云提供商负载均衡器。
四、kube-proxy
kube-proxy是Node上的网络代理组件，以DamonSet的形式工作在每一个节点，是实现Service负载均衡的控制器。
kube-proxy支持iptables和ipvs两种模式，Kube-proxy的作用是管理Service的endpoint，更新endpoint到iptables或ipvs中。
ipvs模式和iptables模式之间的差异如下：
- ipvs为大型集群提供了更好的可扩展性和性能，当服务大于1000时，ipvs的性能明显优于iptables；
- ipvs支持比iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）；
- ipvs支持服务器健康检查和连接重试等；
因此，目前更推荐使用ipvs模式。
五、最佳实践
1. 实践场景描述
SLB设置了externalTrafficPolicy:Local类型，这种类型的SLB地址只有在Node中部署了对应的后端Pod，才能被访问。因为 SLB的地址是集群外使用，如果集群节点和Pod不能直接访问，请求不会到SLB，会被当作Service的扩展IP地址，被kube-proxy的iptables或ipvs转发。
2. 解决方案
方案一：
在Kubernetes集群内通过ClusterIP或者服务名访问。
方案二：
将LoadBalancer的Service中的externalTrafficPolicy修改为cluster，但是在应用中会丢失源IP，Ingress的服务修改命令如下：
kubectl edit svc nginx-ingress-b-nkube-system
- 如果要保留原IP，Pod需要用hostnetwork方式，在Pod的spec里加上: dnspolicy: ClusterFirstWithHostNet
hostNetwork: true
service的metadata里加上:
annotations:
servicebeta.kubenetes.io/bACKend-type: eni
- 如果是terway集群，除了将LoadBalancer的Service中的externalTrafficPolicy修改为Cluster之外，还要直挂eni:添加service.beta.kubernetes.io/bACKend-type: eni
本讲小结
1. 集群中核心控制器的基本作用。
2. Kube-proxy负载均衡的原理。
思考：
1. 为什么集群内无法访问service的externalIP，该怎么解决？
2. 添加新的节点，Pod网络不通，该怎么排查？
3. service的几种类型，kube-proxy如何实现负载均衡的？
