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</pre> 
 
我們將在以后的文章中講述配置文件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 （翻譯：張亞龍） 
 </div>