在這篇博文中，我們回顧了Kubernetes管理前端，并討論了這些工具是如何被構(gòu)建的。

譯自The Inner Workings of Kubernetes Management Frontends — A Software Engineer’s Perspective，作者是 Christoph Enne 。

近年來Kubernetes的興起導(dǎo)致了大量開源的Kubernetes管理工具貌似憑空出現(xiàn)。這篇文章背后的研究的目的僅僅是要理解這些工具的架構(gòu)，并且隨后為試圖開始自己的Kubernetes前端開發(fā)的開發(fā)者提供一個(gè)簡要的概述和選擇。我們不會(huì)深入探討這些工具本身以及它們?cè)噲D解決的問題，而是將重點(diǎn)放在軟件工程方面。我們還僅探索開源和自托管工具，不討論云提供商的PaaS/IaaS平臺(tái)——這將是一篇完全不同的文章。

搭建和與第一個(gè)集群進(jìn)行交互可能會(huì)令人不知所措。就像我一樣，你可能遇到了臭名昭著的kubernetes/dashboard，按照安裝說明進(jìn)行了安裝，并問自己："我剛才做了什么，為什么它的工作方式是這樣的?" 在對(duì)集群進(jìn)行一些調(diào)整之后，你可能還安裝了更多的外部工具來幫助你管理集群的某些具體方面，為你提供CLI或Web UI。

作為最近幾年主要從事Web開發(fā)的軟件工程師，我對(duì)這些工具是如何構(gòu)建和部署的感到好奇。

我們首先澄清一下接下來探索不同Kubernetes UI所需的一些基本知識(shí)。之后，我們將看到它們有什么共同之處，以及是什么使這種軟件如此特別，最后形成一個(gè)建議，說明如何自己構(gòu)建Kubernetes Web UI。

官方文檔在任何情況下都非常有幫助;只需要記住一件重要的事情:無論在何時(shí)何地與集群進(jìn)行交互，都是通過Kubernetes API進(jìn)行的 - 至少就本文的范圍而言是如此，盡管可能還有其他用例。

作為該API的消費(fèi)者，需要知道它托管在哪里以及如何對(duì)其進(jìn)行身份驗(yàn)證。Kubernetes API可以從集群內(nèi)部(即從運(yùn)行在pod上的應(yīng)用程序)和集群外部(例如從命令行)進(jìn)行訪問。但是，在某些情況下，API僅可從VPN內(nèi)訪問。

由于我們正在查看具有Web UI的工具，因此需要暴露該UI及其后端，以便用戶可以訪問它。選項(xiàng)是:

• 使用kubectl proxy打開從本地機(jī)器到集群的代理(參見 訪問集群)，
• 使用kubectl port-forward將本地端口轉(zhuǎn)發(fā)到集群的特定pod(參見 使用端口轉(zhuǎn)發(fā)訪問集群中的應(yīng)用程序)，
• 使用類型為LoadBalancer的Kubernetes服務(wù)來訪問集群的應(yīng)用程序(參見 使用服務(wù)訪問集群中的應(yīng)用程序)。

另外，Web服務(wù)器也可以在用戶的本地機(jī)器上運(yùn)行，在這種情況下就不需要擔(dān)心這些選項(xiàng)。但是，對(duì)于這些方法的任何一種方法都需要在用戶的機(jī)器上有一個(gè)有效的kube配置。

管理前端

現(xiàn)在，讓我們看一下一些常用的前端以及它們是如何構(gòu)建的。

kubernetes-dashboard

Kubernetes Dashboard是一個(gè)流行的Web UI，用于查看和管理集群中的各種Kubernetes資源。在最新穩(wěn)定版本2.7中，后端和前端都是同一個(gè)容器的一部分。Go后端同時(shí)為API和Angular UI資產(chǎn)提供服務(wù)。這種部署策略要求用戶使用kubectl proxy來訪問Web應(yīng)用程序。

在新的3.0版本中，它仍處于alpha階段，部署策略已更改: 后端和前端每個(gè)都在專用的容器中運(yùn)行。因此，通過kubectl proxy訪問它不再起作用，因?yàn)閁I需要訪問在不同pod和端口上運(yùn)行的后端。應(yīng)改用此處描述的端口轉(zhuǎn)發(fā)方法。

ArgoCD

ArgoCD是一個(gè)Kubernetes的GitOps持續(xù)交付工具。它包含幾個(gè)組件，包括自己的API服務(wù)器和Web UI。所有后端組件都是用Go編寫的，UI是一個(gè)React應(yīng)用程序。

與Kubernetes Dashboard一樣，服務(wù)器(包括UI資產(chǎn))部署在集群內(nèi)部，這使得用戶需要執(zhí)行端口轉(zhuǎn)發(fā)或使用LoadBalancer。這在他們的文檔中有描述。

Lens

Lens是一個(gè)桌面UI，但對(duì)我們的探索仍很有趣。它使用Electron、React和Typescript開發(fā)。Lens App使用Typescript Kubernetes客戶端連接到集群，由于桌面應(yīng)用程序顯然在集群外運(yùn)行，它使用本地提供的kubeconfig與其連接。

glasskube

是的，一個(gè)相當(dāng)厚顏無恥的插播廣告(我在那里工作)，但它也是一個(gè)有趣的替代方案。對(duì)于Glasskube軟件包管理器的UI，我們通過CLI命令在本地啟動(dòng)Web服務(wù)器，并從那里提供UI資產(chǎn)。我們決定采用這種方式，因?yàn)樵谖覀兊氖褂冒咐?，這更有意義。每當(dāng)用戶需要Glasskube UI時(shí)，他們會(huì)根據(jù)需要托管它，可以長期或者短期 - 不需要24/7在集群內(nèi)運(yùn)行它。

發(fā)現(xiàn)

許多開源Kubernetes管理UI的編碼方式類似 —— 使用強(qiáng)大的Kubernetes-go客戶端的Go后端，以及JavaScript中的單頁面應(yīng)用程序作為前端。在大多數(shù)情況下，Web資源(例如JS文件)與后端一起提供服務(wù)，這意味著一個(gè)容器同時(shí)為后端和前端提供服務(wù)。實(shí)際上很難找到不是這樣構(gòu)建的東西。

集群內(nèi)與集群外

當(dāng)涉及到部署這樣一個(gè)Web工具時(shí)，只有兩種選擇:

• Web服務(wù)器部署在集群內(nèi)的pod上，并且可以通過代理、端口轉(zhuǎn)發(fā)或ingress訪問。
• Web服務(wù)器部署在集群外部，直接(本地)部署在用戶的機(jī)器上。

Kubernetes客戶端(例如Go客戶端)支持開發(fā)人員這兩種方法來連接集群，正如我們?cè)谙旅娴睦又锌吹降摹?/p>

它所依賴的代碼段:

這些簡化的示例在很大程度上基于這里和這里看到的官方示例。

讓我們看一下在集群內(nèi)部運(yùn)行應(yīng)用程序時(shí)如何連接到Kubernetes API:

import (
  "context"


  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/client-go/kubernetes"
  "k8s.io/client-go/rest"
)


func main() {
  // retreive the config for the cluster we are currently in:
  config, err := rest.InClusterConfig()
  if err != nil {
    panic(err.Error())
  }


  // create the clientset for this config:
  clientset, err := kubernetes.NewForConfig(config)
  if err != nil {
    panic(err.Error())
  }


  // do something with the clientset, e.g. getting all pods in the cluster:
  // pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

Go客戶端實(shí)現(xiàn)使用pod的服務(wù)帳戶以及環(huán)境變量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT來識(shí)別它所在的集群。隨后，它創(chuàng)建REST配置對(duì)象，客戶端集可以通過該對(duì)象獲得。

同樣，在集群外部運(yùn)行時(shí)，需要?jiǎng)?chuàng)建配置對(duì)象，但此配置是從本地kube配置中讀取的:

import (
  "context"
  "flag"
  "path/filepath"


  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/client-go/kubernetes"
  "k8s.io/client-go/tools/clientcmd"
  "k8s.io/client-go/util/homedir"
)


func main() {
  // get the passed (or default) kube config file path
  var kubeconfig *string
  if home := homedir.HomeDir(); home != "" {
    kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file")
  } else {
    kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
  }
  flag.Parse()


  config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig)
  if err != nil {
    panic(err.Error())
  }


  clientset, err := kubernetes.NewForConfig(config)
  if err != nil {
    panic(err.Error())
  }


  // do something with the clientset, e.g. getting all pods in the cluster:
  // pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

同樣，Kubernetes Go客戶端為我們提供了一個(gè)簡單的函數(shù)來解析kubeconfig文件以獲取配置，然后可以用該配置創(chuàng)建一個(gè)clientset。

嘗試運(yùn)行這些簡單的示例時(shí)，您還會(huì)遇到這兩種方法之間的一個(gè)區(qū)別: 運(yùn)行本地工具更容易，因?yàn)槟恍枰獦?gòu)建映像、將其推送到注冊(cè)表，然后將其拉入集群。

選擇哪一個(gè)?

假設(shè)您要以類似的方式構(gòu)建自己的Kubernetes UI。當(dāng)涉及到您的工具的Web服務(wù)器應(yīng)該在哪里運(yùn)行的決定時(shí)，有幾件事需要考慮:

• 分發(fā): 在集群內(nèi)部運(yùn)行您的工具意味著您必須構(gòu)建和分發(fā)docker鏡像。相反，如果您希望用戶在其機(jī)器上安裝它，則必須分發(fā)本機(jī)二進(jìn)制文件。對(duì)于這兩種情況，網(wǎng)上都有大量的工具和資源。
• 可用性: 當(dāng)您的集群由于某種原因關(guān)閉時(shí)，用戶可能無法訪問托管在集群內(nèi)部的工具。這帶我們來到下一個(gè)要點(diǎn):
• 用戶入門體驗(yàn): 這可能是一個(gè)邊緣用例，但本地托管的web工具可以在其所有組件安裝在集群之前使用。這意味著您可以為新用戶實(shí)現(xiàn)某種UI入門流程，使該工具更易于安裝和設(shè)置。
• 兼容性: 同一集群的多個(gè)用戶可能安裝了不同版本的您的(本地托管)工具。如果集群內(nèi)只運(yùn)行一個(gè)web服務(wù)器，則無法發(fā)生這種情況。
• 持久性: 當(dāng)需要存儲(chǔ)工具特定的數(shù)據(jù)(即非Kubernetes資源)時(shí)，您可以將其存儲(chǔ)在集群內(nèi)(例如在ConfigMap中)。對(duì)于本地部署的變量，您還可以在用戶的機(jī)器上存儲(chǔ)用戶特定的數(shù)據(jù)，如設(shè)置。這個(gè)決定在很大程度上取決于用例。
• 開發(fā)人員體驗(yàn): 似乎沒有明顯的區(qū)別，但值得注意的是，在開發(fā)集群內(nèi)web服務(wù)器時(shí)，在開發(fā)期間，這個(gè)服務(wù)器仍然需要以某種方式支持集群外配置方法。否則，每次更改后都必須構(gòu)建和部署鏡像到集群中。

最終，工具是部署在集群內(nèi)部還是外部完全取決于您，但始終要考慮用例并意識(shí)到使用它的上下文非常重要。您也可以選擇為用戶提供這兩種選項(xiàng)。

對(duì)于我們?cè)贕lasskube，很明顯我們希望為新用戶(特別是那些剛接觸Kubernetes世界的用戶)提供一個(gè)易于使用的界面，他們可能還沒有設(shè)置所有Glasskube集群組件。通過提供托管本地Web服務(wù)器的CLI命令和支持性Web UI，可以支持這些用戶。

總結(jié)

在本文中，我們探索了一些提供Web UI的Kubernetes工具，并從軟件工程師的角度分析了這些工具的Web方面。顯然沒有一刀切的解決方案來設(shè)計(jì)和開發(fā)這樣的工具，但以上列表希望能給出正確方向的提示。像軟件工程中的任何事情一樣:這取決于。

最后一個(gè)插播: 我在Glasskube工作，我們正在構(gòu)建缺失的Kubernetes包管理器。如果您對(duì)我們的工作感興趣，請(qǐng)務(wù)必給我們加星:glasskube/glasskube。我們也在研究一篇文章，關(guān)于不同CLI框架的比較，如果您更偏向命令行。如果這還不夠，我們可能很快會(huì)寫關(guān)于使用htmx的文章，因?yàn)樗诹餍校覀冃枰年P(guān)注。我已經(jīng)能看到標(biāo)題了:"我們?nèi)绾瓮ㄟ^使用看似老派的技術(shù)來減少95%的代碼庫" —— 我認(rèn)為這以前沒有做過;)