摘要：問題是不是定義的一個的容器集群是只部署在同一個主機上楊樂到目前是，同一個里的是部署在同一臺主機的。問題這個圖里的是安裝在哪里的所有的客戶端以及會連接這個嘛楊樂可以任意地方，只要能訪問到集群，會作為的出口。

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

下文是本次的分享整理：

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

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的方式來構建。

比較老的版本 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方式來做。

利用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放在容器里的嗎？

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