Ingress Nginx support Progressive Delivery
Progressive delivery is a practice that allows organizations to control how and when new software features or changes are delivered. It builds on the capabilities and practices of feature flag management and deployment strategies like blue-green and canary deployments. Ultimately, progressive delivery combines software development and delivery practices allowing organizations to deliver with control.
In some cases, you may want to “canary” a new set of changes by sending a small number of requests to a different service than the production service. The canary annotation enables the Ingress spec to act as an alternative service for requests to route to depending on the rules applied. The following annotations to configure canary can be enabled after
nginx.ingress.kubernetes.io/canary: "true" is set:
nginx.ingress.kubernetes.io/canary-by-header: The header to use for notifying the Ingress to route the request to the service specified in the Canary Ingress. When the request header is set to
always, it will be routed to the canary. When the header is set to
never, it will never be routed to the canary. For any other value, the header will be ignored and the request compared against the other canary rules by precedence.
nginx.ingress.kubernetes.io/canary-by-header-value: The header value to match for notifying the Ingress to route the request to the service specified in the Canary Ingress. When the request header is set to this value, it will be routed to the canary. For any other header value, the header will be ignored and the request compared against the other canary rules by precedence. This annotation has to be used together with . The annotation is an extension of the
nginx.ingress.kubernetes.io/canary-by-headerto allow customizing the header value instead of using hardcoded values. It doesn’t have any effect if the
nginx.ingress.kubernetes.io/canary-by-headerannotation is not defined.
nginx.ingress.kubernetes.io/canary-by-header-pattern: This works the same way as
canary-by-header-valueexcept it does PCRE Regex matching. Note that when
canary-by-header-valueis set this annotation will be ignored. When the given Regex causes error during request processing, the request will be considered as not matching.
nginx.ingress.kubernetes.io/canary-by-cookie: The cookie to use for notifying the Ingress to route the request to the service specified in the Canary Ingress. When the cookie value is set to
always, it will be routed to the canary. When the cookie is set to
never, it will never be routed to the canary. For any other value, the cookie will be ignored and the request compared against the other canary rules by precedence.
nginx.ingress.kubernetes.io/canary-weight: The integer based
(0 - ) percent of random requests that should be routed to the service specified in the canary Ingress. A weight of
0 implies that no requests will be sent to the service in the Canary ingress by this canary rule. A weight of means implies all requests will be sent to the alternative service specified in the Ingress. <
weight-total> defaults to
100, and can be increased via
nginx.ingress.kubernetes.io/canary-weight-total: The total weight of traffic. If unspecified, it defaults to
Canary rules are evaluated in order of precedence. Precedence is as follows:
kubectl apply -f manifests/Deployment-1.yaml
kubectl apply -f manifests/Service-1.yaml
kubectl apply -f manifests/Ingress-1.yaml
kubectl apply -f manifests/Deployment-canary.yaml
kubectl apply -f manifests/Service-canary.yaml
kubectl apply -f manifests/Ingress-canary.yaml
curl Verion 1
Not support automatic failover. Even if the traffic is completely cut to Canary Ingress, the old version of the service must still exist, otherwise an error 503 will be reported.
Only one Canary Ingress of the same service can be defined, so the back-end service supports up to two versions.
The domain name must be configured in Ingress, otherwise it will not be effective.
All the other non-canary annotations will be ignored. Note that when you mark an ingress as canary, then all the other non-canary annotations will be ignored (inherited from the corresponding main ingress) except
nginx.ingress.kubernetes.io/upstream-hash-by, and annotations related to session affinity. If you want to restore the original behavior of canaries when session affinity was ignored, set
nginx.ingress.kubernetes.io/affinity-canary-behaviorannotation with value
legacyon the canary ingress definition.
Currently a maximum of one canary ingress can be applied per Ingress rule.