Istio Explained – Service Mesh Part 1: Routing

Istio Explained – Service Mesh Part 1: Routing

Istio – Taming Your Microservices Management

K&C’s DevOps and Kubernetes consulting and development engineers have a wealth of experience across modern technology stacks and a broad range of project types. Working across different projects keeps our experience and knowledge at the cutting edge – a huge competitive advantage in today’s fast moving digital environment.

It means we can often plug gaps our clients have in their in-house IT department’s experience and knowledge. We often realise development, infrastructure and QA challenges that have been struggled with internally as a dedicated team. Or consult on set-up and helping introduce new technologies and methodologies as a team extension, supporting an in-house resource.

Over the past couple of years, an issue we have encountered with increasing frequency is in-house DevOps or development resources struggling to effectively manage increasingly complex combinations of microservices. This is particularly often the case for organisations that have more recently transitioned to building apps on a microservice rather than monolith architecture. One of the most important tools we use to help manage the connections between microservices is Istio.

In the first of our series of posts covering ISTIO, we’ll look at exactly what Istio is and how the Google open source project brings the complexities of managing the networks used to connect microservices under control.

Microservices – Business and Technology Pros and Cons

Microservices allow for big, complex apps to be broken up into independent, containerized services. These containers then form Kubernetes clusters. The advantage of this is a reduction in costs as initial development is simplified and so faster. Updates to existing apps or scaling them is also simplified – all of which boosts an organisation’s bottom line.

However, the decision to go with a microservices architecture inevitably introduces some challenges alongside the advantages. Breaking apps down into independent services means an increase in the number of moving parts that need to be connected and secured. Managing this network of independent services such as traffic management, load balance, authentication, authorization etc. etc., can, especially in the case of complex apps, become extremely complex.

The term for the ‘space’ that exists between Kubernetes containers in a cluster is a Service Mesh. Istio, is an open source project initiated by Google and also involving IBM and ride-share app tech company Lyft. It’s a tool to manage the Service Mesh of a Kubernetes cluster – taming it before it becomes a complex zone of chaos that is a potential source of bugs.

Service Mesh

The Service Mesh is the architecture layer responsible for reliable delivery of requests through a complex network of microservices.

When your application has evolved from a monolith to a microservice architecture, it becomes increasingly difficult to manage and monitor it every day. In this case, you need to move on to solutions that solve some of the problems associated with microservices:

  • load balancing inside the microservice grid;
  • service discovery
  • Failure recovery
  • metrics
  • monitoring

They also solve more complex problems:

  • A / B testing;
  • canary rollouts (Canary rollouts);
  • access control
  • end-to-end authentication

Istio Comes Into Play

This is where Istio comes to the rescue.

Key features of Istio:

  • traffic management: timeouts, retries, load balancing;
  • security: authentication and authorization;
  • observability: trace, monitoring;

Istio Architecture:

Istio Service Mesh is logically divided into data plane and control plane.

  • Data plane – consists of a set of smart proxies deployed as sidecars. These proxies provide and control all network communication between services together with the Mixer center of policies and telemetry;
  • Control Plane – Configures proxies for routing traffic. The control plane also configures the Mixer to apply policies and telemetry.

Istio Architecture (source)

Components:

  • Envoy is a high-performance proxy developed in C ++ to transfer all incoming and outgoing traffic for all services;
  • Mixer – provides access control and usage policies for the network of services and collects telemetry data from the Envoy proxy server and other services;
  • Pilot – provides service discovery for Envoy sidecar, provides opportunities for intelligent traffic routing (for example, A / B tests, canary deployments) and fault tolerance (timeouts, retries, circuit breakers);
  • Citadel – provides reliable service-to-service and end-user authentication;
  • Galley – is a component of Istio configuration validation. He is responsible for isolating the remaining components of Istio from the user configuration of the underlying platform.

Routing and traffic configuration

The Istio traffic routing and configuration model uses the following API resources:

  • Virtual services – sets up rules for routing Envoy traffic inside our service mesh;
  • Destination rules – sets up policies for after applying routing rules to Virtual services;
  • Gateways – to configure the Envoy load balancing method (HTTP, TCP or gRPC);
  • Service entries – to configure external grid dependencies.

Install and configure Istio

We will run istio on the Google Kubernetes Engine (GKE). Create a cluster:

We obtain access keys (hereinafter credentials):

We give administrator rights to our user:

After preparing the cluster, we proceed to install the Istio components. Download the latest version, at the time of writing, Istio version 1.3.0:

Go to the directory with Istio:

Install Custom Resource Definitions (CRDs) for Istio with kubectl

After installing the CRD, install Isito control plane itself with mutual TLS authentication:

Checking services:

and pods:

Application launch

We will use the lite version of bookinfo, written by K&C for testing Istio. We won’t use UI yet (it doesn’t work well enough for presentation).

Application Architecture:

 

 

application architecture

  • ui
  • Gateway — API
  • Books
  • Ratings

Differences in application versions:

books:

  • v1 —  нету описания (description)
  • v2 — есть описание

ratings:

  • v1 — presentation «:-)»
  • v2 — presentation «¯\\_(ツ)_/¯»

Create a namespace for the application:

Create the books-deployment.yaml file with the contents.

This is a set of standard api deployments and services for deploying a regular application in kubernetes. In this example, we use one version of Gateway and 2 versions of books and ratings. In service selector is registered only to the name of the application, and not to the version; we will configure routing to a specific version using Istio

We apply:

We check:

In the conclusion, we see 2 containers running in each pod, Istio made an injection container with Envoy during the deployment, in the future all traffic will go through these containers.

We create the istio-gateway.yaml file with the contents. Istio does not allow the use of wildcard in VirtualService, so replace ‘*’ with the balancer ip:

We apply:

We determined the entry point to our application, all incoming traffic from uri / gateway / books will be routed to the gateway service (aka gw).

Now create the istio-destinationrule.yaml file:

In the subset, we determined where to route traffic, for gw traffic will go to under c version 1, books and ratings for both versions in turn.

We apply:

We open in the browser http: // <load_balancer_ip> / gateway / books is our API. We get JSON with books and their rating.

Try to refresh the page – the output will be different, because the application will access different services each time.

And a couple of times more:

The application topology can also be viewed through Kiali, which was installed along with other components of Istio. To do this, use port-forward to forward the service to our machine:

Kiali will be available at http: // localhost: 20001 admin / admin. On the Graph tab we see:

Traffic routing

Everything is beautiful in the picture, but in real life you need traffic to go to certain versions of services. To do this, create another file istio-virtual-service-all-v1.yaml, in which we determine that all requests will go to books and rating version 1:

And apply:

We check that the browser should see the same output:

In this example, in the subset we specified only v1 for books and ratings, and all traffic went only to the first version.

Traffic switching

We apply weight-based routing. This means that we put weights on services, in the example we put the first version 50 on the service ratings and the same on the second version. Now all traffic will be balanced 50/50 between versions. We can also supply 10/90, in which case 10% of the traffic will go to the first version and 90% to the second.

Create a virtual-service-ratings-50.yaml file:

We apply:

Check on browser:

We refresh the page a couple of times:

Clean and move on to the next example:

Timeouts and Retries

Istio allows you to enable timeouts for services, so you can artificially simulate the long response of microservices.

We create the istio-delay.yaml file, in which we set a delay of 2 seconds for all requests:

We apply:

We check in the browser – the application works, but with a delay. Increase the timeout to 5 seconds.

We apply and verify:

We get an error in response, now we know that the application will crash if one of the microservices responds for a long time:

You can also add retries and a timeout for retry:

Clean and move on to the next example:

Traffic mirroring

Sometimes you need to check the new version with more users, but you can’t roll it out to the prod. To do this, Istio has traffic mirroring functionality, we launch a new version of the service in parallel and direct traffic there, without affecting the working version of the service.

To do this, create the file istio-mirroring.yaml

We apply:

We’re checking:

We get the answer from ratings of the first version:

In the ratings container logs of the second version, we see that traffic is mirrored to it:

Clean and move on to the next example:

Circuit Breaker

It is very important that our requests are guaranteed to reach the addressee. Istio implements the Circuit Breaking mechanism. Proxies inside the cluster interrogate services and, in the event of a breakdown or slow response, turn off the service instance (sub) from the network and direct the load to other service replicas.

For the books service, the following rules apply:

  • maxConnections – The maximum number of connections to the service. Any redundant connection will be in the queue.
  • http1MaxPendingRequests – the maximum number of pending service requests. Any excess pending requests will be rejected.
  • maxRequestsPerConnection – the maximum number of requests in the cluster.
  • BaseEjectionTime – maximum extraction time for the hearth. The under will be removed for 20 seconds.
  • ConsecutiveErrors – the number of errors before the sub is removed from the pool. For example, if you have three consecutive errors while interacting with a service, Istio marks it as unhealthy.
  • Interval – time interval for outlier analysis. For example, a service is checked every 10 seconds.
  • MaxEjectionPercent – the maximum percentage of hearths that can be extracted from the load balancing pool. For example, setting this field to 100 implies that any unhealthy hearths that produce consistent errors can be retrieved and the request will be redirected to healthy hearths.

And there you have it – a step-by-step technical guide to using Istio for routing in a microservices-based app environment.

K&C – IT Outsourcing You Can Trust

If your organization needs any assistance with Istio integration and set-up or any other Kubernetes or wider web development gaps in your in-house resource, K&C would be delighted to hear from you.

Based in and managed from Munich, Germany, our nearshored tech talent hubs in Kiev and Krakow offer you access to some of Europe’s best developers, software testers and IT consultants at rates that are competitive without compromising quality.

Our dedicated teams, team extensions and consultants can either work with you onsite wherever you are in Germany or Europe, remotely from our K&C offices or as a hybrid model. We service your needs, as they are and as they change. Please do get in touch.

Kommentar hinzufügen

E-Mail-Adresse ist schon registriert. Bitte benutze Das Login-Formular oder nenne eine andere.

Du hast einen falschen Nutzernamen oder Passwort eingegeben

Sorry that something went wrong, repeat again!
Kontaktieren Sie uns