k8S由google的Borg系统(博格系统,google内部使用的大规模容器编排工具)作为原型,后经G0语言延用Borg的思路重写并捐献给CNCF基金会开源
词根源于希腊语的舵手、飞行员
官网(官方文档):
https://kubernetes.io
GitHub(软件包):
https://github.com/kubernetes/kubernetes
1.试想下传统的后端部署办法:把程序包(包括可执行二进制文件、配置文件等)放到服务器上,接着运行启动脚本把程序跑起来,同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序
2.设想一下,如果服务的请求量上来,已部署的服务响应不过来怎么办?传统的做法往往是,如果请求量、内存、CPU超过阈值做了告警,运维人员马上再加几台服务器,部署好服务之后,接入负载均衡来分担已有服务的压力
3.这样问题就出现了:从监控告警到部署服务,中间需要人力介入! 那么,有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢?
而这就是K8S要做的事情: 自动化运维管理容器(Docker) 程序。K8s的目标是让部署容器化应用简单高效
==========================================================
K8S解决了裸跑Docker的若干痛点:
1.单机使用,无法有效集群
2.随着容器数量的.上升,管理成本攀升
3.没有有效的容灾、自愈机制
4.没有预设编排模板,无法实现快速、大规模容器调度
5.没有统一 的配置管理中心工具
6.没有容器生命周期的管理工具
7.没有图形化运维管理工具
==========================================================
k8s提供了容器编排,资源调度,弹性伸缩,部署管理,服务发现等一系列功能
master节点的请求处理过程:
1)首页用户通过证书认证后使用kubectl命令行工具向API Server发送请求,API Server接收到请求后会写入到etcd中,API Server会让Controller-manager按照所预设的模板(多少实例、生命周期等)去创建Pod,Controller-manager通过 API Server读取etcd中用户的预设信息,再通过API Server去找 Scheduler可以为新创建的Pod选择最适合的Node节点。scheduler会通过API Server在Etcd存储中心中找到node节点存储的元信息、剩余资源等,通过预算策略和优选策略在所有Node节点中挑选最优的
2)scheduler确定node节点后通过API Server交给这个Node节点上的kubelet进行pod资源的创建,kubelet同时也会对所在node的资源信息和pod状态进行监控与API server进行交互将pod状态信息存储到etcd中
3)node节点上的kube-proxy是service资源的载体,负责pod的代理和负载均衡等功能,如果需要将pod发布出去,需要通过kube-proxy创建网络规则承载使用service作为负载均衡的访问入口,负载均衡所关联的pod节点,实现服务发布
Service作用于哪些Pod是通过标签选择器来定义的:
在K8S集群中,Service可以看作一组提供相同服务的Pod的对外访问接口。客户端需要访问的服务就是Service对象。每个Service都有一个固定的虚拟ip (这个ip也被称为Cluster IP) ,自动并且动态地绑定后端的Pod, 所有的网络请求直接访问Service的虚拟ip,Service会自动向后端做转发。通俗来说就是Service通过标签选择器选择那些关联了对应label的Pod,把Pod的IP加入到自己的endpoints当中,当service收到请求后根据endpoints里的ip进行转发
客户端具体访问流程:
客户端使用http/https通过url路径访问K8S集群里的Ingress接入层对外暴露的接口,Ingress层收到请求后找到对应是Service,Service根据标签选择器筛选查询label对应的Pod,根据Pod的IP进行转发获取相应服务
1.用于暴露Kubernetes API,任何资源请求或调用操作都是通过kube-apiserver提供的接口进行。以HTTP Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给API Server处理后再提交给Etcd存储
2.可以理解成API Server是K8S的请求入口服务。API Server 负责接收K8S所有请求(来自UI界面或者CLI命令行工具),然后根据用户的具体请求,去通知其他组件干活。可以说API Server是K8S集群架构的大脑
1.运行管理控制器,是K8S集群中处理常规任务的后台线程,是K8S集群里所有资源对象的自动化控制中心。
2.在K8S集群中,一个资源对应一个控制器,而Controller manager就是负责管理这些控制器的
3.由一系列控制器组成,通过APIServer监控整个集群的状态,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态
#控制器类型
1.Node Controller(节点控制器):负责在节点出现故障时发现和响应
2.Replication Controller (副本控制器) :负责保证集群中一个RC (资源对 象Replication Controller) 所关联的Pod
副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例,N是RC中定义的Pod副本数量
3.Endpoints Controller (端点控制器) :填充端点对象 (即连接Services 和Pods) ,负责监听 Service 和对应的Pod副本的变化
可以理解端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的endpoint
4.Service Account & Token Controllers ( 服务帐户和令牌控制器) :为新的命名空间创建默认帐户和API访问令牌
5.ResourceQuota Controller(资源配额控制器):确保指定的资源对象在任何时候都不会超量占用系统物理资源
6.Namespace Controller ( 命名空间控制器) :管理namespace的生命周期
7.Service Controller (服务控制器) :属于K8S集群与外部的云平台之间的一个接口控制器
是负责资源调度的进程,根据调度算法为新创建的Pod选择-一个合适的Node节点
可以理解成K8S所有Node节点的调度器。当用户要部署服务时Scheduler 会根据调度算法选择最合适的Node节点来部署Podo
●预算策略(predicate)
●优选策略(priorities)
K8S的存储服务。etcd是分布式键值存储系统,存储了K8S的关键配置和用户配置,K8S中仅API Server才具备读写权限,其他组件必须通过
API Server的接口才能读写数据。
1.Node节点的监视器,以及与Master节点的通讯器。Kubelet 是Master节点安插在Node节点上的“眼线”,它会定时向API Server汇报自己Node节点上运行的服务的状态,并接受来自Master节点的指示采取调整措施
2.从Master节点获取自己节点上Pod的期望状态(比如运行什么容器、运行的副本数量、网络或者存储如何配置等),
直接跟容器引擎交互实现容器的生命周期管理,如果自己节点上Pod的状态与期望状态不一致,则调用对应的容器平台接口(即docker的接口)达到这个状态
3.管理镜像和容器的清理工作,保证节点上镜像不会占满磁盘空间,退出的容器不会占用太多资源
1.在每个Node节点上实现pod网络代理,是Kubernetes Service资源的载体,负责维护网络规则和四层负载均衡工作。负责写入规则至iptables(默认)、ipvs(最新)实现服务映射访问的
2.Kube-Proxy本身不是直接给Pod提供网络,Pod的网络是由Kubelet 提供的,Kube-Proxy 实际上维护的是虚拟的Pod集群网络
3.Kube-apiserver通过监控Kube-Proxy进行对Kubernetes Service 的更新和端点的维护
4.在K8S集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器,在K8S的每个节点上都会运行一个Kube-proxy组件
容器引擎,运行容器,负责本机的容器创建和管理工作
=========================Master节点========================
1.apiserver:所有服务访问的同一入口
2.controller manager:维持集群处于预期的工作状态(副本期望数目)
3.scheduler:选择适合的node节点调度pod
4.master节点的请求处理过程:
1)首页用户通过证书认证后使用kubectl命令行工具向API Server发送请求,API Server接收到请求例如创建一批Pod,API Server会让 Controller-manager按照所预设的模板(多少实例、生命周期等)去创建Pod,Controller-manager会通过API Server去找Scheduler为新创建的Pod选择最适合的Node节点。比如运行这个Pod需要2C4G的资源,scheduler会通过API Server在Etcd存储中心中找到node节点存储的元信息、剩余资源等,通过预选策略在所有Node节点中挑选最优的,然后将预设的模板通过API Server交给这个Node节点上运行
2)Node节点中还剩多资源是通报给APT Server存储在etcd里,API Server会调用一个方法找到etcd里所有Node节点的剩余资源,再对比Pod所需要的资源,在所有Node节点中查找哪些Node节点符合要求。如果都符合,预算策略就交给优选策略处理,优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node节点,并把Pod调度到这个Node节点上运行
=========================Etcd储存中心======================
etcd:键值对数据库,存储k8s集群所有的重要信息,并持久化保持,只有apiserver才能对etcd有读写权限
=========================Worker Node节点===================
1.kubelet:监视node节点上的资源和服务状态并汇报给apiserver;跟容器引擎交互实现容器的生命周期管理
2.kube-proxy:实现负载均衡,是server资源的载体,负责写入规则至iptables、ipvs实现服务映射访问的容器引擎:docker,docker用来创建、管理容器
1.Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod 代表集群上正在运行的一个进程,可以把Pod理解成豌豆荚,而同一Pod内的每个容器是一颗颗豌豆
2.一个Pod由一个或多个容器组成,Pod中容器共享网络、存储和计算资源,在同一台Docker主机上运行
3.一个Pod里可以运行多个容器,又叫边车模式(sideCara) 模式。而在生产环境中一般都是单个容器或者具有强关联互补的多个容器组成一个Pod
4.同一个Pod之间的容器可以通过localhost互相访问,并且可以挂载Pod内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问,也不能挂载其他Pod的数据卷
1)Deployment:无状态应用部署。Deployment 的作用是管理和控制Pod和Replicaset, 管控它们运行在用户期望的状态中
2)Replicaset: 确保预期的Pod副本数量。Replicaset的作用就是管理和控制Pod,管控他们好好干活。但是,Replicaset受控于Deployment
可以理解成Deployment 就是总包工头,主要负责监督底下的工人Pod干活,确保每时每刻有用户要求数量的Pod在工作,如果一旦发现某个工人Pod不行了,就赶紧新拉一个Pod过来替换它。而ReplicaSet就是总包工头手下的小包工头。从K8S使用者角度来看,用户会直接操作Deployment部署服务,而当Deployment被部署的时候,K8S会自动生成要求的ReplicaSet和Pod。用户只需要关心Deployment而不操心ReplicaSet
资源对象Replication Controller是ReplicaSet的前身,官方推荐用Deployment取代Replication Controller来部署服务
3)Daemonset: 确保所有节点运行同一类Pod,保证每个节点上都有一个此类Pod运行,通常用于实现系统级后台任务
4)Statefulset:有状态应用部署
5)Job: 一次性任务。根据用户的设置,Job管理的Pod把任务成功完成就自动退出了
6)Cronjob: 周期性计划性任务
1、用户通过客户端发送请求给API server,API Server 接收请求创建一批Pod,会存储pod数据到etcd
2、Controller-manager 通过API Server 到etcd中读取按照预设的模板去创建Pod,Controller-manager 又会通过API Server让Scheduler为新创建的Pod 根据预算策略以及优选策略,选择最适合的Node 节点把pod调度过来
3、scheduler通过Api server来让Kubelet根据调度结果执行Pod创建操作,并且对node节点进行监视,会定时向api server汇报自己node节点运行的服务状态,并且存储到etcd中。在这期间,Controller Manager同时会根据K8S的mainfiles文件执行RC Pod的数量来保证指定的Pod副本数
4、在每个node上都会有一个kube-proxy,来实现pod的网络代理,它是Kubernetes Service 资源的载体。在任何一个节点上访问一个service的虚拟ip,都可以访问到pod,提供cluster ip的访问入口
所有Node上运行的Proxy进程通过APIServer查询并监听service对象与其对应的Endponts信息,建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能