5 ms·
Show HN: GitOps Template for Kubernetes
Hello HN, we’re Philip Louis from Glasskube (https://github.com/glasskube/glasskube https://github.com/glasskube/glasskube). We are working on a package manager for Kubernetes to simplify the packaging of complex applications with multiple dependencies, ensuring they are installed and kept up-to-date across multiple Kubernetes clusters.
Nowadays, it is best practice to use Git as a revision control system for your Kubernetes configurations. Update automation workflows like Renovate or Dependabot can create pull requests for new versions of Docker images and Helm charts, but ensuring these new package versions work is still a manual task. By using the central (or a private) Glasskube repository (https://github.com/glasskube/packages https://github.com/glasskube/packages) together with our Renovate integration (https://docs.renovatebot.com/modules/manager/glasskube/ https://docs.renovatebot.com/modules/manager/glasskube/), you can ensure that new package versions will run through our Minikube-based CI workflows before they get published—similar to how the Homebrew core tap works. We’ve just introduced readiness checks for manifest-based deployments and utilize the flux-helm-controller to wait for a Helm release to succeed.
Dependencies are resolved by our package controller. These dependencies can either be cluster-scoped (installed in the recommended namespace, e.g., operators wird CRDs) or namespace-scoped components of a package (e.g., a database or Redis cache). In such cases, we will prefix resources with the dependent package name to ensure multiple packages can use the same dependencies without naming conflicts (we use Kustomize on a virtual filesystem for this).
Glasskube packages can currently be Helm charts (from an OCI or Helm repository) or manifests, which are mostly built using Kustomize’s overlay approach.
Since neither the overlay approach (using Kustomize) nor Helm’s limited templating functionality will help us and other Kubernetes users scale to more complex packages, we are considering creating a more programmatic approach to package creation, similar to Timoni. Currently, KCL is our frontrunner (https://github.com/glasskube/glasskube/discussions/1018 https://github.com/glasskube/glasskube/discussions/1018), as it already integrates well with the Kubernetes ecosystem.
We would appreciate if you give our GitOps template a try. It also works work existing Kubernetes clusters if just want to use GitOps for some applications. Just make sure that the argocd and glasskube-system namespaces are not yet in use. See: https://github.com/glasskube/gitops-template/ https://github.com/glasskube/gitops-template/
- vanillax 2y ago" It also works work existing Kubernetes clusters if just want to use GitOps for some applications. Just make sure that the argocd and glasskube-system namespaces are not yet in use. See: https://github.com/glasskube/gitops-template/ https://github.com/glasskube/gitops-template/ " I assume this statement is for running this? glasskube bootstrap git --url <your-repo> --username <org-or-username> --token <your-token> I think I'd like to understand what the argo cd / git ops template is and how its different than argocd autopilot. Maybe some pictures of how argo is deploying apps. Etc.
- linkdd 2y agoIIUC, it's basically "manage your Glasskube packages from Git, thanks to ArgoCD". The `glasskube install` command does a bunch of stuff that ends up as resources in your Kubernetes cluster, that are then interpreted by the Glasskube operator. The "Gitops template" make use of ArgoCD and Git to do what `glasskube install` would have done.
- pmig 2y agoThanks linkdd. Exactly Glasskube in "GitOps mode" will output these package custom resources as yaml so you can commit them to git and argo pulls these resources from git into the cluster.
- hadlock 2y agoThanks. It sounds more like glasskube is a plugin for ArgoCD IIUC I am not super thrilled about critical applications like Argo getting a plethora of plugins, otherwise we end up looping back to Jenkins and plugin hell
- linkdd 2y agoOff-topic: To be honest, after trying almost all the CI/CD offerings out there, CircleCI, Github Actions, Gitlab CI, Travis, etc... I've started to believe that none of them actually did it better than Jenkins (despite all its flaws). On-topic: Glasskube isn't really an ArgoCD plugin as it can work standalone, but in 2024, can you really propose a package manager for k8s without having some integration with ArgoCD and GitOps in general? If you want to migrate, having interoperability between the tools can make the process smoother. And if you don't want to migrate and still benefit from a centralized, curated, audited repository of packages for Kubernetes so that your "Powered by ArgoCD" GitOps are easier to manage, that's what the GitOps template propose. In Debian, you can just `apt install <that big thing i don't want to write a deploy script for>`. Imagine doing that with the usual big operators you want in your cluster (cert-manager, a hashicorp vault operator, istio or nginx ingress controller or envoy or ...)