Airflow géré (3e génération) | Airflow géré (2e génération) | Airflow géré (ancienne 1re génération)
Cette page fournit des informations de dépannage pour les problèmes que vous pouvez rencontrer lors de la création d'environnements Managed Airflow.
Pour en savoir plus sur la mise à jour et la mise à niveau des environnements, consultez la page Résoudre les problèmes liés aux mises à jour et aux mises à niveau d'environnement.
Lorsque des environnements Managed Airflow sont créés, la majorité des problèmes se produisent pour les raisons suivantes :
Problèmes d'autorisation de compte de service.
Informations incorrectes de pare-feu, de DNS ou de routage.
Problèmes réseau. Par exemple, une configuration VPC non valide, des conflits d'adresses IP ou des plages d'adresses IP réseau trop restrictives.
Problèmes liés aux quotas.
Règles d'administration incompatibles
Autorisations insuffisantes pour créer un environnement
Si Managed Airflow ne peut pas créer d'environnement car votre compte ne dispose pas des autorisations nécessaires, les messages d'erreur suivants s'affichent :
ERROR: (gcloud.composer.environments.create) PERMISSION_DENIED: The caller
does not have permission
ou
ERROR: (gcloud.composer.environments.create) PERMISSION_DENIED: User not
authorized to act as service account <service-account-name>.
The user must be granted iam.serviceAccounts.actAs permission, included in
Owner, Editor, Service Account User role. See https://cloud.google.com/iam/docs
/understanding-service-accounts for additional details.
Solution : Attribuez des rôles à votre compte et au compte de service de votre environnement, comme décrit dans la section Contrôle des accès.
Dans Managed Airflow (Gen 2), assurez-vous que le compte de service Agent de service Cloud Composer (
service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com) dispose du rôle Extension de l'agent de service de l'API Cloud Composer v2.Assurez-vous que le rôle Éditeur est attribué à l'agent de service des API Google (
PROJECT_NUMBER@cloudservices.gserviceaccount.com).Dans la configuration du VPC partagé, suivez les instructions de configuration du VPC partagé.
Le compte de service de l'environnement ne dispose pas des autorisations nécessaires
Lorsque vous créez un environnement Managed Airflow, vous spécifiez un compte de service qui exécute les nœuds du cluster GKE de l'environnement. Si ce compte de service ne dispose pas des autorisations nécessaires pour l'opération demandée, Managed Airflow génère l'erreur suivante :
Errors in: [Web server]; Error messages:
Creation of airflow web server version failed. This may be an intermittent
issue of the App Engine service. You may retry the operation later.
{"ResourceType":"appengine.v1.version","ResourceErrorCode":"504","ResourceError
Message":"Your deployment has failed to become healthy in the allotted time
and therefore was rolled back. If you believe this was an error, try adjusting
the 'app_start_timeout_sec' setting in the 'readiness_check' section."}
Solution : Attribuez des rôles à votre compte et au compte de service de votre environnement, comme décrit dans la section Contrôle des accès.
Avertissements concernant les rôles IAM manquants dans les comptes de service
Lorsqu'une création d'environnement échoue, Managed Airflow génère le message d'avertissement suivant après une erreur : The issue may be caused by missing IAM roles in the following Service Accounts
....
Ce message d'avertissement met en évidence les causes possibles de l'erreur. Managed Airflow vérifie si les comptes de service de votre projet disposent des rôles requis. Si ce n'est pas le cas, il génère ce message d'avertissement.
Solution : Vérifiez que les comptes de service mentionnés dans le message d'avertissement disposent des rôles requis. Pour en savoir plus sur les rôles et les autorisations dans Managed Airflow, consultez Contrôle des accès.
Dans certains cas, vous pouvez ignorer cet avertissement. Managed Airflow ne vérifie pas les autorisations individuelles attribuées aux rôles. Par exemple, si vous utilisez des rôles IAM personnalisés, il est possible que le compte de service mentionné dans le message d'avertissement dispose déjà de toutes les autorisations requises. Dans ce cas, vous pouvez ignorer cet avertissement.
Un réseau VPC sélectionné pour l'environnement n'existe pas
Vous pouvez spécifier un réseau VPC et un sous-réseau pour votre environnement Managed Airflow lorsque vous le créez. Si vous ne spécifiez pas de réseau VPC, le service Managed Airflow sélectionne le VPC default et le sous-réseau default pour la région et la zone de l'environnement.
Si le réseau et le sous-réseau VPC spécifiés n'existent pas, Managed Airflow génère l'erreur suivante :
Errors in: [GKE cluster]; Error messages:
{"ResourceType":"gcp-types/container-v1:projects.locations.clusters","R
esourceErrorCode":"400","ResourceErrorMessage":{"code":400,"message":"P
roject \"<your composer project>\" has no network named \"non-existing-
vpc\".","status":"INVALID_ARGUMENT","statusMessage":"Bad
Request","requestPath":"https://container.googleapis.com/
v1/projects/<your composer
project>/locations/<zone>/clusters","httpMethod":"POST"}}
Solution :
- Dans Managed Airflow (Gen 2), vous pouvez créer des environnements qui utilisent Private Service Connect au lieu des réseaux VPC.
- Avant de créer un environnement, assurez-vous que le réseau VPC et le sous-réseau de votre nouvel environnement existent.
Configuration réseau incorrecte
La création d'environnements Managed Service for Apache Airflow nécessite une configuration réseau ou DNS appropriée. Suivez ces instructions pour configurer la connectivité aux API et services Google :
Si vous configurez des environnements Managed Service for Apache Airflow en mode VPC partagé, suivez également les instructions concernant le VPC partagé.
Un environnement Managed Service pour Apache Airflow utilise un sous-réseau pour les nœuds de cluster et des plages d'adresses IP pour les pods et les services. Pour assurer la communication avec ces plages d'adresses IP et d'autres, suivez ces instructions pour configurer les règles de pare-feu :
Vous pouvez également rechercher des entrées de journal dans certaines catégories de configuration GCE Networking et Subnetwork dans Cloud Logging pour voir si des erreurs ont été signalées lors de la création de l'environnement : Cloud Logging
Problèmes de quota rencontrés lors de la création d'environnements dans des réseaux à grande échelle
Lorsque vous créez des environnements Managed Service pour Apache Airflow dans des réseaux à grande échelle, vous pouvez rencontrer les limites de quota suivantes :
- Le nombre maximal d'appairages VPC par réseau VPC unique est atteint.
- Le nombre maximal de plages d'adresses IP de sous-réseau principales et secondaires est atteint.
- Le nombre maximal de règles de transfert du groupe d'appairage pour l'équilibrage de charge TCP/UDP interne est atteint.
Solution :
- Dans Managed Airflow (Gen 2), vous pouvez créer des environnements qui utilisent Private Service Connect au lieu des réseaux VPC.
- Dans Managed Airflow (ancienne 1re génération), appliquez l'approche recommandée pour Managed Airflow dans les réseaux à grande échelle.
Règles d'administration incompatibles
Les règles suivantes doivent être configurées de manière appropriée pour que les environnements Managed Airflow puissent être créés avec succès.
| Règles d'administration | Managed Airflow (3e génération) | Managed Airflow (2e génération) | Managed Airflow (ancienne génération 1) |
|---|---|---|---|
compute.disableSerialPortLogging |
Toutes les valeurs sont autorisées | Doit être désactivé | Désactivé pour les versions antérieures à 1.13.0. Sinon, n'importe quelle valeur. |
compute.requireOsLogin |
Toutes les valeurs sont autorisées | Toutes les valeurs sont autorisées | Doit être désactivé |
compute.vmCanIpForward |
Toutes les valeurs sont autorisées | Toutes les valeurs sont autorisées | Doit être autorisé (obligatoire pour les clusters GKE appartenant à Managed Airflow) lorsque le mode VPC natif (utilisation d'une adresse IP d'alias) n'est pas configuré |
compute.vmExternalIpAccess |
Toutes les valeurs sont autorisées | Doit être autorisé pour les environnements d'adresse IP publique | Doit être autorisé pour les environnements d'adresse IP publique |
compute.restrictVpcPeering |
Peut être appliqué | Impossible à appliquer | Impossible à appliquer |
compute.disablePrivateServiceConnectCreationForConsumers |
Toutes les valeurs sont autorisées | Vous ne pouvez pas interdire SERVICE_PRODUCERS pour les environnements d'adresses IP privées et publiques. N'affecte pas les environnements existants, qui peuvent fonctionner lorsque cette règle est activée. | Vous ne pouvez pas interdire SERVICE_PRODUCERS pour les environnements d'adresse IP privée. N'affecte pas les environnements existants, qui peuvent fonctionner lorsque cette règle est activée. |
compute.restrictPrivateServiceConnectProducer |
Lorsque ce paramètre est actif, ajoutez l'organisation google.com à la liste d'autorisation. |
Lorsque ce paramètre est actif, ajoutez l'organisation google.com à la liste d'autorisation. |
Toutes les valeurs sont autorisées |
Stratégies de limite d'accès des comptes principaux incompatibles
Les stratégies de limite d'accès des comptes principaux configurées dans votre organisation peuvent être configurées de manière à bloquer certaines opérations de votre environnement ou à empêcher la création de nouveaux environnements.
Dans ce cas, la ligne suivante peut s'afficher dans les messages d'erreur :
Operations on resource are denied due to an IAM Principal Access Boundary Policy.
Les composants de votre environnement se trouvent dans un locataire et un projet client. Le projet locataire est géré par Google et n'appartient pas à l'organisation dans laquelle se trouve l'environnement. Le compte de service de votre environnement doit disposer des autorisations nécessaires pour effectuer des opérations dans le projet locataire.
Solution :
- Ajoutez une expression de condition à la liaison de la règle pour exclure le compte de service de l'environnement de la règle. Pour obtenir un exemple de la façon d'exclure un compte principal afin que la stratégie ne s'applique pas à celui-ci, consultez Liaisons de règles conditionnelles pour les stratégies de limite d'accès des comptes principaux dans la documentation Identity and Access Management.
Restreindre les services utilisés dans une organisation ou un projet
Les administrateurs d'organisation ou de projet peuvent limiter les services Google utilisables dans leurs projets à l'aide de la contrainte de règle d'administration gcp.restrictServiceUsage.
Lorsque vous utilisez cette règle d'administration, il est important d'autoriser tous les services requis par Managed Airflow.
Messages d'erreur 400 : échec de déploiement du serveur Web Airflow.
Cette erreur peut être due à un échec de la création du cluster GKE d'un environnement d'adresse IP privée en raison du chevauchement des plages d'adresses IP.
Solution : recherchez les erreurs potentielles dans les journaux du cluster de votre environnement et résolvez le problème en fonction du message d'erreur GKE.
Échec de la création d'images d'environnement par Cloud Build
S'applique à : Managed Airflow (2e génération) et Managed Airflow (ancienne 1re génération).
Si le compte de service Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) ne dispose pas du rôle Compte de service Cloud Build (roles/cloudbuild.builds.builder) dans votre projet, les tentatives de création ou de mise à jour d'un environnement peuvent échouer et générer des erreurs liées aux autorisations.
Par exemple, le message denied: Permission "artifactregistry.repositories.uploadArtifacts" denied peut être suivi de ERROR: failed to push because we ran out of retries dans les journaux Cloud Build.
Pour résoudre ce problème, assurez-vous que le compte de service Cloud Build dispose du rôle Compte de service Cloud Build.
Étapes suivantes
- Créer des environnements
- Résoudre les problèmes liés aux mises à jour et aux mises à niveau d'environnement
- Access control (Contrôle des accès)