不推荐用Kubernetes部署Gitea，因其单进程、低资源、无状态（除数据卷外）特性与K8s复杂性不匹配；硬套会增加运维负担、启动延迟，并引发多实例数据冲突、SSH连接异常等问题。
直接用 Kubernetes 部署 Gitea 是可行的，但不推荐——除非你明确需要 Pod 级弹性伸缩、多集群灰度发布或与现有 K8s 告警/监控深度集成。Gitea 本身是单进程、低资源、无状态（除数据卷外）服务，硬套 K8s 反而增加运维负担和启动延迟。
为什么不用 Helm Chart 直接部署
Helm 官方仓库里的 gitea/gitea Chart（如 stable/gitea 已弃用）目前维护滞后，最新版普遍卡在 v1.20.x，而 Gitea 主线已到 v1.22.x；Chart 默认启用 replicaCount: 2，但 Gitea 不支持多实例共享同一数据库（会触发 session 冲突、hook 执行重复、SSH key 写入竞争）；且 Chart 把 app.ini 配置硬编码进 ConfigMap，每次改域名或 SMTP 就得 kubectl apply + rollout restart，比 Docker Compose 还麻烦。
StatefulSet + hostPath 是最简可行方案
如果你必须走 K8s，用 StatefulSet 替代 Deployment，配合 hostPath 或 NFS 持久卷，能规避多数一致性问题：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
-
volumeClaimTemplates必须显式声明，不能依赖默认 StorageClass（否则 PVC 可能跨节点调度，导致 Git 数据错乱） - SSH 端口映射必须用
hostPort: 2222（而非 NodePort），否则 K8s 的 conntrack 会干扰 SSH 的长连接 handshake - 务必设置
podAntiAffinity，禁止同一节点起多个 Gitea Pod——哪怕只部署一个副本，也防误扩缩容 - 健康检查只用
httpGet对/api/v1/version，别用exec调git --version，容器内没装 git 二进制时会反复重启
更推荐的替代路径：Docker Compose + systemd
在单节点 K8s（如 MicroK8s、k3s）宿主机上，直接用 docker-compose.yml 启动 Gitea，再用 systemd 管理其生命周期，实际效果更稳：
- 启动耗时从 K8s 的平均 42s（含调度+拉镜像+initContainer）降到
docker compose up -d的 6s 内 - 备份只需
tar -czf gitea-backup-$(date +%F).tar.gz /var/gitea，不用写 CronJob + PVC 清理逻辑 - 升级时停旧容器、换新镜像、重挂卷，全程无 Pod 删除重建带来的 webhook 中断风险
- 若需 HTTPS，直接在宿主机跑
certbot+ Nginx 反代，比 K8s Ingress Controller 少两层 TLS 终止
真正容易被忽略的是：Gitea 的 APP_DATA_PATH 和 Git 仓库路径必须落在同一挂载点下，否则 git gc 触发时可能因 cross-device link 失败；这个限制在 K8s 里常被 volume 分离配置掩盖，直到某天仓库变慢才暴露。
