API Management in Istio Microservices Using the Kubernetes API Operator
By Pubudu Gunatilaka
- 28 Sep, 2020
A monolithic architecture is the traditional unified model for the design of enterprise software. Monolithic systems act as a composed system and the software components are interconnected and interdependent i.e. components are tightly coupled. In such an architecture, it is difficult to add new components or perform updates, which are often part of an enterprise system’s growth. Even a minor upgrade results in a number of components being updated.
In contrast, a microservices architecture (MSA) follows a modular approach and it provides the ability to update or add components without impacting other components. These modules are relatively independent. However, in MSA, there is a network of dependencies that should be monitored in order to be fault-tolerant. This is where we need a service mesh.
A service mesh’s main purpose is to manage internal service-to-service communication. In contrast, handling external client-to-service communication is the primary objective of an API gateway. Microservices in a service mesh need to be managed by applying API management. Although in some scenarios API management appears to overlap with a service mesh, they are different. To understand this, an API gateway managing north-south traffic and a service mesh managing east-west traffic can be given as an example scenario.
Let’s look at how you can manage microservices that are deployed in the Istio service mesh by applying API management using the Kubernetes API Operator.
In a Kubernetes environment, APIs are treated as first-class citizens by the Kubernetes API Operator. By using this operator, you can deploy APIs for individual microservices or combine microservices into individual APIs. This lets users disclose their microservices in Kubernetes as managed APIs. The following diagram illustrates an overview of the Kubernetes API Operator.
Figure 1: Kubernetes API Operator overview
apictl is a command-line tool that is used to interact with the Kubernetes cluster. By using the apictl tool, you can create an API. To do this, you only need to create a Swagger definition. Once you create an API using the Swagger definition via the apictl tool, a microgateway pod will be deployed in Kubernetes. You can apply API management for your microservices through this microgateway. This Github link on the K8s API Operator will provide more information. Details on all the available Kubernetes operators can be found in the Operator Hub.
Let’s move on to see how you can use the API Operator in Istio. Note that you can follow any of the following three methods to apply API management for Istio.
Figure 2: Permissive mode of the microgateway
You can deploy Istio in either Permissive mode or MTLS mode. If you opted to enable permissive mode, both HTTP and mutual TLS traffic can be accepted by a service.
Let’s assume you have an Istio sidecar injection enabled namespace named bar, which has your running microservices. By creating a Swagger definition and then creating an API in a foo namespace, you can apply API management for those running services. Then, the Kubernetes API Operator that you have installed in the cluster will deploy a microgateway pod in the foo namespace. This will expose an endpoint and API consumers can make use of it. This link provides an example of the first method.
Figure 3: MTLS mode
This method is applicable if the Istio deployment is done in the MTLS mode. In comparison to the first method, between the API microgateway and services, there is the Istio Ingress gateway. API microgateway communicates with the Istio Ingress gateway and routes the traffic. Another difference is that apart from creating an API in K8s, a virtual service needs to be adequately configured in Istio to route traffic from the Istio Ingress gateway to the applicable backend service. This method can be used in the permissive mode as well. This provides an example of this.
Figure 4: Sidecar mode of API microgateway
In this method, the API microgateway is deployed within the service mesh. A microgateway is deployed in the Istio-enabled namespace by the Kubernetes API Operator once an API is created using the swagger definition. The API microgateway pod is attached with a sidecar proxy as the sidecar injection enabled. Also, the API microgateway exposes all the services that are needed to be applied with API management. In this scenario, API consumers communicate with the Istio ingress gateway, and with respect to the definitions of the virtual service, it communicates with the API microgateway. This provides an example.
How Can We Find the Best Approach?
The easiest way to identify the best approach for your requirement is to answer the following questions.
- How are you going to expose other services that are not required to apply API management?
- Will you be able to run Istio in Permissive mode?
- Are you concerned about the number of hops in the flow?
In the first two methods, you can expose other services through the API microgateway. Also, filters, authentication, throttling, QoS, etc. can be disabled as well. In the third method, exposing other services is done through the Istio ingress gateway.
In a scenario where you are not concerned about secure communication between services inside the service mesh, you can simply go with method one and run Istio in permissive mode. In this case, compared to method two, there is no extra hop.
Compared to permissive mode, in MTLS mode, the hop count is high. Yet, in service mesh scenarios, the high count of hops is not a major worry.
Control Plane and Management Plane
As you now know how you can bring API management through an API gateway to manage Istio microservices in the data plane, let’s look at how you can apply API management for other aspects. In order to have a complete API management story, you need to apply other API management aspects such as an API marketplace, business insights, etc.
Data plane and control plane capabilities are covered with Istio. However, in order to provide management plane capabilities, you can use WSO2 API Manager. It will help to manage microservices. The following diagram shows how we can achieve this capability for the first approach’s use case.
Figure 5: Control plane and management plane
API traffic manager handles the rate-limiting while API key manager can be used to control plane token generation/validation. Through the API publisher component, which is deployed in the management plane, an API developer/publisher can easily manage the lifecycle of the APIs. Alongside the API publisher, the API developer portal (which is the API marketplace) and API analytics components are also deployed in the management plane.
An API Marketplace For Your Microservices
Figure 6: API store
An API marketplace holds a special place in the API management space. Through an API marketspace, once you expose all the microservice as APIs, external users such as application developers can use these APIs for their requirements. Through subscription plans, API providers can easily monetize their APIs. This whitepaper discusses the importance of having an enterprise API marketspace and the steps to create one.
With the use of WSO2 API Manager alongside Kubernetes API Operator, you can easily build an API marketplace.
Business Insights For Microservices
Figure 7: Viewing business insight using analytics
Even though Istio’s monitoring and tracing capabilities provide statistics on microservices, to get a deeper understanding of business insights of the exposed APIs, you need to have API analytics. To fulfill this requirement, you can use WSO2 API Manager Analytics with the Kubernetes API Operator.
In this article, we discussed three methods to apply API management for Istio microservices by using the Kubernetes API Operator. Furthermore, we showed how you can choose the most suitable method. We also briefly talked about API marketplaces and API analytics.
If you are interested in learning more about these areas, please visit this link and watch the video. Also, you can watch more videos on our YouTube channel as well.