排解政策控制器問題

本頁說明如何解決 Policy Controller 的問題。

一般提示

下節提供一般建議，協助您解決 Policy Controller 的問題。

停用政策控制器

如果 Policy Controller 導致叢集發生問題，您可以在調查問題時停止 Policy Controller。

查看指標

檢查政策控制器指標有助於診斷政策控制器問題。

驗證安裝

您可以驗證 Policy Controller 和限制範本庫是否已成功安裝。

卸離 Policy Controller

在極少數情況下，您可能需要從叢集卸離 Policy Controller。這會完全停用 Policy Controller 的管理功能。請嘗試暫時停止 Policy Controller，看看是否能解決問題，再使用 detach 指令。

  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，則限制的狀態不明。這項限制可能無法在 Policy Controller 的 Pod 中一致地強制執行，或完全無法強制執行。如果沒有相符的值，系統就不會強制執行限制。

未強制執行限制，但會回報稽核結果

如果前一節所述的 observedGeneration 檢查有相符的值，且限制條件有稽核結果顯示預期違規事項 (適用於現有物件，不適用於傳入要求)，但限制條件仍未強制執行，問題可能與 Webhook 有關。Webhook 可能會遇到下列其中一個問題：

  • Policy Controller 網路鉤 Pod 可能無法運作。 Kubernetes 偵錯技術或許有助於解決 Webhook Pod 的問題。
  • API 伺服器和 Webhook 服務之間可能有防火牆。如要瞭解如何修正防火牆，請參閱防火牆供應商的說明文件。

未強制執行參照限制

如果限制是參照限制，請確認必要的資源已快取。如要進一步瞭解如何快取資源，請參閱為參照限制設定 Policy Controller。

檢查限制範本語法

如果您自行編寫限制範本，但系統未強制執行，可能是限制範本語法有誤。

您可以使用下列指令檢閱範本：

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

將 CONSTRAINT_TEMPLATE_NAME 替換為要調查的範本名稱。錯誤應回報在 status 欄位中。

後續步驟