IBM Developer

Article

Get started with Istio

Explore Istio, service meshes, and how to reduce the challenges that arise from the success of microservices-based architectures

By Saul Calderon Balan

On this page

The advent and growth of applications based on microservices architectures are solving significant challenges that allow companies to maintain an accelerated pace of innovation through the adoption of digital transformation. By working together as a community and using community knowledge, open source projects are often able to quickly solve these challenges. Istio is the result of community innovation, and its use is expanding because of the benefits that it provides. Therefore, it's important to understand how to take advantage of this technology when applying it.

This article provides overview information on Istio, service meshes, and how to reduce the challenges that arise from the success of microservices-based architectures. It also provides use cases and specific scenarios to show how to integrate fault tolerance into applications without making changes to the code of those applications. It's helpful if you have some knowledge of general concepts of microservices, containers, and Kubernetes as well as TCP/HTTP networking, SSL, and TLS security.

Background

Istio began because of the popularity of microservices, from the concept of containers (such as Docker) and container orchestrators (such as Kubernetes). Microservices architectures have evolved because of their expanding use and support by users, major foundations, and manufacturers.

It has matured through this usage by solving challenges that fell on the application itself or on the infrastructure layers that manage the containers where these applications live. Some areas where Istio helped include:

  • Companies, by adopting microservices architectures, had growth in their implementations that entailed many microservices (a single application can be composed of hundreds or thousands of microservices) requiring communication with each other. This might have been manageable in smaller implementations or in monolitic application environments.

  • Unlike monolithic applications, microservices-based applications are not static. Rather, they are dynamic because microservices can be running anywhere, either due to their elasticity or because of failure and update processes.

  • Defining and managing traffic between microservices.

  • Traffic visibility and monitoring in a microservices architecture.

  • Securing communications between microservices.

What is a service mesh?

A service mesh is a dedicated infrastructure layer to transparently add (without touching the code) security, reliability, and observability to the communication between services.

Just as TCP provides a network for delivering bytes between network points, the service mesh provides a network for communication between microservices. Therefore, a service mesh is the mechanism for managing the network functions that are required for microservices-based architectures.

What is Istio?

Istio is a mesh of services, among others that have emerged such as Linkerd or Netflix OSS. It is a service mesh that provides raw, rich, and declarative service discovery and routing capabilities.

Istio supports microservices in a Kubernetes environment through the implementation of a sidecar proxy. This proxy intercepts all communications between microservices to manage them.

The sidecar proxy implementation accompanies the application during its life in a decoupled way, but adds additional capabilities by intercepting network communications. Therefore, the application and the sidecar proxy or "Envoy" live inside a Pod in Kubernetes.

Among the main advantages of using Istio (that it can provide with little change to the application code) are:

  • Automatic load balancing for traffic: HTTP, gRPC, WebSocket, and TCP
  • Granular traffic control with routing, retries, drops, range, and quota limits
  • Metrics, logs, and automatic tracking for traffic within a cluster, including ingress and egress
  • Securing communication between services in a cluster with strong identity-based authentication and authorization

The following image gives a high-level view of Istio in a K8 environment.

Istio environment

Istio architecture

Istio is made up of two planes: the data plane and the control plane.

  • The data plane is composed of the proxy sidecars or "Envoys" deployed within the Pod of an application to intercept all communications between microservices.

  • The control plane lets you configure and manage proxies or Envoys for traffic routing and compliance with other policies at runtime.

The following image shows an overview of the control and data planes.

Istio control plane and data plane

The characteristics of the architecture components are:

  • Envoy: A separate project that is used by Istio. This is the component in charge of providing the dynamic service discovery, load balancing, TLS, gRPC, circuit breakers, timeout management, status controls, and metrics among others.

  • Pilot: The component responsible for service discovery, intelligent routing, and fault tolerance (for example, retries, circuit breakers, and timeouts).

  • Mixer: The component in charge of enforcing policies, access controls, and usage. It also obtains metrics generated by calls to Envoys. This frees applications from implementing capabilities such as access control, quota management, and telemetry reporting.

  • Citadel: As a security component, it enables authentication and encryption between services through identity-based policies and implements TLS.

Istio scenarios and use cases

Istio allows you to integrate fault tolerance into applications without making changes to the code of those applications. Use cases for this include:

1. Server-side service discovery

The Pilot converts high-level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Envoy instances in the mesh perform service discovery and dynamically update their load balancing pools accordingly.

  • You can deploy load balance with sensibility to Availability Zones (AZ) with automatic failover commutation.

  • Client requests to the load balancer:

    • The load balancer checks the Services Registry and routes the requests to the instances.
    • The distribution logic lives in the load balancer.

The following image shows server-side service discovery in Istio.

Server-side discovery Image from Dzone.com

2. Automated testing

The following list shows some automated testing capabilities in Istio (ways to cause problems in the system to identify how things work).

  • Failure testing
  • Generating random problems with a purpose
  • Implementing resilience patterns
  • Service registry: Dynamic listing of service instances
  • Circuit breaking: Blocking calls to services that are not working
  • Bulkhead: Separation of connection pools to separate resources
  • Command: Executing retry, throttle, and monitoring requests

2.1 Circuit breaking

Circuit breaking is an important pattern for creating resilient microservice applications. It lets you write applications that limit the impact of failures, latency spikes, and other undesirable effects of network peculiarities.

The consumer of a service is only as trustworthy as the service provider, so this capability helps when a microservice fails by opening the breaker to help the consumer identify the fail as soon as possible.

To avoid invoking an untrusted service instance, Istio can help when:

  • The service should throw an error
  • The service might throw out an overtime
  • There might be network failures

With circuit breaking, the consumer of a service can invoke an untrusted service, and it can fail fast when the service provider is not working. The following image shows the circuit breakers in Istio.

Circuit breakers

2.2 Failure (or resiliency) testing

Fault injection lets you inject faults to test the resiliency of your application and to identify weaknesses in recovery policies, for example, identify if the timeouts are set correctly. With this capability, you can manage HTTP/rRPC error codes and Delay Injection.

The following image shows a failure test in Istio where Service A calls Service B having a maximum of 200 ms with 2 retries. That's a total of 400 ms. But, Service B also calls Service C, and it has a maximum of 200 ms with 3 retries. That's a total of 900 ms. This means that when Service A calls Service B, it might time out while Service B is still calling Service C. Because it's difficult to identify this kind of issue going through all configurations and services, you can deploy Istio to help reinforce this for you and execute resiliency testings to find these kinds of problems.

Failure test

2.3 Bulkheads

Istio allows the implementation of bulkheads, which reduces the chances of fault propagation. Without bulkheads, a single connection pool is shared with external systems. If one system blocks connections, then all connections are blocked, and there is no way to get connections to the other systems.

With bulkheads, there is a pool of connections for each external system. If one system blocks connections, then the other connections to the other systems continue to work.

The following image shows bulkheads in Istio.

Bulkheads

2.4 Traffic distribution and differentiation

2.4.1 Distribution of traffic by quotas

Istio lets you decouple traffic from the infrastructure using weight-based rules that are set in percentages and differentiating the destination service through tags. The following image shows traffic distribution by quotas in Istio.

Traffic distribution

2.4.2 Traffic distribution by content

Istio lets you route traffic based on its content and differentiate that traffic (for example, the tags of the Pods). The following image shows traffic distribution by content.

Traffic distribution by content

2.5 Service authentication

Istio's security features provide strong identity management, robust policies, transparent TLS encryption, and AAA tools: authentication, authorization, and auditing. At a high level, Istio security considers multiple components:

  • Citadel, which manages keys and certificates
  • Sidecar and Edge proxies, which ensure communication between clients and servers
  • Pilot, which distributes authentication policies and secure naming information to proxies
  • Mixer, which manages authorization and auditing

The following image shows Istio service authentication.

Istio service authentication

Because security is key in any implementation, I’ll dive deeper into the following Istio security features:

  • Identities
  • Secure communication
  • Key management

2.5.1 Identities

Istio uses Kubernetes service accounts (SA) to identify who is running a service. At the beginning of the services communication, the two parties must exchange credentials for mutual authentication.

  • On the customer's side, the identity of the server is validated against a safe name to confirm that you are an authorized executor of the service.
  • On the server side, the server must determine what information can be accessed by the customer based on authorization policies.

Istio implements Spiffe, which provides a secure identity based on a personalized X.509 certificate for any workload in a modern environment. Spiffe eliminates the need for application-level authentication as well as complex ACL-based network configurations. So, Spiffe grants identities to services in heterogeneous environments.

This way, Istio has flexibility and granularity to represent a person, an individual service, or a group of services. In Kubernetes, the Istio service identity is the service account. The identifier of a service account is represented as follows:

spiffe://<domain>/ns/<name space>/sa/<account service>

The namespace (ns) is the project in which microservices and their service accounts are executed. In this way, by using the sa, you can identify, for example, machines and users.

2.5.2 Secure communication

Istio provides two types of authentications: transport and source or end user authentication:

  1. Transport authentication between services: As described previously, communication in the data plane takes place between the Envoys, which can be ensured without changes in the code considering these three capabilities:

    1. Services (applications) communicate with your Envoy over local TCP connections.
    2. Proxies communicate using mTLS (mutual TLS).
    3. During the initial communication process, it is verified that the sa that is identified on the server's certificate has permissions to run the service.

  2. Source or end user authentication: This lets you verify the original customer making the request. Istio enables request-level authentication with JSON Web Token (JWT) validation and OpenID Connect.

In both cases, Istio stores authentication policies in the "Istio config store" through the Kubernetes API. The Pilot keeps them up to date for each proxy along with the keys, where applicable. Istio provides a "permissive mode" to validate how a policy change affects security before it becomes effective.

2.5.3 Key management

The Citadel is responsible for issuing and rotating certificates. It enables strong service-to-service and end-user authentication with built-in identity and credential management. It helps to provide each service an identity to control who can access each service.

Istio and 12-factor apps

What are 12-factor apps?

The 12 factors are good practices for creating modern applications that solve challenges related to their dynamism and scalability, mainly applying to cloud-native applications. The 12 factors are:

  1. Code: A single codebase
  2. Dependencies: Explicitly isolated and declared
  3. Configuration: Configuration stored in the environment
  4. External services: Treat external services as pluggable resources
  5. Build, release, execution: Clearly separate the construction and execution phases
  6. Processes: Run applications as stateless processes
  7. Port assignment: When publishing the services
  8. Concurrency: Scale using processes
  9. Disposability: Arrange through a fast, efficient, and gentle start-up and shutdown
  10. Parity between environments: Keep all environments as similar as possible
  11. Logs: Treat logs as event streams
  12. Administrative processes: Execute administrative and managerial tasks as a single process

This article describes how Istio is a best practice in 12-factor applications but does not explore the 12 factors in depth. It explains how Istio helps to achieve these factors most effectively and how it facilitates the construction and management of cloud-native applications.

To explore the 12 factors in detail, look at the following sources:

The 12 factors and their relationship with Istio

Code (1) and parity between environments (10)

Istio helps to apply different network and security policies for different environments, without the need to "touch" the application. So, it helps to maintain a single code while you can achieve differentiated behavior depending on the characteristics of the environment where the application is deployed.

Dependencies (2)

These policies let you establish rules for the operation of the microservices-based environment in an isolated and completely declarative manner.

Configuration (3)

Istio helps to manage the configuration of the communication rules between the services, although it does so by centralizing the point where this management is carried out. The configuration is distributed to the Envoys in their own environment.

External services (4)

Istio lets you link network and security services as an external resource. This is verified because it does not require modifying the application to include those services in the environment.

Build, release, execute (5)

This factor recommends separating the process of converting the code into an executable (build), then combining the executable with the configuration for a specific environment that's ready for execution. (Here, Istio can provide the configuration for the network and security policies that will apply.) And, finally, executing the application where it was deployed (where the policies are sent to the Envoys to be applied at runtime.

Processes (6)

This factor has a low relevance for this article because running applications in a stateless mode depends more on the application design than in the capabilities that Istio should provide.

Port assignment (7)

This factor allows a service to be visible to other services through port mapping. It is precisely at this point that Istio helps you in the linking of ports to establish rules of "who talks to whom."

Concurrency (8)

Because concurrency might require scalability, Kubernetes offers great value. However, as you have seen previously, the task of working with these environments increases as applications and environments become larger and more complex. Istio helps to manage environments that become more complex when dynamically scaled, thus, easily managing concurrency.

Disposability (9)

This factor has a low relevance or relationship with this article because the fast, efficient, and gentle start-up and shutdown of an application depends more on the application design than in the capabilities that Istio provides.

Logs (11)

Istio, through the Mixer component, allows the generation of logs related to the flow of traffic in the service mesh in a set of configurable formats. This allows for complete control of how, what, when, and where logs are generated, allowing a detailed audit of network transactions. Istio lets you create logs to be exploited by tools such as Fluentd or ELK.

Administrative processes (12)

Istio allows the execution of administrative tasks related to the configuration of network and security rules, among others. These tasks are executed through configuration files that maintain the structure that is handled in the Kubernetes configuration files. These tasks are handled independently of the application, but affect its behavior.

Conclusion and next steps

Istio is a powerful tool for managing complex and large Kubernetes-based application environments (among others), making traffic management and security tasks easier between microservices. While Istio does not cause an application (or more) to adhere to the 12 factors as best practices for cloud-native application development, it does have advantages that help to adhere in several areas.

Continue your learning journey with more Istio content on IBM Developer, and learn more about this open source service mesh platform to connect, manage, and secure microservices.

References