本文讲的是深入浅出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还采用了一个主动/被动双分区方案启动。
系统启动到根分区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（翻译：张亚龙）
原文发布时间为：2016-02-17
本文作者：ylzhang
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：深入浅出CoreOS（一）：概述