隨著容器發展模式逐漸成為主流，容器堆棧本身也在不斷發展?，F在，企業看到了容器的價值，開發和業務重點正在從引擎轉移到增加更多復雜的功能，以便更直接地獲得業務收益。事實上，在短短幾年內，容器已經從沒有管理、技術精湛和社區分化的現狀轉變成為更加高雅、商用化的IT包，并且完全遵循由跨廠商的開放容器生態。

在最基本的層面上，Linux容器使得企業能夠將應用程序域整個runtime環境打包并隔離，以運行所需的所有文件。這使得在保留全部功能的同時在環境(開發、測試和生產等)之間遷移容器化應用變得容易。Linux容器通過分隔責任區域來幫助減少開發和運營團隊之間的沖突，開發人員可以專注于他們的應用程序，運營人員則專注于基礎設施。

[[217214]]

而且，因為Linux容器是基于開源技術的，所以一旦得以應用，組織就可以獲得最新和最大的技術進步。容器技術(如CRI-O，Kubernetes和Docker)可以幫助簡化團隊，加速和協調應用程序開發和部署。

事實上，容器正處于IT不斷發展的進化階段，他們正在成為創新的平臺。從復合應用程序和微服務到快速應用程序開發以及DevOps的各種排列，企業IT現在處于另一個轉折點：路在何方?

以下是組織和開發人員現在需要了解的關于容器堆棧以及如何改變的八件事情。

要素

要運行容器，需要整個企業容器基礎設施：Linux、runtime、編排。這個堆棧通常由LDK-Linux、Docker和Kubernetes組成，但隨著容器技術的發展，這一趨勢也在不斷發展。Docker并不是唯一的通用容器runtime，新的容器似乎每天都在冒出來。而且，專用的容器runtime正在開發中，它能夠讓用戶推進邊界，如在隔離的虛擬機中運行容器。

Kubernetes為王

容器技術使得企業能夠更有效地開發、測試、部署和維護應用程序，這是當今任何組織的競爭命脈。但是容器本質上有很多移動部件，而且大多數公司都有很多容器。Kubernetes Orchestration，一款用于自動化部署，擴展和管理容器化應用程序的開源系統，使企業能夠充分發揮容器的優勢。除此之外，還有其他一些選擇，最著名的是Mesos和Swarm，但是不得不說Kubernetes已經成為了行業的標準。

CRI和CRI-O的角色

去年，Kubernetes項目引入了它的容器運行時接口(CRI)，這是一個插件接口，它提供kubelet，這是一個用于創建容器和啟動容器的集群節點代理，可以使用不同的OCI兼容容器運行時而不需要重新編譯Kubernetes。在這項工作的基礎上，CRI-O項目(最初稱為OCID)為Kubernetes提供了一個輕量級的runtime。CRI-O使開發人員能夠直接從Kubernetes運行容器; 只要容器圖像符合OCI標準，CRI-O就可以運行它。這消除了對獨立運行時間的需求，降低了復雜性并提高了可靠性。

容器標準

容器的標準化對于企業更廣泛和更有效地采用容器起到推動作用，但對于公司和開發團隊來說，能夠將這些標準放在其環境中做出關于容器堆棧的正確決策是非常重要的。現在要關注的標準組織包括Open Container Initiative(OCI)Image Specification(1.0.1版剛剛發布); OCI運行時間規范(也是版本1.0.1); Kubernetes Container Runtime Initiative(CRI);容器網絡接口(CNI)和Docker容器網絡模型(CNM)。

各種開源項目的角色

Google工程師基于內部平臺開發的Kubernetes可以說是目前容器領域最活躍的開源項目之一。雖然Kubernetes可能是最明顯的開源容器項目之一，但還有其他幾十個正在推動容器棧的項目。例如，Origin是OpenShift的上游項目，它使組織能夠開發，部署和管理容器。組織和個人都可以通過成為這些社區中的一個或多個社區的積極貢獻者，更充分地利用容器。

公有云集成

隨著企業擴大其容器堆棧的應用，利用公有云受到企業重視。例如，現在很多AWS服務都可以通過內置在OpenShift Container Platform中的Service Broker界面訪問。這使得AWS用戶可以更輕松地在OpenShift中配置和部署服務，并為企業需求提供基于Kubernetes的單一可擴展應用程序定義。

無聊是件好事

今天的IT專業人員不會考慮Linux內核，因為這很無聊。真正的創新都是在內核以上，容器runtime接口也是如此。事實上，當你在考慮容器堆棧時，這個值已經不再是runtime級別的了。runtime已經成為無聊的工作，這意味著組織不必擔心或投入資源。相反，他們可以把重點放在如何通過容器生態系統的發展以及容器在自己的組織中的使用來創新。

應用程序開發重定義

Linux容器的潛力比重新定義開發乃至操作都要大的多。它們也加速了應用程序本身的重新定義，由于容器的原因，我們所知道的整體式應用程序堆棧可以分解成幾十個甚至數百個細小的單一用途的應用程序，這些應用程序組合在一起時，可以執行與傳統應用程序相同的功能。這使得每個單獨的部分都可以被重寫、重用和管理，遠比單一應用程序更有效，從而提供了一個完全由微服務構建的真正的復合應用程序，可以輕松擴展以滿足需求。雖然微服務架構并不要求使用容器，但大多數轉向微服務的組織都會發現容器是實現應用程序的最佳方式。