摘要：由于，容器任務被簡化，包括部署操作水平自動伸縮滾動更新金絲雀部署和管理監視資源應用健康檢查調試應用等。支持和培訓當企業準備應用容器化戰略時，管理平臺提供商是否向企業保證的支持以及培訓在所有可用的選擇中，只有少數的一些公司，如支持了這些選項。

作為時下最火熱的熱點詞匯：Kubernetes，其擁有成熟的社區，大公司的背景等等獲得了大部分人的認可，很多公司都在準備啟用Kubernetes，但是你的企業真的準備好了去采用Kubernetes這項技術嗎？ 數人云今天給大家分享的本篇文章將從源頭——容器入手，逐步分析選擇Kubernetes所需要的思考及準備。

容器的使用比例正在迅速增長，開發商熱愛它，企業也以前所未有的熱情去擁抱它。

如果你的IT部門正在尋求一種更快，更簡單的方法去進行應用開發，那么容器技術正好可以滿足需求，但什么是容器呢？它們都會處理哪些問題？Kubernetes是否適用于容器和集群管理空間？為什么要向企業展示實施挑戰？在探索容器和集群管理工具是否適合應用開發需求時，應考慮哪些因素？

以下是每個企業需要了解容器、容器集群管理、Kubernetes的優缺點以及如何從Kubernetes實現中獲得最大利益的一些要點。

當應用開發人員進行測試時，必須確保在從一個計算環境移動到另一個計算環境時能夠可靠得運行，這可能來自于從一個登臺環境到生產環境，或者從一個前期服務器到云中的虛擬機，這產生的問題就是，不同的環境很少是共生的，軟件可能不同，但網絡和安全環境幾乎不可能相同。

容器通過將組成的開發環境所有東西打包成一個包去解決這個問題，這引入了環境一致性的級別，并允許開發人員以相同的方式快速、可靠得部署應用程序，而不管部署環境如何，通過對應用平臺及其依賴關系的容器化，操作系統分布和底層基礎結構的差異被抽象出來了，事實上，使用容器，就可以忘記所有的基礎設施。

模塊化的、可執行的應用包應用，容器包括需要運行一個應用的每個元素——從代碼到設置，這種可移植性使容器成為組織思考多云策略的重要資產。

容器還可以幫主準備適當的DevOps實現及高效、快速交付的目標，使用容器，可以更新和升級且不需要從每次開始的遺留問題，這也多虧了容器，在現有系統中實現新的應用和效率并不像想象的那么難。

最近的一項調查顯示，在過去的12個月里，94%的受訪者曾調研或正在使用比虛擬機更輕，資源更少的容器技術。

Docker現在是主流的容器技術，已經有了成熟的技術棧，強大的開源生態系統，且與任何平臺的高強度兼容性，以及最主要的機遇和運氣。Docker已經遠遠超越了曾經的對手——rkt，OpenVZ和LXC，與底層基礎設施不可變和獨立，讓Docker在開發者機器上運行的方式與在生產環境中是一樣的。

為了有效得實現DevOps方法，在企業級應用開發和有效管理容器技術和平臺，需要合適的工具。

這就是容器集群管理或容器編排解決方案發揮作用的地方，隨著企業將容器的使用擴展到生產中，問題出現在管理哪些容器運行在哪里，如何處理所有的這些容器，以及確保跨宿主的容器之間的簡化通信，這些容器被稱之為“集群”。

容器集群管理工具提供了一個企業框架，用于在大規模上集成和管理容器，并確保在實踐DevOps時保持必要的連續性，基本上，它們可以幫助您定義初始容器部署，同時在后臺處理關鍵的IT功能，如可用性、伸縮性和網絡——所有這些都是Streamlined、標準化和統一的。

根據Gartner最近的一項調查顯示，大約50%的受訪者計劃在2017年年底前實施持續交付和DevOps，以便更快、更頻繁、更可靠得提供服務，Puppet Labs發布的DevOps報告顯示，專注于自動化和DevOps的高性能企業能夠減少它們的交付和變更時間，因為它們提供的服務改變了4440個，并且增加了46倍的服務。這些結果幫助DevOps采用了一種主流的企業IT現象，因此，今天我們在幾乎所有的行業和公司規模上都看到了DevOps的采用。

盡管DevOps的快速采用有許多驅動因素，但在技術方面，容器在提高所有團隊的自動化程度方面發揮了關鍵性作用，由于Linux容器的簡單性、可用性和可移植性，曾經為高度工程關注的組織保留的自動化技術現在已經變得可用了。

容器提供了標準的打包格式和運行時，無論應用是如何架構、配置和在容器內運行，都可以運行任何應用，標準化是一個操作系統、中間件、數據庫和其他組建的長期標準操作環境（SOE）項目的目標，實際上已經變成了今天的容器，因此本文坐著看來，這是DevOps人氣的主要轉折點。

盡管容器可以提供標準化，但容器不能解決的是實現持續交付和DevOps所倡導的其他原則所需的端到端自動化，容器提供堅實的標準地面，然而，自動化的過程應該在它之上，以使更快的服務交付。

Kubernetes是在Googer的15年以上容器經驗中誕生的，作為一個精心策劃的框架，被創建并捐贈給社區，容器的自動化部署和管理基礎設施無論使用如虛擬化服務器的基礎設施，私有云或公有云等，在GitHub上，Kubernetes已經成為了最活躍的開放源碼項目之一，有上千萬的貢獻者和數以百計的供應商。

雖然Kubernetes不提供完整的連續交付自動化，但它提供了比容器提供的堅實基礎更高的起點，在容器中運行容器的許多操作復雜性已經通過編排框架來解決，盡管Kubernetes仍然需要團隊在其上面構建一個端到端的自動化流程，但它確實提供了許多現成的模塊，幫助用戶構建一個定制的自動化流程，以進行持續交付。

對于容器集群管理有多種選擇，然而Kubernetes現在比較火熱，稱為最廣泛的開源解決方案，經過15年的Google研發，以及令人羨慕的開源社區（包括紅帽、Canonical、CoreOS和微軟），Kuberentes的成熟速度比市場上任何其他產品都要快。

Kubernetes為容器集群管理提供了一個很好的選擇，因為它為開發者提供了一種工具，可以快速高效地響應客戶需求，同時減輕云中的運行應用負擔。通過消除與部署和伸縮您的容器應用相關的許多手工任務，以便在從一個環境移動到另一個環境時更可靠得運行應用，例如：可以調度并將任意數量的容器部署到節點集群（在公共、私有或混合云中）。然后Kubernetes扶著管理這些工作負載，讓其執行意愿。

由于Kubernetes，容器任務被簡化，包括部署操作（水平自動伸縮、滾動更新、金絲雀部署）和管理（監視資源、應用健康檢查、調試應用等）。

盡管Kubernetes有很多優勢，但正如之前討論過的，在選擇最好的Kubernetes管理平臺時，其仍然相對難以設置和使用，管理Kubernetes是一個耗時的過程，需要高技能的員工和一個潛在的巨大的貨幣承諾，對于沒有經過培訓的人員來說，Kubernetes似乎可以在數小時或數天內運行，但在生產環境中，需要額外的功能——安全性、高可用性、災難恢復、備份和維護——所有需要讓Kubernetes生產“準備就緒”的一切都是如此。

其結果是，那些應用了Kubernetes的企業很快就意識到，他們無法在不引入技術和昂貴外部資源的情況下交付它。

那么，有什么選擇呢？答案在于Kubernetes的管理工具，為了簡化企業的Kubernetes管理，即使你的系統是剛性的，流行的解決方案包括構造，紅帽的開放移動容器平臺，Rancher，andKublr。

當為企業選擇Kubernetes管理平臺時，有很多事情需要考慮，包括：

產品準備就緒：它是否提供了您需要完全自動化的Kubernetes配置的特性，沒有配置麻煩？是否具有企業級的安全特性？它會自動處理集群中的所有管理任務嗎？它是否為您的應用程序提供高可用性、可伸縮性和自愈性？

未來準備就緒：平臺是否支持多云策略？盡管Kubernetes允許在任何地方運行應用且不需要使它們適應新的托管環境，但要確保Kubernetes管理平臺能夠支持這些功能，以便在將來需要時可以進行配置。

易于管理：是否包含自動化的智能監控和警報？是否消除了分析Kubernetes原始數據的問題，以便對系統狀態、錯誤、事件和告警有一個單一的窗格視圖。

支持和培訓：當企業準備應用容器化戰略時，Kuernetes管理平臺提供商是否向企業保證24X7的支持以及培訓？

在所有可用的選擇中，只有少數的一些公司，如Kublr支持了這些選項。加速和簡化了Kubernetes的建立和管理，提供自愈的自動伸縮解決方案，可以將遺留系統引入到單個引擎的云上，同時可以在后臺無縫得維護、重建或替換它們，模塊之間的動態、靈活性和不匹配的透明性，是一種雙贏。

當思考和計劃Kubernetes企業戰略時，要明確自己在前進道路上的障礙，以及對Kubernetes的挑戰和誤解，找出應當在Kubernetes平臺上尋找什么，花點時間做一個Kubernetes平臺的比較，最后，看看自動化工具如何能夠提供生產準備（最重要的特性）、未來準備、易于管理和支持需要使用Kubernetes。

以上是小數今天分享的文章，給想采用Kubernetes的企業供以參考，希望對大家有所幫助。

原文作者：Kublr Team

原文鏈接：http://www.tuicool.com/articl...