Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cluster sync addendum to RFC-0001 #75

Merged
merged 2 commits into from
Jun 10, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 41 additions & 1 deletion rfcs/0001-flux-operator/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

**Creation date:** 2024-02-25

**Last update:** 2024-05-30
**Last update:** 2024-06-10

## Summary

Expand All @@ -29,6 +29,7 @@ contain all the complexity of the Flux components and their various configuratio

- Provide a declarative API for the installation and upgrade of the enterprise distribution.
- Automate patching for hotfixes and CVEs affecting the Flux controllers container images.
- Support for syncing the cluster state from Git repositories, OCI artifacts and S3-compatible storage.
- Provide first-class support for OpenShift, Azure, AWS, GCP and other marketplaces.
- Simplify the configuration of multi-tenancy lockdown on shared Kubernetes clusters.
- Provide a security-first approach to the Flux deployment and FIPS compliance.
Expand Down Expand Up @@ -178,6 +179,43 @@ Events example:
Warning UpgradePending 25s flux-operator Upgrade to latest version 2.4.0 blocked by semver range 2.3.x
```

### Sync configuration

The `.spec.sync` field is optional and specifies the Flux sync configuration.
When set, a Flux source and a Flux Kustomization are generated to sync
the cluster state with the source repository.

Sync fields:

- `kind`: The source kind, supported values are `GitRepository`, `OCIRepository` and `Bucket`.
- `url`: The URL of the source repository, can be a Git repository HTTP/S or SSH address, an OCI repository address or a Bucket endpoint.
- `ref`: The source reference, can be a Git ref name e.g. `refs/heads/main`, an OCI tag e.g. `latest` or a Bucket name.
- `path`: The path to the source directory containing the kustomize overlay or plain Kubernetes manifests to sync from.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have written a question about it in the implementation PR, but what about LayerSelector? I would rather use that than path for an oci Artifact.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LayerSelector could be added via a kustomize patch if anyone needs it, for now there is no practical use to it. The artifacts in this case are create with flux push artifact for the fleet Git repo content, so path is a must for any of this to work.

- `pullSecret`: The name of the Kubernetes secret that contains the credentials to pull the source repository. This field is optional.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whjat about the provider field? It's true that we cannot do it for git yet, but we can already have it in the rfc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provider is set from the cluster.type field, no point in duplicating it here.

- `interval`: The sync interval. This field is optional, when not set the default is `1m`.

Example:

```yaml
apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
name: flux
namespace: flux-system
spec:
sync:
kind: GitRepository
url: "https://github.com/my-org/my-fleet.git"
ref: "refs/heads/main"
path: "clusters/my-cluster"
pullSecret: "flux-system"
```

The Flux objects are created in the same namespace where the `FluxInstance` is deployed
using the namespace name as the Flux source and `Kustomization` name. The naming convention
matches the one used by `flux bootstrap` to ensure compatibility with upstream, and
to allow transitioning a bootstrapped cluster to a `FluxInstance` managed one.

## Implementation History

- 2024-05-30: Initial implementation released in flux-operator [v0.1.0](https://github.com/controlplaneio-fluxcd/flux-operator/releases/tag/v0.1.0)
Expand All @@ -187,3 +225,5 @@ Events example:
- 2024-05-31: Additional features released in flux-operator [v0.2.0](https://github.com/controlplaneio-fluxcd/flux-operator/releases/tag/v0.2.0)
- Support for persistent storage configuration with the `storage` spec field.
- Support for taking ownership of the Flux resources deployed with kubectl, Helm or the Flux CLI.
- 2024-06-04: Additional features released in flux-operator [v0.3.0](https://github.com/controlplaneio-fluxcd/flux-operator/releases/tag/v0.3.0)
- Support for disabling the reconciliation using the `fluxcd.controlplane.io/reconcile: disabled` annotation.