前言

本文主要講4個部分：

1. 關於容器技術；
2. 難以駕馭的K8s；
3. K8s是所有人的良藥嗎？
4. 我的團隊該如何上K8s？

一. 關於容器技術

你是否聽說過容器技術（以docker和Kubernetes為代表）？ 容器技術呱呱墜地到如今，在國內經歷瞭如下3個階段：

• 嬰兒期：2014-2016年的技術探索期；
• 少兒期：2017-2018年的行業試水期；
• 少年期：2019年以後的$\color{red} {規模應用期} $。

容器技術作為技術圈兒中的香餑餑，如果你還沒有聽說過，建議你立刻了解一下，以免跟不上當今的技術潮流。

容器技術帶來的價值，通過它的廣泛使用已經不言而喻，因此不再多費文字闡述。這裡直接向大家大致介紹容器技術的現狀和趨勢。

• Kubernetes(K8s)已成為容器技術的事實標準
  

• 大量企業已經在使用或者計劃使用容器雲
  

• K8s從CO走向OS
  K8s一直以來被當做容器編排工具（Container Operation, CO），而這些年的發展，K8s已經成了雲原生領域事實的作業系統（Operation System, OS）。
  

二. 難以駕馭的K8s

K8s功能固然強大，但同時從K8s目前的定位——作業系統，就能看出它最大的特徵：複雜！！！

複雜真是萬惡之源！複雜會帶來一些列衍生問題：

1. 上手k8s絕非易事，用一個高階點的說法，叫學習曲線陡峭。並且容器技術的更新迭代非常快，Kubernetes衍生出的新概念新工具也在蓬勃發展（有興趣的朋友可以搜尋一下“Kubernetes生態”）。然而更有挑戰性的點在於，如果想在實際的工作中用上K8s，不只你一人要學，整個研發團隊都需要學
   ，包括開發人員、測試人員、運維人員。
2. 市場上，K8s相關人才不多。
3. 專案使用K8s的不確定性太高，可能會導致失敗。
4. 專案切換到K8s的成本太大，導致你的老闆可能會叫停這樣的變革。
5. 你需要適應K8s的工作模式，軟體研發本來就是一個複雜的體系，包括了很多人使用很多工具分工合作，而使用K8s，很多工作方式與原來不一樣。下面羅列一下，以供參考。

6. 在實際使用中，還有很多非常棘手的問題，比如：

   • K8s yaml的配置一部分是開發關注的，一部分是運維關注的，如何分工協作？
     - ConfigMap/Secret 不支援版本控制，引數多時配置起來很麻煩；
     - 叢集如何給外部暴露埠？
     - 如何做熱更新？
     - 多K8s叢集如何管理？
     - K8s叢集本身如何備份和恢復？
     - 如何對K8s叢集進行升級而不影響業務？
     - K8s叢集如何做資源規劃？

   三. K8s是所有人的良藥嗎？

   K8s很好，然而用Ta很困難，是不是讓人又愛又恨？怎麼辦？

   建議你冷靜下來，仔細分析一下更重要的事情——K8s是否適合你、你的專案、你的團隊？

   建議考慮如下亮點：

   • 你的應用是否需要微服務？微服務帶來便利的同時，也會給開發人員帶來巨大負擔，除了維護多個服務之外，可能需要一整套工具來分析解決微服務的問題。還要考慮分散式的一致性問題、服務通訊帶來的效能問題和安全問題等。如果不需要微服務，大概率也不需要K8s。
   • 你的應用需要擴充套件嗎？Kubernetes 的一個關鍵特性是能對應用程式的各個部分進行橫向擴充套件。流量會自動在各個 Pod 間路由和分配，如果配置完成，Kubernetes 甚至可以自動為你縮放 Pod 。如果你的應用有一個或多個熱點元件需要處理突發事件，那這個特性就非常有價值。

   如果你的答案是你不需要K8s，那麼恭喜你，你可以中止閱讀了，你花費了10分鐘不到的時間，得到了一個有價值的答案。

   如果你的答案是：你需要K8s，請繼續閱讀，也許對你有些許幫助。我上面列的困難只是戰術上的困難，是有辦法解決的。

   四. 我的團隊該如何上K8s?

   關於how的問題，有大有小：大如我該如何度過這一生，小則有我該如何學習10以內的加法。而團隊該如何上K8s，這就是一個巨集大的問題。一般而言，大問題可以拆分為小問題，逐個求解得到答案。但如果我把這個問題逐一細細的拆解，恐怕得一本書才能寫完。所以，我僅從大的方面上嘗試回答一下該問題。一些具體的小問題，比如我上文表格中的那些工作項，上了K8s該如何做，有時間咱們可以再做探討，有興趣的讀者也可以給我留言。

   言歸正傳，團隊如何上K8s，從大面上，我的答案包含2點，二者缺一不可：

   1. 漸進式上K8s；
   2. 人員分工 + 第三方產品解決複雜性。

   漸進式上K8s

   漸進式上K8s聽上去很簡單，但實施起來不然，具體來說包括如下幾點：

   • 特定專案。選擇即將要開發的新專案，簡單一點的專案，沒有遷移成本。

   • 特定完整團隊。專案的leader需要有新技術的探索精神，專案中核心成員也有新技術的探索精神。關於特定團隊，團隊中的研發人員、測試人員、運維人員都需要從一開始就直接或間接使用K8s。直接是上原生K8s，間接是指通過第三方平臺上K8s。

     筆者曾經碰到很多上了K8s的客戶，推進得都無比艱難！除了上述的諸多的難題之外，還有一個最重要的原因——這些客戶上K8s是先從運維部門開始。這些客戶認為，正是因為K8s如此複雜和不確定性高，所以引入第三方的產品或解決方案，先從一個部門開始使用，再逐步推廣到研發部門。而現實是：K8s是涉及研發、測試、運維的整體協作方式變革，引入第三方的產品或解決方案時，要麼是研發測試人員沒有參與，要麼是沒有深度參與，導致在推廣時，第三方的產品或解決方案不被研發測試人員接受。

   • 測試環境。專案先在測試環境以K8s方式部署。

   取得成功之後，再擴充套件至生產環境、其他專案、其他團隊。這樣的方式，有利於團隊積累對K8s的自信心。取得一定的廣度成功的同時，在深度上也可以做一定的探索，比如，使用K8s配套的測試工具、運維工具，甚至採用一些開源專案的CRD，比如Open Kruise。甚至編寫自己公司特有的CRD。

   人員分工 + 封裝

   人類解決複雜性有2個非常重要的手段：分工、封裝。這裡就不舉例子了，在IT領域，這兩個手段的例子俯拾皆是。具體到上K8s體現為：

   • 人員分工是指不需要整個團隊的人都懂K8s，只需要特定的一兩個人懂K8s，研發人員、測試人員只需配合相關的工作，由這一兩個人來編寫Dockerfile、K8s yaml，也可以由這一兩個人寫好指令碼，開發人員和測試人員直接呼叫指令碼，傳遞合適引數。
   • 封裝。有如5種方式封裝，第1條是窮人專用，第5條是土豪專用，第2、3、4條是經濟適用條款。
     • 可以採用指令碼或者模板的方式，對開發人員、測試人員遮蔽K8s的複雜性；
     • 採用開源的工具來封裝操作複雜性，提供了Web UI，比如：OKD、Rancher、KubeSphere等；
     • 購買商業化的容器雲產品來封裝操作複雜性，公有云或私有云的產品都可以，比如AWS/阿里雲/騰訊雲/華為雲上的容器雲產品；
     • 購買商業化的產品來封裝操作複雜性、以及理解複雜性。市面上，既封裝了操作複雜性、又封裝了理解複雜性的產品不多，比如StarOS，這款產品封裝了K8s的概念，無需懂K8s即可使用。；
     • 自己團隊開發容器雲平臺來封裝操作複雜性、以及理解複雜性，土豪適用。

   附註

   筆者容器雲行業從業好幾年，略有心得，聊作分享。如有疏漏，多謝指正，歡迎留言探討。

   引用說明

   本文大量資料來源於《艾瑞諮詢：2020年中國容器雲市場研究報告》