深入浅出CoreOS



  • CoreOS是很多容器栈中的重要的组成部分。我们将通过这一系列的文章探讨CoreOS为什么这么重要,它到底是怎么工作的。如果您现在对CoreOS所知不多,请不用担心,让我们从头开始学习。

    CoreOS的基础以及CoreOS与其他Linux系统的区别

    CoreOS是以安全性、一致性、可靠性为设计目标的一款操作系统。

    • CoreOS采用主动/被动双分区方案来实现自动更新。自动更新以单一体为单位,而不是通过逐包替换的方式进行。稍后我们将详细介绍这个。
    • CoreOS使用Linux容器在更高抽象层次上管理服务,而没有采用通过yum或者APT工具做包的安装管理。单一的服务代码以及它所有的依赖会被打包到一个容器中,打包进入容器后就可以运行在单一的CoreOS机器,也可以运行在CoreOS集群中。
    • Linux容器提供与完整虚拟机相似的功能。但是容器聚焦在应用程序层次,而不是整个虚拟主机层次。因为容器不能运行独立的Linux内核,不需要一个中间件层,因此它几乎没有性能上的开销。低性能开销的特质意味着可以部署更少的机器、使用配置低的机器就可以完成虚拟机同样的功能,从而降低成本。

    CoreOS几乎可以运行在包括Vagrant, Amazon EC2, QEMU/KVM, VMware, OpenStack的任何平台,甚至在未安装任何软件的裸机硬件环境都可以。

    因为CoreOS的设计初衷只为运行应用容器,因此需要安装很少系统级别的依赖包即可。相比典型的Linux服务器,这就意味着CoreOS需要很低耗的CPU和高效的RAM即可满足需求。

    例如下面是一个RAM使用率的对比:

    465e000cf24ff9393d34cc36fda0128b.png

    除此之外,CoreOS还采用了一个主动/被动双分区方案启动。
    系统启动到根分区A:

    dd66c65e58adaeb84475b83d03d9d6b7.png

    目标一下子就变得非常清晰了。

    CoreOS更新

    满足CoreOS频繁更新是系统的理念,可靠的更新是良好安全性的关键。
    CoreOS通过合并经常需要更新的为一个实体,实现最小化每一个复杂的更新:

    • 操作系统级
    • 应用程序代码级
    • 单一配置

    FastPatch是一个主动-被动根分区方案, CoreOS的更新是通过使用FastPatch保持一致。它是通过将整个系统作为一个单一的单位替换更新,而不是通过包与包的不断替换更新。

    一旦CoreOS的更新可用,所有的CoreOS都是通过访问公共的更新服务来接收更新。包括渠道到渠道之间版本的升级更新服务都是由CoreOS工程师团队亲自管理的。每一次更新服务的发布都很便捷。这些更新永远是针对所有的用户可用的,而不会再去考虑用户地位等。

    如何更新

    上述所说的更新类型一直用于传统电子元器件更新,现在大多数浏览器的更新也是这样的。考虑一下,像Chrome和Firefox是怎么实现频繁无缝自动更新的?事实上,CoreOS团队也使用了Chrome的更新引擎Omaha。Omaha使用的是一个基于XML客户端-服务器协议。

    开始时,系统启动进入A分区(主动),CoreOS开始启动查询更新服务,查询获取相关更新。如果更新可用,下载并安装到B分区。

    CoreOS会下载一个完整的新分区文件系统,而不是每次只更新一个包。
    下载更新后,操作系统更新会被应用到B分区(被动),重新启动之后B分区就会变成主动引导分区,并引导系统启动。
    下图描述这个过程:

    3778a54e9ffdd7be94a40708e83941a4.png

    如果在重新启动引导中更新不成功,则回滚在先前的启动分区。CoreOS中系统的更新是一个原子的操作,所以很容易回滚。
    双分区方案在就地升级时具有很大的优势:

    • 安全回滚
      以前已知的稳定版本仍在第一个分区。CoreOS有一个内置的故障恢复区,如果升级结果不稳定可以执行恢复。这个过程也可以手动执行。
    • 签名验证
      每一个引导分区都是只读的,这样验证每一个下载的完整性就很容易了,我们还能确保在传输过程中不被篡改。
    • 超快速执行
      由于CoreOS体积很小,所以启动非常迅速。执行一次更新需要重启只用几秒就可以完成。这也意味着会最大限度地减少应用程序中断的时间。平台支持kexec,就可以跳过启动过程,进一步缩短启动的时间。

    更新策略和自动更新

    CoreOS默认会开启自动更新模式。
    每一个CoreOS集群都有一个独特的风险承受能力和业务需求。为了满足每一个人的需求,我们有四个更新策略。

    让我们更详细地看一下这些更新策略:

    • Best-effort:
      这个策略是默认的。它会检测机器是否是集群的一部分,如果属于集群,则Etcd-lock策略启用;否则Reboot策略启用。
      建议在生产集群中使用此策略。
    • Etcd-lock:
      这一策略授权给每一个机器,而且会在重启之前获取Reboot锁,才可以重新启动。这一策略的主要目标是允许更新快速应用到集群中,而不用在etcd丢失全体用户或者在集群中减少服务的负载容积。重启锁会在更新成功前一直起作用。
    • Reboot:
      这一策略是重启机器后尽快将更新安装到被动分区。
      这一策略对准确时间定时启动的机器比较有适用。例如,通过云配置维护窗口自动更新的机器。
    • Off:
      该机器在成功更新到被动分区后不会重新启动。
      该策略用户本地开发环境下,重启控制在用户自己手中;或者在生产集群中,集群在固定的时间或晚上重新启动。

    CoreOS自动重启由重启管理工具locksmith完成,locksmith是CoreOS更新引擎,使用etcd确保集群的子集可以在任何时间重启主机。locksmith只在CoreOS上运行一个守护进程,负责更新后控制系统的重启任务。

    更新的策略在更新部分的cloud-configfile配置:

    #cloud-config
    coreos:
    update:
    reboot-strategy: best-effort
    

    我们将在以后的文章中讲述配置文件cloud-config的细节。

    发行渠道

    CoreOS有三个更新渠道

    • Alpha
    • Beta
    • Stable

    按照顺序,CoreOS的发布过程是:alpha,beta,最后是stable。低一级渠道的发行版都为下一个版本发行版服务。一旦一个版本被认为已经没有Bug,就可以进入下一级发行渠道,一级一级往下。也会可能在stable渠道中下载安装,然后转换为接收beta或者alpha渠道的更新,这都是很容易做到的。相似的,也可能会安装beta渠道的版本,后来转换接收alpha的更新。

    注意:安装alpha渠道版本,后续转换为beta或者stable渠道再请求更新,这样是不可以的。

    转换系统发布渠道时,我们创建一个update.conffile:

    $ sudo vi /etc/coreos/update.conf
    

    然后设置所需的释放渠道:

    GROUP=beta
    

    现在重新启动更新引擎,以便它可以选择改变的渠道:

    $ sudo systemctl restart update-engine
    

    当下一个更新检查完成时,新的发布渠道已经被应用。

    集群发现

    CoreOS使用etcd专门处理集群上软件之间的协调,它运行在每一个系统上。一组CoreOS机器组成一个集群,他们的etcd进程需要互相连接。后续的文章将详细讲述etcd。

    发现服务是通过存储每一个地址列表、元数据、唯一地址的初始化的集群,提供免费连接etcd成员之间的通信的帮助,称之为发现URL,例如https://discovery.etcd.io。
    你可以非常容易地生成一个发现URL。

    $ curl -w "\n" 'https://discovery.etcd.io/new?size=3' 
    

    这应该产生这样的输出:

    https://discovery.etcd.io/6a28e078895c5ec737174db2419bb2f3
    

    这样通过提供给每一个发现服务一个发现Token,这也就是为什么这个服务能被发现相应。
    这仅仅用于初步的发现,一旦一台机器位于一个对等的位置,所有的通信沟通都将在整个集群内部进行。

    发现服务URL可以通过cloud-config(编者注)提供每个CoreOS配置,cloud-config是一个很小的配置工具,主要用于连接在网络和集群的机器。本系列后续的部分将解释发生在幕后的一些细节,但是如果你想尽可能迅速获取集群,你要做的就是提供一个新鲜独特的发现,配置在cloud-config文件中。

    有其他的etcd集群引导方法:

    • Static:在etcd集群 静态IP地址被用于引导
    • DNS发现:SRV记录作为一个发现机制

    你能够在说明文档中读到更多关于集群发现的信息

    总结:

    在这篇文章中,我们讲述到:

    • CoreOS与其他Linux系统的区别
    • 自动更新机制与发布渠道
    • 集群发现的原理

    在接下来这个系列的文章中,我们着重探讨一下cloud-config、etcd,当然也会涉及一部分集群架构的内容。

    原文链接: http://dockone.io/article/1026


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待