All Products
Search
Document Center

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

Last Updated: Sep 28, 2020

1. Overview of Kubernetes clusters

Kubernetes (K8s) is an open source platform for automating operations of containerized applications. It is well-known and has become the mainstream choice for container users. 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.

The following figure shows a typical K8s architecture:

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

K8s clusters can be the first choice of application services. However, they provide insufficient access capabilities in effort to minimize security risks. Specifically, K8s clusters cannot directly provide services for users in large-scale applications, because this poses a high security risk. A variety of access 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:

Whether to use an ingress controller

In the preceding figure, API Gateway serves as an ingress component of a K8s cluster. It is responsible for client access and security. It communicates with an ingress controller-oriented or service-oriented internal SLB instance in the K8s cluster. If only one service is deployed in a K8s cluster, API Gateway communicates with the service-oriented internal SLB instance. If multiple services are deployed in a K8s cluster and you use the service-oriented internal SLB instance to provide services for API Gateway, a large number of SLB instances are generated, which are difficult to manage. In this case, you can use an ingress controller to serve as a layer-7 proxy and discover services in the K8s cluster. All the requests from API Gateway are sent to the ingress controller-oriented internal SLB instance. Then the ingress controller distributes these requests to the containers in the K8s cluster. In this way, only one internal SLB instance is required to access the services in the K8s cluster.

3. Access capabilities provided by API Gateway

API Gateway brings the following benefits to the entire architecture:

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

* HTTP  
* HTTP/2  
* WebSocket
			

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, SDKs for Android, and SDKs for Java. It also automatically generates API calling documents.

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 the requests you want to transmit to backend services conform to the rules.

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

g. API Gateway supports bidirectional communication. For more information, visit Implement bidirectional communication.

h. API Gateway supports both 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 Log Service. All request logs can be automatically uploaded to your Log Service for statistical analysis.

j. API Gateway supports the Mock mode, which is efficient at 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 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 in Alibaba Cloud

Alibaba Cloud allows you to quickly create K8s clusters. API Gateway is 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. In the architecture, API Gateway communicates with a K8s cluster in either of the following modes:

Mode 1: API Gateway sends requests to an ingress controller-oriented SLB instance. The ingress controller routes the requests to the appropriate services in the K8s cluster.

Mode 2: API Gateway sends requests to a service-oriented internal SLB instance. The SLB instance forwards the requests to the appropriate service in the K8s cluster.

In mode 1, only one SLB instance is required for the ingress controller to discover services and route requests. In mode 2, each service requires an SLB instance, so this mode applies to high concurrency scenarios.

4.1 Configuration in mode 1

4.1.1 Create a K8s cluster with an ingress controller installed

Follow these steps to create a K8s cluster with an ingress controller installed in the Container Service - Kubernetes console:

1. Log on to the Container Service - Kubernetes console. For more information, visit https://cs.console.aliyun.com/#/k8s/cluster/list.

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

3. On the Select Cluster Template page, select a cluster template of required specifications based on your business requirements and click Create. Set specific creation options in the Cluster Configurations, Worker Configurations, and Component Configurations steps, confirm the order, and click Create Cluster. You must select Install Ingress Controllers in the Component Configurations step.

The created cluster appears on the Clusters page.

4.1.2 Create a multi-container service in the K8s 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 - Kubernetes console. For more information, visit https://cs.console.aliyun.com/#/k8s/cluster/list.

2. In the left-side navigation pane, click Applications and then click Deployments. On the Deployments page, click Create from Template in the upper-right corner.

3. On the Create from Template page, replace the existing information in the Template field with the following resource orchestration text and 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
			

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. Log on to the Container Service - Kubernetes console. Click Ingresses and Load Balancing and then click Ingresses in the left-side navigation pane. On the Ingress page, click Create in the upper-right corner.

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

4.1.4 Authorize an ingress controller-oriented internal SLB instance in API Gateway

VPC authorization must be configured for API Gateway to access an ingress controller-oriented internal SLB instance. Follow these steps to authorize an ingress controller-oriented internal SLB instance:

1. Log on to the Container Service - Kubernetes console. Click Ingresses and Load Balancing and then click Services in the left-side navigation pane. On the Services page, select All Namespaces from the Namespace drop-down list. The Services page displays the external endpoint information of the SLB instance.

2. Log on to the SLB console. For more information, visit https://slb.console.aliyun.com/. Find the VPC that is automatically created when you created the K8s cluster, click the name of the VPC, and view its ID.

Both the VPC ID and SLB instance ID are obtained.

3. Go to the VPC Access List page in the API Gateway console. For more information, visit https://apigatewaynext.console.aliyun.com/#/eu-central-1/vpcAccess/list. Click Create VPC Access in the upper-right corner. In the Create VPC Access dialog box, specify VPC Access Name and Instance Port, set VPC Id to the obtained VPC ID and Instance Id Or IP to the obtained SLB instance ID, and click OK.

An authorization relationship is created. Remember the authorization name that you specified.

4.1.5 Create APIs

Take note of the following points on backend services when you create APIs in the API Gateway console:

1. Enter the name of the created authorization relationship.

2. Add a header parameter named host to constant parameters on the API creation page. Set this parameter to the domain name specified when you create an ingress on the ingress controller in section 4.1.3 "Create an ingress on the ingress controller that routes requests to a service."

For descriptions of the fields that are used to define an API, visit Create an API operation with HTTP as the backend service

4.1.6 Test API calling

After an API is created and published, you can use a test tool provided by API Gateway to test whether requests can be sent to the created K8s cluster. Go to the details page of the created API. Click Debug API in the left-side navigation pane. On the commonest - Debug API page, specify related parameters and click Send Request.

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 specific page.)

4.2 Configuration in mode 2

The configuration method in mode 2 differs from the configuration method in mode 1:

1. Specify an internal SLB instance when you apply for a containerized service in K8s.

2. Find the required VPC ID for this SLB instance and the internal SLB instance ID, and use these IDs to create an authorization relationship in the API Gateway console.

For more information about how to create a K8s cluster, see section 4.1.1 "Create a K8s cluster with an ingress controller installed."

4.2.1 Create a K8s service with an internal SLB instance deployed

Use a resource orchestration text file to create a service with an internal SLB instance deployed in the created K8s cluster. The differences between the resource orchestration code in this section and that in section 4.1.2 "Create a multi-container service in the K8s cluster" lie in that type is set to LoadBalancer and alicloud-loadbalancer-address-type is set to intranet in this section.

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
			

After the resource orchestration code is executed, two containers are generated by using the latest Tomcat image. The container port is 8080. A service named tomcat-service is created. This service has an internal SLB instance deployed. The service port is 80, which is mapped to port 8080.

4.2.2 Create an authorization relationship

Log on to the Container Service - Kubernetes console. Click Ingresses and Load Balancing and then click Services in the left-side navigation pane. On the Services page, view the external endpoint information of the internal SLB instance.

Like the operations described in section 4.1.4 "Authorize an ingress controller-oriented internal SLB instance in API Gateway," log on to the SLB console and view the required VPC ID and the internal SLB instance ID. Then use these IDs to create an authorization relationship.

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

Section 4 "Quickly configure K8s clusters and API Gateway in Alibaba Cloud" describes the configuration methods for two different modes. In mode 1, an ingress controller is used to discover services deployed in a K8s cluster. After the ingress controller-oriented SLB instance is authorized in the API Gateway console, all the requests from API Gateway are sent to the SLB instance.

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. Log on to the Container Service - Kubernetes console to obtain the external endpoint information of the SLB instance, and log on to the SLB console to obtain the required VPC ID. Then create an authorization relationship in the API Gateway console.

  5. Create APIs in the API Gateway console. Take note of the following points on backend services during the creation of APIs: Enter the name of the created authorization relationship. Add a header parameter named host to constant parameters on the API creation page. Set this parameter to the domain name specified when you create an ingress on the ingress controller in section 4.1.3 "Create an ingress on the ingress controller that routes requests to a service." This way, requests from API Gateway are sent to the ingress controller-oriented SLB instance. Then the ingress controller forwards the requests to tomcat-service in the K8s cluster.

In high concurrency scenarios or in scenarios with only one service deployed in a K8s cluster, deploy an internal SLB instance for the service and authorize the SLB instance for end-to-end communication between API Gateway and the service.

5.2 Comparison between mode 1 and mode 2

Mode 1: Use an ingress controller with an internal SLB instance deployed. The ingress controller can discover services and serve as a layer-7 proxy for K8s clusters. If multiple services are deployed in a K8s cluster, the ingress controller can be used to route requests, with only one internal SLB instance deployed. This facilitates O&M management and the scale-out of services for K8s clusters. We recommend that you use this mode.

Mode 2: Use a separate SLB instance. If a service in a K8s cluster runs with high traffic loads, you can create a separate SLB instance and connect API Gateway to the SLB instance to achieve higher communication efficiency. If multiple services are deployed in a K8s cluster, you need to configure an SLB instance for each service. This makes it more difficult to perform O&M.