Como resolver problemas gerenciados do Anthos Service Mesh

Este documento explica problemas comuns do Anthos Service Mesh e como resolvê-los, como quando um pod é injetado com istio.istio-system, a ferramenta de instalação gera erros como códigos de status HTTP 400 e erros de associação a clusters.

Se você precisar de mais ajuda para resolver problemas do Anthos Service Mesh, consulte Como receber suporte.

O status das revisões é considerado não íntegros

É possível encontrar um erro Revision(s) reporting unhealthy genérico se o Anthos Service Mesh gerenciado não tiver a conta de serviço gerenciada pelo Google necessária com as vinculações de papéis do Identity and Access Management (IAM) do agente de serviço do Anthos Service Mesh. Geralmente, isso ocorre quando a permissão do papel de agente de serviço do Anthos Service Mesh é revogada pelo Terraform, pelo Puppet ou pela reconfiguração de CI/CD.

As etapas necessárias para solucionar esse erro dependem do uso do console do Google Cloud ou da Google Cloud CLI.

Console do Google Cloud

No console do Google Cloud, acesse o IAM e administrador > IAM.
Selecione Incluir concessões de papel fornecidas pelo Google.
Revise a lista Principal.

Se você vir a conta de serviço gerenciada com o papel do IAM necessário na lista, isso significa que ela está configurada corretamente.

Observação :o formato do nome da conta de serviço gerenciado é service-${PROJECT_NUMBER}@gcp-sa-servicemesh.iam.gserviceaccount.com, e o nome do papel do IAM necessário para o Anthos Service Mesh é Anthos Service Mesh Service Agent(roles/anthosservicemesh.serviceAgent).

Se você não encontrar a conta de serviço gerenciada necessária com o papel do IAM necessário na lista, isso significa que a vinculação obrigatória do IAM do agente de serviço do Anthos Service Mesh não existe na conta de serviço gerenciada.
Conceda vinculações do papel de IAM do agente de serviço do Anthos Service Mesh (roles/anthosservicemesh.serviceAgent) à conta de serviço gerenciada do Anthos Service Mesh no console do Google Cloud.

Observação :verifique se você não tem ferramentas automatizadas que reverterão essa mudança. Se o erro se repetir, atualize todas as configurações ou listas de permissões relevantes.

Google Cloud CLI

Na Google Cloud CLI, execute o seguinte comando para verificar se o papel do IAM necessário está configurado:

gcloud projects get-iam-policy PROJECT_ID  \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \
--format='table(bindings.role)'

Revise a ROLE lista.

Se visualizar um papel na lista, ele está configurado corretamente.

Se nenhum papel for exibido na lista, todos os papéis gerenciados da conta de serviço foram revogados.
Execute o comando a seguir para atribuir vinculações de papéis do IAM apropriadas à conta de serviço gerenciada do Anthos Service Mesh:
```
 gcloud projects add-iam-policy-binding PROJECT_ID \
 --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
 --role="roles/anthosservicemesh.serviceAgent"
```
Observação :verifique se você não tem ferramentas automatizadas que reverterão essa mudança. Se o erro se repetir, atualize todas as configurações ou listas de permissões relevantes.

O pod é injetado com istiod.istio-system

Isso pode ocorrer se você não substituiu o rótulo istio-injection: enabled.

Além disso, verifique a configuração de webhooks mutáveis usando o seguinte comando:

kubectl get mutatingwebhookconfiguration

...
istiod-asm-managed
…
# may include istio-sidecar-injector

kubectl get mutatingwebhookconfiguration   istio-sidecar-injector -o yaml

# Run debug commands
export T=$(echo '{"kind":"TokenRequest","apiVersion":"authentication.k8s.io/v1","spec":{"audiences":["istio-ca"], "expirationSeconds":2592000}}' | kubectl create --raw /api/v1/namespaces/default/serviceaccounts/default/token -f - | jq -j '.status.token')

export INJECT_URL=$(kubectl get mutatingwebhookconfiguration istiod-asmca -o json | jq -r .webhooks[0].clientConfig.url)
export ISTIOD_ADDR=$(echo $INJECT_URL | 'sed s/\/inject.*//')

curl -v -H"Authorization: Bearer $T" $ISTIOD_ADDR/debug/configz

A ferramenta de instalação gera erros HTTP 400

A ferramenta de instalação pode gerar erros HTTP 400 como este:

HealthCheckContainerError, message: Cloud Run error: Container failed to start.
Failed to start and then listen on the port defined by the PORT environment
variable. Logs for this revision might contain more information.

Isso pode ocorrer se você não tiver ativado a identidade da carga de trabalho no cluster do Kubernetes, o que pode ser feito usando o seguinte comando:

export CLUSTER_NAME=...
export PROJECT_ID=...
export LOCATION=...
gcloud container clusters update $CLUSTER_NAME --zone $LOCATION \
    --workload-pool=$PROJECT_ID.svc.id.goog

Estado do plano de dados gerenciado

O comando a seguir exibe o status do plano de dados gerenciado:

gcloud container fleet mesh describe --project PROJECT_ID

A tabela a seguir lista todos os estados possíveis do plano de dados gerenciados:

Estado	Código	Descrição
`ACTIVE`	`OK`	O plano de dados gerenciado está em execução normalmente.
`DISABLED`	`DISABLED`	O plano de dados gerenciado se encontra nesse estado se nenhum namespace ou revisão está configurado para usá-lo. Siga as instruções para ativar o Anthos Service Mesh gerenciado pela API Fleet ou ativar o plano de dados gerenciado após o provisionamento do Anthos Service Mesh gerenciado com `asmcli`. Os relatórios de status do plano de dados gerenciado só estarão disponíveis se você tiver ativado o plano de dados gerenciado anotando um namespace ou revisão. Inserir anotações individuais faz com que esses pods sejam gerenciados, mas com um estado de recurso `DISABLED` se nenhum namespace ou revisão for anotado.
`FAILED_PRECONDITION`	`MANAGED_CONTROL_PLANE_REQUIRED`	O plano de dados gerenciado exige um plano de controle gerenciado do Anthos Service Mesh.
`PROVISIONING`	`PROVISIONING`	O plano de dados gerenciado está sendo provisionado. Se esse estado persistir por mais de 10 minutos, é provável que tenha ocorrido um erro. Entre em contato com o suporte.
`STALLED`	`INTERNAL_ERROR`	O plano de dados gerenciado está impedido de operar devido a uma condição de erro interna. Se o problema persistir, entre em contato com o suporte.
`NEEDS_ATTENTION`	`UPGRADE_FAILURES`	O plano de dados gerenciado exige intervenção manual para que o serviço volte ao estado normal. Para mais informações e como resolver esse problema, consulte o estado `NEEDS_ATTENTION`.

`NEEDS_ATTENTION` estado

Se o comando gcloud container fleet mesh describe mostrar que o estado do plano de dados gerenciado está no estado NEEDS_ATTENTION e o código é UPGRADE_FAILURES, significa que o plano de dados gerenciado não fez o upgrade de determinadas cargas de trabalho. Essas cargas de trabalho serão rotuladas com dataplane-upgrade: failed pelo serviço do plano de dados gerenciado para uma análise mais detalhada. Os proxies precisam ser reiniciados manualmente para serem atualizados. Para ver a lista de pods que exigem a atenção, execute o seguinte comando:

kubectl get pods --all-namespaces -l dataplane-upgrade=failed

Erro de associação do cluster (nenhum provedor de identidade especificado)

A ferramenta de instalação pode falhar com erros de associação de cluster, como:

asmcli: [ERROR]: Cluster has memberships.hub.gke.io CRD but no identity
provider specified. Please ensure that an identity provider is available for the
registered cluster.

O erro pode ocorrer se você não tiver a identidade da carga de trabalho do GKE ativada antes de registrar o cluster. É possível registrar novamente o cluster na linha de comando usando o comando gcloud container fleet memberships register --enable-workload-identity.

Verificar o status do plano de controle gerenciado

Para verificar o status do plano de controle gerenciado, execute gcloud container fleet mesh describe --project FLEET_PROJECT_ID.

Na resposta, o campo membershipStates[].servicemesh.controlPlaneManagement.details pode explicar o erro específico.

Se você precisar de mais detalhes, verifique o recurso personalizado ControlPlaneRevision no cluster, que é atualizado quando o plano de controle gerenciado é provisionado ou falha no provisionamento.

Para inspecionar o status do recurso, substitua NAME pelo valor correspondente a cada canal: asm-managed, asm-managed-stable ou asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

A resposta é semelhante a:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

A condição Reconciled determina se o plano de controle gerenciado está em execução corretamente. Se true, o plano de controle está sendo executado. Stalled determina se o processo de provisionamento do plano de controle gerenciado encontrou um erro. Se Stalled, o campo Message conterá mais informações sobre o erro específico. Consulte Códigos interrompidos para ver mais informações sobre possíveis erros.

Códigos interrompidos da ControlPlaneRevision

Há vários motivos para a condição Stalled se tornar verdadeira no status ControlPlaneRevisions.

Motivo	Mensagem	Descrição
PreconditionFailed	Só é possível usar assinaturas do GKE, mas ${CLUSTER_NAME} não é um cluster do GKE.	O cluster atual não parece ser um cluster do GKE. O plano de controle gerenciado só funciona em clusters do GKE.
	Nome de ControlPlaneRevision incompatível: ${NAME}	O nome do ControlPlaneRevision precisa ser um dos seguintes: asm-managed asm-managed-rapid asm-managed-stable
	Namespace de ControlPlaneRevision incompatível: ${NAMESPACE}	O namespace de ControlPlaneRevision precisa ser `istio-system`.
	O canal ${CHANNEL} não é compatível com a versão ControlPlaneRevision com o nome${NAME}. Esperados ${OTHER_CHANNEL}	O nome do ControlPlaneRevision precisa corresponder ao canal do ControlPlaneRevision com o seguinte: asm-managed -> normal asm-managed-rapid -> rápido asm-managed-stable -> estável
	O canal não pode ser omitido ou ficar em branco	`Channel` é um campo obrigatório no ControlPlaneRevision. Ele não foi encontrado ou está em branco no recurso personalizado.
	Tipo de revisão do plano de controle incompatível: ${TYPE}	`managed_service` é o único campo de permissão para o campo ControlPlaneRevisionType.
	Versão incompatível do Kubernetes: ${VERSION}	As versões 1.15+ do Kubernetes são compatíveis.
	A identidade da carga de trabalho não está ativada	Ative a identidade da carga de trabalho no cluster.
	Pool de carga de trabalho incompatível: ${POOL}	O pool de carga de trabalho precisa estar no formato `${PROJECT_ID}.svc.id.goog`.
	O projeto de cluster e o projeto de ambiente não correspondem	Os clusters precisam fazer parte do mesmo projeto em que estão registrados na frota.
ProvisioningFailed	Ocorreu um erro ao atualizar os recursos do cluster	O Google não conseguiu atualizar os recursos no cluster, como CRDs e webhooks.
	MutatingWebhookConfiguration "istiod-asm-managed" contém um webhook com o URL ${EXISTING_URL}, mas é esperado ${PENDING_URL}	O Google não substituirá os webhooks atuais para evitar falhas na instalação. Atualize manualmente se for o comportamento desejado.
	ValidatingWebhookConfiguration ${NAME} contém um webhook com o URL ${EXISTING_URL}, mas é esperado ${PENDING_URL}	O Google não substituirá os webhooks atuais para evitar falhas na instalação. Atualize manualmente se for o comportamento desejado.

O Anthos Service Mesh gerenciado não consegue se conectar ao cluster do GKE

Entre junho de 2022 e setembro de 2022, o Google concluiu o trabalho de segurança relacionado a redes autorizadas e Cloud Run e Cloud Functions no Google Kubernetes Engine (GKE). Os projetos que usavam o Anthos Service Mesh gerenciado, mas pararam de usá-lo antes da migração, não têm a API necessária para a comunicação entre o Cloud Run e o GKE.

Nesse cenário, o provisionamento gerenciado do Anthos Service Mesh falhará e o Cloud Logging exibirá a seguinte mensagem de erro:

Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Filtre esta mensagem usando a seguinte consulta:

resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"

Enquanto isso, a injeção do sidecar e a implantação de recursos personalizados do Kubernetes relacionados ao Anthos Service Mesh também falharão e o Cloud Logging exibirá a seguinte mensagem de aviso:

Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.