云原生架构系列——kubernetes原理及核心组件
1 kubernetes基本介绍试想一下为什么高铁能有条不絮的运行在各自的轨道上,不会出现前后车相撞,那是因为有个调度中心在统一的指挥。什么时间发车,什么时间到站以及遇到故障问题需要作出什么决策,都是由调度中心统一指挥。对于容器也是一样,要想使容器能井然有序的运作,就需要一个统一的管理平台,如分配资源、扩缩容、服务宕机能及时恢复等。目前最流行的容器管理平台是Kubernetes,简称k8s,8代表
1 kubernetes基本介绍
试想一下为什么高铁能有条不絮的运行在各自的轨道上,不会出现前后车相撞,那是因为有个调度中心在统一的指挥。什么时间发车,什么时间到站以及遇到故障问题需要做出什么决策,都是由调度中心统一指挥。对于容器也是一样,要想使容器能井然有序的运作,就需要一个统一的管理平台,如分配资源、扩缩容、服务宕机能及时恢复等。目前最流行的容器管理平台是Kubernetes,简称k8s,8代表中间的8个字母。其它的还有Swarm和Mesos。
k8s是Google开发的开源容器管理平台,源于Google开发的Borg系统,目前由云计算基金会(CNCF)托管。
1.1 k8s内部构造
Kubernetes采用了Pod和Label把容器组合成一个个的互相存在依赖关系的逻辑单元。Pod用于部署容器,Label用于标识一组容器服务,比如一个容器部署了多个副本,可以用Label来标识。
Kubernetes集群架构分为master和node节点:
- master节点: 负责资源调度,存储集群状态(服务注册发现),提供统一API网关入口等,一个master对应多个node节点;
- node节点:node节点存储pod(pod内部封装容器的),一个node节点理论上可以存储无数个pod,但是node节点存储pod的数量受限于硬件资源的限制,同时受限于pod内部服务运行所占用的资源。
1.2 k8s整体架构
- 通过kubectl 客户端指令和浏览器(dashboard)可以向k8s服务发送请求;
- scheduler:调度器 ,负责计算该把pod调度到哪一个node节点;
- Controllers:控制器 ,负责创建和维护node节点的资源对象(如deployment、rs、pod等);
- API Server:统一API网关入口,所有请求都必须要经过网关;
- etcd:是一个开源分布式的、可靠的key-value 存储系统,用于存储服务发现、注册、集群状态、调度等信息;
- Node节点: 每一个node节点都运行一个kubelet进程,此进程负责本机服务的pod的创建维护;
- Regitry: 镜像仓库,可以用阿里的镜像仓库,或者用harbor构建一套自己的私有仓库。
2 Master节点
Master节点包括API Server、Controllers、etcd、scheduler。
2.1 API Server
集群服务的统一入口,以HTTP API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
2.2 Controllers
控制器有以下几种:
- replication controller:副本控制器,控制副本数量与预期设定的数量保持一致,如果有挂掉的容器会自动创建一个;
- Node Controller:管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点;
- namespce controller:创建pod,会把pod分配在不同命名空间下,定期清理无效的namespace;
- service controller:虚拟服务控制器,维护虚拟ip,提供负载均衡;
- endpoints controller:管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,当Pod发生变化时,实时更新Endpoints (即Pod Ip + Container Port);
- service Account controller:安全认证;
- persistent volume controller:持久化存储控制器,针对有状态服务部署;
- daemon set controller:让每一个Node节点都运行一个相同的服务;
- deployment controller:无状态部署控制器,支持滚动更新(不停机更新);
- Job controller:定时任务控制器;
- pod autoscale controller:自动更新控制器,比如配置了cup利用率>=80%,就自动扩容。
2.3 scheduler
根据调度算法为新创建的Pod选择一个Node节点。 scheduler在整个系统中承担了承上启下的重要功能,承上是指它负责接收controllers创建新的Pod,为其安排一个落脚的目标Node,启下是指安置工作完成后,目标Node上的kubelet服务进程接管后继工作。
也就是说scheduler的作用是通过调度算法为待调度Pod列表上的每一个Pod从Node列表中选择一个最合适的Node。
创建pod的流程:
- kubeclt 发送创建的pod的指令,此时这个指令被apiserver拦截,把创建的pod存储在etcd
- schduler 发起调用请求,此时这个指令被apiserver拦截,获取etcd中podQueue.NodeList。
- 通过调度算法(预选调度和优选策略)选择出一个合适的node节点,然后把node和pod信息存储在etcd上
- node节点上有一个kubelet进程,发送请求获取pod,node信息创建对应的资源
- 此时如果kubelet发现pod是本机节点需要创建的,kubelet就开始创建pod
3 Node节点
3.1 kubelet
kubelet是Master在Node节点上的Agent,每个节点都会启动 kubelet进程,用来处理 Master 节点下发到本节点的任务,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、 下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。
kubelet 默认监听四个端口,分别为 10250 、10255、10248、4194
- 10250(kubelet API):kubelet server 与 apiserver 通信的端口,定期请求 apiserver 获取自己所应当处理的任务,通过该端口可以访问获取 node 资源以及状态。
- 10248(健康检查端口):通过访问该端口可以判断 kubelet 是否正常工作, 通过 kubelet 的启动参数 --healthz-port 和 --healthz-bind-address 来指定监听的地址和端口。
- 4194(cAdvisor 监听):kublet 通过该端口可以获取到该节点的环境信息以及 node 上运行的容器状态等内容,访问 http://localhost:4194 可以看到 cAdvisor 的管理界面,通过 kubelet 的启动参数
--cadvisor-port
可以指定启动的端口。 - 10255 (readonly API):提供了 pod 和 node 的信息,接口以只读形式暴露出去,访问该端口不需要认证和鉴权。
3.2 kube-proxy
Pod的网络代理,类似反向代理,用来生成网络规则,创建访问路由,创建service网络访问规则,负载均衡规则。
3.3 Pod
Pod是最小部署单元,一个Pod有一个或多个容器组成,Pod中容器共享存储和网络,在同一台Docker主机上运行。每个Pod都有自己的IP地址和Hostname。
Pause的作用:
我们看下在node节点上都会起很多pause容器,和pod是一一对应的。
每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此它们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。
kubernetes中的pause容器主要为每个业务容器提供以下功能:
- PID命名空间:Pod中的不同应用程序可以看到其他应用程序的进程ID
- 网络命名空间:Pod中的多个容器能够访问同一个IP和端口范围
- IPC命名空间:Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信
- UTS命名空间:Pod中的多个容器共享一个主机名
- Volumes(共享存储卷):Pod中的各个容器可以访问在Pod级别定义的Volumes
3.4 其它
Docker: docker引擎,pod内部运行的容器是由docker引擎创建的,docker引擎是node节点基础服务。
Fluentd:收集日志的组件
4 核心组件
4.1 ReplicationController
副本控制器,用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代,而如果因为异常多创建的容器也会自动回收。
4.2 ReplicaSet
ReplicaSet也是副本控制器,在最新的k8s版本中建议使用ReplicaSet,因为一个Pod可能会定义多个Label,RC只支持单个标签选择器,而RS支持复合标签选择器。说简单点就是,RC只能根据单个标签去查资源对象,而RS可以根据多个标签查资源对象。需要注意的是RS不支持滚动更新(不停机更新),需要结合Deployment组件一起使用。
4.3 Deployment
Deployment是RS的上游组件,Deployment管理RS副本控制器,RS管理Pod容器。它们之间的依赖关系如下图
Deployment实现滚动更新步骤:
- Deployment会重新创建一个新的RS副本控制器
- 新的RS副本控制器会创建新的Pod,同时会销毁对应老的Pod进程,但是容器的镜像还在,在项目发布失败时可以用镜像回滚到上一个版本
4.4 HPA
全称Horizontal Pod Autoscaling,自动扩缩容。该组件可以根据CPU的利用率还进行自动扩缩容,在vlalpha版本中,还支持根据内存进行扩缩容。比如配置了CPU>90%,HPA会监控RS下所有Pod的CPU利用率,如果有大于90%的就会自动扩容。
4.5 StatefullSet
StatefullSet与Deployment一样,都是用来部署服务的。StatefullSet是用来部署有状态的服务,而Deployment用来部署无状态服务。无状态服务是没有实时的数据需要存储,在集群环境中把一个服务抽离出去再加进来对集群没有影响。比如我们部署的项目服务,只是一个进程,用来提供计算,数据由数据库来存储;有状态服务则与之相反,比如MySQL等存储服务。
在Pod宕机再恢复后,pod会生成一个新的IP地址,所以StatefullSet是根据pod的名称来挂载数据,只要保证pod的名称不变即可。
4.6 DaemonSet
DaemonSet是让每一个node节点都可以运行一个相同的pod。比如要在每个node节点上收集日志,就可以用DaemonSet生成一个相同日志pod。
使用DaemonSet 的一些典型用法:
- 运行集群存储daemon,例如在每个Node上运行glustered,ceph
- 在每个Node上运行日志收集Daemon,例如:fluentd、logstash
- 在每个Node上运行监控Daemon,例如:Prometheus Node Exporter
更多推荐
所有评论(0)