ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

使用 Helm Chart 在 Kubernetes 上部署 Tandoor Recipes:values 配置、Secret 管理与流量接入实战

使用 Helm Chart 在 Kubernetes 上部署 Tandoor Recipes:values 配置、Secret 管理与流量接入实战 使用 Helm Chart 在 Kubernetes 上部署 Tandoor Recipesvalues 配置、Secret 管理与流量接入实战【免费下载链接】recipesApplication for managing recipes, planning meals, building shopping lists and much much more!项目地址: https://gitcode.com/GitHub_Trending/re/recipesTandoor Recipes即本仓库的recipes应用是一款用于管理菜谱、规划膳食、生成购物清单的开源食谱管理应用。本文将基于仓库中社区贡献的 docs/install/helmChart.md 指南完整讲解如何通过第三方 Helm Chartcsg33k/helm-charts中的tandoorchart在已有 PostgreSQL 的 Kubernetes 集群上快速部署 Tandoor Recipes包括values.yaml的每一项核心配置、环境变量与启动脚本的对应关系、Secret 的安全注入方式以及用 Gateway API 的HTTPRoute完成流量接入的完整流程。读完本文你将获得一份可直接复制落地、并理解其底层原理的 Helm 部署方案。指南性质与适用前提该指南由社区贡献既非官方支持也不会被官方持续更新或测试。使用时请结合 docs/install/helmChart.md 和 chart 发布方的最新values.yaml核对版本差异。在开始之前需要明确两个前提假设你已有一个可访问的 PostgreSQL 数据库。本 chart 的初始版本不负责创建数据库只负责部署应用本身数据库连接参数全部通过环境变量注入。chart 初始版本不内置 LoadBalancer。应用流量需要你自己通过 Ingress 清单或 Gateway API 的HTTPRoute指向 chart 创建出的 Service。另外需要特别注意 Tandoor 2 的兼容性变化根据 docs/install/kubernetes.md 的警告Tandoor 2 已将 nginx 服务集成进默认 Docker 容器并把服务端口从 8080 改为 80。本仓库的 Dockerfile 中EXPOSE 80 8080与 boot.sh 中的 nginx 启动逻辑印证了这一演进因此在配置路由或 Ingress 时请以你所使用镜像版本实际暴露的端口为准。核心配置values.yaml 逐项解析社区指南给出了一个基础最小化可运行的示例values.yaml本节逐段拆解并结合仓库源码解释每个参数的实际作用。命名空间与资源名称覆盖namespaceOverride: food fullnameOverride: recipesnamespaceOverride: food强制 chart 内所有资源包括下方extraResources中定义的 Secret都部署在food命名空间。后续的helm install、HTTPRoute都基于该命名空间编写。fullnameOverride: recipes覆盖 chart 自动生成的应用资源名称前缀最终应用 Service 名为recipes这也是后面HTTPRoute中backendRefs.name必须对齐的值。指南注明这两项并非必需只是为了保证与作者环境的命名一致使路由示例开箱可用。如果你的环境命名不同请同步修改HTTPRoute中的 backend 名称。global 段镜像与版本# Change to latest version if out of date. #global: # create_namespace: false # image: vabene1111/recipes # tandoor_version: 2.3global段整体被注释掉表示全部采用 chart 内置默认值create_namespace是否由 chart 自动创建命名空间默认为关闭false需提前手动建好food命名空间或由helm install -n food在目标集群策略允许时创建。image/tandoor_version镜像仓库地址与 Tandoor 版本标签。当前仓库主镜像为vabene1111/recipes解注释后按需调整版本例如2.3。建议显式锁定版本号以提升稳定性、避免意外迁移这一点与 docs/install/k8s/50-deployment.yaml 中建议显式指定 tag的建议一致。env 段应用环境变量env: ## Values below will get you to a basic working installation - name: DB_ENGINE value: django.db.backends.postgresql - name: POSTGRES_HOST value: shared-rw.postgres-operator.svc.cluster.local - name: POSTGRES_PORT value: 5432 - name: POSTGRES_DB value: fooddb - name: SECRET_KEY valueFrom: secretKeyRef: name: recipes-secrets key: secret-key - name: POSTGRES_USER valueFrom: secretKeyRef: name: recipes-secrets key: username - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: name: recipes-secrets key: password ## I skipped email support but feel free to add it as well.这些环境变量会被注入应用容器其消费逻辑可以直接在仓库启动脚本 boot.sh 中找到DB_ENGINE固定为 Django 的 PostgreSQL 后端django.db.backends.postgresql。boot.sh依据该值或DATABASE_URL以postgres开头判断是否进入等待数据库就绪与POSTGRES_PASSWORD校验分支。POSTGRES_HOST/POSTGRES_PORT/POSTGRES_DB数据库地址、端口与库名。boot.sh会用pg_isready --host${POSTGRES_HOST} --port${POSTGRES_PORT} --user${POSTGRES_USER}轮询等待数据库可用最多尝试 20 次、每次间隔 5 秒超时会打印诊断信息并以非零码退出容器。SECRET_KEY/POSTGRES_USER/POSTGRES_PASSWORD推荐通过secretKeyRef从 Kubernetes Secret 中引用避免明文写在values.yaml中。boot.sh会校验SECRET_KEY与POSTGRES_PASSWORD是否为空缺失时打印[WARNING]并继续启动但后续应用将无法正常工作因此务必正确注入。补充说明boot.sh还支持*_FILE形式的变量如SECRET_KEY_FILE、POSTGRES_PASSWORD_FILE容器启动时会自动读取文件内容填充对应变量。若你的 Secret 以文件卷形式挂载同样适用。persistence 段数据持久化persistence: enabled: true volumes: - name: staticfiles mountPath: /opt/recipes/staticfiles size: 1Gi - name: mediafiles mountPath: /opt/recipes/mediafiles size: 1Gienabled: true启用持久化声明PVC。两个卷分别挂载到容器内的/opt/recipes/staticfilesDjango 静态文件与/opt/recipes/mediafiles用户上传的图片等媒体文件。这两个路径与 boot.sh 中的默认值MEDIA_ROOT/opt/recipes/mediafiles、STATIC_ROOT/opt/recipes/staticfiles完全对应。指南特别强调虽然持久化并非严格必需但强烈建议创建否则每次 Pod 重启都会丢失已收集的静态文件与用户上传的媒体文件。boot.sh在启动时执行python manage.py collectstatic --noinput --clear重新收集静态文件媒体文件则不可再生必须落盘保存。extraResources 段一次性注入 Secret## In Production, use a different way of getting the secrets in. unless this code never leaves your server. ## In a Prod like homelab you should use ESO or Sealed Secrets, etc populate these values. extraResources: - apiVersion: v1 kind: Secret metadata: name: recipes-secrets namespace: food type: Opaque stringData: password: superSecretDBPass secret-key: ## output of openssl rand -base64 32 | tr -d / | head -c 32 username: db_usernameextraResources允许在安装 chart 的同时附带创建额外 Kubernetes 资源。这里用它直接声明了env段引用的recipes-secretsSecretOpaque 类型包含password、secret-key、username三个键secret-key生成方式openssl rand -base64 32 | tr -d / | head -c 32即取 32 字节随机数并裁剪为 32 字符的 Django SECRET_KEY。安全提醒原指南原文语义直接把 Secret 写进values.yaml仅适用于这份代码不会离开你的服务器的场景在类生产环境如 Homelab 生产应改用External Secrets OperatorESO或Sealed Secrets等方案来注入这些值不要把明文密钥提交到代码仓库。安装 Chart配置好values.yaml文件名可自定义如myvalues.yaml后执行helm install recipe-manager -n food oci://ghcr.io/csg33k/helm-charts/tandoor --version 0.0.1 -f myvalues.yaml参数含义参数说明recipe-manager本次 Helm Release 的名称-n food安装到food命名空间与namespaceOverride保持一致oci://ghcr.io/csg33k/helm-charts/tandoor以 OCI 方式拉取 chart无需手动添加 repo--version 0.0.1指定 chart 版本官方提示若过期请更新到最新版本-f myvalues.yaml覆盖默认值的自定义配置文件流量接入HTTPRoute 示例Chart 本身不创建 LoadBalancer安装完成后应用 Service名为recipes端口 80已就绪剩下就是如何把外部流量引进来。指南给出了基于Gateway API的HTTPRoute示例apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: food-https namespace: food spec: parentRefs: - name: http-gateway ## Change this namespace: default ## Change this sectionName: https hostnames: - food.domain.tld ## Change this rules: - backendRefs: - name: recipes ## If the name is different for your env, update it accordingly. port: 80需要修改的占位项parentRefs.name/parentRefs.namespace指向你集群中已部署的 Gateway 资源示例假定它名为http-gateway、位于default命名空间。parentRefs.sectionNameGateway 监听器名称示例为https。hostnames替换为你的真实域名如food.domain.tld。backendRefs.name必须与fullnameOverride生成的 Service 名一致此处为recipes端口 80。如果你使用的是传统 Ingress 控制器而非 Gateway API也可以参考仓库自带的 docs/install/k8s/70-ingress.yaml它展示了将/media、/static路径路由到 nginx 容器端口 80、其余流量路由到 gunicorn端口 8080的路径拆分写法并预留了 cert-manager 的 TLS 注释模板默认注释状态。与 Manifest 部署方式的对照参考除了 Helm Chart本仓库还维护了一套可直接kubectl apply的清单文件位于 docs/install/k8s/对应指南为 docs/install/kubernetes.md。两套方案的架构思路高度一致可互为印证关注点Helm Chart本文Manifest 方式数据库复用外部 PostgreSQL40-sts-postgresql.yaml 自带 Bitnami PostgreSQL StatefulSet数据卷 2Gi、runAsUser: 1001低权限运行init 容器以 root 准备目录静态/媒体文件persistence声明两个 1Gi 卷30-pvc.yaml 声明recipes-media、recipes-static两个 1Gi PVC初始化流程chart 内置逻辑50-deployment.yaml 的init-chmod-datainit 容器执行migrate、collectstatic并修正媒体目录属主与 boot.sh 的启动流程对应SecretextraResources注入15-secrets.yaml 预置明文必须替换或用kubectl create secret generic recipes --from-file...生成流量入口HTTPRouteGateway API70-ingress.yamlrecipes.local占位域名需修改Manifest 方式还给出了一些 Helm 指南未展开的运维细节可作为补充参考应用主容器recipes以runAsUser: 65534nobody低权限运行gunicorn 绑定:8080配置了 liveness/readiness 探针nginx 容器通过 ConfigMap 10-configmap.yaml 提供/static/、/media/的静态文件服务。如果你需要按需微调探针、资源配额或安全上下文直接阅读并修改这些清单会比改写 chart 更直观。安装后的检查要点数据库连通性boot.sh会在启动时轮询pg_isready失败 20 次后容器会打印Database not reachable. Maximum attempts exceeded.并退出此时优先核对POSTGRES_HOST/POSTGRES_PORT/POSTGRES_USER是否正确。静态文件容器启动时执行collectstatic --noinput --clear首次启动耗时较长属正常现象若通过 nginx 独立服务静态文件需确认挂载的staticfiles卷内容完整。Secret 一致性env段与extraResources中的 Secret 键名必须一一对应secret-key、username、password拼写不一致会导致应用启动时读取不到凭据。版本锁定建议像 docs/install/k8s/50-deployment.yaml 强调的那样显式固定镜像 tag避免latest在升级时触发不必要的数据库迁移。完成以上步骤后你的 Tandoor Recipes 就已通过 Helm Chart 运行在 Kubernetes 集群中外部流量经由HTTPRoute到达recipesService。Happy cooking!【免费下载链接】recipesApplication for managing recipes, planning meals, building shopping lists and much much more!项目地址: https://gitcode.com/GitHub_Trending/re/recipes创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表