Resolva problemas do Controlador de políticas

Esta página mostra como resolver problemas com o Policy Controller.

Sugestões gerais

A secção seguinte fornece aconselhamento geral para resolver problemas com o Policy Controller.

Pare o Controlador de políticas

Se o Policy Controller estiver a causar problemas no seu cluster, pode parar o Policy Controller enquanto investiga o problema.

Examine as métricas

A análise das métricas do Policy Controller pode ajudar a diagnosticar problemas com o Policy Controller.

Valide a instalação

Pode validar se o Policy Controller e a biblioteca de modelos de restrições foram instalados com êxito.

Desassocie o Controlador de políticas

Em casos raros, pode ter de desassociar o Policy Controller dos seus clusters. Isto desativa completamente a gestão do Policy Controller. Experimente parar temporariamente o Policy Controller para ver se consegue resolver os problemas antes de usar o comando detach.

  1. Desassocie o Controlador de políticas em toda a sua frota:

    gcloud container fleet policycontroller detach

  2. Volte a anexar o controlador de políticas:

    gcloud container fleet policycontroller enable

Ocorreu um erro ao criar um modelo de restrição

Se vir um erro que mencione um disallowed ref, confirme que ativou as restrições referenciais. Por exemplo, se usar data.inventory num modelo de restrição sem ativar primeiro as restrições referenciais, o erro é semelhante ao seguinte:

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

Restrição não aplicada

A secção seguinte fornece orientações de resolução de problemas se suspeitar ou souber que as restrições não estão a ser aplicadas.

Verifique se a restrição é aplicada

Se tiver dúvidas de que a restrição não está a ser aplicada, pode verificar o spec.status da restrição e o modelo de restrição. Para verificar o estado, execute o seguinte comando:

kubectl describe CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Substitua o seguinte:

  • CONSTRAINT_TEMPLATE_NAME: o nome do modelo de restrição que quer verificar. Por exemplo, K8sNoExternalServices.

  • CONSTRAINT_NAME: o Name da restrição que quer verificar.

    Se necessário, execute kubectl get constraint para ver que modelos de restrições e restrições estão instalados no seu sistema.

No resultado do comando kubectl describe, tome nota dos valores nos campos metadata.generation e status.byPod.observedGeneration. No exemplo seguinte, estes valores estão em negrito:

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>

Se vir todos os pods do controlador de políticas com um valor observedGeneration igual ao valor metadata.generation (que é o caso no exemplo anterior), é provável que a restrição seja aplicada. No entanto, se estes valores corresponderem, mas continuar a ter problemas com a aplicação da restrição, consulte a secção seguinte para ver sugestões. Se reparar que apenas alguns valores correspondem ou que alguns pods não estão listados, o estado da restrição é desconhecido. A restrição pode ser aplicada de forma inconsistente nos pods do Policy Controller ou não ser aplicada de todo. Se não existirem valores que correspondam, a restrição não é aplicada.

Restrição não aplicada, mas resultados da auditoria comunicados

Se a verificação observedGeneration descrita na secção anterior tiver valores correspondentes e existirem resultados da auditoria comunicados na restrição que mostram violações esperadas (para objetos pré-existentes, não para pedidos de entrada), mas a restrição ainda não for aplicada, é provável que o problema esteja relacionado com o webhook. O webhook pode estar a ter um dos seguintes problemas:

  • O pod do webhook do Policy Controller pode não estar operacional. As técnicas de depuração do Kubernetes podem ajudar a resolver problemas com o pod webhook.
  • Pode existir uma firewall entre o servidor da API e o serviço de webhook. Consulte a documentação do fornecedor da firewall para ver detalhes sobre como corrigir a firewall.

Restrição referencial não aplicada

Se a sua restrição for uma restrição referencial, certifique-se de que os recursos necessários estão a ser colocados em cache. Para ver detalhes sobre como colocar recursos em cache, consulte o artigo Configure o Policy Controller para restrições referenciais.

Verifique a sintaxe do modelo de restrição

Se escreveu o seu próprio modelo de restrição, e este não for aplicado, pode existir um erro na sintaxe do modelo de restrição.

Pode rever o modelo através do seguinte comando:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Substitua CONSTRAINT_TEMPLATE_NAME pelo nome do modelo que quer investigar. Os erros devem ser comunicados no campo status.

O que se segue?