Kubernetes是容器化微服務的聖盃麼？

Kubernetes已成爲山丘之王。開源技術Kubernetes以及隨後的發行版正以超快的速度讓人們愛上容器技術，而且開始奪回對容器化環境的控制權。不幸的是，編排容器只是戰鬥進行了一半。

---

雲服務提供商接連宣佈他們的編排選擇是Kubernetes私有發行版：Red Hat OpenShift（和CoreOS Tectonic），IBM Cloud，Microsoft Azure，VMware，Pivotal Container Service，Oracle Cloud，Google Kubernetes Engine，固然還有亞馬遜網絡服務。他們都建立了本身的Kubernetes發行版，並在其上標準化了編排流程。

最後，有一種標準方法能夠控制半序混亂狀態，即容器化應用程序基礎架構。如今，咱們有一種方法來了解什麼時候須要容器資源，以及什麼時候釋放。

編排擅長將已知資源集帶入系統，觀察正在使用的資源，並據此作出基礎架構/容器部署決策。使用K8s編排管理容器時，有兩個問題：

一是它只能根據系統所知作出決策，二是它沒有將應用程序性能歸入決策過程。

沒有數據，您的分析工具將失去用處。實際上，互聯網上充斥着藉助數據以供分析的問題的文章。但咱們要更進一步。Kubernetes（或任何編排）的最大問題是丟失了一些數據，有時丟失數據與數據錯誤同樣有害。

這使咱們從上面回到了第二個問題：應用程序性能。固然，在過去20年中，應用程序性能幾乎是全部基礎架構/平臺管理系統中的一個大漏洞。這就是存在應用程序性能管理（APM）行業的緣由：由於J2EE中間件平臺對生產應用程序的可見性爲零。

嘗試在沒有應用程序性能信息的狀況下管理應用程序基礎結構，就像在不瞭解颶風是出如今非洲仍是歐洲的狀況下評估風的平均風速。

隨着時間的流逝，通過調整的平臺和新的APM工具應運而生，以應對下一代應用程序技術以及每種應用程序提出的獨特可見性挑戰。

容器沒有什麼不一樣，由於即便是新的APM供應商，流行工具也沒法從那些老舊的容器中執行其監控功能。

而後，咱們進行了編排，在他們之上又放了一層！

所以，第一和第二問題並存。由於在沒有應用程序性能信息的狀況下，精心設計的應用程序環境可能會陷入困境，僅僅是由於它沒有更好的瞭解。那時，丟失的數據讓剩餘的數據也成爲垃圾。

結果是，在您的客戶/最終用戶受到服務影響的同時，全部指示燈都呈綠色點亮，這在IT操做中很是常見。

開發人員對他們的應用程序進行檢測以使其可觀察，使用自動插入監視以提供可見性的工具。

重要的是，您瞭解了應用程序性能，或更具體地說，是經過應用程序向用戶提供的服務的性能，但須要確保您有一種方法來獲取性能信息和業務流程信息並將它們結合起來（從數據管理的角度來看，它們是相互關聯的），以便您能夠根據服務水平制定業務流程決策，並且能夠看到什麼時候不提供應用程序，即便業務流程引擎認爲一切正常。

隨着應用程序平臺和技術的不斷髮展，肯定如何得到性能可見性的艱鉅任務是艱鉅的。像之前同樣-首先使用J2EE，而後使用SOA，如今使用微服務工具和解決方案應運而生，以幫助查看內部應用程序並解決問題。

不管您是要弄清楚如何協調1，000個容器，仍是要了解環境中的25種無服務器功能是如何執行的，或者只是瞭解整個應用程序如何爲用戶提供服務，均可以找到解決方案。