このページは、まだ日本語ではご利用いただけません。翻訳中です。
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
Dynamic Plugin Ordering
The order in which plugins are executed in Kong Gateway is determined by their
static priority
. As the name suggests, this value is static and can’t be
easily changed by the user.
You can override the priority for any Kong Gateway plugin using each plugin’s
ordering
field. This determines plugin ordering during the access
phase,
and lets you create dynamic dependencies between plugins.
Concepts
Dependency tokens
Use one of the following tokens to describe a dependency to a plugin:
-
before
: The plugin will be executed before a specified plugin or list of plugins. -
after
: The plugin will be executed after a specified plugin or list of plugins.
Phases
When a request is processed by Kong Gateway, it goes through various phases, depending on the configured plugins. You can influence the order in which plugins are executed for each phase.
Currently, Kong Gateway supports dynamic plugin ordering in the
access
phase.
API
You can use the following API to express dependencies for plugins within a certain request phase (examples are in decK-formatted YAML):
ordering:
$dependency_token:
$supported_phase:
- pluginA
- ...
For example, if you want to express that PluginA’s access
phase should
run before PluginB’s access
phase, you would write something like this:
PluginA:
ordering:
before:
access:
- PluginB
Known limitations
Consumer scoping
Dynamic plugin ordering cannot coexist with consumer-scoped plugins, even if they are applied to entirely different service and route pairs or are running globally. If you have consumer-scoped plugins anywhere in your workspace, you can’t use dynamic plugin ordering.
Consumer mapping and dynamic plugin ordering both run in the access phase, but the order of the plugins must be determined after consumer mapping has happened. Kong Gateway can’t reliably change the order of the plugins in relation to consumer mapping.
Cascading deletes & updates
There is no support to detect if a plugin has a dependency to a deleted plugin, so handle your configuration with care.
Performance implications
Dynamic plugin ordering requires sorting plugins during a request. This naturally adds latency to the request. In some cases, this might be compensated for when you run rate limiting before an expensive authentication plugin.
Re-ordering any plugin in a workspace has performance implications to all other plugins within the same workspace. If possible, consider offloading plugin ordering to a separate workspace.
Validation
Validating dynamic plugin ordering is a non-trivial task and would require insight into the user’s business logic. Kong Gateway tries to catch basic mistakes but it can’t detect all potentially dangerous configurations.
If using dynamic ordering, manually test all configurations, and handle this feature with care.
Kong Manager
Kong Manager also supports dynamic plugin ordering configuration through the UI. For more information, see Get Started with Dynamic Plugin Ordering
See also
Check out the examples in the getting started guide for dynamic plugin ordering.