开发者学堂课程【企业级运维之云原生与 Kubernets 实战课程：阿里云 ACK 集群控制器 】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/913/detail/14605
阿里云 ACK 集群控制器
目录
Ÿ 控制器列表
Ÿ 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 之外，还要直挂e ni :添加 service.beta.kubernetes.io/bACKend-type: eni
本讲小结
1. 集群中核心控制器的基本作用。
2. Kube-proxy 负载均衡的原理。
思考：
1. 为什么集群内无法访问 service 的 externalIP，该怎么解决？
2. 添加新的节点，Pod 网络不通，该怎么排查？
3. service 的几种类型，kube-proxy 如何实现负载均衡的？
