There are multiple reasons and limitations with current tooling that we want to overcome.
We have abstracted all packages as custom resources and have a controller that reconciles these resources to (1) enable drift detection. Additionally, we use admission controllers (2) to validate dependencies and package configurations before they are applied to the cluster, while also working with custom resources to store and update the status of installed packages.
Genuinely interested. What problems did you have dealing with the standard reconciliation mechanism provided by ArgoCD and by k8s itself. I understand the advantage of the operator approach, but it might be hard to show the state in ArgoCD and somewhat breaks the idea of gitops.
Can we benefit your project in a more limited but agentless way? Limiting the types and CRDs we allow in k8s makes operations better, especially with the aggressive upgrade cycle that k8s already imposes.
pmig|1 year ago
We have abstracted all packages as custom resources and have a controller that reconciles these resources to (1) enable drift detection. Additionally, we use admission controllers (2) to validate dependencies and package configurations before they are applied to the cluster, while also working with custom resources to store and update the status of installed packages.
iwwr|1 year ago
Can we benefit your project in a more limited but agentless way? Limiting the types and CRDs we allow in k8s makes operations better, especially with the aggressive upgrade cycle that k8s already imposes.