Skaffold’s resource selector lets you target specific Kubernetes objects for deployment, bypassing the default behavior of deploying everything in your manifests.
Let’s see it in action. Imagine you have a Kubernetes deployment named my-app and a service named my-service in your k8s/ directory. Normally, skaffold dev would deploy both.
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx:latest
ports:
- containerPort: 80
---
# k8s/service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
If you only want to deploy the my-app deployment without touching my-service, you’d use the --resource-filter flag like this:
skaffold dev --resource-filter=deployment/my-app
This command tells Skaffold to only consider resources matching kind/name. In this case, it’s a deployment with the name my-app. Anything else in your manifest directory will be ignored for this specific Skaffold command.
The problem Skaffold’s resource selector solves is managing complexity in larger projects or during iterative development. When you have dozens or even hundreds of Kubernetes objects defined across multiple files, deploying everything every time becomes slow and error-prone. You might be working on a single microservice and only want to redeploy that specific deployment and its associated service, not the entire backend infrastructure.
Here’s how it works internally: Skaffold parses all your Kubernetes manifests. For each manifest, it extracts the apiVersion, kind, and metadata.name. When you provide a resource filter like deployment/my-app, Skaffold builds an internal allowlist. It then iterates through all the parsed resources and only proceeds with deploying, updating, or deleting those that match an entry in the allowlist.
You can specify multiple resources in a single filter, separated by commas:
skaffold dev --resource-filter=deployment/my-app,service/my-service
You can also filter by kind alone, which will target all resources of that kind:
skaffold dev --resource-filter=deployment
This would deploy all Deployment objects found in your manifests.
The resource-filter flag is incredibly powerful for fine-grained control. It’s not just about deploying; it also affects skaffold delete, skaffold apply, and skaffold render. If you run skaffold delete --resource-filter=deployment/my-app, only that specific deployment will be deleted. This prevents accidental deletion of other critical components.
The underlying mechanism uses a simple string matching against the kind and metadata.name of each Kubernetes object. The format is always kind/name. If you omit the name, it defaults to matching all objects of that kind.
This capability is particularly useful in CI/CD pipelines where you might want to deploy only the specific services that have changed or are part of a targeted release. Instead of a monolithic deployment step, you can orchestrate selective updates.
One way to think about the resource selector is that it acts as a gatekeeper for Skaffold’s core operations. By default, Skaffold wants to manage everything it finds. The --resource-filter flag tells Skaffold, "No, for this particular run, I only care about these specific things." It’s a declarative way to narrow the scope of Skaffold’s actions without modifying your Kubernetes manifests themselves, which is crucial for maintaining a consistent base set of manifests while enabling flexible deployment strategies.
If you’re filtering by kind, like deployment, and you have multiple deployments (deployment/frontend, deployment/backend), they will all be included because they match the deployment kind. If you want to be more specific, you must include the name, e.g., deployment/frontend,deployment/backend.
After successfully deploying specific resources, you might then want to explore how Skaffold handles custom resource definitions (CRDs) and their associated objects.