The SMI Traffic Split API can be used to split outgoing traffic to multiple service backends. This can be used to orchestrate canary releases for multiple versions of the software.
What is supported
OSM implements the SMI traffic split v1alpha2 version.
It supports the following:
- Traffic splitting in both SMI and Permissive traffic policy modes
- HTTP and TCP traffic splitting
- Traffic splitting for canary or blue-green deployments
How it works
Outbound traffic destined to a Kubernetes service can be split to multiple service backends using the SMI Traffic Split API. Consider the following example where traffic to the
bookstore.default.svc.cluster.local FQDN corresponding to the
default/bookstore service is split to services
default/bookstore-v2, with a weight of 90 and 10 respectively.
apiVersion: split.smi-spec.io/v1alpha2 kind: TrafficSplit metadata: name: bookstore-split namespace: default spec: service: bookstore.default.svc.cluster.local backends: - service: bookstore-v1 weight: 90 - service: bookstore-v2 weight: 10
TrafficSplit resource to be correctly configured, it is important to ensure the following conditions are met:
metadata.namespaceis a namespace added to the mesh
spec.backendsall belong to the same namespace
spec.servicespecifies an FQDN of a Kubernetes service
spec.backendscorrespond to Kubernetes service objects
- The total weight of all backends must be greater than zero, and each backend must have a positive weight
TrafficSplit resource is created, OSM applies the configuration on client sidecars to split traffic directed to the root service (
spec.service) to the backends (
spec.backends) based the specified weights. For HTTP traffic, the
Host/Authority header in the request must match the FQDNs of the root service specified in the
TrafficSplit resource. In the above example, it implies that the
Host/Authority header in the HTTP request originated by the client must match the Kubernetes service FQDNs of the
default/bookstore service for traffic split to work.
Note: OSM does not configure
Host/Authorityheader rewrites for the original HTTP requests, so it is necessary that the backend services referenced in a
TrafficSplitresource accept requests with the original HTTP
It is important to note that a
TrafficSplit resource only configures traffic splitting to a service, and does not give applications permission to communicate with each other. Thus, a valid TrafficTarget resource must be configured in conjunction with a
TrafficSplit configuration to achieve traffic flow between applications as desired.
Refer to a demo on Canary rollouts using SMI Traffic Split to learn more.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.