Kubernetes 1.0剛剛發(fā)布，開源社區(qū)400多位貢獻(xiàn)者一年的努力，多達(dá)14000多次的代碼提交，最終達(dá)到了之前預(yù)計的milestone，并意味著這個開源容器編排系統(tǒng)可以正式在生產(chǎn)環(huán)境使用，必將推動容器生態(tài)及周邊產(chǎn)業(yè)的進(jìn)步發(fā)展。本文主要介紹kubernetes1.0較新的功能特性，包括服務(wù)發(fā)現(xiàn)方式及較新版本對應(yīng)的設(shè)置變化，如何用DNS方式構(gòu)建內(nèi)網(wǎng)服務(wù)發(fā)現(xiàn)，存儲支持，如何解決集群存儲及如何使用rbd的方式將Ceph存儲塊附加到Pod，監(jiān)控，如何在集群模式下搭建監(jiān)控系統(tǒng)等話題。以及介紹Kuberentes官方發(fā)布時官方提到的功能理念及未來部分的功能擴(kuò)展，包括Kubernetes產(chǎn)品經(jīng)理 Craig McLuckie所提及的Kubernetes的整體愿景等。

首先介紹 Kubernetes v1.0的部分較新的特征，包括DNS負(fù)載均衡，Kuberentes監(jiān)控和Kubernetes HA高可用性的方式等

1. DNS，負(fù)載均衡

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

這樣portlist里僅僅是一個容器端口到服務(wù)端口的maping，這種方式和marathon里的方式相似。loadbalancer項里是提供給外部clouder provider使用的，云提供商可以通過獲取loadbanancer指定的入口ip和對應(yīng)的虛擬服務(wù)入口，來建立自定義的服務(wù)連接通道，或者通過獲取 endpoint或pod直接將訪問導(dǎo)入containter。當(dāng)然，如果loadbanancer在集群外部，需要自行解決連入集群內(nèi)網(wǎng)的問題。

DNS服務(wù)發(fā)現(xiàn)，就是在Kubernetes內(nèi)網(wǎng)建立一套pod組合，對外提供DNS服務(wù)。DNS服務(wù)組本身是放在Kubernetes平臺里的，同時又給Kubernetes平臺提供服務(wù)。這個和監(jiān)控的服務(wù)組合類似，當(dāng)然也可以單獨(dú)拿出來，以standalone的方式在Kubernetes 平臺之外運(yùn)行提供服務(wù)。

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

舉例來說，如果在K8s中創(chuàng)建了一個服務(wù)“mysql-service", namespace是"tenxcloud"， 這時會在skyDNS中形成記錄 mysql-service.tenxcloud.tenx.domain。在后續(xù)創(chuàng)建的pod中，如果仍然以namespace 為tenxcloud創(chuàng)建，那么在pod內(nèi)可以直接用 mysql-service 來訪問上述服務(wù)，但如果在其他的namespace內(nèi)訪問，就需要加上命名空間名稱，如mysql-service.tenxcloud。實(shí)際上最終的 url是要加上端口號，需要在servcie定義中給端口命名，比如mysql-service 的訪問端口是 {"name": "mysqlport" , "targetport": 3306, "protocol": "tcp"}，那么對于的3306，對于的 DNS SRV記錄是 _mysqlport._tcp.mysql-service.tenxcloud。

Kubernetes 支持以 "link"方式連接跨機(jī)容器服務(wù)，但link的方式依賴于服務(wù)的啟動順序，容錯性能較差，官方更加推薦以DNS的方式來構(gòu)建。

2. Kubernetes監(jiān)控

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

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

當(dāng)以pod及服務(wù)方式運(yùn)行時，heapster通過虛擬網(wǎng)訪問kube-apiserver， 獲取所有node的信息，主要是ip地址，然后通過node節(jié)點(diǎn)(ip地址)上Kubelet對外提供的服務(wù)獲取對應(yīng)pod的metrics。

Kubelet則通過內(nèi)部集成cadvisor的組件或者最終的數(shù)據(jù)。最后，heapster會將獲取的數(shù)據(jù)存儲到后端， 現(xiàn)階段后端存儲支持Influxdb 和GCM等。

簡單介紹下Influxdb， 它是時序數(shù)據(jù)庫，即所有記錄都帶有時間戳屬性。主要用于實(shí)時數(shù)據(jù)采集，事件跟蹤記錄，存儲時間圖表原始數(shù)據(jù)等。它的查詢語言與SQL類似，又略有不同;對外提供RESTAPI接口。自帶的操作面板可以直接把數(shù)據(jù)粗略轉(zhuǎn)成曲線圖表。支持定時自動運(yùn)行的統(tǒng)計命令，比如，定時執(zhí)行求取平均值并存到另外的表格，對于帶有時間坐標(biāo)的數(shù)據(jù)分析有很高的價值。目前在過時數(shù)據(jù)清理上略有瑕疵，不能定時自動清除過往數(shù)據(jù)，需要外接類似crontab等定時工具來處理。

Inflxudb可與Grafana結(jié)合，Grafana可將influxdb數(shù)據(jù)內(nèi)容更好的呈現(xiàn)成圖表曲線的形式，如果不需要提供對外產(chǎn)品的話，Grafana是很好的數(shù)據(jù)圖形工具。

通過設(shè)置heapster --source 來設(shè)置數(shù)據(jù)來源，--sink 參數(shù)可以設(shè)定后端存儲為influxdb。 heapster 抓取數(shù)據(jù)后，將分類存儲到多個influxdb 表格中，包括cpu、memory、network、eventlog 等，另外可以設(shè)置定時統(tǒng)計命令來處理這些raw數(shù)據(jù)。

heapster目前未到1.0版本，對于小規(guī)模的集群監(jiān)控比較方便。但對于較大規(guī)模的集群，heapster目前的cache方式會吃掉大量內(nèi)存。因?yàn)橐〞r獲取整個集群的容器信息，信息在內(nèi)存的臨時存儲成為問題，再加上heaspter要支持api獲取臨時metrics，如果將 heapster以pod方式運(yùn)行，很容易出現(xiàn)OOM。所以目前建議關(guān)掉cache，并以standalone的方式獨(dú)立出Kubernetes平臺，比如單獨(dú)運(yùn)行在一個VM上。而influxdb也要做好數(shù)據(jù)清理工作，日志及監(jiān)控信息增長會給系統(tǒng)帶來很大煩惱，外接crontab運(yùn)行清除命令即可。但作為GoogleCloudPlatform的工具，heapster也有望以容器工具集項目的方式加入CNCF，所以建議Kubernetes監(jiān)控還是用 heapster方式來做。

3. 官方Kubernetes HA的方式

利用etcd實(shí)現(xiàn)master 選舉，從多個Master中得到一個kube-apiserver， 保證至少有一個master可用，實(shí)現(xiàn)high availability。對外以loadbalancer的方式提供入口。這種方式可以用作ha，但仍未成熟，據(jù)了解，未來會更新升級ha的功能。這里用到了kubelet的啟動方式，--config參數(shù)，設(shè)置路徑添加kubelet啟動時刻需要做的動作。 --config=/etc/kubernetes/manifests，可以利用其創(chuàng)建pod。

有以下幾點(diǎn)：

Process watcher，保證 master運(yùn)行失敗后自動重啟，這個是必要條件。monit的方式，或者自行解決守護(hù)問題。

可靠的冗余存儲，使用etcd集群模式。 etcd是key value的存儲方式，它的角色類似于zookeeper。etcd搭建集群節(jié)點(diǎn)至少3個，因?yàn)檫x舉投票最終要確定leader和follower，初始投票會假定自身都是leader，同時又都reject對方，無法形成多數(shù)的票數(shù)。3個可以形成多數(shù)對少數(shù)的情況，并且建議把投票timeout的設(shè)置成不同的時間。而5個以上較為穩(wěn)定。

多個kube-apiserver，用負(fù)載均衡的方式統(tǒng)一起來。node節(jié)點(diǎn)訪問時，通過haproxy的入口，分發(fā)到不同的apiserver，而apiserver背后是相同的etcd集群。

用組件podmaster 模擬選舉。它利用etcd實(shí)現(xiàn)一個選舉算法。類似zookeeper的方式，選舉出來的kube-apiserver被啟動并作為主出口，其他的kube-apiserver處于standby的狀態(tài)被停止。

安裝部署 kube-sheduller和kube-controller-manager，這里在每臺master機(jī)器上同時存在一套 kube-apiserver、kube-scheduller 和kube-controller-manager，并且以localhost的方式連接。這樣當(dāng)kube-apiserver被選中時，同機(jī)的 kube-scheduller和kube-controoler-manager起作用，當(dāng)standby時，同機(jī)的3個組件都會不可用。

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

Q&A

Q1：有幾個問題:1.容器 net方式 網(wǎng)絡(luò)性能損失多少，2 .Kubernetes是怎么做到的容器自動遷移?

A：容器是建在pod里，實(shí)際上最終用的是docker 的 網(wǎng)絡(luò)參數(shù)，同pod里不用轉(zhuǎn)發(fā)，是docker本身的功能，在虛擬網(wǎng)絡(luò)里，是以NAT的方式。

Q2：K8s是不是定義的一個pod的容器集群是只部署在同一個主機(jī)上?

A：到目前是，同一個pod里的containerS 是部署在同一臺主機(jī)的。

Q3：這個圖里的loadbalancer是安裝在哪里的?所有的客戶端以及kubelete會連接這個嘛?

A：loadbanlancer可以任意地方，只要能訪問到集群，會作為api的出口。

Q4：K8s中的etcd放在容器里的嗎?

A：不用放在里面，可以放進(jìn)去，也可以在外面。

原文鏈接：www.dockone.io/article/546