這兩年，Kubernetes擊敗了Swarm和Mesos，幾乎成為容器編排的事實(shí)標(biāo)準(zhǔn)，BAT、滴滴、京東、頭條等大廠，都爭相把容器和K8S項(xiàng)目作為技術(shù)重心。
為什么在眾多容器平臺(tái)中，Kubernetes能夠脫穎而出，是因?yàn)镵ubernetes的接口和概念設(shè)計(jì)是完全站在應(yīng)用角度而非運(yùn)維角度的。
如果站在傳統(tǒng)運(yùn)維人員的角度看Kubernetes，會(huì)覺得他是個(gè)奇葩所在，容器還沒創(chuàng)建出來，概念先來一大堆，文檔先讀一大把，編排文件也復(fù)雜，組件也多，讓很多人望而卻步。
但是如果開發(fā)人員的角度，尤其是從微服務(wù)應(yīng)用的架構(gòu)的角度來看Kubernetes，則會(huì)發(fā)現(xiàn)，他對(duì)于微服務(wù)的運(yùn)行生命周期和相應(yīng)的資源管控，做了非常好的抽象。
如圖中所示，和虛擬機(jī)運(yùn)行傳統(tǒng)應(yīng)用，只需要?jiǎng)?chuàng)建出資源來，并且保證網(wǎng)絡(luò)暢通即可的方式不同，微服務(wù)的運(yùn)行，需要完成左面的一系列工具鏈。
為什么要使用這些工具鏈，以及如何使用這些工具鏈，請參考我的另外兩篇文章以業(yè)務(wù)為核心的云原生體系建設(shè)和從1到2000個(gè)微服務(wù)，史上最落地的實(shí)踐云原生25個(gè)步驟。
你會(huì)發(fā)現(xiàn)，Kubernetes都有相應(yīng)的工具鏈可以匹配。
微服務(wù)設(shè)計(jì)重要的一點(diǎn)就是區(qū)分無狀態(tài)和有狀態(tài)，在K8S中，無狀態(tài)對(duì)應(yīng)deployment，有狀態(tài)對(duì)應(yīng)StatefulSet。
deployment主要通過副本數(shù)，解決橫向擴(kuò)展的問題。
而StatefulSet通過一致的網(wǎng)絡(luò)ID，一致的存儲(chǔ)，順序的升級(jí)，擴(kuò)展，回滾等機(jī)制，保證有狀態(tài)應(yīng)用，很好地利用自己的高可用機(jī)制。因?yàn)榇蠖鄶?shù)集群的高可用機(jī)制，都是可以容忍一個(gè)節(jié)點(diǎn)暫時(shí)掛掉的，但是不能容忍大多數(shù)節(jié)點(diǎn)同時(shí)掛掉。而且高可用機(jī)制雖然可以保證一個(gè)節(jié)點(diǎn)掛掉后回來，有一定的修復(fù)機(jī)制，但是需要知道剛才掛掉的到底是哪個(gè)節(jié)點(diǎn)，StatefulSet的機(jī)制可以讓容器里面的腳本有足夠的信息，處理這些情況，實(shí)現(xiàn)哪怕是有狀態(tài)，也能盡快修復(fù)。
微服務(wù)少不了服務(wù)發(fā)現(xiàn)，除了應(yīng)用層可以使用SpringCloud或者Dubbo進(jìn)行服務(wù)發(fā)現(xiàn)，在容器平臺(tái)層當(dāng)然是用Service了，可以實(shí)現(xiàn)負(fù)載均衡，自修復(fù)，自動(dòng)關(guān)聯(lián)。
服務(wù)編排，本來K8S就是編排的標(biāo)準(zhǔn)，可以將yml文件放到代碼倉庫中進(jìn)行管理，而通過deployment的副本數(shù)，可以實(shí)現(xiàn)彈性伸縮。
對(duì)于配置中心，K8S提供了configMap，可以在容器啟動(dòng)的時(shí)候，將配置注入到環(huán)境變量或者Volume里面。但是唯一的缺點(diǎn)是，注入到環(huán)境變量中的配置不能動(dòng)態(tài)改變了，好在Volume里面的可以，只要容器中的進(jìn)程有reload機(jī)制，就可以實(shí)現(xiàn)配置的動(dòng)態(tài)下發(fā)了。
統(tǒng)一日志中心，監(jiān)控中心，APM往往需要在Node上部署Agent，來對(duì)日志和指標(biāo)進(jìn)行收集，當(dāng)然每個(gè)Node上都有，daemonset的設(shè)計(jì)，使得更容易實(shí)現(xiàn)。
Kubernetes本身能力比較弱的就是服務(wù)的治理能力，這一點(diǎn)Service Mesh，可以實(shí)現(xiàn)更加精細(xì)化的服務(wù)治理，進(jìn)行熔斷，路由，降級(jí)等策略。Service Mesh的實(shí)現(xiàn)往往通過sidecar的方式，攔截服務(wù)的流量，進(jìn)行治理。這也得力于Pod的理念，一個(gè)Pod可以有多個(gè)容器，如果當(dāng)初的設(shè)計(jì)沒有Pod，直接啟動(dòng)的就是容器，會(huì)非常的不方便。
所以，掌握容器技術(shù)成為很多公司招聘時(shí)的重要選項(xiàng)。
這兩年，跟朋友探討K8S落地時(shí)，也有一些問題被反復(fù)提及，比如：
為什么容器里只能跑“一個(gè)進(jìn)程”？
之前一直用的某個(gè)JVM參數(shù)，在容器里怎么不好使了？
為什么Kubernetes不能固定IP地址？容器網(wǎng)絡(luò)連不通，該如何Debug？
K8S中StatefulSet和Operator到底什么區(qū)別？PV和PVC又該怎么用？
這些問題的答案和原理并不復(fù)雜，但很難一兩句話解釋清楚。因?yàn)槿萜骷夹g(shù)涉及操作系統(tǒng)、網(wǎng)絡(luò)、存儲(chǔ)、調(diào)度、分布式原理等方方面面的知識(shí)，是個(gè)名副其實(shí)的全棧技術(shù)。
而其技術(shù)體系里那些“牽一發(fā)而動(dòng)全身”的主線，比如Linux進(jìn)程模型對(duì)容器本身的重要意義，“控制器”模式對(duì)整個(gè)K8S項(xiàng)目提綱挈領(lǐng)的作用等等，不會(huì)詳細(xì)展現(xiàn)在Docker或Kubernetes官方文檔中，但偏偏就是它們，才是掌握容器技術(shù)體系的精髓所在。
