kubernetes架构解析
# kubernetes架构解析
# 官方文档相关
# 部署架构相关
目前的部署架构图如下:
由图可知,Kubernetes架构可分为主(Master)节点、从(工作/Worker/Node)节点和数据库Etcd。
主节点为集群的控制单元,一般不会运行业务应用程序,主要包含的组件有Kube-APIServer、Kube-ControllerManager、Kube-Scheduler。
从节点为工作节点,也就是部署应用程序容器的节点,主要包含的组件有Kubelet、Kube-Proxy,当然如果Master节点也要部署容器,也会包含Kubelet、Kube-Proxy这两个组件。
一个集群中可以有很多Node节点,用以保证集群容器的分布式部署用于实现业务的高可用性,也可以有很多Master节点,之后通过一个负载均衡保证集群控制节点的高可用。负载均衡可以使用软件负载均衡Nginx/LVS/HAProxy+KeepAlived或者硬件负载均衡F5等,通过负载均衡对Kube-APIServer提供的VIP即可实现Master节点的高可用,其他组件通过该VIP连接至Kube-APIServer。Etcd集群可以和Master节点部署在同一个宿主机,也可以单独部署,生产环境建议部署大于3的奇数台Etcd节点实现Etcd集群的高可用。
# Master节点
Master节点是Kubernetes集群的控制节点,在生产环境中不建议部署集群核心组件外的任何容器(在Kubeadm安装方式下,系统组件以容器方式运行在Master节点的宿主机上;二进制安装方式下,系统组件以守护进程的方式运行,Master节点可以不运行任何容器),公司业务程序的容器更是不建议部署到Master节点上,以免升级或者维护时对业务造成影响。
Master节点的组件包括:
APIServer:整个集群的控制中枢,提供集群中各个模块之间的数据交换,并将集群状态和信息存储到分布式键-值(key-value)存储系统Etcd集群中。同时,它也是集群管理、资源配额、提供完备的集群安全机制的入口,为集群各类资源对象提供增删改查以及watch的REST API接口。APIServer作为Kubernetes的关键组件,使用Kubernetes API和JSON over HTTP提供Kubernetes的内部和外部接口。
Scheduler:集群Pod的调度中心,主要通过调度算法将Pod分配到最佳的Node节点,它通过APIServer监听所有Pod的状态,一旦发现新的未被调度到任何Node节点的Pod(PodSpec.NodeName为空),就会根据一系列策略选择最佳节点进行调度,对每一个Pod创建一个绑定(Binding),然后被调度的节点上的Kubelet负责启动该Pod。Scheduler是集群可插拔式组件,它跟踪每个节点上的资源利用率以确保工作负载不会超过可用资源。因此,Scheduler必须知道资源需求、资源可用性以及其他约束和策略,例如服务质量、亲和力/反关联性要求、数据位置等。Scheduler将资源供应与工作负载需求相匹配以维持系统的稳定和可靠性,因此Scheduler在调度的过程中需要考虑公平、资源高效利用、效率等方面的问题。
Controller Manager:集群状态管理器(它的英文直译名为控制器管理器),以保证Pod或其他资源达到期望值。当集群中某个Pod的副本数或其他资源因故障和错误导致无法正常运行,没有达到设定的值时,Controller Manager会尝试自动修复并使其达到期望状态。Controller Manager包含NodeController、ReplicationController、EndpointController、NamespaceController、ServiceAccountController、ResourceQuotaController、ServiceController和TokenController等,该控制器管理器可与API服务器进行通信,以在需要时创建、更新或删除它所管理的资源,如Pod、服务断点等。Scheduler和Controller Manager虽然部署了多个节点,但同时工作的节点只有一个,因为Scheduler和Controller Manager属于有状态服务,为了防止重复调度,多个节点的Scheduler和Controller Manager进行了选主工作,工作节点(主节点)信息保存在Scheduler和Controller Manager的EndPoint中,可以通过
kubectl describe ep kube-scheduler kube-controller-manager -n kube-system
查看(Kubernetes 1.20版本以上需要在leases中查看:kubectl get leases -n kube-system
)。Etcd:由CoreOS开发,用于可靠地存储集群的配置数据,是一种持久型、轻量型、分布式的键-值(key-value)数据存储组件。Etcd作为Kubernetes集群的持久化存储系统,集群的灾难恢复、状态信息存储都与其密不可分,所以在Kubernetes高可用集群中,Etcd的高可用是至关重要的一部分,在生产环境中建议部署大于3的奇数个数的Etcd,以保证数据的安全性和可恢复性。Etcd可与Master组件部署在同一个节点上,大规模集群环境下建议部署在集群外,并且使用高性能服务器来提高Etcd的性能和降低Etcd同步数据的延迟。
# Node节点
Node节点也被称为Worker、Node和Minion,是主要负责部署容器(工作负载)的单机(或虚拟机),集群中的每个节点都必须具备容器的Runtime(运行时),比如Containerd或其他遵循CRI标准的Runtime等。
Kubelet作为守护进程运行在Node节点上,负责监听该节点上所有的Pod,同时负责上报该节点上所有Pod的运行状态,确保节点上的所有容器都能正常运行。当Node节点宕机或故障(NotReady状态)时,该节点上运行的Pod会被自动转移到其他节点上。
Node节点包括:
- Kubelet:负责与Master通信协作,管理该节点上的Pod,对容器进行健康检查及监控,同时负责上报节点和节点上面Pod的状态。
- Kube-Proxy:负责各Pod之间的通信和负载均衡,将指定的流量分发到后端正确的机器上。
- Containerd:Containerd引擎,负责对容器的管理。
其他组件及工具:
- CoreDNS:用于Kubernetes集群内部Service的解析,可以让Pod把Service名称解析成Service的IP,然后通过Service的IP地址连接到对应的应用上。
- Calico:符合CNI标准的一个网络插件,它负责给每个Pod分配一个不会重复的IP,并且把每个节点当作一个“路由器”,这样一个节点的Pod就可以通过IP地址访问其他节点的Pod。