Il s'agit de la version archivée de la documentation. La période d'essai gratuit a pris fin le 30 septembre 2021.

Consultez la documentation de la version en disponibilité générale pour en savoir plus sur l'installation de Cloud Run for Anthos en tant que composant de parc Anthos avec Anthos Service Mesh.

Versions disponibles

Le plus récent
Archiver

Problèmes connus dans Cloud Run pour Anthos

Cette page répertorie les problèmes connus de Cloud Run for Anthos. Pour connaître les failles de sécurité connues, consultez la section Bonnes pratiques de sécurité.

Vous pouvez également consulter les problèmes existants ou signaler de nouveaux problèmes dans les outils publics de suivi des problèmes.

Consultez également la page Dépannage pour découvrir les stratégies de dépannage et les solutions pour certaines erreurs courantes.

Services bloqués à l'état `RevisionMissing` en raison d'une configuration `MutatingWebhookConfiguration` manquante

La création d'un service ou d'une révision de service peut rester bloquée à l'état "RevisionMissing" en raison d'une configuration de webhook manquante. Vous pouvez le vérifier à l'aide de la commande suivante :

kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev

qui renvoie

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

Solution temporaire

Tant que ce problème n'est pas résolu dans une version ultérieure, vous pouvez effectuer les opérations suivantes pour le corriger :

Redémarrez le pod du webhook pour recréer la configuration MutatingWebhookConfiguration :

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

Redémarrez les contrôleurs :

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

Déployez une nouvelle révision pour chaque service présentant le problème RevisionMissing :
```
gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""
```
en remplaçant SERVICE par le nom du service.
Répétez les étapes ci-dessus si vous rencontrez le même problème lorsque vous déployez de nouvelles révisions du service.

Cluster zonal

Lorsque vous utilisez un cluster zonal avec Cloud Run for Anthos, l'accès au plan de contrôle n'est pas disponible pendant la maintenance du cluster.

Durant cette période, il est possible que Cloud Run for Anthos ne fonctionne pas comme prévu. Les services déployés dans ce cluster :

ne sont pas affichés dans la console Cloud ni via gcloud CLI ;
ne peuvent pas être supprimés ou mis à jour ;
n'effectuent pas le scaling automatique des instances, mais les instances existantes continuent à traiter les nouvelles requêtes.

Pour éviter ces problèmes, vous pouvez utiliser un cluster régional, qui garantit un plan de contrôle à haute disponibilité.

La limite de mémoire par défaut n'est pas appliquée via la ligne de commande

Si vous déployez vos services à l'aide de la ligne de commande, vous devez inclure l'option --memory pour définir une limite de mémoire pour ce service. Exclure l'option --memory permet à un service de consommer jusqu'à la quantité totale de mémoire disponible sur le nœud sur lequel ce pod est en cours d'exécution, ce qui peut entraîner des effets secondaires inattendus.

Lors du déploiement via la console Google Cloud, la valeur par défaut de 256M est utilisée, sauf si une valeur différente est spécifiée.

Pour éviter d'avoir à définir des limites par défaut pour chaque service, vous pouvez définir une limite de mémoire par défaut pour l'espace de noms dans lequel vous déployez ces services. Pour en savoir plus, consultez la page Configurer les limites de mémoire par défaut dans la documentation de Kubernetes.

La limite de processeur par défaut n'est pas activée

Lorsque vous effectuez un déploiement à l'aide de la ligne de commande ou de la console, la quantité de processeurs qu'un service peut utiliser n'est pas définie. Cela permet au service de consommer tous les processeurs disponibles dans le nœud sur lequel il s'exécute, ce qui peut entraîner des effets secondaires inattendus.

Pour contourner ce problème, définissez une limite de processeur par défaut pour l'espace de noms dans lequel vous déployez des services avec Cloud Run for Anthos. Pour en savoir plus, consultez la page Configurer les limites de processeur par défaut dans la documentation de Kubernetes.

Remarque : Par défaut, les services déployés avec Cloud Run for Anthos demandent le processeur 400m, qui permet de planifier les instances d'un service sur les nœuds du cluster.

Le contenu des points de lecture/écriture du conteneur est toujours vide

Si un conteneur crée des fichiers ou des dossiers dans /var/log (par exemple, /var/log/nginx), ceux-ci ne sont pas visibles lorsque vous exécutez ce conteneur dans Cloud Run for Anthos, car un volume en lecture/écriture vide a été installé sur /var/log, ce qui masque le contenu du conteneur sous-jacent.

Si votre service doit écrire dans un sous-répertoire de /var/log, il doit s'assurer que le dossier existe au moment de l'exécution avant d'écrire dedans. Il ne peut pas supposer que le dossier existe à partir de l'image du conteneur.

Solution

Si vous avez mis à niveau votre cluster vers la version 1.17 de GKE et que vous rencontrez des problèmes avec le déploiement du service, vous devez supprimer la ressource VirtualService générée par DomainMapping, car ce service n'est plus compatible avec le nouveau contrôleur. Une fois supprimée, le contrôleur recrée une ressource VirtualService compatible et résout les problèmes de déploiement de votre service.

Exécutez les commandes suivantes pour supprimer votre ressource VirtualService, où le nom du service virtuel est identique à celui de vos DomainMappings. Par exemple : foo.example.com

Exécutez la commande suivante pour répertorier tous vos DomainMappings :
```
kubectl get domainmapping --all-namespaces
```
Exécutez la commande suivante pour supprimer la ressource VirtualService spécifiée :
```
kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace
```

Déployer des images de conteneur privées dans Artifact Registry

Un problème de déploiement connu est causé par un échec d'authentification entre Cloud Run for Anthos et Artifact Registry lors du déploiement d'images de conteneurs privées. Pour éviter les problèmes lors du déploiement d'images privées dans Artifact Registry, vous pouvez au choix :

utiliser le condensé de l'image de vos images de conteneurs privées pour déployer un service ;
Créez et utilisez un imagePullSecret. L'utilisation d'un fichier imagePullSecret vous permet d'utiliser le tag de vos images de conteneurs privées. Pour plus d'informations, consultez la section Déployer des images de conteneurs privées à partir d'autres registres de conteneurs.

Erreurs de configuration sur les clusters mis à niveau vers la version `0.20.0-gke.6`

Les clusters mis à niveau vers la version 0.20.0-gke.6 peuvent recevoir l'une des erreurs suivantes.

Lors de la mise à jour de la configuration de ce cluster, le cluster peut recevoir l'erreur suivante :

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

Si les pods ne démarrent pas en raison d'une défaillance du proxy de file d'attente, le cluster peut recevoir l'erreur suivante :

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

Pour résoudre l'erreur, vous devez exécuter la commande suivante pour supprimer la configuration validatingwebhookconfiguration qui n'est plus compatible avec 0.20.0 :

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

Après avoir supprimé la configuration non compatible, vous pouvez procéder à la mise à jour de la ConfigMap de votre cluster.

Métriques manquantes après la mise à niveau vers Cloud Run for Anthos 0.23.0-gke.9

Problème : les métriques suivantes sont manquantes après la mise à niveau de la version de votre cluster vers 0.23.0-gke.9 : Request count, Request latencies et Container instance count

Cause possible : Metric Collector est désactivé.

Pour déterminer si Metric Collector empêche la collecte de vos métriques, procédez comme suit :

Assurez-vous que votre version de Cloud Run for Anthos est 0.23.0-gke.9 en exécutant la commande suivante :

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

Vérifiez si Metric Collector est désactivé en exécutant la commande suivante :
```
kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
```
Si le résultat n'est pas {enabled: true}, votre Metric Collector est désactivé.

Pour activer Metric Collector, exécutez l'une des commandes suivantes :

Si le résultat est vide, exécutez :

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}]'

Si le résultat est {enabled: false}, exécutez :

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

Vérifiez que Metric Collector est activé en exécutant la commande suivante :

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