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

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

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

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

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

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

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

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

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

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

另外，Web服務器也可以在用戶的本地機器上運行，在這種情況下就不需要擔心這些選項。但是，對于這些方法的任何一種方法都需要在用戶的機器上有一個有效的kube配置。

管理前端

現在，讓我們看一下一些常用的前端以及它們是如何構建的。

kubernetes-dashboard

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

在新的3.0版本中，它仍處于alpha階段，部署策略已更改: 后端和前端每個都在專用的容器中運行。因此，通過kubectl proxy訪問它不再起作用，因為UI需要訪問在不同pod和端口上運行的后端。應改用此處描述的端口轉發方法。

ArgoCD

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

與Kubernetes Dashboard一樣，服務器(包括UI資產)部署在集群內部，這使得用戶需要執行端口轉發或使用LoadBalancer。這在他們的文檔中有描述。

Lens

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

glasskube

是的，一個相當厚顏無恥的插播廣告(我在那里工作)，但它也是一個有趣的替代方案。對于Glasskube軟件包管理器的UI，我們通過CLI命令在本地啟動Web服務器，并從那里提供UI資產。我們決定采用這種方式，因為在我們的使用案例中，這更有意義。每當用戶需要Glasskube UI時，他們會根據需要托管它，可以長期或者短期 - 不需要24/7在集群內運行它。

發現

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

集群內與集群外

當涉及到部署這樣一個Web工具時，只有兩種選擇:

• Web服務器部署在集群內的pod上，并且可以通過代理、端口轉發或ingress訪問。
• Web服務器部署在集群外部，直接(本地)部署在用戶的機器上。

Kubernetes客戶端(例如Go客戶端)支持開發人員這兩種方法來連接集群，正如我們在下面的例子中看到的。

它所依賴的代碼段:

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

讓我們看一下在集群內部運行應用程序時如何連接到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客戶端實現使用pod的服務帳戶以及環境變量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT來識別它所在的集群。隨后，它創建REST配置對象，客戶端集可以通過該對象獲得。

同樣，在集群外部運行時，需要創建配置對象，但此配置是從本地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客戶端為我們提供了一個簡單的函數來解析kubeconfig文件以獲取配置，然后可以用該配置創建一個clientset。

嘗試運行這些簡單的示例時，您還會遇到這兩種方法之間的一個區別: 運行本地工具更容易，因為您不需要構建映像、將其推送到注冊表，然后將其拉入集群。

選擇哪一個?

假設您要以類似的方式構建自己的Kubernetes UI。當涉及到您的工具的Web服務器應該在哪里運行的決定時，有幾件事需要考慮:

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

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

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

總結

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

最后一個插播: 我在Glasskube工作，我們正在構建缺失的Kubernetes包管理器。如果您對我們的工作感興趣，請務必給我們加星:glasskube/glasskube。我們也在研究一篇文章，關于不同CLI框架的比較，如果您更偏向命令行。如果這還不夠，我們可能很快會寫關于使用htmx的文章，因為它正在流行，我們需要您的關注。我已經能看到標題了:"我們如何通過使用看似老派的技術來減少95%的代碼庫" —— 我認為這以前沒有做過;)