閒談 Kubernetes 的主要特性和經驗
主要介紹 Kubernetes 的主要特性和一些經驗。先從整體上看一下Kubernetes的一些理念和基本架構, 然後從網路、 資源管理、儲存、服務發現、負載均衡、高可用、rolling upgrade、安全、監控等方面向大家簡單介紹Kubernetes的這些主要特性。
我們先從整體上看一下Kubernetes的一些理念和基本架構, 然後從網路、 資源管理、儲存、服務發現、負載均衡、高可用、rolling upgrade、安全、監控等方面向大家簡單介紹Kubernetes的這些主要特性。
當然也會包括一些需要注意的問題。主要目的是幫助大家快速理解 Kubernetes的主要功能,今後在研究和使用這個具的時候有所參考和幫助。
1.Kubernetes的一些理念:
- 使用者不需要關心需要多少臺機器,只需要關心軟體(服務)執行所需的環境。以服務為中心,你需要關心的是api,如何把大服務拆分成小服務,如何使用api去整合它們。
- 保證系統總是按照使用者指定的狀態去執行。
- 不僅僅提給你供容器服務,同樣提供一種軟體系統升級的方式;在保持HA的前提下去升級系統是很多使用者最想要的功能,也是最難實現的。
- 那些需要擔心和不需要擔心的事情。
- 更好的支援微服務理念,劃分、細分服務之間的邊界,比如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的網路方式主要解決以下幾個問題:
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、記憶體、磁碟、網路等的支援;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 filesystemhostPath 類似於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) 應該可以滿足需求,可以嘗試一下。
問:有沒有好的監控工具?
答:可以參考DockOne上的另外一篇文章。
相關文章
- 經驗談
- 經驗談集
- DBA 經驗談
- 爆破經驗談
- 轉載:Kubernetes實戰——談談微博應對春晚等突發峰值流量的經驗
- 談談Ilog的開發經驗
- 日誌和告警資料探勘經驗談
- 使用nfs經驗談NFS
- 大學打架經驗談
- Lotus 經驗談(轉)
- 淺談程式設計師的薪資和工作經驗程式設計師
- FIFO設計驗證經驗談
- 10年出海老兵的經驗談
- Hugo 建站經驗之談Go
- Android MVP經驗談AndroidMVP
- Oracle 學習經驗談Oracle
- Doxygen簡單經驗談。。。
- ERP經驗談(轉)
- SAP學習經驗談
- Linux安全經驗談Linux
- JGraph開發經驗談
- og視訊BJL莊閒最穩的打法經驗攻略
- 工作十年,談談我的高可用架構和系統設計經驗架構
- puppeteer踩坑經驗之談
- 淺談SAP學習經驗
- 微軟測試工作經驗談微軟
- TurboLinux使用經驗談(轉)Linux
- CVS使用經驗談 (轉)
- 【經驗心得】談一談我IT行業未來的方向行業
- 一個三年工作經驗的Web工程師的經驗之談Web工程師
- 遊戲與現實的經濟——閒談氪金與服務(一)遊戲
- 扎心!一個3年經驗的程式設計師經驗之談!程式設計師
- 資料庫的日常管理經驗淺談資料庫
- 提高隨身碟速度的經驗之談
- 需求編寫的幾點經驗之談
- (ZT)30歲女人的經驗之談(美容)。
- robbin談管理:改造團隊的經驗(1)
- robbin談管理:改造團隊的經驗(2)