Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
PRODUCT
6 min read
Share
Want to know more? Get in touch with us, or delve into the details of the latest release. Or just take a look at some of the Istio features that Backyards automates and simplifies for you, and which we've already blogged about.
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)!
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.
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.
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
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 productpage
service. Let's see how traffic flows through the cluster with Backyards.
Canary
on deploymentOkay, 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 primary
:
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.
If the 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.
After the 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 productpage
workload.
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!
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 and our Istio operator, it gives you flexibility, portability, and consistency across on-premise datacenters and 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.
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.
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
Get emerging insights on innovative technology straight to your inbox.
Discover how AI assistants can revolutionize your business, from automating routine tasks and improving employee productivity to delivering personalized customer experiences and bridging the AI skills gap.
The Shift is Outshift’s exclusive newsletter.
The latest news and updates on generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.