Need some explaination of kubectl stdin and pipe

cat deployment.yaml | kubectl apply -f -

1kubectl apply -f - <<'YAML'
2apiVersion: v1
3kind: ConfigMap
4metadata:
5  name: app-config
6data:
7  LOG_LEVEL: info
8YAML

kubectl get pods -n demo --no-headers | awk '{print $1}'

kubectl get pods -n demo --no-headers \
| awk '/^test-/{print $1}' \ | xargs -r -I {} kubectl delete pod -n demo {} ``` Always preview selected resources first when the final command is destructive. ## Prefer Structured Output over Table Parsing Human-readable tables are convenient but brittle in automation. Use machine-friendly formats. JSONPath example: ```bash kubectl get pods -n demo -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' ``` `jq` example: ```bash kubectl get pods -n demo -o json | jq -r '.items[].metadata.name' ``` These approaches survive formatting changes better than parsing column-aligned text. ## `kubectl exec` and stdin Flags For container execution, stdin behavior is controlled by flags: - '`-i` keeps stdin open.' - '`-t` allocates a pseudo terminal.' ```bash kubectl exec -it web-7d9f8 -- sh ``` Pipe data into a command inside a pod: ```bash echo 'hello from stdin' | kubectl exec -i web-7d9f8 -- cat ``` If interactive behavior looks broken, check whether `-t` is being used in non-interactive pipeline contexts. ## Safer Script Pattern with `pipefail` In multi-step pipelines, enable strict shell mode so upstream failures are not hidden. ```bash #!/usr/bin/env bash set -euo pipefail kubectl kustomize ./overlays/staging \ | kubectl apply -f - kubectl rollout status deployment/api -n staging ``` `set -o pipefail` ensures the script fails if manifest generation fails, even when `kubectl apply` might otherwise mask the issue. ## Debugging Broken stdin Pipelines When a piped apply fails, break the flow into inspectable steps: 1. Capture generated YAML into a temp file. 2. Validate it with `kubectl apply --dry-run=client -f file`. 3. Apply once validation succeeds. ```bash kubectl kustomize ./overlays/dev > /tmp/rendered.yaml kubectl apply --dry-run=client -f /tmp/rendered.yaml kubectl apply -f /tmp/rendered.yaml ``` This isolates whether the problem is shell quoting, generator output, or Kubernetes validation. ## Context and Namespace Discipline Pipes make commands compact, but also easier to run in the wrong cluster. Guard every automation script: ```bash kubectl config current-context kubectl config view --minify --output 'jsonpath={..namespace}' ``` Set namespace explicitly in command lines where possible. Hidden defaults are a common root cause of production mistakes. ## Common Pitfalls - Forgetting `-f -` when sending manifests through stdin. - Parsing table output in automation instead of JSON or JSONPath. - Running `xargs kubectl delete` flows without previewing selected resources. - Combining `-t` with non-interactive pipelines and getting broken stdin behavior. - Omitting context and namespace checks in reusable scripts. ## Summary - Use `kubectl apply -f -` to read manifests directly from stdin. - Combine `kubectl` with shell pipes for repeatable workflow automation. - Prefer structured output formats for robust filtering. - Use `-i` and `-t` intentionally for `kubectl exec` behavior. - Add strict shell options and validation steps for safer production scripts.