Open johnbuluba opened 3 years ago
sarabala1979
commented
3 years ago @johnbuluba I. think. for the Resource template, the controller will not inject the wait container. into pod. So there is no sidecar kill.
This is never supported. it is new usecase. Do you like to submit. the PR for. this? Argo core team may not have istio knowledge.
this code should be add end of this function. wfExecutor.KillSidecars(ctx)
johnbuluba
commented
2 years ago @sarabala1979 Thanks a lot for your response!
This is never supported. it is new usecase.
Looking at the docs and the related issue #1282 there is nothing indicating that resource templates are not working. Is there a doc or issue that documents what will work and what not?
this code should be add end of this function. wfExecutor.KillSidecars(ctx)
This didn't solve the issue. Adding this line resulted with the main container exiting with error:
"executor error: failed to get container name for process 26: open /proc/26/environ: permission denied"To solve this I had to also add the SYS_PTRACE capability to the main container by editing this function https://github.com/argoproj/argo-workflows/blob/312f6463b47588a99050533911ab7e1a9c112136/workflow/controller/operator.go#L2829 and adding the following snippet:
// Add the required capabilities to be able to kill sidecars
if woc.getContainerRuntimeExecutor() == common.ContainerRuntimeExecutorPNS {
mainCtr.SecurityContext = &apiv1.SecurityContext{
Capabilities: &apiv1.Capabilities{
Add: []apiv1.Capability{
// necessary to access sidecars environment
apiv1.Capability("SYS_PTRACE"),
},
},
}
}If this solution is OK, I would be very happy to submit a PR.
alexec
commented
2 years ago I believe this should work. Can you please try with Emissary executor in v3.2.
licheng5625
commented
2 years ago I believe this should work. Can you please try with Emissary executor in v3.2.
still dose not work with version workflow-controller:v3.3.5
videlov
commented
1 year ago Issue still exists with Argo Workflows v3.4.9 and Istio 1.18.2. Workflow just hangs and workflow step pod stays with istio-proxy container running.
Easily reproducible with:
kubectl create namespace argo-istio
kubectl label namespace argo-istio istio-injection=enabled --overwrite
argo submit -n argo-istio --watch https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/steps.yaml
Summary
What happened/what you expected to happen?
We have a Workflow that has resource templates and Istio sidecar injection enabled. After the
maincontainer creates the resources, theistio-proxysidecar is not stopped. Because of this, the Pod stays in theRunningstate and the task hangs forever.We expected that the
istio-proxywill be terminated after the task completes. This works as expected in other templates, e.g. with the container template, where thewaitcontainer kills the sidecars.What version of Argo Workflows are you running? 3.1.6
Diagnostics
This is an example Workflow that uses a resource template with Istio sidecar injection enabled. The following should be created in a namespace with Istio enabled (with label
istio-injection=enabled).What Kubernetes provider are you using? EKS
What executor are you running? PNS
Finally I'd like to ask:
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.