简介
kubernetes,简称K8s,是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新/回滚等操作,当然也可以通过创建虚拟机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。
新的方式是通过部署容器方式实现,每个容器之间互相隔离,每个容器有自己的文件系统 ,容器之间进程不会相互影响,能区分计算资源。相对于虚拟机,容器能快速部署,由于容器与底层设施、机器文件系统解耦的,所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快,每个应用可以被打包成一个容器镜像,每个应用与容器间成一对一关系也使容器有更大优势,使用容器可以在build或release 的阶段,为应用创建容器镜像,因为每个应用不需要与其余的应用堆栈组合,也不依赖于生产环境基础结构,这使得从研发到测试、生产能提供一致环境。类似地,容器比虚拟机轻量、更“透明”,这更便于监控和管理。
特点
- 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)
- 可扩展: 模块化,插件化,可挂载,可组合
- 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展
- 快速部署应用,快速扩展应用
- 无缝对接新的应用功能
- 节省资源,优化硬件资源的使用
kubernetes特性
自我修复
在节点故障时重新启动失败的容器,替换和重新部署,保证预期的副本数量;杀死健康检查失败的容器,并且在未准备好之前不会处理客户端请求,确保线上服务不中断。
弹性伸缩
使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性;业务低峰时回收资源,以最小成本运行服务。
自动部署和回滚
K8S采用滚动更新策略更新应用,一次更新一个Pod,而不是同时删除所有Pod,如果更新过程中出现问题,将回滚更改,确保升级不受影响业务。
服务发现和负载均衡
K8S为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称),并且负载均衡关联的所有容器,使得用户无需考虑容器IP问题。
机密和配置管理
管理机密数据和应用程序配置,而不需要把敏感数据暴露在镜像里,提高敏感数据安全性。并可以将一些常用的配置存储在K8S中,方便应用程序使用。
存储编排
挂载外部存储系统,无论是来自本地存储,公有云(如AWS),还是网络存储(如NFS、GlusterFS、Ceph)都作为集群资源的一部分使用,极大提高存储使用灵活性。
批处理
提供一次性任务,定时任务;满足批量数据处理和分析的场景。
Kubernetes架构
Kubernetes借鉴了Borg的设计理念,比如Pod、Service、Labels和单Pod单IP等。Kubernetes的整体架构跟Borg非常像,如下图所示
Kubernetes主要由以下几个核心组件组成:
- etcd保存了整个集群的状态;
- apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
- controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
- kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;
- Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
- kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;
除了核心组件,还有一些推荐的Add-ons:
- kube-dns负责为整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
- Heapster提供资源监控
- Dashboard提供GUI
- Federation提供跨可用区的集群
- Fluentd-elasticsearch提供集群日志采集、存储与查询
分层架构
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构,如下图所示
- 核心层:Kubernetes最核心的功能,对外提供API构建高层的应用,对内提供插件式应用执行环境
- 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)
- 管理层:系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)
- 接口层:kubectl命令行工具、客户端SDK以及集群联邦
- 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
- Kubernetes外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
- Kubernetes内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
组件
- 1Master 组件
- 1.1kube-apiserver
- 1.2ETCD
- 1.3kube-controller-manager
- 1.4cloud-controller-manager
- 1.5kube-scheduler
- 1.6插件 addons
- 1.6.1DNS
- 1.6.2用户界面
- 1.6.3容器资源监测
- 1.6.4Cluster-level Logging
- 2节点(Node)组件
- 2.1kubelet
- 2.2kube-proxy
- 2.3docker
- 2.4RKT
- 2.5supervisord
- 2.6fluentd
Master 组件
Master组件提供集群的管理控制中心。
Master组件可以在集群中任何节点上运行。但是为了简单起见,通常在一台VM/机器上启动所有Master组件,并且不会在此VM/机器上运行用户容器。请参考构建高可用群集以来构建multi-master-VM。
kube-apiserver
kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。请参阅构建高可用集群。
ETCD
etcd是Kubernetes提供默认的存储系统,保存所有集群数据,使用时需要为etcd数据提供备份计划。
kube-controller-manager
kube-controller-manager运行管理控制器,它们是集群中处理常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成单个二进制文件,并在单个进程中运行。
这些控制器包括:
- 节点(Node)控制器。
- 副本(Replication)控制器:负责维护系统中每个副本中的pod。
- 端点(Endpoints)控制器:填充Endpoints对象(即连接Services&Pods)。
- Service Account和Token控制器:为新的Namespace创建默认帐户访问API Token。
cloud-controller-manager
云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的,还是Alpha的功能。
云控制器管理器仅运行云提供商特定的(controller loops)控制器循环。可以通过将–cloud-providerflag设置为external启动kube-controller-manager ,来禁用控制器循环。
cloud-controller-manager 具体功能:
- 节点(Node)控制器
- 路由(Route)控制器
- Service控制器
- 卷(Volume)控制器
kube-scheduler
kube-scheduler监视新创建没有分配到Node的Pod,为Pod选择一个Node。
插件 addons
插件(addon)是实现集群pod和Services功能的。Pod由Deployments,ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。
DNS
虽然不严格要求使用插件,但Kubernetes集群都应该具有集群 DNS。
群集 DNS是一个DNS服务器,能够为 Kubernetes services提供 DNS记录。
由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。
用户界面
kube-ui提供集群状态基础信息查看。
容器资源监测
容器资源监控提供一个UI浏览监控数据。
Cluster-level Logging
Cluster-level logging,负责保存容器日志,搜索/查看日志。
节点 Node 组件
节点组件运行在Node,提供Kubernetes运行时环境,以及维护Pod。
kubelet
kubelet是主要的节点代理,它会监视已分配给节点的pod,具体功能:
- 安装Pod所需的volume。
- 下载Pod的Secrets。
- Pod中运行的 docker(或experimentally,rkt)容器。
- 定期执行容器健康检查。
- Reports the status of the pod back to the rest of the system, by creating amirror podif necessary.(通过创建amirror podif(必要时),将pod的状态报告回系统的其余部分。)
- Reports the status of the node back to the rest of the system.(将节点的状态报告回系统的其余部分。)
kube-proxy
kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。
docker
docker用于运行容器。
RKT
rkt运行容器,作为docker工具的替代方案。
supervisord
supervisord是一个轻量级的监控系统,用于保障kubelet和docker运行。
fluentd
fluentd是一个守护进程,可提供cluster-level logging.。
kubernetes用途
在您生产环境中使用 Kubernetes 的主要优势在于,它提供了一个便捷有效的平台,让您可以在物理机和虚拟机集群上调度和运行容器。更广泛一点说,它可以帮助您在生产环境中,完全实施并依托基于容器的基础架构运营。由于 Kubernetes 的实质在于实现操作任务自动化,所以您可以将其它应用平台或管理系统分配给您的许多相同任务交给容器来执行。
利用 Kubernetes,您能够达成以下目标:
- 跨多台主机进行容器编排。
- 更加充分地利用硬件,最大程度获取运行企业应用所需的资源。
- 有效管控应用部署和更新,并实现自动化操作。
- 挂载和增加存储,用于运行有状态的应用。
- 快速、按需扩展容器化应用及其资源。
- 对服务进行声明式管理,保证所部署的应用始终按照部署的方式运行。
- 利用自动布局、自动重启、自动复制以及自动扩展功能,对应用实施状况检查和自我修复。
但是,Kubernetes 需要依赖其它项目来全面提供这些经过编排的服务。因此,借助其它开源项目可以帮助您将 Kubernetes 的全部功用发挥出来。这些功能包括:
- 注册表,通过 Atomic 注册表或 Docker 注册表等项目实现。
- 联网,通过 OpenvSwitch 和智能边缘路由等项目实现。
- 遥测,通过 heapster、kibana、hawkular 和 elastic 等项目实现。
- 安全性,通过 LDAP、SELinux、RBAC 和 OAUTH 等项目以及多租户层来实现。
- 自动化,参照 Ansible 手册进行安装和集群生命周期管理。
- 服务,可通过自带预建版常用应用模式的丰富内容目录来提供。
kubernetes 专业术语
pod
- pod是 kubernetes 中最小调度逻辑单元
- pod可以理解为是容器的外壳,它为容器做了一层抽象的封装
- pod内部主要是用来放容器的
- pod的特点是可以将多个容器加入到同一个网络名称空间中
- 一个pod中可以包含多个容器(实际生产中不会放多个容器)
- 同一个pod中的不同容器可以共享存储卷
- 一个pod上无论是有一个容器还是有多个容器,一旦将次pod调度到某node上运行时,这一个pod内部的所有容器只能运行在同一个node上
pod分类
- 自主式pod:自我手动管理的pod,创建以后仍然需要提交给 apiserver ,由 apiserver 接收以后借助于调度器将其调度至指定的node节点,由node启动此pod,如果pod出现故障,需要重启容器则有 kubelet 来完成,如果 node 节点故障了,那么此pod将会消失。其无法实现全局调度,所以不推荐使用此种pod
- 控制器管理的pod
pod控制类型
- ReplicationController:副本控制器。当启动一个pod是,这个pod如果不够用可以再启动一个副本,而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则,精确符合我们所定义的期望
- ReplicaSet:由一个名叫 Deployment 的声明式更新的控制器来管理
- Deployment:管理无状态应用,建构在ReplicaSet之上的
滚动更新
声明式配置–>支持动态运行时修改 - DaemonSet:如果需要在每个node上运行一个副本的时候可以用 Daemonset
- Job:执行一次性任务,执行成功后就退出
- CronJob:周期性Job
- StatefulSet:管理有状态应用
node
- node 是k8s集群中的工作节点,负责运行由 master 指派的各种任务。而最核心的任务就是以pod形式运行容器
- node 可以是任何形式的计算设备,只要此设备上能够有传统意义上的 CPU、内存、存储空间,并且能装上k8s的集群代理程序,它都可以作为整个k8s集群一个成员
标签(Label)和标签选择器(Label Selector)
当大量的pod运行在一个集群当中时,如何实现分类管理?比如想删除某一类pod,这么多的pod,我们肯定不能通过pod的名称来识别容器,因为pod随时都会被创建和删除,当一个pod发生故障被删除后,重新生成的pod的名称和被删除的pod肯定不一样,只不过其内部运行的程序是一样的,所以我们不能通过pod的名称来识别。同时我们有可能要将一类pod归为一组,比如创建4个 nginx 的pod,期望使用一个控制器对其进行统一管理,删除一个控制器就把这4个pod都删了,控制器还要保证这4个pod都处于运行状态,缺一个要补一个,多一个要多杀一个,精确符合我们期望的4个pod才行。
为了能够实现pod识别,需要在pod至上附加一些元数据,类似 Dockerfile 中的 label 标签的方式,比如在创建pod时为其附加一个名为 app 的 key,然后将其值设为 nginx,那么当我们在批量进行pod调度管理时,可以检查pod中是否有 app 这个 key,且其值是否为 nginx,通过此种方法来识别pod是否是我们想要控制的pod。
Label(标签)是 Kubernetes 系统中另外一个核心概念。一个 Label 是 一个key=value 的键值对,其中 key 与 value 由用户自己指定。Label可以被附加到各种资源对象上,例如 Node、Pod、Service、RC 等,一个资源对 象可以定义任意数量的 Label,同一个 Label也可以被添加到任意数量的 资源对象上。Label通常在资源对象定义时确定,也可以在对象创建后 动态添加或者删除。
Label 相当于我们熟悉的“标签”。给某个资源对象定义一个 Label, 就相当于给它打了一个标签,随后可以通过 Label Selector(标签选择 器)查询和筛选拥有某些 Label 的资源对象,Kubernetes 通过这种方式实现了类似SQL的简单又通用的对象查询机制。
Label Selecto r可以被类比为SQL语句中的where查询条件,例如name=redis-slave 这个 Label Selector 作用于Pod时,可以被类比为 select * from pod where pod’s name =‘redis-slave’这样的语句。