actions-runner-controller 资源标签体系详解用 Kubernetes 推荐标签实现 ARC 组件日志的精准筛选【免费下载链接】actions-runner-controllerKubernetes controller for GitHub Actions self-hosted runners项目地址: https://gitcode.com/GitHub_Trending/ac/actions-runner-controller导读在 GitHub Actions self-hosted runner 的 Kubernetes 控制器actions-runner-controller简称 ARC中当用户遇到问题需要寻求支持时第一件事往往是定位并收集相关组件的日志。本文基于仓库中 ADR 2022-12-05 的原始决策完整讲解 ARC 为 controller-manager、Listener、Runner 三类组件设计的统一标签规范并结合 constants.go 与 resourcebuilder.go 等源码实现说明这些标签如何被自动注入、如何通过一条kubectl命令精确筛选出全部 ARC 相关日志以及该方案在后续 ADR 2023-03-14 中的演进。背景为什么需要统一的资源标签支持与排障的核心痛点ADR 2022-12-05 开篇就点明了设计动机Users need to provide us with logs so that we can help support and troubleshoot their issues. We need a way for our users to filter and retrieve the logs we need.ARC 的架构由多个移动部件组成负责协调的控制平面controller-manager、负责与 GitHub Actions 服务通信的 Listenerrunner-scale-set-listener、以及实际执行 Job 的 Runner 容器。当用户报告问题时支持人员无法确定日志散落在哪些 Pod 里用户也往往不理解 ARC 内部各组件的名称与分工。解决方案的核心思路非常朴素为 ARC 创建的所有资源打上一组标准化的标签让收集日志这件事变成一条纯粹的 label selector 查询。用户不需要理解 ARC 的内部结构只需要执行一条命令即可导出全部相关日志。采用 Kubernetes 官方推荐标签方案直接采用了 Kubernetes 官方推荐的通用标签 中最重要的一个app.kubernetes.io/part-of表示该资源属于哪个更大的应用系统在 2022-12-05 的原始 ADR 中所有 ARC 组件的app.kubernetes.io/part-of统一设置为app.kubernetes.io/part-of: actions-runner-controller配合标准日志输出一条命令即可拉取所有 ARC 相关 Pod 的日志kubectl logs -l app.kubernetes.io/part-ofactions-runner-controller这一catch-all一网打尽标签是对开发者最有用的起点也是整套标签体系的基石。提案三组组件的标签清单ADR 提出为 ARC 创建的三类资源分别注入不同粒度的标签覆盖全局归属 → 组件类型 → 版本 → 业务身份四个维度。controller-managercontroller-manager 由 Helm chart 在部署时打标签与 Controller 本身的生命周期一致metadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: controller-manager app.kubernetes.io/version: x.x.xListenerrunner-scale-set-listenerListener 由 Controller 在创建时打标签。除了通用的归属、组件、版本标签外还引入了actions.github.com前缀的业务标签其中scale-set-name对应AutoscalingRunnerSet资源的metadata.namemetadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: runner-scale-set-listener app.kubernetes.io/version: x.x.x actions.github.com/scale-set-name: scale-set-name # 对应 AutoscalingRunnerSet 的 metadata.name # 以下标签由 GitHub Config URL 解析而来 actions.github.com/enterprise: enterprise actions.github.com/organization: organization actions.github.com/repository: repositoryRunnerRunner 由 Controller 在创建时打标签在 Listener 标签的基础上补充了 runner 级别的标识metadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: runner app.kubernetes.io/version: x.x.x actions.github.com/scale-set-name: scale-set-name # 对应 AutoscalingRunnerSet 的 metadata.name actions.github.com/runner-name: runner-name actions.github.com/runner-group-name: runner-group-name # 以下标签由 GitHub Config URL 解析而来 actions.github.com/enterprise: enterprise actions.github.com/organization: organization actions.github.com/repository: repository注意enterprise、organization、repository三个标签的语义是互斥的ARC 支持企业级、组织级、仓库级三种 GitHub Config URL配置 URL 指向哪一层就填充对应的标签其余为空。这组标签让运维人员可以按这个组织下的所有 runner或这个仓库相关的所有组件进行聚合查询。实战用 label selector 收集与排查日志标签体系的最终价值体现在查询命令上。ADR 给出了两个典型场景场景一收集全部 ARC 相关日志适用于绝大多数支持请求kubectl logs -l app.kubernetes.io/part-ofactions-runner-controller场景二只收集 Runner 组件的日志当问题明确出在 runner 执行阶段时kubectl logs -l app.kubernetes.io/componentrunnerADR 明确指出了这套话术的优势——支持人员可以直接对用户说请把带有app.kubernetes.io/part-ofactions-runner-controller标签的 Pod 日志发给我们。如果问题特定于 runner请把带有app.kubernetes.io/componentrunner标签的 Pod 日志发给我们。这样用户无需理解 ARC 的组件构成而维护团队依然能够按需精准定向到具体组件。在实际排障中还可以组合多个标签缩小范围例如同时按 scale set 与组织过滤# 查看某个 scale set 下 Listener 与 Runner 的日志 kubectl logs -l actions.github.com/scale-set-name你的-scale-set-名称 # 查看某个组织下全部相关日志若配置 URL 为组织级 kubectl logs -l actions.github.com/organizationmy-org标签选择器也可以结合--tail、--since等参数进一步控制输出便于对长时间运行的 Runner 容器做定向抓取。源码验证标签是如何被注入的标签键的常量定义当前仓库中所有标签键统一收敛在 controllers/actions.github.com/constants.go 的常量区// Labels applied to resources const ( // Kubernetes labels LabelKeyKubernetesPartOf app.kubernetes.io/part-of LabelKeyKubernetesComponent app.kubernetes.io/component LabelKeyKubernetesVersion app.kubernetes.io/version // Github labels LabelKeyGitHubScaleSetName actions.github.com/scale-set-name LabelKeyGitHubScaleSetNamespace actions.github.com/scale-set-namespace LabelKeyGitHubEnterprise actions.github.com/enterprise LabelKeyGitHubOrganization actions.github.com/organization LabelKeyGitHubRepository actions.github.com/repository )从源码可以看到最终实现比 ADR 原始提案多出一个actions.github.com/scale-set-namespace标签——这是因为跨命名空间部署时仅有 name 不足以唯一定位一个 scale set必须 name namespace 联合标识。此外actions.github.com/runner-group-name在最终实现中被放在了 Annotation 而非 Label 中见同一文件中的AnnotationKeyGitHubRunnerGroupName这是因为 runner group 信息并非创建时静态可知且 Annotation 更适合承载这类非选择器用途的元数据。标签的组装与合并resourcebuilder.go 是标签注入的核心实现。它维护了一个通用标签键清单commonLabelKeys并通过filterAndMergeLabels完成用户自定义标签与系统标签的合并var commonLabelKeys [...]string{ LabelKeyKubernetesPartOf, LabelKeyKubernetesComponent, LabelKeyKubernetesVersion, LabelKeyGitHubScaleSetName, LabelKeyGitHubScaleSetNamespace, LabelKeyGitHubEnterprise, LabelKeyGitHubOrganization, LabelKeyGitHubRepository, }创建 Listener 时resourcebuilder.goController 将AutoscalingRunnerSet自身的标签与系统标签合并并显式指定组件标识与归属标识labels : b.filterAndMergeLabels(autoscalingRunnerSet.Labels, map[string]string{ LabelKeyGitHubScaleSetNamespace: autoscalingRunnerSet.Namespace, LabelKeyGitHubScaleSetName: autoscalingRunnerSet.Name, LabelKeyKubernetesPartOf: labelValueKubernetesPartOf, LabelKeyKubernetesComponent: runner-scale-set-listener, LabelKeyKubernetesVersion: autoscalingRunnerSet.Labels[LabelKeyKubernetesVersion], }) if err : applyGitHubURLLabels(autoscalingRunnerSet.Spec.GitHubConfigUrl, labels); err ! nil { return nil, fmt.Errorf(failed to apply GitHub URL labels: %v, err) }filterAndMergeLabelsresourcebuilder.go支持通过ExcludeLabelPropagationPrefixes排除指定前缀的标签防止用户自定义标签中某些敏感或与系统冲突的键被传播到子资源上。从 Config URL 自动提取 enterprise / organization / repositoryADR 中标注由 Config URL 提取的三个标签在源码中由applyGitHubURLLabels函数实现resourcebuilder.gofunc applyGitHubURLLabels(url string, labels map[string]string) error { githubConfig, err : actions.ParseGitHubConfigFromURL(url) if err ! nil { return fmt.Errorf(failed to parse github config from url: %v, err) } if len(githubConfig.Enterprise) 0 { labels[LabelKeyGitHubEnterprise] trimLabelValue(githubConfig.Enterprise) } if len(githubConfig.Organization) 0 { labels[LabelKeyGitHubOrganization] trimLabelValue(githubConfig.Organization) } if len(githubConfig.Repository) 0 { labels[LabelKeyGitHubRepository] trimLabelValue(githubConfig.Repository) } return nil }该函数解析GitHubConfigUrl如https://github.com/enterprises/xxx、https://github.com/orgs/xxx或https://github.com/xxx/repo把对应层级写入标签。配套的trimLabelValue函数resourcebuilder.go处理了 Kubernetes 标签值的 63 字符上限约束超长值会被截断并追加-trim后缀同时对首尾的-、_、.字符做裁剪保证标签值合法。标签的业务用途反向定位 scale set标签不仅用于日志筛选还被 Controller 自身作为关联查询的依据。例如 ephemeralrunner_controller.go 在回收 EphemeralRunner 时正是通过LabelKeyGitHubScaleSetName与LabelKeyGitHubScaleSetNamespace两个标签反查其所属的 scale setName: ephemeralRunner.Labels[LabelKeyGitHubScaleSetName], Namespace: ephemeralRunner.Labels[LabelKeyGitHubScaleSetNamespace],这印证了标签体系在设计上同时服务于人支持排障与机器控制器内部关联两个目标。相关的单元测试如 autoscalingrunnerset_controller_test.go 中断言创建的 Listener/EphemeralRunnerSet 携带LabelKeyKubernetesPartOf等标签也验证了这套注入逻辑的稳定性。演进ADR 被取代与实际落地值原始 ADR 状态标注为Superceded被取代其继任者是 ADR 2023-03-14: Adding labels to our resources状态Done即已落地实现。两次 ADR 的骨架完全一致差异在于维度ADR 2022-12-05原始提案ADR 2023-03-14 / 当前实现part-of取值actions-runner-controllergha-runner-scale-setController 为gha-runner-scale-set-controller日志筛选命令kubectl logs -l app.kubernetes.io/part-ofactions-runner-controllerkubectl logs -l app.kubernetes.io/part-ofgha-runner-scale-set-controller控制面/...gha-runner-scale-set运行时组件这一变化与项目从actions.summerwind.devAPI 组迁移到actions.github.comAPI 组见 ADR 2022-11-04-crd-api-group-name的时间线吻合。当前源码中resourcebuilder.go 的常量确认了运行时的实际取值const labelValueKubernetesPartOf gha-runner-scale-set同时Controller 的 Helm chart 也会注入这套标签体系例如 charts/gha-runner-scale-set/templates/_helpers.tpl 中通过{{ .Chart.AppVersion | quote }}填充app.kubernetes.io/version而 charts/gha-runner-scale-set-controller 相关模板则使用gha-rs-controller等取值来标记控制面组件并且 scale-set chart 在发现已部署的 controller Deployment 时正是通过app.kubernetes.io/part-ofgha-rs-controller标签进行自动发现若匹配不到或匹配到多个还会直接fail报错提示用户显式指定controllerServiceAccount.name。这说明标签在 ARC 中已经不只是排障手段还成为 Helm chart 间互相发现组件的协议约定。注意事项与最佳实践标签值长度限制Kubernetes 标签值最长 63 字符。trimLabelValueresourcebuilder.go会对超长值与首尾非法字符自动裁剪用户自定义标签时也应遵守这一约束。不要覆盖系统标签Controller 通过filterAndMergeLabels合并标签时系统注入的part-of、component、scale-set-name等键优先级更高overwrite 语义用户自定义标签无法覆盖它们若想完全控制子资源标签应通过ExcludeLabelPropagationPrefixes排除对应前缀。版本标签联动app.kubernetes.io/version取自AutoscalingRunnerSet上携带的版本标签由 Helm chart 注入Controller 还会据此做版本兼容性检查见 autoscalingrunnerset_controller.go 中基于LabelKeyKubernetesVersion的IsVersionAllowed判断因此不建议手动篡改。组合筛选更高效part-of适合兜底全量收集component适合按组件定向actions.github.com/scale-set-name、organization、repository适合按业务边界收敛三者可以任意组合使用。以当前仓库实现为准如果阅读历史版本文章或旧文档注意 2022-12-05 ADR 中的part-of取值actions-runner-controller已被新取值取代实际查询时应以部署环境中 Pod 的真实标签为准。总结ARC 通过一套以 Kubernetes 官方推荐标签为基础的标准化标签体系把收集支持日志从一项需要理解内部架构的专业操作简化成一条kubectl logs -l命令。app.kubernetes.io/part-of提供全局兜底app.kubernetes.io/component提供组件定向actions.github.com/*系列标签提供 scale set 与 GitHub 组织/仓库维度的业务过滤。这套设计从 2022 年底的 ADR 提案出发经过 2023 年 3 月 ADR 的修订后落地实现并持续演进出scale-set-namespace等新标签最终形成了一套同时服务于排障、运维与控制器内部关联查询的完整标签协议——其完整演进脉络均可在这两份 ADR 与 constants.go、resourcebuilder.go 的源码中得到印证。【免费下载链接】actions-runner-controllerKubernetes controller for GitHub Actions self-hosted runners项目地址: https://gitcode.com/GitHub_Trending/ac/actions-runner-controller创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 actions-runner-controller 资源标签体系详解：用 Kubernetes 推荐标签实现 ARC 组件日志的精准筛选
actions-runner-controller 资源标签体系详解用 Kubernetes 推荐标签实现 ARC 组件日志的精准筛选【免费下载链接】actions-runner-controllerKubernetes controller for GitHub Actions self-hosted runners项目地址: https://gitcode.com/GitHub_Trending/ac/actions-runner-controller导读在 GitHub Actions self-hosted runner 的 Kubernetes 控制器actions-runner-controller简称 ARC中当用户遇到问题需要寻求支持时第一件事往往是定位并收集相关组件的日志。本文基于仓库中 ADR 2022-12-05 的原始决策完整讲解 ARC 为 controller-manager、Listener、Runner 三类组件设计的统一标签规范并结合 constants.go 与 resourcebuilder.go 等源码实现说明这些标签如何被自动注入、如何通过一条kubectl命令精确筛选出全部 ARC 相关日志以及该方案在后续 ADR 2023-03-14 中的演进。背景为什么需要统一的资源标签支持与排障的核心痛点ADR 2022-12-05 开篇就点明了设计动机Users need to provide us with logs so that we can help support and troubleshoot their issues. We need a way for our users to filter and retrieve the logs we need.ARC 的架构由多个移动部件组成负责协调的控制平面controller-manager、负责与 GitHub Actions 服务通信的 Listenerrunner-scale-set-listener、以及实际执行 Job 的 Runner 容器。当用户报告问题时支持人员无法确定日志散落在哪些 Pod 里用户也往往不理解 ARC 内部各组件的名称与分工。解决方案的核心思路非常朴素为 ARC 创建的所有资源打上一组标准化的标签让收集日志这件事变成一条纯粹的 label selector 查询。用户不需要理解 ARC 的内部结构只需要执行一条命令即可导出全部相关日志。采用 Kubernetes 官方推荐标签方案直接采用了 Kubernetes 官方推荐的通用标签 中最重要的一个app.kubernetes.io/part-of表示该资源属于哪个更大的应用系统在 2022-12-05 的原始 ADR 中所有 ARC 组件的app.kubernetes.io/part-of统一设置为app.kubernetes.io/part-of: actions-runner-controller配合标准日志输出一条命令即可拉取所有 ARC 相关 Pod 的日志kubectl logs -l app.kubernetes.io/part-ofactions-runner-controller这一catch-all一网打尽标签是对开发者最有用的起点也是整套标签体系的基石。提案三组组件的标签清单ADR 提出为 ARC 创建的三类资源分别注入不同粒度的标签覆盖全局归属 → 组件类型 → 版本 → 业务身份四个维度。controller-managercontroller-manager 由 Helm chart 在部署时打标签与 Controller 本身的生命周期一致metadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: controller-manager app.kubernetes.io/version: x.x.xListenerrunner-scale-set-listenerListener 由 Controller 在创建时打标签。除了通用的归属、组件、版本标签外还引入了actions.github.com前缀的业务标签其中scale-set-name对应AutoscalingRunnerSet资源的metadata.namemetadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: runner-scale-set-listener app.kubernetes.io/version: x.x.x actions.github.com/scale-set-name: scale-set-name # 对应 AutoscalingRunnerSet 的 metadata.name # 以下标签由 GitHub Config URL 解析而来 actions.github.com/enterprise: enterprise actions.github.com/organization: organization actions.github.com/repository: repositoryRunnerRunner 由 Controller 在创建时打标签在 Listener 标签的基础上补充了 runner 级别的标识metadata: labels: app.kubernetes.io/part-of: actions-runner-controller app.kubernetes.io/component: runner app.kubernetes.io/version: x.x.x actions.github.com/scale-set-name: scale-set-name # 对应 AutoscalingRunnerSet 的 metadata.name actions.github.com/runner-name: runner-name actions.github.com/runner-group-name: runner-group-name # 以下标签由 GitHub Config URL 解析而来 actions.github.com/enterprise: enterprise actions.github.com/organization: organization actions.github.com/repository: repository注意enterprise、organization、repository三个标签的语义是互斥的ARC 支持企业级、组织级、仓库级三种 GitHub Config URL配置 URL 指向哪一层就填充对应的标签其余为空。这组标签让运维人员可以按这个组织下的所有 runner或这个仓库相关的所有组件进行聚合查询。实战用 label selector 收集与排查日志标签体系的最终价值体现在查询命令上。ADR 给出了两个典型场景场景一收集全部 ARC 相关日志适用于绝大多数支持请求kubectl logs -l app.kubernetes.io/part-ofactions-runner-controller场景二只收集 Runner 组件的日志当问题明确出在 runner 执行阶段时kubectl logs -l app.kubernetes.io/componentrunnerADR 明确指出了这套话术的优势——支持人员可以直接对用户说请把带有app.kubernetes.io/part-ofactions-runner-controller标签的 Pod 日志发给我们。如果问题特定于 runner请把带有app.kubernetes.io/componentrunner标签的 Pod 日志发给我们。这样用户无需理解 ARC 的组件构成而维护团队依然能够按需精准定向到具体组件。在实际排障中还可以组合多个标签缩小范围例如同时按 scale set 与组织过滤# 查看某个 scale set 下 Listener 与 Runner 的日志 kubectl logs -l actions.github.com/scale-set-name你的-scale-set-名称 # 查看某个组织下全部相关日志若配置 URL 为组织级 kubectl logs -l actions.github.com/organizationmy-org标签选择器也可以结合--tail、--since等参数进一步控制输出便于对长时间运行的 Runner 容器做定向抓取。源码验证标签是如何被注入的标签键的常量定义当前仓库中所有标签键统一收敛在 controllers/actions.github.com/constants.go 的常量区// Labels applied to resources const ( // Kubernetes labels LabelKeyKubernetesPartOf app.kubernetes.io/part-of LabelKeyKubernetesComponent app.kubernetes.io/component LabelKeyKubernetesVersion app.kubernetes.io/version // Github labels LabelKeyGitHubScaleSetName actions.github.com/scale-set-name LabelKeyGitHubScaleSetNamespace actions.github.com/scale-set-namespace LabelKeyGitHubEnterprise actions.github.com/enterprise LabelKeyGitHubOrganization actions.github.com/organization LabelKeyGitHubRepository actions.github.com/repository )从源码可以看到最终实现比 ADR 原始提案多出一个actions.github.com/scale-set-namespace标签——这是因为跨命名空间部署时仅有 name 不足以唯一定位一个 scale set必须 name namespace 联合标识。此外actions.github.com/runner-group-name在最终实现中被放在了 Annotation 而非 Label 中见同一文件中的AnnotationKeyGitHubRunnerGroupName这是因为 runner group 信息并非创建时静态可知且 Annotation 更适合承载这类非选择器用途的元数据。标签的组装与合并resourcebuilder.go 是标签注入的核心实现。它维护了一个通用标签键清单commonLabelKeys并通过filterAndMergeLabels完成用户自定义标签与系统标签的合并var commonLabelKeys [...]string{ LabelKeyKubernetesPartOf, LabelKeyKubernetesComponent, LabelKeyKubernetesVersion, LabelKeyGitHubScaleSetName, LabelKeyGitHubScaleSetNamespace, LabelKeyGitHubEnterprise, LabelKeyGitHubOrganization, LabelKeyGitHubRepository, }创建 Listener 时resourcebuilder.goController 将AutoscalingRunnerSet自身的标签与系统标签合并并显式指定组件标识与归属标识labels : b.filterAndMergeLabels(autoscalingRunnerSet.Labels, map[string]string{ LabelKeyGitHubScaleSetNamespace: autoscalingRunnerSet.Namespace, LabelKeyGitHubScaleSetName: autoscalingRunnerSet.Name, LabelKeyKubernetesPartOf: labelValueKubernetesPartOf, LabelKeyKubernetesComponent: runner-scale-set-listener, LabelKeyKubernetesVersion: autoscalingRunnerSet.Labels[LabelKeyKubernetesVersion], }) if err : applyGitHubURLLabels(autoscalingRunnerSet.Spec.GitHubConfigUrl, labels); err ! nil { return nil, fmt.Errorf(failed to apply GitHub URL labels: %v, err) }filterAndMergeLabelsresourcebuilder.go支持通过ExcludeLabelPropagationPrefixes排除指定前缀的标签防止用户自定义标签中某些敏感或与系统冲突的键被传播到子资源上。从 Config URL 自动提取 enterprise / organization / repositoryADR 中标注由 Config URL 提取的三个标签在源码中由applyGitHubURLLabels函数实现resourcebuilder.gofunc applyGitHubURLLabels(url string, labels map[string]string) error { githubConfig, err : actions.ParseGitHubConfigFromURL(url) if err ! nil { return fmt.Errorf(failed to parse github config from url: %v, err) } if len(githubConfig.Enterprise) 0 { labels[LabelKeyGitHubEnterprise] trimLabelValue(githubConfig.Enterprise) } if len(githubConfig.Organization) 0 { labels[LabelKeyGitHubOrganization] trimLabelValue(githubConfig.Organization) } if len(githubConfig.Repository) 0 { labels[LabelKeyGitHubRepository] trimLabelValue(githubConfig.Repository) } return nil }该函数解析GitHubConfigUrl如https://github.com/enterprises/xxx、https://github.com/orgs/xxx或https://github.com/xxx/repo把对应层级写入标签。配套的trimLabelValue函数resourcebuilder.go处理了 Kubernetes 标签值的 63 字符上限约束超长值会被截断并追加-trim后缀同时对首尾的-、_、.字符做裁剪保证标签值合法。标签的业务用途反向定位 scale set标签不仅用于日志筛选还被 Controller 自身作为关联查询的依据。例如 ephemeralrunner_controller.go 在回收 EphemeralRunner 时正是通过LabelKeyGitHubScaleSetName与LabelKeyGitHubScaleSetNamespace两个标签反查其所属的 scale setName: ephemeralRunner.Labels[LabelKeyGitHubScaleSetName], Namespace: ephemeralRunner.Labels[LabelKeyGitHubScaleSetNamespace],这印证了标签体系在设计上同时服务于人支持排障与机器控制器内部关联两个目标。相关的单元测试如 autoscalingrunnerset_controller_test.go 中断言创建的 Listener/EphemeralRunnerSet 携带LabelKeyKubernetesPartOf等标签也验证了这套注入逻辑的稳定性。演进ADR 被取代与实际落地值原始 ADR 状态标注为Superceded被取代其继任者是 ADR 2023-03-14: Adding labels to our resources状态Done即已落地实现。两次 ADR 的骨架完全一致差异在于维度ADR 2022-12-05原始提案ADR 2023-03-14 / 当前实现part-of取值actions-runner-controllergha-runner-scale-setController 为gha-runner-scale-set-controller日志筛选命令kubectl logs -l app.kubernetes.io/part-ofactions-runner-controllerkubectl logs -l app.kubernetes.io/part-ofgha-runner-scale-set-controller控制面/...gha-runner-scale-set运行时组件这一变化与项目从actions.summerwind.devAPI 组迁移到actions.github.comAPI 组见 ADR 2022-11-04-crd-api-group-name的时间线吻合。当前源码中resourcebuilder.go 的常量确认了运行时的实际取值const labelValueKubernetesPartOf gha-runner-scale-set同时Controller 的 Helm chart 也会注入这套标签体系例如 charts/gha-runner-scale-set/templates/_helpers.tpl 中通过{{ .Chart.AppVersion | quote }}填充app.kubernetes.io/version而 charts/gha-runner-scale-set-controller 相关模板则使用gha-rs-controller等取值来标记控制面组件并且 scale-set chart 在发现已部署的 controller Deployment 时正是通过app.kubernetes.io/part-ofgha-rs-controller标签进行自动发现若匹配不到或匹配到多个还会直接fail报错提示用户显式指定controllerServiceAccount.name。这说明标签在 ARC 中已经不只是排障手段还成为 Helm chart 间互相发现组件的协议约定。注意事项与最佳实践标签值长度限制Kubernetes 标签值最长 63 字符。trimLabelValueresourcebuilder.go会对超长值与首尾非法字符自动裁剪用户自定义标签时也应遵守这一约束。不要覆盖系统标签Controller 通过filterAndMergeLabels合并标签时系统注入的part-of、component、scale-set-name等键优先级更高overwrite 语义用户自定义标签无法覆盖它们若想完全控制子资源标签应通过ExcludeLabelPropagationPrefixes排除对应前缀。版本标签联动app.kubernetes.io/version取自AutoscalingRunnerSet上携带的版本标签由 Helm chart 注入Controller 还会据此做版本兼容性检查见 autoscalingrunnerset_controller.go 中基于LabelKeyKubernetesVersion的IsVersionAllowed判断因此不建议手动篡改。组合筛选更高效part-of适合兜底全量收集component适合按组件定向actions.github.com/scale-set-name、organization、repository适合按业务边界收敛三者可以任意组合使用。以当前仓库实现为准如果阅读历史版本文章或旧文档注意 2022-12-05 ADR 中的part-of取值actions-runner-controller已被新取值取代实际查询时应以部署环境中 Pod 的真实标签为准。总结ARC 通过一套以 Kubernetes 官方推荐标签为基础的标准化标签体系把收集支持日志从一项需要理解内部架构的专业操作简化成一条kubectl logs -l命令。app.kubernetes.io/part-of提供全局兜底app.kubernetes.io/component提供组件定向actions.github.com/*系列标签提供 scale set 与 GitHub 组织/仓库维度的业务过滤。这套设计从 2022 年底的 ADR 提案出发经过 2023 年 3 月 ADR 的修订后落地实现并持续演进出scale-set-namespace等新标签最终形成了一套同时服务于排障、运维与控制器内部关联查询的完整标签协议——其完整演进脉络均可在这两份 ADR 与 constants.go、resourcebuilder.go 的源码中得到印证。【免费下载链接】actions-runner-controllerKubernetes controller for GitHub Actions self-hosted runners项目地址: https://gitcode.com/GitHub_Trending/ac/actions-runner-controller创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考