Flux Reflector can scan container registries for new images and automatically update your Git repository with the latest versions.
Here’s how it works in practice. Imagine you have a deployment running an application, and you want to ensure it’s always using the latest stable version of its container image. Instead of manually checking for new image tags, building new container images, and then updating your Kubernetes manifests, Flux Reflector automates this.
Let’s say you’re using nginx:1.23.0 and a new patch release, nginx:1.23.1, becomes available in your container registry. You’ve configured Flux Reflector to watch the nginx repository for new tags matching a specific pattern (e.g., 1.23.x).
Here’s a snippet of a Flux ImagePolicy that tells Reflector what to look for:
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: nginx-policy
namespace: flux-system
spec:
imageRepositoryRef:
name: nginx-repo # This refers to an ImageRepository object
policy:
semver:
range: "1.23.x" # Watch for any new tags starting with 1.23.
And here’s the corresponding ImageRepository that points Reflector to the registry:
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: nginx-repo
namespace: flux-system
spec:
image: nginx
interval: 10m # How often to scan the registry
secretRef:
name: registry-credentials # If your registry is private
When Flux Reflector scans the nginx repository and finds nginx:1.23.1, it doesn’t directly update your Kubernetes cluster. Instead, it commits a change to your Git repository. This change would typically be an update to a kustomization.yaml file or a specific Kubernetes manifest, referencing the new image tag.
For example, your Git repository might have a file like apps/my-app/kustomization.yaml:
resources:
- deployment.yaml
images:
- name: nginx
newTag: 1.23.0 # This is what Flux Reflector will update
After Reflector finds nginx:1.23.1, it would commit a change to this file, updating newTag to 1.23.1. Because Flux is also managing your Git repository, it detects this new commit and proceeds to apply the updated manifest to your Kubernetes cluster. This creates a declarative, GitOps-driven workflow for managing application dependencies.
The interval in the ImageRepository is crucial. It determines how frequently Flux Reflector polls the container registry for new image tags. A shorter interval means faster detection of new images but also more frequent API calls to the registry. The semver policy allows you to specify exactly which tags you’re interested in, preventing accidental updates from development or unstable tags.
The policy field is where the real intelligence lies. You can use semver for semantic versioning ranges (like "major.minor.patch"), or digest to always pull the latest image based on its digest, ensuring immutability. If you use digest, the newTag in your kustomization.yaml will be replaced by the full image digest (e.g., nginx@sha256:...), which is the most robust way to ensure you’re always running a specific, immutable image.
Flux Reflector’s primary function is to bridge the gap between your container registry and your GitOps workflow. It acts as the automated watcher and updater, ensuring that your Git repository accurately reflects the desired state of your deployed applications, including their specific image versions.
One subtlety many users overlook is how ImagePolicy and ImageRepository interact with ImageUpdateAutomation. While ImagePolicy defines what to look for and ImageRepository defines where, it’s ImageUpdateAutomation that orchestrates the actual Git commit. Without an ImageUpdateAutomation resource, Reflector will detect new images but won’t know how to commit those changes back to Git. This resource defines the commit message, branch to push to, and even how to handle merge conflicts.
The next step after setting up automated image updates is to explore how to manage multiple image policies and repositories, and how to integrate this with your CI/CD pipelines for building new images.