kubernetes1.0 剛剛發(fā)布,，開源社區(qū)400多位貢獻者一年的努力,，多達14000多次的代碼提交，最終達到了之前預計的milestone, 并意味著這個開源容器編排系統(tǒng)可以正式在生產環(huán)境使用,，必將推動容器生態(tài)及周邊產業(yè)的進步發(fā)展,。本文主要介紹kubernetes1.0較新的功能特性,，包括服務發(fā)現(xiàn)方式及較新版本對應的設置變化，如何用dns方式構建內網服務發(fā)現(xiàn),，存儲支持,，如何解決集群存儲及如何使用rbd的方式將ceph存儲塊附加到Pod,，監(jiān)控，如何在集群模式下搭建監(jiān)控系統(tǒng)等話題,。以及Kuberentes官方發(fā)布時官方提到的功能理念及未來部分的功能擴展,，包括k8s產品經理 Craig McLuckie所提及的kubernetes的整體愿景等。
首先介紹 k8s v1.0的部分較新的特征,，包括dns負載均衡,，k8s監(jiān)控和k8s ha高可用性的方式等。
1. DNS,，負載均衡
k8s服務發(fā)現(xiàn)通用兩種方式,， kube-proxy和DNS， 在v1之前,，Service含有字段portalip 和publicIPs,， 分別指定了服務的虛擬ip和服務的出口機ip，publicIPs可任意指定成集群中任意包含kube-proxy的節(jié)點,，可多個,。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服務發(fā)現(xiàn),，就是在k8s內網建立一套pod組合，對外提供dns服務,。dns服務組本身是放在k8s平臺里的,，同時又給k8s平臺提供服務。這個和監(jiān)控的服務組合類似,，當然也可以單獨拿出來,，以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中創(chuàng)建了一個服務“mysql-service", namespace是"tenxcloud", 這時會在skydns中形成記錄 mysql-service.tenxcloud.tenx.domain,。在后續(xù)創(chuàng)建的pod中,，如果仍然以namespace 為tenxcloud創(chuàng)建，那么在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監(jiān)控
比較老的版本 kubernetes需要外接cadvisor,主要功能是將node主機的container metrics抓取出來,。在較新的版本里，cadvior功能被集成到了kubelet組件中,，kubelet在與docker交互的同時,，對外提供監(jiān)控服務。
kubernetes集群范圍內的監(jiān)控主要由kubelet, heapster和storage backend(如influxdb)構建,。Heapster可以在集群范圍獲取metrics和事件數據,。它可以以pod的方式運行在k8s平臺里，也可以單獨運行以standalone的方式,。
當以pod及服務方式運行時,，heapster通過虛擬網訪問kube-apiserver, 獲取所有node的信息，主要是ip地址,，然后通過node節(jié)點(ip地址)上Kubelet對外提供的服務獲取對應pod的metrics,。
Kubelet則通過內部集成cadvisor的組件或者最終的數據。最后,，heapster會將獲取的數據存儲到后端, 現(xiàn)階段后端存儲支持Influxdb 和GCM等,。
簡單介紹下Influxdb, 它是時序數據庫,，即所有記錄都帶有時間戳屬性。主要用于實時數據采集,，事件跟蹤記錄,，存儲時間圖表原始數據等。它的查詢語言與SQL類似,，又略有不同;對外提供RESTAPI接口,。自帶的操作面板可以直接把數據粗略轉成曲線圖表。支持定時自動運行的統(tǒng)計命令,，比如,，定時執(zhí)行求取平均值并存到另外的表格，對于帶有時間坐標的數據分析有很高的價值,。目前在過時數據清理上略有瑕疵,，不能定時自動清除過往數據，需要外接類似crontab等定時工具來處理,。
Inflxudb可與Grafana結合,，Grafana可將influxdb數據內容更好的呈現(xiàn)成圖表曲線的形式，如果不需要提供對外產品的話,，Grafana是很好的數據圖形工具,。
通過設置heapster --source 來設置數據來源，--sink 參數可以設定后端存儲為influxdb,。 heapster 抓取數據后,，將分類存儲到多個influxdb 表格中，包括cpu, memory, network, eventlog 等,，另外可以設置定時統(tǒng)計命令來處理這些raw數據,。
heapster目前未到1.0版本，對于小規(guī)模的集群監(jiān)控比較方便,。但對于較大規(guī)模的集群,，heapster目前的cache方式會吃掉大量內存。因為要定時獲取整個集群的容器信息,，信息在內存的臨時存儲成為問題,，再加上heaspter要支持api獲取臨時metrics，如果將heapster以pod方式運行,，很容易出現(xiàn)OOM,。所以目前建議關掉cache,并以standalone的方式獨立出k8s平臺，比如單獨運行在一個VM上,。而influxdb也要做好數據清理工作,，日志及監(jiān)控信息增長會給系統(tǒng)帶來很大煩惱，外接crontab運行清除命令即可。但作為GoogleCloudPlatform的工具,，heapster也有望以容器工具集項目的方式加入CNCF,所以建議k8s監(jiān)控還是用heapster方式來做,。
3. 官方Kubernetes HA的方式
利用etcd實現(xiàn)master 選舉，從多個Master中得到一個kube-apiserver, 保證至少有一個master可用,，實現(xiàn)high availability,。對外以loadbalancer的方式提供入口。這種方式可以用作ha,，但仍未成熟,，據了解，未來會更新升級ha的功能,。這里用到了kubelet的啟動方式,，--config參數,設置路徑添加kubelet啟動時刻需要做的動作。 --config=/etc/kubernetes/manifests,，可以利用其創(chuàng)建pod,。
有以下幾點：
1. Process watcher,保證 master運行失敗后自動重啟，這個是必要條件,。monit的方式,，或者自行解決守護問題。
2. 可靠的冗余存儲, 使用etcd集群模式,。 etcd是key value的存儲方式,，它的角色類似于zookeeper。etcd搭建集群節(jié)點至少3個,，因為選舉投票最終要確定leader和follower,，初始投票會假定自身都是leader, 同時又都reject對方，無法形成多數的票數,。3個可以形成多數對少數的情況，并且建議把投票timeout的設置成不同的時間,。而5個以上較為穩(wěn)定,。
3. 多個kube-apiserver, 用負載均衡的方式統(tǒng)一起來。node節(jié)點訪問時,通過haproxy的入口,，分發(fā)到不同的apiserver, 而apiserver背后是相同的etcd集群,。
4. 用組件podmaster 模擬選舉。它利用etcd實現(xiàn)一個選舉算法,。類似zookeeper的方式,，選舉出來的kube-apiserver被啟動并作為主出口，其他的kube-apiserver處于standby的狀態(tài)被停止,。
5. 安裝部署 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,同一時間只能有一套運行。
