replacePods gives you the option to exchange an already running or just deployed pod with a modified version. This is especially useful if you:
- Need to configure or disable an option on a pod which is not configurable via your helm chart or manifests
- Do not want to use DevSpace for your pipeline and instead only want to use DevSpace for development
- Want to debug a setup in an already deployed app by exchanging a single pod temporarily with modifications
Each entry that you specify under
dev.replacePods will tell DevSpace to search for a pod that should be replaced with the given configuration. If DevSpace finds a pod to replace, it does the following things:
- Copy the pod.metadata and pod.spec of the already running pod
- Scale down the owning ReplicaSet, Deployment or StatefulSet replicas to 0
- Apply the patches to the copied pod
- Create the copied pod in the cluster
dev part of DevSpace, replacing pods is the first step that is executed, which means that all other services such as port-forwarding, sync, log streaming or terminal forwarding will wait until DevSpace has either replaced the pods or already found replaced pods. The services will then target the newly created patched pod instead of the old one.
DevSpace will automatically recognize changes to the parent Deployment, ReplicaSet or StatefulSet and apply them to the replaced pod automatically in the next run.
The following config options are needed to determine the container which should be replaced:
imageSelector option expects a string that specifies an image (e.g.
my-registry.com/lib/my-image:tag) to select a target pod and container with. The newest running pod that has a container which matches this image will be selected by DevSpace.
In addition, you can also reference images from the
images section in the
- If the image in
images.*.image, DevSpace will automatically append the latest built tag during runtime to the
- You can also let DevSpace resolve the target image and tag by using the helpers
imageName option expects a string with the name of an image from the
images section of the
imageName tells DevSpace to select the container based on the referenced image that was last built using DevSpace.
You can convert a value in
imageSelector by converting the value of
image(my-image):tag(my-image). For example, the image name
imageName: my-image would be equal to the image selector:
imageSelector: image(my-image):tag(my-image). We encourage people to prefer
imageSelector instead of
imageSelector is a lot more flexible and you can also select images that are not defined in
You can also select an image from a dependency with
labelSelector option expects a key-value map of strings with Kubernetes labels. This can be used to select the correct target pod with labels instead of the image name like
imageName. If the pod you want to select has multiple containers, make sure to use
containerName as well.
labelSelectorwould select the pod created for the component deployment
containerName option expects a string with a container name. This option is used to decide which container should be selected when using the
labelSelector option because
labelSelector selects a pod and a pod can have multiple containers.
containerName option is not required if the pod you are selecting using
labelSelector has only one container.
namespace option expects a string with a Kubernetes namespace used to select the container from.
It is generally not needed (nor recommended) to specify the
namespace option because by default, DevSpace uses the default namespace of your current kube-context which is usually the one that has been used to deploy your containers to.
replaceImage expects a string with the new image name (inclusive tag) that should be used for the selected pod. For example:
replaceImage: my-repo/my-debug-image:1.0. In addition, DevSpace will also replace the following things:
- registry.url/repo/name that corresponds to a
images.*.image, will be rewritten to
- image(image-key) that corresponds to a
images.*key, will be rewritten to
- tag(image-key) that corresponds to a
images.*key, will be rewritten to
patches define more generic patches that should be applied to the pod. You can basically modify anything in the pod here. Patch functionality follows JSON Patch(RFC) semantics, as implemented by the yaml-patch library.
patches option expects a patch object which consists of the following properties:
opstating the patch operation (possible values:
pathstating a jsonpath or a xpath within the pod (e.g.
valuestating an arbitrary value used by the operation (e.g. a string, an integer, a boolean, a yaml object)
op: add only for arrays
op: add only works as expected when
path points to an array value. Using
op: add to add properties to an object (e.g.
metadata.annotations) will not work and instead replace all existing properties.
When you want to define a
path that contains an array (e.g.
spec.containers), you have two options:
- Use the index of the array item you want to patch, e.g.
- Use a property selector matching the array item(s) you want to patch, e.g.
Using a property selector is often better because it is more resilient and will not cause any issues even if the order of an array's items is changed later on. A property selector is also able to select multiple array items if all of them have the same value for this property.
Value For Replace / Add
If you use the
value is a mandatory property.
value is defined, the new value must provide the correct type to be used when adding or replacing the existing value found under
path using the newly provided
value, e.g. an array must be replaced with an array.
If you want to reset replaced pods and revert the cluster state to before, you can run