Add ability to re-inject resources that were already injected #1970
Comments
|
Hey @kamushadenes, thanks for reporting this. The issue that you're running into is described by this pre-inject warning: It looks like you're trying to inject a YAML spec that already includes a linkerd-proxy sidecar, so inject skips it rather than overwriting. The fix is to use your original, un-injected YAML spec, inject with linkerd 2.1, and apply. That said, it does seem like this would be a common use case for upgrading. Something like: We should consider modifying the inject behavior to allow it to mutate resources that have already been injected. That might be a good thing to tackle as part of #1748. |
|
@klingerf thanks for the quick response. Manually setting the image to stable-2.1.0 should work? |
|
That would typically work, but there was a breaking name change between 2.0 and 2.1, unfortunately. See the 2.1 upgrade notice here for more info: https://linkerd.io/2/upgrade/index.html#upgrade-notice-stable-2-1-0 |
|
Let's use this issue to track adding support for re-injecting resources that have already been injected with linkerd. On a related note, we could consider adding support for |
klingerf
changed the title
|
How would folks feel if |
|
@alpeb could you explain a little bit more? I'm having a tough time visualizing the use cases and interaction. In particular, I'm wondering how the output looks (the auditability of |
|
@grampelberg both initial and later usage would remain the same, but replacing Currently in the later usage case you need to provide the uninjected yaml. With what I'm suggesting that wouldn't be the case anymore; you would be able to update to a new version an already injected deployment. |
|
It'd be nice to have a user friendly view of that, maybe diff based? The other problem is that patch doesn't take |
|
Thanks for the feedback @grampelberg. I understand now why |
uninject.go iterates through the resources annotations, labels, initContainers and Containers, removing what we know was injected by linkerd. The biggest part of this commit is the refactoring of inject.go, to make it more generic and reusable by uninject. Some common parts were moved into inject_util.go but others common parts remained in inject.go to ease review and will then later get moved (marked with a comment). The entry-point function `transformInput` (formerly called `runInjectCmd`) receives as a parameter the function holding the logic specific for injection (`injectResource`) or uninjection (`uninjectResource`). `injectResource` was split into the `parse` (reused by uninject) and `injectResource` methods on the new `resourceConfig` receiver. That receiver holds all the info required for the injection/uninjection. The idea is that in a following PR this functionality will get reused by `linkerd inject` to uninject as as preliminary step to injection, as a solution to #1970. This was tested successfully on emojivoto with: ``` 1) inject: kubectl get -n emojivoto deployment -o yaml | bin/linkerd inject - | kubectl apply -f - 2) uninject: kubectl get -n emojivoto deployment -o yaml | bin/linkerd uninject - | kubectl apply -f - ``` Signed-off-by: Alejandro Pedraza <[email protected]>
Add `linkerd uninject` command uninject.go iterates through the resources annotations, labels, initContainers and Containers, removing what we know was injected by linkerd. The biggest part of this commit is the refactoring of inject.go, to make it more generic and reusable by uninject. The idea is that in a following PR this functionality will get reused by `linkerd inject` to uninject as as preliminary step to injection, as a solution to #1970. This was tested successfully on emojivoto with: ``` 1) inject: kubectl get -n emojivoto deployment -o yaml | bin/linkerd inject - | kubectl apply -f - 2) uninject: kubectl get -n emojivoto deployment -o yaml | bin/linkerd uninject - | kubectl apply -f - ``` Also created unit tests for uninject.go. The fixture files from the inject tests could be reused. But as now the input files act as outputs, they represent existing resources and required these changes (that didn't affect inject): - Rearranged fields in alphabetical order. - Added fields that are only relevant for existing resources (e.g. creationTimestamp and status.replicas in StatefulSets) Signed-off-by: Alejandro Pedraza <[email protected]>
Fixes #1970 The fixture `inject_emojivoto_already_injected.input.yml` is no longer rejected, so I created the corresponding golden file. Note that we'll still forbid injection over resources already injected with third party meshes (Istio, Contour), so now we have `HasExisting3rdPartySidecars()` to detect that. Signed-off-by: Alejandro Pedraza <[email protected]>
* When injecting, perform an uninject as a first step Fixes #1970 The fixture `inject_emojivoto_already_injected.input.yml` is no longer rejected, so I created the corresponding golden file. Note that we'll still forbid injection over resources already injected with third party meshes (Istio, Contour), so now we have `HasExisting3rdPartySidecars()` to detect that. * Generalize HasExistingSidecars() to cater for both the auto-injector and * Convert `linkerd uninject` result format to the one used in `linkerd inject`. * More updates to the uninject reports. Revert changes to the HasExistingSidecars func. Signed-off-by: Alejandro Pedraza <[email protected]>
Bug Report
What is the issue?
linkerd inject is not upgrading the proxy sidecars from 2.0.0 to 2.1.0
How can it be reproduced?
Logs, error output, etc
All containers stay at 2.0.0:
linkerd checkoutputEnvironment
Possible solution
Maybe
sed s'/stable-2.0.0/stable-2.1.0/g'?Additional context
linkerd check --proxyoutputThe text was updated successfully, but these errors were encountered: