本篇文章轉自網易雲架構師劉超的個人公衆号，劉超的通俗雲計算。
最近總在思考，為什麼在支撐容器平台和微服務的競争中，Kubernetes 會取得最終的勝出，事實上從很多角度出發三大容器平台從功能方面來看，最後簡直是一摸一樣。
經過一段時間的思索，以及采訪了從早期就開始實踐 Kubernetes 的網易雲架構師們後，我把反思所得總結為今天的這篇文章。
- 一、從企業上雲的三大架構看容器平台的三種視角
- 二、Kubernetes 才是微服務和 DevOps 的橋梁
- 三、微服務化的十個設計要點
- 四、Kubernetes 本身就是微服務架構
- 五、Kubernetes 更加适合微服務和 DevOps 的設計
- 六、Kubernetes 常見的使用方式
一、從企業上雲的三大架構看容器平台的三種視角
一切都從企業上雲的三大架構開始看起
如圖所示，企業上雲的三大架構為 IT 架構、應用架構和資料架構，在不同的公司，不同的人、不同的角色，關注的重點不同。
對大部分的企業來講，上雲的訴求是從 IT 部門發起的，發起人往往是運維部門，他們關注計算、網絡、存儲，試圖通過雲計算服務來減輕 CAPEX 和 OPEX。
有的公司有 ToC 的業務，因而累積了大量的使用者資料，公司的營運需要通過這部分資料進行大資料分析和數字化營運，因而在這些企業裡面往往還需要關注資料架構。
從事網際網路應用的企業，往往首先關注的是應用架構，是否能夠滿足終端客戶的需求，帶給客戶良好的使用者體驗。業務量上往往會有短期内出現爆炸式增長的現象，因而關注高并發應用架構，并希望這個架構可以快速疊代，進而搶占風口。
在容器出現之前，這三種架構往往通過虛拟機雲平台的方式解決。當容器出現之後，容器的各種良好的特性讓人眼前一亮，它的輕量級、封裝、标準、易遷移、易傳遞的特性，使得容器技術迅速被廣泛使用。
然而一千個人心中有一千個哈姆雷特，由于原來工作的關系，三類角色分别從自身的角度看到了容器的優勢給自己帶來的便捷。
對于原來在機房裡管計算、網絡、存儲的 IT 運維工程師來講，容器更像是一種輕量級的運維模式，在他們看來，容器和虛拟機的最大的差別就是輕量級，啟動速度快，他們往往更願意推出虛拟機模式的容器。
對于資料架構來講，他們每天都在執行各種各樣的資料計算任務，容器相對于原來的 JVM，是一種隔離性較好，資源使用率高的任務執行模式。
從應用架構的角度出發，容器是微服務的傳遞形式，容器不僅僅是做部署的，而且是做傳遞的，CI/CD 中的 D 的。
是以這三種視角的人，在使用容器和選擇容器平台時方法會不一樣。
二、Kubernetes 才是微服務和 DevOps 的橋梁
Swarm：IT 運維工程師
從 IT 運維工程師的角度來看：容器主要是輕量級、啟動快，并且自動重新開機，自動關聯，彈性伸縮的技術，使得 IT 運維工程師似乎不用再加班。
Swarm 的設計顯然更加符合傳統 IT 工程師的管理模式。
他們希望能夠清晰地看到容器在不同機器的分布和狀态，可以根據需要很友善地 SSH 到一個容器裡面去檢視情況。
容器最好能夠原地重新開機，而非随機排程一個新的容器，這樣原來在容器裡面安裝的一切都是有的。
可以很友善地将某個運作的容器打一個鏡像，而非從 Dockerfile 開始，這樣以後啟動就可以複用在這個容器裡面手動做的 100 項工作。
容器平台的內建性要好，用這個平台本來是為了簡化運維的，如果容器平台本身就很複雜，像 Kubernetes 這種本身就這麼多程序，還需要考慮它的高可用和運維成本，這個不劃算，一點都沒有比原來省事，而且成本還提高了。
最好薄薄的一層，像一個雲管理平台一樣，隻不過更加友善做跨雲管理，畢竟容器鏡像很容易跨雲遷移。
Swarm 的使用方式比較讓 IT 工程師有熟悉的味道，其實 OpenStack 所做的事情它都能做，速度還快。
Swarm 的問題
然而容器作為輕量級虛拟機，暴露出去給客戶使用，無論是外部客戶，還是公司内的開發，而非 IT 人員自己使用的時候，他們以為和虛拟機一樣，但是發現了不一樣的部分，就會有很多的抱怨。
例如自修複功能，重新開機之後，原來 SSH 進去手動安裝的軟體不見了，甚至放在硬碟上的檔案也不見了，而且應用沒有放在 Entrypoint 裡面自動啟動，自修複之後程序沒有跑起來，還需要手動進去啟動程序，客戶會抱怨你這個自修複功能有啥用？
例如有的使用者會 ps 一下，發現有個程序他不認識，于是直接 kill 掉了，結果是 Entrypoint 的程序，整個容器直接就挂了，客戶抱怨你們的容器太不穩定，老是挂。
容器自動排程的時候，IP 是不保持的，是以往往重新開機後原來的 IP 就沒了，很多使用者會提需求，這個能不能保持啊，原來配置檔案裡面都配置的這個 IP ，挂了重新開機就變了，這個怎麼用啊，還不如用虛拟機，至少沒那麼容易挂。
容器的系統盤，也即作業系統的那個盤往往大小是固定的，雖然前期可以配置，後期很難改變，而且沒辦法每個使用者可以選擇系統盤的大小。有的使用者會抱怨，我們原來本來就很多東西直接放在系統盤的，這個都不能調整，叫什麼雲計算的彈性啊。
如果給客戶說容器挂載資料盤，容器都啟動起來了，有的客戶想像雲主機一樣，再挂載一個盤，容器比較難做到，也會被客戶罵。
如果容器的使用者不知道他們在用容器，當虛拟機來用，他們會覺得很難用，這個平台一點都不好。
Swarm 上手雖然相對比較容易，但是當出現問題的時候，作為運維容器平台的人，會發現問題比較難解決。
Swarm 内置的功能太多，都耦合在了一起，一旦出現錯誤，不容易 debug。如果目前的功能不能滿足需求，很難定制化。很多功能都是耦合在 Manager 裡面的，對 Manager 的操作和重新開機影響面太大。
Mesos：資料運維工程師
從大資料平台運維的角度來講，如何更快地排程大資料處理任務，在有限的時間和空間裡面，更快地跑更多的任務，是一個非常重要的要素。
是以當我們評估大資料平台牛不牛的時候，往往以機關時間内跑的任務數目以及能夠處理的資料量來衡量。
從資料運維的角度來講，Mesos 是一個很好的排程器。既然能夠跑任務，也就能夠跑容器，Spark 和 Mesos 天然的內建，有了容器之後，可以用更加細粒度的任務執行方式。
在沒有細粒度的任務排程之前，任務的執行過程是這樣的。任務的執行需要 Master 的節點來管理整個任務的執行過程，需要 Worker 節點來執行一個個子任務。在整個總任務的一開始，就配置設定好 Master 和所有的 Work 所占用的資源，将環境配置好，等在那裡執行子任務，沒有子任務執行的時候，這個環境的資源都是預留在那裡的，顯然不是每個 Work 總是全部跑滿的，存在很多的資源浪費。
在細粒度的模式下，在整個總任務開始的時候，隻會為 Master 配置設定好資源，不給 Worker 配置設定任何的資源，當需要執行一個子任務的時候，Master 才臨時向 Mesos 申請資源，環境沒有準備好怎麼辦？好在有 Docker，啟動一個 Docker，環境就都有了，在裡面跑子任務。在沒有任務的時候，所有節點上的資源都是可被其他任務使用的，大大提升了資源利用效率。
這就是 Mesos 最大的優勢，在 Mesos 的論文中，最重要闡述的就是資源使用率的提升，而 Mesos 的雙層排程算法是核心。
原來大資料運維工程師出身的，會比較容易選擇 Mesos 作為容器管理平台。不過原來是跑短任務，加上 marathon 就能跑長任務。但是後來 Spark 将細粒度的模式 deprecated 掉了，因為效率還是比較差。
Mesos 的問題
排程在大資料領域是核心中的核心，在容器平台中是重要的，但不是全部。是以容器還需要編排，需要各種外圍元件，讓容器跑起來運作長任務，并且互相通路。Marathon 隻是萬裡長征的第一步。
是以早期用 Marathon + Mesos 的廠商，多是裸用 Marathon 和 Mesos 的，由于周邊不全，因而要做各種的封裝，各家不同。大家有興趣可以到社群上去看裸用 Marathon 和 Mesos 的廠商，各有各的負載均衡方案，各有各的服務發現方案。
是以後來有了 DCOS，也就是在 Marathon 和 Mesos 之外，加了大量的周邊元件，補充一個容器平台應有的功能，但是很可惜，很多廠商都自己定制過了，還是裸用 Marathon 和 Mesos 的比較多。
而且 Mesos 雖然排程牛，但是隻解決一部分排程，另一部分靠使用者自己寫 framework 以及裡面的排程，有時候還需要開發 Executor，這個開發起來還是很複雜的，學習成本也比較高。
雖說後來的 DCOS 功能也比較全了，但是感覺沒有如 Kubernetes 一樣使用統一的語言，而是采取大雜燴的方式。在 DCOS 的整個生态中，Marathon 是 Scala 寫的，Mesos 是 C++ 寫的，Admin Router 是 Nginx+lua，Mesos-DNS 是Go，Marathon-lb 是 Python，Minuteman 是 Erlang，這樣太複雜了吧，林林總總，出現了 Bug 的話，比較難自己修複。
Kubernetes
而 Kubernetes 不同，初看 Kubernetes 的人覺得他是個奇葩所在，容器還沒建立出來，概念先來一大堆，文檔先讀一大把，編排檔案也複雜，元件也多，讓很多人望而卻步。我就想建立一個容器，怎麼這麼多的前置條件。如果你将 Kubernetes 的概念放在界面上，讓客戶去建立容器，一定會被客戶罵。
在開發人員角度，使用 Kubernetes 絕對不是像使用虛拟機一樣，開發除了寫代碼，做建構，做測試，還需要知道自己的應用是跑在容器上的，而不是當甩手掌櫃。開發人員需要知道，容器是和原來的部署方式不一樣的存在，你需要區分有狀态和無狀态，容器挂了起來，就會按照鏡像還原了。開發人員需要寫 Dockerfile，需要關心環境的傳遞，需要了解太多原來不了解的東西。實話實說，一點都不友善。
在運維人員角度，使用 Kubernetes 也絕對不是像運維虛拟機一樣，我傳遞出來了環境，應用之間互相怎麼調用，我才不管，我就管網絡通不通。在運維眼中他做了過多不該關心的事情，例如服務的發現，配置中心，熔斷降級，這都應該是代碼層面關心的事情，應該是 SpringCloud 和 Dubbo 關心的事情，為什麼要到容器平台層來關心這個。
Kubernetes + Docker，卻是 Dev 和 Ops 融合的一個橋梁。
Docker 是微服務的傳遞工具，微服務之後，服務太多了，單靠運維根本管不過來，而且很容易出錯，這就需要研發開始關心環境傳遞這件事情。例如配置改了什麼，建立了哪些目錄，如何配置權限，隻有開發最清楚，這些資訊很難通過文檔的方式又及時又準确地同步到運維部門來，就算是同步過來了，運維部門的維護量也非常的大。
是以，有了容器，最大的改變是環境傳遞的提前，是每個開發多花 5% 的時間，去換取運維 200% 的勞動，并且提高穩定性。
而另一方面，本來運維隻管傳遞資源，給你個虛拟機，虛拟機裡面的應用如何互相通路我不管，你們愛咋地咋地，有了 Kubernetes 以後，運維層要關注服務發現，配置中心，熔斷降級。
兩者融合在了一起。在微服務化的研發的角度來講，Kubernetes 雖然複雜，但是設計的都是有道理的，符合微服務的思想。
三、微服務化的十個設計要點
微服務有哪些要點呢？第一張圖是 SpringCloud 的整個生态。
第二張圖是微服務的 12 要素以及在網易雲的實踐。
第三張圖是建構一個高并發的微服務，需要考慮的所有的點。（打個廣告，這是一門課程，即将上線。）
接下來細說微服務的設計要點。
設計要點一：API 網關。
在實施微服務的過程中，不免要面臨服務的聚合與拆分，當後端服務的拆分相對比較頻繁的時候，作為手機 App 來講，往往需要一個統一的入口，将不同的請求路由到不同的服務，無論後面如何拆分與聚合，對于手機端來講都是透明的。
有了 API 網關以後，簡單的資料聚合可以在網關層完成，這樣就不用在手機 App 端完成，進而手機 App 耗電量較小，使用者體驗較好。
有了統一的 API 網關，還可以進行統一的認證和鑒權，盡管服務之間的互相調用比較複雜，接口也會比較多，API 網關往往隻暴露必須的對外接口，并且對接口進行統一的認證和鑒權，使得内部的服務互相通路的時候，不用再進行認證和鑒權，效率會比較高。
有了統一的 API 網關，可以在這一層設定一定的政策，進行 A/B 測試，藍綠釋出，預發環境導流等等。API 網關往往是無狀态的，可以橫向擴充，進而不會成為性能瓶頸。
設計要點二：無狀态化，區分有狀态的和無狀态的應用。
影響應用遷移和橫向擴充的重要因素就是應用的狀态，無狀态服務，是要把這個狀态往外移，将 Session 資料，檔案資料，結構化資料儲存在後端統一的存儲中，進而應用僅僅包含商務邏輯。
狀态是不可避免的，例如 ZooKeeper, DB，Cache 等，把這些所有有狀态的東西收斂在一個非常集中的叢集裡面。
整個業務就分兩部分，一個是無狀态的部分，一個是有狀态的部分。
無狀态的部分能實作兩點，一是跨機房随意地部署，也即遷移性，一是彈性伸縮，很容易地進行擴容。
有狀态的部分，如 DB，Cache，ZooKeeper 有自己的高可用機制，要利用到他們自己高可用的機制來實作這個狀态的叢集。
雖說無狀态化，但是目前處理的資料，還是會在記憶體裡面的，目前的程序挂掉資料，肯定也是有一部分丢失的，為了實作這一點，服務要有重試的機制，接口要有幂等的機制，通過服務發現機制，重新調用一次後端服務的另一個執行個體就可以了。
設計要點三：資料庫的橫向擴充。
資料庫是儲存狀态，是最重要的也是最容易出現瓶頸的。有了分布式資料庫可以使資料庫的性能可以随着節點增加線性地增加。
分布式資料庫最最下面是 RDS，是主備的，通過 MySql 的核心開發能力，我們能夠實作主備切換資料零丢失，是以資料落在這個 RDS 裡面，是非常放心的，哪怕是挂了一個節點，切換完了以後，你的資料也是不會丢的。
再往上就是橫向怎麼承載大的吞吐量的問題，上面有一個負載均衡 NLB，用 LVS，HAProxy, Keepalived，下面接了一層 Query Server。Query Server 是可以根據監控資料進行橫向擴充的，如果出現了故障，可以随時進行替換的修複，對于業務層是沒有任何感覺的。
另外一個就是雙機房的部署，DDB 開發了一個資料運河 NDC 的元件，可以使得不同的 DDB 之間在不同的機房裡面進行同步，這時候不但在一個資料中心裡面是分布式的，在多個資料中心裡面也會有一個類似雙活的一個備份，高可用性有非常好的保證。
設計要點四：緩存
在高并發場景下緩存是非常重要的。要有層次的緩存，使得資料盡量靠近使用者。資料越靠近使用者能承載的并發量也越大，響應時間越短。
在手機用戶端 App 上就應該有一層緩存，不是所有的資料都每時每刻從後端拿，而是隻拿重要的，關鍵的，時常變化的資料。
尤其對于靜态資料，可以過一段時間去取一次，而且也沒必要到資料中心去取，可以通過 CDN，将資料緩存在距離用戶端最近的節點上，進行就近下載下傳。
有時候 CDN 裡面沒有，還是要回到資料中心去下載下傳，稱為回源，在資料中心的最外層，我們稱為接入層，可以設定一層緩存，将大部分的請求攔截，進而不會對背景的資料庫造成壓力。
如果是動态資料，還是需要通路應用，通過應用中的商務邏輯生成，或者去資料庫讀取，為了減輕資料庫的壓力，應用可以使用本地的緩存，也可以使用分布式緩存，如 Memcached 或者 Redis，使得大部分請求讀取緩存即可，不必通路資料庫。
當然動态資料還可以做一定的靜态化，也即降級成靜态資料，進而減少後端的壓力。
設計要點五：服務拆分和服務發現
當系統扛不住，應用變化快的時候，往往要考慮将比較大的服務拆分為一系列小的服務。
這樣第一個好處就是開發比較獨立，當非常多的人在維護同一個代碼倉庫的時候，往往對代碼的修改就會互相影響，常常會出現我沒改什麼測試就不通過了，而且代碼送出的時候，經常會出現沖突，需要進行代碼合并，大大降低了開發的效率。
另一個好處就是上線獨立，物流子產品對接了一家新的快遞公司，需要連同下單一起上線，這是非常不合理的行為，我沒改還要我重新開機，我沒改還讓我釋出，我沒改還要我開會，都是應該拆分的時機。
另外再就是高并發時段的擴容，往往隻有最關鍵的下單和支付流程是核心，隻要将關鍵的交易鍊路進行擴容即可，如果這時候附帶很多其他的服務，擴容即是不經濟的，也是很有風險的。
再就是容災和降級，在大促的時候，可能需要犧牲一部分的邊角功能，但是如果所有的代碼耦合在一起，很難将邊角的部分功能進行降級。
當然拆分完畢以後，應用之間的關系就更加複雜了，因而需要服務發現的機制，來管理應用互相的關系，實作自動的修複，自動的關聯，自動的負載均衡，自動的容錯切換。
設計要點六：服務編排與彈性伸縮
當服務拆分了，程序就會非常的多，因而需要服務編排來管理服務之間的依賴關系，以及将服務的部署代碼化，也就是我們常說的基礎設施即代碼。這樣對于服務的釋出，更新，復原，擴容，縮容，都可以通過修改編排檔案來實作，進而增加了可追溯性，易管理性，和自動化的能力。
既然編排檔案也可以用代碼倉庫進行管理，就可以實作一百個服務中，更新其中五個服務，隻要修改編排檔案中的五個服務的配置就可以，當編排檔案送出的時候，代碼倉庫自動觸發自動部署更新腳本，進而更新線上的環境，當發現新的環境有問題時，當然希望将這五個服務原子性地復原，如果沒有編排檔案，需要人工記錄這次更新了哪五個服務。有了編排檔案，隻要在代碼倉庫裡面 revert，就復原到上一個版本了。所有的操作在代碼倉庫裡都是可以看到的。
設計要點七：統一配置中心
服務拆分以後，服務的數量非常多，如果所有的配置都以配置檔案的方式放在應用本地的話，非常難以管理，可以想象當有幾百上千個程序中有一個配置出現了問題，是很難将它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。
在微服務中，配置往往分為幾類，一類是幾乎不變的配置，這種配置可以直接打在容器鏡像裡面，第二類是啟動時就會确定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去，第三類就是統一的配置，需要通過配置中心進行下發，例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置檔案中統一配置。
設計要點八：統一的日志中心
同樣是程序數目非常多的時候，很難對成千上百個容器，一個一個登入進去檢視日志，是以需要統一的日志中心來收集日志，為了使收集到的日志容易分析，對于日志的規範，需要有一定的要求，當所有的服務都遵守統一的日志規範的時候，在日志中心就可以對一個交易流程進行統一的追溯。例如在最後的日志搜尋引擎中，搜尋交易号，就能夠看到在哪個過程出現了錯誤或者異常。
設計要點九：熔斷，限流，降級
服務要有熔斷，限流，降級的能力，當一個服務調用另一個服務，出現逾時的時候，應及時傳回，而非阻塞在那個地方，進而影響其他使用者的交易，可以傳回預設的托底資料。
當一個服務發現被調用的服務，因為過于繁忙，線程池滿，連接配接池滿，或者總是出錯，則應該及時熔斷，防止因為下一個服務的錯誤或繁忙，導緻本服務的不正常，進而逐漸往前傳導，導緻整個應用的雪崩。
當發現整個系統的确負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。
還有一種手段就是限流，當既設定了熔斷政策，又設定了降級政策，通過全鍊路的壓力測試，應該能夠知道整個系統的支撐能力，因而就需要制定限流政策，保證系統在測試過的支撐能力範圍内進行服務，超出支撐能力範圍的，可拒絕服務。當你下單的時候，系統彈出對話框說 “系統忙，請重試”，并不代表系統挂了，而是說明系統是正常工作的，隻不過限流政策起到了作用。
設計要點十：全方位的監控
當系統非常複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪裡。當系統出現異常的時候，監控系統可以配合告警系統，及時地發現，通知，幹預，進而保障系統的順利運作。
當壓力測試的時候，往往會遭遇瓶頸，也需要有全方位的監控來找出瓶頸點，同時能夠保留現場，進而可以追溯和分析，進行全方位的優化。
四、Kubernetes 本身就是微服務架構
基于上面這十個設計要點，我們再回來看 Kubernetes，會發現越看越順眼。
首先 Kubernetes 本身就是微服務的架構，雖然看起來複雜，但是容易定制化，容易橫向擴充。
如圖黑色的部分是 Kubernetes 原生的部分，而藍色的部分是網易雲為了支撐大規模高并發應用而做的定制化部分。
Kubernetes 的 API Server 更像網關，提供統一的鑒權和通路接口。
衆所周知，Kubernetes 的租戶管理相對比較弱，尤其是對于公有雲場景，複雜的租戶關系的管理，我們隻要定制化 API Server，對接 Keystone，就可以管理複雜的租戶關系，而不用管其他的元件。
在 Kubernetes 中幾乎所有的元件都是無狀态化的，狀态都儲存在統一的 etcd 裡面，這使得擴充性非常好，元件之間異步完成自己的任務，将結果放在 etcd 裡面，互相不耦合。
例如圖中 pod 的建立過程，用戶端的建立僅僅是在 etcd 中生成一個記錄，而其他的元件監聽到這個事件後，也相應異步的做自己的事情，并将處理的結果同樣放在 etcd 中，同樣并不是哪一個元件遠端調用 kubelet，指令它進行容器的建立，而是發現 etcd 中，pod 被綁定到了自己這裡，方才拉起。
為了在公有雲中實作租戶的隔離性，我們的政策是不同的租戶，不共享節點，這就需要 Kubernetes 對于 IaaS 層有所感覺，因而需要實作自己的 Controller，Kubernetes 的設計使得我們可以獨立建立自己的 Controller，而不是直接改代碼。
API-Server 作為接入層，是有自己的緩存機制的，防止所有的請求壓力直接到後端資料庫上。但是當仍然無法承載高并發請求時，瓶頸依然在後端的 etcd 存儲上，這和電商應用一摸一樣。當然能夠想到的方式也是對 etcd 進行分庫分表，不同的租戶儲存在不同的 etcd 叢集中。
有了 API Server 做 API 網關，後端的服務進行定制化，對于 client 和 kubelet 是透明的。
如圖是定制化的容器建立流程，由于大促和非大促期間，節點的數目相差比較大，因而不能采用事先全部建立好節點的方式，這樣會造成資源的浪費，因而中間添加了網易雲自己的子產品 Controller 和 IaaS 的管理層，使得當建立容器資源不足的時候，動态調用 IaaS 的接口，動态的建立資源。這一切對于用戶端和 kubelet 無感覺。
為了解決超過 3 萬個節點的規模問題，網易雲需要對各個子產品進行優化，由于每個子子產品僅僅完成自己的功能，Scheduler 隻管排程，Proxy 隻管轉發，而非耦合在一起，因而每個元件都可以進行獨立的優化，這符合微服務中的獨立功能，獨立優化，互不影響。而且 Kubernetes 的所有元件都是 Go 開發的，更加容易一些。是以 Kubernetes 上手慢，但是一旦需要定制化，會發現更加容易。
五、Kubernetes 更加适合微服務和 DevOps 的設計
好了，說了 K8S 本身，接下來說說 K8S 的理念設計，為什麼這麼适合微服務。
前面微服務設計的十大模式，其中一個就是區分無狀态和有狀态，在 K8S 中，無狀态對應 deployment，有狀态對應 StatefulSet。
deployment 主要通過副本數，解決橫向擴充的問題。
而 StatefulSet 通過一緻的網絡 ID，一緻的存儲，順序的更新，擴充，復原等機制，保證有狀态應用，很好地利用自己的高可用機制。因為大多數叢集的高可用機制，都是可以容忍一個節點暫時挂掉的，但是不能容忍大多數節點同時挂掉。而且高可用機制雖然可以保證一個節點挂掉後回來，有一定的修複機制，但是需要知道剛才挂掉的到底是哪個節點，StatefulSet 的機制可以讓容器裡面的腳本有足夠的資訊，處理這些情況，實作哪怕是有狀态，也能盡快修複。
在微服務中，比較推薦使用雲平台的 PaaS，例如資料庫，消息總線，緩存等。但是配置也是非常複雜的，因為不同的環境需要連接配接不同的 PaaS 服務。
K8S 裡面的 headless service 是可以很好地解決這個問題的，隻要給外部服務建立一個 headless service，指向相應的 PaaS 服務，并且将服務名配置到應用中。由于生産和測試環境分成 Namespace，雖然配置了相同的服務名，但是不會錯誤通路，簡化了配置。
微服務少不了服務發現，除了應用層可以使用 SpringCloud 或者 Dubbo 進行服務發現，在容器平台層當然是用 Service了，可以實作負載均衡，自修複，自動關聯。
服務編排，本來 K8S 就是編排的标準，可以将 yml 檔案放到代碼倉庫中進行管理，而通過 deployment 的副本數，可以實作彈性伸縮。
對于配置中心，K8S 提供了 configMap，可以在容器啟動的時候，将配置注入到環境變量或者 Volume 裡面。但是唯一的缺點是，注入到環境變量中的配置不能動态改變了，好在 Volume 裡面的可以，隻要容器中的程序有 reload 機制，就可以實作配置的動态下發了。
統一日志和監控往往需要在 Node 上部署 Agent，來對日志和名額進行收集，當然每個 Node 上都有，daemonset 的設計，使得更容易實作。
當然目前最最火的 Service Mesh，可以實作更加精細化的服務治理，進行熔斷，路由，降級等政策。Service Mesh 的實作往往通過 sidecar 的方式，攔截服務的流量，進行治理。這也得力于 Pod 的理念，一個 Pod 可以有多個容器，如果當初的設計沒有 Pod，直接啟動的就是容器，會非常的不友善。
是以 K8S 的各種設計，看起來非常備援和複雜，入門門檻比較高，但是一旦想實作真正的微服務，K8S 可以給你各種可能的組合方式。實踐過微服務的人，往往會對這一點深有體會。
六、Kubernetes 常見的使用方式
下面我們來看一下，微服務化的不同階段，Kubernetes 的使用方式。
第一階段：使用公有雲虛拟機
也即沒有微服務化的階段，基本上一個程序就能搞定，兩個程序做高可用，不需要使用容器，虛拟機就非常好。
第二階段：容器作為持續內建工具
當微服務開始拆分了，如何保證拆分後功能的一緻性，需要持續內建作為保證，如前面的論述，容器是非常好的持續內建工具，是解決 CI/CD 中 D 的，是以一開始用 host 網絡就可以，這樣可以保證部署方式和原來相容。
如果想用私有雲進行部署，直接部署在實體機上，在性能要求沒有很高，但是又要和其他實體機很好的通信的情況下，可以用 bridge 打平網絡的方式比較好。通過建立網橋，将實體網卡，容器網卡都連接配接到一個網橋上，可以實作所有的容器和實體機在同樣的一個二層網絡裡面。
如果性能要求比較高，例如要部署類似緩存，則可以使用 sr-iov 網卡。
如果想實作租戶的簡單隔離，則往往使用各種 Overlay 的網絡模式，這是最常用的部署方式。圖中的資料來自網絡。Flannel，Calico 都是非常好的網絡插件，雖然 Flannel 一開始使用使用者态的模式性能不好，後來使用核心态，性能大大改善，使用 gw 模式後，和 Calico 性能相當。
網易雲采用了 Kubernetes 和 IaaS 深度融合的方式，類似 AWS 的 Fargate 的模式，一方面可以使得原來使用虛拟機的使用者平滑地遷移到容器，另一方面可以實作公有雲的租戶隔離。
如圖是融合的網易雲容器服務的架構，這個管理 OpenStack 和 Kubernetes 的管理平台，也是用的微服務架構，有 API 網關，熔斷限流功能，拆分成不同的服務，部署在 K8S 上的，是以處處是微服務。