使用 Meshery Catalog 部署 Kubernetes GuestbookExtended Version Design 全组件解析与实战【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/mesheryMeshery 的 Catalog目录如同云原生基础设施的“应用市场”社区成员可以将自己设计好的可部署单元Design发布其中供他人一键复用。本文以 Catalog 中已发布的Guestbook Application - Extended Version版本 0.0.13为蓝本完整剖析这个经典留言簿示例的每个组件、资源配置、服务暴露方式与组件间关系模型并给出使用mesheryctl导入与部署的完整命令路径。读完本文你将掌握如何阅读一个 Meshery Catalog Design 文件、理解其组件与关系的声明式结构并能将其一键落地到自己的 Kubernetes 集群。Catalog 条目速览元数据背后说明什么该 Design 的 Catalog 清单文件位于 docs/catalog/deployment/517a238d-da27-47d3-94e0-1b75fd0b3052.md其 front matter 本身即是一份结构化的条目元数据主要字段如下字段值含义nameGuestbook Application - Extended VersionCatalog 中展示的名称publishedVersion0.0.13当前发布的 Design 版本typedeploymentCatalog 分类之一Deployment/Security/Resiliency/Observability 等compatibilitykubernetes, pravega兼容的技术栈标签patternId517a238d-da27-47d3-94e0-1b75fd0b3052该 Design 在 Meshery 中的唯一 IDpatternInfo经典 Guestbook 的独特扩展版包含改进的资源限制、作者标签与自定义欢迎语面向读者的一句话介绍patternCaveats仅用于演示使用公共 Redis 与 PHP 镜像已在 Meshery Kanvas UI 中测试使用前须知的重要限制createdAt2025-06-15T18:48:57Z创建时间与 Catalog 条目配套的还有 artifacthub-pkg.yml它遵循 Artifact Hub 的包描述规范记录了install: mesheryctl design import -f这一官方推荐的导入命令以及license: Apache-2.0、作者与说明信息。也就是说这份条目既可以被 Meshery 网页 Catalog 检索也可以被 Artifact Hub 这类外部包索引消费。按照 Meshery Catalog 概念文档 的说明发布到 Catalog 的设计会先经过作者提交申请、Workspace 管理员审核、数据校验等流程随后通过 GitHub Workflow 自动同步到 Catalog——本条目正是这一发布机制的产物。Design 文件一份可部署单元的全部内容Design 是 Meshery 中可部署单元deployable unit由组件Components与关系Relationships构成参见 Designs 概念文档。该条目的真实设计内容存放在 design.ymlschemaVersion: designs.meshery.io/v1beta1它是一个 JSON 序列化的 Design 文件。整个 Design 共声明了10 个组件组件清单如下组件Kind版本命名空间副本/数量镜像frontendDeploymentapps/v1default3php:8.1-apacheredis-masterDeploymentapps/v1default1redis:7-alpineredis-replicaDeploymentapps/v1default2redis:7-alpineguestbook-configConfigMapv1default——frontendServicev1default——redis-masterServicev1default——redis-replicaServicev1default——defaultNamespacev1———containers.0 × 3Container注释组件core.meshery.io/v1alpha1———Section注释组件core.meshery.io/v1alpha1———其中三个containers.0与一个Section来自meshery-core模型属于注释类组件isAnnotation: true它们不直接生成 Kubernetes 资源而是承载设计与部署引擎之间的引用信息例如容器级别的 patch 路径。真正落地到集群的是 3 个 Deployment、3 个 Service、1 个 ConfigMap 与 1 个 Namespace。前端层带资源限额与自定义欢迎语的 PHP 应用前端是一个标准的三副本 Deployment其核心配置如下取自 design.yml 中 id 为75080dff-...的组件{ spec: { replicas: 3, selector: { matchLabels: { app: guestbook, tier: frontend } }, template: { spec: { containers: [ { env: [{ name: GET_HOSTS_FROM, value: dns }], name: php-redis, image: php:8.1-apache, ports: [{ containerPort: 80 }], envFrom: [{ configMapRef: { name: guestbook-config } }], resources: { limits: { cpu: 200m, memory: 200Mi }, requests: { cpu: 100m, memory: 100Mi } } } ] }, metadata: { labels: { app: guestbook, tier: frontend } } } }, metadata: { name: frontend, labels: { app: guestbook, tier: frontend, author: toko, version: 0.2.0 } } }几个值得注意的细节GET_HOSTS_FROMdns经典 Guestbook 示例中用于控制 PHP 应用如何发现 Redis 主机——设置为dns时应用直接通过 Kubernetes 内置 DNSredis-master、redis-replica服务名解析后端地址。envFromconfigMapRef: guestbook-config前端容器将guestbook-configConfigMap 中的全部键值注入为环境变量这正是“自定义欢迎语”的注入通道。资源限制改进原版 Guestbook 通常不声明 resources而此扩展版为每个容器显式声明了limits200m CPU / 200Mi 内存与requests100m CPU / 100Mi 内存。从源码结构看这是该 Design 相对经典版本的核心增强点之一能让 Kubernetes 调度器更合理地分配节点资源。作者标签Deployment 的 metadata 中携带了author: toko与version: 0.2.0标签体现了 Catalog 条目的“作者标记”改进。支撑欢迎语的 ConfigMap 组件定义非常简洁{ data: { WELCOME_MESSAGE: Welcome to Toko’s Unique Guestbook ✨ }, metadata: { name: guestbook-config, namespace: default } }当 Design 被部署后前端 Pod 启动时即可通过环境变量WELCOME_MESSAGE读取这条个性化欢迎语。数据层一主两从的 Redis 拓扑后端存储由两个 Deployment 组成形成经典的 Redis 主从架构redis-master1 副本容器master镜像redis:7-alpine暴露6379端口同样带资源限额200m CPU / 200Mi 内存上限100m / 100Mi 请求值并声明GET_HOSTS_FROMdns环境变量。redis-replica2 副本容器replica镜像redis:7-alpine暴露6379端口资源限额与主节点一致并带author: toko标签。两个 Deployment 通过各自的 label selector 区分角色master 使用app: redis, role: master, tier: backendreplica 使用app: redis, role: replica, tier: backend。这种“一主二从”布局对应经典 Guestbook 教程中演示 Redis 主从复制与高可用的典型形态。需要提醒的是patternCaveats明确指出该设计仅用于演示目的——它直接使用公共redis:7-alpine镜像没有配置持久化卷、密码认证或redis.conf生产环境必须在此基础上补充存储与安全配置。网络层三种 Service 的暴露方式Design 中声明了三个 Service分工明确Servicetype端口selector作用frontendNodePort80appguestbook, tierfrontend对外暴露 PHP 前端页面redis-masterClusterIP默认6379 → targetPort 6379appredis, rolemaster, tierbackend供前端写入redis-replicaClusterIP默认6379appredis, rolereplica, tierbackend供前端读取其中frontend是唯一暴露到集群外部的入口采用NodePort类型并将port: 80映射到 Node 端口浏览器通过NodeIP:NodePort即可访问留言簿页面两个 Redis Service 仅限集群内部 DNS 解析使用。三个 Service 分别通过selector精确匹配对应 Deployment 的 Pod 标签确保流量只到达正确的后端。关系模型Design 如何“粘合”这些组件与普通 Kubernetes 清单相比Meshery Design 的独特之处在于显式声明了组件之间的关系Relationships。本 Design 共携带 5 条关系schemaVersion: relationships.meshery.io/v1alpha3hierarchical / alias3 条将meshery-core的Container注释组件与对应 Deployment 关联resolved_ref_field_path指向configuration.spec.template.spec.containers[0]即“容器的配置会被 patch 到 Deployment 的 Pod 模板首个容器上”patchStrategy: replace表示采用整体替换策略。hierarchical / inventory1 条Namespacedefault与所有命名空间级组件之间的包含关系会将 Namespace 名称写入各组件configuration.metadata.namespace。这也解释了为何 ConfigMap、Deployment、Service 的配置中都出现namespace: default。edge / non-binding / network1 条定义 Service 到 Deployment 的网络边mutatorRef指向 Service 的spec.selector、ports[0].targetPort与protocol表示 Service 的选择器、目标端口会与后端 Deployment 的 labels、containerPort 建立对应关系——这正是 Kanvas 画布上 Service 与 Deployment 之间连线所代表语义的底层实现。Design 顶部还有一段preferences.layers.relationships配置其中hierarchical-sibling-matchlabels: false表示禁用“同级标签自动匹配”这一层的渲染。从源码结构可以推断这些关系是 Meshery 部署引擎在解析 Design 时用来生成最终 Kubernetes 清单的“接线图”也是 Kanvas UI 中可视化连线与配置补全的依据。实战用 mesheryctl 导入并部署该 Design该 Catalog 条目官方推荐的导入方式是mesheryctl design import -f见 artifacthub-pkg.yml。结合 mesheryctl 命令定义完整的命令行工作流如下# 1. 将 Design 文件导入 Meshery文件路径或 URL 均可 mesheryctl design import -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml # 2. 查看本机已有的 Design 列表 mesheryctl design list # 3. 预览某个 Design 的内容 mesheryctl design view guestbook-application---extended-version # 4. 将 Design 部署到当前连接的 Kubernetes 环境 mesheryctl design apply -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml # 若希望部署时不保留记录可追加 --skip-save # 5. 不再需要时一键回收所有由该 Design 创建的资源 mesheryctl design delete -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml命令体系的关键说明mesheryctl design子命令族包含apply / delete / deploy / export / import / list / undeploy / view覆盖了 Design 的全生命周期管理cmds.yml。import支持--source-type [manifest | compose | helm]意味着除了 Meshery 原生 DesignKubernetes 清单、Docker Compose 与 Helm Chart 都可以被转换导入为 Design。apply支持从本地路径或远程 URL 拉取文件“also supports file retrieval from GitHub”。部署前建议先执行 dry-run 或借助 Meshery Kanvas UI 的预览能力核对资源形态——该条目作者正是在 Kanvas UI 中完成验证的。部署完成后前端通过NodePort暴露访问方式为http://任意Node节点IP:NodePort页面首页将显示 ConfigMap 注入的自定义欢迎语写入的留言会经 Redis 主从架构持久化在redis-master/redis-replica的内存数据中。使用前提与注意事项仅限演示Design 直接使用公共php:8.1-apache与redis:7-alpine镜像未做持久化、认证与安全加固不适合直接用于生产。环境要求compatibility声明了 kubernetes 与 pravega部署前请确保mesheryctl已正确连接目标 Kubernetes 集群。版本语义Design 是版本化的本条目当前发布版本为0.0.13每次作者保存都会生成新版本读者可通过 Catalog 页面或mesheryctl design view获取更新。了解 Design 机制如需深入理解 Design 与 Model 的关系、导入导出、快照与发布等能力可继续阅读 Designs 概念文档关于 Catalog 的审核与发布流程可参考 Catalog 概念文档。总结Guestbook Application - Extended Version 是一份结构完整、信息密度适中的 Meshery Catalog Design 样本它用 10 个组件与 5 条关系把“PHP 前端 Redis 一主两从 NodePort 对外入口”这套经典拓扑封装成了可导入、可预览、可一键部署、可整体回收的声明式单元。通过阅读其 design.yml你不仅能理解 Guestbook 示例本身的部署细节更能举一反三掌握 Meshery Design 文件的结构化组织方式——组件描述资源、关系描述连接、mesheryctl design负责全生命周期管理——这套范式同样适用于你为自有应用编写和发布 Catalog 条目。【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
使用 Meshery Catalog 部署 Kubernetes Guestbook：Extended Version Design 全组件解析与实战
使用 Meshery Catalog 部署 Kubernetes GuestbookExtended Version Design 全组件解析与实战【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/mesheryMeshery 的 Catalog目录如同云原生基础设施的“应用市场”社区成员可以将自己设计好的可部署单元Design发布其中供他人一键复用。本文以 Catalog 中已发布的Guestbook Application - Extended Version版本 0.0.13为蓝本完整剖析这个经典留言簿示例的每个组件、资源配置、服务暴露方式与组件间关系模型并给出使用mesheryctl导入与部署的完整命令路径。读完本文你将掌握如何阅读一个 Meshery Catalog Design 文件、理解其组件与关系的声明式结构并能将其一键落地到自己的 Kubernetes 集群。Catalog 条目速览元数据背后说明什么该 Design 的 Catalog 清单文件位于 docs/catalog/deployment/517a238d-da27-47d3-94e0-1b75fd0b3052.md其 front matter 本身即是一份结构化的条目元数据主要字段如下字段值含义nameGuestbook Application - Extended VersionCatalog 中展示的名称publishedVersion0.0.13当前发布的 Design 版本typedeploymentCatalog 分类之一Deployment/Security/Resiliency/Observability 等compatibilitykubernetes, pravega兼容的技术栈标签patternId517a238d-da27-47d3-94e0-1b75fd0b3052该 Design 在 Meshery 中的唯一 IDpatternInfo经典 Guestbook 的独特扩展版包含改进的资源限制、作者标签与自定义欢迎语面向读者的一句话介绍patternCaveats仅用于演示使用公共 Redis 与 PHP 镜像已在 Meshery Kanvas UI 中测试使用前须知的重要限制createdAt2025-06-15T18:48:57Z创建时间与 Catalog 条目配套的还有 artifacthub-pkg.yml它遵循 Artifact Hub 的包描述规范记录了install: mesheryctl design import -f这一官方推荐的导入命令以及license: Apache-2.0、作者与说明信息。也就是说这份条目既可以被 Meshery 网页 Catalog 检索也可以被 Artifact Hub 这类外部包索引消费。按照 Meshery Catalog 概念文档 的说明发布到 Catalog 的设计会先经过作者提交申请、Workspace 管理员审核、数据校验等流程随后通过 GitHub Workflow 自动同步到 Catalog——本条目正是这一发布机制的产物。Design 文件一份可部署单元的全部内容Design 是 Meshery 中可部署单元deployable unit由组件Components与关系Relationships构成参见 Designs 概念文档。该条目的真实设计内容存放在 design.ymlschemaVersion: designs.meshery.io/v1beta1它是一个 JSON 序列化的 Design 文件。整个 Design 共声明了10 个组件组件清单如下组件Kind版本命名空间副本/数量镜像frontendDeploymentapps/v1default3php:8.1-apacheredis-masterDeploymentapps/v1default1redis:7-alpineredis-replicaDeploymentapps/v1default2redis:7-alpineguestbook-configConfigMapv1default——frontendServicev1default——redis-masterServicev1default——redis-replicaServicev1default——defaultNamespacev1———containers.0 × 3Container注释组件core.meshery.io/v1alpha1———Section注释组件core.meshery.io/v1alpha1———其中三个containers.0与一个Section来自meshery-core模型属于注释类组件isAnnotation: true它们不直接生成 Kubernetes 资源而是承载设计与部署引擎之间的引用信息例如容器级别的 patch 路径。真正落地到集群的是 3 个 Deployment、3 个 Service、1 个 ConfigMap 与 1 个 Namespace。前端层带资源限额与自定义欢迎语的 PHP 应用前端是一个标准的三副本 Deployment其核心配置如下取自 design.yml 中 id 为75080dff-...的组件{ spec: { replicas: 3, selector: { matchLabels: { app: guestbook, tier: frontend } }, template: { spec: { containers: [ { env: [{ name: GET_HOSTS_FROM, value: dns }], name: php-redis, image: php:8.1-apache, ports: [{ containerPort: 80 }], envFrom: [{ configMapRef: { name: guestbook-config } }], resources: { limits: { cpu: 200m, memory: 200Mi }, requests: { cpu: 100m, memory: 100Mi } } } ] }, metadata: { labels: { app: guestbook, tier: frontend } } } }, metadata: { name: frontend, labels: { app: guestbook, tier: frontend, author: toko, version: 0.2.0 } } }几个值得注意的细节GET_HOSTS_FROMdns经典 Guestbook 示例中用于控制 PHP 应用如何发现 Redis 主机——设置为dns时应用直接通过 Kubernetes 内置 DNSredis-master、redis-replica服务名解析后端地址。envFromconfigMapRef: guestbook-config前端容器将guestbook-configConfigMap 中的全部键值注入为环境变量这正是“自定义欢迎语”的注入通道。资源限制改进原版 Guestbook 通常不声明 resources而此扩展版为每个容器显式声明了limits200m CPU / 200Mi 内存与requests100m CPU / 100Mi 内存。从源码结构看这是该 Design 相对经典版本的核心增强点之一能让 Kubernetes 调度器更合理地分配节点资源。作者标签Deployment 的 metadata 中携带了author: toko与version: 0.2.0标签体现了 Catalog 条目的“作者标记”改进。支撑欢迎语的 ConfigMap 组件定义非常简洁{ data: { WELCOME_MESSAGE: Welcome to Toko’s Unique Guestbook ✨ }, metadata: { name: guestbook-config, namespace: default } }当 Design 被部署后前端 Pod 启动时即可通过环境变量WELCOME_MESSAGE读取这条个性化欢迎语。数据层一主两从的 Redis 拓扑后端存储由两个 Deployment 组成形成经典的 Redis 主从架构redis-master1 副本容器master镜像redis:7-alpine暴露6379端口同样带资源限额200m CPU / 200Mi 内存上限100m / 100Mi 请求值并声明GET_HOSTS_FROMdns环境变量。redis-replica2 副本容器replica镜像redis:7-alpine暴露6379端口资源限额与主节点一致并带author: toko标签。两个 Deployment 通过各自的 label selector 区分角色master 使用app: redis, role: master, tier: backendreplica 使用app: redis, role: replica, tier: backend。这种“一主二从”布局对应经典 Guestbook 教程中演示 Redis 主从复制与高可用的典型形态。需要提醒的是patternCaveats明确指出该设计仅用于演示目的——它直接使用公共redis:7-alpine镜像没有配置持久化卷、密码认证或redis.conf生产环境必须在此基础上补充存储与安全配置。网络层三种 Service 的暴露方式Design 中声明了三个 Service分工明确Servicetype端口selector作用frontendNodePort80appguestbook, tierfrontend对外暴露 PHP 前端页面redis-masterClusterIP默认6379 → targetPort 6379appredis, rolemaster, tierbackend供前端写入redis-replicaClusterIP默认6379appredis, rolereplica, tierbackend供前端读取其中frontend是唯一暴露到集群外部的入口采用NodePort类型并将port: 80映射到 Node 端口浏览器通过NodeIP:NodePort即可访问留言簿页面两个 Redis Service 仅限集群内部 DNS 解析使用。三个 Service 分别通过selector精确匹配对应 Deployment 的 Pod 标签确保流量只到达正确的后端。关系模型Design 如何“粘合”这些组件与普通 Kubernetes 清单相比Meshery Design 的独特之处在于显式声明了组件之间的关系Relationships。本 Design 共携带 5 条关系schemaVersion: relationships.meshery.io/v1alpha3hierarchical / alias3 条将meshery-core的Container注释组件与对应 Deployment 关联resolved_ref_field_path指向configuration.spec.template.spec.containers[0]即“容器的配置会被 patch 到 Deployment 的 Pod 模板首个容器上”patchStrategy: replace表示采用整体替换策略。hierarchical / inventory1 条Namespacedefault与所有命名空间级组件之间的包含关系会将 Namespace 名称写入各组件configuration.metadata.namespace。这也解释了为何 ConfigMap、Deployment、Service 的配置中都出现namespace: default。edge / non-binding / network1 条定义 Service 到 Deployment 的网络边mutatorRef指向 Service 的spec.selector、ports[0].targetPort与protocol表示 Service 的选择器、目标端口会与后端 Deployment 的 labels、containerPort 建立对应关系——这正是 Kanvas 画布上 Service 与 Deployment 之间连线所代表语义的底层实现。Design 顶部还有一段preferences.layers.relationships配置其中hierarchical-sibling-matchlabels: false表示禁用“同级标签自动匹配”这一层的渲染。从源码结构可以推断这些关系是 Meshery 部署引擎在解析 Design 时用来生成最终 Kubernetes 清单的“接线图”也是 Kanvas UI 中可视化连线与配置补全的依据。实战用 mesheryctl 导入并部署该 Design该 Catalog 条目官方推荐的导入方式是mesheryctl design import -f见 artifacthub-pkg.yml。结合 mesheryctl 命令定义完整的命令行工作流如下# 1. 将 Design 文件导入 Meshery文件路径或 URL 均可 mesheryctl design import -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml # 2. 查看本机已有的 Design 列表 mesheryctl design list # 3. 预览某个 Design 的内容 mesheryctl design view guestbook-application---extended-version # 4. 将 Design 部署到当前连接的 Kubernetes 环境 mesheryctl design apply -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml # 若希望部署时不保留记录可追加 --skip-save # 5. 不再需要时一键回收所有由该 Design 创建的资源 mesheryctl design delete -f 517a238d-da27-47d3-94e0-1b75fd0b3052/design.yml命令体系的关键说明mesheryctl design子命令族包含apply / delete / deploy / export / import / list / undeploy / view覆盖了 Design 的全生命周期管理cmds.yml。import支持--source-type [manifest | compose | helm]意味着除了 Meshery 原生 DesignKubernetes 清单、Docker Compose 与 Helm Chart 都可以被转换导入为 Design。apply支持从本地路径或远程 URL 拉取文件“also supports file retrieval from GitHub”。部署前建议先执行 dry-run 或借助 Meshery Kanvas UI 的预览能力核对资源形态——该条目作者正是在 Kanvas UI 中完成验证的。部署完成后前端通过NodePort暴露访问方式为http://任意Node节点IP:NodePort页面首页将显示 ConfigMap 注入的自定义欢迎语写入的留言会经 Redis 主从架构持久化在redis-master/redis-replica的内存数据中。使用前提与注意事项仅限演示Design 直接使用公共php:8.1-apache与redis:7-alpine镜像未做持久化、认证与安全加固不适合直接用于生产。环境要求compatibility声明了 kubernetes 与 pravega部署前请确保mesheryctl已正确连接目标 Kubernetes 集群。版本语义Design 是版本化的本条目当前发布版本为0.0.13每次作者保存都会生成新版本读者可通过 Catalog 页面或mesheryctl design view获取更新。了解 Design 机制如需深入理解 Design 与 Model 的关系、导入导出、快照与发布等能力可继续阅读 Designs 概念文档关于 Catalog 的审核与发布流程可参考 Catalog 概念文档。总结Guestbook Application - Extended Version 是一份结构完整、信息密度适中的 Meshery Catalog Design 样本它用 10 个组件与 5 条关系把“PHP 前端 Redis 一主两从 NodePort 对外入口”这套经典拓扑封装成了可导入、可预览、可一键部署、可整体回收的声明式单元。通过阅读其 design.yml你不仅能理解 Guestbook 示例本身的部署细节更能举一反三掌握 Meshery Design 文件的结构化组织方式——组件描述资源、关系描述连接、mesheryctl design负责全生命周期管理——这套范式同样适用于你为自有应用编写和发布 Catalog 条目。【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考