Kubernetes中replace与update是否等价？Kazan滚动更新实现疑问

Great questions! Let’s break this down clearly, especially since your REST/CRUD background gives you a solid foundation to build on.

1. Kubernetes replace vs update: Are they equivalent? #

Short answer: No, they’re not equivalent—they map to different HTTP verbs and have distinct behavior, even if they can sometimes achieve similar outcomes.

Here’s the breakdown:

• replace: Maps to an HTTP PUT request. You must send the entire, complete resource definition (e.g., the full Deployment YAML/JSON structure) to the API server. The server replaces the existing resource with the one you send—any fields you omit will be reset to their default values (or removed if they don’t have defaults). This is a "full overwrite" operation.
• update: Typically maps to an HTTP PATCH request (though some older resources might use POST for specific updates). This is an incremental change—you only send the fields you want to modify (using formats like JSON Patch or Merge Patch). The server applies those changes to the existing resource without touching other fields.

Why would you use replace instead of update?

• You have the full, up-to-date resource definition handy (e.g., from a version-controlled file) and want to ensure the cluster’s state exactly matches that definition.
• Some Kubernetes client libraries (like Kazan) might expose replace as a straightforward way to push a full resource change, which aligns well with workflows like kubectl apply (though apply actually uses a mix of get, diff, and either patch or replace under the hood).
• Avoiding potential conflicts from partial updates: if you know the full state you want, replace eliminates ambiguity about which fields are being modified.

2. Using Kazan to implement rolling updates with replace_namespaced_deployment #

Since you’re aiming for a kubectl apply-like workflow with rolling updates, here’s how to approach it with Kazan’s replace_namespaced_deployment function:

Key Background #

Rolling updates for Deployments are triggered automatically when you modify the spec.template section (e.g., changing the container image, resource limits, or environment variables). Kubernetes detects the change to the Pod template hash and starts replacing old Pods with new ones according to the Deployment’s strategy settings (default is rolling update).

Step-by-Step Workflow #

1. Fetch the current Deployment from the cluster to get its current state:

   {:ok, deployment} = Kazan.Api.Apps.V1.get_namespaced_deployment("my-deployment", "my-namespace")
   

2. Modify the Deployment’s spec to your desired state. For example, updating the container image:

   updated_containers = Enum.map(deployment.spec.template.spec.containers, fn container ->
     if container.name == "my-container" do
       %{container | image: "my-image:v2"}
     else
       container
     end
   end)
   
   updated_deployment = %{deployment | spec: %{deployment.spec | template: %{deployment.spec.template | spec: %{deployment.spec.template.spec | containers: updated_containers}}}}
   

3. Use replace_namespaced_deployment to push the full updated Deployment to the API server:

   {:ok, updated_deployment} = Kazan.Api.Apps.V1.replace_namespaced_deployment(updated_deployment, "my-deployment", "my-namespace")
   

Notes #

• Make sure you’re using the latest version of the Deployment from the cluster before modifying it—otherwise, you might overwrite changes made by others (this is similar to the "optimistic concurrency" pattern; you can use the resourceVersion field to prevent conflicts).
• If you want a true kubectl apply-style merge (where only changes from your local config are applied, preserving other fields set in the cluster), you’d need to implement a diff between your local desired state and the cluster’s current state, then send a patch instead of a replace. But replace works great if you’re managing the full Deployment definition in code/version control.

内容的提问来源于stack exchange，提问作者Alex.U