I am learning Kubernetes recently, and I am not very clear about the difference between "kubectl apply" and "kubectl replace". Is there any situation that we can only use one of them?
The command set kubectl apply is used at a terminal's command-line window to create or modify Kubernetes resources defined in a manifest file. This is called a declarative usage. The state of the resource is declared in the manifest file, then kubectl apply is used to implement that state.
It's really important to remember that technically there isn't an inverse to kubectl apply . This is because of how k8s works, it converges desired state against current state. By running apply , you are telling the cluster to "make it look like this".
You can use kubectl set to make changes to an object's image , resources (compute resource such as CPU and memory), or selector fields. The kubectl set image command updates the nginx image of the Deployment's Pods one at a time. You can use kubectl apply to update a resource by applying a new or updated configuration.
Kubectl doesn't have a direct way of restarting individual Pods. Pods are meant to stay running until they're replaced as part of your deployment routine. This is usually when you release a new version of your container image.
I have written up a thorough explanation of the differences between apply, replace, and patch: Kubernetes Apply vs. Replace vs. Patch. It includes an explanation that the current top-ranked answer to this question is wrong.
Briefly, kubectl apply
uses the provided spec to create a resource if it does not exist and update, i.e., patch, it if it does. The spec provided to apply
need only contain the required parts of a spec, when creating a resource the API will use defaults for the rest and when updating a resource it will use its current values.
The kubectl replace
completely replaces the existing resource with the one defined by the provided spec. replace
wants a complete spec as input, including read-only properties supplied by the API like .metadata.resourceVersion
, .spec.nodeName
for pods, .spec.clusterIP
for services, and .secrets
for service accounts. kubectl
has some internal tricks to help you get that right, but typically the use case for replace
is getting a resource spec, changing a property, and then using that changed, complete spec to replace the existing resource.
The kubectl replace
command has a --force
option which actually does not use the replace, i.e., PUT
, API endpoint. It forcibly deletes (DELETE
) and then recreates, (POST
) the resource using the provided spec.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With