干货速递 ▎Kubernetes有状态集群服务部署与管理(上)

Tenxcloud · · 969 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。
2016年12月2日,时速云架构师张寿红应邀参加ArchSummit2016全球架构师峰会,并在微服务与容器实践专场做了《Kubernetes有状态集群服务部署与管理》的干货分享。 ![](http://blog.tenxcloud.com/wp-content/uploads/2016/12/ArchSummit%E5%8C%97%E4%BA%AC2016%E5%BC%A0%E5%AF%BF%E7%BA%A204.jpg) 现场演讲图 由于篇幅关系,第一部分Kubernetes相关概念略过不提,本文将结合分享内容,对《Kubernetes有状态服务部署与管理》之**K8S存储系统**做重点阐述。对K8S有状态服务特性:**Init Container** 和 **Pet Set**感兴趣的伙伴,请关注《Kubernetes有状态集群服务部署与管理(下)》 ![](http://blog.tenxcloud.com/wp-content/uploads/2016/12/%E4%B8%8A1.png) **在K8S运行的服务,从简单到复杂可以分成三类:无状态服务、普通有状态服务和有状态集群服务。**下面分别来看K8S是如何运行这三类服务的。 - **无状态服务**,K8S使用RC(或更新的Replica Set)来保证一个服务的实例数量,如果说某个Pod实例由于某种原因Crash了,RC会立刻用这个Pod的模版新启一个Pod来替代它,由于是无状态的服务,新启的Pod与原来健康状态下的Pod一模一样。在Pod被重建后它的IP地址可能发生变化,为了对外提供一个稳定的访问接口,K8S引入了Service的概念。一个Service后面可以挂多个Pod,实现服务的高可用。 - **普通有状态服务**,和无状态服务相比,它多了状态保存的需求。Kubernetes提供了以Volume和Persistent Volume为基础的存储系统,可以实现服务的状态保存。 - **有状态集群服务**,与普通有状态服务相比,它多了集群管理的需求。K8S为此开发了一套以Pet Set为核心的全新特性,方便了有状态集群服务在K8S上的部署和管理。具体来说是通过Init Container来做集群的初始化工作,用 Headless Service 来维持集群成员的稳定关系,用动态存储供给来方便集群扩容,最后用Pet Set来综合管理整个集群。 **要运行有状态集群服务要解决的问题有两个,一个是状态保存,另一个是集群管理。** 我们先来看如何解决第一个问题:状态保存。Kubernetes 有一套以Volume插件为基础的存储系统,通过这套存储系统可以实现应用和服务的状态保存。 **K8S的存储系统从基础到高级又大致分为三个层次:普通Volume,Persistent Volume 和动态存储供应。** ## 1.普通Volume 最简单的普通Volume是单节点Volume。它和Docker的存储卷类似,使用的是Pod所在K8S节点的本地目录。 第二种类型是跨节点存储卷,这种存储卷不和某个具体的K8S节点绑定,而是独立于K8S节点存在的,整个存储集群和K8S集群是两个集群,相互独立。 跨节点的存储卷在Kubernetes上用的比较多,如果已有的存储不能满足要求,还可以开发自己的Volume插件,只需要实现Volume.go 里定义的接口。如果你是一个存储厂商,想要自己的存储支持Kubernetes 上运行的容器,就可以去开发一个自己的Volume插件。 ## 2.persistent volume 它和普通Volume的区别是什么呢? 普通Volume和使用它的Pod之间是一种静态绑定关系,在定义Pod的文件里,同时定义了它使用的Volume。Volume 是Pod的附属品,我们无法单独创建一个Volume,因为它不是一个独立的K8S资源对象。 而Persistent Volume 简称PV是一个K8S资源对象,所以我们可以单独创建一个PV。它不和Pod直接发生关系,而是通过Persistent Volume Claim,简称PVC来实现动态绑定。Pod定义里指定的是PVC,然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。 PV的访问模式有三种: **第一种,ReadWriteOnce**:是最基本的方式,可读可写,但只支持被单个Pod挂载。 **第二种,ReadOnlyMany**:可以以只读的方式被多个Pod挂载。 **第三种,ReadWriteMany**:这种存储可以以读写的方式被多个Pod共享。不是每一种存储都支持这三种方式,像共享方式,目前支持的还比较少,比较常用的是NFS。在PVC绑定PV时通常根据两个条件来绑定,一个是存储的大小,另一个就是访问模式。 刚才提到说PV与普通Volume的区别是动态绑定,我们来看一下这个过程是怎样的。 ![](http://blog.tenxcloud.com/wp-content/uploads/2016/12/%E4%B8%8A2.png) 这是PV的生命周期,首先是Provision,即创建PV,这里创建PV有两种方式,静态和动态。所谓静态,是管理员手动创建一堆PV,组成一个PV池,供PVC来绑定。动态方式是通过一个叫 Storage Class的对象由存储系统根据PVC的要求自动创建。 一个PV创建完后状态会变成Available,等待被PVC绑定。 一旦被PVC邦定,PV的状态会变成Bound,就可以被定义了相应PVC的Pod使用。 Pod使用完后会释放PV,PV的状态变成Released。 变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略,Retain、Delete 和 Recycle。Retain就是保留现场,K8S什么也不做,等待用户手动去处理PV里的数据,处理完后,再手动删除PV。Delete 策略,K8S会自动删除该PV及里面的数据。Recycle方式,K8S会将PV里的数据删除,然后把PV的状态变成Available,又可以被新的PVC绑定使用。 在实际使用场景里,PV的创建和使用通常不是同一个人。这里有一个典型的应用场景:管理员创建一个PV池,开发人员创建Pod和PVC,PVC里定义了Pod所需存储的大小和访问模式,然后PVC会到PV池里自动匹配最合适的PV给Pod使用。 前面在介绍PV的生命周期时,提到PV的供给有两种方式,静态和动态。**其中动态方式是通过StorageClass来完成的,这是一种新的存储供应方式。** 使用StorageClass有什么好处呢?除了由存储系统动态创建,节省了管理员的时间,还有一个好处是可以封装不同类型的存储供PVC选用。在StorageClass出现以前,PVC绑定一个PV只能根据两个条件,一个是存储的大小,另一个是访问模式。在StorageClass出现后,等于增加了一个绑定维度。 比如这里就有两个StorageClass,它们都是用谷歌的存储系统,但是一个使用的是普通磁盘,我们把这个StorageClass命名为slow。另一个使用的是SSD,我们把它命名为fast。 在PVC里除了常规的大小、访问模式的要求外,还通过annotation指定了Storage Class的名字为fast,这样这个PVC就会绑定一个SSD,而不会绑定一个普通的磁盘。 到这里Kubernetes的整个存储系统就都介绍完了。总结一下,**两种存储卷:普通Volume 和Persistent Volume。**普通Volume在定义Pod的时候直接定义,Persistent Volume通过Persistent Volume Claim来动态绑定。PV可以手动创建,也可以通过StorageClass来动态创建。 Tips: 关注时速云公众号(tenxcloud2),回复 "**1206** "即可获得下载现场PPT。 ![](http://blog.tenxcloud.com/wp-content/uploads/2016/11/qrcode_for_gh_e6bc8f4082d2_430-2.jpg) 下篇文章将介绍Kubernetes与有状态集群服务相关的两个新特性:**Init Container 和 Pet Set**。敬请关注!

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

969 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传