组织级自托管GitHub Runner无法扩容问题求助

核心问题定位 #

日志提示Skipped reconcilation because owner is not synced yet，说明RunnerReplicaSet对应的所有者资源（此处为orglevel-gh-runner-wzx5r-wgf6f）未完成同步，导致控制器跳过扩容逻辑。仓库级配置正常，问题聚焦在组织级资源的同步环节。

具体排查步骤 #

1. 检查组织级Runner资源状态 #

执行命令查看资源详情，确认同步状态：

kubectl get runners.actions.summerwind.dev -n actions-runner-controller
kubectl describe runner orglevel-gh-runner-wzx5r-wgf6f -n actions-runner-controller

重点关注Status下的Synced状态，以及Events中是否存在同步失败报错（如权限不足、网络异常）。

2. 验证组织级Token权限 #

仓库级Token可用不代表组织级权限达标：

• 确保Token拥有admin:org权限（至少需org:read+repo:read，管理Runner需admin:org）
• 确认Token是组织全局Token，未被限制到特定仓库

3. 检查控制器与GitHub API连通性 #

组织级资源同步依赖控制器调用GitHub组织API：

• 进入控制器Pod，执行curl -v https://api.github.com/orgs/[你的组织名]测试连通性
• 若使用GitHub Enterprise，确认控制器配置了正确的github-server-url，且证书信任正常

4. 排查RunnerReplicaSet与所有者资源的关联 #

确认资源引用正确性：

kubectl describe runnerreplicaset orglevel-gh-runner-wzx5r -n actions-runner-controller

查看Owner References字段，确认指向的Runner资源存在且状态正常。

5. 校验Horizontal Runner Autoscaler（HRA）配置 #

若使用HRA，需排查：

• scaleTargetRef是否正确指向组织级Runner资源，而非仓库级
• 组织级Runner的spec.replicas未被手动设为固定值（避免与HRA逻辑冲突）

6. 强制触发资源同步 #

若以上检查无异常，可删除异常Runner资源，让控制器重建同步：

kubectl delete runner orglevel-gh-runner-wzx5r-wgf6f -n actions-runner-controller

等待资源重建后，观察同步状态与扩容情况。

补充说明 #

仓库级Runner正常说明控制器核心功能无问题，问题大概率出在组织级资源的API权限、同步逻辑或资源关联上，重点聚焦GitHub组织API的调用权限与控制器同步状态即可。

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