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

我们如何在 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 频道。