kubectl applyCreate or update resources from YAML, declaratively
kubectl apply makes the cluster match the YAML you give it: it creates objects that don't exist and patches the ones that do, changing only the fields your file manages. Re-running it with no changes is safe, which is why CI pipelines and GitOps tools are built on it.
kubectl apply (-f FILE|DIR|URL | -k DIR) [-R] [--dry-run=server] [--server-side] [-n NAMESPACE]Deploy the worker from a YAML file, then see how apply reports no-op runs and real changes.
kubectlThe Kubernetes CLI.
kubectl parses each document in the files, works out its resource from apiVersion and kind (using the API's discovery data), and GETs the live object. If it doesn't exist, it POSTs it. If it does, classic client-side apply computes a three-way merge patch from the last-applied configuration (stored in the kubectl.kubernetes.io/last-applied-configuration annotation), your new file and the live object, so fields set by others (like replicas changed by an HPA) are left alone unless your file sets them; it then sends a strategic-merge PATCH. With --server-side the API server does the merge itself and tracks which manager owns each field (managedFields), reporting conflicts. Every write goes through authentication, RBAC, mutating and validating admission webhooks and schema validation, then lands in etcd. apply returns as soon as the object is stored: controllers, the scheduler and kubelets do the actual rollout afterwards.
apply only writes the desired state to the API server; controllers, the scheduler and the kubelet each watch for it and do their part.
kubectl reads the YAML, GETs the live Deployment and computes a merge patch from the last-applied annotation, your file and the live object. Then it sends one PATCH.
-f PATHFile, directory or URL to apply (repeatable; - for stdin)-k DIRBuild a kustomization directory and apply the result-RRecurse into subdirectories of -f--dry-run=serverFull server validation and admission, nothing saved--dry-run=clientOnly print what would be sent; no server checks--server-sideLet the API server merge and track field ownership--force-conflictsWith --server-side, take ownership of conflicting fields--prune -l KEY=VALDelete labelled objects no longer in the files (use with care)-o yamlPrint the resulting objects--waitWith --prune, wait for deletions to finishTreating 'deployment.apps/api configured' as 'the new version is live'apply returns once the spec is stored; the rollout may still fail on image pulls or probes.
kubectl apply -f k8s/ && kubectl rollout status deploy/api --timeout=5mMixing kubectl edit / kubectl scale with apply from GitHand edits drift from Git, and the next apply silently reverts them, or conflicts with server-side apply.
Change the YAML in Git and apply it; let only HPA own replicaskubectl create -f in a pipelinecreate fails with AlreadyExists on the second run.
kubectl apply -f (idempotent create-or-update)kubectl apply --prune -f k8s/ --allPrune deletes any matching object not in the files; a partial directory can delete production resources.
Prefer a GitOps tool or apply sets with an explicit label; always diff firstTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that validates every manifest under k8s/ (recursively) against the real API server without changing anything.
Write the commands to see what would change, then apply, then wait up to 5 minutes for the Deployment api in prod to finish rolling out.
Read this and fix it: 'strict decoding error: unknown field "spec.template.spec.containers[0].ports[0].containerport"'
Generate a Deployment manifest for nginx:1.27 with 2 replicas into ~/app/hello.yaml, check it against the API server with a server-side dry run, then apply it to the staging namespace.
kubectl applyCreate or update resources from YAML, declaratively
kubectl apply makes the cluster match the YAML you give it: it creates objects that don't exist and patches the ones that do, changing only the fields your file manages. Re-running it with no changes is safe, which is why CI pipelines and GitOps tools are built on it.
kubectl apply (-f FILE|DIR|URL | -k DIR) [-R] [--dry-run=server] [--server-side] [-n NAMESPACE]Deploy the worker from a YAML file, then see how apply reports no-op runs and real changes.
kubectlThe Kubernetes CLI.
kubectl parses each document in the files, works out its resource from apiVersion and kind (using the API's discovery data), and GETs the live object. If it doesn't exist, it POSTs it. If it does, classic client-side apply computes a three-way merge patch from the last-applied configuration (stored in the kubectl.kubernetes.io/last-applied-configuration annotation), your new file and the live object, so fields set by others (like replicas changed by an HPA) are left alone unless your file sets them; it then sends a strategic-merge PATCH. With --server-side the API server does the merge itself and tracks which manager owns each field (managedFields), reporting conflicts. Every write goes through authentication, RBAC, mutating and validating admission webhooks and schema validation, then lands in etcd. apply returns as soon as the object is stored: controllers, the scheduler and kubelets do the actual rollout afterwards.
apply only writes the desired state to the API server; controllers, the scheduler and the kubelet each watch for it and do their part.
kubectl reads the YAML, GETs the live Deployment and computes a merge patch from the last-applied annotation, your file and the live object. Then it sends one PATCH.
-f PATHFile, directory or URL to apply (repeatable; - for stdin)-k DIRBuild a kustomization directory and apply the result-RRecurse into subdirectories of -f--dry-run=serverFull server validation and admission, nothing saved--dry-run=clientOnly print what would be sent; no server checks--server-sideLet the API server merge and track field ownership--force-conflictsWith --server-side, take ownership of conflicting fields--prune -l KEY=VALDelete labelled objects no longer in the files (use with care)-o yamlPrint the resulting objects--waitWith --prune, wait for deletions to finishTreating 'deployment.apps/api configured' as 'the new version is live'apply returns once the spec is stored; the rollout may still fail on image pulls or probes.
kubectl apply -f k8s/ && kubectl rollout status deploy/api --timeout=5mMixing kubectl edit / kubectl scale with apply from GitHand edits drift from Git, and the next apply silently reverts them, or conflicts with server-side apply.
Change the YAML in Git and apply it; let only HPA own replicaskubectl create -f in a pipelinecreate fails with AlreadyExists on the second run.
kubectl apply -f (idempotent create-or-update)kubectl apply --prune -f k8s/ --allPrune deletes any matching object not in the files; a partial directory can delete production resources.
Prefer a GitOps tool or apply sets with an explicit label; always diff firstTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that validates every manifest under k8s/ (recursively) against the real API server without changing anything.
Write the commands to see what would change, then apply, then wait up to 5 minutes for the Deployment api in prod to finish rolling out.
Read this and fix it: 'strict decoding error: unknown field "spec.template.spec.containers[0].ports[0].containerport"'
Generate a Deployment manifest for nginx:1.27 with 2 replicas into ~/app/hello.yaml, check it against the API server with a server-side dry run, then apply it to the staging namespace.