教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载本篇技术指南以当前仓库manifests/charts/mongodb目录下的 Bitnami MongoDB Helm Chart 为核心完整讲解如何在 Kubernetes 集群中通过 Helm 一键部署 MongoDB、配置管理员与业务账号、开启持久化存储并结合 Chart 模板源码剖析其工作原理。读完本文你将掌握该 Chart 的安装、参数化配置、持久化、健康检查与卸载的完整实战流程并理解 Deployment、Secret、PVC、Service 四类 Kubernetes 资源在数据库部署中的协同方式。1. MongoDB 与 Helm Chart 简介MongoDB 是一款跨平台的文档型document-orientedNoSQL 数据库。与基于表的传统关系型数据库不同MongoDB 采用类 JSON 的文档模型和动态模式dynamic schema无需预先定义表结构这使得它在内容驱动型应用、日志与指标存储、物联网数据等场景中集成数据更加容易和快速。本仓库中的manifests/charts/mongodb是一个可直接使用的 Helm Chart它基于 Bitnami MongoDB 镜像 可以看到该 Chart 的版本为0.4.17对应应用版本appVersion为3.4.9模板引擎为gotpl维护方为 Bitnami关键字为mongodb、database、nosql。2. Chart 目录结构总览在动手部署前先熟悉该 Chart 的完整文件结构manifests/charts/mongodb/ ├── Chart.yaml # Chart 元信息名称、版本、描述、维护者 ├── README.md # 官方使用说明本文的主体参考 ├── values.yaml # 可配置参数及其默认值 └── templates/ # 渲染 Kubernetes 资源的 Go 模板 ├── NOTES.txt # 安装成功后输出的使用提示访问地址与连接命令 ├── _helpers.tpl # 模板辅助函数Chart 名称与完整名称的生成规则 ├── deployment.yaml # DeploymentMongoDB 容器、环境变量、探针、数据卷 ├── pvc.yaml # PersistentVolumeClaim数据持久化声明 ├── secrets.yaml # Secret管理员与业务账号密码 └── svc.yaml # Service集群内访问入口其中templates/deployment.yaml负责生成 Deployment容器与探针secrets.yaml生成存储密码的 Secretpvc.yaml生成持久化卷声明svc.yaml生成访问 Service。这四类模板与values.yaml中的参数一一对应下文将结合源码逐一展开。3. 环境前置要求根据 Chart 官方文档manifests/charts/mongodb/README.md在安装前需要确认以下前提Kubernetes 1.4且已启用 Beta API本 Chart 的 Deployment 模板使用extensions/v1beta1API 版本见templates/deployment.yaml第 1 行属于早期 Kubernetes 版本约定的 API 组集群需兼容该 API底层基础设施支持 PV provisioner动态卷供应当开启持久化时PVC 需要集群具备可用的 StorageClass 与动态卷供应能力如 AWS 的 gp2、GKE 的标准盘等。说明该 Chart 面向 Kubernetes 1.4 时代编写若你在较新版本集群中使用extensions/v1beta1已逐步废弃建议结合集群实际版本评估是否需要对模板的 apiVersion 做适配本仓库仅作为离线镜像与示例用途保存该 Chart。4. 快速安装与卸载4.1 一行命令安装使用默认配置部署 MongoDB$ helm install stable/mongodb如需指定 release 名称使用--name参数$ helm install --name my-release stable/mongodb执行后Helm 会将templates/下所有模板渲染为实际的 Kubernetes 资源并提交到集群。安装成功后可通过helm list查看所有已部署的 release。4.2 卸载卸载/删除名为my-release的部署$ helm delete my-release该命令会移除与 Chart 关联的所有 Kubernetes 组件Deployment、Service、Secret 等并删除 release 记录。注意PVC 默认策略下不会随helm delete立即删除如需彻底清理持久化数据请结合kubectl delete pvc处理详见第 7 节。5. 配置参数详解从参数表到模板源码Chart 的完整可配置参数见下表整理自manifests/charts/mongodb/README.md与values.yaml参数描述默认值imageMongoDB 镜像bitnami/mongodb:{VERSION}本仓库为harbor-001.jimmysong.io/library/bitnami-mongodb:3.4.9-r1imagePullPolicy镜像拉取策略若镜像 tag 为latest则为Always否则为IfNotPresentmongodbRootPasswordMongoDB 管理员root密码空nilmongodbUsername自定义业务用户空nilmongodbPassword自定义业务用户密码空nilmongodbDatabase要创建的数据库空nilserviceTypeKubernetes Service 类型ClusterIPpersistence.enabled是否使用 PVC 持久化数据true本仓库values.yaml中实际为falsepersistence.storageClass后端 PVC 的存储类空使用 alpha storage class 注解persistence.accessMode卷访问模式只读/读写ReadWriteOncepersistence.size数据卷大小8Gi细节提示README 参数表中persistence.enabled的默认值为true但当前仓库的values.yaml第 31 行实际设置为false即默认不开启持久化使用 emptyDir同时image也被替换为本地 Harbor 仓库地址。这说明该 Chart 在仓库中经过了离线化与轻量化定制部署时请以仓库内values.yaml的实际默认值为准并按需通过参数覆盖。5.1 参数如何映射到环境变量这些参数并非仅存在于 Helm 层而是通过模板映射为 Bitnami MongoDB 镜像所识别的环境变量。查看templates/deployment.yaml中容器定义部分env: - name: MONGODB_ROOT_PASSWORD valueFrom: secretKeyRef: name: {{ template mongodb.fullname . }} key: mongodb-root-password - name: MONGODB_USERNAME value: {{ default .Values.mongodbUsername | quote }} - name: MONGODB_PASSWORD valueFrom: secretKeyRef: name: {{ template mongodb.fullname . }} key: mongodb-password - name: MONGODB_DATABASE value: {{ default .Values.mongodbDatabase | quote }}可以看到mongodbRootPassword与mongodbPassword不直接以明文写入 Deployment而是通过secretKeyRef从secrets.yaml生成的 Secret 中引用secrets.yaml使用b64enc管道对密码做 Base64 编码后存入Opaque类型的 Secrettype: Opaque data: mongodb-root-password: {{ default .Values.mongodbRootPassword | b64enc | quote }} mongodb-password: {{ default .Values.mongodbPassword | b64enc | quote }}mongodbUsername与mongodbDatabase则通过default 与quote管道直接注入未配置时为空字符串。这种敏感信息走 Secret、普通信息走环境变量的拆分方式避免了管理员密码以明文形式出现在 Pod 的 spec 中是值得在自研 Chart 中复用的安全实践。5.2 使用--set指定参数安装时可通过--set keyvalue多个参数用逗号分隔覆盖任意参数。例如$ helm install --name my-release \ --set mongodbRootPasswordsecretpassword,mongodbUsernamemy-user,mongodbPasswordmy-password,mongodbDatabasemy-database \ stable/mongodb该命令的效果是将 MongoDBroot账号密码设为secretpassword同时创建一个标准数据库用户my-user密码my-password并赋予其访问名为my-database的数据库的权限。容器首次启动时Bitnami MongoDB 镜像会根据上述环境变量自动完成 root 密码初始化与业务库/业务用户的创建参见 Bitnami 镜像的 first-run 逻辑。5.3 使用 values 文件批量配置当参数较多时更推荐将配置写入 YAML 文件通过-f参数加载$ helm install --name my-release -f values.yaml stable/mongodb仓库内的默认 values.yaml 即为可参考的配置模板它额外展示了以下未被 README 参数表列出的字段resources.requests.memory: 256Mi、resources.requests.cpu: 100m容器资源请求会通过toYaml管道整体注入 Deployment 的resources字段见templates/deployment.yaml第 57-58 行persistence.storageClass的三种取值语义见下文第 6 节imagePullPolicy缺省时的行为默认留空由 kubelet 依据镜像 tag 是否为latest决定。6. 持久化存储PVC、StorageClass 与数据目录Bitnami MongoDB 镜像将数据与配置存放在容器内的/bitnami/mongodb路径。Chart 通过挂载 Persistent Volume 到该位置并使用动态卷供应dynamic volume provisioning创建卷从而保证 Pod 重建或漂移后数据不丢失。6.1 数据卷的挂载逻辑在templates/deployment.yaml中数据卷的处理逻辑如下volumeMounts: - name: data mountPath: /bitnami/mongodb ... volumes: - name: data {{- if .Values.persistence.enabled }} persistentVolumeClaim: claimName: {{ template mongodb.fullname . }} {{- else }} emptyDir: {} {{- end -}}当persistence.enabledtrue时挂载名为release-mongodb的 PVC当persistence.enabledfalse本仓库默认时使用emptyDir——这意味着Pod 被删除或重建后数据会随之丢失仅适合开发、测试或临时环境。6.2 PVC 与 StorageClass 的三种取值PVC 由templates/pvc.yaml生成{{- if .Values.persistence.enabled }} kind: PersistentVolumeClaim apiVersion: v1 metadata: name: {{ template mongodb.fullname . }} spec: accessModes: - {{ .Values.persistence.accessMode | quote }} resources: requests: storage: {{ .Values.persistence.size | quote }} {{- if .Values.persistence.storageClass }} {{- if (eq - .Values.persistence.storageClass) }} storageClassName: {{- else }} storageClassName: {{ .Values.persistence.storageClass }} {{- end }} {{- end }} {{- end }}结合values.yaml中的注释persistence.storageClass有三种语义不设置默认PVC 中不声明storageClassName由集群选择默认 provisionerAWS 上为 gp2GKE/AWS/OpenStack 上为 standard设置为-渲染为storageClassName: 禁用动态供应此时需要集群中已有静态 PV 与 PVC 匹配设置为具体存储类名如fast、standardPVC 会显式绑定到该 StorageClass。实践建议生产环境务必设置persistence.enabledtrue并合理指定persistence.size默认 8Gi与persistence.accessMode默认ReadWriteOnce即同一时刻仅一个节点可读写适合单副本 MongoDB。由于本 Chart 默认单副本且未启用副本集模式ReadWriteOnce是合适的访问模式。7. 容器健康检查存活探针与就绪探针templates/deployment.yaml为 MongoDB 容器定义了两类探针均通过mongo客户端执行db.adminCommand(ping)来验证数据库可用性livenessProbe: exec: command: - mongo - --eval - db.adminCommand(ping) initialDelaySeconds: 30 timeoutSeconds: 5 readinessProbe: exec: command: - mongo - --eval - db.adminCommand(ping) initialDelaySeconds: 5 timeoutSeconds: 1livenessProbe存活探针首次探测延迟 30 秒、超时 5 秒。若ping持续失败kubelet 会判定容器不健康并依据restartPolicy重启容器用于恢复卡死或异常状态readinessProbe就绪探针首次探测延迟 5 秒、超时 1 秒。Pod 只有在就绪探针通过后才会被 Service 纳入 Endpoints从而保证流量不会打到尚未就绪的数据库实例。由于探针执行依赖容器内存在mongo客户端Bitnami MongoDB 镜像内置这一设计无需额外部署 sidecar实现轻量。当容器初始化需要较长时间例如首次建库、导入大文件时可通过调整initialDelaySeconds避免误判重启。8. 访问 MongoDBService 与集群内连接8.1 Service 定义templates/svc.yaml生成 ClusterIP 类型的 Service默认serviceType: ClusterIP可通过--set serviceTypeNodePort/LoadBalancer覆盖spec: type: {{ .Values.serviceType }} ports: - name: mongodb port: 27017 targetPort: mongodb selector: app: {{ template mongodb.fullname . }}Service 将 27017 端口映射到容器的mongodb命名端口templates/deployment.yaml中定义containerPort: 27017并通过app标签选择对应的 Pod。8.2 安装后的访问提示Chart 内置的 NOTES.txt 在helm install成功后会自动打印访问方式。集群内可通过如下 DNS 名称访问数据库release-mongodb.namespace.svc.cluster.local使用临时客户端 Pod 连接数据库kubectl run release-mongodb-client --rm --tty -i --image bitnami/mongodb --command -- mongo --host release-mongodb若设置了mongodbRootPassword连接命令会附加-p password参数。若需要从集群外部访问可将serviceType改为NodePort或LoadBalancer并结合业务场景评估暴露风险。9. 命名规则_helpers.tpl 中的模板函数所有资源的名称均由templates/_helpers.tpl中的两个辅助函数生成{{- define mongodb.name -}} {{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix - -}} {{- end -}} {{- define mongodb.fullname -}} {{- $name : default .Chart.Name .Values.nameOverride -}} {{- printf %s-%s .Release.Name $name | trunc 63 | trimSuffix - -}} {{- end -}}mongodb.nameChart 基础名称支持通过nameOverride覆盖mongodb.fullnamerelease名称-chart名称的拼接形式并截断至 63 字符遵循 DNS 命名规范对 Kubernetes 名称字段的长度限制。这解释了为什么安装时指定--name my-release后生成的 Deployment、Service、Secret、PVC 名称均为my-release-mongodb。理解这一规则便于在kubectl get和日志排查时快速定位资源。10. 部署流程串联一次安装背后的资源编排综合以上各节执行helm install --name my-release -f values.yaml stable/mongodb时Chart 会渲染并依次提交以下资源Secretmy-release-mongodb存储 Base64 编码的 root 密码与业务用户密码Deploymentmy-release-mongodb引用 Secret 中的密码注入环境变量挂载数据卷配置存活/就绪探针与资源请求PVCmy-release-mongodb当persistence.enabledtrue时声明 8Gi 存储卷并绑定 StorageClassServicemy-release-mongodb以 ClusterIP 暴露 27017 端口供集群内应用通过release-mongodb.namespace.svc.cluster.local访问。容器首次启动时Bitnami 镜像依据MONGODB_ROOT_PASSWORD、MONGODB_USERNAME、MONGODB_PASSWORD、MONGODB_DATABASE环境变量完成 root 初始化与业务库创建此后通过 liveness/readiness 探针维持健康状态数据落盘至 PVC开启持久化时实现数据库的有状态运行。11. 卸载与数据清理注意事项执行helm delete my-release后Deployment、Service、Secret 等资源会被删除但需要注意若开启了持久化PVC 及其绑定的 PV 默认不会随 release 删除取决于集群的回收策略Retain策略下 PV 需手动处理如需彻底清理数据在确认数据已备份后手动执行kubectl delete pvc my-release-mongodb若persistence.enabledfalse本仓库默认Pod 删除即数据清空卸载无需额外清理。12. 总结本仓库manifests/charts/mongodb提供了一个结构清晰、开箱即用的 MongoDB Helm Chart 参考实现。本文从安装、卸载、参数化配置、持久化存储、健康检查到资源编排完整还原了其使用方式并结合templates/源码剖析了参数→环境变量→Secret/PVC/Service 的映射链路。该 Chart 既可用于在 Kubernetes 上快速部署 MongoDB 单实例也可作为编写自有有状态服务 Chart 的模板范式——尤其是密码入 Secret、数据挂 PVC、健康走探针、访问经 Service的四件套设计值得在数据库类应用部署中直接借鉴。如需进一步了解 Chart 的离线定制细节可直接查看仓库内的 values.yaml 与 Chart.yaml若希望将 MongoDB 与 Kubernetes 持久化存储方案如 Ceph、GlusterFS、NFS结合可继续阅读仓库practice/目录下的 using-ceph-for-persistent-storage.md、using-nfs-for-persistent-storage.md 等实践文档。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用kubernetes-handbook 中的 mean Chart 实战指南在 Kubernetes 上使用 Helm Chart 部署 MEAN 应用kubernetes handbook 中的 mean Chart 实战指南 导读教程云原生容器编排OpenViking Helm Chart 部署指南在 Kubernetes 上以 Helm 一键部署 AI Agent 上下文数据库OpenViking Helm Chart 部署指南在 Kubernetes 上以 Helm 一键部署 AI Agent 上下文数据库 导读 本文基于 Ope人工智能AI AgentAgent 记忆RAG后端数据库Helm 实战使用 MariaDB 官方 Chart 在 Kubernetes 上部署高可用数据库集群Helm 实战使用 MariaDB 官方 Chart 在 Kubernetes 上部署高可用数据库集群 本指南以当前仓库中随测试样例附带的一份经典 Bitna云原生容器编排CLI运维创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
企业数字化 ERP 产品动态
相关推荐
网络入侵检测:CNN特征提取+随机森林的分层架构设计 简介:本资源是一套面向计算机、人工智能及相关专业本科生的网络入侵检测课程设计与毕业设计实战项目,聚焦于融合深度学习与传统机器学习的二分类安全检测任务。项目基于UNSW_NB15真实数据集(42维特征标签),完整实现从数… · 2026/9/23 18:41:59
360网神选型避坑指南:5个最佳实践解决代码跑不通难题 360网神选型避坑指南:5个最佳实践解决代码跑不通难题 复制来的代码跑不通不知道怎么调,这种崩溃感谁懂?别急着骂人,大概率是环境配置和依赖版本没对齐。做技术选型和后端开发, 最佳实践… · 2026/9/23 18:41:53
伏安特性与电源外特性测量:从内接外接到数据处理全解析 做过这个实验的同学应该都有同感:电路元件伏安特性的测绘及电源外特性的测量,看起来就是把电压表电流表接上去读数据,但真正动手之后才发现,光是一个“电流表内接还是外接”就能让你数据偏到怀疑人生。这篇内容我会把整个实验从原… · 2026/9/23 20:18:31
集装箱类型与尺寸全解析:外贸装柜选型避坑指南 做外贸第一年,我最怕客户突然问一句“这个柜子能装多少”。不是不会算,而是很多人把集装箱想得太简单了——铁皮箱子嘛,长宽高一乘不就是体积?实际跑几次装柜现场你就知道,集装箱的类型、尺寸和内径数据里全是门道。选… · 2026/9/23 20:18:31
BCD码原理与工业实战:嵌入式系统中的确定性数字表达 1. 为什么今天还要学BCD码——一个被低估的“数字翻译官”很多人第一次听说BCD码,是在单片机实验课上看到数码管突然亮起一串“0100 0011 0101”,老师说:“这是435的BCD表示。”台下一片茫然:明明二进制就能表示一切,为… · 2026/9/23 20:18:20
3个避坑指南:扫描全能王官网技术原理从入门到精通 3个避坑指南:扫描全能王官网技术原理从入门到精通 面对满屏红色的 StackTrace,你是不是脑子嗡的一声,完全不知道从哪行代码看起?这种报错一堆看不懂的感觉,是无数开发者从新手走向老手的必经关卡。很多初学者在接触类似扫描全能王官网这样的… · 2026/9/23 20:18:13
3招搞定手机怎么下载微信面试难题实战项目解析 3招搞定手机怎么下载微信面试难题实战项目解析 面试被问“手机怎么下载微信”背后的原理,90%的人答不上来。别笑,这看似弱智的问题,实则是考察你对移动应用分发机制、安全校验及网络协议理解的试金石。我带过不少校招新人,他们背了八股文,却连一个A… · 2026/9/23 0:00:03
你有新短消息请注意查收:3个新手避坑指南搞定消息系统选型 你有新短消息请注意查收:3个新手避坑指南搞定消息系统选型 面试被问“高并发下如何保证消息不丢失”,你张口就是“用Redis”,结果面试官追问“如果Redis宕机了怎么办”,你瞬间卡壳。这种场景太常见了,很多新手在背八股文时,只记住了技术名词… · 2026/9/23 0:00:29