Flux – ecosystem

Blog: Time-based deployments with Flux Operator

Mon, 07 Jul 2025 12:00:00 +0000

We are thrilled to announce time-based deployments, a feature long-awaited by Flux users, in Flux Operator v0.23.0!

Organizations using Flux for GitOps deployments frequently require sophisticated control over when changes are applied to production systems, particularly in regulated industries or critical business environments. Key requirements include adhering to Change Advisory Board (CAB) approval windows, enforcing “No Deploy Fridays” policies, and restricting deployments during peak business hours to ensure service stability.

Maintenance windows become critical when managing helm upgrades, where teams need to skip reconciliation unless the current time falls within a specified interval. In regulated environments like medical device companies, automated deployments must be controlled to prevent unexpected disruptions during critical operational periods. Large telecommunications providers and ISVs managing multiple client clusters need gating mechanisms to control application rollouts, allowing tenants to consume platform updates when ready.

In this post, we show how to use time-based deployment with Flux Operator ResourceSets.

How it works

The Flux Operator ResourceSet API allows defining bundles of Flux objects by templating a set of resources with inputs provided by the ResourceSetInputProvider API.

The ResourceSetInputProvider API allows pulling inputs from external sources, such as GitHub pull requests, branches and tags. For example, on the reconciliation of a ResourceSetInputProvider of type GitHubTag, the operator will list the tags of a GitHub repository, filter them according to a semver range, and export a set of inputs for each matching tag in the ResourceSetInputProvider .status.exportedInputs field. For example:

status:
 exportedInputs:
 - id: "48955639"
 tag: "6.0.4"
 sha: 11cf36d83818e64aaa60d523ab6438258ebb6009

Starting with Flux Operator v0.23.0, the ResourceSetInputProvider API now has the field .spec.schedule, which allows defining a cron-based schedule for the reconciliation of the ResourceSetInputProvider. For example:

spec:
 schedule:
 # Every day-of-week from Monday through Thursday
 # between 10:00 to 16:00
 - cron: "0 10 * * 1-4"
 timeZone: "Europe/London"
 window: "6h"
 # Every Friday from 10:00 to 13:00
 - cron: "0 10 * * 5"
 timeZone: "Europe/London"
 window: "3h"

With this configuration, reconciliations of the ResourceSetInputProvider object would only be allowed to run within the specified time windows. When the window is active, the reconciliation happens normally, according to the interval defined in the fluxcd.controlplane.io/reconcileEvery annotation.

A complete example

Define a ResourceSetInputProvider: This provider will scan a Git branch or tag for changes and export the commit SHA as an input.
Configure schedule: The provider will have a reconciliation schedule that defines when it should check for changes in the Git repository.
Define a ResourceSet: The ResourceSet will use the inputs from the provider to create a GitRepository and Kustomization that deploys the application at the specified commit SHA.

ResourceSetInputProvider Definition

Assuming the Kubernetes deployment manifests for an application are stored in a Git repository, you can define a input provider that scans a branch for changes and exports the commit SHA:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSetInputProvider
metadata:
 name: my-app-main
 namespace: apps
 labels:
 app.kubernetes.io/name: my-app
 annotations:
 fluxcd.controlplane.io/reconcileEvery: "10m"
 fluxcd.controlplane.io/reconcileTimeout: "1m"
spec:
 schedule:
 - cron: "0 8 * * 1-5"
 timeZone: "Europe/London"
 window: 8h
 type: GitHubBranch # or GitLabBranch
 url: https://github.com/my-org/my-app
 secretRef:
 name: gh-app-auth
 filter:
 includeBranch: "^main$"
 defaultValues:
 env: "production"

For when Git tags are used to version the application, you can define an input provider that scans the Git tags and exports the latest tag according to a semantic versioning:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSetInputProvider
metadata:
 name: my-app-release
 namespace: apps
 labels:
 app.kubernetes.io/name: my-app
 annotations:
 fluxcd.controlplane.io/reconcileEvery: "10m"
 fluxcd.controlplane.io/reconcileTimeout: "1m"
spec:
 schedule:
 - cron: "0 8 * * 1-5"
 timeZone: "Europe/London"
 window: 8h
 type: GitHubTag # or GitLabTag
 url: https://github.com/my-org/my-app
 secretRef:
 name: gh-auth
 filter:
 semver: ">=1.0.0"
 limit: 1

ResourceSet Definition

The exported inputs can then be used in a ResourceSet to deploy the application using the commit SHA from the input provider:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSet
metadata:
 name: my-app
 namespace: apps
spec:
 inputsFrom:
 - kind: ResourceSetInputProvider
 selector:
 matchLabels:
 app.kubernetes.io/name: my-app
 resources:
 - apiVersion: source.toolkit.fluxcd.io/v1
 kind: GitRepository
 metadata:
 name: my-app
 namespace: << inputs.provider.namespace >>
 spec:
 interval: 12h
 url: https://github.com/my-org/my-app
 ref:
 commit: << inputs.sha >>
 secretRef:
 name: gh-auth
 sparseCheckout:
 - deploy
 - apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
 metadata:
 name: my-app
 namespace: << inputs.provider.namespace >>
 spec:
 interval: 30m
 retryInterval: 5m
 prune: true
 wait: true
 timeout: 5m
 sourceRef:
 kind: GitRepository
 name: my-app
 path: deploy/<< inputs.env >>

When the ResourceSetInputProvider runs according to its schedule, if it finds a new commit, the ResourceSet will be automatically updated with the new commit SHA which will trigger an application deployment for the new version.

Blog: AI-Assisted GitOps with Flux Operator MCP Server

Wed, 14 May 2025 12:00:00 +0000

In this blog post, we introduce the Flux MCP Server, a new component of the Flux Operator project that connects AI assistants directly to your Kubernetes clusters, enabling seamless interaction through natural language. It serves as a bridge between AI tools and your GitOps pipelines, allowing you to analyze the cluster state, troubleshoot deployment issues, and perform operations using conversational prompts.

Bringing AI to GitOps

The GitOps movement started with the Flux community back in 2016, and since then, it has gained immense popularity in the Kubernetes ecosystem as a way to manage infrastructure and application deployments declaratively. But as the GitOps pipelines grow in complexity, so does the cognitive load required to troubleshoot issues, understand resource relationships, and perform routine operations.

That’s where the Flux MCP Server comes in. By connecting AI assistants to Kubernetes clusters and the desired state in Git, it allows operators to:

Debug GitOps pipelines end-to-end from Flux resources to application logs
Get accurate root cause analysis for failed deployments
Compare Flux configurations and Kubernetes resources between clusters
Visualize Flux dependencies with diagrams generated from the cluster state
Instruct Flux to perform operations using conversational prompts
Get up-to-date information and recommendations using the latest Flux official docs

How It Works

The Flux MCP Server implements the Model Context Protocol (MCP), providing purpose-built tools that allow AI assistants to interact with your clusters. When you ask a question or make a request, the AI model uses these tools to gather information, analyze configurations, and even perform operations based on your instructions.

The AI assistants leveraging the Flux MCP Server can trace issues from high-level GitOps resources like ResourceSets, HelmReleases, and Kustomizations all the way down to Kubernetes deployments and pod logs.

In addition, the MCP Server enables the AI to search the Flux documentation and provide accurate, up-to-date guidance based on the latest features and best practices, rather than relying solely on its training data.

Getting Started

Setting up the Flux MCP Server is straightforward. The server is written in Go and statically compiled as a single binary with no external dependencies.

You can install it using Homebrew:

brew install controlplaneio-fluxcd/tap/flux-operator-mcp

Alternatively, you can download pre-built binaries for Linux, macOS, and Windows, for more details refer to the installation guide.

Once installed, you can configure your AI assistant to use the Flux MCP Server. For Claude, Cursor, Windsurf, or GitHub Copilot add the following configuration to the MCP settings:

{
 "flux-operator-mcp":{
 "command":"flux-operator-mcp",
 "args":["serve"],
 "env":{
 "KUBECONFIG":"/path/to/.kube/config"
 }
 }
}

Make sure to replace /path/to/.kube/config with the absolute path to your kubeconfig file.

Setting Up AI Instructions

For the best experience with the Flux MCP Server, it’s crucial to provide your AI assistant with proper instructions on how to interact with Kubernetes clusters and the Flux resources. These instructions help the AI understand the context and make appropriate tool calls.

The Flux MCP Server comes with a set of predefined instructions that you can copy from the instructions.md file.

It’s recommended to enhance these instructions with information specific to your clusters, such as:

Kubernetes distribution details (EKS, GKE, AKS, etc.)
Cloud-specific services integrated with your clusters
Types of applications deployed
Secret management approaches

For detailed guidance on how to configure these instructions with different AI assistants, refer to the AI Instructions section of the documentation.

Practical Applications

Let’s look at some practical ways the Flux MCP Server can enhance your GitOps experience:

1. Quick Health Assessment

Instead of running multiple kubectl and flux commands to check the status of your GitOps pipeline, you can simply ask:

Analyze the Flux installation in my current cluster and report the status of all components and ResourceSets.

The AI assistant will gather information about your Flux Operator installation, controllers, and managed resources, providing a comprehensive health assessment.

2. GitOps Pipeline Visualization

Understanding the relationships between various GitOps resources can be challenging. The Flux MCP Server makes it easy:

List the Flux Kustomizations and draw a Mermaid diagram for the depends on relationship.

The AI will generate a visual representation of your GitOps pipeline, showing the dependency relationships between Flux Kustomizations and helping you understand the deployment order and potential bottlenecks.

3. Cross-Cluster Comparisons

When managing multiple environments, comparing configurations can be tedious. With Flux MCP Server:

Compare the podinfo HelmRelease between production and staging clusters.

The AI will switch contexts, gather the relevant information, and highlight the differences between the two environments.

3. Root Cause Analysis

When deployments fail, finding the root cause can involve digging through multiple resources and logs:

Perform a root cause analysis of the last failed Helm release in the frontend namespace.

The AI assistant will trace through dependencies, check resource statuses, analyze logs, and provide a detailed explanation of what went wrong and how to fix it.

4. GitOps Operations

You can even perform GitOps operations directly through natural language:

Resume all the suspended Flux resources in the current cluster and verify their status.

The AI will identify suspended resources, resume them, and report on the results.

5. Kubernetes Operations

The Flux MCP Server enables complex Kubernetes operations with simple instructions:

Create a namespace called test, then copy the podinfo Helm release and its source. Change the Helm values for ingress to test.podinfo.com

The AI will generate and apply the necessary Kubernetes resources, handling the details of creating namespaces, cloning Helm releases, and modifying configuration values - all through a single conversational request.

Security Considerations

As with any tool that interacts with your clusters, security should be a top priority. The Flux MCP Server includes several security features to ensure safe operations:

Operates with your existing kubeconfig permissions
Supports service account impersonation for limited access
Masks sensitive information in Kubernetes Secret values
Provides a read-only mode for observation without affecting the cluster state

For more details on security settings, please refer to the configuration guide.

The Future of AI-Assisted GitOps

The Flux MCP Server is currently an experimental feature, and it’s being actively developed based on user feedback and real-world use cases.

We plan to enhance the server with the following features in future releases:

Integration with Kubernetes metrics-server and other observability tools
Improved the documentation search capabilities
More advanced troubleshooting capabilities
Support for staged rollout/rollback of apps across clusters

All feedback is welcome, please reach out to us on GitHub Discussions.

Blog: GitHub App bootstrap with Flux Operator

Mon, 14 Apr 2025 12:00:00 +0000

In this blog post, we will showcase how Flux Operator can be used to bootstrap Kubernetes clusters using the GitHub App authentication method introduced in Flux 2.5.0.

Prior to Flux 2.5.0, the GitHub repository authentication methods were based on using a secret that is tied to a GitHub user, be it a personal access token (PAT) or an SSH deploy key. When the user leaves the organization, the GitHub deploy keys are revoked resulting in Flux losing access to all repositories. To restore access, the cluster administrators have to generate new GitHub deploy keys tied to a different user and rotate the secret in all clusters.

To avoid this situation, the recommendation was for organizations to create a dedicated GitHub user for Flux, but this is also not ideal since an extra user affects billing. The login credentials and MFA code have to be stored in an external secret management system like 1Password, increasing the complexity of the cluster bootstrap process.

Starting with Flux 2.5.0, the GitHub App authentication method allows organizations to create a GitHub App with access to the repositories from where Flux syncs the desired state of Kubernetes clusters. Instead of using the credentials of a GitHub user, Flux running on the clusters will use the GitHub App private key to authenticate with the GitHub API, acquiring a short-lived access token to perform Git operations.

Flux Operator

The Flux Operator offers an alternative to the Flux CLI bootstrap procedure. It removes the operational burden of managing Flux across fleets of clusters by fully automating the installation, configuration, and upgrade of the Flux controllers based on a declarative API called FluxInstance.

The FluxInstance custom resource defines the desired state of the Flux components and allows the configuration of the cluster state syncing from Git repositories, OCI artifacts and S3-compatible storage.

When using a GitHub repository as the source of truth, the Flux instance can be configured to use the GitHub App authentication method by referencing a Kubernetes secret that contains the app ID, the installation ID and the private key of the GitHub App.

What follows is a step-by-step guide on how to install the Flux Operator and bootstrap a cluster using the GitHub App authentication.

Bootstrap using Flux Operator and Helm

First, install the Flux Operator using the Helm chart:

helm install flux-operator oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator \
 --namespace flux-system \
 --create-namespace

Next, create a GitHub App secret using the flux CLI (see docs on how to create a GitHub App here):

flux create secret githubapp flux-system \
 --app-id=1 \
 --app-installation-id=2 \
 --app-private-key=./path/to/private-key-file.pem

Finally, bootstrap the cluster by creating a FluxInstance custom resource in the flux-system namespace:

apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
 name: flux
 namespace: flux-system
spec:
 distribution:
 version: "2.x"
 registry: "ghcr.io/fluxcd"
 components:
 - source-controller
 - kustomize-controller
 - helm-controller
 - notification-controller
 - image-reflector-controller
 - image-automation-controller
 cluster:
 type: kubernetes
 multitenant: false
 networkPolicy: true
 domain: "cluster.local"
 sync:
 kind: GitRepository
 provider: github
 url: "https://github.com/my-org/my-fleet.git"
 ref: "refs/heads/main"
 path: "clusters/my-cluster"
 pullSecret: "flux-system"

When the FluxInstance is applied on the cluster, the operator will automatically deploy the Flux controllers and configure them to sync the cluster state from the specified repository using GitHub App authentication. Similarly to the Flux CLI bootstrap, the operator generates a Flux GitRepository and Kustomization named flux-system that points to the clusters/my-cluster path inside the Git repository.

The Flux instance can be customized in various ways including multi-tenancy lockdown, sharding, horizontal and vertical scaling, persistent storage, and fine-tuning the Flux controllers with Kustomize patches. For more information on the available options, please refer to the Flux Operator documentation.

Bootstrap using Flux Operator and Terraform

Alternatively, you can use Terraform or OpenTofu to install the Flux Operator and the FluxInstance. A Terraform example is available in the Flux Operator repository.

The command for applying this Terraform example with a GitHub App would be the following:

export GITHUB_APP_PEM=`cat path/to/app.private-key.pem`

terraform apply \
 -var flux_version="2.x" \
 -var flux_registry="ghcr.io/fluxcd" \
 -var github_app_id="1" \
 -var github_app_installation_id="2" \
 -var github_app_pem="$GITHUB_APP_PEM" \
 -var git_url="https://github.com/my-org/my-fleet.git" \
 -var git_ref="refs/heads/main" \
 -var git_path="clusters/production"

GitHub App Docs

After installing your GitHub App in your organization you can find the installation ID like this:

Go to the Organization settings
Click on ‘GitHub Apps’ under ‘Third-party Access’
If there are multiple GitHub apps, choose your App and click on ‘Configure’
Once your GitHub App is selected check the URL for obtaining ‘GitHub App Installation ID’

The URL looks like this:

https://github.com/organizations/<Organization-name>/settings/installations/<ID>

Conclusion

Using the GitHub App authentication method with Flux Operator offers a more secure way of bootstrapping Flux on Kubernetes clusters, as it eliminates the need for managing GitHub user credentials and deploy keys. This approach ensures that Flux can continue to operate seamlessly even when users leave the organization or change their access permissions.

Migrating clusters that have been bootstrapped with the Flux CLI to the Flux Operator is a straightforward process. For more information on how to do this, please refer to the Flux Operator bootstrap migration guide.

Blog: How to use Weave GitOps as your Flux UI

Tue, 04 Apr 2023 08:30:00 +0000

Here comes the newest blog post in our ecosystem category. One of the key reasons to rewrite Flux was to break up the former monolith solution into separate controllers which provide distinct parts of the functionality. This allows users to pick just the parts they need, and integrators to very easily build on top of Flux’s APIs. Today we have a very active Flux Ecosystem - we very much welcome this to happen and see it as an indicator of success.

An introduction to Weave GitOps

Today we would like to talk about Weave GitOps. It has been built out in the open for about a year and brings among other things one of the most requested additions to Flux: a UI.

With Weave GitOps you

manage and view applications all in one place
easily see your continuous deployments and what is being produced via GitOps
sync your latest git commits directly from the UI
leverage Kubernetes RBAC to control permissions in the dashboard
quickly see the health of your reconciliation deployment runtime

The Weave GitOps team works very closely together with the Flux Community - many engineers on both teams are actually colleagues.

In addition to the UI Weave GitOps provides a frictionless way to get up to speed with your GitOps experience: GitOps Run. All you need to get started is a cluster and the Weave GitOps CLI. Everything else, including Flux and the Weave GitOps Dashboard will be set up automatically for you.

GitOps Run actually does more than the setup. You see changes sync almost in real time instead of the normal loop, where everything goes through a PR process, enabling you to iterate very quickly without sacrificing the GitOps pattern. The moment you are happy with the changes you create a PR just as usual. It’s the best of both worlds.

Watch this short video to see the beauty and ease of use: set up

If you are a Terraform user, you will love that the terraform-controller is integrated by default and your terraform resources will show up in the dashboard as well.

Getting Started

Using GitOps Run as shown in the video above is the easiest way to get set up. Period.

Here is an example of how to get an app deployment set up using GitOps (powered by Flux), including the dashboard.

brew install fluxcd/tap/flux
Head to podinfo and create a fork with the name podinfo-gitops-run.

Clone locally and change into the directory

export GITHUB_USER=<your github username>
# you can ignore these two commands if you already created and
# cloned your repository
git clone git@github.com:$GITHUB_USER/podinfo-gitops-run.git
cd podinfo-gitops-run

Now run the gitops command with --no-session as it’s a single user cluster which we want to use in direct mode. The port-forward points at the podinfo pod we will create later on.
```
gitops beta run ./podinfo --no-session \
--port-forward namespace=dev,resource=svc/backend,port=9898:9898
```
The other arguments denote a directory where the manifests are going to be stored and we set up port-forwarding for the application we are about to install.
During the installation process, Flux will be installed if it isn’t and you will now be asked if you want to install the GitOps dashboard. Answer yes and set a password.

Note: If you do not set a password, you won’t be able to login to the GitOps UI 😱.

Shortly after you should be able to open the dashboard. The username is admin and the password will be the one you set above.
If you check the contents of the podinfo directory, you will notice a kustomization.yaml file. Edit the resources element to list "../deploy/overlays/dev" as well. It should like below:
```
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
name: dev-podinfo
resources: [
 "../deploy/overlays/dev"
]
```

If you save the file, podinfo will be deployed and able to access it at http://localhost:9898.

There’s more: if you Ctrl-C the running “gitops” process in the terminal, you will be asked if you want to change the deployment to be in “GitOps mode”, this means that the manifests for the cluster definition and dashboard will be added as well and pushed to GitHub for you.

As you can see, Weave GitOps takes care of a lot of the repetitive tasks and heavy lifting. A beautiful way to get set up and know that Flux is doing everything behind the scenes for you.

Is there more?

There is an Enterprise version of Weave GitOps as well, so if you need professional support for everything mentioned above, you will be covered. In addition to that, you get advanced features, such as templates and GitOpsSets - these are what will enable you to create a self-service for application teams.

The Weave GitOps team is very friendly and are always happy to help and receive feedback. Just join them in the #weave-gitops channel on the Weave Users Slack.

Come and talk to us

If you have feedback to this story, let us know on Slack or on social media and if you have a story to tell yourself, come find us as well - you can also hit us up on the fluxcd.io website repository. We want to report more stories from our ecosystem and Flux success stories. Thanks in advance for reaching out!

Blog: How Flux and Pulumi give each other superpowers

Tue, 14 Feb 2023 08:30:00 +0000

Pulumi is an “Infrastructure as Code” tool that lets you specify your infrastructure as programs written in JavaScript, Python, Java, Go, .NET languages, or YAML. The Pulumi Kubernetes operator drives Pulumi from Kubernetes, so you can maintain your infrastructure by pushing commits to git and letting automation take it from there.

Recently, we added support to the operator for using Flux sources. This is a great addition to the operator, but it’s not the only way Flux and Pulumi can work together.

Below I’m going to talk about how Flux and Pulumi can be combined, and the superpowers each grants to the other.

Adding OCI support and supply chain security to Pulumi

The support for Flux sources in the Pulumi operator gives you more ways to make your Pulumi programs available to the operator. Notably, you can now package your program as an OCI image and push it to an image registry, before using it with the operator. This might be appealing if you have deployment pipelines to generate Kubernetes YAML (e.g., from Cue) or other data, before using it in a program. It’s also convenient when you’re on a platform like AWS, GCP or Azure, because these have OCI registries with useful operational features like caching, security scanning, and so on.

But I think an even better reason for using Flux is that it can verify your sources. If you use a Flux source in a Pulumi stack, you can better secure your supply chain. When you’re using an OCI repository source for example, Flux will check Cosign signatures on each image for you, and refuse to update a source that does not have a valid signature.

A more subtle security benefit of Flux sources is context-based authorization. For example, in AWS the Flux controller can take advantage of workload identity to gain access to an ECR container registry containing your sources, so that you don’t have to explicitly manage credentials.

Using Pulumi to extend the reach of Flux

With Pulumi you are not restricted to Kubernetes resources – you can create any resource defined in a provider, e.g., within AWS, GCP, and Azure, among many such platforms and services. You can write a Pulumi program in YAML, and you can declare a YAML program as a Kubernetes custom resource, making the whole chain amenable to Kubernetes Resource Model (KRM)-oriented tooling, including Flux.

For example, here’s Kubernetes YAMLs for creating an AWS EC2 instance, and a security group, with Pulumi:

---
# This is a program for creating the EC2 instance and security group
apiVersion: pulumi.com/v1
kind: Program
metadata:
 name: ec2-instance
program:
 resources:
 group:
 type: aws:ec2:SecurityGroup
 properties:
 description: Enable HTTP access
 ingress:
 - protocol: tcp
 fromPort: 80
 toPort: 80
 cidrBlocks: ["0.0.0.0/0"]
 server:
 type: aws:ec2:Instance
 properties:
 ami: ami-6869aa05
 instanceType: t2.micro
 vpcSecurityGroupIds: ${group.name}
 outputs:
 publicIp: ${server.publicIp}
 publicDns: ${server.publicDns}
---
# This stack tells the operator how to run the program
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: dev-ec2-instance
spec:
 stack: squaremo/ec2-instance/dev
 programRef:
 name: ec2-instance
 destroyOnFinalize: true
 config:
 aws:region: us-east-1

You can commit these in files in git, and have them synced by Flux. Then the Pulumi operator will take over, create the infrastructure as it’s declared, and mark the Stack object as ready. As far as Flux knows, these are just regular Kubernetes resources – but now you can bring your whole infrastructure under control!

Using Flux to simplify Kubernetes for Pulumi

Pulumi makes a huge variety of infrastructure accessible by just writing programs. In the specific context of Kubernetes, many folks will find KRM-oriented tooling and YAML files easier. Flux’s Kustomize and Helm controllers work alongside its source controller, but happily they also work in harmony with the Pulumi operator, and you can mix and match to suit yourself.

For example, you might find it useful to write all your Pulumi Program and Stack YAMLs as files in a directory for Flux to sync, rather than trying to create them in Pulumi code (or – horror – applying them by hand).

Getting started with Flux and the Pulumi operator

If you are already invested in Pulumi, it would make sense to bootstrap Flux, using Pulumi. You can use the Flux provider for Pulumi from your Pulumi program, and gain verified sources and effortless YAML syncing.

And, vice versa – if you are starting with Flux and want to expand its reach with Pulumi, you can bootstrap the Pulumi operator, using Flux, by syncing the deployment manifests in the operator’s GitHub repo:

---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
 name: pulumi-operator
 namespace: flux-system
spec:
 interval: 5m0s
 ref:
 semver: "1.11.x"
 url: https://github.com/pulumi/pulumi-kubernetes-operator
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
 name: deploy-pulumi-operator
 namespace: flux-system
spec:
 interval: 5m0s
 path: ./deploy/yaml
 prune: true
 sourceRef:
 kind: GitRepository
 name: pulumi-operator

Visit Pulumi’s “Get Started” portal to learn more about what you can accomplish with Pulumi.

Blog: GitOps Without Leaving your IDE

Wed, 28 Sep 2022 11:00:00 +0000

Welcome to the second blog post in our Flux Ecosystem category! This time we are talking about one of the Flux UIs: it’s the VS Code GitOps Extension.

If you already use VS Code, this extension will be straight up your alley: it provides an intuitive way to manage, troubleshoot and operate your Kubernetes environment following the GitOps operating model, accelerating your development lifecycle and simplifying your continuous delivery pipelines. Of course it uses Flux under the hood.

Getting Started

Installing it: It’s in the Visual Studio Code Marketplace, so if you search for it in VS Code, it’s just a click of the Install button away.

Additionally, you will need to

Optionally, if available, the extension will make use of the az tool (for Azure clusters) and docker as well.

With that out of the way, let’s get going and take the extension for a spin.

Drive everything from your IDE

Once you launch VS Code, you should see available clusters listed in the Clusters section of the GitOps extension. Now you can easily interact with the resources in each of the clusters. This makes it very straightforward to make changes in your manifests, commit and observe changes in the clusters without leaving your IDE.

The extension was designed so that you always have access to the immediate tasks and events. Turning a manifest into a Kustomization or Source? Right-click on the YAML file. View repositories, clusters, sources, kustomizations, etc. - you see them at the first glance. View GitOps Output panel with CLI command traces for diagnostics, cluster and components versions, Flux controller logs, everything you might need to debug. Enable/disable GitOps cluster operations with just a click. Reconcile Sources and Workloads demand, and much more - links to most-needed docs included.

Constantly evolving

The extension is rapidly growing new features. In 0.21.0, the team added OCI support which is supported natively in Flux. If you would like to see a video demo of this, check out this talk done by Annie Talvasto and Kingdon Barrett in the CNCF Webinar series.

In 0.22.0 basic support for Azure AKS/Arc was added. Future releases will add a new beginner-friendly UI workflow for creating complete Flux configurations using both generic Flux Source (Git, OCI, Bucket, HelmRepository) and Workload (Kustomization, HelmRelease) resources as well as Azure FluxConfig resources.

The team has begun work to transition the extension implementation from shell out commands to Javascript APIs for Kubernetes and Azure. Once that is complete, extension responsiveness and performance will improve dramatically.

Join the community

The team behind the extension loves feedback. If you like what you see, please star the extension on GitHub or leave an issue if something is missing, or send a PR if you can.

All feedback is very welcome!

Blog: How to GitOps Your Terraform

Wed, 14 Sep 2022 11:00:00 +0000

This is the first blog post in a series where we want to shine a light on projects in the Flux Ecosystem. This time it’s going to be the Terraform Controller.

If you use Terraform, you might think of it as “Infrastructure as Code” and to be separate from the concept of GitOps. Quite often we have seen debates about “Infrastructure as Code vs. GitOps”. The Terraform Controller reconciles these two worlds and lets you take advantage of the benefits of GitOps for existing Terraform resources: one source of truth, one single pane of glass and drift detection among them.

You might have resorted to using pipelines or manual deployments up until now. In this blog post we are going to show how to have your Terraform resources managed the GitOps way. Without having to convert your code at all!

What is the Terraform Controller?

The Terraform Controller is a Flux controller that can manage your Terraform resources. Although Flux runs on Kubernetes, whatever you are using Terraform for, the Flux controller can manage it. It has several features including the ability to do manual approvals or auto-approve Terraform plans, and the Terraform outputs can be set as a Kubernetes secret. It is also integrated with Terraform Cloud and Terraform Enterprise.

The benefits of using the Terraform Controller is that you are able to take advantage of GitOps for existing Terraform resources. There is drift detection of Terraform resources and it can be used as a glue for Terraform resources and Kubernetes workloads.

Terraform Controller is very versatile because it offers different modes of operation and many features which give you the integration points and control you need. Primarily it supports these use-cases:

GitOps Automation Model: Here you GitOps your Terraform resources from the provision steps to the enforcement steps, like for example a whole EKS cluster.
Hybrid GitOps Automation Model: Here you GitOps parts of your existing infrastructure resources. For example, you have an existing EKS cluster. You can choose to GitOps only its nodegroup, or its security group.

Building on this, you can make use of these features if you have a TFSTATE file:

State Enforcement: Use GitOps to enforce it, without changing anything else.
Drift Detection: Use GitOps just for drift detection, so you can decide to do things later when a drift occurs.

And there’s more: Multi-Tenancy, Plan and Manual Approve and more features on the roadmap.

Now let’s move on to how to integrate it practically!

GitOpsing your Terraform

Prerequisites

Obviously you will need a Kubernetes cluster and Flux installed. Terraform Controller will require at least Flux 0.32, which in turn needs at least Kubernetes version 1.20.6. Either use flux install or flux bootstrap as explained in the Flux documentation.

Installation

Now you need to install Terraform Controller. There are many ways to do it, check out the installation docs for more information.

One very easy way to do it is to add this HelmRelease to your bootstrap repository.

Tying in your Terraform resources

And here is where all the beauty of Terraform Controller comes in - it does all the hard work for you. All you will need to do to is

Define the source of your Terraform resources
Enable GitOps Automation

Define source

So let’s go ahead, here we define a Source controller’s source (you can pick any of GitRepository, Bucket, OCIRepository). A GitRepository entry could look like this:

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
 name: helloworld
 namespace: flux-system
spec:
 interval: 30s
 url: https://github.com/tf-controller/helloworld
 ref:
 branch: main

The GitOps Automation mode

The GitOps automation mode could be enabled by setting .spec.approvePlan=auto. In this mode, Terraform resources will be planned, and automatically applied for you. Here is a simple example you can just copy and paste.

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
 name: helloworld
 namespace: flux-system
spec:
 interval: 1m
 approvePlan: "auto"
 path: ./
 sourceRef:
 kind: GitRepository
 name: helloworld
 namespace: flux-system

Note: If you have a kustomization.yaml file (which is the case in the basic flux bootstrap use-case), make sure you add the file(s) the above manifest portions are in into the resources list.

Once you commit this to Git, you should see Terraform Controller pick this up quickly. One way to confirm is:

kubectl -n flux-system get terraforms.infra.contrib.fluxcd.io
NAME READY STATUS AGE
helloworld True No drift:
main/d9c5cc348e555526ea563fb82fc901e37de4d732 1m

Simple, wasn’t it?

What else is there?

The Terraform Controller team has been hard at work and made sure that many of the common use-cases are supported. Above we covered the automation mode, some teams might want more control, so there’s a “plan and manual apply” mode as well. You can configure it as well to just do “drift detection only”.

And there’s more, you can disable drift detection, use it with AWS EKS IRSA, interact with Terraform (set variables, manage terraform state), there’s health checks and lots of other flexibility. OCI fans will love to hear that it supports OCI Artifacts as Source as well.

It is also integrated with Terraform Cloud and Terraform Enterprise.

In past weeks the performance of the Terraform Controller has been improved significantly as well. Now the controller is greatly scalable to reconcile and provision a high volume of Terraform modules concurrently. The team has recently tested the controller with 1,500 Terraform modules.

In the most recent release (v0.12.0) new features are: custom backend support, interoperability with Flux’s Notification Controller, and supporting human-readable plan output in ConfigMap.

And there’s more to come, check out the team’s roadmap. While you are checking it out, please give feedback as well. If you are missing something, if you like it, if you want to contribute - the team is eager to hear from you.

Want to learn more?

Priyanka “Pinky” Ravi, Developer Experience Engineer at Weaveworks gave a great introduction to the Terraform Controller a couple of weeks ago. Take a look to dive into some of the finer details of this!

You are lucky, there is more to come! Pinky will give an on-demand webinar as part of the CNCF series. You can sign up for it here. It will become available on Sep 29th, 2022.

Title: How to GitOps your Terraform!

Presenter: Priyanka “Pinky” Ravi

Link: Registration here.

Flux – ecosystem

Blog: Time-based deployments with Flux Operator

How it works

A complete example

ResourceSetInputProvider Definition

ResourceSet Definition

Further reading

Blog: AI-Assisted GitOps with Flux Operator MCP Server

Bringing AI to GitOps

How It Works

Getting Started

Setting Up AI Instructions

Practical Applications

1. Quick Health Assessment

2. GitOps Pipeline Visualization

3. Cross-Cluster Comparisons

3. Root Cause Analysis

4. GitOps Operations

5. Kubernetes Operations

Security Considerations

The Future of AI-Assisted GitOps

Blog: GitHub App bootstrap with Flux Operator

Flux Operator

Bootstrap using Flux Operator and Helm

Bootstrap using Flux Operator and Terraform

GitHub App Docs

Conclusion

Blog: How to use Weave GitOps as your Flux UI

An introduction to Weave GitOps

Getting Started

Is there more?

Come and talk to us

Blog: How Flux and Pulumi give each other superpowers

Adding OCI support and supply chain security to Pulumi

Using Pulumi to extend the reach of Flux

Using Flux to simplify Kubernetes for Pulumi

Getting started with Flux and the Pulumi operator

Blog: GitOps Without Leaving your IDE

Getting Started

Drive everything from your IDE

Constantly evolving

Join the community

Blog: How to GitOps Your Terraform

What is the Terraform Controller?

GitOpsing your Terraform

Prerequisites

Installation

Tying in your Terraform resources

Define source

The GitOps Automation mode

What else is there?

Want to learn more?