All Products
Search
Document Center

API Gateway:Powerful access capabilities provided by API Gateway for containerized Kubernetes application clusters

Last Updated:Sep 27, 2023

1. Overview of Kubernetes clusters

Kubernetes (K8s) is a widely known open source platform and the first choice for developers to deploy applications in containers. K8s leverages container-based technologies to schedule and scale nodes in clusters. This allows you to easily create an enterprise-level containerized application cluster. This cluster provides the following capabilities:

  • Automates container deployment and replication.

  • Scales containers as required.

  • Groups containers and supports load balancing among the containers.

  • Easily upgrades containerized applications.

  • Replaces containers if they fail to work.

2. Architecture with API Gateway that serves as the access layer of K8s clusters

K8s clusters can be used as application services. However, the clusters do not have sufficient access processing capabilities, especially in large-scale applications, in which case the clusters cannot directly provide services due to high security risks. A variety of access processing capabilities are integrated into API Gateway. API Gateway serves as a mature cloud service that is used to access K8s application clusters. This greatly improves the service capabilities of K8s application clusters. This architecture serves as a standard architecture for large-scale Internet applications. The following figure shows an architecture with Alibaba Cloud API Gateway deployed:

When to use an ingress controller

As shown in the architecture diagram, API Gateway processes client requests for and safeguards a K8s cluster as its bridgehead. API Gateway communicates with the internal Classic Load Balancer (CLB) instance of an ingress controller or that of a service in the K8s cluster. If the cluster has only one service, API Gateway communicates directly with the internal CLB instance associated with this service. If the cluster has multiple services, API Gateway cannot communicate with the internal CLB instances associated with the services because too many CLB instances complicate resource management. Instead, API Gateway communicates with the CLB instance associated with the ingress controller of the cluster. In this case, the ingress controller helps discover services and forward requests to containers in the cluster. Therefore, only one internal CLB instance is required to provide all services in the cluster.

3. Access capabilities provided by API Gateway

API Gateway brings the following benefits to the entire architecture:

a. API Gateway communicates with clients over a variety of protocols. These protocols include:

* HTTP  
* HTTP2  
* WebScoket
                        

b. API Gateway uses various methods to secure communications with clients.

* Defines an authorization relationship between APIs and apps. Only the authorized apps are allowed to call APIs.
* Provides a full-link signature authentication mechanism for the communication between clients and API Gateway, and between API Gateway and backend services. This mechanism prevents data tampering during the transmission of requests.
* Allows you to use your SSL certificates for HTTPS communication.
* Supports the OpenID Connect security certification method.
                        

c. API Gateway automatically generates SDKs for iOS, Android, and Java. It also automatically generates API documentation to help callers make calls.

d. API Gateway supports mapping between frontend and backend parameters. Parameters in a request can be mapped to any parameter location in a backend request.

e. API Gateway supports parameter cleansing. When you define an API, you can specify rules such as the parameter type and regular expression. API Gateway helps you determine whether the parameters in a request to be transmitted to backend services conform to the rules.

f. API Gateway supports throttling by user, application, or API.

g. API Gateway supports two-way communications.

h. API Gateway supports monitoring and alerting based on the number of requests, the number of errors, response timeout, and traffic. All alerts are sent by using text messages or emails within one minute after an error occurs.

i. API Gateway is integrated with Alibaba Cloud Simple Log Service. All request logs can be automatically uploaded to your Simple Log Service resources for statistical analysis.

j. API Gateway supports the Mock mode, which is efficient for use during joint debugging between different departments.

k. API Gateway allows you to configure an IP address whitelist or blacklist for callers. l. API Gateway allows API providers to charge API callers for API calls in Alibaba Cloud Marketplace.

Alibaba Cloud API Gateway is a mature cloud service that has been released for years. Its stability and performance have been refined over the years by Alibaba Cloud engineers. API Gateway can meet your high performance requirements.

4. Quickly configure K8s clusters and API Gateway on Alibaba Cloud

Alibaba Cloud allows you to quickly create K8s clusters. API Gateway can be easily integrated with K8s clusters in the same region. The following sections describe how to build the architecture described in Section 2 "Architecture with API Gateway that serves as the access layer of K8s clusters" in Alibaba Cloud. As described in Section 2, API Gateway communicates with a K8s cluster in two modes. In the first mode, API Gateway communicates with the associated CLB instance of an ingress controller, in which case the ingress controller routes requests to services in a K8s cluster. In the second mode, API Gateway communicates with the associated CLB instance of a service in a K8s cluster, in which case the CLB instance forwards requests. The first mode requires only one CLB instance that precedes the ingress controller. The ingress controller discovers services and routes requests. The second mode requires a CLB instance to precede each service and is suitable for high-concurrency scenarios.

4.1 Configuration in mode 1

4.1.1 Create a K8s cluster

Follow these steps to create a K8s cluster that has an ingress controller installed in the Container Service ACK console:

1. Log on to the Container Service ACK console. Link: https://cs.console.aliyun.com/#/k8s/cluster/list.

2. Click Create Kubernetes Cluster in the upper-right corner.

3. Create a cluster based on your business requirements. Select an ingress in the Component Configurations step.

4. View the created cluster on the Clusters page.

4.1.2 Create a multi-container service in the cluster

Perform the following operations to create a service that consists of two containers in the K8s cluster. Each container is generated by using the latest Tomcat image. The container port is 8080. The service port of the ingress controller is 80.

1. Log on to the Container Service ACK console. Link: https://cs.console.aliyun.com/#/k8s/cluster/list.

2. Click the created cluster. On the cluster details page, choose Workloads > Deployments in the left-side navigation pane. On the Deployments page that appears, click Create from YAML in the upper-right corner.

3. Copy the following code and paste it in the editor on the Create page that appears. Then, click Create.

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: tomcat-demo
  labels:
    app: tomcat
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:latest
        ports:
        - containerPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: tomcat
  sessionAffinity: None
  type: NodePort
                        

Code description: Two containers are created based on the latest Tomcat image, and the container service port is 8080; a service named tomcat-service is created, and the service port is 80, which maps to the 8080 port.

A K8s cluster is created. Two containers are created under this cluster, with each running the latest Tomcat. These two containers form a stateless application and support a service named tomcat-service. You can go to the details page of the stateless application and view its running status. Currently, API Gateway cannot access this service. You need to create an ingress on the ingress controller that routes requests to this service for end-to-end communication.

4.1.3 Create an ingress on the ingress controller that routes requests to a service

Deploy a service for the stateless application and create an ingress for this service on the ingress controller. This way, when API Gateway sends requests to K8s services, the ingress controller forwards the requests to appropriate K8s services based on configured ingress information. Follow these steps to create an ingress:

1. On the details page of your cluster, choose Network > Ingresses. Then click Create Ingress in the upper-right corner.

2. In the Create Ingress dialog box, specify relevant parameters, such as the domain name of a service and the listening port.

4.1.4 Create an access authorization for the VPC of the internal CLB instance

If you want API Gateway to access the internal CLB instance of an ingress controller, you must use the IDs of the corresponding virtual private cloud (VPC) and CLB instance to create a VPC access authorization. The following procedure shows how.

1. Log on to the Container Service ACK console. On the details page of your cluster, choose Network > Services. On the Services page that appears, select All Namespaces from the Namespace drop-down list. The internal endpoint of the CLB instance of the ingress controller is displayed in the list.

2. Log on to the Server Load Balancer (SLB) console (link: https://slb.console.aliyun.com/). Find the VPC that was automatically created when you created the K8s service, and click the VPC to go to its details page. On the page that appears, record the VPC ID.

Up to now, you have obtained the VPC ID and CLB instance ID that are required to create the VPC access authorization.

3. Go to the VPC access authorizations page in the API Gateway console (link: https://apigateway.console.aliyun.com/#/cn-beijing/vpcAccess/list) and click Create Authorization in the upper right corner. In the Create VPC Access dialog box, enter the obtained VPC ID and CLB instance ID in the corresponding fields, specify other parameters based on your requirements, and click Confirm. The VPC access authorization is created. Remember or record the authorization name.

4.1.5 Create an API

Take note of the following items about the backend service when you create an API in the API Gateway console:

1. The name of the created authorization is required.

2. A constant parameter whose name is host and location is header is required. Set the parameter value to the domain name specified in Section 4.1.3.

4.1.6 Test the API

After an API is created and published, you can test whether requests can be sent to the created K8s cluster in the API Gateway console. Procedure: 1. Go to the details page of the created API. 2. Click Debug API in the left-side navigation pane. 3. On the Debug API page, test the API as prompted.

A request is sent to a container in the K8s cluster and a response with the 404 error is returned by Tomcat. The 404 error is reported because you did not configure the corresponding page.

4.2 Configuration in mode 2

The configurations for mode 2 are different from those for mode 1 in two ways. You must specify to generate an internal CLB instance when you apply for a service in the K8s cluster. You must use the IDs of the CLB instance and the VPC where the CLB instance resides to create a VPC access authorization in the API Gateway console. For more information about how to create a K8s cluster, see Section 4.1.1. This section describes how to create a K8s service that has an internal CLB instance and obtain the IP address of the internal CLB instance. Operations after you obtain the IP address are the same as Section 4.1.4.

4.2.1 Create a K8s service that has an internal CLB instance

After the operations in Section 4.1.1, a K8s cluster is available. You can use the following template to create a service that has an internal CLB instance in this cluster. Take note that the following code is different from the sample code in Section 4.1.2 in the last line, in which Type is set to LoadBalancer and the CLB instance is specified as an internal instance.

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: tomcat-demo
  labels:
    app: tomcat
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:latest
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: tomcat
  type: LoadBalancer
                        

Code description: Two containers are created based on the latest Tomcat image, and the container service port is 8080; a service named tomcat-service is created with a preceding internal CLB instance, and the service port is 80, which maps to the 8080 port.

4.2.2 Find the endpoint of the internal CLB instance

On the details page of your cluster, choose Network > Services. On the Services page that appears, find the endpoint of the internal CLB instance that precedes the created service.

Then, follow the operations in Section 4.1.4 to obtain the VPC ID and CLB instance ID, and create a VPC access authorization in the API Gateway console.

5. Summary

The first three sections of this topic describe the capabilities provided by K8s clusters and API Gateway. This topic also describes an architecture in which K8s clusters and API Gateway are integrated as backend application services. This architecture achieves higher availability, reliability, and flexibility. The system supports dynamic scaling, dynamic routing, multi-protocol access, automatic SDK generation, and bidirectional communication.

5.1 Configuration summary

The last section describes how to use API Gateway in K8s clusters. The key lies in the use of an ingress controller to discover services and the use of a VPC access authorization to route requests to CLB instances. Configuration procedure in mode 1:

  1. Create a K8s cluster with an ingress controller installed.

  2. Execute resource orchestration code to create two containers on which the latest Tomcat runs and create a service supported by these containers.

  3. Create an ingress that routes requests to the service on the ingress controller.

  4. Obtain the ID of the CLB instance associated with the ingress controller and create a VPC access authorization in API Gateway.

  5. Create an API in the API Gateway console. Remember to use the created VPC access authorization for the backend service and add a constant parameter named host whose value must be set to the domain name of the ingress. This way, API requests are sent to the CLB instance associated with the ingress controller, and the ingress controller routes the requests to the Tomcat service in containers.

For high-concurrency or single-service scenarios, you can directly associate a CLB instance with the service and authorize API Gateway to access the CLB instance.

5.2 Comparison

1. CLB + ingress controller: An ingress controller can be used for service discovery and application-layer proxy for K8s clusters. If a K8s cluster contains multiple services, an ingress controller can be used to route requests by using only one internal CLB instance. This facilitates O&M, management, and cluster scale-out. We recommend that you use this mode.

2. CLB: If a service has heavy loads in a cluster, you can create a separate CLB instance for the service and connect API Gateway directly to this CLB instance for higher communication efficiency. However, if you configure a CLB instance for each of multiple services in a cluster, O&M and management become complicated.