ZEDEDA Edge Kubernetes App Flows GitOps Configuration Examples for fleet.yaml

Updated January 06, 2026 19:49

Introduction

The fleet.yaml file is optional and defines how zks-fleet bundles are deployed to Edge Kubernetes Service Clusters for GitOps. If provided, this file may be located in the root of your Git repository or within a specific subdirectory containing your application manifests.

You can use fleet.yaml to customize Helm chart parameters, define rollout strategies, and target specific edge nodes based on labels. The fleet.yaml file is based on the Fleet format.

There is a default poll time of 60 seconds. When you make your changes in git, App Flows will auto refresh the changes every 60 seconds.

For more info about getting started, see the k8s-app-flows-starter repository on GitHub. This starter template includes a directory structure and sample manifests designed to demonstrate how to implement GitOps workflows within your edge Kubernetes clusters.

This is a series of articles. You will likely follow them in this order.

Prerequisites

You have onboarded one or more edge nodes.
Your edge nodes are online.
Your edge nodes are running the EVE-k v16.0.0 or greater (EVE-OS KVM is not supported).
4GB minimum RAM and 2 CPU.
You have either the SysManager or SysAdmin role in your ZEDEDA Cloud enterprise.
You have already created a ZEDEDA Edge Kubernetes Service Cluster.

Examples

The following example configurations assume that your Helm chart is located under ./chart.

Basic Helm chart deployment

This configuration will instruct App Flows to treat the contents of ./chart/ as a Helm chart bundle, deploy into namespace default, using defaults from the chart’s own values.yaml.

#YAML
# fleet.yaml   # Name of this file
name: my-app-bundle
namespace: default             # target namespace
helm:
  chart: ./chart               # path to the chart in this repo
  # version: 1.2.3             # optional (for OCI / remote charts)
  # repo: https://charts.example.com  # only needed if chart is in external repo

Helm chart with custom values

You can override default values directly within fleet.yaml. This is useful for defining environment-specific configurations or overriding image tags.

#YAML
# fleet.yaml     # Name of this file
name: backend-service
namespace: backend-namespace
helm:
  chart: ./chart # path to the chart in this repo
  values:
    replicaCount: 3 # Min, max, and typical values?
    image:
      tag: "v1.4.2"
    service:
      type: ClusterIP
      port: 8080

Multi-cluster deployment with per-cluster overrides

You can apply different configurations to specific edge nodes using targetCustomizations. This example applies different replicaCount and serviceType values based on the labels attached to the edge node (for example, env=dev, env=prod).

#YAML
# fleet.yaml     # Name of this file
namespace: my-app-namespace
targetCustomizations:
  - name: dev # Development environment
    helm:
      values:
        replicaCount: 1
        serviceType: ClusterIP
    clusterSelector:
      matchLabels:
        env: dev
  - name: test # Test environment
    helm:
      values:
        replicaCount: 2
        serviceType: ClusterIP
    clusterSelector:
      matchLabels:
        env: test
  - name: prod # Production environment
    helm:
      values:
        replicaCount: 4
        serviceType: LoadBalancer
    clusterSelector:
      matchLabels:
        env: prod

Behavior:

Clusters with env: dev - deploy with replicaCount=1, ClusterIP.
Clusters with env: test - replicaCount=2, ClusterIP.
Clusters with env: prod - replicaCount=4, exposed via LoadBalancer.

Skip deployment to specific clusters

Use the doNotDeploy parameter to exclude specific edge clusters from a deployment. This is effective for phasing out legacy nodes or managing maintenance windows.

#YAML
# fleet.yaml     # Name of this file
namespace: my-app-namespace
targetCustomizations:
  - name: skip-legacy
    doNotDeploy: true
    clusterSelector:
      matchLabels:
        legacy: "true"

In this configuration, any edge node labeled legacy: "true" will not receive the bundle deployment.

Mixed approach: values file with per-cluster overrides

You can combine a base values.yaml file with specific overrides in targetCustomizations. This maintains a set of default configurations while allowing specific parameters to change based on the target. When a particular parameter is not set for a target, the default value is used; if a value is set, that value overrides the default.

#YAML
# fleet.yaml     # Name of this file
helm:
  chart: ./chart
  valuesFiles:
    - values.yaml
targetCustomizations:
  - name: prod # Production environment
    helm:
      values:
        replicaCount: 5         # override only this for production
    clusterSelector:
      matchLabels:
        env: prod

Environment-specific values files

For complex configurations, you might prefer separate value files for different environments (for example, values.dev.yaml, values.prod.yaml). App Flows merges these files in a specific order.

#YAML
# fleet.yaml     # Name of this file
namespace: my-app
helm:
  chart: ./chart
  # base values file applied to all clusters
  valuesFiles:
    - values.yaml
targetCustomizations:
  - name: dev # Development environment
    helm:
      valuesFiles:
        - values.dev.yaml
    clusterSelector:
      matchLabels:
        env: dev
  - name: prod # Production environment
    helm:
      valuesFiles:
        - values.prod.yaml
    clusterSelector:
      matchLabels:
        env: prod

Merge details:

All clusters load base values.yaml
Dev clusters additionally load values.dev.yaml
Prod clusters additionally load values.prod.yaml

App Flows merges them in Helm’s normal order: values.yaml → values.dev.yaml or values.prod.yaml → inline values (if any)

Next Steps

This is a series of articles. You will likely follow them in this order.

Was this article helpful?

0 out of 0 found this helpful