Kubernetes v1.0特性解析

摘要：7月24日晚8點30分，我們在CSDN Container微信用戶群進行了一場主題為“ Kubernetes v1.0特性解析”的分享，分享嘉賓是來自時速云的技術負責人楊樂。

7月21日， Google正式對外發布Kubernetes v1.0，意味著這開源容器編排系統可以正式在生產環境使用。在可預見的未來，Kubernetes必將加速虛擬容器技術生態環境發展，也必將推動 Caas容器及服務等生態產業繁榮與進步。有鑒于此，我們特別邀請到時速云技術負責人楊樂到Container微信群進行了一場關于 “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放在容器里的嗎？

楊樂：不用放在里面，可以放進去，也可以在外面。