導語

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種無服務器功能是如何執行的，或者只是了解整個應用程序如何為用戶提供服務，都可以找到解決方案。

總結

以上是生活随笔為你收集整理的Kubernetes是容器化微服务的圣杯么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。