Resolver problemas do Policy Controller

Nesta página, mostramos como resolver problemas com o Policy Controller.

Dicas gerais

A seção a seguir fornece recomendações gerais para resolver problemas com o Policy Controller.

Interromper o Policy Controller

Se o Policy Controller estiver causando problemas no cluster, será possível interromper o Policy Controller enquanto investiga o problema.

Analisar as métricas

O exame das métricas do Policy Controller pode ajudar a diagnosticar problemas no Policy Controller.

Confirme a instalação

É possível verificar se o Policy Controller e a biblioteca de modelos de restrição foram instalados.

Remover o Policy Controller

Em casos raros, pode ser necessário remover o Policy Controller dos clusters. Isso desativa totalmente o gerenciamento do Policy Controller. Tente interromper temporariamente o Policy Controller para descobrir se é possível resolver problemas antes de usar o comando detach.

  1. Remova o Policy Controller de toda a frota:

    gcloud container fleet policycontroller detach

  2. Anexe novamente o Policy Controller:

    gcloud container fleet policycontroller enable

Erro ao criar um modelo de restrição

Se você receber um erro que menciona um disallowed ref, confira se você ativou as restrições referenciais. Por exemplo, se você usar data.inventory em um modelo de restrição sem ativar restrições referenciais primeiro, o erro será 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 seção a seguir fornece orientações para solução de problemas se você suspeitar ou souber que as restrições não estão sendo aplicadas.

Verificar se a restrição foi aplicada

Se você acredita que sua restrição não foi aplicada, verifique o spec.status da restrição e o modelo de restrição. Para verificar o status, execute o comando a seguir.

kubectl describe CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Substitua:

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

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

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

Na saída do comando kubectl describe, anote os valores nos campos metadata.generation e status.byPod.observedGeneration. No exemplo a seguir, esses 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 você vir todos os pods do Policy Controller com um valor observedGeneration igual ao valor metadata.generation (como no exemplo anterior), sua restrição provavelmente será aplicada. No entanto, se esses valores corresponderem, mas você ainda estiver com problemas com a restrição sendo aplicada, consulte a seção a seguir para dicas. Se você perceber que há apenas alguns valores correspondentes, ou alguns pods não estão listados, o status da sua restrição é desconhecido. A restrição pode ser aplicada de maneira inconsistente nos pods do Policy Controller ou não ser aplicada. Se não houver valores correspondentes, a restrição não será aplicada.

A restrição não é aplicada, mas os resultados da auditoria são informados

Se a verificação observedGeneration descrita na seção anterior tiver valores correspondentes e houver resultados de auditoria informados na restrição que mostram violações esperadas (para objetos preexistentes, não para solicitações de entrada), mas a restrição ainda não foi aplicada, o problema provavelmente está relacionado ao webhook. O webhook pode estar com 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 do webhook.
  • Pode haver um firewall entre o servidor de API e o serviço de webhook. Consulte a documentação do seu provedor de firewall para ver detalhes sobre como corrigir o firewall.

Restrição referencial não aplicada

Se a restrição for do tipo restrição referencial, verifique se os recursos necessários estão sendo armazenados em cache. Para detalhes sobre como armazenar recursos em cache, consulte Configurar o Policy Controller para restrições referenciais.

Verificar a sintaxe do modelo de restrição

Se você escreveu seu próprio modelo de restrição e ele não foi aplicado, pode haver um erro na sintaxe do modelo de restrição.

É possível revisar o modelo usando o seguinte comando:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Substitua CONSTRAINT_TEMPLATE_NAME pelo nome do modelo que você quer investigar. Informe os erros no campo status.

A seguir