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放在容器裏的嗎？
楊樂：不用放在裏面，可以放進去，也可以在外面。
