One of possible way to customize the Kubernetes cluster is to use Operators. They extend Kubernetes capabilities by automating the lifecycle management of applications beyond what’s natively supported. This process is powered by Custom Resource Definitions (CRDs) and Custom Resources (CRs). CRDs allow you to define your own API objects, while CRs are the instances of these definitions.

kubectl-modify-secrets allows user to directly modify the secret without worrying about base64 encoding/decoding

Kubectl plugin managing sessions

Manage Kubernetes ingress traffic with Cloudflare Tunnels via the Gateway API.

kcp is a Kubernetes-like control plane focusing on:

- A control plane for many independent, isolated “clusters” known as workspaces
- Enabling API service providers to offer APIs centrally using multi-tenant operators
- Easy API consumption for users in their workspaces

kcp can be a building block for SaaS service providers who need a massively multi-tenant platform to offer services to a large number of fully isolated tenants using Kubernetes-native APIs. The goal is to be useful to cloud providers as well as enterprise IT departments offering APIs within their company.

Have you ever wished your shell noscripts could be faster, more portable, and secure ? Bunster brings this to life by transforming your shell noscripts into efficient, standalone binaries that are easy to distribute and deploy across platforms (only unix is supported at the moment).

Unlike other tools, Bunster doesn’t just wrap your noscripts in a binary—it compiles them down to efficient native machine code, leveraging the powerful Go toolchain. This ensures performance, portability, and robustness.

Technically speaking, Bunster in fact is a shell-to-Go Transpiler that generates Go source out of your noscripts. Then, optionally uses the Go Toolchain to compile the code to an executable program.

Bunster targets bash noscripts in particular. The current syntax and features are all inherited from bash. additional shells will be supported as soon as we release v1.

Static code analysis engine to find security issues in code.

Due to the lack of official guidelines for structuring larger Terraform projects, teams often face challenges like waiting for state locks and slow apply times. This post presents a scalable Terraform project structure designed to address these challenges.

TerraSchema (or terraschema) is a CLI tool which scans Terraform configuration (.tf) files, parses a list of variables along with their type and validation rules, and converts them to a schema which complies with JSON Schema Draft-07.

Back in Alerts Are Fundamentally Messy, I made the point that the events we monitor are often fuzzy and uncertain. To make a distinction between what is valid or invalid as an event, context is needed, and since context doesn’t tend to exist within a metric, humans go around and validate alerts to add it. As such, humans are part of the alerting loop, and alerts can be framed as devices used to redirect our attention.

In this post, I want to drive this concept a bit further. Rather than focusing the thinking on the events that result in alerts, I want to switch the lens with which we look at the system and center it on the operators who get the message, and on how we can restructure our alerting to play these roles better.

In this post, I will highlight some crucial Kubernetes best practices. They are from my years of experience with Kubernetes in production. Think of this as the curated “Kubernetes cheat sheet” you wish you had from Day 1. Buckle up; it’s going to be an exciting ride.

Learn how to handle PostgreSQL migrations in Kubernetes using Helm hooks, preventing deadlocks and automating rollback with practical code examples.

The Flux Operator is a Kubernetes CRD controller that manages the lifecycle of CNCF Flux CD and the ControlPlane enterprise distribution.