1.
Using OpenAPI to configure
your API Gateway
Ole Lensmar, CTO, Kubeshop
github.com/kubeshop/kusk

2.
OpenAPI driving the API Lifecycle

3.
OpenAPI driving the API Lifecycle

4.
Recap - what does an API Gateway do?
● Basic functionality
○ Routing / mapping
○ Rate-limiting / timeouts
○ Authentication / CORS
● Advanced
○ Security (intrusion detection, etc)
○ Orchestration/Aggregation
○ Transformation
○ Validation
○ etc.
github.com/kubeshop/kusk
Kusk

5.
Potential overlap with OpenAPI
● An OpenAPI definition contains metadata on:
○ Operations / paths / methods / parameters
○ Message format (JSON Schema)
○ Security Schemes
● OpenAPI Extensions can be used/defined for adding arbitrary metadata
○ Additional security
○ SLAs (SLA4OAS)
○ Rate-limits, timeouts
○ etc
github.com/kubeshop/kusk
Kusk

6.
New York
JULY
Australia
SEPTEMBER
Singapore
APRIL
Helsinki & North
MARCH
Paris
DECEMBER
London
OCTOBER
Jakarta
FEBRUARY
Hong Kong
AUGUST
JUNE
India
MAY
Check out our API Conferences here
50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees,
300k+ online community
Want to talk at one of our conferences?
Apply to speak here

7.
Wouldn’t it be great if you could use your OpenAPI
definition to configure your API Gateway?
github.com/kubeshop/kusk
Kusk

8.
OpenAPI driving your API Gateway - why?
● One source of truth→ the OpenAPI definition defines both functional and
operational aspects of an API
● Ease collaboration
for involved stakeholders (dev, test, ops, doc, etc)
● “DevOps” automation→ use GitOps/CI/CD to configure your API
-Gateway
○ Ensure that runtime configuration is in sync with the actual API
○ Empower dev teams to iterate rapidly without DevOps involvement
○ Configure adjacent infrastructure; monitoring, analytics, security, etc.
github.com/kubeshop/kusk
Kusk

9.
Approaches to using OpenAPI for Gateway Configuration
1. Import OpenAPI and refine with gateway
-specific configuration/UI
with/without gateway-specific OpenAPI Extensions
1. Generate standalone gateway configuration from OpenAPI
with/without gateway-specific OpenAPI Extensions
1. Gateway uses OpenAPI natively for configuration
with gateway-specific OpenAPI Extensions
github.com/kubeshop/kusk
Kusk

10.
● Pros:
○ Easy to get started with gateway from OpenAPI
○ Access to all gateway features
● Cons
○ Doesn’t always work with iterative/automated workflow
○ OpenAPI is not the source
-of-truth
● Very common approach
○ AWS
○ Azure
○ Google
○ Tyk.io
○ Gloo
○ and many more...
Import OpenAPI and Refine..
github.com/kubeshop/kusk
Kusk

11.
Generate Gateway configuration from OpenAPI
● Pros:
○ Makes OpenAPI definition the source of truth
○ Automatable / iterative development
○ GitOps compatible in Kubernetes context
● Cons:
○ Needs extensions for Gateway functionality
○ Extra step to generate and apply configuration
● Generator frameworks
○ Swagger
-codegen
○ OpenAPI
-generator
● Let’s get back to this...
github.com/kubeshop/kusk
Kusk

12.
Gateway uses OpenAPI natively for configuration
● Pros:
○ OpenAPI is the source of truth
○ Harness OpenAPI metadata for QoS functionality
○ Supports automated/iterative workflows
○ GitOps compatible in Kubernetes context
● Cons
○ Needs extensions for Gateway functionality
○ “Shoehorning”- should all configuration really be in the OpenAPI definition?
● Examples? Let’s get back to this one..
github.com/kubeshop/kusk
Kusk

13.
API Gateways and Kubernetes
github.com/kubeshop/kusk
Kusk

14.
API Gateways and Kubernetes
● Kubernetes generally requires an
Ingressto
expose an API outside a cluster
● An Ingress Controllerprovides the actual
Ingress implementation; Nginx-Ingress is the
most common, others are Ambassador,
Traefik, etc.
● API Gateways for K8s are usually Ingress
Controllers also
github.com/kubeshop/kusk
Kusk

15.
Challenges specific to Ingress Controllers
● The Ingress specificationlacks many features often needed to expose APIs
in
production (being complemented/replaced by the Gateway API)
● Each Ingress controller has their own configuration file(s) / format(s) /
approaches to provide extra/unique functionality
● Due to the nature of Kubernetes and adoption of GitOps
, Ingress controllers are
generally CRD/configuration driven
-> Configuring Ingress Controllers is often done by Ops- while evolving the API
is done by Dev -> workflow contention
github.com/kubeshop/kusk
Kusk

16.
Wouldn’t it be great if you could use OpenAPI
to configure your Ingress Controller?
1. One source
-of-truth!
2. No new configuration files!
3. Less YAML!
github.com/kubeshop/kusk
Kusk

17.
Introducing Kusk!
● Kusk generates Ingress Controller configurations from OpenAPI/Swagger definitions
● Kusk makes your
OpenAPI definition the source of truth
for configuring:
○ Operation routing and availability
○ Rate-limiting
○ CORS
○ Timouts
○ And more...
● Kusksupports multiple Ingress controllers
: Ambassador 1.x / 2.x, Linkerd, Ingress
-
Nginx, Traefik, <your favorite here>
github.com/kubeshop/kusk
Kusk

18.
Kusk Extension
● OpenAPI Extension
for:
○ Rate-limiting
○ Timeouts
○ CORS
○ Disable individual paths/operations
○ Cluster-specific properties
● Applies across all supported
Ingress Controllers- as applicable
github.com/kubeshop/kusk
Kusk

19.
Why use Kusk?
● Configuring / changing Ingress Controllers is tedious
○ Different formats
○ Multiple files
○ Inconsistent feature-sets
○ More people- More YAML!
● Kusk only requires you to extend your OpenAPI definition with additional metadata
○ No new configuration files to learn
○ Keep all API
-metadata in one place
○ Consistent approach to configuring QoS features for supported Ingress Controllers
● Kusk enables an iterative GitOps/CI/CD workflow for (Open)API development
github.com/kubeshop/kusk
Kusk

20.
Kusk + OpenAPI -> GitOps
github.com/kubeshop/kusk
Kusk

21.
Short Demo!
github.com/kubeshop/kusk

22.
Introducing: Kusk Gateway
● An OpenAPI
-first Ingress Controller / API Gateway
● Built on Envoy, a battle-tested, and production-ready proxy
● Works both standalone for local development and as Ingress Controller
under Kubernetes
● Alpha-version available on GitHub
: github.com/kubeshop/kusk -gateway
github.com/kubeshop/kusk
Kusk

23.
Kusk Gateway - Why?
● Your OpenAPI definition becomes the source
-of-truth for both functional and
QoS/deployment aspects of your API
● You canrapidly iterate on your APIwithout having to require DevOps resources
● You won’t have to write boilerplate code for functionality that Kusk Gateway can
provide out-of-the-box based on the OpenAPI definition:
request-validation,
mocking, metrics/analytics, security
, etc.
github.com/kubeshop/kusk
Kusk

24.
Thank You!
Github: github.com/kubeshop/kusk
Discord:bit.ly/kubeshop-discord
Kubeshop:kubeshop.io
Presenter: Ole Lensmar
Come to our virtual booth to learn more - and get a demo!

25.
New York
JULY
Australia
SEPTEMBER
Singapore
APRIL
Helsinki & North
MARCH
Paris
DECEMBER
London
OCTOBER
Jakarta
FEBRUARY
Hong Kong
AUGUST
JUNE
India
MAY
Check out our API Conferences here
50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees,
300k+ online community
Want to talk at one of our conferences?
Apply to speak here