在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用：kubernetes-handbook 中的 mean Chart 实战指南

在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用kubernetes-handbook 中的 mean Chart 实战指南【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook导读本文基于 kubernetes-handbook 仓库中的 mean Helm Chart完整讲解如何借助 Helm 在 Kubernetes 集群中一键部署一套 MEANMongoDB Express.js Angular Node.js全栈应用。Chart 通过 init-containers 在容器启动阶段自动克隆 Git 仓库、安装 npm 依赖并注入数据库配置全程无需手工构建镜像。读完本文你将掌握该 Chart 的全部配置参数、初始化流程的源码级原理以及如何将其改造成部署自有 Node.js 应用的可复用方案。MEAN 技术栈与 Chart 定位MEAN 是 MongoDB、Express.js、Angular 和 Node.js 四个组件首字母的组合。由于该技术栈的所有组件都使用 JavaScript因此 MEAN 应用可以用同一种语言同时编写服务端与客户端代码。Chart.yaml 中将其描述为用于构建动态网站与 Web 应用的自由开源 JavaScript 技术栈。本 Chart版本 0.1.3由 Bitnami 维护的作用是在 Kubernetes 集群上引导一个 Node.js Deployment 和一个 MongoDB DeploymentNode.js 部分从 Git 仓库克隆应用代码到容器的/app目录默认使用 Bitnami 的 Node 镜像MongoDB 部分作为子 Chart 依赖开箱即用地引入提供数据库服务、认证凭据与可选持久化。与常规打包现成镜像的 Chart 不同本 Chart 的核心设计是运行时克隆代码——即应用并不预先构建为镜像而是在 Pod 初始化的过程中从 Git 拉取源码并完成依赖安装这使得它可以部署任意基于 Node.js 的 Git 仓库应用。Chart 目录结构与依赖关系仓库中该 Chart 的完整目录结构如下manifests/charts/mean/ ├── Chart.yaml # Chart 元数据名称、版本、关键字、维护者 ├── README.md # 使用说明本文所依据的主文档 ├── requirements.yaml # 依赖声明mongodb 子 Chart ├── requirements.lock # 依赖锁定文件 ├── values.yaml # Node.js 应用部分默认配置 ├── charts/ │ └── mongodb/ # MongoDB 子 Chartv0.4.x │ ├── Chart.yaml │ ├── values.yaml │ └── templates/ │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ ├── pvc.yaml │ ├── secrets.yaml │ └── svc.yaml └── templates/ ├── NOTES.txt # 安装成功后输出的访问指引 ├── _helpers.tpl # fullname / mongodb.fullname 命名模板 ├── configmap.yaml # 注入应用配置文件database.js ├── deployment.yaml # 主 Deploymentinit-containers 主容器 ├── pvc.yaml # 可选的应用持久卷声明 └── svc.yaml # Node.js 应用的 Service依赖关系在 requirements.yaml 中声明为mongodb子 Chart版本0.4.x。从 charts/mongodb/values.yaml 可以看到MongoDB 默认使用 Bitnami 的 MongoDB 3.4 镜像数据目录默认不开启持久化资源请求为 256Mi 内存与 100m CPU。命名规则由 _helpers.tpl 统一定义主应用资源名形如release-meanfullnameMongoDB 资源名形如release-mongodbmongodb.fullname。名称均按 DNS 规范截断至 63 字符。主 Deployment 正是通过mongodb.fullname模板计算出 MongoDB 的 Service 名称并以此为环境变量注入应用容器。安装 Chart环境前置条件根据 README部署本 Chart 需要Kubernetes 1.4且启用 Beta API模板中使用了extensions/v1beta1的 Deployment 与pod.beta.kubernetes.io/init-containers注解详见下文依赖较早版本的 Beta 特性底层基础设施具备 PV provisioner 支持仅在开启持久化时需要。基本安装最简单的安装方式$ helm install incubator/mean以my-release作为 release 名称安装$ helm install --name my-release incubator/mean该命令会以默认配置在集群中部署 Node.js 应用与 MongoDB。由于 Chart 会在容器初始化期间把应用克隆到/app卷上因此默认不要求持久卷。提示可使用helm list查看所有已部署的 release。自定义安装通过--set keyvalue[,keyvalue]逐项覆盖参数。例如指定应用仓库并同时设置 MongoDB root 密码$ helm install --name my-release \ --set repositoryhttps://github.com/scotch-io/node-todo.git,mongodb.mongodbRootPasswordsecretpassword \ incubator/mean上述命令会把远端 Git 仓库克隆到容器的/app目录并将 MongoDBroot用户的密码设置为secretpassword。更推荐的方式是提供一份完整的 values 文件$ helm install --name my-release -f values.yaml incubator/mean仓库自带的 values.yaml 就是一份可直接复制修改的参考模板。卸载 Chart$ helm delete my-release该命令会删除与该 release 关联的所有 Kubernetes 组件并移除该 release。配置参数详解README 列出了 Node.js Chart 的全部可配置参数及其默认值结合 values.yaml 与子 Chart 的 values.yaml 汇总如下参数描述默认值imageNode.js 镜像harbor-001.jimmysong.io/library/bitnami-node:7.5.0-r0仓库内实际值README 写作bitnami/node:{VERSION}imagePullPolicy镜像拉取策略IfNotPresentrepository应用 Git 仓库地址https://github.com/scotch-io/node-todo.gitrevision要检出的 Git 版本5750cb4仓库内实际值README 写作masterconfig应用配置文件内容见 values.yaml 中的database.js模板configfile应用配置文件名database.jsmongodb.mongodbRootPasswordMongoDB 管理员密码未设置nilmongodb.mongodbUsernameMongoDB 用户名未设置nilmongodb.mongodbPasswordMongoDB 用户密码未设置nilmongodb.mongodbDatabaseMongoDB 数据库名未设置nilmongodb.persistence.enabled是否启用 MongoDB 持久卷falsemongodb.persistence.storageClassPVC 的存储类null走默认 provisionermongodb.persistence.accessModePVC 访问模式ReadWriteOncemongodb.persistence.size磁盘大小8GiserviceTypeKubernetes Service 类型仓库内为ClusterIPREADME 写作LoadBalancerresourcesCPU/内存请求与限制Memory:512MiCPU:300mpersistence.enabledNode.js 是否启用持久化falsepersistence.storageClass应用 PVC 存储类若定义volume.beta.kubernetes.io/storage-class: storageClass否则默认volume.alpha.kubernetes.io/storage-class: defaultpersistence.path应用数据挂载路径/app/data参数来源与取值差异说明上述参数会映射为 Bitnami Node 镜像 约定的环境变量具体映射关系见下文环境变量注入一节仓库内的 values.yaml 与 README 表格存在两处差异应以 values.yaml 为准镜像 tag 已被替换为内部镜像仓库地址harbor-001.jimmysong.iorevision固定为提交号5750cb4serviceType为ClusterIP。README 亦提示minikube 环境应设为NodePort其他环境使用LoadBalancer这是按环境调整serviceType的官方建议MongoDB 子 Chart 的resources请求独立配置256Mi / 100m与主应用512Mi / 300m互不干扰。配置文件注入示例默认config内容是一段database.js模板它从环境变量拼装 MongoDB 连接串module.exports { remoteUrl: mongodb:// process.env.MONGODB_USERNAME : process.env.MONGODB_PASSWORD process.env.MONGODB_HOST : process.env.MONGODB_PORT / process.env.MONGODB_DATABASE , localUrl: mongodb:// process.env.MONGODB_USERNAME : process.env.MONGODB_PASSWORD process.env.MONGODB_HOST : process.env.MONGODB_PORT / process.env.MONGODB_DATABASE };由此可见应用的数据库连接并非硬编码而是完全由 Chart 注入的环境变量驱动这正是本 Chart 可以复用任意 Node.js 仓库的关键设计。核心机制init-containers 驱动的应用初始化流程本 Chart 最具技术价值的部分在 templates/deployment.yaml它以pod.beta.kubernetes.io/init-containers注解的形式声明了4 个串行执行的初始化容器按顺序完成数据库就绪探测、源码克隆、依赖安装与权限修复顺序容器名执行内容1wait-for-db-service循环 100 次用nc -z -w 1探测 MongoDB Service 的 27017 端口就绪后退出 0否则退出 12git-clone-appgit clone repository /app git checkout revision将源码克隆到共享的app卷3npm-install在/app下执行npm install安装 Node.js 依赖4fixing-permissions将/app、/home/bitnami与持久化路径递归chown为bitnami:bitnami确保主容器以非 root 身份可读写这 4 个容器全部挂载共享的app卷emptyDir从而完成代码 → 依赖 → 权限的交接。整个流程遵循init-containers 串行、先于主容器完成的语义因此主容器启动时应用代码已就绪。主容器运行方式主容器使用sudo -HEu bitnami npm start以bitnami用户身份启动应用并设置securityContext.readOnlyRootFilesystem: true根文件系统只读强化容器安全监听 8080 端口名为http存活探针httpGet /initialDelaySeconds: 180、timeoutSeconds: 5、failureThreshold: 6给予初始化与 npm 安装充分的时间就绪探针httpGet /initialDelaySeconds: 30、timeoutSeconds: 3、periodSeconds: 5。环境变量注入主容器通过如下环境变量与 MongoDB 通信环境变量取值来源MONGODB_HOST模板mongodb.fullname生成的 Service 名称MONGODB_PORT固定为27017MONGODB_ROOT_PASSWORDSecretmongodb-root-passwordsecretKeyRefMONGODB_USERNAMEmongodb.mongodbUsername未设置则为空串MONGODB_PASSWORDSecretmongodb-passwordsecretKeyRefMONGODB_DATABASEmongodb.mongodbDatabase未设置则为空串GIT_REPOrepository参数值其中密码类凭据均通过 Secret 的secretKeyRef引用而非明文写在 Pod 定义中。同时configmap.yaml 会把config内容以configfile默认database.js为 key 写入 ConfigMap主容器再以 volume 形式挂载到/app/config让应用能读取到注入的数据库连接配置。从上述结构可以推断本 Chart 的应用初始化完全依赖 init-containers 与共享卷不依赖任何外部 CI 流水线一条helm install命令即可完成从 Git 拉码到应用可用的全流程。持久化Node.js 应用持久化Bitnami Node 镜像将应用与配置存放在容器的/app路径。这一存储是**临时性ephemeral**的Pod 被删除后即消失。因此 Chart 提供可选的 PVC通过persistence.enabledtrue开启后pvc.yaml 会创建名为release-mean的 PersistentVolumeClaim存储类注解遵循旧版约定若显式定义storageClass则写入volume.beta.kubernetes.io/storage-class: storageClass否则使用默认的volume.alpha.kubernetes.io/storage-class: defaultPVC 挂载到/app/data即persistence.path与代码目录/app分离——源码仍走emptyDir只有数据目录持久化README 说明该持久化方案在 GCE、AWS 与 minikube 上验证可用。MongoDB 持久化MongoDB 子 Chart 的持久化参数前缀为mongodb.persistence.*默认关闭开启后创建 8Gi 的 PVC访问模式ReadWriteOnce存储类同样遵循定义则用 beta 注解、未定义则用 alpha 默认值的旧版约定。持久化的权衡需要特别指出主应用与 MongoDB 的持久化默认都是关闭的。对于演示或测试环境这没有问题但生产环境中数据库数据会随 Pod 重建而丢失。README 明确说明应用在容器初始化时克隆到 /app 卷因此不强制要求持久卷——这意味着默认配置牺牲数据持久性以换取部署的轻量生产部署时应显式开启mongodb.persistence.enabled。访问应用安装完成后NOTES.txt 会根据serviceType给出对应的访问指引NodePort通过kubectl get svc与kubectl get nodes拼出http://NODE_IP:NODE_PORT/LoadBalancer等待云厂商分配外部 IP 后访问http://SERVICE_IP/可用kubectl get svc -w观察分配过程可能需要数分钟ClusterIP仓库默认使用端口转发访问$ export POD_NAME$(kubectl get pods --namespace namespace -l apprelease-mean -o jsonpath{.items[0].metadata.name}) $ kubectl port-forward $POD_NAME 8080:80 $ echo http://127.0.0.1:8080/Service 定义见 svc.yaml类型由serviceType决定端口 80 转发到容器的http8080端口selector 匹配app: release-mean。部署自有应用的改造要点基于以上分析将该 Chart 用于部署你自己的 Node.js 应用时只需调整 values.yaml 中的少数参数repository改为你自己的 Git 仓库地址revision指定要检出的分支或提交号config/configfile如果你的应用有独立的配置文件如数据库连接、第三方密钥将其内容写入config并以configfile指定文件名Chart 会自动以 ConfigMap 形式挂载到/app/configmongodb.*设置数据库用户名、密码与库名若数据库由外部提供可考虑去掉子 Chart 依赖serviceTypeminikube 用NodePort云上可用LoadBalancer内部环境用ClusterIP加端口转发resources按实际负载调整 CPU/内存请求。需要注意的适用前提应用必须以npm start作为启动命令、监听 8080 端口并且config中引用的MONGODB_*环境变量命名要与 deployment.yaml 保持一致否则需要同时修改模板中的环境变量定义。排障要点与版本限制探针超时存活探针initialDelaySeconds为 180 秒这是为 init-containers 的 git clone 与 npm install 预留的时间。若大仓库安装依赖耗时过长可调大该值与failureThresholdinit-container 失败wait-for-db-service最多探测 100 次若 MongoDB 长时间未就绪会以状态码 1 退出。可用kubectl describe pod查看各 init-container 的状态与日志kubectl logs pod -c git-clone-app等Beta API 依赖模板使用extensions/v1beta1Deployment 与pod.beta.kubernetes.io/init-containers注解均属早期 Kubernetes API 形态。README 明确要求 Kubernetes 1.4 且启用 Beta API在新版本集群上部署时需要先确认这些 API 是否仍然受支持必要时可将 Deployment 升级为apps/v1并将 init-containers 迁移为spec.initContainers字段镜像来源仓库 values.yaml 中的镜像地址指向内部镜像仓库harbor-001.jimmysong.io若该地址不可达需将其替换为可访问的 Bitnami Node / MongoDB 镜像 tag。小结kubernetes-handbook 中的 mean Chart 是一个结构清晰、极具参考价值的 Helm 模板它演示了如何用 4 个 init-containers 串联等数据库 → 拉代码 → 装依赖 → 修权限的完整应用初始化流水线如何通过 ConfigMap 环境变量把数据库配置注入应用以及如何用 PVC 按需开启持久化。对于希望用 Helm 部署任意 Git 仓库型 Node.js 应用、或学习早期 Helm Chart 编排手法的开发者而言这份 Chart 及其 values.yaml、deployment.yaml 是可直接对照研读的完整范例。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考