Watch vs Poll

Kubernetes provides two approaches to track resource changes: polling with repeated get or list calls, and watching with a persistent streaming connection. Watching is almost always the better choice.

Polling Drawbacks

Polling repeatedly queries the API server at fixed intervals. This wastes bandwidth, increases API server load, and introduces delay between the event and your detection of it:

# Polling approach: misses events between intervals
while true; do
  kubectl get pods -l app=myapp -o wide
  sleep 10
done

Using kubectl --watch

The --watch or -w flag opens a streaming connection that delivers changes in real time:

# Watch all pod changes in real time
kubectl get pods --watch

# Watch a specific deployment
kubectl get deployment myapp --watch

# Watch with output formatting
kubectl get pods -o wide --watch

# Watch events as they occur
kubectl get events --watch

# Watch only pods matching a label
kubectl get pods -l app=myapp -w

Resource Versions

Every Kubernetes resource has a resourceVersion field that increments on change. Watches use this to track state:

# Get current resource version
kubectl get pods myapp -o jsonpath='{.metadata.resourceVersion}'

# Start watching from a specific resource version
kubectl get pods --watch --resource-version=48291

When a watch connection drops, the client reconnects using the last known resourceVersion to avoid missing events. If the resource version is too old, the API server returns a 410 Gone error, and the client must re-list.

Practical Watch Patterns

# Watch for pod failures
kubectl get pods --watch | grep -v Running

# Monitor rollout progress
kubectl rollout status deployment/myapp --watch

# Watch node conditions
kubectl get nodes --watch

# Combine with jsonpath for specific fields
kubectl get pods -o jsonpath='{.metadata.name} {.status.phase}' --watch

Use --watch for interactive monitoring and informers for programmatic automation.