Basic introduction and installation verification of the open source API gateway Kong

Today I am going to introduce the open source API gateway Kong. If you search for open source products such as API gateways on Gtihub, you can see that Kong gateway is always ranked first. In addition, many companies with certain R&D capabilities will basically choose Kong gateway when selecting API gateway products, and perform secondary development and customization based on Kong gateway.

API Gateway Overview

In simple terms, the API gateway aggregates all API interface service capabilities provided by all microservices and manages them in a unified way. It is also through unified interception that the gateway can realize common requirements for API interface security, logging, current limiting and fuse breaking. To put it simply, the gateway realizes several key capabilities.

• The location of internal microservices is transparent to external access, and external applications only need to interact with the gateway
• Unified interception interface service to achieve security, logging, current limiting and fuse requirements

From this, we can see that the API gateway is similar to the ESB bus in the traditional architecture. These key capabilities are also the capabilities of the ESB service bus. However, since the ESB service bus needs to consider the access of legacy systems, it has added:

• A large number of adapters enable legacy system interface adaptation and multi-protocol conversion capabilities
• Capabilities of data replication, mapping, routing, etc.

I have made a simple comparison between the two, which you can refer to.

Developing API Gateway based on Openresty

Before talking about API Gateway, let's talk about Openresty. As mentioned in the previous article, the current architecture suitable for API Gateway is based on Openresty and the other is based on Go language.

OpenResty® is a high-performance Web platform based on Nginx and Lua, which integrates a large number of sophisticated Lua libraries, third-party modules, and most dependencies. It is used to easily build dynamic Web applications, Web services, and dynamic gateways that can handle ultra-high concurrency and high scalability.

OpenResty® effectively turns Nginx into a powerful general-purpose system Web application platform by bringing together various well-designed Nginx modules (mainly developed independently by the OpenResty team). In this way, Web developers and system engineers can use the Lua scripting language to mobilize various C and Lua modules supported by Nginx to quickly construct high-performance Web application systems that are capable of handling 10K or even more than 1000K single-machine concurrent connections.

The goal of OpenResty® is to run your web services directly inside the Nginx service, making full use of Nginx's non-blocking I/O model to provide consistent and high-performance responses not only to HTTP client requests, but also to remote backends such as MySQL, PostgreSQL, Memcached, and Redis.

• Why is Openresty suitable for API Gateway development?

For API gateway, one of the most basic core functions is to implement interface service proxy routing, which is also a standard function that Nginx reverse proxy can provide.

If the application scenario is relatively simple and only requires the unified interface to be exposed to the outside world, we can see that many companies do not actually use an API gateway, but directly use Nginx to replace the service proxy routing function of the API gateway.

Secondly, for the development of conventional API gateway middleware, after the development is completed, it still needs to rely on a Web container for deployment, and it also needs to implement various capabilities such as routing proxy by itself.

In this scenario, we can see that relying on Nginx to expand the capabilities of a Web container inside it is an important choice, which can fully utilize the proxy routing and performance advantages of Nginx itself. OpenResty itself can be seen as based on the Nginx server, with a LuaJVM embedded in its worker, which realizes the integration of the two. At the same time, it can quickly expand functions by developing and customizing various Lua libraries.

For this reason, expanding the dynamic gateway function based on Openresty is a good choice.

• Installation of OpenResty

OpenResty can be easily installed through yum under CentOS, as follows:

 //Install yum-utils
 # sudo yum install yum-utils
 //Add openresty repository
 sudo yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo  
 //Install openresty
 # sudo yum install openresty
 //Install command line tools
 # sudo yum install openresty-resty
 //The installation is successful, and it is installed in /usr/ local /openresty by default
 //test
 # sudo /sbin/service openresty start
 # sudo /sbin/service openresty stop

Note that after the installation is complete, if you access it through a browser, you need to turn off the firewall or open port 80 first.

Kong Gateway Overview

First, let's take a look at some introductions to Kong Gateway on GitHub

When we decide to transform the application into microservices, the question of how the application client interacts with the microservices also arises. After all, the increase in the number of services will directly lead to increased difficulty in deployment authorization, load balancing, communication management, analysis, and change.

In the face of the above problems, API GATEWAY is a good solution. The access restriction, security, traffic control, analysis and monitoring, logging, request forwarding, synthesis and protocol conversion functions it provides can free developers to focus on the specific logic code instead of spending time thinking about how to solve the problem of linking applications with other microservices.

Kong Gateway is a highly available and scalable API Gateway project based on OpenResty (Nginx + Lua module) and is open sourced by Mashape. Kong is built on NGINX and Apache Cassandra or PostgreSQL, and provides an easy-to-use RESTful API to operate and configure the API management system, so it can horizontally scale multiple Kong servers and evenly distribute requests to each server through the front-end load balancing configuration to handle large quantities of network requests.

KONG itself provides basic functions including HTTP basic authentication, key authentication, CORS, TCP, UDP, file log, API request flow control, request forwarding and NGINX monitoring. Currently, Kong manages more than 15,000 APIs in Mashape and provides billions of requests per month for 200,000 developers.

Kong Gateway Core Components

• Kong Server: An nginx-based server used to receive API requests.
• Apache Cassandra/PostgreSQL: used to store operational data.
• Kong dashboard: Officially recommended UI management tool, you can also use the open source Konga platform

Kong uses a plug-in mechanism for function customization. It currently has basic plug-in capabilities such as security, current limiting, logging, authentication, data mapping, etc. It can also easily customize its own plug-ins through Lua. Plug-ins are a completely dynamic pluggable mode, and plug-ins can easily expand the capabilities of the Kong gateway.

Key features of Kong Gateway core components

• Cloud-Native: Platform-agnostic, Kong runs on any platform from bare metal to containers, and runs natively on every cloud.
• Kubernetes integration: Use the official Ingress Controller to declaratively configure Kong via native Kubernetes CRDs to route and connect all L4 + L7 layer network traffic.
• Dynamic load balancing: balances traffic between multiple upstream services.
• Hash-based load balancing: Load balancing with consistent hashing/sticky sessions.
• Circuit Breaker: Intelligent tracking of unhealthy upstream services.
• Health checks: Active and passive monitoring of upstream services.
• Service Discovery: Resolve SRV records in a third-party DNS resolver like Consul.
• Serverless: Invoke and secure AWS Lambda or OpenWhisk functions directly from Kong.
• WebSockets: Communicate with your upstream services via WebSockets.
• gRPC: Communicate with gRPC services and observe traffic through logging and observability plugins
• OAuth2.0: Easily add OAuth2.0 authentication to your API.
• Logging function: Log system requests and responses via HTTP, TCP, UDP or disk.
• Security: ACL, bot detection, allow/deny IPs, etc...
• Syslog: Log to the system log.
• SSL: Set up a specific SSL certificate for the underlying service or API.
• Monitoring: Provides dynamic real-time monitoring of key load and performance server metrics.
• Forward Proxy: Enables Kong to connect to a transparent intermediary HTTP proxy.
• Authentication: HMAC, JWT, Basic, etc.
• Throttling: Block and limit requests based on many variables.
• Transformations: Add, remove, or process HTTP requests and responses.
• Cache: Cache and serve responses at the proxy layer.
• CLI: Control your Kong cluster from the command line.
• Open API interface: Kong can be operated using its RESTful API for maximum flexibility.
• Cross-region replication: Configurations across different regions are always up to date.
• Failure detection and recovery: If one of your Cassandra nodes fails, Kong will not be affected.
• Clustering: All Kong nodes automatically join the cluster and update their configuration across nodes.
• Scalability: Kong is distributed in nature and can be scaled horizontally by simply adding nodes.
• Performance: Kong handles the load easily by scaling and using NGINX at the core.
• Plugins: An extensible architecture for adding functionality to Kong and the API.

Analysis of the main functions of Kong gateway

Kong Gateway itself is built based on OpenResty, so the features of OpenResty introduced earlier have become the features of Kong Gateway. At the same time, Kong Gateway itself is naturally integrated with OpenResty and no longer needs to rely on other middleware or Web containers for deployment.

The second is the plug-in development mechanism of Kong Gateway itself. Through the plug-in, the HTTP interface request and response can be intercepted, and various API interface control and governance requirements can be implemented at the interception point. The plug-in is developed in Lua language and can be dynamically plugged in and out.

It is also very simple to integrate and manage the Kong Gateway itself. The Kong Gateway provides various Rest API interfaces, which can easily connect with the capabilities of the Kong Gateway. In other words, you can completely develop your own API management and governance platform, and use the Kong Gateway as the underlying engine.

It supports high-availability clusters, and the gossip protocol is used for discovery between nodes. When a Kong node is started, it will add its own IP information to the node list and broadcast it to any other Kong node. When another Kong node is started, it will read the node list in the database and add its own information to the list.

Let's take a look at some basic functions provided by Kong API Gateway:

• API Registry and Service Proxy

Register the original API interface and provide service proxy capabilities, that is, after different API interfaces are registered with the gateway, the gateway can provide a unified access address and interface. This is consistent with the proxy service of the ESB bus. After the service is registered with the API gateway, all internal services are transparent to the outside world, and external service access must be performed through the API gateway.

This part corresponds to the functions and capabilities of the service registration and routing parts of the Kong API Gateway.

• Load Balancing

Since the underlying layer of Kong API Gateway is also based on Nginx, the corresponding load balancing capability is actually completed through the underlying Nginx. To implement load balancing and API registration proxy on Kong, it is actually necessary to separate them into two steps.

That is, you must first configure the load balancing capability, create an Upstream group, and add multiple Targets, and then register the API.

• AUTHENTICATION Implementation

Use the OAuth 2.0 Authentication plug-in to implement user access restrictions on the user port. The specific steps are as follows:

• Register Oauth2 plugin, configuration reference
• Add Consumer and its corresponding credentials
• Apply for access token and access. Access without token will be denied.

Security and access control

Supports the most basic IP-based security access control and blacklist and whitelist settings. That is, add IP Restriction plug-in extensions to the corresponding ports and set up whitelists (only IPs in the list can access the API).

This is the same as our current ESB's IP-based access control and authorization. However, our ESB is more flexible and has an additional business system layer, which means that authorization can be performed uniformly on the business system layer.

If authorization is not granted, an access error "Your IP address is not allowed" will be returned when access is attempted.

• Traffic Control

The flow control on the current Kong gateway, from the reference on GitHub, mainly implements flow control based on the number of accesses per unit time. If the number of accesses exceeds this number, a prompt will be displayed directly indicating that the flow control constraint is met and the access is inaccessible. The current flow control does not currently support flow control based on data volume.

The current flow control does not yet see the circuit breaker operation commonly used in microservice gateways, that is, when the service concurrency or service response time exceeds a certain critical value, the service is directly fused and taken offline.

• Logging Implementation

To obtain each access log through the File-log plug-in, you need to pay attention to the write permission of the log file. For the log format, refer to Log Format. There are two specific steps.

• Add the File-log plugin to the port and set the log file path to: /tmp/file.log
• After adding the log plugin, every access will be recorded

Currently, Kong gateway logs are written to the file system, but this can be easily customized with log plugins to write logs to cache, time series database or distributed database. In addition, the current log LOGGING does not provide a front-end function interface for log query. If necessary, you need to develop the corresponding log query function yourself.

This log function is completely similar to the log of our current ESB bus, but our ESB has stronger capabilities, including statistical analysis and report viewing of subsequent service operation logs.

Kong Gateway Plugin Description

As can be seen from the above figure, Kong Gateway is based on OpenResty application server. OpenResty is a high-performance Web platform based on Nginx and Lua, which integrates a large number of sophisticated Lua libraries, third-party modules and most dependencies. It is used to easily build dynamic Web applications, Web services and dynamic gateways that can handle ultra-high concurrency and high scalability. The Kong core is built on OpenResty and has powerful plug-in extension capabilities.

After the Http request reaches the Kong gateway, before it is forwarded to the backend application, the various plug-ins of the gateway can be used to control the flow, security, log and other aspects of the request. Currently, Kong plug-ins are divided into open source version and community version. The community version has more customized functions, but the community version is charged.

Currently, the KONG open source version has a total of 28 plug-ins available, as follows:

• acl, aws-lambda, basic-auth, bot-detection, correlation-id, cors, datadog, file-log, galileo, hmac-auth, http-log, ip-restriction, jwt, key-auth, ldap-auth, loggly, oauth2, r ate-limiting, request-size-limiting, request-termination, request-transformer, response-ratelimiting, response-transformer, runscope, statsd, syslog, tcp-log, udp-log.

The above plug-ins are mainly divided into five categories: Authentication, Security, Traffic Control, Analytics & Monitoring, Logging, and others include request message processing. Plug-ins are similar to cross-cutting functions in AOP development, and can be flexibly configured for interception and control. The following selects some key plug-ins for a brief description.

• Blacklist and whitelist control capability - ip-restriction

The IP blacklist and whitelist control capabilities provided by Kong are quite strong. From the configuration items, we can see that it can be configured mainly in two dimensions, one is for all API interfaces or for specific API interfaces, and the other is for all consumers or for a specific consumer.

The IP configuration can be a segment or a specific IP address. However, the blacklist and whitelist cannot be configured at the same time. Secondly, there is currently no function to enable the blacklist or whitelist function for all services provided by a certain system.

• Logging capabilities - syslog, file-log, http-log

There are many main log plugins here. One is sysLog, which can directly write the logs generated by Kong to the system log file of the application server after configuration. If file-log is configured, it will be written separately to the file you specify. For http-log, it can record the input and output message information of the request in detail for http service requests, but where to record it specifically needs to be configured through config.http_endpoint.

If you need to write the API interface call message log to a distributed storage or database, you need to define the corresponding log plug-in to access the writing problem.

• Fuse plug-in-request-termination

This plug-in is used to define a specified request or service without performing upper-layer services, but directly return the specified content, which is used to perform circuit breaking for the specified request or specified service. Note that Kong's circuit breaker plug-in feels like a temporary disablement of the service, rather than automatically triggering the circuit breaker when a certain monitoring threshold is reached. This can also be seen from the application scenarios in the official documentation.

If this is the only way to do the circuit breaker, it is not very meaningful. However, it is useful in that when a business system is released and deployed, we can circuit breaker the business system or all the services provided by the business system.

• Rate-limiting plugin

The current limiting provided by Kong is relatively weak, that is, it mainly controls the maximum number of calls that a certain API interface service can make within a unit of time. If this number is exceeded, the gateway will directly deny access and return an error message. When I talked about current limiting and flow control earlier, I often mentioned that current limiting is actually based on the number of service calls and the amount of service call data. Current limiting is required in these two aspects. What is more important is the amount of data flow, because large data packets are often more likely to cause memory overflow exceptions.

• Security authentication plug-in

Currently, Kong gateway provides multiple authentication plug-ins including basic-auth, key-auth, ldap-auth, and hmac-auth.

The Basic-auth basic authentication plug-in generates a base64 code based on the username and password, and binds the code to the target service. In this way, when consuming the target service, you need to fill in the Base64 code information in the message header.

The key-auth authentication plug-in uses a preset keyword name, such as keynote = apices, and then sets a key-auth key for the consumer, such as key-auth=test@keyauth. When requesting the API, append apikey=test@keyauth as a parameter to the request URL or place it in the headers.

The Hmac-auth plugin sets the bound service and route to enable Hmac authentication. Then add a username and secret to the Hmac credentials of Consumer setting on the Consumers page.

• Request message capacity limit - request-size-limiting

This plug-in is used to limit the data size of the request message. It can limit a single service or display all API interface services. This is actually a very useful function, which can prevent the entire API gateway from overflowing memory due to large message calls.

• Support OAuth2.0 authentication-oauth2

Kong Gateway supports OAuth2.0 authentication. The OAuth2.0 protocol defines four authorization modes according to different application scenarios, namely Authorization code, Implicit Grant, Resource Owner Password Credentials, and Client Credentials.

Among the four methods, the most commonly used is the standard server authorization mode of authorization code, which is very suitable for server-side web applications. Once the resource owner authorizes access to their data, they will be redirected to the web application with an authorization code in the query parameter of the URL.

In the client, code is used to request an access token (access_token). And the token exchange process is completed between the two servers to prevent others or even the resource owner from obtaining the token. In addition, in this authorization mode, refresh_token can be used to refresh the token to extend the access authorization time, which is also the most complicated way.

• Simple conversion capability

The simple conversion capability is accomplished through two plug-ins: request-transformer and response transformer. The Kong gateway provides the ability to simply convert input and output messages, which will be introduced in detail later. From the current configuration, it mainly provides various simple operation capabilities such as Add, Replace, Rename, and Append for message messages.

• Comparison between Kong Gateway and other gateways

The comparison between the open source Kong gateway and other gateways is as follows.

As can be seen from the comparison chart above, Kong Gateway can better meet the needs of enterprise API Gateway in terms of functions, performance, and plug-in scalability. Therefore, we also further customize the management and control platform of Kong Gateway based on Konga.

The entire customization adds capabilities such as automatic publishing of Http Rest API interfaces based on DB adaptation, automatic registration of API services, service log collection and service log query, customization of common mapping templates, and automated testing of interface services.

Installation of Kong Gateway

Here are the instructions for installing Kong 2.2 version under CentOS 7. Note that the installation of Postgresql in CentOS 7 is no longer listed, you can refer to the online articles for installation.

 # Install kong-yum source
 $wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
 $export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
 $sed -i -e 's/baseurl.*/&\/centos\/' $major_version '' / bintray-kong-kong-rpm.repo
 $mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/ 
   
 # Clear the cache and regenerate the cache
 $yum clean all && yum makecache
 # View yum source information
 $ yum repolist
 # Update yum source
 $ yum update -y 
 
 #############################
 #Install kong via yum
 #Note that if there is incompatibility with openresty, you need to download the old version of openresty first
 $ yum install -y kong
 # View the location of the configuration file
 $whereis kong
 $kong: /etc/kong /usr/ local /bin/kong /usr/ local /kong 
 
 #############################
 #Install postgresql database (omitted)
 ############################# 
 
 #Create kong user in the database
 $ su - postgres
 $ psql -U postgres
 CREATE   USER kong;
 CREATE   DATABASE kong OWNER kong;
 ALTER   USER kong with encrypted password   'kong' ;
 #Modify kong, postgresql connection configuration
 $cp -r /etc/kong/kong.conf. default /etc/kong/kong.conf
 $vi /etc/kong/kong.conf
 database = postgres
 pg_host = 172.28.102.62
 pg_port = 5432
 pg_timeout = 5000
 pg_user = kong
 pg_password = kong
 pg_database = kong 
     
 # Initialize the database
 $kong migrations bootstrap [-c /etc/kong/kong.conf]
 Note that if you encounter the error "failed to retrieve PostgreSQL server_version_num: FATAL: Ident authentication failed for   user   "kong" , please set a password for the user and change the authorization method of postgres to MD5. The operation is as follows:
 $ alter   user kong with   password    'kong' ;
 # Start kong
 $kong start [-c /etc/ to /kong.conf]
 #Check if KONG is running correctly
 $curl -i http://localhost:8001/
 or
 $kong health
 #Stop KONG
 $ kong stop

Kong-Dashboard Installation

Kong Gateway also provides a Kong Dashboard management page. Let's take a look at the installation of the Dashboard. Before installing the Dashboard, you need to install node.js first, as follows:

 #Unzip the installation package
 $wget http://nodejs.org/dist/v8.1.0/node-v8.1.0.tar.gz
 $ tar zxvf node-v8.1.0.tar.gz
 $ cd node-v8.1.0 
 
 #Compile and install (note that compilation takes a long time)
 $./configure –prefix=/usr/ local /node/*
 $make
 $ make install 
 
 ln -s /usr/ local /node/bin/* /usr/sbin/ 
 
 #npm configuration
 npm set prefix /usr/ local  
 echo -e '\nexport PATH=/usr/local/lib/node_modules:$PATH' >> ~/.bashrc
 source ~/.bashrc

After node.js is installed, you can install Dashboard

 #Clone from git repository
 git clone https://github.com/PGBI/kong-dashboard 
 
 #Install Kong Dashboard:
 npm install -g kong-dashboard@v2 
 
 #Start kong-dashboard, note that there are changes from the old version
 #When starting, you can specify the port number yourself, such as 9001
 kong-dashboard start -p 9001 
 
 #Visit kong-dashboard
 http://localhost:9001

After startup, configure the Kong Server that the Dashboard needs to be bound to, as follows:

Access the Dashboard interface as follows:

It can be seen that the interface of Dashboard 2.0 has changed significantly from that of V1. The latest API interface registration access, routing, security management, and current limiting and circuit breaker configuration can be realized on the Dashboard. Since there is another open source Kong gateway management platform Konga, we plan to further explain and introduce the key functions of the gateway based on Konga.