mirror of https://github.com/istio/istio.io.git
Fix bad formatting.
This commit is contained in:
parent
c24e266103
commit
0c00b72d75
|
@ -8,7 +8,14 @@ aliases:
|
|||
- /blog/canary-deployments-using-istio.html
|
||||
---
|
||||
|
||||
> This post was updated on May 16, 2018 to use the latest version of the traffic management model. One of the benefits of the [Istio]() project is that it provides the control needed to deploy canary services. The idea behind canary deployment (or rollout) is to introduce a new version of a service by first testing it using a small percentage of user traffic, and then if all goes well, increase, possibly gradually in increments, the percentage while simultaneously phasing out the old version. If anything goes wrong along the way, we abort and rollback to the previous version. In its simplest form, the traffic sent to the canary version is a randomly selected percentage of requests, but in more sophisticated schemes it can be based on the region, user, or other properties of the request.
|
||||
> This post was updated on May 16, 2018 to use the latest version of the traffic management model.
|
||||
|
||||
One of the benefits of the [Istio](/) project is that it provides the control needed to deploy canary services. The idea behind
|
||||
canary deployment (or rollout) is to introduce a new version of a service by first testing it using a small percentage of user
|
||||
traffic, and then if all goes well, increase, possibly gradually in increments, the percentage while simultaneously phasing out
|
||||
the old version. If anything goes wrong along the way, we abort and rollback to the previous version. In its simplest form,
|
||||
the traffic sent to the canary version is a randomly selected percentage of requests, but in more sophisticated schemes it
|
||||
can be based on the region, user, or other properties of the request.
|
||||
|
||||
Depending on your level of expertise in this area, you may wonder why Istio's support for canary deployment is even needed, given that platforms like Kubernetes already provide a way to do [version rollout](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) and [canary deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). Problem solved, right? Well, not exactly. Although doing a rollout this way works in simple cases, it’s very limited, especially in large scale cloud environments receiving lots of (and especially varying amounts of) traffic, where autoscaling is needed.
|
||||
|
||||
|
|
Loading…
Reference in New Issue