Kubernetes API Operator: Apply API Management for Istio Microservices

A service mesh’s primary objective is to handle internal service to service communication, while an API Gateway handles external client to service communication. It is required to apply API Management for the microservices that are in a service mesh. Although they overlap in some cases, service mesh’s focus and API Management focus is different. For an example, API gateway handles north south traffic, while service mesh handles east west traffic. 

Let’s look at how we can apply API Management for the microservices that are deployed in Istio, service mesh using the Kubernetes API Operator.

The Kubernetes API Operator makes APIs first-class citizens in the Kubernetes ecosystem. Similar to deploying microservices, you can now use this Kubernetes API operator to deploy APIs for individual microservices or compose several microservices into individual APIs. With this, users will be able to expose their microservice as managed APIs in a Kubernetes environment without any additional work.

Refer below for an overview of the Kubernetes API Operator.

You only need to come up with a Swagger definition and then create an API using the apictl, which is a command-line tool to interact with the Kubernetes cluster. This will deploy a microgateway pod in Kubernetes, which, in turn,  allows you to apply API management for your microservices. You can refer to this Github link on the K8s API Operator for more details. You can also find the available operators for Kubernetes in Operator Hub.

Along with the API operator, you can use an API marketplace, which allows developers and external users to discover APIs and use API analytics to obtain business insights. 

Let’s see how we can apply the API Operator for Istio.

There are three approaches we can follow when applying API Management for Istio. 

Approach 1 - Permissive Mode

Istio can be deployed in Permissive mode or MTLS mode. If permissive mode is enabled, a service can take both HTTP and mutual TLS traffic. 

In this approach, let’s assume that your microservices are running on bar namespace, where Istio sidecar injection is enabled. When you want to apply API management for those services, you can create a Swagger definition and create an API in foo namespace. As we have installed the Kubernetes API Operator in the cluster, it will deploy a microgateway pod in foo namespace and expose an endpoint for API consumers. 

An example can be found in https://github.com/wso2/K8s-api-operator/tree/master/scenarios/scenario-13/S01-APIM_for_Istio_Services

Approach 2  - MTLS Mode

This approach can be used when Istio is deployed in MTLS mode. If we compare this approach with approach 1, the only difference is between the API gateway and the services you have the Istio Ingress gateway. The API microgateway talks to the Istio ingress gateway and routes traffic. In addition to creating an API in K8s, you need to add a virtual service in Istio to route from the Istio Ingress gateway to the relevant backend service.

This approach is not limited to MTLS mode, but this works in the permissive mode as well.

An example can be found in https://github.com/wso2/K8s-api-operator/tree/master/scenarios/scenario-13/S02-APIM_for_Istio_Services_MTLS

Approach 3  - Sidecar Mode

In this third approach, we are deploying the API microgateway inside the service mesh. When you create an API using the Swagger definition inside the Istio enabled namespace, the Kubernetes API Operator will deploy a microgateway in that namespace. As the sidecar injection is enabled, a sidecar proxy is attached to the API microgateway pod as well. The services that are required to apply API management are exposed via the API microgateway. API consumers can talk to the Istio Ingress gateway, and, based on the virtual service definitions, it talks to the API microgateway.

An example can be found in https://github.com/wso2/K8s-api-operator/tree/master/scenarios/scenario-13/S03-API_Gateway_In_Istio_As_A_Service

Which approach is better for you?

In order to identify the best approach, you need to answer the following questions.

1. How do you want to expose other services that are not required to apply API Management?

In approach one  and two, if you want to expose other services to the outside, then, it has to be via the API microgateway. You can disable filters and disable authentication, throttling, QoS, etc. In the third case, you can expose those services via the Istio ingress gateway.

2. Can you run Istio in Permissive mode?

There can be cases where you are not worried about secure communication between services within the service mesh. In that case, you can run Istio in permissive mode and you can go with approach 1. In this approach, there is no additional hop when compared to approach 2. 

3. Do you have a concern about the number of hops in the flow?

When comparing approaches one and two, the hop count is more in approach two. However, in the service mesh use cases, this increase is not a big concern. 

Control Plane and Management Plane 

Up To now we discussed how we can position our API Gateway in the data plane for Istio microservices to apply API Management. But API Management story is not completed unless you bring other API Management capabilities such as API marketplace, business insights, etc.

While Istio provides data plane and control plane capabilities, WSO2 API Manager provides management plane capabilities to manage microservices. The full use case looks like as below for approach 1.

We can deploy API traffic manager for rate limiting and API key manager for token generation/ validation in the control plane. In the management plane, API publisher is deployed where API developer/publisher can manage the life cycle of the APIs. API developer portal (marketplace) and API analytics also reside in the management plane.

Build an API marketplace for your microservices

When you look at the typical API management story, an API marketplace is an important aspect. When you are exposing your microservices as APIs, an API marketplace is built so that application developers or external users can discover available APIs. The marketplace allows the API providers to monetize their APIs by creating subscription plans. Refer to this whitepaper to learn more about an API marketplace; in it we discuss the advantages of building an enterprise API marketplace and the required steps to effectively launch one. 

To build the API Marketplace, you can use WSO2 API Manager along with the K8s API Operator.

Business insights for your microservices

Istio's monitoring and tracing capabilities provide useful statistics relating to microservices. However, if you require deeper business insights into your exposed APIs, then you need API analytics. This helps you to grow your business based on the business insights gathered here. 

With K8s API Operator, you can plug WSO2 API Manager Analytics to get business insights.

Summary 

In this article, we discussed how we can apply API management for Istio microservices using the Kubernetes API Operator. There are three approaches, and, when looking for the most suitable, you have to consider several aspects. The API marketplace helps app developers and external users to discover available APIs. Using API analytics, you can get the business insights for your APIs.