|
1 | 1 | # Source Controller |
2 | 2 |
|
3 | | -The main goal is to define a set of Kubernetes objects that cluster |
4 | | -admins and various automated operators can interact with to offload |
5 | | -the sources (e.g. Git and Helm repositories) registration, authentication, |
6 | | -verification and resource fetching to a dedicated controller. |
7 | | - |
8 | | -## Motivation |
9 | | - |
10 | | -Each Flux and each Helm operator mirrors the Git repositories they are |
11 | | -using, in the same way, using the same code. But other components |
12 | | -might benefit from access to the source mirrors, and Flux and the Helm |
13 | | -operator could work more in sympathy with Kubernetes by factoring it out. |
14 | | - |
15 | | -If "sources" (usually git repos, but also Helm charts and potentially |
16 | | -other things) existed in their own right as Kubernetes resources, |
17 | | -components like Flux and Helm operator could use standard Kubernetes |
18 | | -mechanisms to build on them; and, they could be managed independently |
19 | | -of the components using them. |
20 | | - |
21 | 3 | ## API Specification |
22 | 4 |
|
| 5 | +* [v1](v1/README.md) |
23 | 6 | * [v1beta2](v1beta2/README.md) |
24 | 7 | * [v1beta1](v1beta1/README.md) |
25 | | - |
26 | | -## Implementation |
27 | | - |
28 | | -The controller implementation will watch for source objects in a cluster and act on them. |
29 | | -The actions performed by the source controller could be: |
30 | | - |
31 | | -* validate source definitions |
32 | | -* authenticate to sources and validate authenticity |
33 | | -* detect source changes based on update policies (semver) |
34 | | -* fetch resources on-demand and on-a-schedule |
35 | | -* package the fetched resources into a well known format (tar.gz, yaml) |
36 | | -* store the artifacts locally |
37 | | -* make the artifacts addressable by their source identifier (sha, version, ts) |
38 | | -* make the artifacts available in-cluster to interested 3rd parties |
39 | | -* notify interested 3rd parties of source changes and availability (status conditions, events, hooks) |
40 | | - |
41 | | -## Impact to Flux |
42 | | - |
43 | | -Having a dedicated controller that manages Git repositories defined with Kubernetes custom resources would: |
44 | | - |
45 | | -* simplify Flux configuration as fluxd could subscribe to Git sources in-cluster and pull the artifacts |
46 | | -automatically without manual intervention from users to reconfigure and redeploy FLux |
47 | | -* improve the installation experience as users will not have to patch fluxd's deployment to inject |
48 | | -the HTTPS basic auth credentials, change the source URL or other Git and PGP related settings |
49 | | -* enable fluxd to compose the desired state of a cluster from multiple sources by applying all artifacts present in flux namespace |
50 | | -* enable fluxd to apply manifests coming from other sources than Git, e.g. S3 buckets |
51 | | -* allow fluxd to run under a non-root user as it wouldn't need to shell out to ssh-keygen, git or pgp |
52 | | -* enable fluxd to apply manifests coming from the most recent semver tag of a Git repository |
53 | | -* allow user to pin the cluster desired state to a specific Git commit or Git tag |
54 | | - |
55 | | -## Impact to Helm Operator |
56 | | - |
57 | | -Having a dedicated controller that manages Helm repositories and charts defined with Kubernetes custom |
58 | | -resources would: |
59 | | - |
60 | | -* simplify the Helm Operator configuration as repository and chart definitions can be re-used across |
61 | | - `HelmRelease` resources (see [fluxcd/helm-operator#142](https://github.com/fluxcd/helm-operator/issues/142)) |
62 | | -* improve the user experience as repositories requiring authentication will no longer require a |
63 | | - `repositories.yaml` import / file mount |
64 | | -* simplify the architecture of the Helm Operator as it allows the operator to work with a single |
65 | | - source type (`HelmChart`) and way of preparing and executing installations and/or upgrades |
66 | | -* allow the Helm Operator to run under a non-root user as it wouldn't need to shell out to git |
0 commit comments