本文发布已超过一年。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不准确。

我们如何改进 Kubernetes Dashboard UI 1.4 以满足你的生产需求​

作者：Dan Romlein (Apprenda) |

随着上周 Kubernetes 1.4 的发布，Kubernetes 的官方 Web UI - Dashboard 也迎来了一系列令人兴奋的更新和改进。过去三个月对于 Dashboard 团队来说是忙碌的，我们很高兴在这里分享这些努力的成果。如果你还不熟悉 Dashboard，GitHub 仓库 是一个很好的入门资源。

在介绍我们的全新特性之前，快速回顾一下：Dashboard 于 2016 年 3 月首次发布。Dashboard 一直以来的重点之一是用户入门体验；对于 Kubernetes 新手来说，它是一种不那么令人望而生畏的入门方式，并且通过一次性显示多个资源，它提供了 kubectl（命令行工具）所缺乏的上下文信息。然而，在首次发布后，产品团队意识到为新手用户进行微调有些超前了：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 无关的全局对象，如 Namespaces、Nodes 和 Persistent Volumes。随着角色的添加，这些将仅显示给集群操作员，开发者的侧边导航栏将从 Namespace 下拉菜单开始。

就像胶水将一叠散落的纸张装订成书一样，我们需要一种方法来对这些资源进行排序，以实现它们的价值，因此，我们在 1.4 中最令人兴奋的功能之一就是导航。

导航
在 1.1 版本中，所有资源都简单地堆叠在单个页面上。侧边导航栏的引入提供了快速访问集群任何方面的途径。要实现这个解决方案，我们花费了大量时间思考 Kubernetes 对象的层级结构——这是一项艰巨的任务，因为从设计上来说，事物之间的关系更像是一个有机体，而不是一组嵌套的线性关系。我们最终找到的解决方案平衡了组织上的分组需求和尽可能保留相关信息的鸟瞰图的愿望。侧边导航栏的设计简洁灵活，以便未来能容纳更多资源。其顶层对象（例如“工作负载”、“服务和发现”）会汇总其子对象的信息，最终将包含这些对象的聚合数据。

更紧密地对齐 Material Design
Dashboard 遵循 Google 的 Material Design 设计系统，这些原则在新 UI 中的实现得到了改进：全局创建选项从两个选择减少到一个初始的“创建”按钮，官方 Kubernetes 标志以 SVG 格式显示，而不是简单的文本，并引入了卡片来帮助更好地对不同类型的内容进行分组（例如，在“工作负载”页面上显示 Replication Controller 表格和 Pod 表格）。Material Design 目前在面向桌面企业级软件的指导方针方面存在局限（更多侧重于移动优先的场景），因此我们在 UI 的某些方面不得不进行即兴创作，并与 Google Cloud Platform 的 UX 团队密切合作完成此项工作——借鉴他们在更信息密集的环境中实现 Material Design 的专业知识。

示例用例
为了展示 Dashboard 1.4 的全新功能集及其如何在现实世界中改善用户体验，让我们设想以下场景：

我是一名集群操作员，一位客户给我发消息，警告他们的应用程序 Kubernetes Dashboard 遇到了性能问题。我解决问题的第一个步骤是切换到正确的 Namespace，即 kube-system，以检查可能发生的情况。

进入相关的 Namespace 后，我查看了我的 Deployments，看看是否有异常。果然，我注意到 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 频道。