摘要：主要介紹的主要特性和一些經(jīng)驗(yàn)。先從整體上看一下的一些理念和基本架構(gòu)，然后從網(wǎng)絡(luò)資源管理存儲(chǔ)服務(wù)發(fā)現(xiàn)負(fù)載均衡高可用安全監(jiān)控等方面向大家簡單介紹的這些主要特性。集群范圍內(nèi)的監(jiān)控主要由和如構(gòu)建。

主要介紹 Kubernetes 的主要特性和一些經(jīng)驗(yàn)。先從整體上看一下Kubernetes的一些理念和基本架構(gòu)， 然后從網(wǎng)絡(luò)、 資源管理、存儲(chǔ)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高可用、rolling upgrade、安全、監(jiān)控等方面向大家簡單介紹Kubernetes的這些主要特性。

我們先從整體上看一下Kubernetes的一些理念和基本架構(gòu)， 然后從網(wǎng)絡(luò)、 資源管理、存儲(chǔ)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高可用、rolling upgrade、安全、監(jiān)控等方面向大家簡單介紹Kubernetes的這些主要特性。

當(dāng)然也會(huì)包括一些需要注意的問題。主要目的是幫助大家快速理解 Kubernetes的主要功能，今后在研究和使用這個(gè)具的時(shí)候有所參考和幫助。

1.1）用戶不需要關(guān)心需要多少臺(tái)機(jī)器，只需要關(guān)心軟件（服務(wù)）運(yùn)行所需的環(huán)境。以服務(wù)為中心，你需要關(guān)心的是api，如何把大服務(wù)拆分成小服務(wù)，如何使用api去整合它們。

1.2) 保證系統(tǒng)總是按照用戶指定的狀態(tài)去運(yùn)行。

1.3) 不僅僅提給你供容器服務(wù)，同樣提供一種軟件系統(tǒng)升級(jí)的方式；在保持HA的前提下去升級(jí)系統(tǒng)是很多用戶最想要的功能，也是最難實(shí)現(xiàn)的。

1.4) 那些需要擔(dān)心和不需要擔(dān)心的事情。

1.5）更好的支持微服務(wù)理念，劃分、細(xì)分服務(wù)之間的邊界，比如lablel、pod等概念的引入。

對(duì)于Kubernetes的架構(gòu)，可以參考官方文檔。

大致由一些主要組件構(gòu)成，包括Master節(jié)點(diǎn)上的kube-apiserver、kube-scheduler、kube-controller-manager、控制組件kubectl、狀態(tài)存儲(chǔ)etcd、Slave節(jié)點(diǎn)上的kubelet、kube-proxy，以及底層的網(wǎng)絡(luò)支持（可以用Flannel、OpenVSwitch、Weave等）。

看上去也是微服務(wù)的架構(gòu)設(shè)計(jì)，不過目前還不能很好支持單個(gè)服務(wù)的橫向伸縮，但這個(gè)會(huì)在 Kubernetes 的未來版本中解決。

會(huì)從網(wǎng)絡(luò)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、資源管理、高可用、存儲(chǔ)、安全、監(jiān)控等方面向大家簡單介紹Kubernetes的這些主要特性 -> 由于時(shí)間有限，只能簡單一些了。

另外，對(duì)于服務(wù)發(fā)現(xiàn)、高可用和監(jiān)控的一些更詳細(xì)的介紹，感興趣的朋友可以通過這篇文章了解。

Kubernetes的網(wǎng)絡(luò)方式主要解決以下幾個(gè)問題：

緊耦合的容器之間通信，通過 Pod 和 localhost 訪問解決。

Pod之間通信，建立通信子網(wǎng)，比如隧道、路由，F(xiàn)lannel、Open vSwitch、Weave。

Pod和Service，以及外部系統(tǒng)和Service的通信，引入Service解決。

Kubernetes的網(wǎng)絡(luò)會(huì)給每個(gè)Pod分配一個(gè)IP地址，不需要在Pod之間建立鏈接，也基本不需要去處理容器和主機(jī)之間的端口映射。

注意：Pod重建后，IP會(huì)被重新分配，所以內(nèi)網(wǎng)通信不要依賴Pod IP；通過Service環(huán)境變量或者DNS解決。

kube-proxy和DNS， 在v1之前，Service含有字段portalip 和publicIPs， 分別指定了服務(wù)的虛擬ip和服務(wù)的出口機(jī)ip，publicIPs可任意指定成集群中任意包含kube-proxy的節(jié)點(diǎn)，可多個(gè)。portalIp 通過NAT的方式跳轉(zhuǎn)到container的內(nèi)網(wǎng)地址。在v1版本中，publicIPS被約定廢除，標(biāo)記為deprecatedPublicIPs，僅用作向后兼容，portalIp也改為ClusterIp, 而在service port 定義列表里，增加了nodePort項(xiàng)，即對(duì)應(yīng)node上映射的服務(wù)端口。

DNS服務(wù)以addon的方式，需要安裝skydns和kube2dns。kube2dns會(huì)通過讀取Kubernetes API獲取服務(wù)的clusterIP和port信息，同時(shí)以watch的方式檢查service的變動(dòng)，及時(shí)收集變動(dòng)信息，并將對(duì)于的ip信息提交給etcd存檔，而skydns通過etcd內(nèi)的DNS記錄信息，開啟53端口對(duì)外提供服務(wù)。大概的DNS的域名記錄是servicename.namespace.tenx.domain, "tenx.domain"是提前設(shè)置的主域名。

注意：kube-proxy 在集群規(guī)模較大以后，可能會(huì)有訪問的性能問題，可以考慮用其他方式替換，比如HAProxy，直接導(dǎo)流到Service 的endpints 或者 Pods上。Kubernetes官方也在修復(fù)這個(gè)問題。

有3 個(gè)層次的資源限制方式，分別在Container、Pod、Namespace 層次。Container層次主要利用容器本身的支持，比如Docker 對(duì)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等的支持；Pod方面可以限制系統(tǒng)內(nèi)創(chuàng)建Pod的資源范圍，比如最大或者最小的CPU、memory需求；Namespace層次就是對(duì)用戶級(jí)別的資源限額了，包括CPU、內(nèi)存，還可以限定Pod、rc、service的數(shù)量。

資源管理模型 －》 簡單、通用、準(zhǔn)確，并可擴(kuò)展

目前的資源分配計(jì)算也相對(duì)簡單，沒有什么資源搶占之類的強(qiáng)大功能，通過每個(gè)節(jié)點(diǎn)上的資源總量、以及已經(jīng)使用的各種資源加權(quán)和，來計(jì)算某個(gè)Pod優(yōu)先非配到哪些節(jié)點(diǎn)，還沒有加入對(duì)節(jié)點(diǎn)實(shí)際可用資源的評(píng)估，需要自己的scheduler plugin來支持。其實(shí)kubelet已經(jīng)可以拿到節(jié)點(diǎn)的資源，只要進(jìn)行收集計(jì)算即可，相信Kubernetes的后續(xù)版本會(huì)有支持。

主要是指Master節(jié)點(diǎn)的 HA方式 官方推薦 利用etcd實(shí)現(xiàn)master 選舉，從多個(gè)Master中得到一個(gè)kube-apiserver 保證至少有一個(gè)master可用，實(shí)現(xiàn)high availability。對(duì)外以loadbalancer的方式提供入口。這種方式可以用作ha，但仍未成熟，據(jù)了解，未來會(huì)更新升級(jí)ha的功能。

一張圖幫助大家理解：

也就是在etcd集群背景下，存在多個(gè)kube-apiserver，并用pod-master保證僅是主master可用。同時(shí)kube-sheduller和kube-controller-manager也存在多個(gè)，而且伴隨著kube-apiserver 同一時(shí)間只能有一套運(yùn)行。

RC 在開始的設(shè)計(jì)就是讓rolling upgrade變的更容易，通過一個(gè)一個(gè)替換Pod來更新service，實(shí)現(xiàn)服務(wù)中斷時(shí)間的最小化?；舅悸肥莿?chuàng)建一個(gè)復(fù)本為1的新的rc，并逐步減少老的rc的復(fù)本、增加新的rc的復(fù)本，在老的rc數(shù)量為0時(shí)將其刪除。

通過kubectl提供，可以指定更新的鏡像、替換pod的時(shí)間間隔，也可以rollback 當(dāng)前正在執(zhí)行的upgrade操作。

同樣， Kuberntes也支持多版本同時(shí)部署，并通過lable來進(jìn)行區(qū)分，在service不變的情況下，調(diào)整支撐服務(wù)的Pod，測試、監(jiān)控新Pod的工作情況。

大家都知道容器本身一般不會(huì)對(duì)數(shù)據(jù)進(jìn)行持久化處理，在Kubernetes中，容器異常退出，kubelet也只是簡單的基于原有鏡像重啟一個(gè)新的容器。另外，如果我們?cè)谕粋€(gè)Pod中運(yùn)行多個(gè)容器，經(jīng)常會(huì)需要在這些容器之間進(jìn)行共享一些數(shù)據(jù)。Kuberenetes 的 Volume就是主要來解決上面兩個(gè)基礎(chǔ)問題的。

Docker 也有Volume的概念，但是相對(duì)簡單，而且目前的支持很有限，Kubernetes對(duì)Volume則有著清晰定義和廣泛的支持。其中最核心的理念：Volume只是一個(gè)目錄，并可以被在同一個(gè)Pod中的所有容器訪問。而這個(gè)目錄會(huì)是什么樣，后端用什么介質(zhì)和里面的內(nèi)容則由使用的特定Volume類型決定。

創(chuàng)建一個(gè)帶Volume的Pod：

spec.volumes 指定這個(gè)Pod需要的volume信息 spec.containers.volumeMounts 指定哪些container需要用到這個(gè)Volume Kubernetes對(duì)Volume的支持非常廣泛，有很多貢獻(xiàn)者為其添加不同的存儲(chǔ)支持，也反映出Kubernetes社區(qū)的活躍程度。

emptyDir 隨Pod刪除，適用于臨時(shí)存儲(chǔ)、災(zāi)難恢復(fù)、共享運(yùn)行時(shí)數(shù)據(jù)，支持 RAM-backed filesystem hostPath 類似于Docker的本地Volume 用于訪問一些本地資源（比如本地Docker）。

gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平臺(tái)上可用。

awsElasticBlockStore 類似于GCE disk 節(jié)點(diǎn)必須是 AWS EC2的實(shí)例 nfs - 支持網(wǎng)絡(luò)文件系統(tǒng)。

rbd - Rados Block Device - Ceph

secret 用來通過Kubernetes API 向Pod 傳遞敏感信息，使用 tmpfs （a RAM-backed filesystem）

persistentVolumeClaim - 從抽象的PV中申請(qǐng)資源，而無需關(guān)心存儲(chǔ)的提供方

glusterfs

iscsi

gitRepo

根據(jù)自己的需求選擇合適的存儲(chǔ)類型，反正支持的夠多，總用一款適合的 :)

一些主要原則：
基礎(chǔ)設(shè)施模塊應(yīng)該通過API server交換數(shù)據(jù)、修改系統(tǒng)狀態(tài)，而且只有API server可以訪問后端存儲(chǔ)（etcd）。
把用戶分為不同的角色：Developers/Project Admins/Administrators。
允許Developers定義secrets 對(duì)象，并在pod啟動(dòng)時(shí)關(guān)聯(lián)到相關(guān)容器。

以secret 為例，如果kubelet要去pull 私有鏡像，那么Kubernetes支持以下方式：
通過docker login 生成 .dockercfg 文件，進(jìn)行全局授權(quán)。
通過在每個(gè)namespace上創(chuàng)建用戶的secret對(duì)象，在創(chuàng)建Pod時(shí)指定 imagePullSecrets 屬性（也可以統(tǒng)一設(shè)置在serviceAcouunt 上），進(jìn)行授權(quán)。

認(rèn)證 （Authentication）

API server 支持證書、token、和基本信息三種認(rèn)證方式。

授權(quán) （Authorization）

通過apiserver的安全端口，authorization會(huì)應(yīng)用到所有http的請(qǐng)求上
AlwaysDeny、AlwaysAllow、ABAC三種模式，其他需求可以自己實(shí)現(xiàn)Authorizer接口。

比較老的版本Kubernetes需要外接cadvisor主要功能是將node主機(jī)的container metrics抓取出來。在較新的版本里，cadvior功能被集成到了kubelet組件中，kubelet在與docker交互的同時(shí)，對(duì)外提供監(jiān)控服務(wù)。

Kubernetes集群范圍內(nèi)的監(jiān)控主要由kubelet、heapster和storage backend（如influxdb）構(gòu)建。Heapster可以在集群范圍獲取metrics和事件數(shù)據(jù)。它可以以pod的方式運(yùn)行在k8s平臺(tái)里，也可以多帶帶運(yùn)行以standalone的方式。

注意： heapster目前未到1.0版本，對(duì)于小規(guī)模的集群監(jiān)控比較方便。但對(duì)于較大規(guī)模的集群，heapster目前的cache方式會(huì)吃掉大量內(nèi)存。因?yàn)橐〞r(shí)獲取整個(gè)集群的容器信息，信息在內(nèi)存的臨時(shí)存儲(chǔ)成為問題，再加上heaspter要支持api獲取臨時(shí)metrics，如果將heapster以pod方式運(yùn)行，很容易出現(xiàn)OOM。所以目前建議關(guān)掉cache并以standalone的方式獨(dú)立出k8s平臺(tái)。

問：kubelet本身也跑在pod里嗎？
答：可以跑在容器里，也可以跑在host上，可以嘗試hyperkube的集成工具。

問：roollback的具體機(jī)制是？
答：感覺應(yīng)該通過lablel，再一個(gè)個(gè)替換已經(jīng)升級(jí)的pod，不過還沒仔細(xì)研究過。

問：Mesos和Kubernetes到底有什么區(qū)別？感覺有很多重合的地方。
答：Mesos和Kubernetes側(cè)重點(diǎn)不同，確實(shí)有一些重合的地方；mesos更擅長資源管理，支持上層framework，k8s原生為容器設(shè)計(jì)，更關(guān)注app相關(guān)的一些問題。

問：“比如用HAProxy，直接導(dǎo)流到service的endpoints或者Pods 上”，haproxy如何導(dǎo)流到Pod上，podIP不是不固定的嗎？
答：可以通過watch etcd或者api server的方式，監(jiān)聽變化來更新haproxy；kubeproxy改用haproxy，只是external loadbalancer的方式；如果要替換，需要重新開發(fā)。

問：有沒有可以推薦的分布式Volume方案？你們使用起來性能如何？
答：分布式volume，可以嘗試rbd，性能的話就需要自己多多測試，不斷調(diào)優(yōu)了；有用戶提到在使用moosefs做存儲(chǔ)，對(duì)glusterfs的支持也很多。

問：k8s的插件規(guī)范嗎？還是直接硬改？
答：有些還是比較規(guī)范的，可以plugin方式；有些還需要后續(xù)版本的調(diào)整，否則要?jiǎng)釉创a了。

問： k8s 如何監(jiān)聽docker 的事件，比如：在意外退出前，想拋出一些額外的事件，通知lb如何做？
答：不確定這個(gè)是監(jiān)聽docker的哪些事件，再pod，rc層面可以進(jìn)行watch。

問： k8s如何設(shè)置各個(gè)pod的依賴和啟動(dòng)順序？
答：目前沒看到很好的控制Pod的依賴和啟動(dòng)順序的機(jī)制 可以在應(yīng)用層面避免這些依賴和順序問題。

問：問一下k8s 集群內(nèi)部容器間網(wǎng)絡(luò)這塊的解決方案有哪些，類似flannel這類方案的性能問題有什么好的解決方案？
答：目前flannel有其他的替代方案，但flannel部署比較方便，貼近Kubernetes的整體工作模式；性能上，如果做聯(lián)機(jī)內(nèi)網(wǎng)，總會(huì)有損耗，這個(gè)需要取舍了；有用戶反映，華為的測試結(jié)果說ovs比flannel好，但是自己沒有實(shí)際測試過；flannel的性能可以看coreos官網(wǎng)的blog，上面有測試報(bào)告。

問：先用容器做輕量級(jí)虛擬機(jī)，容器間可以通過hsotname訪問，不知如何動(dòng)手？
答：k8上的內(nèi)網(wǎng)DNS（kube2dns + skydns） 應(yīng)該可以滿足需求，可以嘗試一下。

問：有沒有好的監(jiān)控工具？
答：可以參考Docker上的另外一篇文章

作者：王磊，原文鏈接：http://blog.tenxcloud.com/?p=296