Esta é a versão Arquivada da documentação. O período de avaliação gratuita terminou em 30 de setembro de 2021.

Consulte a documentação de versão do GA para detalhes sobre como instalar o Cloud Run for Anthos como um componente da frota do Anthos com o Anthos Service Mesh.

Versões disponíveis

Mais recente
Arquivar

Problemas conhecidos no Cloud Run para Anthos

Nesta página, você verá uma lista de problemas conhecidos do Cloud Run for Anthos. Para ver as vulnerabilidades de segurança conhecidas, consulte Práticas recomendadas de segurança.

Você também pode verificar problemas existentes ou abrir novos nos issue trackers públicos.

Consulte também esta página para ver estratégias de solução de problemas, bem como soluções para alguns erros comuns.

Serviços travados em `RevisionMissing` devido à ausência de `MutatingWebhookConfiguration`

A criação de um novo serviço ou uma nova revisão de serviço pode ficar travada no estado "RevisionMissing" devido a uma configuração de webhook ausente. Você pode confirmar isso usando o comando

kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev

que retorna

kmutatingwebhookconfigurations.admissionregistration.k8s.io "webhook.serving.knative.dev" not found`

Solução alternativa temporária

Até que isso seja corrigido em uma versão futura, você poderá fazer o seguinte para corrigir esse problema:

Reinicie o pod do webhook para recriar a MutatingWebhookConfiguration:

kubectl delete pod -n knative-serving -lapp=webhook
kubectl get mutatingwebhookconfiguration --watch

Reinicie os controladores:

kubectl delete pod -n gke-system -listio=pilot
kubectl delete pod -n knative-serving -lapp=controller

Implante uma nova revisão para cada serviço que tenha o problema RevisionMissing:
```
gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""
```
substituindo SERVICE pelo nome do serviço.
Repita as etapas acima conforme necessário se tiver o mesmo problema ao implantar novas revisões do serviço.

Clusters zonais

Ao usar um cluster zonal com o Cloud Run para Anthos, o acesso ao plano de controle fica indisponível durante a manutenção do cluster.

Durante esse período, o Cloud Run for Anthos pode não funcionar conforme o esperado. Serviços implantados nesse cluster

não são mostrados no Console do Cloud ou pela CLI gcloud;
não podem ser excluídos ou atualizados;
não farão escalonamento automático das instâncias, mas as existentes continuarão a atender novas solicitações.

Para evitar esses problemas, use um cluster regional, que garante um plano de controle de alta disponibilidade.

O limite de memória padrão não é aplicado pela linha de comando

Se você usar a linha de comando para implantar seus serviços, inclua a sinalização --memory para definir um limite de memória para esse serviço. A exclusão da sinalização --memory permite que um serviço consuma até a quantidade total de memória disponível no nó em que esse pod está em execução, o que pode ter efeitos colaterais inesperados.

Ao implantar usando o Console do Google Cloud, o valor padrão de 256M é usado, a menos que outro valor seja especificado.

Para não precisar definir limites padrão para cada serviço, você pode escolher definir um limite de memória padrão para o namespace em que esses serviços são implantados. Para saber mais, consulte Como configurar limites de memória padrão na documentação do Kubernetes.

O limite de CPU padrão não está ativado.

Ao implantar usando a linha de comando ou o Console, a quantidade de CPU que um serviço pode usar não é definida. Isso permite que o serviço consuma toda a CPU disponível no nó em que ele está em execução, o que pode ter efeitos secundários inesperados.

Para solucionar isso, defina um limite de CPU padrão para o namespace em que você está implantando os serviços com o Cloud Run for Anthos. Para mais informações, consulte Como configurar limites de CPU padrão na documentação do Kubernetes.

Observação: por padrão, os serviços implantados com o Cloud Run for Anthos solicitam a CPU 400m, que é usada para programar instâncias de um serviço nos nós do cluster.

O conteúdo dos pontos de leitura/gravação no contêiner está sempre vazio

Se você tiver um contêiner que cria arquivos ou pastas em /var/log, por exemplo, /var/log/nginx, quando executá-lo no Cloud Run for Anthos, esses arquivos ou pastas não ficarão visíveis porque um volume de leitura/gravação foi ativado em /var/log, que oculta o conteúdo do contêiner subjacente.

Se o serviço precisar gravar em um subdiretório de /var/log, ele precisará garantir que a pasta exista no ambiente de execução antes de ser gravado nela. Não é possível presumir que a pasta existe a partir da imagem de contêiner.

Alternativa

Se você fez upgrade do cluster para a versão 1.17 do GKE e está com problemas na implantação do serviço, exclua o VirtualService que foi gerado pelo DomainMapping porque ele não é mais compatível com o novo controlador. Depois de excluí-lo, o controlador recria um VirtualService compatível e resolve seus problemas de implantação do serviço.

Execute os comandos a seguir para excluir o VirtualService, em que o nome do VirtualService é o mesmo que seu DomainMappings. Exemplo: foo.example.com

Execute o seguinte comando para listar todos os DomainMappings:
```
kubectl get domainmapping --all-namespaces
```

Execute o seguinte comando para excluir o VirtualService especificado:

kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace

Como implantar imagens de contêiner privadas no Artifact Registry

Há um problema de implantação conhecido que é causado por uma falha de autenticação entre o Cloud Run for Anthos e o Artifact Registry quando imagens de contêiner privadas são implantadas. Para evitar problemas ao implantar imagens privadas no Artifact Registry, você pode:

Usar o resumo de imagem das imagens de contêiner particular para implantar um serviço.
Criar e usar um imagePullSecret. A utilização de um imagePullSecret permite que você use a tag de imagem das suas imagens de contêiner particulares. Para mais detalhes, consulte Como implantar imagens de contêiner privadas de outros registros de contêiner.

Erros de configuração em clusters atualizados para a versão `0.20.0-gke.6`

Os clusters que são atualizados para a versão 0.20.0-gke.6 podem receber um dos seguintes erros.

Ao atualizar o configmap do cluster, ele pode receber o seguinte erro:

Error from server (InternalError): error when replacing "/tmp/file.yaml":
Internal error occurred: failed calling webhook "config.webhook.istio.networking.internal.knative.dev":
the server rejected our request for an unknown reason

Se os pods não forem iniciados devido a um problema de proxy na fila, o cluster poderá receber o seguinte erro:

Startup probe failed: flag provided but not defined: -probe-timeout

Para resolver o erro, execute o seguinte comando para remover a configuração validatingwebhookconfiguration que não é mais compatível com 0.20.0:

kubectl delete validatingwebhookconfiguration config.webhook.istio.networking.internal.knative.dev

Depois de remover a configuração não compatível, continue a atualização do configmap do cluster.

Métricas ausentes após o upgrade para o Cloud Run para Anthos 0.23.0-gke.9

Problema: as seguintes métricas estão ausentes após o upgrade da versão do cluster para 0.23.0-gke.9: Request count, Request latencies e Container instance count

Possível causa: o Metric Collector está desativado.

Para determinar se o Metric Collector está impedindo a coleta das métricas:

Verifique se sua versão do Cloud Run for Anthos é 0.23.0-gke.9 executando o seguinte comando:

kubectl get deployment controller -n knative-serving -o jsonpath='{.metadata.labels.serving\.knative\.dev/release}'

Para verificar se o Metric Collector está desativado, execute o seguinte comando:
```
kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
```
O Metric Collector será desativado se o resultado não for {enabled: true}.

Para ativar o Metric Collector, execute um dos seguintes comandos:

Se o campo de resultado estiver vazio, execute:

kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec", "value": NULL}, {"op": "add", "path": "/spec", "value": {}}]'
kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec/metricscollector", "value": NULL}, {"op": "add", "path": "/spec/metricscollector", "value": {}}]'
kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "add", "path": "/spec/metricscollector/enabled", "value": true}]'

Se o resultado for {enabled: false}, execute:

kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "replace", "path": "/spec/metricscollector/enabled", "value": true}]'

Para verificar se o Metric Collector está ativado, execute o seguinte comando:

kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'