前言
本文主要講4個部分：
- 關(guān)于容器技術(shù)赃份；
- 難以駕馭的K8s稿茉；
- K8s是所有人的良藥嗎？
- 我的團隊該如何上K8s芥炭？
一. 關(guān)于容器技術(shù)
你是否聽說過容器技術(shù)（以docker和Kubernetes為代表）？ 容器技術(shù)呱呱墜地到如今恃慧，在國內(nèi)經(jīng)歷了如下3個階段：
- 嬰兒期：2014-2016年的技術(shù)探索期园蝠；
- 少兒期：2017-2018年的行業(yè)試水期；
- 少年期：2019年以后的
痢士。
容器技術(shù)作為技術(shù)圈兒中的香餑餑彪薛，如果你還沒有聽說過，建議你立刻了解一下怠蹂，以免跟不上當(dāng)今的技術(shù)潮流善延。
容器技術(shù)帶來的價值，通過它的廣泛使用已經(jīng)不言而喻城侧，因此不再多費文字闡述易遣。這里直接向大家大致介紹容器技術(shù)的現(xiàn)狀和趨勢。
-
Kubernetes(K8s)已成為容器技術(shù)的事實標(biāo)準(zhǔn)
1.png
-
大量企業(yè)已經(jīng)在使用或者計劃使用容器云
2.png
-
K8s從CO走向OS
K8s一直以來被當(dāng)做容器編排工具（Container Operation, CO）嫌佑，而這些年的發(fā)展豆茫，K8s已經(jīng)成了云原生領(lǐng)域事實的操作系統(tǒng)（Operation System, OS）。
3.png
二. 難以駕馭的K8s
K8s功能固然強大屋摇，但同時從K8s目前的定位——操作系統(tǒng)揩魂，就能看出它最大的特征：復(fù)雜！Ｅ谖隆火脉！
復(fù)雜真是萬惡之源！復(fù)雜會帶來一些列衍生問題：
- 上手k8s絕非易事柒啤，用一個高級點的說法倦挂，叫學(xué)習(xí)曲線陡峭。并且容器技術(shù)的更新迭代非嘲仔蓿快妒峦，Kubernetes衍生出的新概念新工具也在蓬勃發(fā)展（有興趣的朋友可以搜索一下“Kubernetes生態(tài)”）。然而更有挑戰(zhàn)性的點在于兵睛，如果想在實際的工作中用上K8s肯骇，不只你一人要學(xué)窥浪，整個研發(fā)團隊都需要學(xué)，包括開發(fā)人員笛丙、測試人員漾脂、運維人員。
- 市場上胚鸯，K8s相關(guān)人才不多骨稿。
- 項目使用K8s的不確定性太高，可能會導(dǎo)致失敗姜钳。
- 項目切換到K8s的成本太大坦冠，導(dǎo)致你的老板可能會叫停這樣的變革。
- 你需要適應(yīng)K8s的工作模式哥桥，軟件研發(fā)本來就是一個復(fù)雜的體系辙浑，包括了很多人使用很多工具分工合作，而使用K8s拟糕，很多工作方式與原來不一樣判呕。下面羅列一下，以供參考送滞。
-
在實際使用中侠草，還有很多非常棘手的問題，比如：
- K8s yaml的配置一部分是開發(fā)關(guān)注的犁嗅，一部分是運維關(guān)注的边涕，如何分工協(xié)作？
- ConfigMap/Secret 不支持版本控制褂微，參數(shù)多時配置起來很麻煩奥吩；
- 集群如何給外部暴露端口？
- 如何做熱更新蕊梧？
- 多K8s集群如何管理霞赫？
- K8s集群本身如何備份和恢復(fù)？
- 如何對K8s集群進行升級而不影響業(yè)務(wù)肥矢？
- K8s集群如何做資源規(guī)劃端衰？
三. K8s是所有人的良藥嗎？
K8s很好甘改，然而用Ta很困難旅东，是不是讓人又愛又恨？怎么辦十艾？
建議你冷靜下來抵代，仔細分析一下更重要的事情——K8s是否適合你、你的項目忘嫉、你的團隊荤牍？
建議考慮如下亮點：
- 你的應(yīng)用是否需要微服務(wù)案腺？微服務(wù)帶來便利的同時，也會給開發(fā)人員帶來巨大負擔(dān)康吵，除了維護多個服務(wù)之外劈榨，可能需要一整套工具來分析解決微服務(wù)的問題。還要考慮分布式的一致性問題晦嵌、服務(wù)通信帶來的性能問題和安全問題等同辣。如果不需要微服務(wù)，大概率也不需要K8s惭载。
- 你的應(yīng)用需要擴展嗎旱函？Kubernetes 的一個關(guān)鍵特性是能對應(yīng)用程序的各個部分進行橫向擴展。流量會自動在各個 Pod 間路由和分配描滔，如果配置完成陡舅，Kubernetes 甚至可以自動為你縮放 Pod 。如果你的應(yīng)用有一個或多個熱點組件需要處理突發(fā)事件伴挚，那這個特性就非常有價值。
如果你的答案是你不需要K8s灾炭，那么恭喜你茎芋，你可以中止閱讀了，你花費了10分鐘不到的時間蜈出，得到了一個有價值的答案田弥。
如果你的答案是：你需要K8s，請繼續(xù)閱讀铡原，也許對你有些許幫助偷厦。我上面列的困難只是戰(zhàn)術(shù)上的困難，是有辦法解決的燕刻。
四. 我的團隊該如何上K8s?
關(guān)于how的問題只泼，有大有小：大如我該如何度過這一生卵洗，小則有我該如何學(xué)習(xí)10以內(nèi)的加法请唱。而團隊該如何上K8s，這就是一個宏大的問題过蹂。一般而言十绑，大問題可以拆分為小問題，逐個求解得到答案酷勺。但如果我把這個問題逐一細細的拆解本橙，恐怕得一本書才能寫完。所以脆诉，我僅從大的方面上嘗試回答一下該問題甚亭。一些具體的小問題贷币，比如我上文表格中的那些工作項，上了K8s該如何做狂鞋，有時間咱們可以再做探討片择，有興趣的讀者也可以給我留言。
言歸正傳骚揍，團隊如何上K8s字管，從大面上，我的答案包含2點信不，二者缺一不可：
1. 漸進式上K8s嘲叔；
2. 人員分工 + 第三方產(chǎn)品解決復(fù)雜性。漸進式上K8s
漸進式上K8s聽上去很簡單抽活，但實施起來不然硫戈，具體來說包括如下幾點：
特定項目。選擇即將要開發(fā)的新項目下硕，簡單一點的項目丁逝，沒有遷移成本。
-
特定完整團隊梭姓。項目的leader需要有新技術(shù)的探索精神霜幼，項目中核心成員也有新技術(shù)的探索精神。關(guān)于特定團隊誉尖，團隊中的研發(fā)人員罪既、測試人員、運維人員都需要從一開始就直接或間接使用K8s铡恕。直接是上原生K8s琢感，間接是指通過第三方平臺上K8s。
筆者曾經(jīng)碰到很多上了K8s的客戶探熔，推進得都無比艱難驹针！除了上述的諸多的難題之外，還有一個最重要的原因——這些客戶上K8s是先從運維部門開始诀艰。這些客戶認為牌捷，正是因為K8s如此復(fù)雜和不確定性高，所以引入第三方的產(chǎn)品或解決方案涡驮，先從一個部門開始使用暗甥，再逐步推廣到研發(fā)部門。而現(xiàn)實是：K8s是涉及研發(fā)捉捅、測試撤防、運維的整體協(xié)作方式變革，引入第三方的產(chǎn)品或解決方案時棒口，要么是研發(fā)測試人員沒有參與寄月，要么是沒有深度參與辜膝，導(dǎo)致在推廣時，第三方的產(chǎn)品或解決方案不被研發(fā)測試人員接受漾肮。
測試環(huán)境厂抖。項目先在測試環(huán)境以K8s方式部署。
取得成功之后克懊，再擴展至生產(chǎn)環(huán)境忱辅、其他項目、其他團隊谭溉。這樣的方式墙懂，有利于團隊積累對K8s的自信心。取得一定的廣度成功的同時扮念，在深度上也可以做一定的探索损搬，比如，使用K8s配套的測試工具柜与、運維工具巧勤，甚至采用一些開源項目的CRD，比如Open Kruise弄匕。甚至編寫自己公司特有的CRD颅悉。
人員分工 + 封裝
人類解決復(fù)雜性有2個非常重要的手段：分工、封裝粘茄。這里就不舉例子了，在IT領(lǐng)域秕脓，這兩個手段的例子俯拾皆是柒瓣。具體到上K8s體現(xiàn)為：
- 人員分工是指不需要整個團隊的人都懂K8s，只需要特定的一兩個人懂K8s吠架，研發(fā)人員芙贫、測試人員只需配合相關(guān)的工作，由這一兩個人來編寫Dockerfile傍药、K8s yaml磺平，也可以由這一兩個人寫好腳本，開發(fā)人員和測試人員直接調(diào)用腳本拐辽，傳遞合適參數(shù)拣挪。
-
封裝。有如5種方式封裝俱诸，第1條是窮人專用菠劝，第5條是土豪專用，第2睁搭、3赶诊、4條是經(jīng)濟適用條款笼平。
- 可以采用腳本或者模板的方式，對開發(fā)人員舔痪、測試人員屏蔽K8s的復(fù)雜性寓调；
- 采用開源的工具來封裝操作復(fù)雜性，提供了Web UI锄码，比如：OKD夺英、Rancher、KubeSphere等巍耗；
- 購買商業(yè)化的容器云產(chǎn)品來封裝操作復(fù)雜性秋麸，公有云或私有云的產(chǎn)品都可以，比如AWS/阿里云/騰訊云/華為云上的容器云產(chǎn)品炬太；
- 購買商業(yè)化的產(chǎn)品來封裝操作復(fù)雜性灸蟆、以及理解復(fù)雜性。市面上亲族，既封裝了操作復(fù)雜性炒考、又封裝了理解復(fù)雜性的產(chǎn)品不多，比如StarOS霎迫、好雨云斋枢，這兩款產(chǎn)品都封裝了K8s的概念，無需懂K8s即可使用知给，但使用體驗不一樣瓤帚，定位不一樣。StarOS定位是一站式云原生開發(fā)平臺涩赢，好雨云定位的是云原生應(yīng)用部署和交付戈次；
- 自己團隊開發(fā)容器云平臺來封裝操作復(fù)雜性、以及理解復(fù)雜性筒扒，土豪適用怯邪。
附注
筆者容器云行業(yè)從業(yè)好幾年，略有心得花墩，聊作分享悬秉。如有疏漏，多謝指正冰蘑，歡迎留言探討和泌。
引用說明
本文大量數(shù)據(jù)來源于《艾瑞咨詢：2020年中國容器云市場研究報告》
