John Howard
John Howard
This could be https://github.com/istio/istio/issues/38982?
I don't know that its explicitly "not implemented", I think its a bug. We would need to find the root cause before we fix. Note https://github.com/istio/istio/pull/48253/files changes things a lot
Istio isn't supposed to elide the pod when it's not ready, only if it's not *running*. not sure if that is working incorrectly or what
cc @jwendell @jacob-delgado may have experience with multus
15002 is just a bogus port to test the iptables. We dial :15002 and if the iptables is setup, it redirects to 15001 and succeds. If it fails, we know...
That might not work with CNI
I think this is from the `-A ISTIO_OUTPUT -d 127.0.0.0/24 -j RETURN` line. That looks like custom config?
the logging won't work if the pod doesn't come up either. You can use an ephemeral container to connect to the pod even while it's crashing
``` values: cni: image: cniConfDir: /etc/cni/multus/net.d chained: false ``` Note there are two configs: istiod, and the CNI itself. You are only configuring the latter here. the injection template depends...
> It pollutes troubleshooting Envoy debug logs due to constant traffic. This is much less of an issue after https://github.com/istio/istio/issues/32569. Before there was 1req/2s, now its once /15s. Most users...