John Howard
John Howard
No, it would not due to the "If either label is disabled, the pod is not injected" part. Agree its a bit confusing with the 3 labels though
Here is basically every combination possible: https://github.com/istio/istio/blob/44c2f6312201a4172f138b1953e763ced3170cff/operator/cmd/mesh/manifest-generate_test.go#L1060 The reason things behave as they do is largely for backwards compatibility
I am not sure we need to document internal envoy details. If we do it should be "Low level, advanced doc, unstable"
There must be a second SE for catalog.acme.com in istio-system? Can you include it? Stepping back, this is a pretty unexpected configuration - I have never seen a setup like...
the auto passthrough mode filters endpoints that do not do mTLS On Mon, Mar 25, 2024, 8:25 AM lkalaivanan ***@***.***> wrote: > @lkalaivanan You should check all SEs > with...
this was probably a bug in 1.19 not 1.20
Yeah there was a unification of EDS and CDS code On Mon, Mar 25, 2024, 9:13 AM lkalaivanan ***@***.***> wrote: > @howardjohn Not only for 1.19, on the > previous...
No, that issue is about a new envoy commit merged days ago
This was changed in https://github.com/istio/istio/commit/d4f548ab4bedb4b7a59f0229e38ecae1a6ebfc05. mTLS is required for multi-network. This was a bug that was (accidentally) fixed in 1.20 by the above change.
The k8s gw status stuff is not a new subresource, just a new struct within `status`