本文是去年寫的一篇文章，當(dāng)時這個公眾號還沒開，首發(fā)微博上，后來運維幫轉(zhuǎn)載，這里和Mesos的文章一并推送一次，方便查閱。

閱讀對象：對Kubernetes尚未深入了解的同學(xué)

首先，為什么要用Kubernetes? 使用一個工具先要梳理下使用這個工具的目標(biāo)，我們不是為了工具而用工具。

Kubernetes的目標(biāo)用一張被很多人引用過的圖來說明最好：

一句話，Kubernetes的目標(biāo)是讓你可以像管理牲畜一樣管理你的服務(wù)，而不是像寵物一樣，同時提高資源的利用率，讓碼農(nóng)關(guān)注在應(yīng)用開發(fā)本身，高可用的事情就交給Kubernetes吧。這個圖本來是openstack提出的，但純粹IaaS層的解決方案實現(xiàn)不了這個目標(biāo)，于是有了Kubernetes。

Kubernetes和Borg系出同門，基本是Borg的開源改進(jìn)版本，引用Google Borg論文里的說法：

• it (1) hides the details of resource management and failure handling so its users can focus on application development instead; (2) operates with very high reliability and availability, and supports applica- tions that do the same; and (3) lets us run workloads across tens of thousands of machines effectively

我們?nèi)绾悟炞C是否達(dá)到這個目標(biāo)了呢?

1. 隨機(jī)關(guān)掉一臺機(jī)器，看你的服務(wù)能否正常
2. 減少的應(yīng)用實例能否自動遷移并恢復(fù)到其他節(jié)點
3. 服務(wù)能否隨著流量進(jìn)行自動伸縮

我們從一個簡單的多層應(yīng)用的架構(gòu)改進(jìn)來探討下：

說明:

• mysql應(yīng)該是一主多從的架構(gòu)，這里為了簡單進(jìn)行了省略
• service后面也會依賴數(shù)據(jù)庫等資源，這里為了簡單進(jìn)行了省略
• 箭頭表示調(diào)用和依賴關(guān)系

具體分析一下為了達(dá)到我們的目標(biāo)，需要做到改進(jìn)：

1.Loadbalancer要調(diào)用后端應(yīng)用服務(wù)節(jié)點，后端應(yīng)用服務(wù)節(jié)點掛了或者遷移增加節(jié)點，都要變更Loadbalancer的配置。這樣明顯達(dá)不到目標(biāo)，于是計劃將Loadbalancer改造成Smart Loadbalancer，通過服務(wù)發(fā)現(xiàn)機(jī)制，應(yīng)用實例啟動或者銷毀時自動注冊到一個配置中心(etcd/zookeeper)，Loadbalancer監(jiān)聽?wèi)?yīng)用配置的變化自動修改自己的配置。

2.Web應(yīng)用對后端資源的依賴，比如Mysql和Memcached，對應(yīng)資源的ip一般是寫到配置文件的。資源節(jié)點變更或者增加都要變更應(yīng)用配置。

• Mysql計劃該成域名訪問方式，而不是ip。為了避免dns變更時的延遲問題，需要在內(nèi)網(wǎng)架設(shè)私有dns。高可用采用MHA方案，然后配合服務(wù)發(fā)現(xiàn)機(jī)制自動修改dns。
• Memcached計劃參照couchbase的方式，通過服務(wù)發(fā)現(xiàn)機(jī)制，使用SmartClient，客戶端應(yīng)用監(jiān)聽配置中心的節(jié)點變化。難點可能在于對Memcached的改造(可以參考couchbase)。另外也可以通過增加一層代理的機(jī)制實現(xiàn)。

3.應(yīng)用節(jié)點遷移時依賴的系統(tǒng)和基礎(chǔ)庫不一樣如何處理?部署方式不一樣如何處理?磁盤路徑，監(jiān)聽端口等沖突怎么辦?這個可以通過Docker這樣的容器技術(shù)，將應(yīng)用部署運行的方式進(jìn)行標(biāo)準(zhǔn)化，操作系統(tǒng)和基礎(chǔ)庫的依賴允許應(yīng)用自定義，對磁盤路徑以及端口的依賴通過Docker運行參數(shù)動態(tài)注入，而不需要變更應(yīng)用配置。Docker的自定義變量以及參數(shù)，需要提供標(biāo)準(zhǔn)化的配置文件。

4.服務(wù)遷移問題 每種服務(wù)都需要一個master調(diào)度中心，來監(jiān)控實例狀態(tài)，確定要不要進(jìn)行遷移，負(fù)責(zé)統(tǒng)一調(diào)度。并且每個服務(wù)器節(jié)點上要有個agent來執(zhí)行具體的操作，監(jiān)控該節(jié)點上的應(yīng)用。另外還要提供接口以及工具去操作。

5.網(wǎng)絡(luò)以及端口沖突的問題比較麻煩 需要引入類似SDN的解決方案。

6.內(nèi)存,cpu,以及磁盤等硬件資源，原來的習(xí)慣是購買服務(wù)器的時候就根據(jù)服務(wù)器的上的應(yīng)用類型進(jìn)行規(guī)劃，如果應(yīng)用和硬件解耦，這種方式需要淘汰。但必須有一種調(diào)度機(jī)制讓應(yīng)用遷移的時候可進(jìn)行篩選?？偨Y(jié)一下，通過分析得出，要達(dá)到目標(biāo)，關(guān)鍵是解耦，應(yīng)用進(jìn)程和資源(包括 cpu，內(nèi)存，磁盤，網(wǎng)絡(luò))的解耦，服務(wù)依賴關(guān)系的解耦。

我們上面的改造機(jī)制基本是按照個案進(jìn)行設(shè)計，Kubernetes的則是要提供一套全面通用的機(jī)制。

然后，我們看看Kubernetes對以上問題的解決方案。

Kubernates架構(gòu)

先上一張Kubernetes官方的架構(gòu)圖

1.調(diào)度中心master，主要有四個組件構(gòu)成：

etcd 作為配置中心和存儲服務(wù)(架構(gòu)圖中的Distributed Watchable Storage)，保存了所有組件的定義以及狀態(tài)，Kubernetes的多個組件之間的互相交互也主要通過etcd。

Kubernetes etcd registry的目錄結(jié)構(gòu)  
 etcdctl ls /registry 
 /registry/minions 保存node節(jié)點信息 
 /registry/namespaces  
 /registry/pods 保存所有的pods信息 
 /registry/ranges 
 /registry/serviceaccounts 
 /registry/services 
 /registry/controllers 
 /registry/events Kubernetes組件的變更事件都會寫到這個目錄下 

kube-apiserver 提供和外部交互的接口，提供安全機(jī)制，大多數(shù)接口都是直接讀寫etcd中的數(shù)據(jù)。

kube-scheduler 調(diào)度器，主要干一件事情：監(jiān)聽etcd中的pod目錄變更，然后通過調(diào)度算法分配node，最后調(diào)用apiserver的bind接口將分配的node和pod進(jìn)行關(guān)聯(lián)(修改pod節(jié)點中的nodeName屬性)。scheduler在Kubernetes中是一個plugin，可以用其他的實現(xiàn)替換(比如mesos)。有不同的算法提供，算法接口如下:

type ScheduleAlgorithm interface { 
Schedule(api.Pod, NodeLister) (selectedMachine string, err error)  
} 

kube-controller-manager 承擔(dān)了master的主要功能，比如和CloudProvider(IaaS)交互，管理node，pod，replication，service，namespace等?；緳C(jī)制是監(jiān)聽etcd /registry/events下對應(yīng)的事件，進(jìn)行處理。具體的邏輯需要專門文章分析，此處不進(jìn)行詳解。

2.節(jié)點上的agent，主要有兩個組件：

kubelet 主要包含容器管理，鏡像管理，Volume管理等。同時kubelet也是一個rest服務(wù)，和pod相關(guān)的命令操作都是通過調(diào)用接口實現(xiàn)的。比如：查看pod日志，在pod上執(zhí)行命令等。pod的啟動以及銷毀操作依然是通過監(jiān)聽etcd的變更進(jìn)行操作的。但kubelet不直接和etcd交互，而是通過apiserver提供的watch機(jī)制，應(yīng)該是出于安全的考慮。kubelet提供插件機(jī)制，用于支持Volume和Network的擴(kuò)展。

kube-proxy 主要用于實現(xiàn)Kubernetes的service機(jī)制。提供一部分SDN功能以及集群內(nèi)部的智能LoadBalancer。前面我們也分析了，應(yīng)用實例在多個服務(wù)器節(jié)點之間遷移的一個難題是網(wǎng)絡(luò)和端口沖突問題。Kubernetes為每個service分配一個clusterIP(虛擬ip)。不同的service用不同的ip，所以端口也不會沖突。Kubernetes的虛擬ip是通過iptables機(jī)制實現(xiàn)的。每個service定義的端口，kube-proxy都會監(jiān)聽一個隨機(jī)端口對應(yīng)，然后通過iptables nat規(guī)則做轉(zhuǎn)發(fā)。比如Kubernetes上有個dns服務(wù)，clusterIP:10.254.0.10，端口:53。應(yīng)用對10.254.0.10:53的請求會被轉(zhuǎn)發(fā)到該node的kube-proxy監(jiān)聽的隨機(jī)端口上，然后再轉(zhuǎn)發(fā)給對應(yīng)的pod。如果該服務(wù)的pod不在當(dāng)前node上，會先在kube-proxy之間進(jìn)行轉(zhuǎn)發(fā)。當(dāng)前版本的kube-proxy是通過tcp代理實現(xiàn)的，性能損失比較大(具體參看后面的壓測比較)，1.2版本中已經(jīng)計劃將kube-proxy完全通過iptables實現(xiàn)(https://github.com/kubernetes/kubernetes/issues/3760)

3.Pods Kubernetes將應(yīng)用的具體實例抽象為pod。每個pod首先會啟動一個google_containers/pause docker容器，然后再啟動應(yīng)用真正的docker容器。這樣做的目的是為了可以將多個docker容器封裝到一個pod中，共享網(wǎng)絡(luò)地址。

4.Replication Controller 控制pod的副本數(shù)量，高可用就靠它了。

5.Services service是對一組pods的抽象，通過kube-proxy的智能LoadBalancer機(jī)制，pods的銷毀遷移不會影響services的功能以及上層的調(diào)用方。Kubernetes對service的抽象可以將底層服務(wù)和上層服務(wù)的依賴關(guān)系解耦，同時實現(xiàn)了和Docker links類似的環(huán)境變量注入機(jī)制(https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/services.md#environment-variables)，但更靈活。如果配合dns的短域名解析機(jī)制，最終可實現(xiàn)完全解耦。

6.Label key-value格式的標(biāo)簽，主要用于篩選，比如service和后端的pod是通過label進(jìn)行篩選的，是弱關(guān)聯(lián)的。

7.Namespace Kubernetes中的namespace主要用來避免pod，service的名稱沖突。同一個namespace內(nèi)的pod，service的名稱必須是唯一的。

8.Kubectl Kubernetes的命令行工具，主要是通過調(diào)用apiserver來實現(xiàn)管理。

9.Kube-dns dns是Kubernetes之上的應(yīng)用，通過設(shè)置Pod的dns searchDomain(由kubelet啟動pod時進(jìn)行操作)，可以實現(xiàn)同一個namespace中的service直接通過名稱解析(這樣帶來的好處是開發(fā)測試正式環(huán)境可以共用同一套配置)。主要包含以下組件，這幾個組件是打包到同一個pod中的。

• etcd skydns依賴，用于存儲dns數(shù)據(jù)
• skydns 開源的dns服務(wù)
• kube2sky 通過apiserver的接口監(jiān)聽kube內(nèi)部變更，然后調(diào)用skydns的接口操作dns

10.Networking Kubernetes的理念里，pod之間是可以直接通訊的(http://kubernetes.io/v1.1/docs/admin/networking.html)，但實際上并沒有內(nèi)置解決方案，需要用戶自己選擇解決方案: Flannel,OpenVSwitch,Weave 等。我們測試用的是Flannel,比較簡單。

11.配置文件 Kubernetes 支持yaml和json格式的配置文件，主要用來定義pod,replication controller,service,namespace等。

Kubernates 可能帶來的改變

1. 降低分布式應(yīng)用開發(fā)運維的復(fù)雜度 縱觀當(dāng)前的各種分布式架構(gòu)，hadoop，storm等，都是master-workers模式，框架很大一部分功能在節(jié)點的管理，處理程序的調(diào)度上，如果基于Kubernetes來實現(xiàn)類似功能，這些基本都可以交給Kubernetes完成，框架只需要負(fù)責(zé)核心數(shù)據(jù)的流轉(zhuǎn)以及收集邏輯。當(dāng)然，當(dāng)前Kubernetes的pod還未像Borg一樣直接支持batch job，但按照Kubernetes和Borg的關(guān)系，將來應(yīng)該會支持(http://blog.kubernetes.io/2015/04/borg-predecessor-to-kubernetes.html)。
2. 更完備的CI/CD(持續(xù)集成/持續(xù)交付)工具 CI是code-deploy的關(guān)鍵工具，但當(dāng)前由于受限于部署環(huán)境的不一致，CI可做的事情有限，大多數(shù)還依賴用戶的自定義腳本。有了Kubernetes這樣的標(biāo)準(zhǔn)環(huán)境后，以后此類工具可以覆蓋測試環(huán)境部署，集成測試，上線部署等環(huán)節(jié)，實現(xiàn)標(biāo)準(zhǔn)化的交付工作流。
3. Kubernetes之上的分布式存儲 Kubernetes官方提供了一個在Kubernetes上部署cassandra的例子，只需要重寫一個基于Kubernetes apiserver的SeedProvider，就可以避免靜態(tài)配置seed ip，享受Kubernetes帶來的scale-out能力。再如前面我們提到的memcached的高可用例子，如果基于Kubernetes實現(xiàn)一個memcached的smart client，只需要改下客戶端即可，非常簡單。個人認(rèn)為以后在Kubernetes上的支持多租戶的分布式存儲會更加流行。只要解決了存儲服務(wù)的scale-out問題，應(yīng)用的scale-out一般不會有太大問題。Hypernetes就是一個實現(xiàn)了多租戶的Kubernetes版本。
4. 企業(yè)應(yīng)用的分發(fā) 當(dāng)前SaaS(on-demand)比較流行的一個很大的原因是原來的on-premise應(yīng)用的部署運維成本太高，如果Kubernetes等分布式操作系統(tǒng)得到廣泛應(yīng)用，on-premise的成本降低，on-premise以及托管云模式對SaaS的格局也會帶來影響。這也是我們這樣的創(chuàng)業(yè)公司關(guān)注Kubernetes的原因之一。
5. 對IaaS的影響 當(dāng)前的IaaS平臺的組件逐漸有閉源的趨勢，比如AWS嘗試用Aurora替代Mysql，阿里云用KVStore替換Redis。用戶主要關(guān)心的是服務(wù)的可靠性，自己運維的時候可能會傾向于開源方案，但如果使用云廠商的服務(wù)，就不太關(guān)心。按照這樣的趨勢，隨著IaaS的普及，會對整個開源的生態(tài)產(chǎn)生影響。但有了Kubernetes這樣的平臺，IaaS廠商主要為Kubernetes提供運行的基礎(chǔ)環(huán)境，Kubernetes接管上面的應(yīng)用和服務(wù)，這樣在IaaS廠商之間遷移也很容易。
6. 微服務(wù) 微服務(wù)最近很熱，但這個概念其實不新。主要一直受限于運維的復(fù)雜度，沒有普及。如果運維系統(tǒng)跟不上，服務(wù)拆太細(xì)，很容易出現(xiàn)某個服務(wù)器的角落里部署著一個很古老的不常更新的服務(wù)，后來大家竟然忘記了，最后服務(wù)器遷移的時候給丟了，用戶投訴才發(fā)現(xiàn)。而隨著Docker以及Kubernetes這樣的工具和平臺逐漸成熟，微服務(wù)的時代也到來了。 在Kubernetes上的微服務(wù)治理框架可以一攬子解決微服務(wù)的rpc，監(jiān)控，容災(zāi)問題，個人覺得可以期待。

遇到的一些問題

最后總結(jié)一下我遇到的一些問題

1. 墻 gcr.io已被墻，如果在本地用腳本在虛擬機(jī)安裝，請全程翻墻。如果在服務(wù)器上就自己想辦法下載，然后在配置文件中指定鏡像地址。
2. 并發(fā)拉取鏡像導(dǎo)致鏡像文件破壞(https://github.com/kubernetes/kubernetes/issues/10623) 這個和docker也相關(guān)，建議先用腳本在各node上pull鏡像再部署。
3. 同一個pod內(nèi)的多個容器啟動順序問題 同一個pod的多個容器定義中沒有優(yōu)先級，啟動順序不能保證。比如kube-dns中，etcd要先啟動，然后skydns連接etcd創(chuàng)建基本的目錄，最后kube2sky啟動，將kube中已經(jīng)定義的數(shù)據(jù)同步到dns中。如果順序不對dns數(shù)據(jù)就不正常。如果遇到這種問題按順序重啟一下對應(yīng)的容器即可。這種問題當(dāng)前需要應(yīng)用自己通過重試機(jī)制解決。
4. 容器內(nèi)訪問外部網(wǎng)絡(luò) 如果使用了Flannel方案，但容器內(nèi)無法訪問公網(wǎng)(node可以的情況)，一般是iptables被搞壞了(https://github.com/coreos/flannel/issues/115)。
5. 當(dāng)前的Kubernetes沒有應(yīng)用的概念，我們的應(yīng)用包含4個自己開發(fā)的服務(wù)組件，還有一些依賴(mysql,redis,mongodb等)，定義下來一共要20多個yaml。要實現(xiàn)一鍵安裝或者更新，還需要做不少工作。
6. Kubernetes的公網(wǎng)負(fù)載均衡的解決方案依賴IaaS的實現(xiàn)，不夠靈活。
7. kube-proxy的性能問題，簡單的壓測結(jié)果如下: 10.254.2.99:80是service地址，后面有兩個pod。11.1.16.15:3000是其中一個pod。代碼是golang官方網(wǎng)站首頁的那個helloword。

【本文為51CTO專欄作者“王淵命”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號jolestar-blog獲取授權(quán)】

戳這里，看該作者更多好文