在當今雲計算領域，“容器技術”已經從三四年前的炒作期正式進入了產業落地期，而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併合理優化現有業務，最終達成提升業務交付效率、簡化基礎設施管理的目的。