閒談 Kubernetes 的主要特性和經驗分享

主要介紹 Kubernetes 的主要特性和一些經驗。先從總體上看一下Kubernetes的一些理念和基本架構， 而後從網絡、 資源管理、存儲、服務發現、負載均衡、高可用、rolling upgrade、安全、監控等方面向你們簡單介紹Kubernetes的這些主要特性。

咱們先從總體上看一下Kubernetes的一些理念和基本架構， 而後從網絡、 資源管理、存儲、服務發現、負載均衡、高可用、rolling upgrade、安全、監控等方面向你們簡單介紹Kubernetes的這些主要特性。

固然也會包括一些須要注意的問題。主要目的是幫助你們快速理解 Kubernetes的主要功能，從此在研究和使用這個具的時候有所參考和幫助。

1.Kubernetes的一些理念：

1.1）用戶不須要關心須要多少臺機器，只須要關心軟件（服務）運行所需的環境。以服務爲中心，你須要關心的是api，如何把大服務拆分紅小服務，如何使用api去整合它們。

1.2) 保證系統老是按照用戶指定的狀態去運行。

1.3) 不只僅提給你供容器服務，一樣提供一種軟件系統升級的方式；在保持HA的前提下去升級系統是不少用戶最想要的功能，也是最難實現的。

1.4) 那些須要擔憂和不須要擔憂的事情。

1.5）更好的支持微服務理念，劃分、細分服務之間的邊界，好比lablel、pod等概念的引入。

對於Kubernetes的架構，能夠參考官方文檔。

大體由一些主要組件構成，包括Master節點上的kube-apiserver、kube-scheduler、kube-controller-manager、控制組件kubectl、狀態存儲etcd、Slave節點上的kubelet、kube-proxy，以及底層的網絡支持（能夠用Flannel、OpenVSwitch、Weave等）。

看上去也是微服務的架構設計，不過目前還不能很好支持單個服務的橫向伸縮，但這個會在 Kubernetes 的將來版本中解決。

2.Kubernetes的主要特性

會從網絡、服務發現、負載均衡、資源管理、高可用、存儲、安全、監控等方面向你們簡單介紹Kubernetes的這些主要特性 -> 因爲時間有限，只能簡單一些了。

另外，對於服務發現、高可用和監控的一些更詳細的介紹，感興趣的朋友能夠經過這篇文章瞭解。

1）網絡

Kubernetes的網絡方式主要解決如下幾個問題：

1. 緊耦合的容器之間通訊，經過 Pod 和 localhost 訪問解決。

2. Pod之間通訊，創建通訊子網，好比隧道、路由，Flannel、Open vSwitch、Weave。

3. 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、內存、磁盤、網絡等的支持；Pod方面能夠限制系統內建立Pod的資源範圍，好比最大或者最小的CPU、memory需求；Namespace層次就是對用戶級別的資源限額了，包括CPU、內存，還能夠限定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）安全

一些主要原則：
基礎設施模塊應該經過API server交換數據、修改系統狀態，並且只有API server能夠訪問後端存儲（etcd）。
把用戶分爲不一樣的角色：Developers/Project Admins/Administrators。
容許Developers定義secrets 對象，並在pod啓動時關聯到相關容器。

以secret 爲例，若是kubelet要去pull 私有鏡像，那麼Kubernetes支持如下方式：
經過docker login 生成 .dockercfg 文件，進行全局受權。
經過在每一個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平臺。

Q&A

問：kubelet自己也跑在pod裏嗎？
答：能夠跑在容器裏，也能夠跑在host上，能夠嘗試hyperkube的集成工具。

問：roollback的具體機制是？
答：感受應該經過lablel，再一個個替換已經升級的pod，不過還沒仔細研究過。

問：Mesos和Kubernetes到底有什麼區別？感受有不少重合的地方。
答：Mesos和Kubernetes側重點不一樣，確實有一些重合的地方；mesos更擅長資源管理，支持上層framework，k8s原生爲容器設計，更關注app相關的一些問題。

問：「好比用HAProxy，直接導流到service的endpoints或者Pods 上」，haproxy如何導流到Pod上，podIP不是不固定的嗎？
答：能夠經過watch etcd或者api server的方式，監聽變化來更新haproxy；kubeproxy改用haproxy，只是external loadbalancer的方式；若是要替換，須要從新開發。

問：有沒有能夠推薦的分佈式Volume方案？大家使用起來性能如何？
答：分佈式volume，能夠嘗試rbd，性能的話就須要本身多多測試，不斷調優了；有用戶提到在使用moosefs作存儲，對glusterfs的支持也不少。

問：k8s的插件規範嗎？仍是直接硬改？
答：有些仍是比較規範的，能夠plugin方式；有些還須要後續版本的調整，不然要動源碼了。

問： k8s 如何監聽docker 的事件，好比：在乎外退出前，想拋出一些額外的事件，通知lb如何作？
答：不肯定這個是監聽docker的哪些事件，再pod，rc層面能夠進行watch。

問： k8s如何設置各個pod的依賴和啓動順序？
答：目前沒看到很好的控制Pod的依賴和啓動順序的機制 能夠在應用層面避免這些依賴和順序問題。

問：問一下k8s 集羣內部容器間網絡這塊的解決方案有哪些，相似flannel這類方案的性能問題有什麼好的解決方案？
答：目前flannel有其餘的替代方案，但flannel部署比較方便，貼近Kubernetes的總體工做模式；性能上，若是作聯機內網，總會有損耗，這個須要取捨了；有用戶反映，華爲的測試結果說ovs比flannel好，可是本身沒有實際測試過；flannel的性能能夠看coreos官網的blog，上面有測試報告。

問：先用容器作輕量級虛擬機，容器間能夠經過hsotname訪問，不知如何動手？
答：k8上的內網DNS（kube2dns + skydns） 應該能夠知足需求，能夠嘗試一下。

問：有沒有好的監控工具？
答：能夠參考Docker上的另一篇文章

做者：王磊，原文連接：http://blog.tenxcloud.com/?p=296