Introduction

In cloud era, many organizations are starting journey towards adopting microservice architecture to enable organizations to grow fast, where & when needed. This article has been divided into multiple parts.

In part 1 of series, we touched upon key challenges in traditional (monolithic) architecture and microservice style architecture to start with.

In part 2, focus on what is Service Mesh, why do need to use Istio Service Mesh

In part 3, will be focusing on quick comparison between Spring Cloud and Istio service mesh.

In part 4, will be focusing on key benefits of Istio service mesh like how Istio helps developer, operators, etc.

In part 5, will be focusing on additional features of Istio service mesh

Benefits

This section explains about features of Istio using two simple service communications. For setting up Istio in IBM Cloud Container Service, enable Istio for sample app and execute route rules, refer Istio site.

Traffic management
Let’s take two simple services, ‘service A’ and ‘service B’ to go through features of Istio. Let’s assume,

  • Both services are running in Bluemix container (Kubernetes)
  • ‘service A’ had been configured to access ‘service B’ without header validation (like version, user name, etc)
  • ‘service B’ went for new release from ‘version 1.0’ to ‘version 2.0’

At this stage, as there is no specific route mentioned, ‘service A’ may route either ‘version 1.0’ or ‘version 2.0’ randomly as below,

Let’s check feature’s of Istio using some scenarios:-

Scenario 1 – Canary release: Content-Based: User name
Route to all user to ‘service B: Version 1.0’ and specific user to ‘service B: Version 2.0’

Let’s say Admin user create route rule using below mentioned specification, then traffic will be changed as depicted. Here route rule will be based on header parameters. Instead of rolling out to entire audience, this option helps to test new release with smaller group.

Scenario 2 – Canary release: Content-Based: User agent
Route to iPhone user to ‘service B: Version 1.0’ and Android user to ‘service B: Version 2.0’

Let’s say Admin user create route rule using below mentioned specification, then traffic will be changed as depicted. Here route rule will be based on user-agent in header parameters. Instead of rolling out to entire audience, this option helps to test new release with Android user (where less usage).

Scenario 3 – Canary release: Weightage-Based
Route to users between ‘service B: version 1.0’ and ‘service B: version 2.0’ based on weightage

Let’s say Admin user create route rule using below mentioned specification, then traffic will be changed as depicted. Here route rule will be based on weightage. Instead of rolling out to entire audience to new version, this option helps to test new release with less percentage of users.

In same way, we can increase weightage of V2 gradually and deprecate V1.

Scenario 4 – Route to all user to service B: version 2.0
Let’s say Admin user create route rule using below mentioned specification, then traffic will be changed as depicted.

Enabling External Traffic (Egress)

By default, Istio-enabled services are unable to access URLs outside of the cluster because iptables is used in the pod to transparently redirect all outbound traffic to the sidecar proxy, which only handles intra-cluster destinations.

The Istio egress rules currently only supports HTTP/HTTPS requests. If you want to access services with other protocols (e.g., mongodb://host/database), or if you want to completely bypass Istio for a specific IP range, you will need to configure the source service’s Envoy sidecar to prevent it from intercepting the external requests. This can be done using the –includeIPRanges option of istioctl kube-inject when starting the service.

The simplest way to use the –includeIPRanges option is to pass it the IP range(s) used for internal cluster services, thereby excluding external IPs from being redirected to the sidecar proxy. The values used for internal IP range(s), however, depends on where your cluster is running. For example, with Minikube the range is 10.0.0.1/24, so you would start the sleep service like this:

On IBM Cloud Container Service
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --includeIPRanges=172.30.0.0/16,172.20.0.0/16,10.10.10.0/24)


Handling failures
Envoy provides a set of out-of-the-box opt-in failure recovery features that can be taken advantage of by the services in an application. Features include:

  • Timeouts
  • Retries
  • Limits on number of concurrent connections and requests to upstream services
  • Active (periodic) health checks on each member of the load balancing pool
  • Fine-grained circuit breakers (passive health checks) – applied per instance in the load balancing pool

Scenario 5 – Increase delay response time
Let’s say we want to check the behavior of ServiceA if ServiceB response with some delay, as this is for test, let’s specify for specific user. In this scenario, ServiceA waits till ServiceB gives a response, as there is no timeout specified at ServiceA.

Scenario 6 – Timeouts, Retry and Redirect
In this scenario, let’s check about timeout, retries for specified times and can be redirected.

Access Policy Enforcement

Scenario 7 – Rate limits

Istio enables users to rate limit traffic to a service. Consider ratings as an external paid service with 1qps free quota. Using Istio we can ensure that 1qps is not breached.

Also, we can include conditional rate limit for specific service.

Every distinct rate limit configuration represents a counter. If the number of requests in the last expirationduration exceed maxAmount, Mixer returns a RESOURCE_EXHAUSTED message to the proxy. The proxy in turn returns status HTTP 429 to the caller.

References

Join The Discussion

Your email address will not be published. Required fields are marked *