Feat/cluster gitops #47
Conversation
Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Kurt Garloff <[email protected]>
| Cluster-admin credentials need to be provided to the owners of the cluster. | ||
| The current thinking is to have a public key included in the git repo; | ||
| the cluster-admin credentials for the created cluster would be encrypted | ||
| with this public key and can then be published. (Would still use https | ||
| to ensure that these are the true credentials.) Only the owner(s) of | ||
| the private key can decrypt the credentials. |
There was a problem hiding this comment.
https://github.com/bitnami-labs/sealed-secrets may be worth looking at for this
There was a problem hiding this comment.
Same for SOPS. Flux also has builtin support for it: https://fluxcd.io/docs/guides/mozilla-sops/
| ## Implementation thoughts | ||
|
|
||
| The reconciliation loop would roughly look like this: | ||
| 1. Get the latest clusters from git (via a regular check or an event) |
There was a problem hiding this comment.
This should be done by something like fluxcd, shouldn't it?
|
|
||
| The reconciliation loop would roughly look like this: | ||
| 1. Get the latest clusters from git (via a regular check or an event) | ||
| 1. Per cluster |
There was a problem hiding this comment.
I'm not sure what (and why) exactly is needed here beyond what already happens when one applies a cluster resource.
In my mind, the workflow would look like: "install fluxcd, register git repository, put cluster manifests in there, done", so this looks very complex. Am I missing anything?
|
I think this topic also is tightly related to what the general user experience should look like when provisioning cloud resources (be it VM instances, storage buckets or Kubernetes clusters). From a user perspective, IMHO a single, consistent API for all resources would be best, like most big cloud providers have already. |
Signed-off-by: Kurt Garloff <[email protected]>
garloff
added
the
Container
|
|
||
| * Can this be integrated into capo or do we really need to create a loop around it? | ||
|
|
||
| * On errors in this loop, we would move to the next cluster. However, how do we handle error reporting? |
There was a problem hiding this comment.
on fluxcd: it happen independent on every cluster on the same time (if you have not set an branch, tag (semver parsing included), or gitrepo for each cluster) ...
fluxcd has metrics, we use prometheus to get them and fire alerts, if something does not work.
|
Is this still relevant? I will close this PR if nothing happens by July 31st. |
No description provided.