Using Istio

You have already used API Rules 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 want to route only a fraction of the traffic to a new version of a back-end service. Traffic is split up between the service's previous version 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 CRDs (Custom Resource Definitions) that you can use to define traffic rules.

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

Gateways

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

Virtual Services

Describes a configuration that affects traffic routing. It's also how multiple services can be exposed behind a single entry point (Gateway).

Destination Rules

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

Get a complete list of Istio's traffic management resources here.

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

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     

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, your developers don't have to implement security features such as traffic encryption by themselves. Using Istio, you can 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. Unlike TLS, which only allows the server to authenticate the client, mTLS allows both parties to authenticate each other. This is done by presenting certificates to each other.

Read more about Istio's security features here.

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, the response code, and so on.

Istio has many features to secure, manage and monitor your service mesh. As the project "Kyma" fully integrates Istio, SAP BTP, Kyma runtime does not. Istio's tracing capabilities are unavailable in SAP BTP, Kyma runtime, and Istio's "Kiali" dashboard is neither available with the managed runtime. However, you can use Istio's security and traffic management features in SAP BTP, Kyma runtime. To compare the open source "Kyma" project with the managed SAP BTP, Kyma runtime, review the previous lesson of this course - "Kyma Overview".