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.
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.
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"
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:
|
|
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:
|
|
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.
Filtre esta mensagem usando a seguinte consulta:
resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"
Para resolver o problema:
Ative a API
connectgateway
necessária.gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]
Execute uma reinicialização gradual nas cargas de trabalho.