kubectl Parity

xcsh applies F5 Distributed Cloud resource manifests; it is not a Kubernetes client. The Action adopts kubectl’s useful non-interactive, file-oriented workflow while keeping XC authentication and API semantics explicit. Every operation executes programmatically without an LLM turn.

kubectl behavior	xcsh Action behavior	Important difference
kubectl apply -f creates or patches declared objects	operation: apply creates, updates, or preserves each XC manifest	Client-side desired/live comparison; no field manager, server-side apply, prune, or Kustomize
kubectl create -f creates declared objects	operation: create fails if a resource already exists	XC resource kinds and API paths replace Kubernetes discovery
kubectl replace -f replaces existing objects	operation: update fails if a resource is missing	Named update to match the XC API; no force delete-and-recreate mode
kubectl get -f or get TYPE NAME reads objects	operation: get accepts manifests or resource-kind with optional resource-name	No selectors, watches, custom columns, or Kubernetes API groups
kubectl delete -f or delete TYPE NAME deletes objects	operation: delete accepts either identity form and never prompts	No grace period, cascade policy, force deletion, selector, or wait flag
kubectl diff -f compares desired and live state	operation: diff reports new, different, or identical resources and sets changed	A difference is a successful report, not exit code 1; use Action outputs for gates
kubectl ... --dry-run=client validates locally	dry-run: client calculates create, update, apply, or delete without mutation	Server-side dry-run is not available
kubectl get -o yaml can be adapted as an export	operation: export emits reusable XC manifests	Export removes live-only fields and has no direct kubectl command equivalent

Common file behavior

• files may contain repeated JSON or YAML paths, directories, and include globs.
• JSON arrays and multi-document YAML files may contain multiple resource manifests.
• recursive: true maps to the intent of kubectl’s recursive -R traversal.
• namespace overrides manifest namespaces like kubectl -n, but it selects an XC namespace.
• manifest supplies inline JSON or YAML without shell interpolation or standard-input piping.
• The Action does not fetch -f URLs or accept -; commit the manifest or use manifest.
• Batch manifests are prevalidated before network operations, preventing a partial batch when one document is invalid.

Authentication model

kubectl normally selects credentials and a cluster through kubeconfig contexts. xcsh uses a direct CI environment contract:

XCSH_API_URL
XCSH_API_TOKEN
XCSH_NAMESPACE

No kubeconfig or Kubernetes context is read, and no AI provider credential is required.

Intentionally unsupported features

• Kustomize and generators
• Label or field selectors and selector-based deletion
• Pruning and apply-set tracking
• Server-side apply, field managers, and conflict forcing
• Server-side dry-run
• Kubernetes discovery, kubeconfig contexts, impersonation, and watches
• Delete grace periods, cascading policies, and force deletion

Parity describes workflow intent

xcsh does not emulate Kubernetes storage or reconciliation semantics. The comparison explains familiar command behavior while the F5 Distributed Cloud API remains the authority for resources and updates.