当前位置: 首页 > 科技观察

K8s集群架构及高可用分析

时间:2023-03-13 04:27:07 科技观察

基本工作流程Kubernetes的核心工作流程:资源对象:Node、Pod、Service、ReplicationController等可以看成是对资源对象的操作:通过使用kubectl工具,执行增删改查存储:对象的目标状态(预设状态)存储在etcd中进行持久化存储;自动控制:跟踪并比较存储在etcd中的目标状态与资源的当前状态,针对不同的资源进行偏差修正,自动控制集群状态。Kubernetes实际上是一个高度自动化的资源控制系统,它将它管理的一切抽象为资源对象,从服务器Node节点到服务实例Pod。Kubernetes的资源控制是一个语句+引擎的概念:语句:对于某个资源,声明其目标状态自动:Kubernetes自动资源控制系统会一直尝试将资源对象维持在目标状态。架构(物理+逻辑)Kubernetes集群是主从架构:Master:管理节点,对集群进行控制和调度Node:worker节点,执行具体的业务容器下面的组件是独立的进程,每个进程都是用Go语言编写的,而实际部署Kubernetes集群就是部署这些程序。主节点:kube-apiserverkube-controller-managerkube-scheduler节点节点:kubeletkube-proxy具体来说,具有两种角色的节点需要运行的进程和职责不同,具体描述如下。Master管理节点:管理整个Kubernetes集群,接收外部命令,维护集群状态。apiserver:KubernetesAPIServer集群控制的入口点,对资源进行增删改查,持久化存储在etcd中kubectl直接与APIServer交互,默认端口为6443。etcd:一个高可用的key-value存储系统功能:存储资源状态,支持RestfulAPI。默认监听2379和2380端口(2379提供服务,2380用于集群节点通信)(问题:集群节点,是指etcd集群?master集群?)scheduler:负责将pod资源调度到合适的节点。调度算法:根据node节点的性能、负载、数据位置等进行调度。默认监听10251端口。controller-manager:所有资源的自动控制中心每个资源对应一个controller(问题:作用是什么?)controllermanager管理这些controller。controllermanager是自动循环控制器Kubernetes的核心控制守护进程。默认监听10252端口。(问题:为什么会有监控部分的感觉?)补充说明:scheduler和controller-manager都是通过apiserver从etcd获取各种资源的状态,并进行相应的调度和控制操作。Node节点:Master节点,将任务调度到Node节点,以docker方式运行;当Node节点宕机时,Master会自动将Node上的任务调度到其他Node上。kubelet:本节点上Pod的生命周期管理,定期向Master上报本节点和Pod的基本信息kubelet不会管理非Kubernetes创建的容器定期向Master上报信息,比如操作系统,Docker版本、CPU、内存、pod运行状态等信息给agent。反向代理:支持TCP和UDP连接转发,默认基于RoundRobin算法将客户端流量转发到服务对应的一组后端Pod。服务发现:利用etcd的watch机制监控集群中服务和端点对象数据的动态变化,维护服务到端点的映射关系。(本质是:路由关系)实现方式:实现方式有两种,userspace和iptables。userspace:在用户空间,使用kuber-proxy实现负载均衡代理服务,是最初的实现方案,比较稳定,效率不高;iptables:在内核空间,LB是纯粹通过iptables实现的,这是目前Kubernetes默认的方式;runtime:一般使用docker容器,也支持其他容器。集群的高可用Kubernetes集群在生产环境中必须实现高可用:实现Master节点及其核心组件的高可用;如果Master节点出现问题,整个集群就会失去控制;具体HA图:以上方法可以作为HA使用,但目前还不成熟。据了解,HA的功能未来还会进行更新升级。具体工作原理:etcd集群:部署3个Master节点,每个Master节点的etcd组成一个集群入口集群:在3个Ma??ster节点上,在APIServer前面放置一个负载均衡器。工作节点和客户端通过这个负载均衡器与APIServer通信。pod-master保证只有主master可用。集群中只有一个scheduler和controller-manager实例,其他都是备用的