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

我們如何在 1.4 版中改進 Kubernetes Dashboard 使用者介面以滿足您的生產需求

作者：Dan Romlein (Apprenda) |

上週隨著 Kubernetes 1.4 的釋出，Dashboard——Kubernetes 的官方 Web UI——也有了一些令人興奮的更新和改進。在過去的三個月裡，Dashboard 團隊一直很忙碌，我們很高興在這裡分享這些努力所帶來的功能。如果您不熟悉 Dashboard，GitHub 倉庫是一個很好的入門之地。

在介紹我們閃亮的新功能之前，先快速回顧一下：Dashboard 最初於 2016 年 3 月釋出。Dashboard 在其整個生命週期中一直關注的焦點之一是入門體驗；它為 Kubernetes 新手提供了一種不那麼令人生畏的入門方式，透過同時顯示多個資源，它提供了 kubectl (CLI) 中缺乏的上下文。然而，在最初發布之後，產品團隊意識到，為初學者受眾進行微調有點超前了：Dashboard 仍然需要滿足一些基本的產品要求，才能擁有高效的使用者體驗來引導新使用者。這成為了我們此次釋出的目標：透過顯示更多資源、利用 Web UI 在監控和故障排除方面的優勢，並以使用者友好的方式構建所有這些，來彌合 Dashboard 和 kubectl 之間的差距。

監控圖表
即時視覺化是 UI 相對於 CLI 的優勢，在 1.4 中，我們很高興利用這一能力，引入了叢集上所有工作負載的即時 CPU 和記憶體使用圖表。即使有眾多的第三方監控解決方案，Dashboard 至少也應該包含一些基本的開箱即用功能。圖表的下一步路線圖是擴充套件圖表所代表的時間跨度，新增向下鑽取功能以顯示更多細節，並改進關聯不同圖表資料時的使用者體驗。

日誌
根據對 Kubernetes 前身 Borg 的使用者研究和持續的社群反饋，我們知道日誌對使用者來說非常重要。因此，我們一直在尋找改進 Dashboard 中這些功能的方法。此版本修復了大量日誌導致系統崩潰的問題，並引入了按日期檢視日誌的功能。

顯示更多資源
上一個版本將所有工作負載帶到了 Dashboard：Pods、Pet Sets、Daemon Sets、Replication Controllers、Replica Set、Services 和 Deployments。在 1.4 中，我們透過包含 Services、Ingresses、Persistent Volume Claims、Secrets 和 ConfigMaps 來擴充套件這組物件。我們還引入了一個“Admin”部分，其中包含 Namespace-independent 的全域性物件：Namespaces、Nodes 和 Persistent Volumes。隨著角色的新增，這些將僅顯示給叢集操作員，開發人員的側邊導航將以 Namespace 下拉列表開頭。

就像將一堆散亂的紙張裝訂成一本書一樣，我們需要某種方式來對這些資源施加秩序，以實現它們的價值，因此我們在 1.4 中最激動人心的新功能之一就是導航。

導航
在 1.1 版本中，所有資源都簡單地堆疊在一個頁面上。引入側邊導航提供了對叢集任何方面快速訪問的功能。實現這一解決方案需要花費大量時間思考 Kubernetes 物件的層次結構——這是一項艱鉅的任務，因為從設計上講，事物更像一個活生生的有機體，而不是一組巢狀的線性關係。我們所達成的解決方案平衡了分組的組織需求和儘可能多地保留相關資訊的鳥瞰圖的願望。側邊導航的設計簡潔靈活，以便將來容納更多資源。其頂級物件（例如“工作負載”、“服務與發現”）會捲起其子物件，並最終將包含所述物件的聚合資料。

更緊密地與 Material Design 對齊
Dashboard 遵循 Google 的 Material design 系統，在新 UI 中對這些原則的實現得到了改進：全域性建立選項從兩個選擇減少到一個初始的“建立”按鈕，官方 Kubernetes 徽標以 SVG 而不是簡單的文字形式顯示，並引入了卡片以更好地對不同型別的內容進行分組（例如，在“工作負載”頁面上顯示覆制控制器表格和 Pods 表格）。Material 關於以桌面為中心的企業級軟體的指南目前是有限的（並且更多地關注移動優先的上下文），因此我們不得不即興處理 UI 的某些方面，並與 Google Cloud Platform 的 UX 團隊密切合作，利用他們在資訊密集型環境中實施 Material 的專業知識。

示例用例
為了展示 Dashboard 1.4 的新功能套件以及它們將如何改善使用者在現實生活中的體驗，讓我們設想以下場景：

我是一名叢集操作員，一位客戶向我發出警告，他們的應用 Kubernetes Dashboard 正在遭遇效能問題。我解決問題的第一步是切換到正確的名稱空間 kube-system，以檢查可能發生的情況。

進入相關名稱空間後，我檢查我的 Deployment，看是否有異常。果然，我注意到 CPU 使用率飆升。

我意識到我們需要對該應用進行滾動更新到新版本，以便處理明顯增加的請求，因此我更新了此 Deployment 的映象，這反過來又建立了一個新的 Replica Set。

現在 Replica Set 已建立，我可以開啟其中一個 pod 的日誌以確認它已成功連線到 API 伺服器。

就這樣，我們解決了問題。Dashboard 為我們提供了一個集中位置來掃描問題的來源，一旦確定了問題，我們就可以深入查詢並解決問題的根源。

為什麼跳過了版本？
如果您一直關注 Dashboard，從 1.0 版本開始，您可能會對我們版本號的跳躍感到困惑；我們從 1.0、1.1……跳到了 1.4。我們這樣做是為了與主要的 Kubernetes 發行版同步，希望將來這能使這種關係更容易理解。

還有更多精彩內容
Dashboard 正在蓄勢待發，早期階段是一個非常令人興奮和有意義的參與時期。如果您想了解更多關於貢獻的資訊，請檢視 SIG UI。在 Kubernetes Slack 與我們聊天：#sig-ui 頻道。