Manage Konnect Service Versions
Every Konnect service version is associated with one runtime group.
Any configurations for the service version, such as implementations, plugins,
and routes, will also be associated with the same runtime group.
If a service has multiple service versions, each version can be
associated with a different runtime group, or with the same runtime group.
Through its versions, a service can made be available in multiple environments,
simply by creating new service versions in different runtime groups.
A common use case for this is environment specialization.
For example, if you have three runtime groups for
production, you can manage which environment the service is available in by
assigning a version to that group at creation time. You might have v1 running
production, and be actively working on v2 in
development. Once it’s
ready to test, you’d create v2 in
staging before finally creating v2 in
production alongside v1.
Note: You can’t move a service version from one runtime group to another.
Instead, create a new version of the service in the new environment when you’re
ready to move to it.
Each service version is in one of the states:
- Published: This indicates that the service version is ready to be shared with API consumers. It displays in the Dev Portal where developers can request access to consume it via Kong Gateway. This is the default state.
- Deprecated: This indicates that the service version will be deprecated soon. It is still displayed in the Dev Portal and can receive API request via Kong Gateway. A banner with information about the deprecation is displayed at the top of the service version page in the Dev Portal and developers are notified via email that the version is deprecated.
- Unpublished: This indicates that the service version no longer displays in the Dev Portal, but it can still be accessed by existing Dev Portal applications via Kong Gateway.
Note: If the service package associated with a service version is unpublished, the service version won’t display in the Dev Portal.
Create a service version
From the Service Hub, select a service, then follow these steps:
From the Service actions drop-down menu, select Add new version.
Enter a version name.
A version name can be any string containing letters, numbers, or characters;
version#1. A service can have any number of
Select a runtime group.
Choose a group to deploy this version to a specific group of runtime
instances. This determines which entities and runtimes the service version
has access to, and who has access to this version.
Note: Application registration is only available for
services in the default runtime group, so if you plan on enabling
default in this step.
Different versions of the same service can run in different runtime groups.
The version name is unique within a group:
- If you create multiple versions in the same group, the versions must have unique names.
- If you create multiple versions in different groups, the versions can have the same name.
Click Create to save.
Manage the service version lifecycle
The service version lifecycle determines how and if a service version is displayed in the Dev Portal.
From the Service Hub, choose the service you want to manage the lifecycle of.
Select the service version you want to manage.
Click Service version actions > Edit version status.
Select a service version status.
- Deprecation only: Click Save on the dialog to deprecate the service version and send consumers an email notification.
Delete a service version
Deleting a service version permanently removes it and its implementation, routes, and plugins from the Service Hub.
From the Service Hub, select the service version you want to delete.
Click Service version actions > Delete service version.
Confirm the deletion by typing the name of the service version and clicking Yes, delete.