Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1
Cette page explique comment utiliser KubernetesPodOperator pour déployer des pods Kubernetes à partir de Cloud Composer dans le cluster Google Kubernetes Engine appartenant à votre environnement Cloud Composer.
KubernetesPodOperator lance les pods Kubernetes dans le cluster de votre environnement. Les opérateurs Google Kubernetes Engine, quant à eux, exécutent des pods Kubernetes dans un cluster spécifié, qui peut être un cluster distinct et non lié à votre environnement. Vous pouvez également créer et supprimer des clusters à l'aide d'opérateurs Google Kubernetes Engine.
KubernetesPodOperator est une bonne option si vous avez besoin:
- de dépendances Python personnalisées qui ne sont pas disponibles via le dépôt PyPI public ;
- de dépendances binaires qui ne sont pas disponibles dans l'image de nœud de calcul Cloud Composer issue de la banque d'images.
Avant de commencer
Consultez la liste suivante des différences entre KubernetesPodOperator dans Cloud Composer 3 et Cloud Composer 2, et assurez-vous que vos DAG sont compatibles:
Il n'est pas possible de créer d'espaces de noms personnalisés dans Cloud Composer 3. Les pods s'exécutent toujours dans l'espace de noms
composer-user-workloads
, même si un autre espace de noms est spécifié. Les pods de cet espace de noms ont accès aux ressources de votre projet et au réseau VPC (s'il est activé) sans configuration supplémentaire.Vous ne pouvez pas créer de secrets ni de ConfigMaps Kubernetes à l'aide de l'API Kubernetes. À la place, Cloud Composer fournit des commandes Google Cloud CLI, des ressources Terraform et l'API Cloud Composer pour gérer les secrets et les ConfigMaps Kubernetes. Pour en savoir plus, consultez la section Utiliser des secrets et des ConfigMaps Kubernetes.
Il n'est pas possible de déployer des charges de travail personnalisées dans Cloud Composer 3. Seuls les secrets et les ConfigMaps Kubernetes peuvent être modifiés, mais toutes les autres modifications de configuration ne sont pas possibles.
Les exigences en termes de ressources (processeur, mémoire et stockage) doivent être spécifiées à l'aide des valeurs acceptées.
Comme dans Cloud Composer 2, la configuration de l'affinité de pod n'est pas disponible. Si vous souhaitez utiliser l'affinité de pod, utilisez plutôt les opérateurs GKE pour lancer des pods dans un autre cluster.
À propos de KubernetesPodOperator dans Cloud Composer 3
Cette section décrit le fonctionnement de KubernetesPodOperator dans Cloud Composer 3.
Utilisation des ressources
Dans Cloud Composer 3, le cluster de votre environnement évolue automatiquement. Les charges de travail supplémentaires que vous exécutez à l'aide de KubernetesPodOperator évoluent indépendamment de votre environnement. Votre environnement n'est pas affecté par l'augmentation de la demande de ressources, mais son cluster peut évoluer à la hausse en fonction de la demande de ressources.
La tarification des charges de travail supplémentaires que vous exécutez dans le cluster de votre environnement suit le modèle de tarification de Cloud Composer 3 et utilise les SKU Cloud Composer 3.
Cloud Composer 3 utilise des clusters Autopilot qui introduisent la notion de classes de calcul:
Cloud Composer n'est compatible qu'avec la classe de calcul
general-purpose
.Par défaut, si aucune classe n'est sélectionnée, la classe
general-purpose
est supposée lorsque vous créez des pods à l'aide de KubernetesPodOperator.Chaque classe est associée à des propriétés et des limites de ressources spécifiques. Pour en savoir plus, consultez la documentation Autopilot. Par exemple, les pods exécutés dans la classe
general-purpose
peuvent utiliser jusqu'à 110 Go de mémoire.
Accès aux ressources du projet
Dans Cloud Composer 3, le cluster de votre environnement se trouve dans le projet du locataire. Les pods sont exécutés dans le cluster de l'environnement, dans un espace de noms isolé.
Dans Cloud Composer 3, les pods s'exécutent toujours dans l'espace de noms composer-user-workloads
, même si un autre espace de noms est spécifié.
Les pods de ce namespace peuvent accéder aux ressources Google Cloudde votre projet et à votre réseau VPC (s'il est activé) sans configuration supplémentaire.
Le compte de service de votre environnement est utilisé pour accéder à ces ressources. Il n'est pas possible de spécifier un autre compte de service.
Configuration minimale
Pour créer un KubernetesPodOperator, seuls les paramètres name
, image
à utiliser et task_id
du pod sont obligatoires. /home/airflow/composer_kube_config
contient les identifiants permettant de s'authentifier auprès de GKE.
Configuration supplémentaire
Cet exemple présente des paramètres supplémentaires que vous pouvez configurer dans KubernetesPodOperator.
Pour en savoir plus, consultez les ressources suivantes:
Pour en savoir plus sur l'utilisation des secrets et des ConfigMaps Kubernetes, consultez Utiliser des secrets et des ConfigMaps Kubernetes.
Pour en savoir plus sur l'utilisation des modèles Jinja avec KubernetesPodOperator, consultez la section Utiliser des modèles Jinja.
Pour en savoir plus sur les valeurs acceptées pour les exigences en ressources (processeur, mémoire et stockage), consultez la section Exigences en ressources.
Pour en savoir plus sur les paramètres KubernetesPodOperator, consultez la documentation de référence de l'opérateur dans la documentation Airflow.
Utiliser des modèles Jinja
Airflow est compatible avec les modèles Jinja dans les DAG.
Vous devez déclarer les paramètres Airflow requis (task_id
, name
et image
) avec l'opérateur. Comme le montre l'exemple suivant, vous pouvez modéliser tous les autres paramètres avec Jinja, y compris cmds
, arguments
, env_vars
et config_file
.
Le paramètre env_vars
de l'exemple est défini à partir d'une variable Airflow nommée my_value
. L'exemple de DAG obtient sa valeur à partir de la variable de modèle vars
dans Airflow. Airflow dispose de plus de variables qui permettent d'accéder à différents types d'informations. Par exemple, vous pouvez utiliser la variable de modèle conf
pour accéder aux valeurs des options de configuration d'Airflow. Pour en savoir plus et obtenir la liste des variables disponibles dans Airflow, consultez la documentation de référence sur les modèles dans la documentation Airflow.
Sans modifier le DAG ni créer la variable env_vars
, la tâche ex-kube-templates
de l'exemple échoue, car la variable n'existe pas. Créez cette variable dans l'interface utilisateur d'Airflow ou avec Google Cloud CLI:
Interface utilisateur d'Airflow
Accédez à l'interface utilisateur d'Airflow.
Dans la barre d'outils, sélectionnez Administration > Variables.
Sur la page List Variable (Variable de liste), cliquez sur Add a new record (Ajouter un enregistrement).
Sur la page Add Variable (Ajouter une variable), saisissez les informations suivantes :
- Key (Clé) :
my_value
- Val (Valeur) :
example_value
- Key (Clé) :
Cliquez sur Enregistrer.
gcloud
Saisissez la commande suivante :
gcloud composer environments run ENVIRONMENT \
--location LOCATION \
variables set -- \
my_value example_value
Remplacez :
ENVIRONMENT
par le nom de l'environnement.LOCATION
par la région où se trouve l'environnement.
L'exemple suivant montre comment utiliser des modèles Jinja avec KubernetesPodOperator:
Utiliser les secrets et les ConfigMaps Kubernetes
Un secret Kubernetes est un objet qui contient des données sensibles. Un ConfigMap Kubernetes est un objet qui contient des données non confidentielles sous forme de paires clé-valeur.
Dans Cloud Composer 3, vous pouvez créer des secrets et des ConfigMaps à l'aide de la Google Cloud CLI, de l'API ou de Terraform, puis y accéder depuis KubernetesPodOperator:
- Avec la Google Cloud CLI et l'API, vous devez fournir un fichier de configuration YAML.
- Avec Terraform, vous définissez les secrets et les ConfigMaps en tant que ressources distinctes dans les fichiers de configuration Terraform.
À propos des fichiers de configuration YAML
Lorsque vous créez un secret Kubernetes ou un ConfigMap à l'aide de la Google Cloud CLI et de l'API, vous fournissez un fichier au format YAML. Ce fichier doit respecter le même format que celui utilisé par les secrets et les ConfigMaps Kubernetes. La documentation Kubernetes fournit de nombreux exemples de code de ConfigMaps et de secrets. Pour commencer, consultez les pages Distribuer des identifiants de manière sécurisée à l'aide de secrets et ConfigMaps.
Comme dans les secrets Kubernetes, utilisez la représentation base64 lorsque vous définissez des valeurs dans Secrets.
Pour encoder une valeur, vous pouvez utiliser la commande suivante (il s'agit de l'une des nombreuses façons d'obtenir une valeur encodée en base64):
echo "postgresql+psycopg2://root:example-password@127.0.0.1:3306/example-db" -n | base64
Sortie :
cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==
Les deux exemples de fichiers YAML suivants sont utilisés dans des exemples plus loin dans ce guide. Exemple de fichier de configuration YAML pour un secret Kubernetes:
apiVersion: v1
kind: Secret
metadata:
name: airflow-secrets
data:
sql_alchemy_conn: cG9zdGdyZXNxbCtwc3ljb3BnMjovL3Jvb3Q6ZXhhbXBsZS1wYXNzd29yZEAxMjcuMC4wLjE6MzMwNi9leGFtcGxlLWRiIC1uCg==
Autre exemple montrant comment inclure des fichiers. Comme dans l'exemple précédent, commencez par encoder le contenu d'un fichier (cat ./key.json | base64
), puis fournissez cette valeur dans le fichier YAML:
apiVersion: v1
kind: Secret
metadata:
name: service-account
data:
service-account.json: |
ewogICJ0eXBl...mdzZXJ2aWNlYWNjb3VudC5jb20iCn0K
Exemple de fichier de configuration YAML pour un ConfigMap. Vous n'avez pas besoin d'utiliser la représentation base64 dans les ConfigMaps:
apiVersion: v1
kind: ConfigMap
metadata:
name: example-configmap
data:
example_key: example_value
Gérer les secrets Kubernetes
gcloud
Créer un secret
Pour créer un secret Kubernetes, exécutez la commande suivante:
gcloud beta composer environments user-workloads-secrets create \
--environment ENVIRONMENT_NAME \
--location LOCATION \
--secret-file-path SECRET_FILE
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.SECRET_FILE
: chemin d'accès à un fichier YAML local contenant la configuration du secret.
Exemple :
gcloud beta composer environments user-workloads-secrets create \
--environment example-environment \
--location us-central1 \
--secret-file-path ./secrets/example-secret.yaml
Mettre à jour un secret
Pour mettre à jour un secret Kubernetes, exécutez la commande suivante. Le nom du secret sera extrait du fichier YAML spécifié et son contenu sera remplacé.
gcloud beta composer environments user-workloads-secrets update \
--environment ENVIRONMENT_NAME \
--location LOCATION \
--secret-file-path SECRET_FILE
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.SECRET_FILE
: chemin d'accès à un fichier YAML local contenant la configuration du secret. Spécifiez le nom du secret dans le champname
>metadata
de ce fichier.
List Secrets
Pour obtenir la liste des secrets et de leurs champs pour un environnement, exécutez la commande suivante. Les valeurs de clé dans la sortie seront remplacées par des astérisques.
gcloud beta composer environments user-workloads-secrets list \
--environment ENVIRONMENT_NAME \
--location LOCATION
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
Obtenir les détails du secret
Pour obtenir des informations détaillées sur un secret, exécutez la commande suivante. Les valeurs de clé dans la sortie seront remplacées par des astérisques.
gcloud beta composer environments user-workloads-secrets describe \
SECRET_NAME \
--environment ENVIRONMENT_NAME \
--location LOCATION
Remplacez les éléments suivants :
SECRET_NAME
: nom du secret, tel qu'il a été défini dans le champname
metadata
> du fichier YAML avec la configuration du secret.ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
Supprimer un secret
Pour supprimer un secret, exécutez la commande suivante:
gcloud beta composer environments user-workloads-secrets delete \
SECRET_NAME \
--environment ENVIRONMENT_NAME \
--location LOCATION
SECRET_NAME
: nom du secret, tel qu'il a été défini dans le champname
metadata
> du fichier YAML avec la configuration du secret.ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
API
Créer un secret
Créez une requête API
environments.userWorkloadsSecrets.create
.Dans cette requête :
- Dans le corps de la requête, dans le champ
name
, spécifiez l'URI du nouveau secret. - Dans le corps de la requête, dans le champ
data
, spécifiez les clés et les valeurs encodées en base64 pour le secret.
- Dans le corps de la requête, dans le champ
Exemple :
// POST https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsSecrets
{
"name": "projects/example-project/locations/us-central1/environments/example-environment/userWorkloadsSecrets/example-secret",
"data": {
"example": "ZXhhbXBsZV92YWx1ZSAtbgo="
}
}
Mettre à jour un secret
Créez une requête API
environments.userWorkloadsSecrets.update
.Dans cette requête :
- Dans le corps de la requête, dans le champ
name
, spécifiez l'URI du secret. - Dans le corps de la requête, dans le champ
data
, spécifiez les clés et les valeurs encodées en base64 pour le secret. Les valeurs seront remplacées.
- Dans le corps de la requête, dans le champ
Exemple :
// PUT https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsSecrets/example-secret
{
"name": "projects/example-project/locations/us-central1/environments/example-environment/userWorkloadsSecrets/example-secret",
"data": {
"example": "ZXhhbXBsZV92YWx1ZSAtbgo=",
"another-example": "YW5vdGhlcl9leGFtcGxlX3ZhbHVlIC1uCg=="
}
}
List Secrets
Créez une requête API environments.userWorkloadsSecrets.list
. Les valeurs de clé dans la sortie seront remplacées par des astérisques. Vous pouvez utiliser la pagination avec cette requête. Pour en savoir plus, consultez la référence de la requête.
Exemple :
// GET https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsSecrets
Obtenir les détails du secret
Créez une requête API environments.userWorkloadsSecrets.get
. Les valeurs de clé dans la sortie seront remplacées par des astérisques.
Exemple :
// GET https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsSecrets/example-secret
Supprimer un secret
Créez une requête API environments.userWorkloadsSecrets.delete
.
Exemple :
// DELETE https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsSecrets/example-secret
Terraform
La ressource google_composer_user_workloads_secret
définit un secret Kubernetes, avec des clés et des valeurs définies dans le bloc data
.
resource "google_composer_user_workloads_secret" "example_secret" {
provider = google-beta
environment = google_composer_environment.ENVIRONMENT_RESOURCE_NAME.name
name = "SECRET_NAME"
region = "LOCATION"
data = {
KEY_NAME: "KEY_VALUE"
}
}
ENVIRONMENT_RESOURCE_NAME
: nom de la ressource de l'environnement, qui contient la définition de l'environnement dans Terraform. Le nom de l'environnement réel est également spécifié dans cette ressource.LOCATION
: région où se trouve l'environnement.SECRET_NAME
: nom du secret.KEY_NAME
: une ou plusieurs clés pour ce secret.KEY_VALUE
: valeur de la clé encodée en base64. Vous pouvez utiliser la fonctionbase64encode
pour encoder la valeur (voir l'exemple).
Les deux exemples de secrets Kubernetes suivants sont utilisés dans des exemples plus loin dans ce guide.
resource "google_composer_user_workloads_secret" "example_secret" {
provider = google-beta
name = "airflow-secrets"
environment = google_composer_environment.example_environment.name
region = "us-central1"
data = {
sql_alchemy_conn: base64encode("postgresql+psycopg2://root:example-password@127.0.0.1:3306/example-db")
}
}
Autre exemple montrant comment inclure des fichiers. Vous pouvez utiliser la fonction file
pour lire le contenu du fichier en tant que chaîne, puis l'encoder en base64:
resource "google_composer_user_workloads_secret" "service_account_secret" {
provider = google-beta
name = "service-account"
environment = google_composer_environment.example_environment.name
region = "us-central1"
data = {
"service-account.json": base64encode(file("./key.json"))
}
}
Utiliser des secrets Kubernetes dans vos DAG
Cet exemple présente deux façons d'utiliser les secrets Kubernetes: en tant que variable d'environnement et en tant que volume installé par le pod.
Le premier secret, airflow-secrets
, est défini sur une variable d'environnement Kubernetes nommée SQL_CONN
(par opposition à une variable d'environnement Airflow ou Cloud Composer).
Le second secret, service-account
, installe service-account.json
, un fichier contenant un jeton de compte de service, dans /var/secrets/google
.
Voici à quoi ressemblent les objets Secret:
Le nom du premier secret Kubernetes est défini dans la variable secret_env
.
Ce secret est nommé airflow-secrets
. Le paramètre deploy_type
spécifie qu'il doit être exposé en tant que variable d'environnement. Le nom de la variable d'environnement est SQL_CONN
, comme spécifié dans le paramètre deploy_target
. Enfin, la valeur de la variable d'environnement SQL_CONN
est définie sur la valeur de la clé sql_alchemy_conn
.
Le nom du second secret Kubernetes est défini dans la variable secret_volume
. Ce secret est nommé service-account
. Il est exposé en tant que volume, comme spécifié dans le paramètre deploy_type
. Le chemin d'accès au fichier à installer, deploy_target
, est /var/secrets/google
. Enfin, la clé (key
) du secret stocké dans deploy_target
est service-account.json
.
Voici à quoi ressemble la configuration de l'opérateur :
Gérer les ConfigMaps Kubernetes
gcloud
Créer un ConfigMap
Pour créer un ConfigMap, exécutez la commande suivante:
gcloud beta composer environments user-workloads-config-maps create \
--environment ENVIRONMENT_NAME \
--location LOCATION \
--config-map-file-path CONFIG_MAP_FILE
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.CONFIG_MAP_FILE
: chemin d'accès à un fichier YAML local contenant la configuration du ConfigMap.
Exemple :
gcloud beta composer environments user-workloads-config-maps create \
--environment example-environment \
--location us-central1 \
--config-map-file-path ./configs/example-configmap.yaml
Mettre à jour un ConfigMap
Pour mettre à jour un ConfigMap, exécutez la commande suivante. Le nom des ConfigMaps sera extrait du fichier YAML spécifié et le contenu des ConfigMaps sera remplacé.
gcloud beta composer environments user-workloads-config-maps update \
--environment ENVIRONMENT_NAME \
--location LOCATION \
--config-map-file-path CONFIG_MAP_FILE
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.CONFIG_MAP_FILE
: chemin d'accès à un fichier YAML local contenant la configuration du ConfigMap. Spécifiez le nom du ConfigMap dans le champname
>metadata
de ce fichier.
Lister les ConfigMaps
Pour obtenir la liste des ConfigMaps et de leurs champs pour un environnement, exécutez la commande suivante. Les valeurs de clé de la sortie sont affichées telles quelles.
gcloud beta composer environments user-workloads-config-maps list \
--environment ENVIRONMENT_NAME \
--location LOCATION
Remplacez les éléments suivants :
ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
Obtenir les détails d'un ConfigMap
Pour obtenir des informations détaillées sur un ConfigMap, exécutez la commande suivante. Les valeurs de clé dans la sortie s'affichent telles quelles.
gcloud beta composer environments user-workloads-config-maps describe \
CONFIG_MAP_NAME \
--environment ENVIRONMENT_NAME \
--location LOCATION
Remplacez les éléments suivants :
CONFIG_MAP_NAME
: nom du ConfigMap, tel qu'il a été défini dans le champmetadata
>name
du fichier YAML avec la configuration du ConfigMap.ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
Supprimer un ConfigMap
Pour supprimer un ConfigMap, exécutez la commande suivante:
gcloud beta composer environments user-workloads-config-maps delete \
CONFIG_MAP_NAME \
--environment ENVIRONMENT_NAME \
--location LOCATION
CONFIG_MAP_NAME
: nom du ConfigMap, tel qu'il a été défini dans le champmetadata
>name
du fichier YAML avec la configuration du ConfigMap.ENVIRONMENT_NAME
: nom de votre environnementLOCATION
: région où se trouve l'environnement.
API
Créer un ConfigMap
Créez une requête API
environments.userWorkloadsConfigMaps.create
.Dans cette requête :
- Dans le corps de la requête, dans le champ
name
, spécifiez l'URI du nouveau ConfigMap. - Dans le corps de la requête, dans le champ
data
, spécifiez les clés et les valeurs du ConfigMap.
- Dans le corps de la requête, dans le champ
Exemple :
// POST https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsConfigMaps
{
"name": "projects/example-project/locations/us-central1/environments/example-environment/userWorkloadsConfigMaps/example-configmap",
"data": {
"example_key": "example_value"
}
}
Mettre à jour un ConfigMap
Créez une requête API
environments.userWorkloadsConfigMaps.update
.Dans cette requête :
- Dans le corps de la requête, dans le champ
name
, spécifiez l'URI du ConfigMap. - Dans le corps de la requête, dans le champ
data
, spécifiez les clés et les valeurs du ConfigMap. Les valeurs seront remplacées.
- Dans le corps de la requête, dans le champ
Exemple :
// PUT https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsConfigMaps/example-configmap
{
"name": "projects/example-project/locations/us-central1/environments/example-environment/userWorkloadsConfigMaps/example-configmap",
"data": {
"example_key": "example_value",
"another_key": "another_value"
}
}
Lister les ConfigMaps
Créez une requête API environments.userWorkloadsConfigMaps.list
. Les valeurs de clé de la sortie s'affichent telles quelles. Il est possible d'utiliser la pagination avec cette requête. Pour en savoir plus, consultez la documentation de référence de la requête.
Exemple :
// GET https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsConfigMaps
Obtenir les détails d'un ConfigMap
Créez une requête API environments.userWorkloadsConfigMaps.get
. Les valeurs de clé de la sortie sont affichées telles quelles.
Exemple :
// GET https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsConfigMaps/example-configmap
Supprimer un ConfigMap
Créez une requête API environments.userWorkloadsConfigMaps.delete
.
Exemple :
// DELETE https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment/userWorkloadsConfigMaps/example-configmap
Terraform
La ressource google_composer_user_workloads_config_map
définit un ConfigMap, avec des clés et des valeurs définies dans le bloc data
.
resource "google_composer_user_workloads_config_map" "example_config_map" {
provider = google-beta
environment = google_composer_environment.ENVIRONMENT_RESOURCE_NAME.name
name = "CONFIG_MAP_NAME"
region = "LOCATION"
data = {
KEY_NAME: "KEY_VALUE"
}
}
ENVIRONMENT_RESOURCE_NAME
: nom de la ressource de l'environnement, qui contient la définition de l'environnement dans Terraform. Le nom de l'environnement réel est également spécifié dans cette ressource.LOCATION
: région où se trouve l'environnement.CONFIG_MAP_NAME
: nom du ConfigMap.KEY_NAME
: une ou plusieurs clés pour ce ConfigMap.KEY_VALUE
: valeur de la clé.
Exemple :
resource "google_composer_user_workloads_config_map" "example_config_map" {
provider = google-beta
name = "example-config-map"
environment = google_composer_environment.example_environment.name
region = "us-central1"
data = {
"example_key": "example_value"
}
}
Utiliser des ConfigMaps dans vos DAG
Cet exemple montre comment utiliser des ConfigMaps dans vos DAG.
Dans l'exemple suivant, un ConfigMap est transmis dans le paramètre configmaps
.
Toutes les clés de ce ConfigMap sont disponibles en tant que variables d'environnement:
import datetime
from airflow import models
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator
with models.DAG(
dag_id="composer_kubernetes_pod_configmap",
schedule_interval=None,
start_date=datetime.datetime(2024, 1, 1),
) as dag:
KubernetesPodOperator(
task_id='kpo_configmap_env_vars',
image='busybox:1.28',
cmds=['sh'],
arguments=[
'-c',
'echo "Value: $example_key"',
],
configmaps=["example-configmap"],
config_file="/home/airflow/composer_kube_config",
)
L'exemple suivant montre comment monter un ConfigMap en tant que volume:
import datetime
from airflow import models
from kubernetes.client import models as k8s
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator
volume_mount = k8s.V1VolumeMount(name='confmap-example',
mount_path='/config',
sub_path=None,
read_only=False)
volume = k8s.V1Volume(name='confmap-example',
config_map=k8s.V1ConfigMapVolumeSource(name='example-configmap'))
with models.DAG(
dag_id="composer_kubernetes_pod_configmap",
schedule_interval=None,
start_date=datetime.datetime(2024, 1, 1),
) as dag:
KubernetesPodOperator(
task_id='kpo_configmap_volume_mount',
image='busybox:1.28',
cmds=['sh'],
arguments=[
'-c',
'ls /config'
],
volumes=[volume],
volume_mounts=[volume_mount],
configmaps=["example-configmap"],
config_file="/home/airflow/composer_kube_config",
)
Informations sur le fournisseur Kubernetes CNCF
KubernetesPodOperator est implémenté dans le fournisseur apache-airflow-providers-cncf-kubernetes
.
Pour obtenir des notes de version détaillées sur le fournisseur Kubernetes CNCF, consultez le site Web du fournisseur Kubernetes CNCF.
Ressources nécessaires
Cloud Composer 3 accepte les valeurs suivantes pour les exigences en termes de ressources. Pour obtenir un exemple d'utilisation des exigences de ressources, consultez la section Configuration supplémentaire.
Ressource | Minimum | Maximum | Étape |
---|---|---|---|
Processeur | 0,25 | 32 | Valeurs d'incrément: 0,25, 0,5, 1, 2, 4, 6, 8, 10, etc., 32. Les valeurs demandées sont arrondies à la valeur d'étape compatible la plus proche (par exemple, 5 à 6). |
Mémoire | 2 Go (Go) | 128 Go | Valeurs d'incrément: 2, 3, 4, 5, etc., 128. Les valeurs demandées sont arrondies à la valeur d'étape compatible la plus proche (par exemple, 3,5 G à 4 G). |
Stockage | - | 100 Go (Go) | N'importe quelle valeur. Si vous demandez plus de 100 Go, seuls 100 Go vous sont fournis. |
Pour en savoir plus sur les unités de ressources dans Kubernetes, consultez la section Unités de ressources dans Kubernetes.
Dépannage
Cette section fournit des conseils pour résoudre les problèmes courants liés à KubernetesPodOperator:
Afficher les journaux
Pour résoudre les problèmes, vous pouvez consulter les journaux dans l'ordre suivant:
Journaux de tâches Airflow:
Dans la console Google Cloud, accédez à la page Environnements.
Dans la liste des environnements, cliquez sur le nom de votre environnement. La page Détails de l'environnement s'ouvre.
Accédez à l'onglet DAG.
Cliquez sur le nom du DAG, puis sur l'exécution du DAG pour afficher les détails et les journaux.
Journaux du programmeur Airflow:
Accédez à la page Détails de l'environnement.
Accédez à l'onglet Journaux.
Inspectez les journaux du planificateur Airflow.
Journaux des charges de travail de l'utilisateur:
Accédez à la page Détails de l'environnement.
Accédez à l'onglet Surveillance.
Sélectionnez Charges de travail utilisateur.
Examinez la liste des charges de travail exécutées. Vous pouvez afficher les journaux et les informations sur l'utilisation des ressources pour chaque charge de travail.
Codes de retour non nuls
Lorsque vous utilisez KubernetesPodOperator (et GKEStartPodOperator), le code de retour du point d'entrée du conteneur détermine si la tâche est considérée comme réussie ou non. Les codes de retour non nuls indiquent un échec.
Un schéma courant consiste à exécuter un script shell comme point d'entrée du conteneur pour regrouper plusieurs opérations dans le conteneur.
Si vous écrivez un script de ce type, nous vous recommandons d'inclure la commande set -e
en haut du script afin que les commandes ayant échoué dans le script arrêtent le script et propagent l'échec à l'instance de tâche Airflow.
Délais d'inactivité des pods
Le délai d'inactivité par défaut de KubernetesPodOperator est de 120 secondes, ce qui signifie que ce délai peut être dépassé avant que des images volumineuses ne puissent être téléchargées. Vous pouvez augmenter le délai d'inactivité en modifiant le paramètre startup_timeout_seconds
lorsque vous créez KubernetesPodOperator.
Lorsqu'un pod expire, le journal spécifique à la tâche est disponible dans l'interface utilisateur d'Airflow. Exemple :
Executing <Task(KubernetesPodOperator): ex-all-configs> on 2018-07-23 19:06:58.133811
Running: ['bash', '-c', u'airflow run kubernetes-pod-example ex-all-configs 2018-07-23T19:06:58.133811 --job_id 726 --raw -sd DAGS_FOLDER/kubernetes_pod_operator_sample.py']
Event: pod-name-9a8e9d06 had an event of type Pending
...
...
Event: pod-name-9a8e9d06 had an event of type Pending
Traceback (most recent call last):
File "/usr/local/bin/airflow", line 27, in <module>
args.func(args)
File "/usr/local/lib/python2.7/site-packages/airflow/bin/cli.py", line 392, in run
pool=args.pool,
File "/usr/local/lib/python2.7/site-packages/airflow/utils/db.py", line 50, in wrapper
result = func(*args, **kwargs)
File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1492, in _run_raw_task
result = task_copy.execute(context=context)
File "/usr/local/lib/python2.7/site-packages/airflow/contrib/operators/kubernetes_pod_operator.py", line 123, in execute
raise AirflowException('Pod Launching failed: {error}'.format(error=ex))
airflow.exceptions.AirflowException: Pod Launching failed: Pod took too long to start
Un dépassement du délai d'inactivité d'un pod peut également se produire lorsque le compte de service Cloud Composer ne dispose pas des autorisations IAM nécessaires pour effectuer la tâche en question. Pour vérifier cela, examinez les erreurs au niveau du pod à l'aide des tableaux de bord GKE, afin de consulter les journaux de votre charge de travail en question, ou utilisez Cloud Logging.
Les tâches KubernetesPodOperator échouent lorsqu'un grand nombre de tâches sont exécutées
Lorsque votre environnement exécute un grand nombre de tâches KubernetesPodOperator ou KubernetesExecutor en même temps, Cloud Composer 3 n'accepte pas de nouvelles tâches tant que certaines des tâches existantes ne sont pas terminées.
Pour en savoir plus sur le dépannage de ce problème, consultez la section Résoudre les problèmes liés aux tâches KubernetesExecutor.