彙總一週容器圈熱點資訊，讓開發者瞭解最 in 的容器技術，讓企業熟知最實時的國內外容器行業動態
1.針對 Kubernetes 進行優化的容器執行時環境 – CRI-O 1.0 正式釋出
2.Notary 是什麼專案？為什麼他對 CNCF 來說如此重要？
3.Oracle 開源 Fn，加入 Serverless 之爭
針對 Kubernetes 進行優化的容器執行時環境 – CRI-O 1.0 正式釋出
10 月 26 日，基於Kubernetes容器執行時介面（CRI）和 Open Container Initiative（OCI）標準容器的 CRI-O 1.0 版本釋出。這是一個輕量級的，專門對 Kubernetes 進行優化的容器執行時環境。它是將 Docker 用作 Kubernetes 的執行時的一種輕量級的替代方案。
對於 CRI-O 團隊而言今天是一個激動的日子。 就在一年前，Antonio Murdaca 和我們研發團隊的 Antonio Murdaca 建立了一個名為 OCID 的專案，後來改名為 CRI-O。
我們的目標是為了確認我們是否可以構建一個簡單的後臺程式，這個程式既可以同時支援基於 Kubernetes 容器執行時介面（CRI）和 Open Container Initiative（OCI）標準的容器。也因如此，這個專案才會命名為 CRI-O。
當時我們認為由於上游的 Docker 專案變化太快，導致了 Kubernetes 的不穩定。因此我們認為通過簡化容器執行時環境我們應該可以做的更好。
我們的第一個版本的 CRI-O v1.0 是基於Kubernetes 1.7版本。 工程團隊希望有一個1.0版本。這是 OpenShift 3.7 中正在構建的版本。我們還計劃近期釋出 CRI-O 1.8，未來 CRI-O所有的版本都會與它們所支援的 Kubernetes 版本保持一致。
CRI-O 專案的另一個目標是與其他專案共享技術。 我們知道我們自己無法構建一切。 首先，我們需要能夠支援與基於 OCI 標準的執行時環境如 runC 以及 Intel 的 Clear Containers 一起工作。
我們也希望使用像 containers/storage 以及 containers/image 這樣的庫，這樣我們可以有效的取長補短。同時我們並不希望像其他的容器執行時環境一樣將所有的鎖以及容器狀態放在記憶體當中，這種做法會阻止系統中的其它程式與映象和及儲存系統協同工作。因此 CRI-O 能夠與 Skepeo 和 Buildah 這樣的工具一起很好的工作。對於未來，我們很樂意能夠看到其它專案能夠分享這些內容。
對於這個專案而言，我們另外的一個目標是能夠比其它的容器執行時環境更輕。能夠佔用更小的內容空間，以及相比其他容器執行時環境對 Kubernetes 提供更好的效能表現。
CRI-O 也非常感謝處於（容器生態系統）上游的 Docker 專案。正如 Isaac Newton 所說：“如果我能夠看得更遠，那一定是站在巨人的肩膀上”。同樣，CRI-O 專案的工程師也從 Docker 專案中學習到了許多的經驗。同時，我們也相信我們能夠從他們過去的錯誤中吸取教訓。由於開源，他們也能夠借用一些其他的技術了。我們的工程師也會繼續對Moby（原名 Docker）專案做出貢獻，並且希望所有容器相關的專案都能夠繼續蓬勃發展。
V1.0 只是一個開始。我們對於 CRI-O 的未來還有很多大的計劃。做出一些新的嘗試，並且一如既往的歡迎貢獻者們的加入。
Notary 是什麼專案？為什麼他對 CNCF 來說如此重要？
正如你聽說的那樣，Notary 專案正式加入雲原生計算基金會（Cloud Native Computing Foundation，CNCF）。也如 notary(公證人)本意一樣，Notary 是一個用於建立內容之間信任的平臺。
在現實生活中，想買房子這樣重要的事，一般由一個被稱作“公證人”的值得信賴的第三方所促成。當你在購買房子時，“公證人”通常受僱於貸款人以驗明你的身份，並作為你在抵押協議上簽名的見證人。“公證人”攜帶特別的印章，並簽署檔案作為確認，核實與借款人有關的所有必要資訊。
以類似的方式，最初由 Docker 贊助的 Notary 專案，旨在通過強大的加密簽名提供對數字內容的高度信任。除了確保軟體的來源之外，他還能提供保證：在供應鏈中的任何地方，未經作者批准，內容都不會被修改。這樣就可以讓附帶 Docker Content Trust（使用 Notary）的 Docker 的產品建立更高階別的系統來制定明確的內容使用的政策。比方說，可以設定策略，只有簽名的內容可以在執行時使用，並由 Docker 平臺中的業務流程部署。總體來說，Notary 是 Docker 安全供應鏈的核心部分，其安全性無縫地統一嵌入到從開發到運營的工作流程中。
Notary 是一個寫在 Go 中的 The Update Framework (TUF) 的執行，TUF 與 Notary 都被提交加入 CNCF 專案。這兩個專案的綜合性質吸引了大量的注資 – 規範和最廣泛部署的實施將在 CNCF 的主持下進行。
諸如容器化和 Kubernetes 等技術已經成為 CNCF 的專案，Notary 和 TUF是首批與 CNCF 相關的安全專案。今年，資料安全方面的進展有著顯著的上升，我們相信 CNCF 正通過 Notary 和 TUF 的加入，讓自己置身於這方面的前列位置。我們希望隨著時間的推移，CNCF 能增加更多以安全為重點的專案。
Oracle 開源 Fn，加入 Serverless 之爭
Oracle 釋出了Fn，Fn是一個新開源的、雲平臺無關的Serverless平臺。它初始啟動時擁有廣泛的Java能力和一個JUnit測試框架，但也支援”任何程式語言”。
Fn 包含四個主要的元件：Fn 伺服器、Fn FDK、Fn Flow 和 Fn 負載均衡器。Fn 伺服器以 Go 編寫，是執行程式碼的平臺。
開發人員可以根據偏愛的語言使用一種 FDK（Function Development Kit），構建和測試實現業務功能的函式。函式打包之後，就部署到 Fn 伺服器。Fn Flow 提供了一個用於工作流的時序控制和編排的工具，因此函式可以連結在一起以實現更高階別的業務流程。這消除了微服務架構由於服務需要彼此呼叫而導致的常見的耦合問題。負載均衡器是運營團隊部署Fn伺服器群集並將流量路由到其中的工具。
與最近釋出的 Spring Cloud Function 專案一樣，Oracle 的 Fn 提供了一個雲平臺無關的框架。函式打包成容器，可以在任何支援Docker的平臺上執行。“container native”是Fn專案開發團隊的具體目標，使其開源也是他們的目標。在一篇博文中，Oracle 軟體開發副總裁 Chad Arimura 表示，Fn 團隊認為開源是現在軟體交付和採用的方式。因此，Fn 專案使用 Apache 2.0 許可證開源，而這一戰略似乎正在取得成效。
Arimura 是 Iron.io 的前創始人兼 CIO。他以及開發 IronFunctions（開創性的 Serverless 平臺之一）的團隊去年搬到了 Oracle，然後就開發了 Fn 專案。儘管 Arimura 將Fn 平臺無關性視為將其與其他 Serverless 框架區分開來的因素之一，但也許不足為奇的是，Fn 路線圖的後續步驟之一是將其作為 Oracle Cloud 的服務。他還列出了 container-native、擁有更完整的開發人員支援並且 orchestrator 無關的關鍵特徵，這些特徵有助於 Fn 專案在 Serverless 領域脫穎而出。
這一期的『航海日誌』就到這裡，下期再浪～
參考連結