Kong
Kong is an API gateway: a proxy that sits in front of your services and decides which request goes where, who is allowed to make it, how often they may make it, and what gets recorded about it. That sounds like a small job, but it is the job that every other part of your platform is quietly leaning on. The moment more than one team publishes an API, the interesting questions - authentication, quotas, versioning, auditing - stop belonging to any single service and start belonging to the gateway.
This course works through Kong in the order you would actually use it. You start a gateway and publish one route. You learn the three entities everything else hangs off - Service, Route and Plugin - and how Consumers and credentials fit on top. You then configure the things a gateway is judged on: authentication, rate limiting and request transformation. After that come the topics that separate a working gateway from a production one: keeping several environments in sync, scaling out without a single point of failure, and the observability you need to answer “what happened to this request?” at two in the morning.
Every example here is written against Kong Gateway 3.x and the configuration is shown in the declarative YAML format that you would commit to Git, because that is the format you want in version control. The Admin API equivalents are given alongside, since you will use both: the API when you are exploring, declarative config when you are shipping.
- Introduction to Kong - what a gateway is for, where it sits relative to your services, and the deployment modes you can choose from.
- Kong Fundamentals - Services, Routes, Upstreams, Consumers, credentials and the Admin API, with a first complete route published end to end.
- Advanced Practice - key authentication, JWT, OAuth 2.0, rate limiting and request transformation, and how to keep several environments consistent.
- Advanced Techniques - writing a custom plugin, running Kong alongside a service mesh, and tuning the gateway for throughput.
- Kong in Practice - the three deployment shapes teams actually use: a microservice gateway, an internal API portal, and a gateway shared by many teams.
- Kong Mastery - the mental model in one page, a troubleshooting playbook for the failures you will actually hit, and a production readiness checklist.
You should be comfortable with HTTP - methods, status codes, headers, JSON - and you should have run at least one service that other systems call. You do not need prior gateway experience, and you do not need Kubernetes.
If you are on the other side of the gateway - building the services that Kong fronts - this course still pays for itself, because it explains exactly what the gateway will do to your requests before they reach you.
Set up a local gateway before you start the second chapter, and keep it running for the rest of the course:
docker run --rm --name kong \
-p 8000:8000 -p 8443:8443 -p 8001:8001 \
-e "KONG_DATABASE=off" \
-e "KONG_DECLARATIVE_CONFIG=/kong/declarative/kong.yml" \
-v "$PWD/kong.yml:/kong/declarative/kong.yml:ro" \
kong:3.8The proxy listens on 8000 and 8443; the Admin API listens on 8001. Everything in this course can be exercised against that container with curl.
Kong’s core concepts - Services, Routes, Plugins, Consumers - have been stable for years, and everything in this course works on Kong Gateway 3.4 or later. Two areas move faster than the rest: the router, which gained an expression-based flavor, and the plugin set, which grows with every release. Where a feature is version-sensitive, the version is stated explicitly.
Before you read on, write down your answer to this: a service called orders is reachable at http://orders.internal:8080, and two different client teams need different behaviour from it - the payments team must present an API key, while the internal reporting tool may call it without any credentials but must not exceed ten requests per minute.
Which Kong objects do you create, and where do you attach each one? Name the object, the field, and the reason you chose that level rather than another.
Approach:
The question is really asking whether you can separate the four decisions a gateway makes and attach each to the right object. Kong’s model is: a Service says where traffic goes, a Route says which traffic, a Plugin says what happens to it, and a Consumer says who is calling. Rate limiting and authentication are both Plugins, but they are scoped differently - authentication is per-consumer because it identifies a caller, while the rate limit is per-consumer too but is often left global with the limit_by setting choosing the dimension.
The second half of the question is a deliberate trap: “must not exceed ten requests per minute” with no consumer identity mentioned. If the reporting tool is anonymous, a per-consumer rate limit has nothing to count. The limit has to be applied by IP or by path instead, or the tool needs to authenticate too.
Steps:
-
Service - create one, named
orders, pointing athttp://orders.internal:8080. The upstream address lives on the Service and nowhere else. The URL, the retries and the timeouts all belong here. -
Route - create one on that Service, with
pathsof/ordersandstrip_pathset totrue, so the gateway forwards/orders/42upstream as/42. Whether the upstream expects the prefix is a decision you make deliberately and record. -
Authentication plugin - attach
key-authto the Service, not to the Route and not globally. Scoping to the Service means every route in front ofordersis protected, including any future route you add. Global scope would demand an API key from unrelated APIs; Route scope would mean re-attaching the plugin every time you add a route. -
Consumer - create one for the payments team and give it a
key-authcredential. The credential is what the plugin looks up, and the Consumer is the identity that later rate limits and audit logs are recorded against. -
Reporting tool - because it calls without credentials, it must not go through the same Route, or the
key-authplugin on the Service will reject it with401. It needs its own Route on the same Service, with thekey-authplugin removed at the Route level. -
Rate limiting plugin - attach
rate-limitingto the Route that serves the reporting tool, configured withminute: 10andlimit_by: ip, because the caller is anonymous and there is no consumer to count. Attaching it to the Service would also throttle the payments team, which is not what the requirement says. -
Scope check - the payments Route gets
key-authfrom the Service and no rate limit, unless you also decide the payments team needs one. The reporting Route gets the rate limit and inheritskey-authfrom the Service, so you must explicitly remove it withconfig: ...override or place the rate limit and the exemption carefully.
Answer:
Five objects, one per decision:
| Object | Name | Key settings | Why this level |
|---|---|---|---|
| Service | orders | url: http://orders.internal:8080 | The upstream address belongs to one place; both routes share it |
| Route | orders-secure | paths: [/orders], strip_path: true, on orders | Carries the authenticated traffic |
| Plugin | key-auth on Service orders | key_names: [apikey] | Service scope protects every present and future route of that service |
| Consumer | payments-team | one key-auth credential | Gives the plugin something to look up and gives later limits and logs an identity |
| Route | orders-reporting | paths: [/reports/orders], on orders | A separate path so the anonymous caller is not subject to key-auth |
| Plugin | rate-limiting on Route orders-reporting | minute: 10, limit_by: ip | The caller is anonymous, so the counter must be keyed on IP, not on a consumer that does not exist |