一文解讀2019年容器基礎設施最新趨勢與進展
Kubernetes的崛起令人驚嘆。在短短幾年時間內，它已經從一個由一群云原生開發者倡導的開源項目轉變為由云服務提供商推廣的標準運維平臺。
由于應用程序工作負載從VM轉移到容器，Kubernetes已成為自動化和擴展容器部署的流行選擇。但是，到目前為止，Kubernetes的開發主要集中在基礎設施內部，而不是關于簡化應用程序開發和部署的更廣泛問題。幸運的是，這種孤立性正在逐漸消退，因為幾個PaaS堆棧正在將Kubernetes集群添加為支持的運行時目標，比如Pivotal Cloud Foundry，該公司將Cloud Foundry與Kubernetes集成的舉措代表著將容器編排平臺演變為企業友好環境的大趨勢。
正如我們之前所討論的，企業通過采用PaaS堆棧和開發方法來利用軟件抽象的力量，這有著令人信服的業務和技術原因。Cloud Foundry因為產品上市早，和基于技術優勢所提供的滿足開發人員和IT專業人員需求的完整系統而成為最受歡迎的選擇。Cloud Foundry長期以來一直使用容器作為應用程序運行時環境，但作為一個自包含的系統，容器由名為Garden的內部模塊管理。商業Pivotal Cloud Foundry版本的用戶很快將有另一種選擇——Kubernetes，并且有一系列增強功能——這些增強功能解決了阻礙企業采用Kubernetes的缺點。
Pivotal擁抱Kubernetes、服務網格
Pivotal通過提供集成的、受支持的軟件和服務，使Cloud Foundry成為企業PaaS。在最近的OSCON開發者大會上，該公司承認了Kubernetes作為容器管理系統的蓬勃發展，宣布其核心產品Pivotal Application Service的有限預覽版本在Kubernetes上運行。
“PAS on Kubernetes旨在將PAS的開發經驗帶到Kubernetes之上。alpha版本是概念驗證，支持PAS最重要的功能，例如`cf push`用于許多基于buildpack的應用程序，同時在Kubernetes上運行PAS app實例。下圖總結了alpha版本中的內容。”
Pivotal還實現了以下功能：
- Cloud Foundry應用程序實例運行Kubernetes pod，其中包含一個translator，可將PAS應用程序轉換為OCI(Open Container Initiative)鏡像和Kubernetes pod配置。然后，Kubernetes控制器管理應用程序的部署和擴展。
- 與PAS HTTP路由器集成，將客戶端請求的流量定向到Kubernetes上運行的應用程序。
- 應用程序和pod日志與PAS日志記錄系統(Loggregator)的集成。
- 最多支持50個應用程序實例。
alpha版本需要vSphere、NSX-T和Pivotal企業容器服務PKS，但該公司計劃支持其他Kubernetes平臺，特別是AWS、Azure和Google Cloud Kubernetes服務。
在過去幾個月里，Pivotal還推出了其他幾款Kubernetes產品，包括基于開源Buildpacks項目創建容器鏡像的構建服務、對Spring Java Runtime環境和Kubernetes上RabbitMQ軟件的支持以及基于Istio和Envoy(自動化客戶端訪問在Kubernetes集群上運行的應用程序)的容器服務網格。這些都顯著增強了Kubernetes作為生產應用平臺的實用性和可用性。此外，作為商業支持的產品，它們不需要安裝、調整和調試開源軟件所需的專業人士和專業知識。
IBM引領云原生應用程序開發
IBM還忙于為企業開發人員提供Kubernetes增強功能，宣布了幾個旨在加速和簡化容器化應用程序開發的開源項目。雖然尚未打包為商業軟件，但以下項目將特別吸引剛接觸云原生應用程序設計的開發人員：
Kabanero是容器化應用程序的體系結構和開發框架。它使用Kubernetes進行工作負載管理，滿足架構師、Java開發人員和DevOps交付團隊的需求。它建立在其他三個與Kubernetes相關的項目上：Knative(開發過程自動化和無服務器端點)、Istio(服務網格)和Tekton(CI / CD集成)。通過開發運行時和框架(Node.js、Java、Swift)，Kabanero將配置Kubernetes集群、安全性和網絡的實踐封裝到預構建部署中。它還包含幾個新項目，包括：
- Appsody通過捆綁多個流行編程環境的預配置開發框架和模板，簡化了應用程序開發。
- Codewind是一個開源開發項目管理器，它為流行的IDE(包括Eclipse和Visual Studio)添加了容器支持。
- Razee是一個持續交付工具，支持針對Kubernetes部署的容器化微服務，其中包括可視化配置信息和部署的圖形界面，以幫助進行故障排除。它通過內置模板簡化了多集群部署，這些模板跨集群和云環境實施配置和安全策略。
來看看IBM的聲明，“沒有任何其他開源項目能夠通過整個Kubernetes生產生命周期創建容器化云原生應用程序提供集成體驗。”“通過使用Kabanero，你的開發團隊能夠構建可以部署到Kubernetes上的應用程序，而無需先成為容器和Kubernetes的專家。這降低了開發人員在企業從遺留基礎設施轉移到更現代化的基礎設施的云化過程中的進入門檻。”
容器的強有力采用與警示性挑戰并存
Pivotal(還有戴爾和VMware)和IBM(以及紅帽)都意識到，企業開發人員和IT組織將容器視為比他們當前使用的VM服務器更高效、更靈活和更可擴展的應用程序環境。但是，企業用戶仍然在努力應對不成熟的技術、挑戰性的安全配置、陡峭的學習曲線以及無法輕松集成到其他系統中的復雜基礎設施。
事實上，Diamanti最近的一項調查表明，容器的使用越來越多，而企業采用者面臨著持續的挑戰。容器已進入主流，調查發現IT和平臺架構師負責大部分容器決策，而今年在容器技術上花費至少10萬美元的組織增加了5.5個百分點，達到38.5%。此外，在容器上至少花費100000美元的組織中，有26%計劃將大部分工作負載量轉移到容器上。
企業努力應對的一個領域是找到足夠的容器專業知識來實現其目標。那些認為缺乏容器技能的人才是“主要采用抑制因素”的人今年增加了一半，幾乎占調查對象的四分之一。而認為沒有影響的受訪者是指只對花費最少的容器技術(少于50000美元)計劃沒有影響，即剛開始或測試最小容器安裝的那些。實際上，近65%的人認為技能短缺是中度或主要的采用抑制因素。
至于在生產中運行容器，多年來什么是主要的挑戰非常一致：與現有基礎設施的集成、安全性和部署復雜性。這些抑制因素是Diamanti、PAS、Red Hat OpenShift等打包容器平臺在企業IT和DevOps組織中如此受歡迎的關鍵原因。
筆者的看法
在一大堆服務器配置、網絡管道和編程語法的神秘細節中，關于Kubernetes的討論似乎無可救藥地偏題了，這讓業務和IT主管們質疑該技術如何滿足他們對新應用程序的需求和實現更快的上市時間。對于這些非專業人士來說，他們并不多關心設計細節。相反，應用程序所有者、贊助商和業務主管希望了解Kubernetes如何為他們節省資金，提高應用程序性能并縮短開發時間。而通過專注于應用程序開發過程而不是交付系統，可以更好地實現這些目標。
這就是Kubernetes開發人員的機會——無論是Pivotal和IBM等商業軟件公司，AWS、微軟和谷歌等云服務提供商，還是Kubernetes生態系統的大量開源貢獻者。企業已經意識到容器和Kubernetes的價值，但需要在以下方面簡化產品和服務：
- 開發容器化的云原生應用程序
- 部署容器基礎設施
- 管理容器工作負載和安全策略
最近的進展體現了容器基礎設施發展的潛力和希望。核心容器技術與PaaS框架和開發方法論的結合最終將使Kubernetes及其生態系統足夠成熟，為普通企業所用。
