Kubernetes上自托管Gitlab：新Helm发布时Runner注册异常

问题背景 #

• 在GKE环境通过Terraform helm_release 部署官方Gitlab Helm Chart，全局启用Gitlab Runner组件
• 依赖外部云服务：Cloud SQL（数据库）、MemoryStore（Redis缓存）、Cloud Storage（对象存储）
• 首次部署完全正常，但更换Helm发布名称（无版本升级，属于全新安装而非升级）时出现以下异常：
  • 新Gitlab Runner Pod无法完成注册，持续处于错误状态
  • 后台Admin区域的Runners页面返回500内部服务器错误
  • 数据库迁移任务从版本1开始执行，最终因对象已存在等冲突失败
  • 其余Pod运行正常，Web界面可访问，原有数据完整（因复用同一外部组件）
  • 复用旧发布名称重新部署可恢复正常，但旧Runner仍显示在线且无法被新实例调度

核心原因与关联解释 #

1. Gitlab Runner注册的身份与数据冲突 #

Gitlab Runner注册依赖Gitlab实例生成的注册令牌，且注册后会在数据库中写入与实例绑定的Runner记录。当新发布的实例复用旧实例的数据库时：

• 新Runner尝试注册时，数据库中已存在旧发布关联的Runner记录（含相同的实例标识或令牌关联关系），导致Gitlab API拒绝新注册请求
• 新实例的内部上下文（如Pod名称、组件标识符）与旧实例残留的数据库记录不匹配，查询Runner数据时触发未处理的异常，直接导致Admin页面500错误

2. 数据库迁移的全局版本锁冲突 #

Gitlab通过schema_migrations表追踪已执行的数据库迁移版本。当新发布的实例连接到已有迁移记录的数据库时：

• 新实例默认会以"全新安装"的逻辑检查迁移状态，忽略已存在的schema_migrations记录，尝试从头执行所有迁移
• 已存在的数据库表、约束会与新迁移的DDL操作冲突，导致迁移任务失败
• 本质上Gitlab数据库为实例专属，不支持多独立Helm发布共享同一数据库实例

3. 外部缓存的上下文冲突 #

新发布的Gitlab实例复用同一MemoryStore（Redis）时，Redis中存储的旧实例缓存数据（如Session、Runner状态缓存）会与新实例的上下文冲突：

• 新实例查询Runner状态时，读取到旧实例的缓存数据，导致逻辑异常，进一步触发Admin页面的500错误

解决建议 #

• 复用发布名称执行升级：若仅需更新配置而非创建新实例，使用同一Helm发布名称执行helm upgrade操作，确保组件上下文、令牌、数据库迁移记录的一致性
• 隔离外部依赖实例：每个独立的Gitlab Helm发布（不同发布名）需使用专属的Cloud SQL、MemoryStore实例及Cloud Storage Bucket，避免跨实例的数据冲突
• 手动清理残留数据（不推荐）：若必须复用同一数据库，需手动清理旧发布的残留数据：
  • 删除runners表中旧发布关联的所有记录
  • 确认schema_migrations表记录完整后，临时设置migrations.enabled: false跳过迁移（仅适用于同版本Gitlab）

内容的提问来源于stack exchange，提问作者Alssanro