| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
YWPRay
8年前发布

CoreOS概览,第一部分

来自: http://dockone.io/article/1026

【编者的话】CoreOS是一款OS,但它是一款面向云的轻量级OS。CoreOS是以Linux系统为基础,为了建设数据中心的需要,而从Linux底层进行了内核裁减。CoreOS提供了一系列的机制和工具来保证CoreOS组建的云环境是安全,可靠和最新的。CoreOS设计之初就定位于可以提供一种动态缩放和管理集群的能力,可以方便管理类似google 这种庞大数据中心的集群。本系列文章从浅入深介绍了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使用率的对比:

除此之外,CoreOS还采用了一个主动/被动双分区方案启动。

系统启动到根分区A:

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

CoreOS更新

满足CoreOS频繁更新是系统的理念,可靠的更新是良好安全性的关键。

CoreOS通过合并经常需要更新的为一个实体,实现最小化每一个复杂的更新:

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

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

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

如何更新

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

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

CoreOS会下载一个完整的新分区文件系统,而不是每次只更新一个包。

下载更新后,操作系统更新会被应用到B分区(被动),重新启动之后B分区就会变成主动引导分区,并引导系统启动。

下图描述这个过程:

如果在重新启动引导中更新不成功,则回滚在先前的启动分区。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,当然也会涉及一部分集群架构的内容。

原文链接: CoreOS Overview, Part One (翻译:张亚龙)

 本文由用户 YWPRay 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1455707157855.html
CoreOS CentOS