Kubernetes Dashboard 2015 初始 MVP 设计原型全解析从 Sketch 草图到源码落地【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址: https://gitcode.com/gh_mirrors/da/dashboard本篇技术指南以 docs/design/mockups/11-11-2015-initial/README.md 中记录的 23 张初始设计幻灯片为核心骨架系统还原 2015 年 11 月 Kubernetes Dashboard即当前仓库gh_mirrors/da/dashboard的前身首个 MVP 版本的界面设计意图——包括零状态引导、两种部署应用方式、命名空间与镜像拉取密钥、应用卡片列表、事件排查与日志查看等。读者不仅能理解为什么今天 Dashboard 长这样还能通过对照 modules/web 与 modules/api 中的源码实现验证当年设计决策如何在现代 Angular Go 架构中一一落地。背景一份面向 Kubernetes UI SIG 的 MVP 设计稿该目录是 Dashboard 设计原型归档中时间最早的一份docs/design/mockups/README.md 说明该目录按版本归档各期 mockup。目录下的 README.md 本质是一份幻灯片的索引清单同时提供原始可编辑设计源文件Sketch 源文件kubernetes-dashboard.sketch设计师可直接打开继续编辑23 张导出 PNG从标题页到 MVP 遗留问题清单按演示顺序编号01_title.png至23_tbd for mvp.png。其中02_notes.png明确了这份设计的性质与时间线These are current designs for the initial MVP version of the Kubernetes Dashboard. The designs were presented to the Kubernetes UI SIG on Nov 9, 2015.也就是说这是 2015 年 11 月 9 日提交给 Kubernetes UI SIG 评审的初始 MVP 方案标题页日期标注为 November 9, 2015而目录名11-11-2015记录了归档日期。这 23 张图覆盖了 Dashboard 的第一个用户旅程欢迎引导 → 部署应用 → 查看应用列表 → 详情排查 → 查看日志这一流程骨架至今仍能在仓库代码中辨认出来。第一印象顶部导航与零状态引导页01_title.png与02_notes.png是演示用的封面与说明页从03_welcome - zero state.png开始进入真正的产品界面。这张零状态页奠定了 Dashboard 的整体视觉骨架顶部是一条深蓝色导航栏左侧为 Kubernetes Logo 与当前集群名cluster-1主区域左侧是一张引导卡片文案为 The Kubernetes Dashboard lets you deploy, monitor and troubleshoot containerized apps and services配一个醒目的DEPLOY AN APP主按钮右侧是一张 Learn more 卡片提供Dashboard Tour / Deploying your App / Monitoring your App / Troubleshooting四个学习入口。零状态Zero State设计是 MVP 中非常关键的产品决策空集群没有可展示的资源此时引导用户完成第一个动作部署应用比展示空表格更有价值。这一理念延续至今仓库中的通用零状态组件 kd-list-zero-state 以及 overview 页面组件 都体现了无数据时给引导的思路。部署应用MVP 的核心交互04–14 号幻灯片部署应用是整个 MVP 中占比最大的模块04–14 号共 11 张也是与当前源码对应关系最清晰的部分。如今的前端实现在 modules/web/src/create/from/form/template.html表单与 modules/web/src/create/from/file/template.html文件上传中后端实现在 modules/api/pkg/resource/deployment/deploy.go。两种部署方式表单填写 与 上传 YAML/JSON04_deploy form upload.png与08_deploy form.png展示了部署对话框顶部的两个互斥选项radioSpecify app details below手动填写应用信息Upload a YAML or JSON file上传一个 YAML/JSON 清单文件由系统解析后创建资源。后者在源码中的完整链路为前端 CreateService.createContent() 携带 CSRF Token 向api/v1/appdeploymentfromfile发起 POST后端 DeployAppFromFile() 使用yaml.NewYAMLOrJSONDecoder逐对象解码文件内容通过 Discovery API 判断资源类型apiResource.Kind kind且名称不含/再用dynamic client创建任意类型的资源当请求的 namespace 为_all时会改用清单内自带的目标命名空间deploy.go。文件上传模式天然支持 Deployment、Service、CRD 等任意 Kubernetes 资源这是表单模式做不到的。命名空间下拉选择 新建对话框05/06/07三张图演示了命名空间交互的完整闭环表单中的Namespace下拉默认值为defaulttooltip 说明 Partition resources into logical groups下拉里提供Create a new namespace入口弹出 Create a new namespace 对话框副标题提示 The namespace will be added to cluster-1输入名称后点 OK创建成功后07号图显示下拉框已切换为新建的production命名空间。这段交互的现代实现就在 modules/web/src/create/from/form/template.html下拉框 Create a new namespace... 选项与 component.ts 的 handleNamespaceDialog()打开 createnamespace/dialog.ts成功后把新命名空间 push 进列表并选中失败则回退到第一个命名空间。有趣的是2015 年原型中的 tooltip 文案 Namespaces let you partition resources into logically named groups 被原样保留在了今天的模板里template.html。表单字段设计与今天的对应关系08_deploy form.png给出了 MVP 表单的完整字段14_deploy more.png则展开 More options 展示高级选项。将原型字段与 modules/web/src/create/from/form/component.ts 中form的 FormControl 定义逐一对照可见设计几乎全部落地原型字段2015今日 FormControl / 组件说明App namenamekdUniqueName异步校验 FormValidators.namePattern原型 tooltip 说会为 Replica Set/Service 添加 app 标签今天实际是添加到 Deployment/Service且前端用APP_LABEL_KEY k8s-app自动生成标签component.tsContainer imagecontainerImagekdValidImageReference校验支持 Docker Hub / Google Container RegistryNumber of podsreplicasmin1、kdWarnThreshold100超过 100 时给出性能告警Port / Target port / ProtocolportMappingsportmappings 组件支持多组端口协议 TCP/UDPExpose service externallyisExternal布尔值决定 Service 类型Namespacenamespace见上文More options 中的各项description、labels、imagePullSecret、cpuRequirement、memoryRequirement、containerCommand、containerCommandArgs、runAsPrivileged、variables见下文以14_deploy more.png为例原型中的高级选项包括CPU requirement0.25 CPU/ Memory requirement250 MB、Run command、Run as privileged、Volumes、Secrets、环境变量外加自定义Labels。这些在今天全部实现CPU/内存请求会通过resource.Quantity写入容器Resources.RequestsRun as privileged映射到SecurityContext.Privileged环境变量经convertEnvVarsSpec()转换为[]api.EnvVardeploy.go。内存输入界面使用 MiB 单位组装 spec 时后端会拼上Mi后缀component.ts。私有镜像与 Image Pull Secret09–13 号这 5 张图集中打磨了一个细节场景当镜像来自私有仓库时需要提供凭据。09号镜像字段填入了hub.docker.com/lowrey/webserver:4.3右侧出现Image pull secret下拉placeholder Select a secret并带设计批注If using public repo, show autocomplete dropdown for easier typing、Vision: Hide Image pull secret if public; technical challenge requires toggle for public/private10号下拉展开列出cassandra-access、mysql-lowrey、mysql-root等已有 secret以及Upload a new image pull secret...入口11/12号弹出 Upload an image pull secret 对话框输入本地 YAML 文件路径如/Users/petelow/webserver/src/pull-secret.yaml上传13号选择dockerhub-lowrey后的最终表单状态。今天的前端依旧保留这一交互Image Pull Secret 下拉在点击时通过api/v1/secret/{namespace}拉取当前命名空间下所有 Secretcomponent.ts getSecrets()并提供 Create a new secret... 选项createsecret/dialog.ts后端 DeployApp() 在ImagePullSecret非空时写入podSpec.ImagePullSecrets []api.LocalObjectReference{{Name: *spec.ImagePullSecret}}。当年私有仓库才显示密钥的设想最终以始终可选、按需填写的方式落地。部署动作的后端语义DeployApp()deploy.go完整定义了点击 DEPLOY之后发生了什么先创建Deployment携带 labels、annotations、replicas、PodTemplate再根据是否有端口映射决定是否创建Service——有端口映射时IsExternal决定 Service 类型是LoadBalancer还是ClusterIP每个端口映射会生成一个不超过 63 字符、带随机后缀的端口名generatePortMappingName/generateName。这与原型端口映射是可选服务定义的定位完全一致。应用列表卡片化设计与 24 小时迷你图表15_apps list.png与16_card variations.png定义了 Dashboard 最具辨识度的元素——应用卡片每张卡片代表一组Replica Set Service以匹配的 label query 聚合包含状态行如 12 pods running、4 pods running, 2 pending后者带红色告警镜像与 Age如gcr.io/peng/_webapp:1.0.4、19 days端点Internal服务名与 ExternalIP:Port如211.18.44.141:80CPU / Memory 迷你折线图批注明确Mini graphs show 24 hours of dataLogs下拉入口16_card variations.png一张超长规格图枚举了卡片的各种边界状态全部 Pod 运行、无描述、有额外标签、无 Service 端点、Pod pending/调度失败红色警告、多个 Service 合并为一张卡、多个 Replica Set 拆分为多张卡、More 菜单与大下拉等。卡片中的迷你趋势图在今天的实现中对应 sparkline 组件 与 graph 组件而多 Service 共享一个 label selector 合并展示、不同查询拆分展示的聚合逻辑则沉淀在后端资源列表的聚合层与前端 resourcelist 系列组件 中。应用列表卡片聚合 RS/Service的模型后来演进为 Overview 页面的分组卡片视图modules/web/src/overview。应用详情、事件排查与扩容17–20 号17_job details.png展示了一个应用webapp的详情页其布局与后续所有资源详情页一脉相承左侧信息栏返回面包屑、ROLLING UPDATE与DELETE操作按钮、可编辑的 6 pods 计数、Label selectorappwebapp, version1.0.4、Replica Set 与 Service 的元数据与端点右侧主区域采用Pods / Events 双 TabPods 表格列Pod 名、Restarts含时间如 2 (4 min ago)、Age、CPU进度条、Memory进度条、IP、Node、Logs18_node hover.png鼠标悬停 Node 名gke-k2n9时显示完整节点名 tooltipgke-cluster-1-da3452-node-k2n9。19_events.png是事件排查页表格列几乎与今天的事件组件一一对应Type / Reason / Message / Source / Sub-object / Count / First seen / Last seen。现代实现在 resourcelist/event/component.tsgetDisplayColumns()返回statusicon, name, reason, message, source, count, firstSeen, lastSeen其中 Type 为Warning的事件会显示红色警告图标component.ts对应原型中 Killed for reason OutOfMemory 这类告警条目matSortActivelastSeen默认按最后出现时间排序template.html与原型中 First seen / Last seen 列的设计意图一致。20_change pod count.png演示了扩容交互点击可编辑的 pod 计数铅笔图标弹出Set desired number of pods对话框副标题说明 Replica set webapp will be updated to reflect the desired count。这在今天的实现中对应 scaleresource 对话框 与后端 modules/api/pkg/scaling/scale.go——从 2015 年原型到现代代码手动扩缩容始终是 Dashboard 的高频操作之一。日志查看器21–22 号21/22两张图展示了同一个全屏日志查看器区别仅在 Pod 启动时间不同说明是连续交互的两帧顶栏显示 Logs from pod webapp-7p1n 与 Running since 10-02-2015 06:14:36 PM提供Aa 字号调节按钮与Pod 选择下拉日志正文为带时间戳的逐行文本如I008 08:21:29.226156 20 pulls.go:551 Registered...。现代实现位于 modules/web/src/logs 目录标题同样以 Logs from 开头template.html下拉改为按Containers / Init Containers分组选择日志来源template.html——这恰好解决了 23 号幻灯片中 displaying multiple containers per pod 这个遗留问题。日志 API 侧由 modules/api/pkg/handler 与 modules/web/pkg/settings 提供参数化读取支持容器选择与时间范围控制。MVP 遗留问题清单23 号幻灯片最后一张23_tbd for mvp.png诚实记录了 MVP 发布前尚未解决的 6 项设计问题text pass with writers——文案需要专业写手润色details of autocomplete for image——镜像输入框的自动补全细节原型 09 号批注中已有 show autocomplete dropdown 的设想displaying multiple containers per pod——单 Pod 多容器的展示现已通过日志页的容器分组下拉解决case where Replica Set and Service names differ——RS 与 Service 命名不一致的场景17 号卡片假设两者标签一致proper control to stop a pod——停止 Pod 的明确控件include states and dismissable messages in app details page——详情页中的状态提示与可关闭消息。这份清单对研究 Dashboard 演进很有价值它划定了 MVP 的边界也预告了后续迭代的方向。对比今天的代码库第 3 项多容器与第 6 项可关闭通知见 notifications 组件 与 alert 对话框已经得到解决第 2 项的镜像自动补全、第 5 项的停止 Pod 控件则让位于更通用的资源管理能力如 Scale、Restart、Delete 等 ActionBar 操作见 actionbars 目录。从原型到现代架构一页设计的十年演变对照 2015 年原型与当前仓库可以清晰总结出 Dashboard 的设计连续性信息架构未变顶部集群导航 → 零状态/概览引导 → 部署表单/文件→ 列表 → 详情元数据 Pods/Events Tab→ 日志这一旅程贯穿始终组件模型可追溯应用卡片RS/Service 聚合 迷你图表、事件表列、日志查看器、命名空间/密钥创建对话框都能在 modules/web/src/common/components 与 modules/web/src/create 中找到直接对应实现后端语义一致DeployApp()deploy.go中 Deployment 可选 Service 的原子创建模型正是 2015 年表单 DEPLOY 按钮背后承诺的行为设计遗留显性化23 号幻灯片的问题清单成为观察 Dashboard 后续功能优先级的一把钥匙。若要亲手体验这套设计的现代形态可按仓库 DEVELOPMENT.md 与 Makefile 的指引本地启动各模块web/api/auth/metrics-scraper原始 Sketch 设计稿仍保存在 docs/design/mockups/11-11-2015-initial/kubernetes-dashboard.sketch同目录下 23 张 PNG 可逐张对照阅读。【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址: https://gitcode.com/gh_mirrors/da/dashboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes Dashboard 2015 初始 MVP 设计原型全解析：从 Sketch 草图到源码落地
Kubernetes Dashboard 2015 初始 MVP 设计原型全解析从 Sketch 草图到源码落地【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址: https://gitcode.com/gh_mirrors/da/dashboard本篇技术指南以 docs/design/mockups/11-11-2015-initial/README.md 中记录的 23 张初始设计幻灯片为核心骨架系统还原 2015 年 11 月 Kubernetes Dashboard即当前仓库gh_mirrors/da/dashboard的前身首个 MVP 版本的界面设计意图——包括零状态引导、两种部署应用方式、命名空间与镜像拉取密钥、应用卡片列表、事件排查与日志查看等。读者不仅能理解为什么今天 Dashboard 长这样还能通过对照 modules/web 与 modules/api 中的源码实现验证当年设计决策如何在现代 Angular Go 架构中一一落地。背景一份面向 Kubernetes UI SIG 的 MVP 设计稿该目录是 Dashboard 设计原型归档中时间最早的一份docs/design/mockups/README.md 说明该目录按版本归档各期 mockup。目录下的 README.md 本质是一份幻灯片的索引清单同时提供原始可编辑设计源文件Sketch 源文件kubernetes-dashboard.sketch设计师可直接打开继续编辑23 张导出 PNG从标题页到 MVP 遗留问题清单按演示顺序编号01_title.png至23_tbd for mvp.png。其中02_notes.png明确了这份设计的性质与时间线These are current designs for the initial MVP version of the Kubernetes Dashboard. The designs were presented to the Kubernetes UI SIG on Nov 9, 2015.也就是说这是 2015 年 11 月 9 日提交给 Kubernetes UI SIG 评审的初始 MVP 方案标题页日期标注为 November 9, 2015而目录名11-11-2015记录了归档日期。这 23 张图覆盖了 Dashboard 的第一个用户旅程欢迎引导 → 部署应用 → 查看应用列表 → 详情排查 → 查看日志这一流程骨架至今仍能在仓库代码中辨认出来。第一印象顶部导航与零状态引导页01_title.png与02_notes.png是演示用的封面与说明页从03_welcome - zero state.png开始进入真正的产品界面。这张零状态页奠定了 Dashboard 的整体视觉骨架顶部是一条深蓝色导航栏左侧为 Kubernetes Logo 与当前集群名cluster-1主区域左侧是一张引导卡片文案为 The Kubernetes Dashboard lets you deploy, monitor and troubleshoot containerized apps and services配一个醒目的DEPLOY AN APP主按钮右侧是一张 Learn more 卡片提供Dashboard Tour / Deploying your App / Monitoring your App / Troubleshooting四个学习入口。零状态Zero State设计是 MVP 中非常关键的产品决策空集群没有可展示的资源此时引导用户完成第一个动作部署应用比展示空表格更有价值。这一理念延续至今仓库中的通用零状态组件 kd-list-zero-state 以及 overview 页面组件 都体现了无数据时给引导的思路。部署应用MVP 的核心交互04–14 号幻灯片部署应用是整个 MVP 中占比最大的模块04–14 号共 11 张也是与当前源码对应关系最清晰的部分。如今的前端实现在 modules/web/src/create/from/form/template.html表单与 modules/web/src/create/from/file/template.html文件上传中后端实现在 modules/api/pkg/resource/deployment/deploy.go。两种部署方式表单填写 与 上传 YAML/JSON04_deploy form upload.png与08_deploy form.png展示了部署对话框顶部的两个互斥选项radioSpecify app details below手动填写应用信息Upload a YAML or JSON file上传一个 YAML/JSON 清单文件由系统解析后创建资源。后者在源码中的完整链路为前端 CreateService.createContent() 携带 CSRF Token 向api/v1/appdeploymentfromfile发起 POST后端 DeployAppFromFile() 使用yaml.NewYAMLOrJSONDecoder逐对象解码文件内容通过 Discovery API 判断资源类型apiResource.Kind kind且名称不含/再用dynamic client创建任意类型的资源当请求的 namespace 为_all时会改用清单内自带的目标命名空间deploy.go。文件上传模式天然支持 Deployment、Service、CRD 等任意 Kubernetes 资源这是表单模式做不到的。命名空间下拉选择 新建对话框05/06/07三张图演示了命名空间交互的完整闭环表单中的Namespace下拉默认值为defaulttooltip 说明 Partition resources into logical groups下拉里提供Create a new namespace入口弹出 Create a new namespace 对话框副标题提示 The namespace will be added to cluster-1输入名称后点 OK创建成功后07号图显示下拉框已切换为新建的production命名空间。这段交互的现代实现就在 modules/web/src/create/from/form/template.html下拉框 Create a new namespace... 选项与 component.ts 的 handleNamespaceDialog()打开 createnamespace/dialog.ts成功后把新命名空间 push 进列表并选中失败则回退到第一个命名空间。有趣的是2015 年原型中的 tooltip 文案 Namespaces let you partition resources into logically named groups 被原样保留在了今天的模板里template.html。表单字段设计与今天的对应关系08_deploy form.png给出了 MVP 表单的完整字段14_deploy more.png则展开 More options 展示高级选项。将原型字段与 modules/web/src/create/from/form/component.ts 中form的 FormControl 定义逐一对照可见设计几乎全部落地原型字段2015今日 FormControl / 组件说明App namenamekdUniqueName异步校验 FormValidators.namePattern原型 tooltip 说会为 Replica Set/Service 添加 app 标签今天实际是添加到 Deployment/Service且前端用APP_LABEL_KEY k8s-app自动生成标签component.tsContainer imagecontainerImagekdValidImageReference校验支持 Docker Hub / Google Container RegistryNumber of podsreplicasmin1、kdWarnThreshold100超过 100 时给出性能告警Port / Target port / ProtocolportMappingsportmappings 组件支持多组端口协议 TCP/UDPExpose service externallyisExternal布尔值决定 Service 类型Namespacenamespace见上文More options 中的各项description、labels、imagePullSecret、cpuRequirement、memoryRequirement、containerCommand、containerCommandArgs、runAsPrivileged、variables见下文以14_deploy more.png为例原型中的高级选项包括CPU requirement0.25 CPU/ Memory requirement250 MB、Run command、Run as privileged、Volumes、Secrets、环境变量外加自定义Labels。这些在今天全部实现CPU/内存请求会通过resource.Quantity写入容器Resources.RequestsRun as privileged映射到SecurityContext.Privileged环境变量经convertEnvVarsSpec()转换为[]api.EnvVardeploy.go。内存输入界面使用 MiB 单位组装 spec 时后端会拼上Mi后缀component.ts。私有镜像与 Image Pull Secret09–13 号这 5 张图集中打磨了一个细节场景当镜像来自私有仓库时需要提供凭据。09号镜像字段填入了hub.docker.com/lowrey/webserver:4.3右侧出现Image pull secret下拉placeholder Select a secret并带设计批注If using public repo, show autocomplete dropdown for easier typing、Vision: Hide Image pull secret if public; technical challenge requires toggle for public/private10号下拉展开列出cassandra-access、mysql-lowrey、mysql-root等已有 secret以及Upload a new image pull secret...入口11/12号弹出 Upload an image pull secret 对话框输入本地 YAML 文件路径如/Users/petelow/webserver/src/pull-secret.yaml上传13号选择dockerhub-lowrey后的最终表单状态。今天的前端依旧保留这一交互Image Pull Secret 下拉在点击时通过api/v1/secret/{namespace}拉取当前命名空间下所有 Secretcomponent.ts getSecrets()并提供 Create a new secret... 选项createsecret/dialog.ts后端 DeployApp() 在ImagePullSecret非空时写入podSpec.ImagePullSecrets []api.LocalObjectReference{{Name: *spec.ImagePullSecret}}。当年私有仓库才显示密钥的设想最终以始终可选、按需填写的方式落地。部署动作的后端语义DeployApp()deploy.go完整定义了点击 DEPLOY之后发生了什么先创建Deployment携带 labels、annotations、replicas、PodTemplate再根据是否有端口映射决定是否创建Service——有端口映射时IsExternal决定 Service 类型是LoadBalancer还是ClusterIP每个端口映射会生成一个不超过 63 字符、带随机后缀的端口名generatePortMappingName/generateName。这与原型端口映射是可选服务定义的定位完全一致。应用列表卡片化设计与 24 小时迷你图表15_apps list.png与16_card variations.png定义了 Dashboard 最具辨识度的元素——应用卡片每张卡片代表一组Replica Set Service以匹配的 label query 聚合包含状态行如 12 pods running、4 pods running, 2 pending后者带红色告警镜像与 Age如gcr.io/peng/_webapp:1.0.4、19 days端点Internal服务名与 ExternalIP:Port如211.18.44.141:80CPU / Memory 迷你折线图批注明确Mini graphs show 24 hours of dataLogs下拉入口16_card variations.png一张超长规格图枚举了卡片的各种边界状态全部 Pod 运行、无描述、有额外标签、无 Service 端点、Pod pending/调度失败红色警告、多个 Service 合并为一张卡、多个 Replica Set 拆分为多张卡、More 菜单与大下拉等。卡片中的迷你趋势图在今天的实现中对应 sparkline 组件 与 graph 组件而多 Service 共享一个 label selector 合并展示、不同查询拆分展示的聚合逻辑则沉淀在后端资源列表的聚合层与前端 resourcelist 系列组件 中。应用列表卡片聚合 RS/Service的模型后来演进为 Overview 页面的分组卡片视图modules/web/src/overview。应用详情、事件排查与扩容17–20 号17_job details.png展示了一个应用webapp的详情页其布局与后续所有资源详情页一脉相承左侧信息栏返回面包屑、ROLLING UPDATE与DELETE操作按钮、可编辑的 6 pods 计数、Label selectorappwebapp, version1.0.4、Replica Set 与 Service 的元数据与端点右侧主区域采用Pods / Events 双 TabPods 表格列Pod 名、Restarts含时间如 2 (4 min ago)、Age、CPU进度条、Memory进度条、IP、Node、Logs18_node hover.png鼠标悬停 Node 名gke-k2n9时显示完整节点名 tooltipgke-cluster-1-da3452-node-k2n9。19_events.png是事件排查页表格列几乎与今天的事件组件一一对应Type / Reason / Message / Source / Sub-object / Count / First seen / Last seen。现代实现在 resourcelist/event/component.tsgetDisplayColumns()返回statusicon, name, reason, message, source, count, firstSeen, lastSeen其中 Type 为Warning的事件会显示红色警告图标component.ts对应原型中 Killed for reason OutOfMemory 这类告警条目matSortActivelastSeen默认按最后出现时间排序template.html与原型中 First seen / Last seen 列的设计意图一致。20_change pod count.png演示了扩容交互点击可编辑的 pod 计数铅笔图标弹出Set desired number of pods对话框副标题说明 Replica set webapp will be updated to reflect the desired count。这在今天的实现中对应 scaleresource 对话框 与后端 modules/api/pkg/scaling/scale.go——从 2015 年原型到现代代码手动扩缩容始终是 Dashboard 的高频操作之一。日志查看器21–22 号21/22两张图展示了同一个全屏日志查看器区别仅在 Pod 启动时间不同说明是连续交互的两帧顶栏显示 Logs from pod webapp-7p1n 与 Running since 10-02-2015 06:14:36 PM提供Aa 字号调节按钮与Pod 选择下拉日志正文为带时间戳的逐行文本如I008 08:21:29.226156 20 pulls.go:551 Registered...。现代实现位于 modules/web/src/logs 目录标题同样以 Logs from 开头template.html下拉改为按Containers / Init Containers分组选择日志来源template.html——这恰好解决了 23 号幻灯片中 displaying multiple containers per pod 这个遗留问题。日志 API 侧由 modules/api/pkg/handler 与 modules/web/pkg/settings 提供参数化读取支持容器选择与时间范围控制。MVP 遗留问题清单23 号幻灯片最后一张23_tbd for mvp.png诚实记录了 MVP 发布前尚未解决的 6 项设计问题text pass with writers——文案需要专业写手润色details of autocomplete for image——镜像输入框的自动补全细节原型 09 号批注中已有 show autocomplete dropdown 的设想displaying multiple containers per pod——单 Pod 多容器的展示现已通过日志页的容器分组下拉解决case where Replica Set and Service names differ——RS 与 Service 命名不一致的场景17 号卡片假设两者标签一致proper control to stop a pod——停止 Pod 的明确控件include states and dismissable messages in app details page——详情页中的状态提示与可关闭消息。这份清单对研究 Dashboard 演进很有价值它划定了 MVP 的边界也预告了后续迭代的方向。对比今天的代码库第 3 项多容器与第 6 项可关闭通知见 notifications 组件 与 alert 对话框已经得到解决第 2 项的镜像自动补全、第 5 项的停止 Pod 控件则让位于更通用的资源管理能力如 Scale、Restart、Delete 等 ActionBar 操作见 actionbars 目录。从原型到现代架构一页设计的十年演变对照 2015 年原型与当前仓库可以清晰总结出 Dashboard 的设计连续性信息架构未变顶部集群导航 → 零状态/概览引导 → 部署表单/文件→ 列表 → 详情元数据 Pods/Events Tab→ 日志这一旅程贯穿始终组件模型可追溯应用卡片RS/Service 聚合 迷你图表、事件表列、日志查看器、命名空间/密钥创建对话框都能在 modules/web/src/common/components 与 modules/web/src/create 中找到直接对应实现后端语义一致DeployApp()deploy.go中 Deployment 可选 Service 的原子创建模型正是 2015 年表单 DEPLOY 按钮背后承诺的行为设计遗留显性化23 号幻灯片的问题清单成为观察 Dashboard 后续功能优先级的一把钥匙。若要亲手体验这套设计的现代形态可按仓库 DEVELOPMENT.md 与 Makefile 的指引本地启动各模块web/api/auth/metrics-scraper原始 Sketch 设计稿仍保存在 docs/design/mockups/11-11-2015-initial/kubernetes-dashboard.sketch同目录下 23 张 PNG 可逐张对照阅读。【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址: https://gitcode.com/gh_mirrors/da/dashboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考