閑談Kubernetes 的主要特性和經驗分享 － 時速云 王磊
大家好，我是時速云的王磊，目前主要負責時速云容器即服務平臺的技術架構、設計和開發管理工作。很高興今天有機會和大家一起聊一聊 Kubernetes 的一些主要特性和一些經驗。
我們先從整體上看一下Kubernetes的?些理念和基本架構, 然后從網絡、 資源管理、存儲、服務發現、負載均衡、高可?、rolling upgrade、安全、監控等?面向?家簡單介紹kubernetes的這些主要特性。
當然也會包括?些需要注意的問題。主要目的是幫助大家快速理解 Kubernetes的主要功能,今后在研究和使?用這個?具的時候有所參考和幫助。
- 先來隨便看一下Kubernetes的一些理念：
1.1) 用戶不需要關心需要多少臺機器，只需要關心軟件（服務）運行所需的環境。以服務為中心，你需要關心的是api，如何把大服務拆分成小服務，如何使用api去整合它們。
1.2) 保證系統總是按照用戶指定的狀態去運行
1.3）不僅僅提給你供容器服務，同樣提供一種軟件系統升級的方式；在保持HA的前提下去升級系統是很多用戶最想要的功能，也是最難實現的。
1.4) 那些需要擔心和不需要擔心的事情
1.5）更好的支持微服務理念，劃分、細分服務之間的邊界，比如lablel、pod等概念的引入
對于Kubernetes的架構，可以參考下面的官方文檔：
https://github.com/GoogleCloud ... re.md
大致由一些主要組件構成，包括Master節點上的kube-apiserver, kube-scheduler, kube-controller-manager, 控制組件kubectl，狀態存儲etcd，Slave節點上的kubelet, kube-proxy，以及底層的網絡支持(可以用flannel, OpenVSwitch, Weave等）
看上去也是微服務的架構設計，不過目前還不能很好支持單個服務的橫向伸縮，但這個會在 Kubernetes 的未來版本中解決。
- 接下來我們就進入Kubernetes的主要特性分享了
會從網絡、服務發現、負載均衡、資源管理、?可用、存儲、安全、監控等??向?家簡單介紹kubernetes的這些主要特性 -> 由于時間有限，只能簡單一些了 :)
另外，對于服務發現、高可用和監控的一些更詳細的介紹，感興趣的朋友可以通過下面的鏈接了解：
http://www.csdn.net/article/2015-07-30/2825337
1) 網絡
Kubernetes的網絡方式主要解決以下幾個問題：
a. 緊耦合的容器之間通信，通過 Pod 和 localhost 訪問解決
b. Pod之間通信，建立通信子網，比如隧道、路由，Flannel、Open vSwitch、Weave
c. Pod和Service，以及外部系統和Service的通信，引入Service解決
Kubernetes的網絡會給每個Pod分配一個IP地址，不需要在Pod之間建立鏈接，也基本不需要去處理容器和主機之間的端口映射。
注意：Pod重建后，IP會被重新分配，所以內網通信不要依賴Pod IP；通過Service環境變量或者DNS解決。
2） 服務發現及負載均衡
kube-proxy和DNS， 在v1之前，Service含有字段portalip 和publicIPs， 分別指定了服務的虛擬ip和服務的出口機ip，publicIPs可任意指定成集群中任意包含kube-proxy的節點，可多個。portalIp 通過NAT的方式跳轉到container的內網地址。在v1版本中，publicIPS被約定廢除，標記為deprecatedPublicIPs，僅 用作向后兼容，portalIp也改為ClusterIp, 而在service port 定義列表里，增加了nodePort項，即對應node上映射的服務端口。
dns服務以addon的方式，需要安裝skydns和kube2dns。kube2dns會通過讀取kubernetes API獲取服務的clusterIP和port信息，同時以watch的方式檢查service的變動，及時收集變動信息，并將對于的ip信息提交給 etcd存檔，而skydns通過etcd內的dns記錄信息，開啟53端口對外提供服務。大概的dns的域名記錄是 servicename.namespace.tenx.domain, "tenx.domain"是提前設置的主域名。
注意：kube-proxy 在集群規模較大以后，可能會有訪問的性能問題，可以考慮用其他方式替換，比如HAProxy，直接導流到Service 的endpints 或者 Pods上。Kubernetes官方也在修復這個問題。
3）資源管理
有3 個層次的資源限制方式，分別在Container, Pod, Namespace 層次。Container層次主要利用容器本身的支持，比如Docker 對CPU, Memory, disk, network 等的支持；Pod方面可以限制系統內創建Pod的資源范圍，比如最大或者最小的CPU、memory需求；Namespace層次就是對用戶級別的資源限 額了，包括CPU、Memory，還可以限定Pod、rc、service的數量。
資源管理模型 －》 簡單、通用、準確，并可擴展
目前的資源分配計算也相對簡單，沒有什么資源搶占之類的強大功能，通過每個節點上的資源總量、以及已經使用的各種資源加權和，來計算某個Pod優 先非配到哪些節點，還沒有加入對節點實際可用資源的評估，需要自己的scheduler plugin來支持。其實kubelet已經可以拿到節點的資源，只要進行收集計算即可，相信Kubernetes的后續版本會有支持。
4）?可用
主要是指Master節點的 HA方式, 官方推薦 利用etcd實現master 選舉，從多個Master中得到一個kube-apiserver, 保證至少有一個master可用，實現high availability。對外以loadbalancer的方式提供入口。這種方式可以用作ha，但仍未成熟，據了解，未來會更新升級ha的功能。
一張圖幫助大家理解：
也就是在etcd集群背景下，存在多個kube-apiserver，并用pod-master保證僅是主master可用。同時kube- sheduller和kube-controller-manager也存在多個，而且伴隨著kube-apiserver, 同一時間只能有一套運行。
5) rolling upgrade
RC 在開始的設計就是讓rolling upgrade變的更容易，通過一個一個替換Pod來更新service，實現服務中斷時間的最小化。基本思路是創建一個復本為1的新的rc，并逐步減少老的rc的復本、增加新的rc的復本，在老的rc數量為0時將其刪除。
通過kubectl提供，可以指定更新的鏡像、替換pod的時間間隔，也可以rollback 當前正在執行的upgrade操作。
同樣， Kuberntes也支持多版本同時部署，并通過lable來進行區分，在service不變的情況下，調整支撐服務的Pod，測試、監控新Pod的工作情況。
6）存儲
大家都知道容器本身一般不會對數據進行持久化處理，在Kubernetes中，容器異常退出，kubelet也只是簡單的基于原有鏡像重啟一個新 的容器。另外，如果我們在同一個Pod中運行多個容器，經常會需要在這些容器之間進行共享一些數據。Kuberenetes 的 Volume就是主要來解決上面兩個基礎問題的。
Docker 也有Volume的概念，但是相對簡單，而且目前的支持很有限，Kubernetes對Volume則有著清晰定義和廣泛的支持。其中最核心的理 念：Volume只是一個目錄，并可以被在同一個Pod中的所有容器訪問。而這個目錄會是什么樣，后端用什么介質和里面的內容則由使用的特定Volume 類型決定。
創建一個帶Volume的Pod：
spec.volumes 指定這個Pod需要的volume信息, spec.containers.volumeMounts 指定哪些container需要用到這個Volume, Kubernetes對Volume的支持非常廣泛，有很多貢獻者為其添加不同的存儲支持，也反映出Kubernetes社區的活躍程度。
emptyDir 隨Pod刪除，適用于臨時存儲、災難恢復、共享運行時數據，支持 RAM-backed filesystem
hostPath 類似于Docker的本地Volume, 用于訪問一些本地資源（比如本地Docker)
gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平臺上可用
awsElasticBlockStore 類似于GCE disk, 節點必須是 AWS EC2的實例
nfs - 支持網絡文件系統
rbd - Rados Block Device - Ceph
secret 用來通過Kubernetes API 向Pod 傳遞敏感信息，使用 tmpfs (a RAM-backed filesystem）
persistentVolumeClaim - 從抽象的PV中申請資源，而無需關心存儲的提供方
glusterfs
iscsi
gitRepo
根據自己的需求選擇合適的存儲類型，反正支持的夠多，總用一款適合的 :)
7) 安全
一些主要原則
a. 基礎設施模塊應該通過API server交換數據、修改系統狀態，而且只有API server可以訪問后端存儲(etcd)
b. 把用戶分為不同的角色：Developers/Project Admins/Administrators
c. 允許Developers定義secrets 對象，并在pod啟動時關聯到相關容器
以secret 為例，如果kubelet要去pull 私有鏡像，那么kubernetes支持以下方式：
1）通過docker login 生成 .dockercfg 文件，進行全局授權
2）通過在每個namespace上創建用戶的secret對象，在創建Pod時指定 imagePullSecrets 屬性（也可以統一設置在serviceAcouunt 上），進行授權
認證 (Authentication)
API server 支持證書、token、和基本信息三種認證方式
授權 (Authorization)
通過apiserver的安全端口，authorization會應用到所有http的請求上
AlwaysDeny、AlwaysAllow、ABAC三種模式，其他需求可以自己實現Authorizer接口
8) 監控
比較老的版本kubernetes需要外接cadvisor,主要功能是將node主機的container metrics抓取出來。在較新的版本里，cadvior功能被集成到了kubelet組件中，kubelet在與docker交互的同時，對外提供監控服務。
kubernetes集群范圍內的監控主要由kubelet, heapster和storage backend（如influxdb）構建。Heapster可以在集群范圍獲取metrics和事件數據。它可以以pod的方式運行在k8s平臺里，也 可以單獨運行以standalone的方式。
注意： heapster目前未到1.0版本，對于小規模的集群監控比較方便。但對于較大規模的集群，heapster目前的cache方式會吃掉大量內存。因為 要定時獲取整個集群的容器信息，信息在內存的臨時存儲成為問題，再加上heaspter要支持api獲取臨時metrics，如果將heapster以 pod方式運行，很容易出現OOM。所以目前建議關掉cache,并以standalone的方式獨立出k8s平臺。
今天的分享就到這里，感謝大家的參與，也希望大家多多貢獻Kubernetes相關的技術話題，一起分享、共同進步。最后，感謝Dockone社區安排這次分享活動，謝謝！
整理一下會上的主要問題和解答：
1. kubelet本身也跑在pod里嗎？
答：可以跑在容器里，也可以跑在host上，可以嘗試hyperkube的集成工具
2. roollback的具體機制
答：感覺應該通過lablel，再一個個替換已經升級的pod，不過還沒仔細研究過
3. mesos和kubernetes到底有什么區別？感覺有很多重合的地方
答：mesos和kubernetes側重點不同，確實有一些重合的地方；mesos更擅長資源管理，支持上層framework，k8s原生為容器設計，更關注app相關的一些問題。
4. “比如用HAProxy，直接導流到service的endpoints或者Pods 上”，haproxy如何導流到Pod上，podIP不是不固定的嗎？
答：可以通過watch etcd或者api server的方式，監聽變化來更新haproxy；kubeproxy改用haproxy，只是external loadbalancer的方式；如果要替換，需要重新開發。
5. 有沒有可以推薦的分布式Volume方案？你們使用起來性能如何？
答：分布式volume，可以嘗試rbd，性能的話就需要自己多多測試，不斷調優了；有用戶提到在使用moosefs做存儲，對glusterfs的支持也很多
6. k8s的插件規范嗎？還是直接硬改？
答：有些還是比較規范的，可以plugin方式；有些還需要后續版本的調整，否則要動源碼了
7. k8s 如何監聽docker 的事件，比如：在意外退出前，想拋出一些額外的事件，通知lb如何做？
答：不確定這個是監聽docker的哪些事件，再pod，rc層面可以進行watch。
8. k8s如何設置各個pod的依賴和啟動順序？
答：目前沒看到很好的控制Pod的依賴和啟動順序的機制, 可以在應用層面避免這些依賴和順序問題
9. 問一下k8s 集群內部容器間網絡這塊的解決方案有哪些，類似flannel這類方案的性能問題有什么好的解決方案？
答：目前flannel有其他的替代方案，但flannel部署比較方便，貼近kubernetes的整體工作模式；性能上，如果做聯機內網，總 會有損耗，這個需要取舍了；有用戶反映，華為的測試結果說ovs比flannel好，但是自己沒有實際測試過；flannel的性能可以看coreos官 網的blog，上面有測試報告。
10. 先用容器做輕量級虛擬機，容器間可以通過hsotname訪問，不知如何動手？
答：k8上的內網dns(kube2dns + skydns_ 應該可以滿足需求，可以嘗試一下
11. k8s的日志收集，有什么好的經驗？
答：我們目前也在嘗試一些工具和解決方案，用戶也提到了logstash，fluent等，以后可以搞個專題分享一下
12. 有沒有好的監控工具？
答：可以參考dockone上的另外一篇文章： http://dockone.io/article/397