old_issues_repo
old_issues_repo copied to clipboard
istio
two questions about --coreDump option
Is this a BUG or FEATURE REQUEST?:
Did you review istio.io/help and existing issues to identify if this is already solved or being worked on?:
Bug: Y
What Version of Istio and Kubernetes are you using, where did you get Istio from, Installation details
istioctl version 0.5.0
kubectl version 1.10-alpha
Is Istio Auth enabled or not ? No
What happened: This coreDump feature makes me confused.
When we run istioctl kube-inject --codeDump=true, what component do we want to debug?
- pilot-agent
- pilot-agent along with other containers in the injected pod
- all pods in the node
As far as I can see, the answer is 1. pilot-agent.
A initContainer set kernel.core_pattern to /etc/istio/proxy/core.%e.%p.%t.
But in the node host and the injected pod, there is no directory /etc/istio/proxy.
So for them, coredump files can not be generated any more. Is this a side effect of --coreDump?
Why not set core_pattern to a common directory, so that progresses in other mnt namespaces can also generate core files?
Another question is that /etc/istio/proxy is bindded to the host temp directory, when the pod is crushed or evicted, will the temp directory be garbage collected by kubelet? If so, the core files will lost.
I believe the primary motivation for --coreDump was to debug the proxy (envoy).
cc @andraxylia @costinm
yes the goal of that init container and option is to capture (or not capture) envoy crashes if any
https://github.com/istio/istio/issues/3064 is tracking to confirm if it does work (on ci but we should also check in prod)
This featrue has several disadvantages, as far as i can see.
- it effect other pods and the node itself.
- there is no directory /etc/istio/proxy in other pods and the node, so coredump files in their namespaces could not be generated.