目录
一、K8S概述
1、什么是K8S
2、为什么要用K8S
3、作用及功能
二、K8S的特性
1、弹性伸缩
2、自我修复
3、服务发现和复制均衡
5、自动发布和回滚
6、集中化配置管理和秘钥管理
7、存储编排
8、任务批量处理运行
三、K8S的集群架构
四、K8S的核心组件
1、Master组件
①Kube-apiserver
②Kube-controller-manager
③Kube-scheduler
2、配置存储中心etcd
3、Node组件
①Kubelet
②Kube-Proxy
③docker或rocker
4、K8S三种负载均衡模式
5、K8S架构工作流程
6、K8S的核心概念
①Pod
②Pod控制器
7、Label标签
8、Label选择器(Label selector)
9、Service
10、Ingress
一、K8S概述
1、什么是K8S
K8S全程为Kubernetes,由于K到S直接有8个字母简称为K8S。
版本:目前一般是1.18~1.2.0,后续可能会到1.24-1.26,1.24版本后丢弃了docker(如需要使用需要第三方插件配合),目前最新版本是1.27
官网:https://kubernetes.io
GitHub:GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management
2、为什么要用K8S
①试想下传统的后端部署办法:把程序包(包括可执行二进制文件、配置文件等)放到服务器上,接着运行启动脚本把程序跑起来,同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。
②设想一下,如果服务的请求量上来,已部署的服务响应不过来怎么办?传统的做法往往是,如果请求量、内存、CPu超过阈值做了告警,运维人员马上再加几台服务器,部署好服务之后,接入负载均衡来分担已有服务的压力。
③这样问题就出现了:从监控告警到部署服务,中间需要人力介入!那么,有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢,而这就是K8S要做的事情:自动化运维管理容器化(Docker) 程序。
④解决了docker的以下个问题
●单机使用,无法有效集群
●随着容器数量的上升,管理成本攀升
●没有有效的容灾、自愈机制
●没有预设编排模板,无法实现快速、大规模容器调度
●没有统一的配置管理中心工具
●没有容器生命周期的管理工具
●没有图形化运维管理工具
3、作用及功能
①作用:用于自动部署、扩展、管理编排容器化应用程序。
②功能:容器编排、资源调度、弹性伸缩、部署管理、服务发现等。
二、K8S的特性
1、弹性伸缩
使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例,保证应用高并发时的高可用和业务低峰时回收资源,以最小成本运行服务。
2、自我修复
在节点故障时重新启动失败的容器、替换和重新部署,保证预期的副本数量,杀死健康检查失败的容器,并在未准备好之前不会处理客户端请求,确保线上服务不中断。
3、服务发现和复制均衡
为多容器提供同一的访问入口(内部ip地址和一个dns名称),并且负载均衡关联所有容器,用户无需考虑容器ip问题
5、自动发布和回滚
默认是滚动发布模式(其他二种发布模式,蓝绿发布、灰度发布)。采用滚动更新策略更新应用,一次更新一个Pod而不是同时删除所有Pod如果更新过程中有问题可以回滚更改确保业务升级不受影响
6、集中化配置管理和秘钥管理
管理机密数据和应用程序配置,而不是把敏感数据暴露在镜像中,提高敏感数据安全性、可以将一些常用的配置存储在k8s中,方便应用程序使用
7、存储编排
支持外挂存储并对外挂存储进行编排,挂载外部存储系统,无论是来自本地存储,公有云还是网络存储(NFS、ceph、GlusterFS)都作为集群资源的一部分使用,极大提高存储使用灵活性
8、任务批量处理运行
提供一次性任务,定时任务;满足批量数据处理和分析的场景
三、K8S的集群架构
1、K8S是属于主从设备模型(master-slave架构),master负责集群的调度管理和运维,slave节点是集群中运算工作负载节点,企业中一般最少2台master,多数为3台作为负载。
2、主节点成为master节点,从节点成为worker node节点。每个node都会被master分配任务
3、master可以在任何集群中的计算机上运行,建议给master一台独立的服务器防止master出问题所有控制命令都将实现,worker node节点宕机该机器上的任务会被自动转移其他节点继续运行
四、K8S的核心组件
1、Master组件
①Kube-apiserver
统一请求入口服务组件,所有资源请求或者调用都通过Kube-apiserver入口提供的接口进行,以Http Restful API 提供接口服务,所有对资源的增删改查和监听都交给APIserver处理,然后再交给ETCD存储(键值对存储方式,相当于分布式数据库)。APIserver负责接受所有请求(uI和CLI),然后根据用户具体请求通知其他组件干活,APIserver相当于K8S的大脑
②Kube-controller-manager
运行管理控制器由各种控制器组成,处理常规任务的后台线程,所有资源对象的自动化控制中心。在K8S中一个资源对应一个控制器,controller-manager负责管理这些控制器,通过API server监控整个集群的状态,确保集群处于预期的工作状态,当某个node意外宕机,controlle-manager会及时发现并自动化修复,确保集群处于预期的工作状态。
控制器 | 控制名称 | 控制器作用 |
Node Controller | 节点控制器 | 负责在节点出现故障时发送和响应 |
Replication Controller | 副本控制器 | 负责保证集群中一个RC即资源对象所关联的Pod副本数据始终保持预期值 |
Endpoints Controller | 端点控制器 | 填充端点对象(service和Pods),负责监听service和对应的Pod副本的变化,服务暴露出来的访问点,如果需要访问一个服务必须知道他都Endpoints |
Service Account & Tocken Controller | 服务账户和令牌控制器 | 为新的命名空间创建默认账户和API访问令牌 |
ResourceQuota Controller | 资源配额控制器 | 确保指定的资源对象在任何时候都不会超量占用系统物理资源 |
Namespace Controller | 命名空间控制器 | 管理namespace的生命周期 |
Service Controller | 服务器控制器 | 属于K8S集群与外部云平台之间的一个接口控制器 |
③Kube-scheduler
负责资源调度的进程,根据调度算法(62种算法)为新创建的Pod选择一个合适的Node节点
可以理解成K8s所有Node节点的调度器,当用户要部署服务时,Scheduler会根据调度算法选择最合适的Node节点来部署Pod。
预选策略(predicate):首选过滤掉资源不满足的node
优选策略(priorities):预选后的满足的节点进行打分排名选择最优的node
2、配置存储中心etcd
etcd:K8s的存储服务,是分布式键值存储系统,最少三台最优为8G内存。存储了K8S的关键配置和用户配置并且持久化保存,K8s中仅有API server才具有读写权限,其他组件必须通过API server的接口才能读写数据。端口为2379和2380,2379用于对外客户的提供通信,2380用于对集群服务器间内部的通信
3、Node组件
①Kubelet
Node节点的监视器,以及与Master节点的通讯器。Kubelet是Master节点安插在Node节点的眼线,会定时向API server汇报自己Node节点上运行服务的状态,并接受来自Master节点的指示采取调整措施(例如创建Pod)。
从Master节点获取自己节点上Pod的期望状态(例如运行什么容器、运行的副本数量、网络等),直接与容器引擎交互实现容器的声明周期管理,如果自己节点上的Pod状态与期望状态不一致调用对应容器的接口达到预期状态
管理镜像和容器的清理工作,保证节点上镜像不会占满磁盘,退出的容器不会占用太多的资源
②Kube-Proxy
每个节点上实现Pod网络代理,是K8S Service 资源的载体,负责维护网络规则和四层负载均衡工作,负责写入规则至iptables、ipvs等实现服务映射访问的。
本身不是直接给Pod提供网络,Pod的网络是由Kubelet提供的,实际上维护的是虚拟的Pod集群网络
Kube-apiserver通过监控Kube-Proxy 进行对Kubernetes Service的更新和端点的维护。
在K8S集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器,在K8S的每个节点上都会运行一个Kube-proxy 组件。
③docker或rocker
容器引擎,运行容器,负责本机的容器创建和管理工作
4、K8S三种负载均衡模式
①namespace
②iptables(默认使用 )
③ipvs(此模式更快,所有安装是需要更改为此模式。内核运行更快,性能更好。 )
5、K8S架构工作流程
①运维人员操作Kubectl命令向API server发送任务请求,先到Auth进行鉴权认证,然后进到API Server中,API Server存储操作到Etcd
②然后API Server根据Etcd中用户执行的操作调用 controller manager对应的控制器进行操作,例如创建
③controller manager通过调用创建控制器到API Server创建replication副本,APIserver将操作存到Etcd中,API Server再调用Scheduler进行算法选择为Pod选择最合适的节点创建,Scheduler需要通过API Server在node节点上的Kubelet进行预选策略和优选策略选择最优的node节点APIserver将动作保存到Etcd中
④Scheduler选择完节点后通过APIserver的Kubelet在对应的node节点上创建Pod,并通知对应node节点的doker在Pod中创建容器
⑤容器需要对外提供服务时,通过node节点的Kube-Proxy代理对外映射端口信息,Kube-proxy进来后通过service负载均衡器分发到容器上,访问容器是根据Label标签访问的。
6、K8S的核心概念
包含:Pod、Label、Service、Replication、Controller。等
①Pod
是K8s创建或者部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程,Pod里面可以放很多容器。一个Pod由一个或多个容器组成,Pod中的容器共享网络、存储和计算资源在同一台Docker主机上运行,一个Pod可以运行多个容器,又称为边车模式(sidecar)。生产中一般一个Pod就一个容器或者是有多个强关联性互补的容器
同一个Pod直接的容器可以通过localhost互相访问,并且可以挂载Pod内所有数据卷。不同Pod之间的容器不能用localhost访问,也不能挂载Pod内所有数据卷。
②Pod控制器
Pod控制器是启动Pod的一种模板,用来保证在K8S里启动Pod应始终按照用户的预期运行
Deployment:无状态应用部署即无论谁来访问都是一样的例如http网页
有状态协议:需要持久化
无状态协议:一次性的不需要持久化,每一次请求都是一条新的数据
Replicaset:受控于Deployment,确保预期的Pod副本数量,Replicaset的通就是管理和控制Pod管理他们好好工作,若发现某个Pod不行了就找个新的Pod来做替换。
Daemonset:确保所有节点运行同一类Pod,保证每个节点上都有一一个此类Pod运行,通常用于实现系统级后台任务。
Statefulset:有状态应用部署
Job:一次性任务。根据用户的设置,Job 管理的Pod把任务成功完成就自动退出了。
Cronjob:周期性计划性任务
7、Label标签
①标签是K8s特色的管理方式便于分类管理资源对象
②label可以附加到各种资源对象上,例如:node、Pod、service、Rc等,用于关联对象、查询和筛选
③一个label是一个key-value的键值对,key-value都由用户自定义
④一个资源对象可以定义任意数量的label,同一个label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除
⑤可以通过给指定的资源对象捆绑一个或多个不通的label,实现多维度的资源分组管理功能
8、Label选择器(Label selector)
①给某个资源对象定义一个Label,就相当于给他打开了一个标签,随后可以通过标签选择器(Labelselector)查询和筛选拥有某些Label的资源对象。
②标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在。
9、Service
K8S集群中每个Pod会被分配一个单独的ip地址,但是由于Pod是有生命周期的(可以被创建而且销毁后不会再重启),随时可能会因为业务ip的变更,导致这个ip地址会随着Pod的销毁而消失
Service就是用来解决这个问题的核心概念:
Service:通过标签选择器关联具有对应Lable的Pod,再把相关的Pod IP加入自己的Endpoints当中,service根据Endpoints里的Ip进行转发
不是服务的含义,更像是一个网关层、流量均衡器、Service作用于那些Pod由标签选择器来定义。
service可以看作一组提供相同服务的Pod的对外访问接口,客户端需要访问的服务就是Service的对象,每个Service都有一个虚拟的ip,会自动向后端做转发。
负载均衡功能:自动把请求流量分配到后端所有的服务上,可以对客户端透明的做水平扩展,实现此功能的关键是Kube-proxy,Kubeproxy运行在每个节点上监听APIserver中服务对象的变化,三种流量调度模式:userspace、iptables(利用的nat默认但不常用)、ipvs(推荐,性能最好),实现网络的转发
Service是K8s服务的核心,屏蔽了服务细节,统一了对外暴露服务接口,真正做到了微服务。用户只需要关注一个Service入口即可,不需要关注具体请求那个Pod。用户不会感知因为Pod上服务的意外崩溃K8S重新拉起Pod而导致的ip变更,也不会感知到因服务升级、服务变更等带来的Pod替换而导致的IP变化。
10、Ingress
service负责K8s集群内部的网络拓扑(四层)、Ingress负责集群外部的网络(七层),将客户的请求转发给对应的service处理,然后service根据label负载均衡给Pod