apidays LIVE Helsinki & North: API Ecosystems - Connecting Physical and Digital March 16 & 17, 2022 Using OpenAPI to configure your API Gateway Ole Lensmar, CTO at Kubeshop

1. Using OpenAPI
to configure your
API Gateway
Ole Lensmar, CTO, Kubeshop
www.kusk.io

2. OpenAPI
driving the API
Lifecycle
www.kusk.io

3. 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.
www.kusk.io

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

5. 2022 SERIES OF EVENT
New York
JULY
(HYBRID)
Australia
SEPTEMBER
(HYBRID)
Singapore
APRIL
(VIRTUAL)
Helsinki & North
MARCH
(VIRTUAL)
Paris
DECEMBER
(HYBRID)
London
OCTOBER
(HYBRID)
Hong Kong
AUGUST
(VIRTUAL)
JUNE (VIRTUAL)
India
MAY
(VIRTUAL)
APRIL (VIRTUAL)
Dubai & Middle East
JUNE
(VIRTUAL)
Check out our API Conferences here
Wa nt t o t a lk a t one of our conference?
Apply t o spea k here

6. Wouldn’t it be great if you could use
your OpenAPI definition to configure your
API Gateway?
www.kusk.io

7. OpenAPI driving your API
Gateway — why?
● One source of truth the
OpenAPI definition defines both
functional and operational aspects
of an API
www.kusk.io

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.)
www.kusk.io

9. 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.
www.kusk.io

10. OpenAPI
driving the API
Lifecycle
www.kusk.io

11. Approaches to using OpenAPI
for Gateway Configuration
www.kusk.io

12. Approaches to using OpenAPI
for Gateway Configuration
1. Import OpenAPI and refine with
gateway-specific configuration / UI
with / without gateway-specific
OpenAPI Extensions
www.kusk.io

13. Approaches to using OpenAPI
for Gateway Configuration
1. Import OpenAPI and refine with
gateway-specific configuration / UI
with / without gateway-specific
OpenAPI Extensions
2. Generate standalone gateway
configuration from OpenAPI
with / without gateway-specific
OpenAPI Extensions
www.kusk.io

14. Approaches to using OpenAPI
for Gateway Configuration
1. Import OpenAPI and refine with
gateway-specific configuration / UI
with / without gateway-specific
OpenAPI Extensions
2. Generate standalone gateway
configuration from OpenAPI
with / without gateway-specific
OpenAPI Extensions
3. Gateway uses OpenAPI
natively for configuration
with gateway-specific OpenAPI
Extensions
www.kusk.io

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

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

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

18. API Gateways and Kubernetes
www.kusk.io

19. API Gateways
and Kubernetes
● Kubernetes generally uses an Ingress
to expose an API outside a cluster
● An Ingress Controller provides the actual
Ingress implementation; Nginx-Ingress is
the most common, others are Ambassador,
Traefik, etc.
● API Gateways for K8s are usually Ingress
Controllers also
www.kusk.io

20. Challenges specific
to Ingress Controllers
● The Ingress specification lacks 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
www.kusk.io

21. Wouldn’t it be great if you could
use OpenAPI to configure your Ingress
Controller?
www.kusk.io

22. Wouldn’t it be great if you could
use OpenAPI to configure your Ingress
Controller?
1. One source-of-truth!
www.kusk.io

23. Wouldn’t it be great if you could
use OpenAPI to configure your Ingress
Controller?
1. One source-of-truth!
2. No new/YAML configuration files!
www.kusk.io

24. Wouldn’t it be great if you could
use OpenAPI to configure your Ingress
Controller?
1. One source-of-truth!
2. No new/YAML configuration files!
3. Automated workflows = No DevOps!
www.kusk.io

25. That’s why we built Kusk
● Kusk makes your OpenAPI
definition the source of truth for:
○ Operation routing and availability
○ Rate-limiting, CORS, Timeouts
www.kusk.io
● Use Kusk-gen with an existing
Ingress controller / API Gateway
○ Ambassador 1.x / 2.x, Linkerd,
Ingress-Nginx, Traefik, <your
favorite here>
● Use Kusk Gateway as a standalone
Ingress controller / API Gateway
● 100% Open-Source - MIT license
○ Validation, Mocking, Metrics /
Coverage

26. ● x-kusk extension for configuring:
Kusk OpenAPI Extension
○ Rate-limiting
○ Timeouts
○ CORS
○ Disable paths / operations
○ Cluster-specific properties
■ Targeted service(s)
www.kusk.io
○ Mocking
○ Validation

27. Using Kusk-Gen with an
existing controller - why?
● 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
www.kusk.io

28. Detect/inspect/generate
www.kusk.io
Kusk-gen + OpenAPI + CD GitOps

29. www.kusk.io
Wouldn’t it be even greater if your API
Gateway speaks OpenAPI Natively?

30. 1. One source-of-truth!
2. No new/YAML configuration files!
3. Automated workflows = No DevOps!
www.kusk.io
Wouldn’t it be even greater if your API
Gateway speaks OpenAPI Natively?

31. 1. One source-of-truth!
2. No new/YAML configuration files!
3. Automated workflows = No DevOps!
4. OpenAPI Driven functionality
www.kusk.io
Wouldn’t it be even greater if your API
Gateway speaks OpenAPI Natively?

32. 1. One source-of-truth!
2. No new/YAML configuration files!
3. Automated workflows = No DevOps!
4. OpenAPI Driven functionality
a. Validation, Mocking, Debugging, etc
www.kusk.io
Wouldn’t it be even greater if your API
Gateway speaks OpenAPI Natively?

33. 1. One source-of-truth!
2. No new/YAML configuration files!
3. Automated workflows = No DevOps!
4. OpenAPI Driven functionality
a. Validation, Mocking, Debugging, etc
b. Security, Metrics, API Coverage, etc
www.kusk.io
Wouldn’t it be even greater if your API
Gateway speaks OpenAPI Natively?

34. Kusk Gateway
● Your OpenAPI definition becomes
the source-of-truth for both functional
and QoS / deployment aspects of your
API
● You can rapidly iterate on your API
without 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.
www.kusk.io

35. Kusk Gateway
● Built on Envoy - a battle proven proxy
for Kubernetes used by many other
Gateways
● Based on the same x-kusk extension
as Kusk-Gen - configure
operation-level rate-limiting,
timeouts, enable/disable, etc.
● Deployed as a standard Kubernetes
Controller/Operator with CRDs for
configuring APIs based on OpenAPI
● OpenAPI-specific functionality
- Configurable request validation with
user-friendly error messages based on the
operation/schema definition
- Configurable operation mocking based on
provided example responses in the OpenAPI
definition
www.kusk.io
● Kusk Gateway UI - Browser-based dashboard
for invoking/debugging deployed APIs
- metrics/health/usage
- operational parameters
- etc

36. Kusk Gateway UI
www.kusk.io

37. Kusk-Gateway
+ OpenAPI +
CD GitOps

38. OpenAPI +
Kusk Gateway
driving the
API Lifecycle
www.kusk.io

39. Kusk:
kusk.io
Discord:
bit.ly/kubeshop-discord
Kubeshop:
kubeshop.io
by Kubeshop
Come to our virtual booth
to learn more!
Thank You!
Presenter: Ole Lensmar