As I explored Kubernetes, I quickly found it to be quite overwhelming. Managing clusters, handling configuration changes, and ensuring security felt like a complex maze. I often felt frustrated trying to keep everything consistent across different environments and struggling to monitor how applications were performing. While Kubernetes is powerful, it requires a lot of expertise and careful management. However, discovering GitOps changed everything for me. It allowed me to use Git as a single source of truth, which made my deployments more reliable and significantly reduced the operational challenges I faced.
Before moving to this let us first understand what is GitOps?
Explaining in short GitOps is a modern approach to managing and operating infrastructure and applications in the cloud using Git as the single source of truth. It builds on the principles of Infrastructure as Code (IaC), Continuous Integration/Continuous Deployment (CI/CD), and version control to automate and streamline the deployment, monitoring, and management of systems.
Getting Started: Setting Up the Environment
Before diving into the GitOps template, I needed a Kubernetes cluster. For simplicity, I opted to use Kind, a tool I’ve used numerous times before. To make it simple you can also use minikube. The command to create a new cluster is straightforward:
minikube start -p gitops
Next, I installed the Glasskube CLI, making sure I had at least version 0.16.0 installed. If you don’t have it installed, a simple command does the trick:
brew install glasskube/tap/glasskube
Use of GitOps Template
With the environment set up, I moved on to the core of the experience: using the GitOps template. The first step was to create a GitHub repository or simply fork it based on the template. The template itself was well-structured and easy to use, though it required the repository to be public initially. I found this to be a minor inconvenience but one that was easily remedied after the bootstrap process by switching the repository back to private.
The next task was to replace the placeholder repoURL in the template files with the URL of my newly created repository. This involved modifying a few lines in the following files:
bootstrap/glasskube-application.yamlbootstrap/glasskube/applicationset.yaml
While this was straightforward, it was a good reminder to be thorough in checking that all references were correctly updated. Missing even one of these could lead to issues later on.
Here let us make some changes the gitops-template comes with some sample packages already installed. They include cloud-native-pg, kube-prometheus-stack and argo-cd. While to make it more interesting I made few changes on packages. To have a real-time log for Kubernetes I added Kubetail package to the /packages directory. It was pretty simple, you can try this by adding the following configuration in the /packages/kubetail/clusterpackages.yaml
apiVersion: packages.glasskube.dev/v1alpha1
kind: ClusterPackage
metadata:
name: kubetail
spec:
packageInfo:
name: kubetail
repositoryName: glasskube
version: v0.6.0+1
Also to add any package you can do the following steps:
Create a directory of name of the package in the
/packagesThen run the following command in the terminal:
glasskube install <package_name> --dry-run -o yaml --yes > clusterpackage.yaml
That's it !!!!
This command generated the necessary YAML files, which I then committed to my Git repository. ArgoCD automatically picked up the changes, and within minutes, the kubetail was installed in my cluster. The ability to manage everything through Git not only streamlined the process but also provided a clear audit trail for every change made.
Integrating Renovate: A Proof of Concept
One aspect I was eager to try was the integration with Renovate, a tool that automates dependency updates. The GitOps template provided a basic configuration for Renovate, focusing on a regex-based approach to detect version updates in YAML files.
While the integration worked, it did have some limitations. For example, the regex approach required the name and version fields to appear in a specific order, which might not always be the case in real-world scenarios. Additionally, the current implementation only supported packages from the public Glasskube repository. Despite these limitations, the proof of concept showed that it’s possible to automate updates, albeit with some manual oversight.
I’m looking forward to future updates where a dedicated Glasskube manager inside Renovate could offer more robust support and awareness of package dependencies.
Final Steps
Now start the argo-cd UI with the following command, and signin with the initial username and password.
glasskube open argo-cd
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 --decode
Then click on the Synchronize button to SYNC all the packages and apps from your gitops template.
BOOM !!! Everything installed with GIT as a source of truth.
My experience
Overall, my experience with the GitOps template was positive. It delivered on its promise of getting ArgoCD and Glasskube up and running in a Kubernetes cluster within minutes. The template is well-thought-out and provides a solid foundation for managing a Kubernetes environment using GitOps principles.
While there were a few areas where manual intervention was necessary, these were minor and I didn’t detract from the overall experience. I’m particularly excited to see how the integration with Renovate evolves, as it holds the potential to further automate and streamline cluster management.
If you’re looking to implement GitOps in your Kubernetes environment, I highly recommend giving this template a try. It’s a great starting point, especially for those new to ArgoCD and Glasskube, and it can significantly reduce the time and effort required to get everything set up.