使用 Meshery 在 Kubernetes 上部署 WordPress 与 MySQL：MeshMap 设计模式实战解析

使用 Meshery 在 Kubernetes 上部署 WordPress 与 MySQLMeshMap 设计模式实战解析【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery本篇技术指南基于 Meshery 开源仓库中的 Catalog 设计模式文档 WordPress and MySQL on Kubernetes 及其配套的 design.yml 模式定义完整拆解该模式在 Kubernetes 集群上部署 WordPress 应用与 MySQL 数据库的组件构成、配置细节与导入部署流程。读完本文你将掌握该 Catalog 模式的整体架构、每个 Kubernetes 资源对象的关键配置字段以及如何通过mesheryctl design import一键将设计导入 Meshery 并交付到目标集群。一、设计模式概览这是什么该 Catalog 条目是 Meshery 生态中的一个部署型deployment设计模式模式 ID 为3546d0d4-ba6e-4c7e-9661-853ade11847f当前发布版本为0.0.1。其官方描述patternInfo明确指出该 MeshMap 设计在 Kubernetes 集群上部署一套可扩展、健壮的 WordPress 应用并以 MySQL 数据库作为后端支撑。设计充分利用 Kubernetes 资源来确保 WordPress 站点的高可用性、高效扩缩容与易管理性。模式元数据中声明的兼容性组件包括kubernetes、mysql-operator与wordpress-operator发布者为David HunteruserId:6126611f-41d6-4206-8504-822a5262d110创建时间为2024-01-29。文档 Front Matter 同时声明了模式的下载入口downloadLink: 3546d0d4-ba6e-4c7e-9661-853ade11847f/design.yml对应的完整设计文件即为 design.yml而 artifacthub-pkg.yml 则以 ArtifactHub 包清单的形式补充了该模式的安装命令mesheryctl design import -f。二、组件清单一张图看懂资源构成从design.yml的components数组可以看出该设计模式并非单一工作负载而是一套完整的 WordPress MySQL 拓扑。核心可部署资源isAnnotation: false包括资源类型displayName说明Deployment (apps/v1)deploymentWordPress 前端 DeploymentDeployment (apps/v1)wordpress-mysqlMySQL 后端 DeploymentService (v1)wordpressWordPress 前端服务headless ClusterIPService (v1)wordpress-mysqlMySQL 后端服务Secret (v1)mysql-pass数据库密码凭据PersistentVolumeClaimmysql-pv-claimMySQL 数据卷声明20GiPersistentVolumeClaimwp-pv-claimWordPress 数据卷声明20GiPersistentVolume (v1)wordpress-persistent-storageWordPress 持久卷PersistentVolume (v1)mysql-persistent-storageMySQL 持久卷Namespace (v1)default全部资源所在的命名空间此外设计中还包含若干meshery-core模型的AnchorNode、NodeGroupInventoryWallet、Container等注解类节点isAnnotation: true它们属于 MeshMap 画布用于可视化编组与容器拓扑表达的辅助节点并非直接下发的 Kubernetes 资源在阅读 design.yml 时应加以区分。三、WordPress 前端 Deployment 详解设计中的 WordPress 工作负载是名为deployment的 Deployment命名空间为default携带标签app: wordpress。其核心配置如下节选自 design.yml 中 id 为6c0d3f0d-5c82-407a-8a03-30b518cccdb0的组件{ component: { kind: Deployment, version: apps/v1 }, configuration: { metadata: { labels: { app: wordpress }, namespace: default }, spec: { selector: { matchLabels: { app: wordpress, tier: frontend } }, template: { metadata: { labels: { app: wordpress, tier: frontend } }, spec: { containers: [ { name: wordpress, image: wordpress:6.2.1-apache, ports: [{ name: wordpress, containerPort: 80, protocol: TCP }], env: [ { name: WORDPRESS_DB_HOST, value: wordpress-mysql }, { name: WORDPRESS_DB_USER, value: wordpress }, { name: WORDPRESS_DB_PASSWORD, valueFrom: { secretKeyRef: { name: mysql-pass, key: password } } } ], volumeMounts: [ { name: wordpress-persistent-storage, mountPath: /var/www/html } ] } ], volumes: [ { name: wordpress-persistent-storage, persistentVolumeClaim: { claimName: wp-pv-claim } } ] } } } } }要点分析镜像固定为wordpress:6.2.1-apache以 Apache 运行并监听 80 端口与官方 WordPress 容器的环境变量规范一致。数据库连接通过环境变量注入WORDPRESS_DB_HOST指向wordpress-mysql对应后文 MySQL Service 的名称利用 Kubernetes 集群内 DNS 完成服务发现WORDPRESS_DB_USER为wordpressWORDPRESS_DB_PASSWORD不直接写在配置里而是通过secretKeyRef从名为mysql-pass的 Secret 中读取password键的值避免明文落盘。站点数据持久化容器将/var/www/htmlWordPress 的 Web 根目录与上传内容所在挂载到名为wordpress-persistent-storage的卷该卷绑定 PVCwp-pv-claim保证容器重建或滚动更新时站点文件不丢失。四、MySQL 后端 Deployment 详解MySQL 工作负载是名为wordpress-mysql的 Deploymentselector 使用tier: mysql标签。其核心配置如下对应 design.yml 中 id 为def3b3a8-59ea-49eb-96f7-4f3fd5cfc258的组件{ component: { kind: Deployment, version: apps/v1 }, configuration: { metadata: { labels: { app: wordpress }, namespace: default }, spec: { selector: { matchLabels: { app: wordpress, tier: mysql } }, template: { metadata: { labels: { app: wordpress, tier: mysql } }, spec: { containers: [ { name: mysql, image: mysql:8.0, ports: [{ name: mysql, containerPort: 3306, protocol: TCP }], env: [ { name: MYSQL_ROOT_PASSWORD, valueFrom: { secretKeyRef: { name: mysql-pass, key: password, optional: true } } }, { name: MYSQL_DATABASE, value: wordpress }, { name: MYSQL_USER, value: wordpress }, { name: MYSQL_PASSWORD, valueFrom: { secretKeyRef: { name: mysql-pass, key: password } } } ], volumeMounts: [ { name: mysql-persistent-storage, mountPath: /var/lib/mysql } ] } ], volumes: [ { name: mysql-persistent-storage, persistentVolumeClaim: { claimName: mysql-pv-claim } } ] } } } } }要点分析镜像为mysql:8.0监听 3306 端口。首次启动时 MySQL 容器会根据MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD等环境变量自动初始化数据库wordpress与专用账号wordpress与 WordPress 侧WORDPRESS_DB_USER/WORDPRESS_DB_PASSWORD形成闭环对应。root 密码同样取自mysql-passSecret且该引用标记为optional: true——这意味着即使 Secret 中缺少该键容器也能启动体现了设计上对初始化过程的一定容错。数据卷挂载/var/lib/mysql对应 PVCmysql-pv-claim保证数据库文件持久化是重启不丢数据的关键。从设计文件可见部分 Pod 形态的组件如 displayName 为pod-ako、pod-mec的 Pod保留了与 Deployment 一致的容器定义从源码结构看这些是 MeshMap 画布中 Pod 层级的可视化节点最终以 Deployment 为实际下发单元。五、服务发现与网络拓扑模式通过两个 Service 完成集群内的服务发现与流量路由。WordPress Serviceid:a309c048-143c-470d-bc20-41d766b96ca3{ component: { kind: Service, version: v1 }, configuration: { metadata: { labels: { app: wordpress }, namespace: default }, spec: { clusterIP: None, type: ClusterIP, allocateLoadBalancerNodePorts: false, ports: [ { name: wordpress, port: 80, protocol: TCP }, { name: wordpress-mysql, port: 80, protocol: TCP }, { name: deployment, port: 80, protocol: TCP }, { name: wordpress-mysql-deployment, port: 3309, protocol: TCP } ], selector: { app: wordpress, tier: frontend } } } }MySQL Serviceid:224b606b-1a71-4f25-8374-093374785235{ component: { kind: Service, version: v1 }, configuration: { metadata: { labels: { app: wordpress }, namespace: default }, spec: { ports: [ { name: mysql, port: 3308, protocol: TCP }, { name: wordpress, port: 3306, protocol: TCP }, { name: wordpress-mysql, port: 3309, protocol: TCP } ], selector: { app: wordpress, tier: mysql } } } }几个值得注意的设计细节前端 Service 将clusterIP显式设置为None即 headless Service适合有状态服务的稳定端点发现其 selector 精确匹配tier: frontend的 WordPress Pod。后端 Service 以tier: mysql为 selectorWordPress 容器通过 DNS 名称wordpress-mysql即可解析到 MySQL Pod——这正是第三节中WORDPRESS_DB_HOSTwordpress-mysql能够工作的网络基础。两个 Service 的 ports 定义中存在多个同名/异名端口条目如 3306、3308、3309从配置结构看这些端口条目更偏向 MeshMap 画布中服务连接的示意性声明实际生效路由以 selector 与 DNS 解析为准在生产环境中建议按需精简为单一明确的端口映射。六、凭据管理Secret mysql-pass数据库密码不硬编码在 Deployment 中而是集中存放在名为mysql-pass的 Secretid:1521fbc8-cc57-4f6b-8e78-ea1e749a463d里{ component: { kind: Secret, version: v1 }, configuration: { metadata: { namespace: default }, data: { password: }, stringData: { password: secretpassword } } }通过stringData.password声明的明文secretpassword仅存在于设计文件层面应用时由 Kubernetes 自动以 base64 编码写入data字段。WordPress 与 MySQL 两个 Deployment 均通过secretKeyRef: { name: mysql-pass, key: password }引用同一凭据实现单一数据源single source of truth修改密码只需更新 Secret 一处。需要注意secretpassword是设计文档中的演示值实际使用时应改为强密码避免直接沿用样例。七、持久化存储PV 与 PVCMySQL 与 WordPress 各自配有一组 20Gi 的持久化存储mysql-pv-claimid:feba8e8e-e245-4274-94db-66bc740a0634accessModes: [ReadWriteOnce]resources.requests.storage: 20GivolumeName: persistent-volume-storage。wp-pv-claimid:f8ac953d-4fbd-4fd3-8a5a-e971dae66dbe同样为ReadWriteOnce、20GivolumeName: wordpress-persistent-storage。配套的 PersistentVolumewordpress-persistent-storageReadWriteOnce与mysql-persistent-storage通过claimRef: { name: mysql-pv-claim }显式绑定到 MySQL 的 PVC。从存储配置可见该设计假定集群中存在可满足ReadWriteOnce 20Gi 需求的存储类或静态 PV在 kind、minikube 等本地集群中部署时需要预先提供对应的动态供应能力否则 PVC 会停留在Pending状态。八、组件关系Relationships与画布语义design.yml 后半部分的relationships数组记录了组件间的关联语义用于驱动 MeshMap 画布的连线、依赖与校验。其中主要包含两类hierarchical / parent层级父子关系描述父组件配置被子组件配置补丁覆盖的语义。例如 Namespace 与各 Pod/Deployment 之间、Pod 与 Deployment 之间mutatedRef: [[configuration,spec,template,spec]]表明画布上的 Pod 节点配置会并入其父级 Deployment。hierarchical / sibling同层兄弟关系以matchlabels为子类型通过configuration.metadata.labels匹配建立 Service 与 Deployment、PVC 与 PV 之间的对应关系。这些关系记录relationships.meshery.io/v1alpha3的价值在于当你在 MeshMap 中拖拽、连线或批量修改组件时平台可依据这些规则自动维护拓扑一致性这也是该设计模式可视化可编排特性的底层支撑。九、导入与部署mesheryctl design import该模式的官方安装方式在 artifacthub-pkg.yml 中声明为mesheryctl design import -f-f参数后应跟上设计文件的路径。导入设计文件后即可在 Meshery 的 Catalog 与设计中心中查看该拓扑选择已接入的 Kubernetes 集群执行部署。design.yml 的schemaVersion为designs.meshery.io/v1beta1其中嵌入的 Kubernetes 模型版本为v1.32.0-alpha.3来源git://github.com/kubernetes/kubernetes/master/api/openapi-spec/v3模式版本号为0.0.106——这些字段共同定义了设计文件的解析规范与所依赖的组件模型版本。十、注意事项与最佳实践文档 Front Matter 中的patternCaveats注意事项原样提出了两条部署前提这也是本模式落地时最容易被忽略的点确保 Kubernetes 集群拥有足够的资源CPU、内存与存储来同时承载 WordPress 与 MySQL 两个 Pod 及其持久卷。MySQL 8.0 与 Apache 版 WordPress 均有最低资源消耗建议集群至少提供数 GB 内存与足够的磁盘 IO。正确设置资源请求与限制resource requests/limits避免因资源竞争导致性能抖动。原始设计文件中未显式声明 requests/limits因此在使用前建议在 Deployment 的容器配置中补充例如为 MySQL 设置requests.memory: 512Mi、limits.memory: 1Gi之类的保守值。十一、相关仓库资源模式文档本文主体docs/catalog/deployment/3546d0d4-ba6e-4c7e-9661-853ade11847f.md完整设计定义组件与关系docs/data/catalog/3546d0d4-ba6e-4c7e-9661-853ade11847f/0.0.1/design.yml包清单安装命令与元数据docs/data/catalog/3546d0d4-ba6e-4c7e-9661-853ade11847f/0.0.1/artifacthub-pkg.ymlCatalog 目录默认模板docs/catalog/_defaults.md通过本模式你可以快速获得一套WordPress 前端 MySQL 后端 双向持久化 Secret 凭据管理的标准参考架构并以此为基础根据自身集群的存储与算力条件调整资源声明后再借助 Meshery 的可视化设计能力完成定制与交付。【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考