Resolver problemas do Config Controller

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

Resolver problemas de instalação

Nenhuma rede nomeada como padrão

Ao criar uma instância do Config Controller, você pode receber um erro sobre a indisponibilidade da rede padrão:

Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n  on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"

Esse erro ocorrerá se você não especificar uma rede atual com o flag --network e sua rede padrão no Google Cloud for excluída ou desativada. Por padrão, o Config Controller cria o cluster da edição Google Kubernetes Engine (GKE) Enterprise que faz o backup da instância do Config Controller na rede padrão.

Se você quiser criar a instância em uma rede atual, adicione o flag --network=NETWORK ao criar a instância do Config Controller. Substitua NETWORK pelo nome de uma rede atual.

Se você quiser criar a instância do Config Controller na rede padrão, recrie-a com o comando a seguir:

gcloud compute networks create default --subnet-mode=auto

Para que esse comando funcione, é necessário ativar sub-redes automáticas com o flag --subnet-mode=auto.

Depois de recriar sua rede padrão, é possível omitir o flag --network ao criar a instância do Config Controller.

Valor inválido para MasterIpv4CidrBlock

A criação do Config Controller usa uma sub-rede padrão 172.16.0.128/28 para o CIDR IPv4 do plano de controle. Se houver um conflito no bloco de CIDR do IPv4, a criação do Config Controller falhará com o seguinte erro:

Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.

Se você vir esse erro, selecione um CIDR IPv4 particular diferente e use-o usando a sinalização --master-ipv4-cidr-block no comando gcloud anthos config controller create.

Para encontrar blocos CIDR IPv4 que já estão em uso, conclua as seguintes etapas:

  1. Encontre o nome do peering:

    gcloud compute networks peerings list --network=NETWORK

    Substitua NETWORK pelo nome da rede que você quer pesquisar.

    O resultado será assim:

    NAME                                    NETWORK   PEER_PROJECT               PEER_NETWORK                            PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
gke-n210ce17a4dd120e16b6-7ebf-959a-peer  default  gke-prod-us-central1-59d2  gke-n210ce17a4dd120e16b6-7ebf-0c27-net            False                 False                 ACTIVE  [2021-06-08T13:22:07.596-07:00]: Connected.

  2. Mostre o CIDR IPv4 usado pelo peering:

    gcloud compute networks peerings list-routes PEERING_NAME \
    --direction=INCOMING \
    --network=NETWORK \
    --region=REGION

    Substitua:

    • PEERING_NAME: o nome do peering que você quer pesquisar.
    • NETWORK: o nome da rede que você quer pesquisar.
    • REGION: o nome da região em que a instância do Config Controller está

Resolver problemas ao executar o Config Controller

Não há IPs do pool de nós

Se a mensagem de erro a seguir for exibida, talvez os pools de nós não tenham endereços IP suficientes:

Can't scale up because instances in managed instance groups hosting node pools ran out of IPs

Esse problema poderá acontecer se você omitir o flag --cluster-ipv4-cidr-block. Ao omitir esse flag, o Config Controller assume como padrão o intervalo de CIDR de pod /20. Ele pode ter no máximo 16 nós.

Se você precisar de mais nós, exclua a instância do Config Controller, já que não é possível modificar o bloco de CIDR após a criação. Ao recriar a instância do Config Controller, use o parâmetro opcional --cluster-ipv4-cidr-block e especifique o CIDR range or netmask size.

Faltam informações no painel

Se você não encontrar detalhes do Config Controller no painel do console do Google Cloud, a conta de serviço padrão usada pelo Config Controller pode não ter as permissões de observabilidade do Google Cloud necessárias.

Para conceder essas permissões, use os seguintes comandos:

# Cloud Monitoring metrics permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/monitoring.metricWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/stackdriver.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/opsconfigmonitoring.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Logging permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/logging.logWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Trace permissions\
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudtrace.agent \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Substitua:

  • PROJECT_ID: o ID do projeto em que você criou a instância do Config Controller
  • PROJECT_NUMBER: o número do projeto do Google Cloud.

Resolver problemas de componentes

Como a instância do Config Controller vem pré-instalada com o Policy Controller, o Config Sync e o Config Connector, você pode encontrar problemas com esses componentes. Para saber como resolver problemas nesses componentes, consulte as seguintes páginas:

As seções a seguir fornecem conselhos sobre alguns dos problemas mais comuns que você pode encontrar ao usar o Config Controller com esses componentes.

Erros de sincronização

As configurações na sua fonte de informações (por exemplo, um repositório Git ou uma imagem OCI) são sincronizadas com a instância do Config Controller com o Config Sync. Verifique se há erros nesse processo de sincronização usando o comando nomos status:

nomos status  --contexts $(kubectl config current-context)

Resolver problemas com recursos do Config Connector

Campos e recursos imutáveis

Alguns campos nos recursos subjacentes do Google Cloud são imutáveis, como IDs do projeto ou o nome da sua rede VPC. O Config Connector bloqueia as edições nesses campos e não pode ativar as alterações. Se você quiser editar um desses campos imutáveis, exclua o recurso original (usando o Git) antes de adicioná-lo novamente com seus valores preferenciais.

Recursos travados

Às vezes, os recursos podem não ser excluídos corretamente (conforme informado por nomos status). Para corrigir esse problema, remova os finalizadores e exclua o recurso manualmente.

Por exemplo, para excluir um IAMPolicyMember que esteja travado, execute o seguinte comando:

kubectl patch IAMPolicyMember logging-sa-iam-permissions \
    -p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control

A seguir