Right, so you’ve got your labels set up, you’re using matchLabels to grab a nice, clean set of pods. Feels good, doesn’t it? Precise. Surgical. Then you discover fieldSelector and think, “Aha! Even more precision! I can combine the power of labels with the innate properties of the pod itself!” My friend, I am here to gently disabuse you of that notion. Field selectors are the bluntest of instruments in the Kubernetes toolkit. They’re useful, but you have to understand their profound limitations or you’ll be left scratching your head, wondering why your beautifully crafted command returned nothing.

Let’s start with the basics. While label selectors filter objects based on metadata you apply, field selectors filter objects based on fields from the object’s own specification and status. Think things like node names, pod statuses, or the dreaded restartCount.

The Core Syntax

The syntax is dead simple, which should be your first clue that we’re not dealing with a complex query language. It’s just fieldName=value or fieldName!=value. No in, no notin, no exists operator, and certainly no regular expressions.

Want to find all pods running on a specific node? This is where fieldSelector shines.

kubectl get pods --field-selector spec.nodeName=worker-node-07

This is efficient because the API server can handle this filter internally; it doesn’t have to scan through every pod and then check its labels.

The Big, Glaring Limitation

Here’s the part that trips everyone up. You cannot use a field selector and a label selector together in a logical AND operation via the API or kubectl. When you use both in a command, the API treats it as a single, combined selector under the hood, and the field selector is often only applied to a limited subset of fields.

Wait, what? Let me be direct: The fieldSelector parameter you use in kubectl or an API call is not universally supported for all resources or all fields. Its support is patchy and entirely dependent on the resource type. This isn’t a design flaw per se, but more a consequence of the API’s decentralized nature. Each resource type defines what fields are selectable.

For example, this works perfectly with Pods:

kubectl get pods --field-selector status.phase=Running

But try to use a field selector on a Deployment’s spec.replicas field? Yeah, no. Go ahead, try it. I’ll wait. See? Nothing. The Deployment resource simply doesn’t support field selectors for most of its spec fields. The API just ignores it.

The “Why” Behind the Madness

The reason for this hobbled functionality is performance. Supporting arbitrary field selection on any field for any resource would be a nightmare for the API server. It would have to fetch the entire object for every single resource of that type and then perform client-side filtering, which is the opposite of scalable. Selectable fields are typically those that are indexed within the underlying storage (like etcd), allowing for server-side filtering without a massive performance hit. This is why you can select on spec.nodeName (indexed for scheduling) and status.phase (indexed for general usability) but not on spec.containers[0].image.

The Workaround (Because Of Course There Is One)

So you need to find all pods that have the label app=monolith and are in a Pending state? You can’t just do:

# This DOES NOT work as a true AND
kubectl get pods -l app=monolith --field-selector status.phase=Pending

The result might be unpredictable depending on the API version. The reliable, if less elegant, way is to use kubectl and jq or JSONPath to do the second filter yourself on the client side.

kubectl get pods -l app=monolith -o json | jq '.items[] | select(.status.phase == "Pending")'

It’s less efficient, but it’s precise and guaranteed to work. Sometimes you just have to accept the trade-off.

Best Practices and When to Bother

Use field selectors for what they’re good for: quick, efficient queries against core, indexed status fields.

  • Node Assignment: spec.nodeName
  • Pod Status: status.phase (Running, Pending, Failed)
  • Non-Ready Pods: status.phase!=Running (though be careful, this includes Succeeded pods too!)

Don’t waste your time trying to use them for complex queries or on fields that clearly aren’t meant for it. Embrace them for the simple, slightly clunky tools they are, and reach for jq or your client’s filtering library when you need real precision. It’s not a flaw in your understanding; it’s just a rough edge in the API. Now you know, and you can work around it like a pro.