容器運行時（ContainerRuntime），運行於kubernetes（k8s）集羣的每個節點中，負責容器的整個生命週期。其中docker是目前應用最廣的。隨着容器雲的發展，越來越多的容器運行時涌現。爲了解決這些容器運行時和k8s的集成問題，在k8s1.5版本中，社區推出了CRI（ContainerRuntimeInterface,容器運行時接口）（如圖1所示），以支持更多的容器運行時。
Kubelet通過CRI和容器運行時進行通信，使得容器運行時能夠像插件一樣單獨運行。可以說每個容器運行時都有自己的優勢，這就允許用戶更容易選擇和替換自己的容器運行時。
一、CRI&OCI
CRI是kubernetes定義的一組gRPC服務。Kubelet作爲客戶端，基於gRPC框架，通過Socket和容器運行時通信。它包括兩類服務：鏡像服務（ImageService）和運行時服務（RuntimeService）。鏡像服務提供下載、檢查和刪除鏡像的遠程程序調用。運行時服務包含用於管理容器生命週期，以及與容器交互的調用（exec/attach/port-forward）的遠程程序調用。
如圖2所示，dockershim,containerd和cri-o都是遵循CRI的容器運行時，我們稱他們爲高層級運行時（High-levelRuntime）。
OCI（OpenContainerInitiative，開放容器計劃）定義了創建容器的格式和運行時的開源行業標準，包括鏡像規範（ImageSpecification）和運行時規範(RuntimeSpecification)。
鏡像規範定義了OCI鏡像的標準。如圖2所示，高層級運行時將會下載一個OCI鏡像，並把它解壓成OCI運行時文件系統包（filesystembundle）。
運行時規範則描述瞭如何從OCI運行時文件系統包運行容器程序，並且定義它的配置、運行環境和生命週期。如何爲新容器設置命名空間(namepsaces)和控制組(cgroups)，以及掛載根文件系統等等操作，都是在這裏定義的。它的一個參考實現是runC。我們稱其爲低層級運行時（Low-levelRuntime）。除runC以外，也有很多其他的運行時遵循OCI標準，例如kata-runtime。
二、ContainerdvsCri-o
目前docker仍是kubernetes默認的容器運行時。那爲什麼會選擇換掉docker呢？主要的原因是它的複雜性。
如圖3所示，我們總結了docker,containerd以及cri-o的詳細調用層級。Docker的多層封裝和調用，導致其在可維護性上略遜一籌，增加了線上問題的定位難度（貌似除了重啓docker，我們就毫無他法了）。Containerd和cri-o的方案比起docker簡潔很多。因此我們更偏向於選用更加簡單和純粹的containerd和cri-o作爲我們的容器運行時。
我們對containerd和cri-o進行了一組性能測試，包括創建、啓動、停止和刪除容器，以比較它們所耗的時間。如圖4所示，containerd在各個方面都表現良好，除了啓動容器這項。從總用時來看，containerd的用時還是要比cri-o要短的。
如圖5所示，從功能性來講，containerd和cri-o都符合CRI和OCI的標準。從穩定性來說，單獨使用containerd和cri-o都沒有足夠的生產環境經驗。但慶幸的是，containerd一直在docker裏使用，而docker的生產環境經驗可以說比較充足。可見在穩定性上containerd略勝一籌。所以我們最終選用了containerd。
三、DeviceMappervs.Overlayfs
容器運行時使用存儲驅動程序（storagedriver）來管理鏡像和容器的數據。目前我們生產環境選用的是DeviceMapper。然而目前DeviceMapper在新版本的docker中已經被棄用，containerd也放棄對DeviceMapper的支持。
當初選用DeviceMapper，也是有歷史原因的。我們大概是在2014年開始k8s這個項目的。那時候Overlayfs都還沒合進kernel。當時我們評估了docker支持的存儲驅動程序，發現DeviceMapper是最穩定的。所以我們選用了DeviceMapper。但是實際使用下來，由DeviceMapper引起的docker問題也不少。所以我們也借這個契機把DeviceMapper給換掉，換成現在containerd和docker都默認的Overlayfs。
從圖6的測試結果來看，Overlayfs的IO性能比DeviceMapper好很多。Overlayfs的IOPS大體上能比DeviceMapper高20%，和直接操作主機路徑差不多。
四、遷移方案
最終，我們選用了containerd，並以Overlayfs作爲存儲後端的文件系統，替換了原有的docker加DeviceMapper的搭配。那遷移前後的性能是否得到提升呢？我們在同一個節點上同時起10，30，50和80的pod，然後再同時刪除，去比較遷移前後創建和刪除的用時。從圖7和圖8可知，containerd用時明顯優於docker。
五、遷移挑戰
從docker+DeviceMapper到containerd+Overlayfs，容器運行時的遷移並非易事。這個過程中需要刪除DeviceMapper的thin_pool，全部重新下載用戶的容器鏡像，全新重建用戶的容器。
如圖9所示，遷移過程看似簡單，但是這對於已運行了5年且擁有**100K+**光怪陸離的應用程序的集羣而言，如何將用戶的影響降到最低纔是最難的。Containerd在我們生產環境中是否會出現“重大”問題也未可知。
針對這些挑戰，我們也從下面幾個方面做出了優化，來保證我們遷移過程的順利進行。
01 多樣的遷移策略
最基本的是以容錯域（FaultDomain,fd）爲單元遷移。針對我們集羣，是以rack（機架）爲單元（rackbyrack）遷移。針對雲原生（cloud-native）且跨容錯域部署的應用程序，此升級策略最爲安全有效。針對非雲原生的應用程序，我們根據其特性和部署拓撲，定製了專屬他們的升級策略，例如針對Cassini的集羣，我們採用了jenga（層層疊）的升級策略，保證應用程序0宕機。
02 自動化的遷移過程
以rackbyrack的策略爲例，需要等到一個rack遷移完成以後且客戶應用程序恢復到遷移前的狀態，才能進行下一個rack的遷移。因此我們對遷移控制器（Controller）進行了加強，利用控制平面（ControlPlane）的監控指標（Metrics）和數據平面（DataPlane,即應用程序）的告警（Alerts），實現典型問題的自動干預和修復功能，詳見圖10。如果問題不能被修復，錯誤率達到閾值，遷移纔會被暫停。對於大集羣，實現了人爲的0干預。
03 高可用的鏡像倉庫
一個rack共有76臺機器。假設每個機器上只有50個pod，就可能最多有3800個鏡像需要下載。這對鏡像倉庫的壓力是非常大的。除了使用本地倉庫，這次遷移過程中還使用了基於gossip協議的鏡像本地緩存的功能，來減少遠端服務端的壓力，具體參見圖11。
04 可逆的遷移過程
雖然我們對containerd的問題修復是有信心的，但是畢竟缺少生產環境經驗，得做好隨時回退的準備。一旦發現遷移後，存在極大程度影響集羣的可靠性和可用性的問題，我們就要換回docker。雖然遷移後,在線上的確發現了鏡像不能成功下載，容器不能啓動和刪除等問題，但是我們都找到了根本原因，並修復。所以令人慶幸的是，這個回退方法並未發揮其作用。
六、用戶體驗
容器運行時是kubernetes的後端服務。容器運行時的遷移不會改變任何的用戶體驗。但是有一個Overlayfs的問題需要特別說明一下。如果容器的基礎鏡像（BaseImage）是centos6，利用Dockerfile去創建鏡像時，如果用yum去安裝包，或者在運行的centos6容器中用yum安裝包的，會報以下錯誤：
因爲yum在安裝包的過程中，會先以只讀模式，然後再以寫模式去打開rmpdb文件。
如圖12所示，對於Overlayfs來說，以只讀模式打開一個文件的話，文件直接在下層（lowerlayer）被打開，我們得到一個fd1。當我們再以寫模式打開，就會觸發一個copy_up。rmpdb就會拷貝到上層（upperlayer）。文件就會在上層打開得到fd2。這兩個fd本來是想打開同一個文件，事實卻並非如此。
解決方案就是在執行yum命令之前先裝一個yum-plugin-ovl插件。這個插件就是去做一個初始的copy_up，如圖13所示。將rpmdb先拷貝到上層，參考Dockerfile如下：
如果基礎鏡像是centos7，則沒有這個問題，因爲centos7的基礎鏡像已經有這個規避方法了。
七、總結
目前我們50個集羣，20K+的節點已經全部遷到containerd，歷時2個月（非執行時間）。從目前情況來看，還比較穩定。雖然遷移過程中也出了不少問題，但經過各個小組的不懈努力，此次遷移終於順利完成了。
本文轉載自公衆號eBay技術薈（ID：eBayTechRecruiting）。
原文鏈接：