開源容器編排系統 Kubernetes v1.0新特性全解
Kubernetes 1.0剛剛發布，開源社區400多位貢獻者一年的努力，多達14000多次的代碼提交，最終達到了之前預計的milestone，并意味著這個開源容器編排系統可以正式在生產環境使用，必將推動容器生態及周邊產業的進步發展。本文主要介紹kubernetes1.0較新的功能特性，包括服務發現方式及較新版本對應的設置變化，如何用DNS方式構建內網服務發現，存儲支持，如何解決集群存儲及如何使用rbd的方式將Ceph存儲塊附加到Pod，監控，如何在集群模式下搭建監控系統等話題。以及介紹Kuberentes官方發布時官方提到的功能理念及未來部分的功能擴展，包括Kubernetes產品經理 Craig McLuckie所提及的Kubernetes的整體愿景等。
首先介紹 Kubernetes v1.0的部分較新的特征，包括DNS負載均衡，Kuberentes監控和Kubernetes HA高可用性的方式等
1. DNS，負載均衡
Kubernetes服務發現通用兩種方式， 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服務發現，就是在Kubernetes內網建立一套pod組合，對外提供DNS服務。DNS服務組本身是放在Kubernetes平臺里的，同時又給Kubernetes平臺提供服務。這個和監控的服務組合類似，當然也可以單獨拿出來，以standalone的方式在Kubernetes 平臺之外運行提供服務。
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的方式運行在 Kubernetes平臺里，也可以單獨運行以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的方式獨立出Kubernetes平臺，比如單獨運行在一個VM上。而influxdb也要做好數據清理工作，日志及監控信息增長會給系統帶來很大煩惱，外接crontab運行清除命令即可。但作為GoogleCloudPlatform的工具，heapster也有望以容器工具集項目的方式加入CNCF，所以建議Kubernetes監控還是用 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，同一時間只能有一套運行。
Q&A
Q1：有幾個問題:1.容器 net方式 網絡性能損失多少，2 .Kubernetes是怎么做到的容器自動遷移?
A：容器是建在pod里，實際上最終用的是docker 的 網絡參數，同pod里不用轉發，是docker本身的功能，在虛擬網絡里，是以NAT的方式。
Q2：K8s是不是定義的一個pod的容器集群是只部署在同一個主機上?
A：到目前是，同一個pod里的containerS 是部署在同一臺主機的。
Q3：這個圖里的loadbalancer是安裝在哪里的?所有的客戶端以及kubelete會連接這個嘛?
A：loadbanlancer可以任意地方，只要能訪問到集群，會作為api的出口。
Q4：K8s中的etcd放在容器里的嗎?
A：不用放在里面，可以放進去，也可以在外面。
