Having recently undertaken a comprehensive evaluation of Flux for a multi-cluster platform initiative, I've found its declarative model for continuous delivery to be exceptionally robust. However, a point of conceptual nuance that frequently surfaces, particularly for teams transitioning from imperative CI/CD tooling, is the distinction between a **trigger** and an **action** within the Flux ecosystem. While the documentation touches on these, a practical, operational breakdown from an infrastructure-as-code perspective is often needed.
Fundamentally, this distinction lies at the heart of Flux's event-driven architecture. A **trigger** is an *event* or a *condition* that signals a change has occurred in the source of truth. An **action** is the *operational workflow* that Flux executes in response to that trigger. It's a classic cause-and-effect relationship, but understanding the specific mechanisms is key to designing reliable GitOps pipelines.
Let's examine the primary triggers available in Flux:
* **Source Change:** The most common trigger. A new commit or tag in a watched Git repository branch, or an updated version in a Helm repository, changes the `Source` CR (e.g., `GitRepository`, `HelmRepository`). This change in the source artifact is the trigger.
* **Dependency Update (Image Automation):** A change in a container image tag, detected by the `ImageRepository` and `ImagePolicy` objects, triggers an update to a `Kustomization` or `HelmRelease` manifest in Git (via `ImageUpdateAutomation`).
* **Manual Intervention:** While anti-pattern to pure GitOps, a manual `kubectl patch` or `kubectl reconcile` command on a Flux object can serve as an explicit, ad-hoc trigger.
* **Periodic Reconciliation:** The built-in `interval` defined in sources and Kustomizations acts as a time-based safety trigger, ensuring state convergence even if push events are missed.
The corresponding **actions** are the reconciliation loops that Flux controllers execute. These are not generic "run a script" actions; they are precise, declarative operations:
* **Fetch/Download:** The action of pulling the latest artifact (git commit, helm chart) as defined by the source.
* **Build/Compose:** For `Kustomization`, this is the action of building the final Kubernetes manifests, including applying any patches or overlays. For `HelmRelease`, it's templating the Helm chart with the specified values.
* **Health Assessment:** The action of checking the health of deployed workloads (e.g., via readiness probes, Helm test hooks) as part of the apply process.
* **Apply/Install:** The core action of performing a server-side apply of the composed manifests to the target Kubernetes cluster, or installing/upgrading a Helm release.
* **Prune:** The cleanup action of removing Kubernetes objects that were previously applied by Flux but are no longer present in the source.
To illustrate, consider this simplified flow triggered by a Git commit:
```yaml
# 1. TRIGGER: New commit pushed to main branch.
# 2. The `GitRepository` source object status reflects new revision.
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: app-deployment
spec:
interval: 10m0s # Fallback time-based trigger
sourceRef:
kind: GitRepository
name: app-repo
path: "./kustomize/overlays/prod"
prune: true
healthChecks:
- apiVersion: apps/v1
kind: Deployment
name: my-app
namespace: production
# 3. ACTIONS initiated for this Kustomization:
# a. Fetch latest commit identified by trigger.
# b. Build the kustomized manifests from ./kustomize/overlays/prod.
# c. Apply manifests to cluster.
# d. Perform Health Assessment on the `my-app` Deployment.
# e. Prune any old objects.
```
In platform engineering terms, separating triggers from actions allows for finer-grained observability and control. You can monitor for trigger events (e.g., "source revision changed") separately from action outcomes (e.g., "reconciliation succeeded, health check passed"). This is critical for debugging and for implementing cost optimization (FinOps) by understanding the exact chain of events that leads to resource-intensive operations like cluster-wide reconciliations.
infra nerd, cost hawk