Exécuter Flower sur GCP¶

Guide étape par étape pour apprendre à créer, déployer et exécuter une application Flower sur le Google Cloud Platform (GCP) en utilisant le Google Kubernetes Engine (GKE). La figure ci-dessous présente un aperçu de l’architecture des composants Flower que nous allons déployer sur GCP en utilisant GKE. Dans cette architecture, les ServerApps et les ClientApps sont exécutés par le SuperExec Flower (flower-superexec).

Exécution de Flower sur GCP à l'aide d'GKE Architecture — Exécution de Flower sur GCP à l’aide d’GKE Architecture.¶

Une partie de ce guide a également été présentée lors du Flower AI Summit 2025, par Prashant Kulkarni, Ingénieur en sécurité GenAI chez Google Cloud.

Créer un cluster Kubernetes¶

Voici les étapes pour créer un cluster Kubernetes dans GCP à l’aide de l’interface utilisateur de GCP. Avant de poursuivre, veuillez vous assurer d’avoir un compte sur GCP.

Créez un projet GCP : Une fois que vous avez créé le compte, créez un nouveau projet en sélectionnant le bouton de sélection du projet, c’est-à-dire le bouton avec le nom du projet apparaissant en haut de la page. Cela ouvrira une nouvelle fenêtre à partir de laquelle vous pouvez cliquer sur le bouton NEW PROJECT et créer le nouveau projet et affecter un nom, par exemple flower-gcp. Avant de passer à l’étape suivante, assurez-vous que le projet flower-gcp est sélectionné dans le coin supérieur gauche.
Activer l’API Kubernetes : Après avoir créé le projet GCP, dans la barre de recherche en haut de la page GCP tapez Kubernetes Engine API et cliquez dessus (il a un icône API). Cela vous redirigera vers la page Produit Kubernetes Engine API. De là, vous devez sélectionner Enable; si vous voyez une fenêtre de dialogue Billing required, veuillez consulter votre administrateur pour continuer, le cas échéant. Une fois que vous avez activé cela, vous devriez voir un signe vert dans la Kubernetes Engine API disant API Enabled.
Create Kubernetes Cluster : sur la page d’accueil du projet GCP, dans la section Products, recherchez l’onglet Create a Kubernetes Cluster. Vous serez redirigé vers une page présentant une vue d’ensemble des clusters Kubernetes existants. En haut de la page, vous devriez voir un bouton Create cluster. Par défaut, les clusters Kubernetes sont déployés en mode Autopilot. Dans ce guide, nous utilisons le mode Autopilot.
Configurez le cluster Kubernetes : dans la page qui s’affiche, nous affectons un nom au nouveau cluster, par exemple quickstart-numpy, et nous sélectionnons la région, par exemple us-central1. Pour les autres paramètres de configuration, tels que Cluster Tier, Fleet Registration, Networking, et d’autres paramètres, nous utilisons les valeurs par défaut. Cliquez maintenant sur le bouton Create.

Note

Veuillez patienter quelques minutes jusqu’à ce que le cluster soit prêt et complètement déployé.

Configurer Google Cloud SDK¶

Pour interagir avec notre cluster Kubernetes récemment déployé, nous utiliserons l’outil de ligne de commande Google Cloud SDK et le configurerons localement. Cet outil nous permet d’interagir directement avec GCP et en retour avec notre cluster Kubernetes récemment déployé.

Pour installer le SDK Google Cloud, il faut tout d’abord installer et configurer le gcloud CLI:

# macOS
curl https://sdk.cloud.google.com | bash  # and then follow on-screen prompts

# macOS (w/ Homebrew)
brew install --cask google-cloud-sdk

# Windows
# Download the Windows installer from the Google Cloud SDK page
# https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe
# Run the .exe installer and follow the on-screen instructions

# Once the package is installed (e.g., using brew), we initialize gcloud as follows:
gcloud init  # initialize with gcloud init.
gcloud version  # verify installation

Note

Pour plus d’informations sur l’installation détaillée et pour installer gcloud sur différents systèmes d’exploitation, veuillez consulter la page d’installation officielle gcloud CLI https://cloud.google.com/sdk/docs/install

Une fois gcloud installé, nous devons installer kubectl, qui est un outil en ligne de commande pour interagir avec les clusters Kubernetes:

gcloud components install kubectl
kubectl version --client  # this will show the installed versions of the Client and Kustomize

Avant de poursuivre les étapes suivantes, veuillez vous assurer d’avoir sélectionné un compte actif, sinon vous recevrez une erreur ERROR: (gcloud.container.clusters.get-credentials) lors de l’exécution des commandes ci-dessous. Pour obtenir de nouvelles informations d’identification ou sélectionner un compte déjà authentifié, veuillez exécuter les commandes suivantes

gcloud auth login  # to obtain new credentials
gcloud config set account <ACCOUNT>  # to select an already authenticated <ACCOUNT> that you want to use

Maintenant, vous devez définir la propriété project dans votre espace de travail actuel en utilisant l’identifiant de projet unique, qui peut être trouvé sous la colonne ID lors du clic sur le sélecteur de projet.

# glocud config set project
gcloud config set project <YOUR_PROJECT_ID>  # <YOUR_PROJECT_ID> is not the project name but the project identifier, e.g., flower-gcp-XXXXXX

Note

La valeur de <YOUR_PROJECT_ID> sera différente pour chaque utilisateur, par exemple flower-gcp, flower-gcp-XXXXXX. Sa valeur sera utilisée dans les étapes suivantes, par exemple

L’étape suivante consiste à configurer kubectl pour qu’il pointe vers le cluster GKE que vous avez créé dans les étapes précédentes en utilisant le nom du cluster, par exemple quickstart-numpy, et le nom de la région où le cluster a été créé:

gcloud container clusters get-credentials quickstart-numpy --region us-central1

Cela configurera les métadonnées requises et récupérera les informations nécessaires pour permettre à votre local kubectl de communiquer avec le cluster GKE. Pour vérifier que kubectl a pu se connecter au cluster et obtenir les informations nécessaires, vous pouvez exécuter la commande suivante:

kubectl config current-context  # this should return the Kubernetes cluster you are connected to

Note

Pour en savoir plus sur la façon dont kubectl fonctionne, veuillez jeter un coup d’œil sur le document suivant : official quick-reference guide.

Créer un registre Artifact Google¶

Le registre Artifact Google est un service géré, scalable et privé pour stocker et gérer les artefacts de construction logiciels et leurs dépendances. Par conséquent, pour exécuter notre application Flower sur le cluster GKE, nous devons stocker l’image Docker spécifique à l’application dans le registre, c’est-à-dire le SuperExec Flower, que nous discuterons dans la section suivante. Pour les cas d’utilisation typiques, les images Docker SuperLink et SuperNode de Flower ne nécessitent pas d’être construites et peuvent être récupérées directement à partir du référentiel officiel Flower DockerHub repository. Cette étape est cruciale car elle permet au cluster et en conséquence à la Pods de télécharger les images Docker construites et déployer les composants Flower nécessaires. Veuillez consulter ci-dessous les instructions pour créer le registre à l’aide du CLI gcloud :

# Enable the Artifact Registry API service
gcloud services enable artifactregistry.googleapis.com

# Create the repository
# gcloud artifacts repositories create <YOUR_REPOSITORY_NAME>
gcloud artifacts repositories create flower-gcp-example-artifacts \
    --repository-format=docker \
    --location=us-central1

# Configure Docker to Authenticate with Artifact Registry, e.g.:
#   gcloud auth configure-docker <YOUR_REGION>-docker.pkg.dev
gcloud auth configure-docker us-central1-docker.pkg.dev  # we use us-central1 as our region

Validation & Permissions du Registre¶

Les étapes suivantes valident que le registre Artifact Google a été correctement configuré, que vous avez accès correct et que vous avez des permissions d’écriture pour pousser les images Docker discutées dans la section suivante.

gcloud artifacts repositories list --location=us-central1  # this will list the items under the project with ID <YOUR_PROJECT_ID>

La commande ci-dessus montre que le référentiel flower-gcp-example-artifacts a été créé avec succès sous le projet spécifié avec l’ID <YOUR_PROJECT_ID>. Finalement, vous devez mettre à jour votre rôle et attribuer des permissions d’écriture au registre d’artefacts. Pour accomplir cela, veuillez exécuter la commande suivante:

gcloud projects add-iam-policy-binding <YOUR_PROJECT_ID> \  # <YOUR_PROJECT_ID> is the ID of the project
    --member="user:<YOUR_EMAIL@DOMAIN.COM>" \
    --role="roles/artifactregistry.writer"

Configurer les Images Docker de l’Application Flower¶

Pour poursuivre avec l’étape suivante, nous créons d’abord une application Flower locale puis définissons un fichier Docker spécifique à l’image qui exécutera SuperExec. Dans SuperExec, soit ServerApp ou ClientApp sera exécuté. Après avoir construit l’image, nous la taggeons et la poussons dans le registre Google récemment créé. La plupart des étapes sur la façon de construire les images Docker discutées ci-dessous sont basées sur le Flower Quickstart with Docker Tutorial.

Nous créons l’application Flower NumPy comme suit :

# flwr new <APP_ID>[==<APP_VERSION>]
flwr new @flwrlabs/quickstart-numpy

Créer des images Docker¶

Avec flower-superexec, vous n’avez pas besoin de faire cuire votre code d’applications dans l’image. SuperExec reçoit et installe le Bundle d’application (FAB) Flower à l’exécution à l’intérieur du conteneur, gardant vos images légères.

Note

SuperExec ne NE installe pas les dépendances en temps réel. Si votre application nécessite des dépendances supplémentaires, assurez-vous qu’elles sont incluses dans votre image Docker, tel que montré dans l’exemple de fichier Docker ci-dessous :

Une fois que nous avons créé le fichier Docker requis, nous construisons l’image Docker comme suit :

Important

Avant d’exécuter les commandes ci-dessous, assurez-vous que Docker est installé et qu’il fonctionne. Le type de --platform est défini sur linux/amd64, car lorsqu’on utilise le mode Autopilot, tous les Pods du cluster Kubernetes (par défaut) sont déployés avec une architecture basée sur amd64.

docker build --platform linux/amd64 -f superexec.Dockerfile -t quickstart_numpy_superexec:0.0.1 .

Taguer les images Docker¶

Avant que nous puissions pousser nos deux images locales créées récemment, nous avons besoin de les étiqueter avec le nom du référentiel Google Artifact Registry et le nom de l’image que nous avons créé pendant les étapes précédentes. Si vous avez suivi les suggestions de nommage antérieures, le nom du référentiel est flower-gcp-example-artifacts, le nom local de l’image Docker est quickstart_numpy_superexec:0.0.1, et la région est us-central1. Notez que <YOUR_PROJECT_ID> est différent d’utilisateur en utilisateur, donc dans les commandes ci-dessous, nous utilisons le placeholder <YOUR_PROJECT_ID>. En mettant tout cela ensemble, la commande finale que vous devez exécuter pour étiqueter l’image SuperExec Docker est :

# docker tag YOUR_IMAGE_NAME YOUR_REGION-docker.pkg.dev/YOUR_PROJECT_ID/YOUR_REPOSITORY_NAME/YOUR_IMAGE_NAME:YOUR_TAG

# please change <YOUR_PROJECT_ID> to point to your project identifier
docker tag quickstart_numpy_superexec:0.0.1 us-central1-docker.pkg.dev/<YOUR_PROJECT_ID>/flower-gcp-example-artifacts/quickstart_numpy_superexec:0.0.1

Envoyer les images Docker¶

Une fois que notre image est correctement étiquetée, vous pouvez la pousser vers votre Artifact Registry répertoire en utilisant le command docker push avec le nom étiqueté :

# docker push YOUR_REGION-docker.pkg.dev/<YOUR_PROJECT_ID>/YOUR_REPOSITORY_NAME/YOUR_IMAGE_NAME:YOUR_TAG

# please change <YOUR_PROJECT_ID> to point to your project identifier
docker push us-central1-docker.pkg.dev/<YOUR_PROJECT_ID>/flower-gcp-example-artifacts/quickstart_numpy_superexec:0.0.1

Déployer l’infrastructure Flower¶

Avant de lancer notre Flower application, nous avons besoin de déployer notre Pods sur le cluster Kubernetes.

Dans ce pas, nous allons déployer six Pods: 1x SuperLink, 2x SuperNode, 2x SuperExec(ClientApp), et 1x SuperExec(ServerApp). Pour y parvenir, voici la définition des six fichiers yaml qui sont nécessaires pour déployer le Pods sur le cluster et qui sont transmises à kubectl, ainsi qu’un script d’aide k8s-deploy.sh qui déployera le Pods.

Une fois que vous avez créé les fichiers requis, vous pouvez utiliser l” aide script suivant k8s-deploy.sh pour déployer tous les Pods.

Important

Assurez-vous que la version Flower que vous utilisez pour déployer le Pods correspond à la version de votre application Flower.

Pour voir que vos Pods sont déployés, veuillez aller sur le Navigation Menu dans l’interface Google, sélectionnez Kubernetes Engine et puis la page Workloads. La nouvelle fenêtre qui apparaît montrera l’état des Pods en cours de déploiement.

Prudence

Veuillez patienter pendant quelques minutes (3 à 5 minutes devraient suffire) avant que les Pods soient en cours d’exécution. Pendant la mise en place des ressources Pods, certaines avertissements sont attendus.

Exécutez l’application Flower¶

Une fois que tous les Pods sont en cours d’exécution, nous avons besoin de récupérer le EXTERNAL_IP du superlink-service et pointer notre application Flower pour utiliser le cluster Kubernetes pour soumettre et exécuter la tâche.

Pour récupérer le EXTERNAL-IP du NAME, nous lançons la commande suivante, qui montrera les TYPE, CLUSTER-IP, EXTERNAL-IP, PORTS et __PH7__ de la service :

kubectl get service superlink-service

Après avoir récupéré le EXTERNAL-IP, nous avons besoin de créer un nouveau lien de connexion dans le fichier de configuration SuperLink :

Exécutez flwr config list pour localiser le fichier de configuration Flower sur votre machine et afficher les connexions SuperLink disponibles.

  $ flwr config list

  Flower Config file: /path/to/.flwr/config.toml
  SuperLink connections:
    supergrid
    local (default)

Ouvrez le fichier de configuration Flower (config.toml) et ajoutez une nouvelle connexion SuperLink à la fin:

config.toml¶

[superlink.gcp-deployment]
address = "<EXTERNAL_IP>:9093" # replace the EXTERNAL_IP with the correct value
insecure = true

Nous pouvons ensuite exécuter l’exemple sur le cluster GCP en exécutant :

flwr run . gcp-deployment --stream

Note

Notez que dans la mise en production actuelle, la communication n’est pas chiffrée. Pour activer TLS pour les connexions sécurisées, consultez les instructions guide. Nous mettrons également à jour ce guide bientôt avec plus de détails sur la configuration de TLS.

Si le job est soumis et exécuté avec succès, alors dans votre console, vous devriez voir les logs de l’exécution. Le résultat devrait ressembler à celui partagé ci-dessous :

Sortie attendue

Loading project configuration...
Success
🎊 Successfully built flower.quickstart-numpy.1-0-0.ba270a25.fab
🎊 Successfully started run 2796207907461390277
INFO :      Starting logstream for run_id `2796207907461390277`
INFO :      Start `flwr-serverapp` process
🎊 Successfully installed quickstart-numpy to /app/.flwr/apps/flower.quickstart-numpy.1.0.0.ba270a25.
INFO :      Starting FedAvg strategy:
INFO :          ├── Number of rounds: 3
INFO :          ├── ArrayRecord (0.00 MB)
INFO :          ├── ConfigRecord (train): (empty!)
INFO :          ├── ConfigRecord (evaluate): (empty!)
INFO :          ├──> Sampling:
INFO :          │       ├──Fraction: train (1.00) | evaluate ( 1.00)
INFO :          │       ├──Minimum nodes: train (2) | evaluate (2)
INFO :          │       └──Minimum available nodes: 2
INFO :          └──> Keys in records:
INFO :                  ├── Weighted by: 'num-examples'
INFO :                  ├── ArrayRecord key: 'arrays'
INFO :                  └── ConfigRecord key: 'config'
INFO :
INFO :
INFO :      [ROUND 1/3]
INFO :      configure_train: Sampled 2 nodes (out of 2)
INFO :      aggregate_train: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': 0.6692931409515264}
INFO :      configure_evaluate: Sampled 2 nodes (out of 2)
INFO :      aggregate_evaluate: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': [0.4880010858339962, 0.3087008997447846, 0.6336219116058434]}
INFO :
INFO :      [ROUND 2/3]
INFO :      configure_train: Sampled 2 nodes (out of 2)
INFO :      aggregate_train: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': 0.5360441357065859}
INFO :      configure_evaluate: Sampled 2 nodes (out of 2)
INFO :      aggregate_evaluate: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': [0.25413977771677904, 0.33788546118090673, 0.64626655554784]}
INFO :
INFO :      [ROUND 3/3]
INFO :      configure_train: Sampled 2 nodes (out of 2)
INFO :      aggregate_train: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': 0.04090013167984635}
INFO :      configure_evaluate: Sampled 2 nodes (out of 2)
INFO :      aggregate_evaluate: Received 2 results and 0 failures
INFO :          └──> Aggregated MetricRecord: {'random_metric': [0.7990976665955934, 0.20095453623327086, 0.6090265112641057]}
INFO :
INFO :      Strategy execution finished in 14.66s
INFO :
INFO :      Final results:
INFO :
INFO :          Global Arrays:
INFO :                  ArrayRecord (0.000 MB)
INFO :
INFO :          Aggregated ClientApp-side Train Metrics:
INFO :          { 1: {'random_metric': '6.6929e-01'},
INFO :            2: {'random_metric': '5.3604e-01'},
INFO :            3: {'random_metric': '4.0900e-02'}}
INFO :
INFO :          Aggregated ClientApp-side Evaluate Metrics:
INFO :          { 1: {'random_metric': "['4.8800e-01', '3.0870e-01', '6.3362e-01']"},
INFO :            2: {'random_metric': "['2.5414e-01', '3.3789e-01', '6.4627e-01']"},
INFO :            3: {'random_metric': "['7.9910e-01', '2.0095e-01', '6.0903e-01']"}}
INFO :
INFO :          ServerApp-side Evaluate Metrics:
INFO :          {}
INFO :

Note

Veuillez noter que si vous terminez ou arrêtez le cluster, et créez un nouveau, la valeur du EXTERNAL_IP change. Dans ce cas, vous devrez mettre à jour le fichier de configuration Flower.

Arrêter l’infrastructure Flower¶

Si vous souhaitez fermer tous les pods en cours d’exécution déployés pendant ce guide, vous pouvez utiliser la commande kubectl delete et passer le fichier .yaml de chaque pod, comme également montré dans l’aide script ci-dessous.