Déployer SuperNode à l’aide de Helm¶
Note
Flower Helm charts are a Flower Enterprise feature. See Flower Enterprise for details.
Le cadre de référence Flower offre une approche unifiée pour l’apprentissage fédéré, les analyses et l’évaluation, vous permettant de faire participer tout type de charge de travail, framework d’apprentissage automatique ou langage de programmation.
Ce chart Helm installe les composants côté-client du Framework Flower, en spécifiant notamment la mise en place de SuperNode.
La configuration d’installation par défaut vise à reproduire la fonctionnalité et la mise en place des sorties officielles du cadre de référence Flower.
Configuration multi-projet¶
Pour installer plusieurs types de SuperNodes, tels qu’un fédération pour exécuter PyTorch et un autre pour TensorFlow, vous devez installer le chart Helm plusieurs fois avec des noms différents. Cela permet à chaque déploiement d’avoir ses propres configurations et dépendances.
Par exemple, vous pouvez installer le chart pour la configuration de PyTorch en ajustant le fichier values.yaml comme suit :
supernode:
superlink:
address: my-superlink.example.com
port: 9092
node:
config:
partition-id: 0
num-partitions: 2
image:
registry: myregistry.example.com
repository: flwr/supernode
tag: 1.20.0-pytorch
Installez cette configuration à l’aide du command suivant :
$ helm install pytorch . --values values.yaml
Cela déployera 10 SuperNodes nommés pytorch-flower-client-supernode-<random>.
Pour une configuration TensorFlow, modifiez le fichier values.yaml comme suit :
supernode:
replicas: 3
superlink:
address: my-other-superlink.example.com
port: 9092
node:
config:
partition-id: 1
num-partitions: 2
image:
registry: myregistry.example.com
repository: flwr/supernode
tag: 1.20.0-tensorflow
Installez cette configuration à l’aide du command suivant :
$ helm install tensorflow . --values values.yaml
Cela déployera 3 SuperNodes nommés tensorflow-flower-client-supernode-<random>.
Déployez le Framework Flower avec TLS¶
Par défaut, le Framework Flower est déployé avec TLS activé. Cela signifie que tls.enabled est défini sur true.
Lorsque vous utilisez des CAs privés, SuperNode doit faire confiance au certificat CA pour se connecter de manière sécurisée à SuperLink.
Pour fournir le certificat CA, définissez tls.enabled sur true et créez un Secret du type kubernetes.io/tls nommé flower-client-tls :
tls:
enabled: true
Si vous souhaitez utiliser un autre nom de Secret, remplacez la valeur par défaut en définissant supernode.superlink.certificate.existingSecret :
tls:
enabled: true
supernode:
superlink:
certificate:
existingSecret: my-custom-tls-secret-name
Important:
La pratique recommandée est de monter différents Secrets pour SuperLink et les SuperNodes existingSecret paramètre. En gardant ces Secrets séparés, vous assurez que si le Secret contenant la clé privée et le certificat du serveur est jamais compromis, le client échouera à se connecter plutôt que de faire confiance à un serveur compromis.
Pour plus d’informations, consultez la documentation cert-manager.
Si le certificat SuperLink (du type kubernetes.io/tls) est déployé dans le même cluster et namespace que SuperNode, vous pouvez activer supernode.superlink.certificate.copyFromExistingSecret. Cela instruit le chart à créer un nouveau Secret contenant le certificat CA. Il copie ca.crt du Secret SuperLink ou tombe en arrière sur tls.crt si ca.crt n’est pas présent.
Par défaut, le Secret copié est nommé flower-client-tls. Vous pouvez personnaliser ce nom avec supernode.superlink.certificate.copyFromExistingSecret.secretName :
tls:
enabled: true
supernode:
superlink:
certificate:
existingSecret: superlink-tls-secret-name
copyFromExistingSecret:
enabled: true
secretName: my-custom-tls-secret-name
Déployer le Framework Flower sans TLS¶
Vous pourriez vouloir déployer le Framework Flower sans TLS pour des tests ou une utilisation interne. Soyez prudent car cela expose votre déploiement à des risques de sécurité potentiels.
tls:
enabled: false
Authentification du nœud¶
Pour activer l’authentification du nœud, vous devez spécifier une clé privée au format PKCS8 ou OpenSSH (PEM-like). Cet exemple suppose que SuperLink est également configuré pour l’authentification du nœud et reconnaît la clé publique ecdsa-sha2-nistp384 [...] de ce SuperNode.
global:
nodeAuth:
enabled: true
authSupernodePrivateKey: |+
-----BEGIN OPENSSH PRIVATE KEY-----
[...]
-----END OPENSSH PRIVATE KEY-----
authSupernodePublicKey: ecdsa-sha2-nistp384 [...]
tls:
enabled: true
supernode:
enabled: true
superlink:
address: my-superlink.example.com
port: 9092
superexec:
enabled: true
supernode:
address: my-supernode.example.com
port: 9094
Configuration isolée¶
Isolation Tous-en-Un¶
Pour installer SuperNode en mode d’isolement à l’aide de la configuration « process », il faut activer à la fois SuperExec et SuperNode. Par défaut, SuperExec se connecte à SuperNode internement au sein du cluster, donc il n’est pas nécessaire de définir supernode.address et supernode.port sauf si la connexion est externe. Cette configuration suppose que les deux composants sont exécutés dans le même cluster.
supernode:
enabled: true
isolationMode: process
superexec:
enabled: true
Isolation Distribuée¶
Vous pouvez également déployer SuperNode et SuperExec séparément. Pour cela, il faut déployer le chart deux fois : une fois avec supernode.enabled=true et une fois avec superexec.enabled=true.
supernode:
enabled: true
superexec:
enabled: true
supernode:
address: my-supernode.example.com
port: 9094
Configuration du nœud¶
Vous pouvez ajouter une configuration de nœud pour configurer un SuperNode. Le datatype YAML est conservé lorsqu’il est passé dans l’application Python :
supernode:
node:
config:
bool: false
int: 1
negative_int: -1
float: 21.23
negative_float: -1.34
string: value 1
int-as-string: "1"
Parameters¶
Paramètres Helm¶
Name |
Description |
Value |
|---|---|---|
|
Remplace le nom du chart dans le Chart.yaml |
|
|
Remplace complètement le nom généré. |
|
Paramètres globaux¶
Name |
Description |
Value |
|---|---|---|
|
Annotations par défaut |
|
|
Étiquettes par défaut |
|
|
PodLabels par défaut |
|
|
Sélecteur de nœud par défaut pour tous les composants |
|
|
Tolérations par défaut pour tous les composants |
|
|
Présentation d’affinité par défaut pour tous les composants |
|
|
Règles d’anti-affinité du pod par défaut. Soit : |
|
|
Règles d’affinité de nœud par défaut. Soit : |
|
|
Expressions de match pour l’affinité de nœud par défaut |
|
|
Activer ou désactiver la liaison SuperLink <-> SuperNode |
|
|
Spécifie la clé privée ecdsa-sha2-nistp384 |
|
|
Définir le contexte de sécurité runAsUser |
|
|
Définir le contexte de sécurité runAsGroup |
|
|
Définir le contexte de sécurité fsGroup |
|
|
Définir le contexte de sécurité runAsNonRoot |
|
|
Définir le contexte de sécurité readOnlyRootFilesystem |
|
|
Définir le contexte de sécurité allowPrivilegeEscalation |
|
|
Définir le contexte de sécurité seccompProfile |
|
|
Définir le contexte de sécurité capabilities |
|
|
Variables d’environnement par défaut |
|
|
Politique de tirage d’image par défaut |
|
Configuration TLS¶
Name |
Description |
Value |
|---|---|---|
|
Activer la configuration TLS pour le Framework Flower. |
|
Composant SuperNode¶
Name |
Description |
Value |
|---|---|---|
|
Nom du SuperNode |
|
|
Activer ou désactiver SuperNode |
|
|
Définir les demandes et les limites des conteneurs pour différentes ressources comme la CPU ou la mémoire (essentiel pour les charges de travail de production) |
|
|
|
|
|
Mode d’isolement du SuperNode |
|
|
Définir les demandes et les limites des conteneurs pour différentes ressources comme la CPU ou la mémoire (essentiel pour les charges de travail de production) |
|
|
Adresse de SuperLink que les SuperNodes doivent se connecter à |
|
|
Port de SuperLink que les SuperNodes doivent se connecter à |
|
|
|
|
|
|
|
|
|
|
|
Spécifiez une liste de volumes pour le pod(s) SuperNode |
|
|
Permet de spécifier des VolumeMounts supplémentaires |
|
|
Automount SA-TOKEN dans le pod. |
|
|
Activer un compte de service pour ce composant |
|
|
Annotations appliquées au compte de service activé |
|
|
Étiquettes appliquées au compte de service activé |
|
|
Automount SA-TOKEN |
|
|
Sont valides ClusterIP, NodePort ou Loadbalancer |
|
|
Préfixe du port API ClientAppIo de SuperNode |
|
|
Port à exposer pour l’API ClientAppIo de SuperNode |
|
|
Port du nœud pour l’API ClientAppIo de SuperNode |
|
|
Port du conteneur pour l’API ClientAppIo de SuperNode |
|
|
Port du conteneur pour l’API Health de SuperNode |
|
|
|
|
|
Nombre de pods SuperNode à exécuter |
|
|
Étiquettes supplémentaires pour les pods SuperNode |
|
|
Ajoutez des arguments supplémentaires aux arguments par défaut pour le SuperNode |
|
|
Chemin vers un fichier contenant le secret partagé SuperExec. |
|
|
Étiquettes de nœud pour les pods SuperNode qui se mélangent avec global.nodeSelector |
|
|
Tolérations de nœud pour les pods SuperNode qui se mélangent avec global.tolerations |
|
|
Type de stratégie de déploiement SuperNode |
|
|
Paramètres de configuration d’actualisation roulante du déploiement SuperNode |
|
|
Affinité des nœuds pour les pods SuperNode qui se mélangent avec global.affinity |
|
|
Tableau avec des variables d’environnement supplémentaires à ajouter aux nœuds SuperNode qui se mélangent avec global.env |
|
|
Activer livenessProbe sur les conteneurs SuperNode |
|
|
Délai initial en secondes pour livenessProbe |
|
|
Période en secondes pour livenessProbe |
|
|
Temps d’attente en secondes pour livenessProbe |
|
|
Seuil de défaillance pour livenessProbe |
|
|
Seuil de réussite pour livenessProbe |
|
|
Activer readinessProbe sur les conteneurs SuperNode |
|
|
Délai initial en secondes pour readinessProbe |
|
|
Période en secondes pour readinessProbe |
|
|
Temps d’attente en secondes pour readinessProbe |
|
|
Seuil de défaillance pour readinessProbe |
|
|
Seuil de réussite pour readinessProbe |
|
|
Conteneur(s) SuperNode pour automatiser la configuration avant ou après le démarrage |
|
|
Annotations personnalisées supplémentaires pour SuperNode |
|
|
Étiquettes de sélection supplémentaires pour les pods SuperNode |
|
|
Annotations pour les pods SuperNode |
|
|
Étiquettes de pod supplémentaires pour les pods SuperNode |
|
|
Secrets d’image pull SuperNode qui dépassent global.imagePullSecrets |
|
|
Registre d’image SuperNode |
|
|
Répertoire d’image SuperNode |
|
|
Tag d’image SuperNode |
|
|
Digest d’image SuperNode |
|
|
Politique de tirage d’image des composants |
|
|
Spécifiez si une NetworkPolicy doit être créée |
|
|
Autoriser le trafic d’ingress externe |
|
|
Autoriser un trafic egress non restreint |
|
|
Ajouter des règles d’ingress supplémentaires à la NetworkPolicy |
|
|
Ajouter des règles d’ingress supplémentaires à la NetworkPolicy (ignorées si allowExternalEgress=true) |
|
|
Étiquettes à matcher pour autoriser le trafic de autres pods. Ignoré si |
|
|
Étiquettes à matcher pour autoriser le trafic de autres namespaces. Ignoré si |
|
|
Étiquettes de pod à matcher pour autoriser le trafic de autres namespaces. Ignoré si |
|
Composant SuperExec¶
Name |
Description |
Value |
|---|---|---|
|
Nom du SuperExec |
|
|
Activer ou désactiver le composant SuperExec |
|
|
Type de plugin à utiliser. |
|
|
Définir les demandes et les limites des conteneurs pour différentes ressources comme la CPU ou la mémoire (essentiel pour les charges de travail de production) |
|
|
Adresse du supernode auquel SuperExec doit se connecter |
|
|
Chemin vers un fichier contenant le secret partagé SuperExec. |
|
|
Spécifiez une liste de volumes pour les pods SuperExec(s) |
|
|
Permet de spécifier des VolumeMounts supplémentaires |
|
|
Automount SA-TOKEN dans le pod. |
|
|
Activer un compte de service pour ce composant |
|
|
Annotations appliquées au compte de service activé |
|
|
Étiquettes appliquées au compte de service activé |
|
|
Automount SA-TOKEN |
|
|
Port conteneur pour l’API de santé SuperExec |
|
|
Paramètres de sécurité pour le Pod SuperExec |
|
|
Activer livenessProbe sur les conteneurs SuperExec |
|
|
Délai initial en secondes pour livenessProbe |
|
|
Période en secondes pour livenessProbe |
|
|
Temps d’attente en secondes pour livenessProbe |
|
|
Seuil de défaillance pour livenessProbe |
|
|
Seuil de réussite pour livenessProbe |
|
|
Activer readinessProbe sur les conteneurs SuperExec |
|
|
Délai initial en secondes pour readinessProbe |
|
|
Période en secondes pour readinessProbe |
|
|
Temps d’attente en secondes pour readinessProbe |
|
|
Seuil de défaillance pour readinessProbe |
|
|
Seuil de réussite pour readinessProbe |
|
|
Le nombre de conteneurs SuperExec à lancer |
|
|
Étiquettes supplémentaires pour les pods SuperExec |
|
|
Ajouter des arguments supplémentaires aux arguments par défaut pour le SuperExec |
|
|
Étiquettes de nœud pour les pods SuperExec qui se mélangent avec global.nodeSelector |
|
|
Tolérations de nœud pour les pods SuperExec qui se mélangent avec global.tolerations |
|
|
Type de stratégie de déploiement SuperExec |
|
|
Paramètres de configuration d’actualisation roulante pour le déploiement SuperExec |
|
|
Affinité de nœud pour les pods SuperExec qui se mélangent avec global.affinity |
|
|
Tableau avec des variables d’environnement supplémentaires à ajouter aux nœuds SuperExec qui se mélangent avec global.env |
|
|
Conteneurs SuperExec à automatiser la configuration avant ou après le démarrage |
|
|
Annotations personnalisées supplémentaires pour les pods SuperExec |
|
|
Étiquettes de sélection supplémentaires pour les pods SuperExec |
|
|
Annotations pour les pods SuperExec |
|
|
Étiquettes de pod supplémentaires pour les pods SuperExec |
|
|
Secrets d’image pull SuperExec qui surchargent global.imagePullSecrets |
|
|
Registre d’image SuperExec |
|
|
Répertoire d’image SuperExec |
|
|
Tag d’image du SuperExec |
|
|
Digest d’image de SuperExec |
|
|
Politique de tirage d’image des composants |
|
|
Spécifiez si une NetworkPolicy doit être créée |
|
|
Autoriser un trafic egress non restreint |
|
|
Ajouter des règles d’ingress supplémentaires à la NetworkPolicy (ignorées si allowExternalEgress=true) |
|