Operators

Right, so you’ve got your cluster humming along, and you’ve probably realized that kubectl get pods,svc,deploy is only the beginning. The real magic—and complexity—of Kubernetes is that you can teach it new tricks. You can extend its API to understand what a “PostgreSQL cluster” or a “Kafka topic” is. This is where Operators and their trusty sidekicks, Custom Resource Definitions (CRDs), come in. Think of a CRD as the blueprint for a new type of object you want Kubernetes to manage, and the Operator as the brains that knows how to actually do the managing. It’s a control loop that watches your custom objects and takes action to make the real world match what you’ve specified.

Right, so you’ve got your CRD defined. It’s a beautiful spec, full of hope and YAML. But it just sits there. It’s like building a car with no engine. The CRD is the chassis and body; the controller is the engine that makes it go. And when it comes to building controllers in Go, controller-runtime is the machine shop where you forge that engine. It’s the core library that Kubebuilder and the Operator SDK use to do the heavy lifting. Think of Kubebuilder as the fancy, pre-fab garage—it gets you started fast. But to really understand what’s going on under the hood, you need to know controller-runtime.

Right, so you’ve decided to build an Operator. Good for you. You’ve outgrown Helm charts and you’re tired of manually kubectl apply-ing a sequence of YAML files to get your stateful, complex application running. You want to encode your operational knowledge directly into Kubernetes itself. This is where the real magic happens, and kubebuilder is the wand we’re going to use. It’s not the only option, but it’s the one that has become the de facto standard, built on top of the same libraries the Kubernetes API server itself uses. Think of it as getting the blueprints from the architects.

Right, so you’ve decided to build an Operator. Welcome to the club. We’ve moved past the philosophical debate of “should you?” and landed squarely in the “how the hell do you?” phase. The Operator SDK is your power tool for this job. It doesn’t just generate a skeleton; it gives you a full-blown exoskeleton, complete with best practices and structure baked in. Think of it as scaffold new-project but for the incredibly specific world of Kubernetes automation. Let’s get our hands dirty.

Right, so you’ve built a basic Operator. It can install your app. Pat yourself on the back, that’s a solid first step. But let’s be honest: if your Operator just runs a kubectl apply and then stares blankly into space, you’ve basically just automated a single, slightly more complicated kubectl command. The real magic—the reason we bother with this whole song and dance—is when your Operator starts to manage the application’s lifecycle, not just install it. This is where the Operator Maturity Model comes in. Think of it as a ladder, and we’re climbing out of the “basic script” basement and into the penthouse of full, hands-off automation.

Alright, let’s get our hands dirty. You’ve defined your fancy Custom Resource (CR) with a Custom Resource Definition (CRD). It’s sitting there in your cluster, a beautiful, empty JSON-shaped promise. But right now, it’s about as useful as a car without an engine. It looks like a car, you can describe the car you want, but turning the key does absolutely nothing. That’s where the Operator Pattern comes in. It’s the engine. More precisely, it’s the controller that acts as the engine for your CR. The core idea is gloriously simple, and it’s the same pattern that makes all of Kubernetes work: reconcile desired state with observed state.

Right, so you’ve got your Custom Resource Definition (CRD) YAML open, and you’ve defined your spec and status structs. You’re feeling pretty good. You’re basically an API designer now. But if you just stop there and kubectl apply this thing, you’re signing up for a world of pain. You’ll have a fancy new resource that accepts anything—literally anything—thrown into its spec. A malformed configuration, a string where an integer should be, a nested object that’s seven levels deep for no reason. It’s the Kubernetes equivalent of leaving your front door wide open with a sign that says “Please Make Sensible Choices.”

Right, so you’ve got Kubernetes. It’s brilliant. It knows how to run Deployments, Services, Pods—the whole gang. But what if you need it to know about something else? Something specific to your company’s bizarrely complex and beautiful internal architecture? You don’t just want to run a pod; you want to tell Kubernetes, “Hey, I need a DatabaseCluster with 3 replicas, encrypted storage, and a weekly backup to this S3 bucket.”

Right, so you’ve got your JSONB document. It’s a beautiful, nested snowflake, perfect and pristine. And now you need to change it. Of course you do. Data isn’t a museum exhibit; it’s a living, breathing, frequently-misconfigured mess that needs constant tweaking. Let’s talk about how to perform surgery on these JSONB structures without leaving a bloody mess everywhere. The workhorse here is jsonb_set(). Don’t let the simple name fool you; it’s deceptively powerful and, like most powerful things, easy to misuse. Its job is to replace or set the value at a specified path.

Right, so you’ve got all this lovely JSONB data sitting in your columns, and you’re probably thinking, “Great, I can query it. But how do I make it?” Because sometimes you need to assemble your own JSON structures on the fly, either to return from an API, feed into another system, or just to show off. That’s where jsonb_agg() and jsonb_build_object() come in. They’re your power tools for constructing JSON directly within a SQL statement, saving you from the nightmare of string concatenation (a path that leads only to madness and escaping errors).

Alright, let’s talk about jsonpath. You’ve probably been using the -> and ->> operators to navigate your JSONB data, and they’re great for simple, straightforward paths. But what happens when your data structure gets more complex, or you need to do something more powerful, like filtering for elements within an array based on a condition? You start writing these monstrous, nested SQL expressions that are a pain to write and a nightmare to read.

Right, let’s talk about making your JSONB queries not just work, but scream. You’ve loaded up a table with a mountain of JSON documents, and you’re running WHERE data @> '{"status": "published"}'. It’s fast at first, but as your data grows, it starts to feel like wading through molasses. You’ve heard about GIN indexes, the workhorse for JSONB, but then you’re hit with a choice: jsonb_ops or jsonb_path_ops? It’s not just academic; picking the wrong one is like showing up to a Formula 1 race with a go-kart engine.

Right, let’s talk about JSONB operators. This is where you stop just storing JSON and start actually using it. Forget the clunky, string-based horror of json_extract_path_text or whatever your previous database tried to sell you. PostgreSQL gives you a proper set of tools that feel, well, like they belong in a database. They’re the difference between poking your data with a stick and wielding a lightsaber. We’ll break them down into two camps: the path navigators (who get you the data) and the existence checkers (who tell you if something’s there).

Right, let’s settle this. You’ve probably already been told that jsonb is the one you should use 99.9% of the time. You nod, you move on. But I know you. You’re the kind of person who needs to know why. Because if you don’t, that 0.1% case will sneak up and bite you in production at 3 AM on a Sunday. So let’s get our hands dirty. The core difference isn’t about what they store—they both store perfectly valid JSON. It’s about how they store it. The json type stores an exact, whitespace-and-all copy of the text you put in. It’s a glorified text field with syntax validation. Need to preserve the exact textual representation for legal reasons or because some external system is ridiculously fussy? Fine, use json. For everyone else, read on.