phpMyAdmin Helm 部署失败主因是误用已弃用的 stable 仓库，应改用 bitnami/phpmyadmin；需正确配置 Ingress+TLS+认证、MySQL 连接参数及资源限制与 session 存储。
phpMyAdmin Helm Chart 部署失败常见报错：failed to download chart 或 repository not found
直接原因通常是 helm 仓库没加对，或者用的是已弃用的旧仓库。官方 phpmyadmin chart 已从 stable 仓库移除（2020 年起），现在由社区维护在 https://github.com/helm/charts 的归档分支中，但主流推荐是改用 bitnami/phpmyadmin —— 它持续更新、镜像可信、rbac 和 ingress 支持更完整。
实操建议：
- 运行
helm repo add bitnami https://charts.bitnami.com/bitnami，再helm repo update - 别用
stable/phpmyadmin，它已不可用，强行helm pull stable/phpmyadmin会报no such chart - Bitnami 版默认不暴露服务，必须显式设置
service.type=LoadBalancer或配ingress.enabled=true，否则部署完看不到入口
如何安全暴露 phpMyAdmin：Ingress 配置绕不开 TLS 和认证
裸露 NodePort 或 ClusterIP 直接对外等于把数据库管理后台挂公网上，实际生产中基本不可行。Ingress 是标准解法，但 Bitnami Chart 的 ingress 块默认只生成规则，不自动配证书或基础认证。
实操建议：
- 启用 ingress：设
ingress.enabled=true，并填ingress.hostname=phpmyadmin.example.com - TLS 必须手动提供 Secret：提前创建
kubectl create secret tls phpmyadmin-tls --cert=tls.crt --key=tls.key -n default，再通过ingress.tls.secretName=phpmyadmin-tls引用 - Basic Auth 不内置：得自己加
nginx.ingress.kubernetes.io/auth-type: basic注解，并挂载包含htpasswd文件的 Secret 到 Ingress Controller - 若用 Let's Encrypt，需配合
cert-manager，Chart 本身不集成 ACME 流程
连接 MySQL 时提示 mysqli::real_connect(): (HY000/1045): Access denied
这不是 phpMyAdmin 本身问题，而是它连不上后端 MySQL 服务——最常踩的坑是 Service 名写错、端口没对上、或 MySQL 用户权限不足。Bitnami Chart 默认生成的 auth.rootPassword 只用于初始化 root，不自动授权给 phpMyAdmin 连接用的用户。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 确认 MySQL Service 名：若 MySQL 是独立部署，phpMyAdmin 的
mysql.host必须设成mysql.default.svc.cluster.local（命名空间+服务名+svc.cluster.local） - 检查端口：MySQL 默认是
3306，但 Bitnami MySQL Chart 默认暴露3306，而 phpMyAdmin Chart 的mysql.port默认也是3306，保持一致即可 - 权限要手动开：进 MySQL Pod 执行
CREATE USER 'pma'@'%' IDENTIFIED BY 'xxx'; GRANT ALL ON *.* TO 'pma'@'%'; FLUSH PRIVILEGES;，再把mysql.auth.username=pma和mysql.auth.password=xxx传给 phpMyAdmin - 别依赖
mysql.auth.existingSecret自动注入：它只读 Secret 里的 key，字段名必须严格匹配username/password，拼错就静默失败
资源限制和 Session 存储导致登录后白屏或 500
phpMyAdmin 在 K8s 里跑久了容易因内存溢出或 session 写入失败崩掉，尤其默认用 tmpfs 存 session —— Pod 重启就丢，且没设 limits 时可能被 OOMKilled。
实操建议：
- 必须设资源限制：
resources.limits.memory=256Mi，resources.requests.memory=128Mi；不设的话，小规格节点上极易被驱逐 - Session 存到 Redis 更稳：启用
redis.enabled=true，并配session.saveHandler=redis和session.savePath="tcp://redis:6379" - 若坚持用文件存储，挂
emptyDir并设session.gcMaxLifetime=1440，否则默认 1440 秒后 session 清理逻辑可能卡住 - PHP 错误日志默认不输出到 stdout：加
extraEnv[0].name=PHP_ERROR_LOG+extraEnv[0].value=/dev/stderr，方便kubectl logs排查
真正麻烦的不是部署命令敲几行，而是 MySQL 权限粒度、Ingress TLS 绑定时机、以及 session 在无状态环境里的存续方式——这三块不动手试两遍，配置文件里写的都是纸上参数。
