排查政策控制器问题

本页面介绍了如何解决政策控制器的问题。

常规提示

以下部分提供了解决 Policy Controller 问题的一般建议。

停止政策控制器

如果政策控制器导致集群出现问题，您可以在调查问题时停止政策控制器。

检查指标

检查政策控制器指标可帮助您诊断政策控制器的问题。

验证安装

您可以验证政策控制器和限制条件模板库是否已成功安装。

分离 Policy Controller

在极少数情况下，您可能需要将 Policy Controller 与集群分离。这会完全停用 Policy Controller 的管理。在使用 detach 命令之前，请尝试暂时停止 Policy Controller，以查看是否可以解决问题。

  1. 在整个舰队中分离 Policy Controller：

    gcloud container fleet policycontroller detach

  2. 重新关联 Policy Controller：

    gcloud container fleet policycontroller enable

创建限制条件模板时出错

如果您看到提及 disallowed ref 的错误，请确认您已启用参照限制条件。例如，如果您在未启用参照限制条件的情况下在限制条件模板中使用 data.inventory，则该错误会如下所示：

admission webhook "validation.gatekeeper.sh" denied the request: check refs failed on module {templates["admission.k8s.gatekeeper.sh"]["MyTemplate"]}: disallowed ref data.inventory...

未强制执行限制条件

如果您怀疑或知道限制条件未强制执行，以下部分提供了问题排查指导。

检查您的限制条件是否已强制执行

如果您担心未强制执行限制条件，则可以检查限制条件和限制条件模板的 spec.status。如需检查状态，请运行以下命令：

kubectl describe CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

替换以下内容：

  • CONSTRAINT_TEMPLATE_NAME：您要检查的限制条件模板的名称。例如 K8sNoExternalServices。

  • CONSTRAINT_NAME：您要检查的限制条件的 Name。

    如果需要的话，请运行 kubectl get constraint 以查看系统中安装了哪些限制条件模板和限制条件。

记下 kubectl describe 命令输出的 metadata.generation 和 status.byPod.observedGeneration 字段中的值。在以下示例中，这些值以粗体显示：

Name:         no-internet-services
Namespace:
API Version:  constraints.gatekeeper.sh/v1beta1
Kind:         K8sNoExternalServices
Metadata:
  Creation Timestamp:  2021-12-03T19:00:06Z
  Generation:          1
  Managed Fields:
    API Version:  constraints.gatekeeper.sh/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:config.k8s.io/owning-inventory:
          f:configmanagement.gke.io/cluster-name:
          f:configmanagement.gke.io/managed:
          f:configmanagement.gke.io/source-path:
          f:configmanagement.gke.io/token:
          f:configsync.gke.io/declared-fields:
          f:configsync.gke.io/git-context:
          f:configsync.gke.io/manager:
          f:configsync.gke.io/resource-id:
        f:labels:
          f:app.kubernetes.io/managed-by:
          f:configsync.gke.io/declared-version:
      f:spec:
        f:parameters:
          f:internalCIDRs:
    Manager:      configsync.gke.io
    Operation:    Apply
    Time:         2022-02-15T17:13:20Z
    API Version:  constraints.gatekeeper.sh/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
    Manager:         gatekeeper
    Operation:       Update
    Time:            2021-12-03T19:00:08Z
  Resource Version:  41460953
  UID:               ac80849d-a644-4c5c-8787-f73e90b2c988
Spec:
  Parameters:
    Internal CID Rs:
Status:
  Audit Timestamp:  2022-02-15T17:21:51Z
  By Pod:
    Constraint UID:       ac80849d-a644-4c5c-8787-f73e90b2c988
    Enforced:             true
    Id:                   gatekeeper-audit-5d4d474f95-746x4
    Observed Generation:  1
    Operations:
      audit
      status
    Constraint UID:       ac80849d-a644-4c5c-8787-f73e90b2c988
    Enforced:             true
    Id:                   gatekeeper-controller-manager-76d777ddb8-g24dh
    Observed Generation:  1
    Operations:
      webhook
  Total Violations:  0
Events:              <none>

如果您看到每个 Policy Controller Pod 的 observedGeneration 值都等于 metadata.generation 值（在前面的示例中都是这种情况），则您的限制条件可能已强制执行。但是，如果这些值匹配，但您仍然遇到与强制执行限制条件相关的问题，请参阅下一部分了解提示。如果您发现只有部分值匹配，或者未列出某些 Pod，则限制条件的状态未知。限制条件可能未在各个政策控制器的 Pod 中一致地实施，或者根本未强制执行。如果没有匹配的值，则系统不会强制执行您的限制条件。

未强制执行限制条件，但报告了审核结果

如果先前部分所述的 observedGeneration 检查具有匹配值，并且限制条件报告的审核结果显示预期的违规行为（针对现有对象，而非入站请求），但仍然没有强制执行限制条件，那么问题很可能与 Webhook 有关。该 Webhook 可能遇到以下问题之一：

  • 政策控制器 Webhook Pod 可能无法正常运行。Kubernetes 调试技术可能有助于您解决 webhook Pod 的问题。
  • API 服务器和网络钩子服务之间可能存在防火墙。如需详细了解如何修复防火墙，请参阅防火墙提供商的文档。

未强制执行参照限制条件

如果您的限制条件是一个参照限制条件，请确保缓存必要的资源。如需详细了解如何缓存资源，请参阅为参照限制条件配置政策控制器。

检查限制条件模板语法

如果编写了自己的限制条件模板，但未强制执行，则限制条件模板语法中可能存在错误。

您可以使用以下命令查看模板：

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

将 CONSTRAINT_TEMPLATE_NAME 替换为您要调查的模板的名称。系统应该会在 status 字段中报告错误。

后续步骤