Over a million developers have joined DZone.

Istio Service Mesh for Containers

DZone's Guide to

Istio Service Mesh for Containers

Get more information about what service meshes are and how they relate to containers, and what Istio does to provide.

· Cloud Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

This article is featured in the new DZone Guide to Containers: Development and Management. Get your free copy for more insightful articles, industry statistics, and more! 

Containers have simplified how we deploy and manage applications by abstracting the underlying infrastructure and focusing on the app and its dependencies. This allows us to run our applications on any kind of deployment platform (e.g. Kubernetes, Nomad, Mesos, etc.) whether self-managed on-premise, self-managed in the public cloud, or as a service in the public cloud. As we continue building our applications and services in the cloud and also integrate with our existing, non-cloud-native workloads, we'll end up trying to solve a lot of layer-seven networking issues like service discovery, load balancing, resiliency, and others. We want to focus on building differentiating applications and services, not on getting distracted with these new infrastructure problems. Istio is an open-source project from the folks at Google, IBM, Lyft, Red Hat, Tigera, and others that aims to solve these application networking issues irrespective of application architecture (microservices, functions, monoliths), language (Java, Go, Python), deployment platform (Kubernetes, Mesos, etc.), or even location (private datacenter, public cloud, hybrid, etc.). Containers give a unifying way to package and deploy applications across infrastructure. Istio gives application  owners and operators a way to unify how those applications talk with each other.

Istio Service Mesh

Istio is an implementation of a service mesh. A service mesh is decentralized application networking infrastructure that transparently enables applications to communicate securely and reliably, and also adds observability and traffic/policy control. A service mesh does this by using application proxies through which all of the traffic passes. These "service proxies" are deployed one-to-one with application instances and all network traffic for that application instance passes through its own proxy. So, in other words, for each instance of an application, it has its own proxy. Whenever an application needs to communicate over the network, e.g. communicate with another service or make calls to a database, its calls transparently flow through the proxy so the proxy can add additional networking functionality. This means any of our services can be enhanced to use a service mesh without even knowing it's there.

In Istio, the default proxy is a powerful layer-seven proxy named Envoy Proxy. Envoy is deployed as a "sidecar" next to our application instances and provides the bulk of the networking functionality. A "sidecar" is a helper process that gets deployed alongside our main application's process to enhance its capabilities. With containers, these side-car deployments are packaged up just like any ofour applications and are highly reusable.  Some container deployment platforms, like Kubernetes, make it easy to deploy both a side-car container and our application container as an atomic unit. This way, the application seems to have additional capabilities but with a much more composable and reusable architecture.

Resiliency and Observability from Our Data Plane

The application proxies in our architecture through which all application traffic flows make up the "data plane" in our service mesh. The data plane is where things like reliability, observability, and control can be implemented. For example, if a "shopping cart service" needs to interact with a "product catalog service" to look up details about certain items in a customer's virtual shopping cart, it may initiate this with a request/reply protocol like HTTP or gRPC. When making requests over the network, we must be wary of latency, network hops, and network failures. The product catalog service could be overloaded and return errors, or worse, introduce significant latency while processing a request.  With the data plane, we can implement resiliency outside of the applications by adding request timeouts,  retries, and circuit breaking to the request path via the data plane proxies without expecting the application to properly code this into its implementation.

Containers give a unifying way to package and deploy applications across infrastructure. Istio gives application owners and operators away to unify how those applications talk with each other.

Since all traffic would be flowing over the data plane proxies, we have a great opportunity to collect metrics and other signals about what's happening when services communicate with each other. With Istio, Envoy collects very detailed telemetry about the connections, requests, failures, and protocols that can aid debugging and overall understanding of the system at runtime. Using our previous example, the application proxy for the shopping cart service can use this telemetry to report back to its service operators that we've had a drop in the throughput of the service because calls to the product catalog are taking a lot longer to succeed.

A Data Plane Needs a Control Plane

Requests and messages flow through the data plane, which is made up of application proxies. As operators of our individual services, we need a way to set rules about how the data plane proxies should behave. We need both an API as well as higher-level constructs through which to reason and establish these rules. Istio's control plane provides three areas that  operators can leverage to manage their service mesh:

  1. Istio Pilot: Establish configuration of traffic routing and resilience policies.

  2. Istio Mixer: Handles usage policies (quota, ACL, rate limiting, etc.) and provides a central point for collecting telemetry.

  3. Istio Auth: Manages certificate issuance, revocation,  and rotation that can be used to prove identity and establish mTLS.

With the Istio control plane, we can control how traffic gets routed between our services and any resilience policies we expect callers of our service to honor. In Istio, all of the configuration is treated as YAML resource files that get sent to an API. The set of resource files you send to the API get synthesized to proxy-specific configuration that gets sent to the data plane, which then enforces the rules. For example, with Istio, we can define a VirtualService  rule to specify traffic behaviors and qualities. A VirtualService  rule looks like this:



apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService
name: catalog-route 
prefix: “/newcatalog"
host: catalog.prod.svc.cluster.local 
                subset: v2
host: catalog.prod.svc.cluster.local 
subset: v1

With this simple rule, we're specifying any service that tries to talk to the catalog.prod.svc.cluster.local  service that it should be routed to the v1 of that service. If we send requests to the catalog service at  catalog.prod.svc.cluster.local/ newcatalog, then our request should be routed to v2 of the catalog service. With Istio, we can set request-specific rules for how a request gets routed within the cluster, which gives us fine-grained control over traffic flow.

With the Istio control plane, we can control how traffic gets routed between our services and any resilience policies we expect callers of our service to honor.

With DestinationRule, we can define how load balancing and circuit-breaking work. For example, if we're trying to communicate with the catalog.prod.svc.cluster.local service, we can specify a rule like the following, which defines how consumers of the service interact with it and maintain resilience during network issues:



apiVersion: networking.istio.io/v1alpha3 
kind: DestinationRule
name: catalog-destination-rule
host: catalog.prod.svc.cluster.local 
simple: LEAST_CONN
consecutiveErrors: 5 
                  interval: 5m 
                  baseEjectionTime: 15m

In this rule, we specify to use the least-connection load balancing rule and set the "outlier detection" rules to trip after five consecutive errors. The "outlier detection" functionality behaves very closely to how a circuit breaker behaves. If it sees five errors to the same endpoint within 5m, it will remove the endpoint from the load balancing pool for a minimum period of 15m.

Creating these rules can be done by posting to the Istio API

server (Istio Pilot); however, a convenience CLI is provided with the Istio distribution. For example, you can use the istioctlCLI tool to create the previous destination rule:

 $  istioctl  create -f catalog-destination-rule.yaml

Security as a First-Class Concern

A service mesh is intended to provide a uniform communication control and observation infrastructure regardless of how you deploy your applications. With Istio, security is a first-class concern. As systems become more distributed and deployed on untrusted cloud networks, we need a way to secure that communication. Istio leverages a new spec called SPIFEE (secure production identity for everyone) to assign and validate identity of workloads. For example, Istio on Kubernetes leverages the "service-account" construct from Kubernetes and encodes that into x.509 certificates that get assigned when your application gets deployed. Istio Auth then manages the issuance of these certificates, which the data plane then uses to secure the communication transport without the application having to configure anything. We can get strong client and server verification (mutual TLS) between the services to set up and maintain.

Service mesh is a hot topic right now in the container space for good reason. Getting applications built and deployed with containers is a great abstraction to enable organizations to take advantage of cloud infrastructure; however, those workloads will need to communicate with each other in non-trivial ways. Istio provides an open-source implementation of a service mesh that aims to tackle the hard problems of service communication like traffic control, reliability, observability, and security. Check out istio.io to get started and keep up with the latest advancements.

This article is featured in the new DZone Guide to Containers: Development and Management. Get your free copy for more insightful articles, industry statistics, and more! 

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

cloud ,istio ,service mesh ,data plane

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}