在當今雲端計算領域，“容器技術”已經從三四年前的炒作期正式進入了產業落地期，而Kubernetes作為容器平臺的標準已經得到了廣泛應用。
Kubernetes從2014年6月由Google宣佈開源，到2015年7月釋出第一個正式版本1.0並進入CNCF基金會，再到2018年3月從CNCF基金會正式畢業，版本更替到1.10。短短三年間，Kubernetes含著Google的金鑰匙，頂著Borg的光環迅速成為容器編排領域的標準，是開源歷史上發展最快的專案之一。
截止3月份，Kubernetes專案在總體貢獻方面位於GitHub第9位，作者/問題排在第2位，僅次於Linux專案。從CNCF基金會今年3月份釋出的報告，71％的財富100強企業使用容器，超過50％的財富100強企業使用Kubernetes作為容器業務流程平臺。
企業在思考並實踐落地Kubernetes的過程中，通常需要面對多個問題，比如：
● Kubernetes對我們有什麼好處？能夠解決當前的什麼問題？
● 優先在哪些業務場景、流程環節使用Kubernetes？
● 現有基礎設施能否平滑切換到Kubernetes？
● 現有基礎設施上託管的業務能否平滑切換到Kubernetes？
● 企業人員（開發、測試、運維、設計等）能否快速適應Kubernetes？是否會帶來較大的轉型挑戰？
…………
如果我們對這些疑問進行歸類，可以聚焦到以下三個基礎問題上來。
需不需要Kubernetes？
01
Kubernetes是一個“容器編排平臺”，即：容器化業務的管理平臺。因此，需不需要Kubernetes通常與業務需不需要做容器化改造在一起考慮。與基於“伺服器+Linux+軟體包”的傳統非容器化業務相比，核心差異點主要有兩處：
● 業務交付件是容器化交付件；
● 業務執行時環境是容器化執行時；
而需不需要Kubernetes完全取決於這兩點是否能夠帶來收益。下表簡單描述了一些關鍵收益，以及同時引入的問題。
Kubernetes是一個“容器編排平臺”，即：容器化業務的管理平臺。因此，需不需要Kubernetes通常與業務需不需要做容器化改造在一起考慮。與基於“伺服器+Linux+軟體包”的傳統非容器化業務相比，核心差異點主要有兩處：
● 業務交付件是容器化交付件；
● 業務執行時環境是容器化執行時；
而需不需要Kubernetes完全取決於這兩點是否能夠帶來收益。下表簡單描述了一些關鍵收益，以及同時引入的問題。
收益
問題
容器化交付件
● 環境一致性保障
● 交付簡單
● 交付件對傳輸與儲存有更高要求
● 引入新的映象構建過程
容器化執行時
● 更細粒度資源切分
● 程式級資源SLA保障
● 秒級啟動與擴容
● 業務密度高，運維難度增加
● 網路、儲存的處理複雜度提升
從企業的角度來看，容器化改造對於關鍵的業務交付效率、基礎設施資源利用率普遍會帶來很好的收益，尤其是對交付效率和資源成本更為關注的輕資產型業務，這也是為何容器技術得到廣泛關注與應用的主要原因。而相對而言容器化改造所帶來的問題則可以通過引入一些工具與服務進行解決，比如自動化映象構建工具、具有高速傳輸與高容量儲存能力的映象倉庫、容器化環境與業務的監控運維工具、高效能與配置自動化的容器網路與儲存管理服務等。
如何切換到Kubernetes？
02
一旦確定要使用Kubernetes，那對於企業業務而言，就需要考慮業務研發流程、基礎設施資源如何切換到Kubernetes。這裡，通常可以分為三個場景考慮：
● 業務交付流程如何切換到Kubernetes
● 業務運維流程如何切換到Kubernetes
● 業務執行負載如何遷移到Kubernetes
下表描述了典型的處理方式：
典型處理方式
交付流程切換
① 搭建容器映象倉庫，用於儲存容器化交付件
②容器化改造，軟體包改造成Docker Image
③編寫新的容器化版本釋出包，包括執行在K8S上所需的描述檔案
④改造開發、測試、生產環境，改為容器化基礎設施（K8S叢集）
⑤修改CI/CD系統，對接到容器化測試、生產環境
⑥（可選）修改現有交付流程管理工具或平臺，適應新的容器化交付流程
運維流程切換
① 部署用於收集容器化基礎設施（K8S叢集）的監控、日誌、告警等資訊的運維繫統，並對接到運維中心
②部署用於收集容器化業務的監控、日誌、告警等資訊的運維繫統，並對接到運維中心
執行負載遷移
①準備新的容器化基礎設施（K8S叢集）
②部署新的容器化版本，業務邏輯測試通過
③準備灰度釋出環境，通過A/B testing或藍綠等釋出方式完成新舊版本執行時負載遷移
④非容器化的舊版本下線，完成遷移
在上述過程中可以看到，在企業落地Kubernetes過程中，除了Kubernetes平臺本身的搭建，圍繞著Kubernetes生態的一些工具與服務也非常重要，包括面向容器化業務的CI/CD工具鏈、容器化環境與業務的監控運維、應用釋出與交付工具等。在不具備相關容器化平臺完整能力的情況下，落地Kubernetes並不能夠達成提升業務交付效率的目的。
如何適應Kubernetes？
03
完成面向容器的交付、運維與遷移流程改造只是做好了實踐Kubernetes的基礎條件準備工作，對企業而言最重要的還是業務如何在新的平臺之上運轉的更高效、更可靠、更安全。“容器”相比於傳統基礎設施而言，更適合作為當前企業的新一代應用設施的原因主要包括三點：
● “容器”將應用與基礎設施緊密的聯絡在了一起，改變了傳統的應用與設施管理相分離的思維與運作模式，而這一點恰恰與DevOps理念是完美契合的。
● “容器”帶來了更高的彈性，表現在更精細的資源分配與排程、更快速的彈性擴縮容，以及對底層資源更高的抽象，更適合以“彈性”為核心理念的雲端計算。
● “容器”是應用微服務理念的最佳實踐。微服務化架構更多是從應用開發角度來思考，而容器更偏向於應用釋出與運維，這兩者的結合真正能打通應用交付全流程。
上述三點在Kubernetes均得到完整的體現。Kubernetes通過CNI、CSI、Device Plugin等外掛與網路、儲存、GPU等基礎設施資源整合在一起，通過上層統一的排程系統完成面向應用的實時、彈性資源分配，並且通過Autoscaler能夠完成基於策略的自動擴縮容；而Service、Workload、ConfigMap等物件以及DNS、Ingress/Service controller等系統級元件原生支援了服務發現、配置、路由、負載均衡等微服務模型及框架能力，並且通過Kubernetes生態中的Istio專案能夠提供更為完整的ServiceMesh微服務治理能力。
因此，企業業務如何適應Kubernetes的過程，也同時是如何落地DevOps、微服務、彈性基礎設施理念的過程。這裡面，不僅僅包含如何做業務的改造來適應容器化執行環境與容器化交付流程，更多的應該是思考如何更好地基於Kubernetes的各種最佳實踐來優化業務本身，設計更適合的業務架構，優化業務交付流程中各個環節，做到更好的Cloud-Native與Kubernetes-Native。
華為雲幫助企業落地Kubernetes
04
作為Kubernetes 最早的採用者之一，華為自2013年起在內部多個產品落地Kubernetes，在這個過程中，圍繞著本文上述的三個基本性問題，以及規模化生產環境落地場景，華為發現並解決了一些功能缺失、系統級高可用、可擴充套件性挑戰等問題，並積極回饋給了Kubernetes社群。基於這些場景的落地經驗，以及廣泛的社群核心特性貢獻，華為也順利成為Kubernetes社群技術監管委員會成員，以及CNCF基金會TOC成員。
一方面基於內部實踐的思考，另一方面基於外部各類客戶場景的落地經驗總結，華為雲圍繞著上述三個基礎問題，面向企業使用者提供了全棧Kubernetes服務，以期能夠幫助企業快速落地Kubernetes，助力企業Cloud-Native戰略實施。
華為雲提供的Kubernetes全棧服務主要包括：
容器化基礎設施
華為雲提供了通過CNCF官方認證的兩種Kubernetes服務供使用者選擇，包括雲容器引擎（CCE）與雲容器例項（CCI）。CCE是使用者專屬Kubernetes服務，使用者可以控制整個Kubernetes叢集，同時管理基礎設施資源與執行在Kubernetes上的容器化業務；而CCI是Serverless Kubernetes服務，使用者只需要管理執行在Kubernetes上的容器化業務，無需感知Kubernetes叢集，而交由華為雲自動管理，進一步降低Kubernetes落地門檻。
容器化交付流程
華為雲容器映象服務（SWR）提供了高效能、高容量、高安全的企業級私有映象倉庫，並提供了映象構建與釋出流水線ContainerOps支援業務自動化交付，同時，ContainerOps能夠支援企業現有工具的接入，最大程度減小對現有企業交付流程的衝擊，輔助企業業務平滑遷移。
華為雲應用編排服務（AOS）提供了自動化雲設施管理工具，企業可以通過預置的模板自動化完成容器化的開發、測試、生產環境準備，以及日常配置與變更工作，將企業從繁雜的基礎設施管理工作中解放出來，聚焦到業務本身。對於業務較複雜的場景，AOS還能夠將Kubernetes上執行的各種工作負載、各類資源物件進行整合管理，並提供完善的版本與生命週期管理機制，便於企業以更完整的業務為物件進行日常管理。
容器化運維流程
華為雲提供了應用運維管理（AOM）與應用效能管理（APM）服務輔助容器化業務運維，包括豐富的各類運維工具，除了基礎的監控、日誌與告警，進一步面向故障定位與分析場景提供了應用全域性效能拓撲展示與呼叫鏈跟蹤等高階特性，使得運維人員能夠及時瞭解應用健康狀態並進行相關處理。
容器化架構轉型
華為云云容器引擎（CCE）與微服務引擎（CSE）提供了Kubernetes生態的Istio以及Apache ServiceComb兩種微服務框架供企業實施微服務架構轉型。對於Java企業級應用，CSE基於ServiceComb提供了具備升降級、容錯、熔斷等完整服務治理能力的微服務框架，併相容Spring Cloud、Dubbo等開源介面，具備更高的服務吞吐效能；而CCE也原生整合了Istio專案，並提供高效能ServiceMesh資料面，面向非侵入式場景提供Kubernetes-Native的微服務治理能力。
隨著Kubernetes的全面成熟與大規模應用，如何落地Kubernetes是企業實施雲戰略需要考慮的迫切問題。
落地Kubernetes除了對Kubernetes平臺自身的熟悉與掌握之外，如何對現有業務及基礎設施進行容器化改造、如何應對Kubernetes對業務現有交付與運維流程的衝擊、如何深入思考容器與Kubernetes給企業所帶來的轉型化思考都是需要一併考慮的問題。
引入圍繞著Kubernetes的各類工具化服務能夠讓企業快速獲取業界最佳實踐，平滑遷移現有軟硬體資產，減小對現有業務交付與運維流程的衝擊，使得企業平穩落地Kubernetes併合理優化現有業務，最終達成提升業務交付效率、簡化基礎設施管理的目的。