监控 Config Sync

本页面介绍如何监控 Config Sync 资源。

启用 RootSync 和 RepoSync API 时,Config Sync 会使用 OpenCensus 创建和记录指标并使用 OpenTelemetry 将其指标导出到 PrometheusCloud Monitoring。您还可以使用 OpenTelemety 将指标导出到自定义监控系统。此过程为您提供了三种监控资源的方法:

  1. Cloud Monitoring
  2. 自定义监控系统
  3. Prometheus

如果您未启用 RootSync 和 RepoSync API,则只能使用 Prometheus 监控资源

可用的 OpenTelemetry 指标

启用 RootSync 和 RepoSync API 后,Config Sync 和资源组控制器将收集以下指标并将其提供给 OpenTelemetry。标记列列出了适用于每个指标的所有标记。带有标记的指标代表多个测量结果,每个标记值组合对应一个。

Config Sync 指标

Anthos Config Management 1.10.1 版及更高版本提供以下指标。

名称 类型 标记 说明
api_duration_seconds 分布 operation、status API 服务器调用的延迟时间分布
apply_duration_seconds 分布 status Applier 资源同步事件的延迟时间分布
apply_operations_total 计数 operation、status 已执行以便将资源同步至可靠来源的操作总数
declared_resources 最后一个值 reconciler 从 Git 解析的已声明资源数量
internal_errors_total 计数 reconciler、source Config Sync 触发的内部错误总数
last_sync_timestamp 最后一个值 reconciler 从 Git 最近一次同步的时间戳
parser_duration_seconds 分布 reconciler、status、trigger、source “解析-应用-监视”循环的延迟时间分布
pipeline_error_observed 最后一个值 name、reconciler、component RootSync 和 RepoSync 自定义资源的状态。值 1 表示失败。
reconcile_duration_seconds 分布 status 由协调器管理器处理的协调事件的延迟时间分布。
reconciler_errors 最后一个值 reconciler、component RootSync 和 RepoSync 协调器中的错误数
remediate_duration_seconds 分布 status 补救器协调事件的延迟时间分布
resource_conflicts_total 计数 reconciler 因缓存资源和集群资源之间存在不匹配而导致的资源冲突总数
resource_fights_total 计数 reconciler 过于频繁同步的资源总数。任何高于零的结果都表示有问题。如需了解详情,请参阅 KNV2005:ResourceFightWarning
rendering_count_total 计数 reconciler 在资源上使用 Kustomize 或 Helm 图表呈现的同步执行计数。
skip_rendering_count_total 计数 reconciler 不在资源上使用 Kustomize 或 Helm 图表呈现的同步执行计数。
resource_override_count_total 计数 reconciler、container、resource 资源补丁中指定的资源替换计数
git_sync_depth_override_count_total 计数 - 设置了 spec.override.gitSyncDepth 替换的 Root/RepoSync 对象的计数。Git 深度可用于在从大型代码库同步时改善性能。
no_ssl_verify_count_total 计数 - 设置了 .spec.git.noSSLVerify 替换的 Root/RepoSync 对象的计数。

资源组控制器指标

资源组控制器是 Config Sync 中的一个组件,它可跟踪代管式资源并检查每个资源是否准备就绪或已协调。Anthos Config Management 1.10 版及更高版本提供以下指标。

名称 类型 标记 说明
reconcile_duration_seconds 分布 stallreason 协调 ResourceGroup CR 所需的时间分布
resource_group_total 最后一个值 当前的 ResourceGroup CR 数量
resource_count_total 求和 集群中所有 ResourceGroup CR 跟踪的资源总数
resource_count 最后一个值 resourcegroup 一个 ResourceGroup 跟踪的资源总数
ready_resource_count_total 求和 集群的所有 ResourceGroup CR 中准备就绪的资源总数。
ready_resource_count 最后一个值 resourcegroup ResourceGroup 中准备就绪的资源总数
resource_ns_count 最后一个值 resourcegorup ResourceGroup 中的资源使用的命名空间数量
cluster_scoped_resource_count 最后一个值 resourcegroup ResourceGroup 中集群范围的资源的数量
crd_count 最后一个值 resourcegroup ResourceGroup 中的 CRD 数量
kcc_resource_count_total 求和 集群的所有 ResourceGroup CR 中的 Config Connector 资源的总数
kcc_resource_count 仪表盘 resourcegroup ResourceGroup 中的 KCC 资源总数
pipeline_error_obvserved 最后一个值 name、reconciler、component RootSync 和 RepoSync 自定义资源的状态。值 1 表示失败。

Config Sync 指标标记

指标标记可用于聚合指标数据。可以在 Monitoring 控制台的“分组依据”下拉列表中进行选择。

自定义标记

上面表格的“标记”列中为每个指标列出了自定义标记。

名称 说明
operation create、patch、update、delete 执行的操作类型
status success、error 操作的执行状态
reconciler rootsync、reposync 协调器的类型
source parser、differ、remediator 内部错误的来源
trigger retry、watchUpdate、managementConflict、resync、reimport 协调事件的触发因素
name 协调器的名称 协调器的名称
component parsing、source、sync、rendering、readiness 协调当前位于的组件/阶段的名称
container reconciler、git-sync 容器的名称
resource cpu、memory 资源的类型

资源标记

Config Sync 自定义监控指标使用的是 K8s_Pod 资源类型,它具有以下标记。

名称 说明
project 项目的 ID
cluster_name 集群的名称
location 集群的位置/可用区
namespace_name 从中导出指标的命名空间的名称
pod_name 从中导出指标的 Pod 的名称

了解 pipeline_error_observed 指标

pipeline_error_observed 指标可帮助您快速识别未同步或包含未协调为所需状态的资源的 RepoSync 或 RootSync CR。Anthos Config Management 1.10 版及更高版本提供此指标。

  • 对于 RootSync 或 RepoSync 的成功同步,具有所有组件(renderingsourcesyncreadiness)的指标的值显示为 0。

    pipeline_error_observed 指标的屏幕截图,其中观察到的所有组件的值都为 0

  • 当最新提交使自动呈现失败时,包含组件 rendering 的指标的值为 1。

  • 在签出最新提交遇到错误或最新提交包含无效配置时,具有组件 source 的指标的值显示为 1。

  • 当某个资源无法应用于集群时,具有组件 sync 的指标的值显示为 1。

  • 如果应用资源,但资源无法达到其所需状态,则具有组件 readiness 的指标的值显示为 1。例如,Deployment 已应用于集群,但相应的 pod 却未成功创建。

使用 Cloud Monitoring 监控资源

如果 Config Sync 在具有默认服务帐号的 Google Cloud 环境中运行,则 Config Sync 会自动将指标导出到 Cloud Monitoring。

如果启用了 Workload Identity,请完成以下步骤:

  1. 将命名空间 config-management-monitoring 中的 Kubernetes ServiceAccount default 绑定到具有指标写入者角色的 Google 服务帐号:

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    替换以下内容:

    • PROJECT_ID:您的项目 ID
    • GSA_NAME:具有指标写入者角色的 Google 服务帐号

    此操作需要项目的 iam.serviceAccounts.setIamPolicy 权限。

  2. 使用 Google 服务帐号的电子邮件地址为 Kubernetes ServiceAccount 添加注解:

    kubectl annotate serviceaccount \
        --namespace config-management-monitoring \
        default \
        iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

如需查看关于如何查看这些指标的示例,请参阅下面的调试过程示例部分和 Cloud Monitoring 中的 OpenCensus 指标一文。

Cloud Monitoring 的调试过程示例

以下 Cloud Monitoring 示例展示了一些模式,当您使用 RootSync 和 RepoSync API 时,它们使用 OpenCensus 指标来检测和诊断与 Config Sync 相关的问题。

指标格式

在 Cloud Monitoring 中,指标采用以下格式:custom.googleapis.com/opencensus/config_sync/METRIC

此指标名称由以下各部分组成:

  • custom.googleapis.com:所有自定义指标都具有此前缀
  • opencensus:已添加此前缀,因为 Config Sync 使用 OpenCensus 库
  • config_sync/:由 Config Sync 导出到 Cloud Monitoring 的指标具有此前缀
  • METRIC:您要查询的指标的名称

按协调器查询指标

RootSync 和 RepoSync 对象可通过概要指标进行检测,有助于您全面了解 Config Sync 在集群上的运行情况。几乎所有指标都按照协调器名称进行标记,因此您可以查看是否发生了任何错误,并且可以在 Cloud Monitoring 中为其设置提醒。

协调器是部署为 Deployment 的 Pod。它会将清单从 Git 代码库同步到集群。当您创建 RootSync 对象时,Config Sync 会创建名为 root-reconciler 的协调器。 当您创建 RepoSync 对象时,Config Sync 会创建一个名为 ns-reconciler-NAMESPACE 的协调器,其中 NAMESPACE 是您在其中创建了 RepoSync 对象的命名空间。

下图展示了协调器 Pod 的工作原理:

协调器流

例如,若要在使用 Cloud Monitoring 时按协调器名称进行过滤,请完成以下任务:

  1. 在 Google Cloud Console 中,转到 Monitoring

    转至 Resources

  2. Monitoring 导航窗格中,点击 Metrics explorer.

  3. 选择指标下拉列表中,添加 custom.googleapis.com/opencensus/config_sync/reconciler_errors

  4. 过滤条件下拉列表中,选择协调器。此时会显示一个过滤条件字段框。

  5. 在过滤条件字段框中,在第一个字段中选择 =,在第二个字段中选择 root-reconciler

  6. 点击应用

您现在可以查看 RootSync 对象的指标。

如需详细了解如何按特定数据类型进行过滤,请参阅过滤数据

按组件和状态查询 Config Sync 操作

启用 RootSync 和 RepoSync API 后,协调器会处理从 Git 代码库导入和获取以及同步到集群的操作。reconciler_errors 指标按组件进行标记,因此您可以查看发生错误的位置。

例如,若要在使用 Cloud Monitoring 时按组件过滤,请完成以下任务:

  1. 在 Google Cloud Console 中,转到 Monitoring

    转至 Resources

  2. Monitoring 导航窗格中,点击 Metrics explorer.

  3. 选择指标下拉列表中,添加 custom.googleapis.com/opencensus/config_sync/reconciler_errors

  4. 过滤条件下拉列表中,选择组件。此时会显示一个过滤条件字段框。

  5. 在过滤条件字段中,在第一个框中选择 =,在第二个框中选择 source

  6. 点击应用

现在,您就可以查看从协调器的 Git 代码库搜寻时发生的错误了。

您还可以通过查询以下指标并按 status 标记进行过滤,自行检查来源的指标并自行同步进程:

custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

配置自定义 OpenTelemetry 导出器

如果要将指标发送到其他监控系统,您可以修改 OpenTelemetry 配置。如需受支持的监控系统列表,请参阅 OpenTelemetry Collector ExportersOpenTelemetry Collector-Contrib Exporters

OpenTelemetry 监控资源在单独的 config-management-monitoring 命名空间中管理。如需配置自定义 OpenTelemetry 导出器以与 Config Sync 搭配使用,您需要在该 config-management-monitoring 命名空间中创建名为 otel-collector-custom 的 ConfigMap。ConfigMap 应包含 otel-collector-config.yaml 键,并且值应该是自定义 OpenTelemetry 收集器配置的文件内容。如需详细了解配置选项,请参阅 OpenTelemetry 收集器配置文档

以下 ConfigMap 是一个具有自定义日志记录导出器的 ConfigMap 示例:

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

所有自定义配置都必须定义 opencensus 接收器和 metrics 流水线。其余字段均为可选且可配置,但我们建议您添加 batch 处理器和健康检查扩展程序,如示例中所示。

创建 ConfigMap 后,您可以使用 kubectl 创建资源:

kubectl apply -f otel-collector-custom-cm.yaml

OpenTelemetry Collector Deployment 选取此 ConfigMap 并自动重启以应用自定义配置。

使用 Prometheus 监控资源

Config Sync 使用 Prometheus 来收集和显示与其进程相关的指标。

您还可以配置 Cloud Monitoring 以从 Prometheus 中拉取自定义指标。然后,您可以在 Prometheus 和 Monitoring 中查看自定义指标。如需了解详情,请参阅使用 Prometheus

爬取指标

所有 Prometheus 指标均可在端口 8675 抓取。在抓取指标之前,您需要采用下列两种方式中的任意一种为 Prometheus 配置集群。采用以下任一方式:

  • 按照 Prometheus 文档的说明配置集群以抓取指标,

  • 使用 Prometheus Operator 以及以下清单,这些清单每 10 秒抓取所有 Anthos Config Management 指标一次。

    1. 创建一个临时目录来保存清单文件。

      mkdir acm-monitor
      cd acm-monitor
      
    2. 使用 curl 命令从 CoreOS 代码库下载 Prometheus Operator 清单:

      curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
      

      此清单配置为使用 default 命名空间,但不建议使用该命名空间。下一步会将配置修改为使用名为 monitoring 的命名空间。如需使用其他命名空间,请通过其余步骤在显示 monitoring 的位置替换命名空间。

    3. 创建一个文件来更新上述软件包中 ClusterRoleBinding 的命名空间。

      # patch-crb.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-operator
      subjects:
      - kind: ServiceAccount
        name: prometheus-operator
        namespace: monitoring # we are patching from default namespace
      
    4. 创建一个 kustomization.yaml 文件,该文件将应用补丁程序并为清单中的其他资源修改命名空间。

      # kustomization.yaml
      resources:
      - bundle.yaml
      
      namespace: monitoring
      
      patchesStrategicMerge:
      - patch-crb.yaml
      
    5. 如果 monitoring 命名空间不存在,请创建一个。您可以对该命名空间使用其他名称,但这样的话,还要通过前面的步骤更改 YAML 清单中 namespace 的值。

      kubectl create namespace monitoring
      
    6. 使用以下命令应用 Kustomize 清单:

      kubectl apply -k .
      
      until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \
      do date; sleep 1; echo ""; done

      第二个命令会进行阻止,直到集群上有可用的 CRD。

    7. 为配置 Prometheus 服务器所需的资源创建清单,该服务器将从 Anthos Config Management 中抓取指标。

      # acm.yaml
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: prometheus-acm
      rules:
      - apiGroups: [""]
        resources:
        - nodes
        - services
        - endpoints
        - pods
        verbs: ["get", "list", "watch"]
      - apiGroups: [""]
        resources:
        - configmaps
        verbs: ["get"]
      - nonResourceURLs: ["/metrics"]
        verbs: ["get"]
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-acm
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: prometheus-acm
      subjects:
      - kind: ServiceAccount
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: Prometheus
      metadata:
        name: acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        replicas: 2
        serviceAccountName: prometheus-acm
        serviceMonitorSelector:
          matchLabels:
            prometheus: config-management
        podMonitorSelector:
          matchLabels:
            prometheus: config-management
        alerting:
          alertmanagers:
          - namespace: default
            name: alertmanager
            port: web
        resources:
          requests:
            memory: 400Mi
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: prometheus-acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        type: NodePort
        ports:
        - name: web
          nodePort: 31900
          port: 9190
          protocol: TCP
          targetPort: web
        selector:
          app: prometheus
          prometheus: acm
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        name: acm-service
        namespace: monitoring
        labels:
          prometheus: config-management
      spec:
        selector:
          matchLabels:
            monitored: "true"
        namespaceSelector:
          matchNames:
          # If you are using RootSync and RepoSync APIs, change
          # config-management-system to config-management-monitoring
          - config-management-system
        endpoints:
        - port: metrics
          interval: 10s
      ---
      
    8. 使用以下命令应用清单:

      kubectl apply -f acm.yaml
      
      until kubectl rollout status statefulset/prometheus-acm -n monitoring; \
      do sleep 1; done
      

      第二个命令会进行阻止,直到 Pod 开始运行。

    9. 您可以通过将 Prometheus 服务器的 Web 端口转发到本地机器来验证安装。

      kubectl -n monitoring port-forward svc/prometheus-acm 9190
      

      现在,您可以通过 http://localhost:9190 访问 Prometheus 网页界面。

    10. 移除临时目录。

      cd ..
      rm -rf acm-monitor
      

可用的 Prometheus 指标

Config Sync 会收集以下指标并将其提供给 Prometheus。标签列列出了适用于每个指标的所有标签。没有标签的指标代表一段时间内的一次测量结果,而带有标签的指标代表多次测量结果,每组标签值对应一次测量结果。

如果此表变得不同步,您可以在 Prometheus 界面中按前缀过滤指标,所有指标都以 gkeconfig_ 前缀开头。

名称 类型 标签 说明
gkeconfig_importer_cycle_duration_seconds_bucket 直方图 status 导入程序尝试将配置导入集群的周期数(按每个周期的持续时间分配到存储分区中)
gkeconfig_importer_cycle_duration_seconds_count 直方图 status 导入程序尝试将配置导入集群的周期数(忽略持续时间)
gkeconfig_importer_cycle_duration_seconds_sum 直方图 status 导入程序尝试将配置导入集群的所有周期的持续时间之和
gkeconfig_importer_namespace_configs 仪表盘 当前状态下的命名空间配置数
gkeconfig_monitor_errors 仪表盘 component 配置代码库中按发生错误的组件分组的错误数
gkeconfig_monitor_configs 仪表盘 state 按配置(集群和命名空间)的同步状态分组的配置数量
gkeconfig_monitor_last_import_timestamp 仪表盘 最近执行的导入操作的时间戳
gkeconfig_monitor_last_sync_timestamp 仪表盘 最近执行的同步操作的时间戳
gkeconfig_monitor_sync_latency_seconds_bucket 直方图 执行的导入到同步测量的数量(通过两者之间的延迟时间分配到存储分区中)
gkeconfig_monitor_sync_latency_seconds_count 直方图 执行的导入到同步测量的数量(忽略两者之间的延迟时间)
gkeconfig_monitor_sync_latency_seconds_sum 直方图 执行的所有导入到同步测量的延迟时间总和
gkeconfig_syncer_api_duration_seconds_bucket 直方图 operation、type、status 同步程序对 API 服务器的调用次数(按每次调用的持续时间分配到存储分区中)
gkeconfig_syncer_api_duration_seconds_count 直方图 operation、type、status 导入程序对 API 服务器的调用次数(忽略持续时间)
gkeconfig_syncer_api_duration_seconds_sum 直方图 operation、type、status 同步程序对 API 服务器进行的所有调用的持续时间之和
gkeconfig_syncer_controller_restarts_total 计数器 source 命名空间和集群配置控制器的重新启动总数
gkeconfig_syncer_operations_total 计数器 operation、type、status 将资源同步到配置所执行的操作总数
gkeconfig_syncer_reconcile_duration_seconds_bucket 直方图 type、status 同步程序处理的协调事件数(按持续时间分配到存储分区中)
gkeconfig_syncer_reconcile_duration_seconds_count 直方图 type、status 同步程序处理的协调事件数(忽略持续时间)
gkeconfig_syncer_reconcile_duration_seconds_sum 直方图 type、status 同步程序处理的所有协调事件的持续时间之和
gkeconfig_syncer_reconcile_event_timestamps 仪表盘 type 同步程序协调事件发生时的时间戳

Prometheus 的调试过程示例

下面的示例展示了一些模式,它们使用 Prometheus 指标、对象状态字段和对象注释来检测和诊断与 Config Sync 相关的问题。这些示例显示了如何先从检测问题的基本监控开始,然后逐步优化搜索,从而深入分析并诊断问题的根本原因。

按状态查询配置

monitor 进程提供了概要指标,有助于您全面了解 Config Sync 在集群上的运行情况。您可以查看是否发生了任何错误,甚至还可以设置错误提醒

gkeconfig_monitor_errors

按协调器查询指标

如果您使用 Config Sync RootSync 和 RepoSync API,则可以监控 RootSync 和 RepoSync 对象。RootSync 和 RepoSync 对象可通过概要指标进行检测,有助于您全面了解 Config Sync 在集群上的运行情况。几乎所有指标都按照协调器名称进行标记,因此您可以查看是否发生了任何错误,并且可以在 Prometheus 中为其设置提醒。

协调器是一个 Pod,用于将清单从 Git 代码库同步到集群。当您创建 RootSync 对象时,Config Sync 会创建名为 root-reconciler 的协调器。当您创建 RepoSync 对象时,Config Sync 会创建一个名为 ns-reconciler-NAMESPACE 的协调器,其中 NAMESPACE 是您在其中创建了 RepoSync 对象的命名空间。

在 Prometheus 中,您可以将以下过滤条件用于协调器:

# Querying Root reconciler
config_sync_reconciler_errors{root_reconciler="root-reconciler"}

# Querying Namespace reconciler for a namespace called retail
config_sync_reconciler_errors{ns_reconciler_retail="ns-reconciler-retail"}

使用 nomos status 显示错误

除了使用 Prometheus 指标来监控集群上的 Config Sync 状态之外,您还可以使用 nomos status 命令在命令行上显示所有集群中的错误。

按状态查询导入和同步操作

Config Sync 使用两个步骤将代码库中的配置应用到集群。gkeconfig_monitor_errors 指标按组件进行标记,因此您可以查看发生错误的位置。

gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}

您还可以查看导入程序和同步程序进程自身的指标。

gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}

启用 RootSync 和 RepoSync API 后,协调器会处理从 Git 代码库导入和获取以及同步到集群的操作。reconciler_errors 指标按组件进行标记,因此您可以查看发生错误的位置。

在 Prometheus 中,您可以使用以下查询:

# Check for errors that occurred when sourcing configs from the Git repository.
config_sync_reconciler_errors{component="source"}

# Check for errors that occurred when syncing configs to the cluster.
config_sync_reconciler_errors{component="sync"}

您还可以检查来源的指标并自动同步进程:

config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}

检查配置的对象状态

Config Sync 定义两个自定义 Kubernetes 对象:ClusterConfig 和 NamespaceConfig。这些对象定义一个状态字段,可在其中了解上次应用于配置的更改以及发生的任何错误。例如,如果名为 shipping-dev 的命名空间出现错误,您可查看相应的 NamespaceConfig 的状态。

kubectl get namespaceconfig shipping-dev -o yaml

检查对象的 token 注解

您可能希望了解 Config Sync 上次更新托管 Kubernetes 对象的时间。每个代管对象都将进行注释,以显示在上次修改时 Git 提交的哈希值以及包含修改内容的配置的路径。

kubectl get clusterrolebinding namespace-readers
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/source-path: cluster/namespace-reader-clusterrolebinding.yaml
    configmanagement.gke.io/token: bbb6a1e2f3db692b17201da028daff0d38797771
  name: namespace-readers
...

如需了解详情,请参阅标签和注释

后续步骤