Using Istio

You have already used APIRules to expose your services to the outside world. To secure, connect, and monitor the services, you want to use Istio and learn more about its features and mechanisms.

Traffic management, in a nutshell, is the ability to take control of the flow of traffic in your service mesh. Without traffic management, requests are routed to any available service instance. In many cases, this is not desirable. For example, you want to redirect traffic based on rules, such as to forward only a certain percentage of traffic over to a new version of a service (a.k.a canary deployment). Or, before you let customers consume the new version of a service, you want to test it internally. So you can only route traffic to the latest service version for internal users (a.k.a dogfooding). Traffic management enables you to implement these scenarios.

The image depicts a scenario where you route only a fraction of the traffic to a new version of a backend service. Traffic is split up between the service's previous and the new version. With such a setup, you can test the new version of the service in production only on a subset of the users and roll back quickly if something goes wrong.

If the new version of the service works as expected, you can increase the percentage of traffic routed to the new version of the service.

But how does this work? Istio has a set of CustomResourceDefinitions (CRDs) that you can use to define traffic rules.

In Istio, you have several resources that you can use for traffic management:

Gateway

It's a Load Balancer operating at the edge of the mesh. The Gateway handles incoming or outgoing HTTP/TCP connections.

VirtualService

Describes a configuration that affects traffic routing. You can use it to expose multiple services behind a single entry point (Gateway).

DestinationRule

Specifies rules that apply to traffic intended for the service after routing.

For a complete list of Istio's traffic management resources, see Traffic Management.

1234567891011121314
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: foo-gateway
spec:
    selector:
        istio: ingressgateway 
    servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*.foo.com"

12345678910111213141516171819
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: shop-route
spec:
  gateways:
    - foo-namespace/foo-gateway
  hosts:
    - shop.foo.com
  http:
  - route:
    - destination:
        host: shop
        subset: v1
      weight: 90
    - destination:
        host: shop
        subset: v2
      weight: 10     

12345678910111213
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: shop-route
spec:
    host: shop
    subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Istio's security features allow you to control the service mesh's security. With Istio, you don't have to implement security features such as traffic encryption by yourself. Istio enables you to secure the service-to-service communication in your service mesh by encrypting the traffic. These security features are essential to defend yourself against man-in-the-middle attacks and prevent unauthorized access to your services by validating the caller's identity.

Securing the communication between services in your cluster is one of the primary use cases for Istio. Istio provides traffic encryption with mutual TLS (mTLS) and allows you to authenticate the caller's identity. Mutual TLS is a protocol that allows the client and the server to authenticate each other. Mutual TLS is a protocol that allows the client and the server to authenticate each other. Unlike TLS, which only allows the server to authenticate the client, mTLS is a protocol that allows for mutual authentication by presenting certificates to each other.

To learn more about Istio's security features, see Security.

Since Istio intercepts all the traffic in your service mesh, it can provide you with detailed telemetry data for all service communication. This telemetry provides observability into the service mesh. To provide observability based on the collected telemetry data, Istio offers the following types:

Metrics

Metrics are numerical measurements that are used to track the state of a system. Istio provides a set of metrics that are used to monitor the health of the mesh, such as latency, traffic, errors, and so on.

Distributed Traces

In a cloud-native microservice architecture, a user request often flows through dozens of different microservices. With distributed tracing, you can trace the path of a request through the entire service mesh. Distributed tracing allows you to monitor the performance of your services and to identify bottlenecks.

Access Logs

Istio can also provide you with access logs for all the traffic that flows through the service mesh. Access logs provide detailed information about the traffic, such as the source and destination of the request or the response code.

In SAP BTP, Kyma runtime, the Telemetry module provides observability features that can help you collect all relevant data in a Kyma cluster, for example, those provided by the Istio service mesh. The Telemetry module also enriches the data and ships it to a backend for further analysis. To learn more, see Describing Observability in Kyma.