I introduced the basics of a service-mesh in my last post. Here I will go into more details of isito, one of the most known service mesh in the kubernetes world.

What is istio?

Istio is an open source service mesh, and probably one of the best known. However there are others like Kong. Linkerd or Consul which are also very popular.

As we already know, istio, as any other service mesh has a data plane and a control plane.

The data plane consists of intelligent Envoy proxies, which are deployed as sidecars. They are responsible for

• Dynamic service discovery
• Load balancing
• TLS termination
• HTTP/2 and gRPC proxies
• Circuit breakers
• Health checks
• Staged rollouts with %-based traffic split
• Fault injection
• Rich metrics, which can be forwarded to monitoring systems

The control plane component is called Istiod, which manages and configures the proxies:

• converts routing rules to Envoy-specific configurations and propagates them to the Envoy proxies
• apply policies and ensure that they’re enforced, and that resources are fairly distributed among consumers
• offers an Traffic Management API

Deployment of istio

The way istio s deployed ultimately depends on your setup. There are a bunch of different approaches to be taken:

• single or multiple cluster

  Deployment to a single cluster with a single mesh network is probably the easiest one. But multicluster deployments give you a greater degree of isolation and availability but increase complexity.

• single or multiple network

  You can have a single network. where all workload instances can reach each other or you may have multiple networks. A multi-network offer additional capabilities (e.g. fault tolerance, ..) but is more complex as each network can reach the other only trough an Istio gateways

• single or multiple control plane

  With multi-cluster networks you can have a shared control plane instance, where the control plane runs in one or more *primary clusters and manages t connected remote cluster(s). Multiple control planes allows high availability.

  Alternatively the control plane could be deployed to an external control plane - this may be very well a dedicate cluster - which then manages the mesh workload.

• single or multiple mesh

  A single mesh is obviously the simplest one but all service names are unique and all workloads share a common identity.

  Multiple meshes on the other hand, allow to set organizational boundaries, stronger isolation and reuse of service names.

Here an example of a multi-control deployment:

In order to fully understand what these different deployment methods mean and what you have to consider, I recommend to read trough the official documentation.

What does istio offer?

Traffic Management

Istio allows to manage the traffic between services and allows you to control how your traffic flows - e.g. redirect certain % of your traffic to a never version of a service, apply different load balancing policies (default is round-robin). In order to do so, istio maintains an internal service registry which contains all services and their corresponding endpoints. This registry is populated by istio itself, as it connects to a service discovery system. The rules/settings are implemented as CDRs:

• virtual service lets you configure how requests are routed to a service within an Istio service mesh. They consists of a set of routing rules, which tell the Envoy proxy to which destination the virtual service’s traffic shall be sent - see virtual service example and Canary Deployments using Istio for more details. There are two things which you can to with virtual services

  • Address multiple application services through a single virtual service
  • Configure traffic rules in combination with gateways to control ingress and egress traffic.

  You can define failure recovery and fault injection features with your virtual servicer

  • timeouts is the time the Envoy proxy waits for replies
  • retries is the maximum number of times an Envoy proxy tries to connect to a service
  • circuit breakers limits for calls to individual hosts within a service (e.g. number of concurrent connections) and stops further connections once the limit is reached
  • fault injection introduces and error into a system to test the failure recovery capacity of your application. This can be delays to mimic network latency or aborts which mimic crash failures

• destination rules define what happens to routed traffic for the destination - see Destination Rule reference. These rules are applied after the virtual service routing rules and allow to do things like change the default load balancin As every configuration. also theseg policy or define client tls settings

• gateways manage inbound and outbound traffic for your mesh and are applied to standalone Envoy proxies that are running at the edge of the mesh (not the ones running in the sidecar).

• service entires is an entry into the internal istio service registry, and allows you to manage traffic for services running outside of the mesh.

  You don’t need to add a service entry for every external service that you want your mesh services to use. By default, Istio configures the Envoy proxies to passthrough requests to unknown services. However, you can’t use Istio features to control the traffic to destinations that aren’t registered in the mesh.

• sidecars allow to limit the ports and protocols an Envoy proxy accepts and also limit the service the [Enovy proxy] can reach.

Security

Security automatically secures your services through managed authentication, authorization, and encryption of communication between services. We know, to establish secure connections, for the mutual authentication process, the parties on both ends have to exchange credentials containing their identity information.

• istio identity model uses service identity to determine and verify the identity, from the exchanged credentials used in the mutual authentication purposes. On the client side, the server’s identity is checked against the secure naming information, whereas the server checks the authorization policies and ensures that the client can only access what he is allowed to. The service identityc an represent a human user, an individual workload, or a group of workloads.

• Envoy proxy and istiod provide automate key and certificate rotation

  

• Istio provides peer authentication for service-to-service authentication, using mutual TLS authentication. Istio also provides request authentication for end-user authentication, using JSON Web Token (JWT) and any OpenID Connect providers. The authentication relies on AuthorizationPolicies which are stored in the Istio config store and propagated to the proxies.

  

• Istios Authorization allows fine grained access control on mesh-, namespace- and workload level

An Authorization Policy includes a selector, an action, and a list of rules

• The selector field specifies the target of the policy
• The action field specifies whether to allow or deny the request
• The rules specify when to trigger the action
  • The from field in the rules specifies the sources of the request
  • The to field in the rules specifies the operations of the request
  • The when field specifies the conditions needed to apply the rule

For more details and examples checkout the Authorization Policy and Authorization Policy.

Observability

Istio generates detailed telemetry for all service communications within a mesh:

• Metrics for latency, traffic, errors, and saturation for each service, as well as metrics for the control plane. Istio collects metrics collection with the sidecar proxies - it can be configured what metrics shall be collected - as well as metrics for monitoring service communications and the istio components itself.
• Distributed Traces to understand the data flow and dependencies of the services and supports different backends like Zipkin, Jaeger, Lightstep, and Datadog
• Access Logs generates a full record of each request, including source and destination metadata