亚洲一区爱区精品无码-国产欧美日韩第一区在线-色综合久久98天天综合-国产卡一卡二无线乱码-国产免费va在线观看视频-日韩av无码一区二区三区不卡-成在线人免费视频-精品国产一区二区三区麻豆-а天堂中文官网-无码人妻精品一二三区免费

關于容器技術

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

· 嬰兒期：2014-2016年的技術探索期；

· 少兒期：2017-2018年的行業試水期；

· 少年期：2019年以后的規模應用期。

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

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

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

2、大量企業已經在使用或者計劃使用容器云。

3、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，很多工作方式與原來不一樣。

下面羅列一下，以供參考。

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

· K8s yaml的配置一部分是開發關注的，一部分是運維關注的，如何分工協作？

· ConfigMap/Secret 不支持版本控制，參數多時配置起來很麻煩；

· 集群如何給外部暴露端口？

· 如何做熱更新？

· 多K8s集群如何管理？

· K8s集群本身如何備份和恢復？

· 如何對K8s集群進行升級而不影響業務？

· K8s集群如何做資源規劃？

我的團隊該如何上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，也可以由這一兩個人寫好腳本，開發人員和測試人員直接調用腳本，傳遞合適參數。

什么樣的云原生產品能解決復雜性：

答案是以應用為中心的云原生產品。什么是以應用為中心？從企業上云的過程來看，企業上云越來越關注上層，越來越趨向應用，越來越不關心資源。

從某個角度上說，容器仍然是資源。當前企業上云，說的其實都是上容器。未來能否再往上走，企業不用運維容器，也完全不用管資源呢？

完全可以！

把上面圖的右半部分變一下形，如下圖所示。

企業都是在應用云上進行應用的全生命周期管理，不用再看到阿里云、騰訊云、AWS、企業私有云的細節，也不用運維云資源，這些云服務廠商只是提供了在世界各地不同的服務規格的云資源。企業只需要在應用云上把應用交付到不同云服務。這樣，就徹底做到了以應用為中心，應用開發人員、測試人員、運維人員需要關注的是應用，是業務，再也不用關注容器，自然就不用理會容器的復雜度。個人認為，這是云原生的終態。這就是我們產品CloudOS的理念，也是我們的實踐。

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

引用說明：本文大量數據來源于《艾瑞咨詢：2020年中國容器云市場研究報告》