Rancher 2.5特性解讀丨更簡單友好的API和Dashboard

RancherLabs發表於2020-10-29

本文來自Rancher Labs

關注我們,看K8S乾貨教程

 

作者簡介

張智博,Rancher中國研發與產品總監。7年雲端計算領域經驗,一直活躍在研發一線,經歷了OpenStack到Kubernetes的技術變革,無論底層作業系統Linux,還是虛擬化KVM或是Docker容器技術都有豐富的研發和實踐經驗。

自Rancher 2.0系列版本問世,以其簡單務實的UI風格和成熟穩健的後端架構贏得了市場的普遍青睞。Kubernetes本身架構和功能逐漸穩定,同時擁有豐富經驗的Kubernetes技術人員也在不斷增加,根據市場出現的這些新變化,我們近期釋出的Rancher 2.5對此做出了諸多改變。本文將從API和Dashboard兩個角度來探討Rancher 2.5的變化。

Kubernetes Native API

Rancher 2.5之前的版本中,我們對原生的Kubernetes API做了一些封裝,以便適應我們的UI展示需求。這些封裝的好處就是,我們可以定義適用自身的資料結構,並且提供了一套可以單獨互動的API-UI,使用者可以使用它來模擬呼叫API。通常在Rancher UI的很多入口中,點選“View API”或者在瀏覽器中訪問“https:///v3”即可檢視訪問。這些API本身基於Kubernetes CRD實現,封裝後形成了Rancher風格API。至於如何定義Rancher風格API,可以訪問此連結檢視:

https://github.com/rancher/api-spec

當然,這種做法的劣勢顯而易見,從Rancher工程師和社群使用者的使用經驗看,主要有以下幾點:

  1. 擴充套件Rancher API非常複雜,只有深入閱讀Rancher程式碼或者接受了一定培訓的開發人員才能做到。

  2. Kubernetes API在不斷演變,Rancher API去相容多個版本的Kubernetes API變得越來越困難。

  3. Rancher API遮蔽了一些高階API引數,對於一些高階使用者,這非常不友好。

對於這些問題,我們在Rancher 2.4已經開始嘗試做一些改變,細心的小夥伴可能發現了Rancher 2.4的新型Dashboard,它背後使用的就是新風格的Rancher API。這套API的實現依靠一個相對獨立的元件steve,為了解決之前的API問題,steve做了以下改善工作:

  • 完全沿用Rancher的API-UI模式,不破壞使用者的使用習慣。

  • 相容Kubernetes Native API,包括原生物件和CRD,最大程度保留其資料欄位。

  • 擴充套件API非常簡單,只要向Kubernetes註冊了CRD,steve通過內建controller來watch CRD資源變化,將其熱裝載加入steve API中。

Steve是一個較為獨立的元件,即使離開Rancher也依然能夠獨立執行。如果想要在二次開發Kubernetes,但是覺得原生API不友善,完全可以在上面啟用Steve風格的API。筆者做了一個小實驗,部署k3s並獨立安裝steve,可以非常方便得到一個友好的API。

k3s安裝過程較為簡單直接略過,steve的編譯直接參考Makefile/Dockerfile即可。成功編譯後,會在本地生成一個steve:latest的映象,然後使用docker run -itd --net=host -v ${HOME}/.kube:/root/.kube steve:latest啟動steve,我們就能夠獲得一個Kubernetes Native的Rancher API。訪問“https://:9443/v1”可以檢視效果:

Kubernetes Native Dashboard

如今Kubernetes生態中,可接入的擴充套件元件越來越多,往往我們會在Kubernetes中安裝Prometheus、Istio、ArgoCD等各種程式,這些程式基本都會通過CRD來增強自己的服務能力。這就導致了叢集中存在大量的CRD,並且越來越難以管理,於是很多經驗豐富的高階技術人員開始期望CRD的視覺化管理,以避免Kubectl CLI操作的繁瑣。從這個需求出發,Rancher 2.5中整合的新Dashboard也更加Kubernetes Native化。

這一切都源於Steve API的能力,可以讓我們非常方便地間接使用Kubernetes API。在Rancher 2.4中,我們已經提供了這個功能的實驗版,相信很多使用者都已經試用。在Rancher 2.5中,這部分功能將會正式提供,這對於管理單個Kubernetes叢集的高階技術人員將會非常友好。

新的Dashboard可以對Kubernetes原生資源和CRD擴充套件資源都進行視覺化管理,在諸如Kubernetes原生資源的建立等表單上也會提供全面的引數設定,比Rancher 2.4時代的實驗性Dashboard更加成熟。整體的頁面風格也更加傾向簡潔,對於熟練使用Kubernetes的開發的人員會非常方便,同時也採用了Vue框架編寫,這對於國內使用者做二次開發也是一個大利好。

上手體驗Rancher 2.5

在Rancher 2.5中可以繼續使用docker run方式試用體驗,與先前不同的是需要增加privileged引數

$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher:v2.5.1

啟動完成後,首次進入登入頁,除了配置初始化密碼外,還要設定預設檢視。兩個檢視分別是:多叢集管理和單叢集管理,前者沿用Rancher2.4 UI並做增強,後者就是前文介紹的Kubernetes Native Dashboard。對於Native Dashboard,由於啟動時增加了privileged提權引數,所以可以在容器中啟動一個完整的local叢集,原先docker run方式只能啟動的是kube-api,並非一個完整叢集,現在通過新的Dashboard則可以完整管理它,在local叢集上新建workload,當然我們相信你只會在開發測試時如此使用。

總的來說,期望單一叢集管理的使用者,相比之前會節省很多部署資源。而期望使用多叢集管理的使用者,Rancher 2.5依然會保留訪問入口,同時多叢集管理的核心功能也將會有重大的提升,Rancher 2.5整體架構也更加靈活,將會非常方便使用者進行模組化的擴充套件,這些內容我們在後續的文章中逐步交流。

相關文章