Kong API Gateway
Last updated
Last updated
An open source API Gateway, with characteristics of a .
It has flexible deployment (meaning it can be used not only at the architecture's edge, but also managing Services integrations), Kubernetes ready and it is also extensible with Plugins.
All Kong instances have access to the database.
This distributed deployment mode is only available at paid enterprise version.
The recommended model, where only the Control Plane access the Database, reducing usage of the database.
The source of truth is the declarative .yaml or .json file that includes all the configuration and that is parsed in-memory when Kong starts.
Some Kong Plugins are not compatible with Db-Less.
The source of truth is the shared datase (postgreSQL or Cassandra) that is a required dependency for every Kong node in the same cluster.
A service is an entity that represents an (API or Microservice) upstream. (Ex.: An Invoice Microservice)
An upstream is always your available API or Microservice.
When configuring a service you can specify:
Service name;
Description of service;
Tags;
Url that will be used to reach the API or Microservice inside the network (Ex.: http://api-container:3000);
Retries, amount of retries for a request to try reaching the service;
Connection timeout;
etc.
Rate Limiting can be done on the Service level, by configuring the plugin for each Service.
Always hide headers for too many requests.
Check more on the docs.
A Route is how (the URL) Kong will reach the Service.
You create Routes from inside the Service panel in Konga.
Just setting up the url in the service is not enough.
You have to explicitly create a Route to the upstream.
When configuring a route the main configurations are:
Route name;
Route tags;
Route host (a list of hosts), a header variable that must be sent on the request (Ex.: { Host: api-url.com }) (If configured, it MUST be sent on the request headers);
Route paths (a list of paths), very important, which is part of the URL that comes from the downstream (Ex.: /api/v1);
etc.
With host and paths you can route different URLs to different services.
A consumer typically refers to an entity that consumes or uses the APIs managed by Kong Gateway. (Like applications, services, or users)
Kong allows you to manage them, apply access control policies, and monitor their API usage.
They are identified by key authorization, OAuth, or other authentication and authorization mechanisms.
They provide additional functionality and extend the use of Kong.
You may create plugins in go, python, javascript and lua.
Check third-party plugins available here.
Konga is an Admin Interface for Kong API Gateway, useful to see Kong instance's metrics and do user management.
It can also manage multiple Kongs.
