Replies: 5 comments
-
Great idea and insights already!
Maybe we could make use of configmap here? You can't really build a file structure but if it's only a few files, it could be an option. |
Beta Was this translation helpful? Give feedback.
-
I would really like to see this implemented. Our primary use-case is to setup all of our clusters using gitops, then use UI based tools (like keptn) to control deployments etc. So having the ability to setup projects/services/upstream git from git (and thus the k8s api) would be awesome! |
Beta Was this translation helpful? Give feedback.
-
It's a huge need for my company too, we use GitOps approach for mostly everything. I would love to see this implemented and contribute to the implementation and design. |
Beta Was this translation helpful? Give feedback.
-
Please follow this Keptn Enhancement Proposal (KEP) keptn/enhancement-proposals#67 that provides more insights into this topic as well. |
Beta Was this translation helpful? Give feedback.
-
Currently, the way Keptn manages its entities, such as projects, stages, services, by creating an internal git repository on the configuration-service. The resources, like the Shipyard file containing the sequences for a project, SLOs that are used by the lighthouse service for defining quality gates, the remediation.yaml, etc., are then stored within the internal git repository as files within the respective branches for a certain stage. If an upstream Git repo is enabled, the Keptn-internal git repo is synced with the upstream whenever a resource is created, updated, or retrieved.
This however is not a real implementation of the GitOps approach that Keptn would like to follow, and also it causes problems with regards to performance, due to the frequent communication with the upstream repository.
Therefore, I suggest to consider a solution where every Keptn entity, i.e.:
are implemented as a K8s custom resource which is then stored and managed by the Kubernetes API. This means, that if a user does not want to actually use GitOps, and therefore does not provide an upstream repository, it would be possible to manage these entities directly by using the kubectl CLI. If access to the cluster is not available, a HTTP API with CRUD endpoints for each of the implemented CRDs can be made available (this declarative API will also likely be much easier to use than our current API).
If a user does in fact would like to use GitOps, and therefore specifies an upstream repository for a project, the CRDs for the Keptn entities can be uploaded to the upstream repository. Then, a GitOps operator running inside the Keptn cluster can periodically check for changes within that repo and apply those using the K8s library. Keptn core services using those CRDs can then use the API mentioned above to retrieve the resources they need (e.g. the SLO resource for the lighthouse service). As opposed to the configuration service, this API can however easily be kept stateless since the storage of those resources is managed by the K8s API and no persistent volume is needed anymore.
Another interesting possibility is the triggering of task sequences via PRs, if those are also implemented as a Custom resource.
An open point however is how we can still support the storage and retrieval of arbitrary files that might be needed by 3rd party services. This however might also be possible without a persistent volume attached to the configuration service, if we e.g. map the file structure within a project to a mongodb collection. This collection can then also be kept in sync with an upstream repo via the gitops operator.
Beta Was this translation helpful? Give feedback.
All reactions