Kubernetes核心组件运行机制

三杯水Plus

发布于 2021-04-19 15:26:23

4610

发布于 2021-04-19 15:26:23

文章被收录于专栏：运维

Kubernetes架构

Kubernets核心组件

API Server
Controller Manager
Scheduler
Kubelet
Kube-Proxy
Etcd

Kubernetes API Server原理解析

总体来看，Kubernetes API Server的核心功能是提供Kubernetes各类资源对象（如Pod、RC、Service等）的增、删、改、查及Watch等HTTP Rest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还有以下一些功能特性。（1）是集群管理的API入口。（2）是资源配额控制的入口。（3）提供了完备的集群安全机制。

API Server架构

Controller Manager原理解析

Controller Manager内部包含ReplicationController、Node Controller、ResourceQuotaController、Namespace Controller、ServiceAccountController、Token Controller、Service Controller及Endpoint Controller这8种Controller，每种Controller都负责一种特定资源的控制流程，而Controller Manager正是这些Controller的核心管理者。

Controller Manager架构图如下

Scheduler原理解析

Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能，“承上”是指它负责接收Controller Manager创建的新Pod，为其安排一个落脚的“家”——目标Node；“启下”是指安置工作完成后，目标Node上的kubelet服务进程接管后继工作，负责Pod生命周期中的“下半生”。具体来说，Kubernetes Scheduler的作用是将待调度的Pod（API新创建的Pod、Controller Manager为补足副本而创建的Pod等）按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中。在整个调度过程中涉及三个对象，分别是待调度Pod列表、可用Node列表，以及调度算法和策略。简单地说，就是通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node。随后，目标节点上的kubelet通过API Server监听到KubernetesScheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器。完整的流程图如下：

Kubelet运行机制解析

在Kubernetes集群中，在每个Node（又称Minion）上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程都会在APIServer上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。

Kube-proxy运行机制解析

起初，kube-proxy进程是一个真实的TCP/UDP代理，类似HAProxy，负责从Service到Pod的访问流量的转发，这种模式被称为userspace（用户空间代理）模式。当某个Pod以Cluster IP方式访问某个Service的时候，这个流量会被Pod所在本机的iptables转发到本机的kube-proxy进程，然后由kube-proxy建立起到后端Pod的TCP/UDP连接，随后将请求转发到某个后端Pod上，并在这个过程中实现负载均衡功能。

Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。

Kubernetes从1.8版本开始引入第3代的IPVS（IP Virtual Server）模式。IPVS在Kubernetes 1.11中升级为GA稳定版。iptables与IPVS虽然都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为第三代模式。