InPlace Update

    Workloads that support in-place update:

    Currently , Advanced StatefulSet and Advanced DaemonSet re-use the same code package and have similar behaviours of in-place update. In this article, we would like to introduce the usage and workflow of them.

    Note that the in-place update workflow of SidecarSet is a little different from the other workloads, such as it will not set Pod to not-ready before update. So the things we talk below do not totally go for SidecarSet.

    Once we are going to update image in a existing Pod, look at the comparation between Recreate and InPlace Update:

    In ReCreate way we have to delete the old Pod and create a new Pod:

    • Pod name and uid all changed, because they are totally different Pod objects (such as Deployment update)
    • Or Pod name may not change but uid changed, because they are still different Pod objects, althrough re-use the same name (such as StatefulSet update)
    • Node name of the Pod changed, because the new Pod is almost impossible to be scheduled to the previous node.
    • Pod IP changed, because the new Pod is almost impossible to be allocated the previous IP.

    But for InPlace way we can re-use the Pod object but only modify the fields in it, so that:

    • Avoid additional cost of scheduling, allocating IP, allocating and mounting volumes
    • When a container is in-place updating, the other containers in Pod will not be affected and remain running.

    The update type in Kruise workloads is named , which tells Kruise to update Pods in-place as possible, and it should go back to ReCreate Update if impossible.

    What changes does it consider to be possilble to in-place update?

    1. Update spec.template.metadata.* in workloads, such as labels and annotations, Kruise will only update the metadata to existing Pods without recreate them.
    2. Update spec.template.spec.containers[x].image in workloads, Kruise will in-place update the container image in Pods without recreate them.
    3. Since Kruise v1.0 (including v1.0 alpha/beta), update spec.template.metadata.labels/annotations and there exists container env from the changed labels/annotations, Kruise will in-place update them to renew the env value in containers.

    Take the CloneSet YAML below as an example:

    1. Modify app-image:v1 image, will trigger in-place update.
    2. Modify the value of app-config in annotations, will trigger in-place update (Read the Requirements below).
    3. Directly modify the value of APP_NAME in env or add a new env, will trigger recreate update.

    You can see the whole workflow of in-place update below (you may need to right click and open it in a new tab):

    To use InPlace Update for env from metadata, you have to enable kruise-daemon (defaults to be enabled) and feature-gate when install or upgrade Kruise chart.