Check out Backyards in action on your own clusters!
Many organizations are embracing a more decentralized decision making process, allowing them to better build cloud native applications, and to deliver them more rapidly and safely. Often, different teams manage different microservices, with each team able to release their microservices independent of the others. Istio is exceedingly helpful for this, since it provides low level constructs able to enforce policies in the network and configure traffic control, observability, rate limiting, circuit breaking and programmable rollouts. These configurations are expressed on Layer 7, and allow the decoupling of traffic flows from infrastructure, across multiple network topologies.
At Banzai Cloud we’ve been simplifying and automating how our customers provision Istio service meshes across multiple topologies. We do this on five cloud providers and on on-premise datacenters using our multi and hybrid-cloud platform, Pipeline. The core components at work behind the scenes are our open source Istio operator and Backyards (now Cisco Service Mesh Manager). We have often found that managing the deployment and control of microservices deployed to the Istio mesh was too complex or insufficiently automated, especially in multi-cluster, multi-cloud or hybrid-cloud scenarios. In contrast, building out and managing service meshes across single or multi-cluster topologies with Backyards (now Cisco Service Mesh Manager) was extremely simple.
Today, the wait is over, we’re about to make it easier than ever to manage microservices; this post will focus on making canary releases available in Backyards (now Cisco Service Mesh Manager)!
Canary releases - quick intro 🔗︎
The main goal of canary releases is to reduce the risk of introducing new versions of microservices by rolling them out gradually to a small subset of users before making them available to everyone. This process starts with an unused deployment of the service’s new version, which receives no traffic. Throughout the canary release, the service is monitored and observed via Prometheus metrics, and the traffic is increasingly routed towards the new service (e.g. from 10% to 20% onward, until reaching 100%). The health of the new service, error rates, and other configurable metrics are constantly checked, until
exit criteria have been met (or have otherwise been failed to be met), and the new microservice serves all requests.
A canary release is a special instance of a Blue/Green deployment, where the transition happens gradually, rather than instantly. In Istio terms, the relative weighing of traffic between service versions is programatically adjusted during a control loop, which constantly observes the service health and adjusts routing accordingly.
Try it out 🔗︎
Create a service mesh 🔗︎
Let’s start by creating a cluster on AWS, using Banzai Cloud’s lightweight and CNCF certified Kubernetes distribution, PKE. Next, we’ll create an Istio service mesh on top of that cluster.
After a few seconds, the mesh will have beeen installed and be ready to use.
Deploy Bookinfo 🔗︎
Now we’ll deploy a sample Bookinfo application so that we can use it to showcase our canary feature:
~ ❯ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/platform/kube/bookinfo.yaml
Generate load 🔗︎
The Backyards UI has a
test flight feature that sends traffic to a selected endpoint. If you click the
HTTP button in the top right corner of the screen, you’ll be able to fill out a form with endpoint details, and send test traffic to your services. Let’s use this to generate a continuous load on our
Let’s see how traffic flows through the cluster with Backyards.
Canary on deployment 🔗︎
Okay, now let’s say we’d like to do a canary release for our
productpage deployment. We can easily enable this from the Backyards UI. Once we enable the canary, we will have a
primary and a
canary pod, with traffic being routed through the
Trigger canary release 🔗︎
We can trigger a canary release on the deployment by changing a specification, like, for example, the deployment’s image:
~ ❯ kubectl set image deploy/productpage-v1 productpage=docker.io/istio/examples-bookinfo-productpage-v1:1.14.0
This triggers a canary deployment process. As the application receives a continuous load, more and more traffic will be forwarded to the
canary, providing the Prometheus metrics are within their thresholds for maximum error rates and request durations.
canary pod responds successfully to these requests, at the end of the process all traffic will be being forwarded to it. Then, the
primary will be rolling updated and all traffic will be routed to that instead.
Delete canary 🔗︎
canary is enabled for a deployment, any image change will trigger a canary release process. To disable it, simply disable the
canary on the UI.
After disabling the
canary, traffic will begin to flow in the same way it did before the canary feature was enabled to the original
Canary releases are an enormously useful tool. They reduce the risk of introducing a new microservice version, but they require lots of machinery. With the Pipeline platform and Backyards, our users can execute canary releases through the UI, CLI or API, more easily than ever before. Happy canary releasing!
About Backyards 🔗︎
Banzai Cloud’s Backyards (now Cisco Service Mesh Manager) is a multi and hybrid-cloud enabled service mesh platform for constructing modern applications. Built on Kubernetes, our Istio operator and the Banzai Cloud Pipeline platform gives you flexibility, portability, and consistency across on-premise datacenters and on five cloud environments. Use our simple, yet extremely powerful UI and CLI, and experience automated canary releases, traffic shifting, routing, secure service communication, in-depth observability and more, for yourself.
About Banzai Cloud Pipeline 🔗︎
Banzai Cloud’s Pipeline provides a platform for enterprises to develop, deploy, and scale container-based applications. It leverages best-of-breed cloud components, such as Kubernetes, to create a highly productive, yet flexible environment for developers and operations teams alike. Strong security measures — multiple authentication backends, fine-grained authorization, dynamic secret management, automated secure communications between components using TLS, vulnerability scans, static code analysis, CI/CD, and so on — are default features of the Pipeline platform.
About Banzai Cloud 🔗︎
Banzai Cloud is changing how private clouds are built: simplifying the development, deployment, and scaling of complex applications, and putting the power of Kubernetes and Cloud Native technologies in the hands of developers and enterprises, everywhere.
#multicloud #hybridcloud #BanzaiCloud