转载

CoreOS概览，第一部分

【编者的话】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概览，第一部分

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

系统启动到根分区A:

CoreOS概览，第一部分

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

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有一个内置的故障恢复区，如果升级结果不稳定可以执行恢复。这个过程也可以手动执行。
签名验证
每一个引导分区都是只读的，这样验证每一个下载的完整性就很容易了，我们还能确保在传输过程中不被篡改。
超快速执行
由于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集群引导方法：