本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已失效。

我们如何在 1.4 中改进 Kubernetes 仪表板 UI 以满足您的生产需求

作者：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：Pod、Pet Set、Daemon Set、Replication Controller、Replica Set、Service 和 Deployment。在 1.4 版本中，我们通过包含 Service、Ingress、Persistent Volume Claim、Secret 和 ConfigMap 来扩展这组对象。我们还引入了一个“管理”部分，其中包含 Namespace 独立的全局对象，例如 Namespace、Node 和 Persistent Volume。通过添加角色，这些将仅向集群操作员显示，开发人员的侧边导航将从 Namespace 下拉列表开始。

就像将一堆松散的纸张装订成书一样，我们需要某种方式来对这些资源进行排序，以实现它们的价值，因此我们在 1.4 中最兴奋地宣布的功能之一就是导航。

导航
在 1.1 版本中，所有资源都只是堆叠在单个页面上。引入侧边导航可以快速访问您想要查看的集群的任何方面。为了找到这个解决方案，我们花了很多时间思考 Kubernetes 对象的层次结构，这是一个困难的任务，因为按照设计，事物更像是像生物体一样相互配合，而不是线性关系的嵌套集合。我们找到的解决方案平衡了分组的组织需求和尽可能保留相关信息概览的愿望。侧边导航的设计简单而灵活，以便在未来容纳更多资源。其顶级对象（例如“工作负载”、“服务和发现”）会汇总其子对象，最终将包括所述对象的聚合数据。

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

示例用例
为了展示 Dashboard 1.4 的新功能套件及其如何改善用户在现实世界中的生活，让我们想象以下场景

我是一名集群操作员，一位客户 ping 我，警告说他们的应用程序 Kubernetes Dashboard 正在遭受性能问题。我解决问题的第一步是切换到正确的 Namespace kube-system，以检查可能发生的情况。

进入相关的 Namespace 后，我检查我的 Deployment，看看是否有什么不对劲。果然，我注意到 CPU 使用率出现了峰值。

我意识到我们需要对该应用程序执行滚动更新到可以处理明显增加的请求的较新版本，因此我更新了此 Deployment 的镜像，这反过来又创建了一个新的 Replica Set。

现在已经创建了 Replica Set，我可以打开其中一个 Pod 的日志，以确认它已成功连接到 API 服务器。

就像这样简单，我们已经调试了我们的问题。Dashboard 为我们提供了一个中心位置来扫描问题的根源，一旦我们确定了问题，我们就可以深入挖掘并解决问题的根源。

为什么跳过了版本？
如果您自 1.0 版本以来一直关注 Dashboard，您可能会对我们版本控制中的跳跃感到困惑；我们从 1.0、1.1...到 1.4。我们这样做是为了与主要的 Kubernetes 发行版同步，希望将来这将使这种关系更容易理解。

还有更多来自这里
Dashboard 正在获得发展势头，这些早期阶段是非常令人兴奋和有益的参与时期。如果您想了解有关贡献的更多信息，请查看 SIG UI。在 Kubernetes Slack 上与我们聊天：#sig-ui 频道。