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.
After completing this lesson, you will be able to:
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:
Get a complete list of Istio's traffic management resources here.
With an installation of Istio on Kubernetes, an Ingress Gateway is installed by default. This gateway is exposed through an external IP address on your cluster.
With Gateway resources, you can configure the default Istio Ingress Gateway to expose your services through a custom domain name, for example. You can also configure multiple gateways to expose your services through different domains. In "Kyma", you also get a Kyma Gateway installed by default. This gateway is used to expose your services through the Kyma domain.
A Gateway resource looks like this:
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"
With Virtual Service resources, you can define the routing rules for your services. You can specify the routing rules based on the HTTP request path, headers, or query parameters.
A Virtual Service resource looks like this:
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
This Virtual Service resource defines a routing rule for the shop
service. The rule routes 90% of the traffic to version v1
of the service and 10% to the v2
version.
Istio supports way more features to define routing rules. You can find more information about it here.
A Destination Rule lets you group your Kubernetes service by subsets and define rules for each subset.
A Destination Rule resource looks like this:
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
The shop
service is grouped into two subsets based on versions in the example above.
Read more about Destination Rules here.
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:
Read more about Istio's observability features here.
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".
In this lesson, you expanded your knowledge of Istio: you discovered how Istio helps with traffic management, security, and observability.
Log in to track your progress & complete quizzes