Kubernetes的缩写为:K8S,这个缩写是因为k和s之间有八个字符的关系。
Kubernetes是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用。
kubernetes,是一个全新的基于容器技术的分布式架构领先方案,是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本,于2014年9月发布第一个版本,2015年7月发布第一个正式版本。
kubernetes的本质是一组服务器集群,它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。目的是实现资源管理的自动化,主要提供了如下的主要功能:
在部署应用程序的方式上,主要经历了三个时代:
容器化部署方式给带来很多的便利,但是也会出现一些问题,比如说:
K8S 是属于主从设备模型(Master-Slave 架构),主节点一般被称为== Master 节点==,负责集群的调度、管理和运维。而从节点则被称为 Worker Node 节点,每个 Node 都会被 Master 分配一些工作负载。
Kubernetes主要由以下几个核心组件组成:
一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成,每个节点上都会安装不同的组件。
集群的控制平面,负责集群的决策 ( 管理 )
Kubernetes API,集群的统一入口,各组件协调者,以**Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
用于暴露Kubernetes API,任何资源请求或调用操作都是通过kube-apiserver 提供的接口进行。以HTTP Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd 存储(相当于分布式数据库,以键值对方式存储)。
可以理解成API Server 是K8S的请求入口服务。API server负责接收K8S所有请求(来自UI界面或者CLI 命令行工具),然后根据用户的具体请求,去通知其他组件干活。可以说API server 是K8S集群架构的大脑。
运行管理控制器,是k8s集群中处理常规任务的后台线程,是k8s集群里所有资源对象的自动化控制中心。
在k8s集群中,一个资源对应一个控制器,而Controller manager 就是负责管理这些控制器的。
由一系列控制器组成,通过API Server监控整个集群的状态,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态.
控制器 | 功能 |
---|---|
Node Contrpller(节点控制器) | 负责在节点出现故障时发现和响应 |
Replication Controller ( 副本控制器) | 负责保证集群中一个RC (资源对象ReplicationController) |
Endpoints Controller (端点控制器) | 填充端点对象(即连接Services 和Pods) ,负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的 endpoint |
Service Account & Token Controllers (服务帐户和令牌控制器) | 为新的命名空间创建默认帐户和API访问令牌 |
Resource Quota Controller(资源配额控制器) | 确保指定的资源对象在任何时候都不会超量占用系统物理资源 |
Namespace Controller (命名空间控制器) | 管理namespace的生命周期 |
Service Controller (服务控制器) | 属于K8S集群与外部的云平台之间的一个接口控制器 |
- API Server 接收到请求创建一批Pod,API Server 会让Controller-manager 按照所预设的模板去创建Pod,Controller-manager 会通过API Server去找Scheduler为新创建的Pod选择最适合的Node 节点。比如运行这个Pod需要2C4G 的资源,Scheduler会通过预算策略在所有Node节点中挑选最优的。Node 节点中还剩多少资源是通过汇报给API Server 存储在etcd 里,API Server 会调用一个方法找到etcd 里所有Node节点的剩余资源,再对比Pod 所需要的资源,在所有Node 节点中查找哪些Node节点符合要求。
- 如果都符合,预算策略就交给优选策略处理,优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node 节点,并把Pod调度到这个Node节点上运行。
- controller manager会通过API Server通知kubelet去创建pod,然后通过kube-proxy中的service对外提供服务接口。(node组件)
分布式键值存储系统(特性:服务自动发现)。用于保存集群状态数据,比如Pod、Service等对象信息
k8s中仅API Server 才具备读写权限,其他组件必须通过API Server 的接口才能读写数据
PS:etcd V2版本:数据保存在内存中
v3版本:引入本地volume卷的持久化(可根据磁盘进行恢复),服务发现,分布式(方便扩容,缩容)
etcd是一种定时全量备份+持续增量备份的持久化方式,最后存储在磁盘中
但kubernetes 1.11版本前不支持v3,我用的事K8S 1.15
ETCD一般会做为3副本机制(奇数方式),分布在三台master上(也有的公司单独用服务器部署ETCD )
master:奇数的方式部署(多节点的时候)
kubelet —》先和docker引擎进行交互—》docker容器(一组容器跑在Pod中)
在Node节点上实现Pod网络代理,维护网络规则、pod之间通信和四层负载均衡工作。默认会写入规则至iptables ,目前支持IPVS、同时还支持namespaces
对于七层的负载,k8s官方提供了一种解决方案;ingress-nginx
Pod是Kubernetes 创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
一个Pod 由一个或多个容器组成,Pod 中容器共享网络、存储和计算资源,在同一台Docker 主机上运行。
一个Pod里可以运行多个容器,又叫边车模式(SideCara) 模式。而在生产环境中一 般都是单个容器或者具有强关联互补的多个容器组成一 个Pod。
同一个Pod 之间的容器可以通过localhost 互相访问,并且可以挂载Pod 内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问,也不能挂载其他Pod的数据卷。
pod控制器
Pod控制器是Pod启动的一种模版,用来保证在K8S里启动的Pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)
K8s内提供了众多的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: 周期性计划性任务
kubectl 创建一个Pod(在提交时,转化为json格式)
1、首先经过auth认证(鉴权),然后传递给api-server进行处理
2、api-server 将请求信息提交给etcd
3、scheduler和controller-manager 会watch(监听) api-server ,监听请求
4、在scheduler 和controller-manager监听到请求后,scheduler 会提交给api-server一个list清单——>>包含的是获取node节点信息
5、此时api-server就会向etcd获取后端node节点信息,获取到后,被scheduler watch到,然后进行预选优选进行打分,最后将结果给与api-server
6、此时api-server也会被controller-manager watch(监听) controller-manager会根据请求创建Pod的配置信息(需求什么控制器)将控制器资源给与api-server
7、此时api-server 会提交list清单给与对应节点的kubelet(代理)
8、kubelet代理通过K8S与容器的接口(例如containerd)进行交互,假设是docker容器,那么此时kubelet就会通过dockershim 以及runc接口与docker的守护进程docker-server进行交互,来创建对应的容器,再生成对应的Pod
9、kubelet 同时会借助于metrics server 收集本节点的所有状态信息,然后再提交给api-server
10、最后api-server会提交list清单给与etcd来存储(最后api-server会将数据维护在etcd中)
Kubernetes包含多种类型的资源对象: Pod、 Label、 Service、 Replication Controller 等。
所有的资源对象都可以通过Kubernetes 提供的kubectl 工具进行增、删、改、查等操作,并将其保存在etcd 中持久化存储。
Kubernets其实是一个高度自动化的资源控制系统,通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。
在K8s的集群里,虽然每个Pod会被分配一个单独的IP地址,Pod是有生命周期的。当一个工作节点(Node)销毁时,节点上运行的Pod也会销毁,然后通过ReplicationController动态创建新的Pods来保持应用的运行。Service就是用来解决这个问题的核心概念。
Kubernetes中的Service 是一个抽象的概念,它定义了Pod的逻辑分组和一种可以访问它们的策略,这组Pod能被Service访问,使用YAML (优先)或JSON 来定义Service,Service所针对的一组Pod通常由LabelSelector实现。
Service 是== K8S服务的核心,屏蔽了服务细节,统一对外暴露服务接口==
Service的四种type:
小结:
在K8S集群中,service 可以看作一组提供相同服务的Pod的对外访问接口。
客户端需要访问的服务就是service对象。每个service都有一个固定的虛拟ip
(这个ip也被称为Cluster IP) ,自动并且动态地绑定后端的Pod,
所有的网络请求直接访问Service 的虚拟ip,service会自动向后端做转发。
Service除了提供稳定的对外访问方式之外,还能起到负载均衡(Load Balance)
的功能,自动把请求流量分布到后端所有的服务.上,Service可以做到对客户
透明地进行水平扩展(scale)。
而实现service 这一功能的关键, 就是kube-proxy。
kube-proxy 运行在每个节点上,监听API Server 中服务对象的变化,
可通过以下三种流量调度模式:
userspace (废弃)、
iptables ( 濒临废弃)、
ipvs (推荐,性能最好)来实现网络的转发。
Kubernetes Service 是一个抽象层,统一对外暴露服务接口,应用可以方便的实现服务发现与负载均衡。
标签,是K8S特色的管理方式,便于分类管理资源对象。
Label可以附加到各种资源对象.上,例如Node、Pod、Service、 RC等,用于关联对象、查询和筛选。
一个Label 是一个key-value 的键值对,其中key 与value 由用户自己指定。
一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除。
可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多维度的资源分组管理功能。
与Label 类似的,还有Annotation (注释)
区别在于有效的标签值必须为63个字符或更少,并且必须为空或以字母数字字符( [a-z0-9A-Z])开头和结尾,中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制。
Label选择器(Label selector )
给某个资源对象定义一个Label,就相当于给它打了一个标签;随后可以通过标签选择器( Label selector) 查询和筛选拥有某些Label的资源对象。
标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。
ps:如下图,相同的label处于同一service
Service主要负责K8S集群内部的网络拓扑,那么集群外部怎么访问集群内部呢?这个时候就需要Ingress 了。Ingress 是整个K8S集群的接入层,负责集群内外通讯。
Ingress是K8S 集群里工作在OSI网络参考模型下,第7层的应用,对外暴露的接口,典型的访问方式是http/https.
Service只能进行第四层的流量调度,表现形式是iptport。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
比如:客户端请求http://www. kgc。com:port —> Ingress —> Service —> Pod
随着项目增多、人员增加、集群规模的扩大,需要一种能够逻辑上隔离K8S内各种“资源”的方法,这就是Namespace 。
Namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同Namespace 内的“资源”名称可以相同,相同Namespace 内的同种“资源”,“名称”不能相同。
合理的使用K8S的Namespace,可以使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览。
K8S里默认存在的Namespace 有: default、kube-system、kube-public等。
查询K8S里特定“资源”要带上相应的Namespace