Deploy SuperNode using Helm¶
Note
Flower Helm charts are a Flower Enterprise feature. See Flower Enterprise for details.
The Flower Framework offers a unified approach to federated learning, analytics, and evaluation, allowing you to federate any workload, machine learning framework, or programming language.
This Helm chart installs the client-side components of the Flower Framework, specifically setting up the SuperNode.
The default installation configuration aims to replicate the functionality and setup of the provided Flower Framework releases.
Multi Project Setup¶
To install multiple types of SuperNodes, such as a federation for running PyTorch and another for TensorFlow, you need to install the Helm Chart multiple times with different names. This allows each deployment to have its own configurations and dependencies.
For instance, you can install the Chart for the PyTorch setup by adjusting the values.yaml file as shown below:
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
Install this configuration using the following command:
$ helm install pytorch . --values values.yaml
This will deploy 10 SuperNodes named pytorch-flower-client-supernode-<random>.
For a TensorFlow setup, modify the values.yaml file as follows:
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
Install this configuration using the following command:
$ helm install tensorflow . --values values.yaml
This will deploy 3 SuperNodes named tensorflow-flower-client-supernode-<random>.
Deploy Flower Framework with TLS¶
By default, the Flower Framework is deployed with TLS enabled. This means tls.enabled is
set to true.
When using private CAs, the SuperNode must trust the CA certificate in order to connect securely to the SuperLink.
To provide the CA certificate, set tls.enabled to true and create a Secret of type
kubernetes.io/tls named flower-client-tls:
tls:
enabled: true
If you want to use a different Secret name, override the default by setting
supernode.superlink.certificate.existingSecret:
tls:
enabled: true
supernode:
superlink:
certificate:
existingSecret: my-custom-tls-secret-name
Important:
The recommended practice is to mount different Secrets for the SuperLink and the
SuperNodes existingSecret parameter. Keeping these Secrets separate ensures
that if the Secret containing the server’s private key and certificate is ever
tampered with, the client will fail to connect rather than trusting a compromised
server.
For further details, refer to the cert-manager documentation.
If the SuperLink certificate (of type kubernetes.io/tls) is deployed in the same cluster and
namespace as the SuperNode, you can enable supernode.superlink.certificate.copyFromExistingSecret.
This instructs the chart to create a new Secret containing the CA certificate.
It copies ca.crt from the SuperLink Secret, or falls back to tls.crt if ca.crt is not
present.
By default, the copied Secret is named flower-client-tls. You can customize this name with
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
Deploy Flower Framework without TLS¶
You might want to deploy the Flower framework without TLS for testing or internal use. Be cautious as this exposes your deployment to potential security risks.
tls:
enabled: false
Node Authentication¶
To enable Node Authentication, you need to specify a private key in either PKCS8 or OpenSSH
(PEM-like) format. This example assumes that the SuperLink is also configured for Node
Authentication and recognizes the ecdsa-sha2-nistp384 [...] public key of this 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
Isolated Setup¶
Isolation All-in-One¶
To install SuperNode in isolation mode using the “process” configuration, both the SuperExec and
SuperNode need to be enabled. By default, the SuperExec connects to the SuperNode internally
within the cluster, so there is no need to set supernode.address and supernode.port unless the
connection is external. This setup assumes that both components are running within the same cluster.
supernode:
enabled: true
isolationMode: process
superexec:
enabled: true
Isolation Distributed¶
You can also deploy the SuperNode and SuperExec separately. To do this, you need to deploy the
chart twice: once with supernode.enabled=true and once with superexec.enabled=true.
supernode:
enabled: true
superexec:
enabled: true
supernode:
address: my-supernode.example.com
port: 9094
Node Configuration¶
You can add a node configuration to configure a SuperNode. The YAML datatype is preserved when passing it in the Python application:
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¶
Helm parameters¶
Name |
Description |
Value |
|---|---|---|
|
Replaces the name of the chart in the Chart.yaml |
|
|
Completely replaces the generated name. |
|
Global parameters¶
Name |
Description |
Value |
|---|---|---|
|
Default Annotations |
|
|
Default Labels |
|
|
Default PodLabels |
|
|
Default node selector for all components |
|
|
Default tolerations for all components |
|
|
Default affinity preset for all components |
|
|
Default pod anti-affinity rules. Either: |
|
|
Default node affinity rules. Either: |
|
|
Default match expressions for node affinity |
|
|
Enables or Disables Node-Authentication SuperLink <-> SuperNode |
|
|
Specifies the ecdsa-sha2-nistp384 private key |
|
|
Set Security Context runAsUser |
|
|
Set Security Context runAsGroup |
|
|
Set Security Context fsGroup |
|
|
Set Security Context runAsNonRoot |
|
|
Set Security Context readOnlyRootFilesystem |
|
|
Set Security Context allowPrivilegeEscalation |
|
|
Set Security Context seccompProfile |
|
|
Set Security Context capabilities |
|
|
Default environment variables |
|
|
Default image pullPolicy |
|
TLS Configuration¶
Name |
Description |
Value |
|---|---|---|
|
Enable TLS configuration for the Flower Framework. |
|
Component SuperNode¶
Name |
Description |
Value |
|---|---|---|
|
Name of the SuperNode |
|
|
Enable or disable SuperNode |
|
|
Set container requests and limits for different resources like CPU or memory (essential for production workloads) |
|
|
|
|
|
The isolation mode of the SuperNode |
|
|
Set container requests and limits for different resources like CPU or memory (essential for production workloads) |
|
|
Address of the SuperLink the SuperNodes should connect to |
|
|
Port of the SuperLink the SuperNodes should connect to |
|
|
|
|
|
|
|
|
|
|
|
Specify a list of volumes for the SuperNode pod(s) |
|
|
Allows to specify additional VolumeMounts |
|
|
Automount SA-Token into the pod. |
|
|
Enable a service account for this component |
|
|
Annotations applied to enabled service account |
|
|
Labels applied to enabled service account |
|
|
Automount SA-Token |
|
|
Valid are ClusterIP, NodePort or Loadbalancer |
|
|
Prefix of the SuperNode ClientAppIo API port |
|
|
Port to expose for the SuperNode ClientAppIo API |
|
|
Node port for SuperNode ClientAppIo API |
|
|
Container port for SuperNode ClientAppIo API |
|
|
Container port for SuperNode Health API |
|
|
|
|
|
The number of SuperNode pods to run |
|
|
Extra labels for SuperNode pods |
|
|
Add extra arguments to the default arguments for the SuperNode |
|
|
Enable TLS on the SuperNode ClientAppIo API. |
|
|
Path to the CA certificate used by SuperExec to verify ClientAppIo. |
|
|
Path to the ClientAppIo server certificate. |
|
|
Path to the ClientAppIo server private key. |
|
|
Path to a file containing the SuperExec shared secret. |
|
|
Node labels for SuperNode pods which merges with global.nodeSelector |
|
|
Node tolerations for SuperNode pods which merges with global.tolerations |
|
|
SuperNode deployment strategy type |
|
|
SuperNode deployment rolling update configuration parameters |
|
|
Node affinity for SuperNode pods which merges with global.affinity |
|
|
Array with extra environment variables to add to SuperNode nodes which merges with global.env |
|
|
Enable livenessProbe on SuperNode containers |
|
|
Initial delay seconds for livenessProbe |
|
|
Period seconds for livenessProbe |
|
|
Timeout seconds for livenessProbe |
|
|
Failure threshold for livenessProbe |
|
|
Success threshold for livenessProbe |
|
|
Enable readinessProbe on SuperNode containers |
|
|
Initial delay seconds for readinessProbe |
|
|
Period seconds for readinessProbe |
|
|
Timeout seconds for readinessProbe |
|
|
Failure threshold for readinessProbe |
|
|
Success threshold for readinessProbe |
|
|
SuperNode container(s) to automate configuration before or after startup |
|
|
Additional custom annotations for SuperNode |
|
|
Extra selectorLabels for SuperNode pods |
|
|
Annotations for SuperNode pods |
|
|
Extra podLabels for SuperNode pods |
|
|
SuperNode image pull secrets which overrides global.imagePullSecrets |
|
|
SuperNode image registry |
|
|
SuperNode image repository |
|
|
Image tag of SuperNode |
|
|
Image digest of SuperNode |
|
|
Components image pullPolicy |
|
|
Specifies whether a NetworkPolicy should be created |
|
|
Allow external ingress traffic |
|
|
Allow unrestricted egress traffic |
|
|
Add extra ingress rules to the NetworkPolicy |
|
|
Add extra egress rules to the NetworkPolicy (ignored if allowExternalEgress=true) |
|
|
Labels to match to allow traffic from other pods. Ignored if |
|
|
Labels to match to allow traffic from other namespaces. Ignored if |
|
|
Pod labels to match to allow traffic from other namespaces. Ignored if |
|
Component SuperExec¶
Name |
Description |
Value |
|---|---|---|
|
Name of the SuperExec |
|
|
Enable or disable SuperExec component |
|
|
The type of plugin to use. |
|
|
Set container requests and limits for different resources like CPU or memory (essential for production workloads) |
|
|
Address of the supernode the SuperExec should connect to |
|
|
Path to a file containing the SuperExec shared secret. |
|
|
Path to a PEM-encoded root CA certificate used to verify AppIO. |
|
|
Allow SuperExec to install runtime dependencies for ClientApps. |
|
|
Executor backend for SuperExec task launches. Valid values are |
|
|
Absolute file path inside the SuperExec container for the executor config file. Must not end with |
|
|
Create a ConfigMap containing the generated executor config. |
|
|
ConfigMap name to create or mount. Required when |
|
|
ConfigMap data key for the generated executor config file. |
|
|
Namespace where SuperExec creates TaskExecutor Pods and credential Secrets. The chart renders this Namespace in Kubernetes executor mode, so installation requires permission to create or adopt it. Required when |
|
|
Path to a PEM-encoded AppIO root CA file to copy into TaskExecutor credential Secrets. |
|
|
TaskExecutor image registry. |
|
|
TaskExecutor image repository. |
|
|
TaskExecutor image tag. |
|
|
TaskExecutor image digest. |
|
|
TaskExecutor image pull policy. |
|
|
Resource pool label value for the TaskExecutor Namespace and generated TaskExecutor Pods and Secrets. |
|
|
Maximum active TaskExecutor Pods allowed for this SuperExec before it waits for capacity. |
|
|
Capacity wait polling interval in seconds. |
|
|
Capacity wait log interval in seconds. |
|
|
Additional labels for generated TaskExecutor Pods and Secrets. |
|
|
Additional annotations for generated TaskExecutor Pods and Secrets. |
|
|
Literal environment variables for the generated TaskExecutor container. |
|
|
TaskExecutor container requests and limits. |
|
|
Node selector for generated TaskExecutor Pods. |
|
|
Tolerations for generated TaskExecutor Pods. |
|
|
Affinity for generated TaskExecutor Pods. |
|
|
PriorityClass name for generated TaskExecutor Pods. |
|
|
Pod security context for generated TaskExecutor Pods. |
|
|
Container security context for generated TaskExecutor Pods. |
|
|
Optional service account name for generated TaskExecutor Pods. Flower’s Kubernetes executor runtime sets |
|
|
Specify a list of volumes for the SuperExec pod(s) |
|
|
Allows to specify additional VolumeMounts |
|
|
Automount SA-Token into the pod. |
|
|
Enable a service account for this component |
|
|
Annotations applied to enabled service account |
|
|
Labels applied to enabled service account |
|
|
Automount SA-Token |
|
|
Create Role and RoleBinding permissions in the TaskExecutor namespace for the Kubernetes executor launcher ServiceAccount. |
|
|
Include diagnostic |
|
|
Container port for SuperExec Health API |
|
|
Security settings for the SuperExec Pod |
|
|
Enable livenessProbe on SuperExec containers |
|
|
Initial delay seconds for livenessProbe |
|
|
Period seconds for livenessProbe |
|
|
Timeout seconds for livenessProbe |
|
|
Failure threshold for livenessProbe |
|
|
Success threshold for livenessProbe |
|
|
Enable readinessProbe on SuperExec containers |
|
|
Initial delay seconds for readinessProbe |
|
|
Period seconds for readinessProbe |
|
|
Timeout seconds for readinessProbe |
|
|
Failure threshold for readinessProbe |
|
|
Success threshold for readinessProbe |
|
|
The number of SuperExec containers to run |
|
|
Extra labels for SuperExec pods |
|
|
Add extra arguments to the default arguments for the SuperExec |
|
|
Node labels for SuperExec pods which merges with global.nodeSelector |
|
|
Node tolerations for SuperExec pods which merges with global.tolerations |
|
|
SuperExec deployment strategy type |
|
|
SuperExec deployment rolling update configuration parameters |
|
|
Node affinity for SuperExec pods which merges with global.affinity |
|
|
Array with extra environment variables to add to SuperExec nodes which merges with global.env |
|
|
SuperExec container(s) to automate configuration before or after startup |
|
|
Additional custom annotations for SuperExec |
|
|
Extra selectorLabels for SuperExec pods |
|
|
Annotations for SuperExec pods |
|
|
Extra podLabels for SuperExec pods |
|
|
SuperExec image pull secrets which overrides global.imagePullSecrets |
|
|
SuperExec image registry |
|
|
SuperExec image repository |
|
|
Image tag of SuperExec |
|
|
Image digest of SuperExec |
|
|
Components image pullPolicy |
|
|
Specifies whether a NetworkPolicy should be created |
|
|
Allow unrestricted egress traffic |
|
|
Add extra egress rules to the NetworkPolicy (ignored if allowExternalEgress=true) |
|
|
Create a NetworkPolicy in the TaskExecutor namespace for Flower-created TaskExecutor Pods. |
|
|
Allow unrestricted egress from TaskExecutor Pods. |
|
|
Additional labels for the TaskExecutor NetworkPolicy pod selector. These labels are also added to generated TaskExecutor Pod labels. |
|
|
Add egress rules from TaskExecutor Pods to AppIO, proxies, registries, or other required services (ignored if allowExternalEgress=true). |
|