Red Hat ServiceMesh 2 migration towards 3 known caveats
-
Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content. *
-
Follow the documentation on migrating from ServiceMesh 2 to 3
https://docs.redhat.com/en/documentation/red_hat_openshift_service_mesh/3.0/html-single/migrating_from_service_mesh_2_to_service_mesh_3/index -
Default value of the feature flag VERIFY_CERT_AT_CLIENT is set to true
https://istio.io/latest/news/releases/1.21.x/announcing-1.21/upgrade-notes/#default-value-of-the-feature-flag-verify_cert_at_client-is-set-to-true- If you are using Openshifts build in ServiceCA to expose SSL based services in your cluster, the default verification of DestinationRules in ServiceMesh have changed and a you need to adjust the
spec.trafficPolicy.tlsconfiguration with the trusted-ca bundle accordingly. - https://access.redhat.com/solutions/7139758
- If you are using Openshifts build in ServiceCA to expose SSL based services in your cluster, the default verification of DestinationRules in ServiceMesh have changed and a you need to adjust the
-
Default tracing to zipkin.istio-system.svc removed
https://istio.io/latest/news/releases/1.22.x/announcing-1.22/upgrade-notes/#default-tracing-to-zipkinistio-systemsvc-removed- Migrate your Zipkin configuration accordingly to following documentation and blog posts
- https://access.redhat.com/solutions/7083722
- https://developers.redhat.com/articles/2025/04/09/best-practices-migration-jaeger-tempo?source=sso#change_jaeger_to_tempo_with_opentelemetry_collector
- https://developers.redhat.com/learn/openshift/seamless-transition-migrate-your-service-mesh-observability-jaeger-opentelemetry
- Migrate your Zipkin configuration accordingly to following documentation and blog posts
-
ServiceEntry with resolution: NONE now respects targetPort
https://istio.io/latest/news/releases/1.22.x/announcing-1.22/upgrade-notes/#serviceentry-with-resolution-none-now-respects-targetport- with the change on respecting
targetPortin the ServiceEntry when resolution is set toNONEensure that the configured targetPort matches the expected service port accordingly.
- with the change on respecting
-
SDN to OVN changes in IstioCNI. In case your migration also goes along the SDN to OVN change you need to adjust the SDN based CNI configuration accordingly
- follow the instructions in Solution https://access.redhat.com/solutions/7132352
-
ServiceMesh 3 Sail Operator CR specification changes
- ServiceEntry
addressarray size is limited to256entries.- If you have ServiceEntry CRs with more than 256 entries, you will need to split them into multiple ServiceEntry CRs accordingly.
- ServiceEntry
-
Default retry policy to exclude retries on 503
-
EXCLUDE_UNSAFE_503_FROM_DEFAULT_RETRY been introuduced in https://istio.io/latest/news/releases/1.24.x/announcing-1.24/change-notes/
-
EXCLUDE_UNSAFE_503_FROM_DEFAULT_RETRY has been removed from Istio 1.27.x (including Service Mesh 3.2)
Therefore, if you upgrade to Service Mesh 3.2 (Istio 1.27.9) and want retries on HTTP 503 responses,
1) Configure them explicitly, for example by defining a VirtualService with:retries: attempts: 2 perTryTimeout: 2s retryOn: connect-failure,refused-stream,unavailable,cancelled,5032) Another way based on internal checking in OSSM-13454 ,
using the way below towards ISTIO CR can also help (VirtualService can still be used when a customer
needs a different retry policy for a specific host/service, since it can override the mesh-level default.)spec: values: meshConfig: defaultHttpRetryPolicy: attempts: 2 retryOn: connect-failure,refused-stream,unavailable,cancelled,503
-
-
ServiceEntry DNS Proxying, which defaults to false
- follow the instructions in Solution https://access.redhat.com/solutions/7134151
further preparations for Red Hat OpenShift ServiceMesh 3 onwards
-
Native sidecar enabled by default
https://istio.io/latest/news/releases/1.27.x/announcing-1.27/upgrade-notes/#native-sidecar-enabled-by-default- with Native sidecars being defaulted ServiceMesh 3.3 mutating webhooks of additional operators might be conflicting.
-
HTTP compression of Envoy metrics (prometheus_stats) enabled by default
https://istio.io/latest/news/releases/1.29.x/announcing-1.29/upgrade-notes/#http-compression-of-envoy-metrics-prometheus_stats-enabled-by-default- with HTTP compression enabled on the metrics endpoint, ensure your Service and or PodMonitor specifications grant HTTP compression from the scrape sources accordingly.
-
Circuit breaker metrics tracking behavior change
https://istio.io/latest/news/releases/1.29.x/announcing-1.29/upgrade-notes/#circuit-breaker-metrics-tracking-behavior-change- Custom Circuit breaker metrics dashboards might break with the release of Red Hat ServiceMesh 3.3+
Comments