本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

我們如何在 1.4 中改進 Kubernetes 儀表板 UI 以滿足您的生產需求

作者：Dan Romlein (Apprenda) | 2016 年 10 月 3 日星期一

隨著上週 Kubernetes 1.4 的發布，Dashboard – Kubernetes 的官方 Web UI – 本身也有許多令人興奮的更新和改進。過去三個月對於 Dashboard 團隊來說是很忙碌的，我們很高興在這裡分享這項努力的成果功能。如果您不熟悉 Dashboard，GitHub 儲存庫是入門的好地方。

在拆開我們閃亮的新功能之前，先快速回顧一下：Dashboard 最初於 2016 年 3 月發布。Dashboard 在整個生命週期中的重點之一是入門體驗；對於 Kubernetes 新手來說，這是一種不那麼令人生畏的入門方式，並且透過一次顯示多個資源，它提供了 kubectl (CLI) 中缺乏的脈絡化。然而，在最初發布之後，產品團隊意識到，為初學者受眾進行微調已經超前了：Dashboard 仍然需要滿足基本產品要求，才能擁有富有成效的 UX 來讓新使用者入門。這成為我們此版本的任務：透過顯示更多資源、利用 Web UI 在監控和故障排除方面的優勢，以及以使用者友善的方式架構所有這些，來縮小 Dashboard 和 kubectl 之間的差距。

監控圖表
即時視覺化是 UI 相較於 CLI 的優勢，在 1.4 中，我們很高興能利用此功能，為叢集上運行的所有工作負載引入即時 CPU 和記憶體使用率圖表。即使有眾多第三方監控解決方案，Dashboard 也應至少在此領域包含一些基本的開箱即用功能。圖表路線圖上的下一步是擴展圖表表示的時間跨度、新增向下鑽取功能以顯示更多詳細資訊，以及改進關聯不同圖表之間資料的 UX。

日誌
根據對 Kubernetes 前身 Borg 的使用者研究以及持續的社群回饋，我們知道日誌對使用者非常重要。因此，我們不斷尋找在 Dashboard 中改進這些功能的方法。此版本包含修復大量日誌會導致系統崩潰的問題，以及引入按日期查看日誌的功能。

顯示更多資源
先前的版本將所有工作負載都帶到了 Dashboard：Pod、Pet Set、Daemon Set、複寫控制器、複本集、服務和部署。在 1.4 中，我們透過包含服務、Ingress、持久卷宣告、密碼和 ConfigMap 來擴展該物件集。我們還引入了一個「管理員」部分，其中包含命名空間獨立的全局物件：命名空間、節點和持久卷。隨著角色的新增，這些物件將僅向叢集運營商顯示，而開發人員的側邊導航將從命名空間下拉選單開始。

就像膠水將鬆散的一疊紙張裝訂成一本書一樣，我們需要某種方法來對這些資源施加秩序，才能實現其價值，因此我們在 1.4 中最興奮地宣布的功能之一是導航。

導航
在 1.1 中，所有資源都簡單地堆疊在單個頁面上。側邊導航的引入提供了對您想要查看的叢集任何方面的快速存取。達成此解決方案意味著花費大量時間思考 Kubernetes 物件的層次結構 – 這是一項艱鉅的任務，因為從設計上來說，事物的組合更像是生物體，而不是線性關係的巢狀集合。我們達成的解決方案平衡了分組的組織需求和保留盡可能多相關資訊的鳥瞰圖的願望。側邊導航的設計簡單而靈活，以便在未來容納更多資源。其頂層物件（例如「工作負載」、「服務和探索」）會彙總其子物件，最終將包含所述物件的彙總資料。

更貼近 Material Design
Dashboard 遵循 Google 的 Material Design 系統，並且在新 UI 中改進了這些原則的實作：全局建立選項已從兩個選項減少為一個初始「建立」按鈕，官方 Kubernetes 標誌顯示為 SVG 而不是簡單的文字，並且引入了卡片以幫助更好地將不同類型的內容分組（例如，「工作負載」頁面上的複寫控制器表和 Pod 表）。Material 關於以桌面為中心的企業級軟體的指南目前受到限制（而是關注行動優先的環境），因此我們不得不在 UI 的某些方面進行即興創作，並與 Google Cloud Platform 的 UX 團隊密切合作來做到這一點 – 借鑒他們在資訊密集型環境中實作 Material 的專業知識。

範例使用案例
為了展示 Dashboard 1.4 的新功能套件以及它們如何在現實世界中讓使用者的生活更美好，讓我們想像以下情境

我是一名叢集運營商，一位客戶 ping 我，警告我他們的應用程式 Kubernetes Dashboard 遇到效能問題。我解決問題的第一步是切換到正確的命名空間 kube-system，以檢查可能發生的情況。