kdocs
GitHub
T&O - Servers
T&O - Servers
  • Gateway
    • API Gateway
    • Kong API Gateway
      • New Project
  • Service Mesh
    • Service Mesh
    • Istio
      • New Project
  • Virtualization
    • Docker
      • Dockerfile
      • Docker Compose
      • Optimizing Images
    • Kubernetes
  • Web Servers
    • Nginx
  • Windows
    • WSL 2
Powered by GitBook
On this page
  • About
  • Deployment Models
  • Distributed
  • Hybrid
  • DB-Less
  • With Database
  • Getting Started
  • Kong Services
  • Kong Routes
  • Kong Consumers
  • Kong Plugins
  • Konga
  1. Gateway

Kong API Gateway

PreviousAPI GatewayNextNew Project

Last updated 3 months ago

About

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.

Deployment Models

Distributed

All Kong instances have access to the database.

This distributed deployment mode is only available at paid enterprise version.

Hybrid

The recommended model, where only the Control Plane access the Database, reducing usage of the database.

DB-Less

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.

With Database

The source of truth is the shared datase (postgreSQL or Cassandra) that is a required dependency for every Kong node in the same cluster.

Getting Started

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.

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.

Check third-party plugins available .

Kong Services
Rate Limiting
Kong Routes
Kong Consumers
Kong Plugins
here
Konga
Micro Gateways
Kong Gateway | Kong DocsKong Docs
Logo
Drawing
Drawing
Drawing
Drawing
Drawing
Drawing