Kuberentes,k8s诞生简介

一、前言

什么是k8s?

Kuberentes 是基于容器的集群管理平台,它的简称,是K8S。有人说之所以叫k8s,是因为k到s中间有8个字母,因此叫k8s,也有人说,在使用k8s的安装配置流程中,共分为8步,大家各自参考就好。
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新/回滚等操作,当然也可以通过创建虚拟机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。
新的方式是通过部署容器方式实现,每个容器之间互相隔离,每个容器有自己的文件系统 ,容器之间进程不会相互影响,能区分计算资源。相对于虚拟机,容器能快速部署,由于容器与底层设施、机器文件系统解耦的,所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快,每个应用可以被打包成一个容器镜像,每个应用与容器间成一对一关系也使容器有更大优势,使用容器可以在build或release 的阶段,为应用创建容器镜像,因为每个应用不需要与其余的应用堆栈组合,也不依赖于生产环境基础结构,这使得从研发到测试、生产能提供一致环境。类似地,容器比虚拟机轻量、更“透明”,这更便于监控和管理。
各位同堂,希望通过本次介绍k8s的诞生与关键技术,让我们了解流行技术发展中的一些规律或者技术特点,给想准备使用k8s和设计系统的人一些启发。
我将从k8s的时代背景, k8s的架构与对象,设计理念四个方面去介绍k8s。不涉及具体的配置操作。最后是我的一个总结。

二、 k8s的时代背景

2.1 云计算发展概览

Kuberentes,k8s诞生简介_第1张图片

讲到k8s 我们先从物理机到虚拟化说起。最早我们的应用都是直接在物理机部署、运行的。代表公司有传统IBM,SUN公司。

在上世纪60年代,就提出了虚拟化的概念了。分时系统就是相关的技术。后来提出针对服务器市场虚拟化技术方案,满足提升计算资源利用率和降低成本的要求。VMware,Xen和KVM,三足鼎力,促进VM概念的普及,拉开虚拟云时代计算的大幕。

到了2006年,基于虚拟机技术,AWS开启基础设施服务的市场实现了自助,按需租用以VM为基本计算单元的计算资源,基础计算单元变成VM,服务端应用构建部署和运行逐步迁移到虚拟机VM上。谷歌也加入了进来,叫做GCE。

2010年开始进入成熟期基于虚拟化技术的公有云爆发式增长,形成公有云四巨头AWS,Azure,Aliyun,GCE。

2.2 容器的产生

云计算(虚拟化技术)解决了基础资源层的弹性伸缩,却没有解决 PaaS层应用随基础资源层弹性伸缩而带来的批量、快速部署问题。于是容器应运而生。

容器是一种沙盒技术,主要目的是为了将应用运行在其中,与外界隔离;及方便这个沙盒可以被转移到其它宿主机器。本质上,它是一个特殊的进程。通过名称空间(Namespace)、控制组(Control groups)、切根(chroot)技术把资源、文件、设备、状态和配置划分到一个独立的空间。
通俗点的理解就是一个装应用软件的箱子,箱子里面有软件运行所需的依赖库和配置。开发人员可以把这个箱子搬到任何机器上,且不影响里面软件的运行。
Kuberentes,k8s诞生简介_第2张图片

容器和虚拟化的区别是什么呢?通过这幅图,我们可以看到为什么容器是轻量的,因为它不像虚拟机那样,虚拟一套硬件和完整操作系统。而容器实际上是通过内核去控制,去使用使宿主机的cpu和内存。

Docker是流行的容器。除了大名鼎鼎的 Docker,还有其他的容器,例如 AppC、Mesos Container,都能运行容器镜像。所以说容器不等于 Docker。

Docker有一个独特的功能就是镜像。将镜像还原成运行时的过程(就是读取镜像文件,还原那个时刻的过程)就是容器运行的过程.

Docker镜像是Docker项目能够成功的关键。它解决的根本问题就是应用打包的问题。Docker通过提供一种非常方便的打包机制,直接打包了应用运行所需要的整个操作系统(其实只打包了文件系统),从而保证了本地环境和云端环境的高度一致。

2.3 k8s的诞生

Docker毕竟只是解决了打包的问题。在微服务化情况下,容器数量会非常多,如何管理容器,持续集成和编排的问题不可避免。
这时候,Kubernetes、Mesos,Swarm三大平台为解决容器的问题而出现,互相竞争,抢占市场。Kubernetes基于google公司已经使用了十多年的Borg项目进行了沉淀和升华才提出的一套框架,使其拥有一套完整的全新的设计理念,在设计上有很强的扩展性。同时有Google的背书,以及相对优秀的社区运营能力。所以最终Kubernetes赢得了胜利,成为了容器生态的行业标准。
Kubernetes是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。kubernetes主要解决容器编排问题。

三、K8s架构与对象

Kuberentes,k8s诞生简介_第3张图片

学习Kubernetes的架构,有助于我们了解Kubernetes的全貌,帮助我们进一步学习Kubernetes其他内容。Kubernetes本身细节很多,但从它的架构图来看,整体简单明了。我认为优秀的设计,往往在整体上是简单的,而且是易于理解的。

Kubernetes的功能组件是松耦合的,它们各司其职,功能明确。有负责外部资源请求的安全访问和控制,有的负责内部资源任务的调度(Scheduler)。然后由统一的api将对应的操作请求分发到对应的物理节点。再由各个节点的代理人(kubelet)根据资源的请求去管理容器(pod)。

Kubernetes集群有各种二进制组件,这些组件承担不同的角色,共同支持kubernetes集群的运行。Kubernetes集群角色有管理节点和工作节点,它们都是可以分布式部署的。管理节点主要负责整个集群的控制。对资源调度和配置,以及持久化集群的数据(节点,容器状态等,而非具体某个业务应用的日志等数据)。工作节点提供Kubernetes运行时环境,以及维护Pod,也就是实际运行我们应用的节点。

3.1 管理节点主要组件

kube-apiserver

ETCD
etcd是Kubernetes提供默认的存储系统,保存所有集群数据,使用时需要为etcd数据提供备份计划。

kube-controller-manager

节点(Node)控制器。
副本(Replication)控制器:负责维护系统中每个副本中的pod。
端点(Endpoints)控制器:填充Endpoints对象(即连接Services&Pods)。
Service Account和Token控制器:为新的Namespace 创建默认帐户访问API Token。

cloud-controller-manager
云控制器管理器负责与底层云提供商的平台交互。它是Kubernetes中开放给云厂商的通用接口,便于Kubernetes自动管理和利用云服务商提供的资源,这些资源包括虚拟机资源、负载均衡服务、弹性公网IP、存储服务等。
cloud-controller-manager 具体功能:
节点(Node)控制器
路由(Route)控制器
Service控制器
卷(Volume)控制器

3.2 工作节点(Node)主要组件

kubelet
kubelet是主要的节点代理,它会监视已分配给节点的pod,具体功能:
安装Pod所需的volume。
下载Pod的Secrets。
Pod中运行的 docker(或experimentally,rkt)容器。
定期执行容器健康检查。
报告容器个节点的状态

kube-proxy
kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。简单来说,就是负责Kubernetes集群内部网络通信的。

节点(Node)控制器
路由(Route)控制器
Service控制器
卷(Volume)控制器

3.3 k8s对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态。具体来说,他们可以描述:
容器化应用正在运行(以及在哪些节点上)
这些应用可用的资源
关于这些应用如何运行的策略,如重新策略,升级和容错
Kubernetes对象是“record of intent”,一旦创建了对象,Kubernetes系统会确保对象存在。通过创建对象,可以有效地告诉Kubernetes系统你希望集群的工作负载是什么样的。

3.4 常见的k8s对象

Pod
Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器(也可以有多个容器),存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位:Kubernetes中单个应用的实例,它可能由单个容器或多个容器共享组成的资源。

ReplicationController
(简称RC)是确保用户定义的Pod副本数保持不变。

ReplicaSet
ReplicaSet(RS)是Replication Controller(RC)的升级版本。ReplicaSet 和 Replication Controller之间的唯一区别是对选择器的支持。

Deployment
Deployment又叫部署,这是我们部署应用最常用的对象类型。
Deployment为Pod和Replica Set提供声明式更新,它是更上一层的抽象和封装。通过Deployment控制Replica Set,用作pod 机制的创建、删除和更新。

Service
Service 定义了这样一种抽象:一个 Pod 的逻辑分组,一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到,通常是通过 Label Selector将Pod与Service关联起来。
Service对象里面允许你定义一个固定的IP,这样,外部调用的时候,就可以直接访问这个固定IP,Service接到请求之后,自动负载均衡的转发到关联的Pod上。

Volume
翻译过来叫做“卷”,显然和存储有关。

Namespaces(命名空间)
命名空间是用来隔离对象资源的。上文提到的如pod、service、Deployment等于应用相关的对象都是需要指定Namespaces的
Kubernetes可以使用Namespaces(命名空间)创建多个虚拟集群。当团队或项目中具有许多用户时,可以考虑使用Namespace来区分。定义了命名空间,我们还可以做计算机资源、网络的统一限制,比如默认开放一些端口,默认pod创建时使用多少cpu、内存等等。

3.5 fcp使用的k8s对象

四、k8s设计理念

Kubernetes系统最核心的两个设计理念:一个是容错性,一个是易扩展性。容错性实际是保证Kubernetes系统稳定性和安全性的基础,易扩展性是保证Kubernetes对变更友好,可以快速迭代增加新功能的基础。
分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统,更好地利用它管理分布式部署的云原生应用,另一方面也可以让我们借鉴其在分布式系统设计方面的经验。下文列举了一些Kubernetes的部分设计原则。

4.1 API部分设计原则

所有API应该是声明式的
声明式的操作,相对于命令式操作,对于重复操作的效果是稳定的,这对于容易出现数据丢失或重复的分布式环境来说是很重要的。

API对象是彼此互补而且可组合的
这里面实际是鼓励API对象尽量实现面向对象设计时的要求,即“高内聚,松耦合”,对业务相关的概念有一个合适的分解,提高分解出来的对象的可重用性。事实上,Kubernetes这种分布式系统管理平台,也是一种业务系统,只不过它的业务就是调度和管理容器服务。所以我们,会看到如Pod、ReplicaSet、Deployment之类的对象,而它们可以组合。

API对象状态不能依赖于网络连接状态。
由于众所周知,在分布式环境下,网络连接断开是经常发生的事情,因此要保证API对象状态能应对网络的不稳定,API对象的状态就不能依赖于网络连接状态。

4.2 控制机制设计部分原则

假设任何错误的可能,并做容错处理
在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障,外部系统故障也可能来自于系统自身的代码错误,依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的,因此要设计对任何可能错误的容错处理。

假设任何操作都可能被任何操作对象拒绝,甚至被错误解析
由于分布式系统的复杂性以及各子系统的相对独立性,不同子系统经常来自不同的开发团队,所以不能奢望任何操作被另一个子系统以正确的方式处理,要保证出现错误的时候,操作级别的错误不会影响到系统稳定性。

每个模块都可以在出错后自动恢复
由于分布式系统中无法保证系统各个模块是始终连接的,因此每个模块要有自我修复的能力,保证不会因为连接不到其他模块而自我崩溃。

五.最后总结

规模增长是推动技术发展的一个重要因素。在设计系统的时候,我们有意识的问两个问题,如果业务量足够大之后,可能会存在什么问题?是否需要提前做一些设计?

尽可能的做到各模块之间彼此独立,不过度依赖,才能保持更灵活的扩展性,适应变化。

分层的对象设计,做到高内聚,松耦合。各个对象组合起来就像洋葱一样,看似一体,实则又是一个个独立的个体对象。比如从Pod,到ReplicaSet,到Deployment,再到Service。从内到外,它们一层包着一层,剥掉最外的一层,它还是能独立运行,再拨一层也还是能独立运行。

对象、幂等性、统一的Api入口、充分假设、高容错、自我修复等要求与机制融入到设计之中,使得Kubernetes如此的健壮和高扩展性。这些理念在我们设计分布式系统的时候,如分布式调度平台值得去借鉴和使用。

你可能感兴趣的:(kubernetes,docker,容器)