Open cah-hbaum opened 1 year ago
cah-hbaum
commented
1 year ago Notes from prioritization meeting 06-10-23:
flux is already optional for clusters (convenience feature)
argo was also used in the project
does this even need to be standardized?
tonifinger
commented
7 months ago I have investigated how Argo CD treats GitOps. So far I see the use of argocd as a tool for end users, as it was developed as a gitops tool for deploying k8s applications. Therefore, I propose to look at a possible standardization of argo cd from the perspective of an end user.
Acro CD as gitops needs following resources:
Maybe we could standardize the way we use these resources. In particular, how to securely store GitLab and GitHub access tokens
garloff
commented
7 months ago If this is just for the provider, we may document implementation hints and recommendations. SCS-standards on the other hand really are meant to ensure users (the provider's customers) find behavior and interfaces they can rely on being available and uniform.
tonifinger
commented
6 months ago From the users' (provider's customers) perspective, a provider could deploy gitops tools such as flux/Argo CD in the management cluster and provide restricted access to these tools for the User. This setting should be useful if a provider wants to enable the user to make use of the Cluster API to create k8s clusters themselves. Hence the User can then manage/operate its k8s clusters using his own git Repository.
Example for Argo CD: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Cluster/ and https://argocd-applicationset.readthedocs.io/en/stable/Generators-Cluster/#cluster-generator
Therefore, we should discuss about supporting the deployment of additional applications on the management cluster. A discussion on this topic has already been started in this Github project: discussions/218
Another approach would be to allow the provision of Gitops tools for the usage of the users only on the worker clusters. This would only make sense if a provider manages the useage of the Cluster API and does not allow users to use it.
cah-hbaum
commented
6 months ago In our meeting, we had a small discussion about this topic. Basically it boiled down to the Use Cases of this GitOps topic, which include:
Use Case (1) is very valid in the KaaS context, because it is right in line with the parts of an infrastructure we could define. Sadly its not advisable (or senseful) to force every CSP to use GitOps for their cluster management. I would therefore probably advise to write either a standard with "weak" wording (mostly recommendations) OR even better, write some kind of informational document that provides helpful points if a CSP wants to use GitOps. Some combination of both approaches could also be nice.
Use Case (2) isn't something we can control, since this is entirely up to a customer.
Use Case (3) is the only part that could be standardized. If a user wants to deploy their own applications in a GitOps style way, a provider could already provide a ready to go cluster with the necessary software installed (e.g. ArgoCD). I would probably keep this independent from a normal cluster, meaning a provider would need to provide e.g. "Kubernetes 1.19" and "Kubernetes 1.19 + argoCD" in their KaaS offerings. If this is feasible or if this is wanted should probably discussed in the "Team Container Meeting". Personally, I would probably create a standard, but also make most things in their only recommendations or OPT-IN, because the amount of customers using such solutions is probably not very large.
tonifinger
commented
6 months ago In our meeting, we had a small discussion about this topic. Basically it boiled down to the Use Cases of this GitOps topic, which include:
- GitOps is used by a provider to provide clusters for customers
- GitOps is used by a customer to provision their own clusters
- GitOps is used by a customer to provision their own applications
Use Case (1) is very valid in the KaaS context, because it is right in line with the parts of an infrastructure we could define. Sadly its not advisable (or senseful) to force every CSP to use GitOps for their cluster management. I would therefore probably advise to write either a standard with "weak" wording (mostly recommendations) OR even better, write some kind of informational document that provides helpful points if a CSP wants to use GitOps. Some combination of both approaches could also be nice.
Use Case (2) isn't something we can control, since this is entirely up to a customer.
Use Case (3) is the only part that could be standardized. If a user wants to deploy their own applications in a GitOps style way, a provider could already provide a ready to go cluster with the necessary software installed (e.g. ArgoCD). I would probably keep this independent from a normal cluster, meaning a provider would need to provide e.g. "Kubernetes 1.19" and "Kubernetes 1.19 + argoCD" in their KaaS offerings. If this is feasible or if this is wanted should probably discussed in the "Team Container Meeting". Personally, I would probably create a standard, but also make most things in their only recommendations or OPT-IN, because the amount of customers using such solutions is probably not very large.
As discussed in today's Team Container Meeting the use of GitOps for users should be completely in the hands of the user and the decision to use GitOps in this Use Cases should be left to the user. Therefore, of the three use cases listed in the recommendation above, only option 1 is considered.
Furthermore the moin cluster provides a reference implementation on how to "Deploy-cluster-stacks-management-cluster-using-GitOps-approach". Therefor we will focus on this reference for writing a DR.
This issue was created to provide a discussion ground for possible future standards. It is derived from #181 and on of the points not assigned any issue yet. The issue should discuss the ideas for Gitops/CI tooling, especially
Definition of Done: