Kuberentes 是基于容器的集群管理平台,它的简称,是K8S。
K8s是Go语言开发,是Docker的上层架构,就好像Java与J2EE的关系一样。K8s是一个开放的开发平台,不局限于任何语言。其主要功能:
- k8s能方便地管理跨机器运行容器化的应用
- 提供应用部署、维护、扩展机制
- 集群管理、安全防护、准入机制、多应用支撑、服务注册、服务发现、智能负载均衡、故障发现、自我修复、服务滚动升级、在线扩容、资源配额管理
- 使用Docker对应用程序包装、实例化、运行
- 以集群的方式运行、管理跨机器的容器
- 解决Docker跨机器容器之间的通讯问题
- k8s的自我修复机制使得容器集群总是运行在用户期望的状态
架构
master组件
所有集群的控制命令都传递给master组件并在其上执行。
每个kubernetes集群至少有一个套master组件(当前默认1个),每套master组件包括三个核心组( api server , controller manager,scheduler)件以及集群数据配置中心etcd
API server
是集群控制的唯一入口,是提供kubernetes集群控制RESTful API的核心组件k8s权威指南是集群内各个组件之间数据交互和通信的中枢并提供认证、授权、访问控制、API注册和发现等机制。此外,还提供集群控制的安全机制(身份认证、授权以及admission control)。
Scheduler
Scheduler是调度器,通过API Server的Watch接口监听新建Pod副本信息,并通过调度算法为该Pod选择一个最合适的Node,支持自定义调度算法provider,默认调度算法内置预选策略和优选策略,决策考虑资源需求、服务质量、软硬件约束、亲缘性、数据局部性等指标参数。
Controller manager
负责维护集群的各种状态,是集群内各种资源controller的核心管理者,针对每一种具体的资源,都有相应的Controller,保证其下管理的每个controller所对应的资源始终处于“期望状态”。
数据库etcd
etcd保存了整个集群的状态,作为一个数据库使用。主节点可以做成一个分布式的,以做到高可用。
etcd是kubernetes集群的主数据库,存储着所有资源对象以及状态,默认与master组件部署在一个Node上。注意etcd的数据变更都是通过API server进行。
Node组件-工作负载节点
kubernetes集群由多个Node共同承担工作负载,Pod被分配到某个具体的Node上执行。
kubernetes通过Node controller对node资源进行管理,支持动态在集群中添加或删除node,每个集群node上都会部署kubelet和kube-proxy两个组件。
kubelet
位于集群中每个Node上的非容器形式的服务进程组件,Master和node之间的桥梁,处理master下发到Node上的Pod创建、启停等管理任务,向API Server注册node信息,监控Node上容器和节点资源情况,并定期向Master汇报节点资源占用情况。,类似tars中的node server。
具体来说,kubelet负责Pod对应的容器的创建、启停等任务,同时与Master节点密切协作,实现集群管理的基本功能。一旦Node被纳入集群管理范围,kubelet进程就会向Master汇报自身的情报,这样Master可以获知每个Node的资源使用情况,并实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息,会被Master判定为“失联”,Node状态被标记为不可用(Not Ready),随后Master会触发“工作负载大转移”的自动流程。
kube-proxy
是service抽象概念的实现,将到service的请求按策略(负载均衡)算法发到后端Pod(Endpoint),是实现Kubernetes Service的通信与负载均衡机制的重要组件。默认使用iptables mode实现,支持nodeport模式,实现从外部访问集群内的service。
k8s水平扩展服务,本质是增加pod(也会增加机器),会自动均衡(根据pod使用的资源和node所使用的资源)分布到不同机器上。
pod
Pod是最小部署单元,一个Pod由一个或多个容器组成,Pod中容器共享存储和网络,在同一台Docker主机上运行。
同一个Pod里的容器共享同一个网络命名空间,可以使用localhost互相通信,
- 每个Pod都有一个特殊的被称为“根容器”的Pause容器,还包含一个或多个紧密相关的用户业务容器
- 一个Pod里的容器与另外主机上的Pod容器能够直接通信
- 如果Pod所在的Node宕机,会将这个Node上的所有Pod重新调度到其他节点上
- 普通Pod及静态Pod,前者存放在etcd中,后者存放在具体Node上的一个具体文件中,并且只能在此Node上启动运行
- Docker Volume对应Kubernetes中的Pod Volume
- 每个Pod可以设置限额的计算机资源有CPU和Memory:Requests,资源的最小申请量;Limits,资源最大允许使用的量
pod创建流程
- 创建pod都是通过api server去做的
- 通过Scheduler做调度,到地方发布到哪一台机器上
- 找到对应的node,发布到这个node上
- node会调用docker引擎,运行镜像
- 再将pod状态反馈给api server
Pod、容器与Node关系
- 主节点也可以有node组件,只不过一般情况下,不建议部署。
- 一个pod可以开多个容器(docker),这类似进程与线程的关系。同样,一般建议只部署一个容器。当多个容器之间有协作关系,且通过localhost回环通信,才会在一个pod内开多个容器。
- 一个pod只能在一台机器上部署,一台机器上可以运行多个pod
Endpoint与Event
Endpoint是标识服务进程的访问点,Event是一个事件记录,记录了事件最早产生的时间、最后重复时间、重复次数、发起者、类型,以及导致此事件的原因等信息。Event通常关联到具体资源对象上,式排查故障的重要参考信息。
Service
Service是一个应用服务抽象,定义了Pod逻辑集合和访问这个Pod集合的策略。
- Service代理Pod集合对外表现是为一个访问入口,分配一个集群IP地址,来自这个IP的请求将负载均衡转发后端Pod中的容器。
- Service通过LableSelector选择一组Pod提供服务。
- 在K8s集群中微服务的负载均衡是由Kube-proxy实现的,在K8s的每个节点上都有一个Kube-proxy。
Service其实就是我们经常提起的微服务架构中的一个“微服务”,kubernetes中的核心。通过分析、识别并建模系统中的所有服务为微服务——Kubernetes Service,最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成,服务之间通过TCP/IP进行通信,从而形成了我们强大而又灵活的弹性网络,拥有了强大的分布式能力、弹性扩展能力、容错能力。
Service抽象概念的实现,将到Service的请求按策略(负载均衡)算法发到后端Pod(Endpoint),默认使用iptables mode实现。此外,Service支持nodeport模式,实现从外部访问集群内的Service。