Kubernetes v1.0特性解析

kubernetes1.0剛剛發佈，開源社區400多位貢獻者一年的努力，多達14000屢次的代碼提交，最終達到了以前預計的milestone, 並意味着這個開源容器編排系統能夠正式在生產環境使用，必將推進容器生態及周邊產業的進步發展。本次分享主要介紹kubernetes1.0較新的功能特性，包括服務發現方式及較新版本對應的設置變化，如何用dns方式構建內網服務發現，存儲支持，如何解決集羣存儲及如何使用rbd的方式將ceph存儲塊附加到Pod，監控，如何在集羣模式下搭建監控系統等話題。以及介紹Kuberentes官方發佈時官方提到的功能理念及將來部分的功能擴展，包括k8s產品經理Craig McLuckie所說起的kubernetes的總體願景等。

下文是本次的分享整理：

首先介紹 k8s v1.0的部分較新的特徵，包括dns負載均衡，k8s監控和k8s ha高可用性的方式等

1. DNS，負載均衡

k8s服務發現通用兩種方式， kube-proxy和DNS， 在v1以前，Service含有字段portalip 和publicIPs， 分別指定了服務的虛擬ip和服務的出口機ip，publicIPs可任意指定成集羣中任意包含kube-proxy的節點，可多個。portalIp 經過NAT的方式跳轉到container的內網地址。在v1版本中，publicIPS被約定廢除，標記爲deprecatedPublicIPs，僅用做向後兼容，portalIp也改成ClusterIp, 而在service port 定義列表裏，增長了nodePort項，即對應node上映射的服務端口。

這樣portlist裏僅僅是一個容器端口到服務端口的maping，這種方式和marathon裏的方式類似。loadbalancer項裏是提供給外部clouder provider使用的，雲提供商能夠經過獲取loadbanancer指定的入口ip和對應的虛擬服務入口，來創建自定義的服務鏈接通道，或者經過獲取endpoint或pod直接將訪問導入containter。固然，若是loadbanancer在集羣外部，須要自行解決連入集羣內網的問題。

dns服務發現，就是在k8s內網創建一套pod組合，對外提供dns服務。dns服務組自己是放在k8s平臺裏的，同時又給k8s平臺提供服務。這個和監控的服務組合相似，固然也能夠單獨拿出來，以standalone的方式在k8s平臺以外運行提供服務。

dns服務以addon的方式，須要安裝skydns和kube2dns。kube2dns會經過讀取kubernetes API獲取服務的clusterIP和port信息，同時以watch的方式檢查service的變更，及時收集變更信息，並將對於的ip信息提交給etcd存檔，而skydns經過etcd內的dns記錄信息，開啓53端口對外提供服務。大概的dns的域名記錄是 servicename.namespace.tenx.domain, "tenx.domain"是提早設置的主域名。

舉例來講，若是在K8s中建立了一個服務「mysql-service", namespace是"tenxcloud", 這時會在skydns中造成記錄 mysql-service.tenxcloud.tenx.domain。在後續建立的pod中，若是仍然以namespace 爲tenxcloud建立，那麼在pod內能夠直接用 mysql-service 來訪問上述服務，但若是在其餘的namespace內訪問，就須要加上命名空間名稱，如mysql-service.tenxcloud。實際上最終的url是要加上端口號，須要在servcie定義中給端口命名，好比mysql-service 的訪問端口是 {"name": "mysqlport" , "targetport": 3306, "protocol": "tcp"}, 那麼對於的3306,對於的 DNS SRV記錄是 _mysqlport._tcp.mysql-service.tenxcloud

kubernetes 支持以 "link"方式鏈接跨機容器服務，但link的方式依賴於服務的啓動順序,容錯性能較差，官方更加推薦以dns的方式來構建。

2. kubernetes監控

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

kubernetes集羣範圍內的監控主要由kubelet, heapster和storage backend（如influxdb）構建。Heapster能夠在集羣範圍獲取metrics和事件數據。它能夠以pod的方式運行在k8s平臺裏，也能夠單獨運行以standalone的方式。

當以pod及服務方式運行時，heapster經過虛擬網訪問kube-apiserver, 獲取全部node的信息，主要是ip地址，而後經過node節點(ip地址)上Kubelet對外提供的服務獲取對應pod的metrics。

Kubelet則經過內部集成cadvisor的組件或者最終的數據。最後，heapster會將獲取的數據存儲到後端, 現階段後端存儲支持Influxdb 和GCM等。

簡單介紹下Influxdb, 它是時序數據庫，即全部記錄都帶有時間戳屬性。主要用於實時數據採集，事件跟蹤記錄，存儲時間圖表原始數據等。它的查詢語言與SQL相似，又略有不一樣；對外提供RESTAPI接口。自帶的操做面板能夠直接把數據粗略轉成曲線圖表。支持定時自動運行的統計命令，好比，定時執行求取平均值並存到另外的表格，對於帶有時間座標的數據分析有很高的價值。目前在過期數據清理上略有瑕疵，不能定時自動清除過往數據，須要外接相似crontab等定時工具來處理。

Inflxudb可與Grafana結合，Grafana可將influxdb數據內容更好的呈現成圖表曲線的形式，若是不須要提供對外產品的話，Grafana是很好的數據圖形工具。

經過設置heapster --source 來設置數據來源，--sink 參數能夠設定後端存儲爲influxdb。 heapster 抓取數據後，將分類存儲到多個influxdb 表格中，包括cpu, memory, network, eventlog 等，另外能夠設置定時統計命令來處理這些raw數據。

heapster目前未到1.0版本，對於小規模的集羣監控比較方便。但對於較大規模的集羣，heapster目前的cache方式會吃掉大量內存。由於要定時獲取整個集羣的容器信息，信息在內存的臨時存儲成爲問題，再加上heaspter要支持api獲取臨時metrics，若是將heapster以pod方式運行，很容易出現OOM。因此目前建議關掉cache,並以standalone的方式獨立出k8s平臺，好比單獨運行在一個VM上。而influxdb也要作好數據清理工做，日誌及監控信息增加會給系統帶來很大煩惱，外接crontab運行清除命令便可。但做爲GoogleCloudPlatform的工具，heapster也有望以容器工具集項目的方式加入CNCF,因此建議k8s監控仍是用heapster方式來作。

3. 官方Kubernetes HA的方式

利用etcd實現master 選舉，從多個Master中獲得一個kube-apiserver, 保證至少有一個master可用，實現high availability。對外以loadbalancer的方式提供入口。這種方式能夠用做ha，但仍未成熟，據瞭解，將來會更新升級ha的功能。這裏用到了kubelet的啓動方式，--config參數,設置路徑添加kubelet啓動時刻須要作的動做。 --config=/etc/kubernetes/manifests，能夠利用其建立pod。

有如下幾點：

Process watcher,保證 master運行失敗後自動重啓，這個是必要條件。monit的方式，或者自行解決守護問題。
可靠的冗餘存儲, 使用etcd集羣模式。 etcd是key value的存儲方式，它的角色相似於zookeeper。etcd搭建集羣節點至少3個，由於選舉投票最終要肯定leader和follower，初始投票會假定自身都是leader, 同時又都reject對方，沒法造成多數的票數。3個能夠造成多數對少數的狀況，而且建議把投票timeout的設置成不一樣的時間。而5個以上較爲穩定。
多個kube-apiserver, 用負載均衡的方式統一塊兒來。node節點訪問時,經過haproxy的入口，分發到不一樣的apiserver, 而apiserver背後是相同的etcd集羣。
用組件podmaster 模擬選舉。它利用etcd實現一個選舉算法。相似zookeeper的方式，選舉出來的kube-apiserver被啓動並做爲主出口，其餘的kube-apiserver處於standby的狀態被中止。
安裝部署 kube-sheduller和kube-controller-manager，這裏在每臺master機器上同時存在一套 kube-apiserver, kube-scheduller 和kube-controller-manager,而且以localhost的方式鏈接。這樣當kube-apiserver被選中時，同機的kube-scheduller和kube-controoler-manager起做用，當standby時，同機的3個組件都會不可用。
也就是說，etcd集羣背景下，存在多個kube-apiserver，並用pod-master保證僅是主master可用。同時kube-sheduller和kube-controller-manager也存在多個，但伴隨着kube-apiserver,同一時間只能有一套運行。

QA節選：
問題1：有幾個問題:1.容器 net方式 網絡性能損失多少，2 .k8s是怎麼作到的容器自動遷移？

楊樂：容器是建在pod裏，實際上最終用的是docker 的 網絡參數，同pod裏不用轉發，是docker自己的功能，在虛擬網絡裏，是以NAT的方式。

問題2：K8s是否是定義的一個pod的容器集羣是隻部署在同一個主機上？

楊樂：到目前是，同一個pod裏的containerS 是部署在同一臺主機的。

問題3：這個圖裏的loadbalancer是安裝在哪裏的？全部的客戶端以及kubelete會鏈接這個嘛？

楊樂: loadbanlancer能夠任意地方，只要能訪問到集羣，會做爲api的出口。

問題4：K8s中的etcd放在容器裏的嗎？

楊樂：不用放在裏面，能夠放進去，也能夠在外面。