Not long ago, I shared how to monitor Kubernetes costs using OpenCost, Prometheus, and Grafana. In this follow-up, I want to highlight a specific feature: setting up proactive budget alerts using OpenCost and Prometheus. It’s a simple but powerful way to catch cost overruns early.

In modern DevOps workflows, GitOps has emerged as a powerful model for managing infrastructure and application deployments using Git as the single source of truth. One common challenge in GitOps is how to promote changes across environments - from staging to production - while maintaining traceability, automation, and control. In this post, we’ll explore how to implement environment promotions using GitHub Releases and Semantic Versioning (SemVer) to streamline delivery and improve reliability.

This approach is tailored for small and mid-sized teams that want to implement reliable, controlled GitOps promotions without the overhead of enterprise-scale CI/CD systems.

A while back, I wrote a blog post on creating a low-cost managed Kubernetes cluster. The solution centers around Google Kubernetes Engines’s (GKE) free zonal cluster and preemptive node pools. This allows for a very low-cost Kubernetes cluster which is useful for learning purposes or for small workloads. The same setup is in use today for me; however, over time, the GKE cluster has by default become bloated. Google have enabled by default logging, monitoring, and other features to the cluster, which is great for production workloads, but if you are looking to cut costs, then many of these features don’t make sense.

Kubernetes events offer valuable insights into the activities within your cluster, providing a comprehensive view of each resource’s status. While they’re beneficial for debugging individual resources, they often face challenges due to the absence of aggregation. This can lead to issues such as events being garbage collected, the necessity to view them promptly, difficulties in filtering and searching, and limited accessibility for other systems. The blog post explores configuring Loki with Alloy to efficiently scrape Kubernetes events and visualize them in Grafana.

Finding quality system trays for Linux can be challenging due to limited documentation and scattered resources. However, there are several great system tray options available for Linux users. This blog post highlights some of the best and most useful system trays.

With the release of Karpenter v1 we have stable Prometheus metrics, but the Grafana dashboards are not that great and there are no open source alerts. Therefore, I decided to create a monitoring-mixin that provides a set of Prometheus rules and Grafana dashboards for Karpenter. This blog post will introduce the kubernetes-autoscaling-mixin - a set of Prometheus rules and Grafana dashboards for Kubernetes autoscaling, but we will only write about Karpenter monitoring in this blog post.

The kube-prometheus-stack Helm chart, which deploys the kubernetes-mixin, is designed for standard Kubernetes setups, often pre-configured for specific cloud environments. However, these configurations are not directly compatible with k3s, a lightweight Kubernetes distribution. Since k3s lacks many of the default cloud integrations, issues arise, such as missing metrics, broken graphs, and unavailable endpoints (example issue). This blog post will guide you through adapting the kube-prometheus-stack Helm chart and the kubernetes-mixin to work seamlessly in k3s environments, ensuring functional dashboards and alerts tailored to k3s.

I’ve been running this blog for about five years, and during that time, it’s undergone several transformations. Initially, it was built with plain Markdown, HTML, and CSS. Over time, I experimented with various frameworks before finally settling on Tailwind CSS. The blog has been using Tailwind for a while now, and I’m happy with the results. In addition to Tailwind, I’ve incorporated other tools that enhance the blog’s functionality and aesthetics, such as Pygments for syntax highlighting and Medium Zoom for an interactive image zooming experience. Now that I’ve settled on a stack that I’m happy with, I thought it would be a good idea to document it. This post will cover the tools I use for my blog, including Tailwind, Pygments, Medium Zoom, and other tips & tricks.

OpenCost is an open-source tool designed to help you monitor and understand the cost of your cloud infrastructure. As a project under the Cloud Native Computing Foundation (CNCF), OpenCost offers a transparent and powerful solution for cloud cost management. It provides both a user-friendly interface for visualizing cloud costs and Prometheus metrics, enabling you to query and visualize these costs using Grafana. The popular tool KubeCost is built on top of OpenCost, offering an enhanced feature set and user experience. However, KubeCost is not open-source, and its free plan has limitations on data retention and storage. Given these constraints and a preference for consolidating data visualization within Grafana, I opted to use OpenCost. This blog post will introduce the opencost-mixin - a set of Prometheus rules and Grafana dashboards for OpenCost.

I use Ansible to manage my entire OS setup, with a playbook that installs all necessary software, sets up my dotfiles, and configures my system. This playbook can be run on a fresh installation of my OS and have my system set up exactly how I like it. Recently, I shifted from the Linux Arch AUR to go install for Go binaries, as it felt simpler and ensured up-to-date dependencies - without having to depend on the authors creating Arch AUR packaging for it. However, I still couldn’t find a way to pin packages to specific GitHub tags/releases. To solve this, I created a simple Ansible playbook to install Go binaries directly from GitHub releases, allowing me to pin and auto update the version of the Go binaries I want to install.