The latest release of decK's APIOps features with the Kong Ingress Controller advances API management and automation in Kubernetes environments. This blog post delves into how this integration streamlines operations, ensuring a more feature-rich API lifecycle management.

The role of decK in APIOps

For teams utilizing the Kong Ingress Controller, Kubernetes manifests have been the standard method for configuration. While effective, this approach limited their access to the suite of APIOps features that decK offers.

decK is the command-line tool engineered to automate and orchestrate the entire API delivery process. It works with state files, which are declarative representations of the Kong Gateway configuration. These files cover all aspects of the API setup, including services, routes, plugins, and consumers, thereby defining the routing and processing logic for requests.

decK commands at a Glance

The decK commands are organized into three categories:

1. Configuration Generation: Commands like deck file openapi2kong translate OpenAPI specifications into decK's native state files. This step sets the stage for configuration transformation and state management commands.
2. Configuration Transformation: This is the suite of commands designed to refine and tailor the decK configuration files. Tools such as deck file add-plugins and deck file merge enable teams to break down and reassemble their configurations.
3. Gateway State Management: The final stages in an APIOps pipeline involve synchronizing the state files with the intended platform, whether it's Kong Konnect, Kong Gateway, or the Kong Ingress Controller. Commands like deck gateway sync align the Kong environment with the decK configuration.

Bridging the Gap: deck file kong2kic

A standout feature in the latest decK release is the deck file kong2kic command. This tool acts as a bridge, converting Kong configuration files into Kubernetes manifests for the Kong Ingress Controller. It enables API teams to utilize decK's APIOps features within their Kubernetes-centric workflows.

Simplify API management at KongAir with decK

Let's dive into how KongAir, a fictional airline, is simplifying its API management with the new deck file kong2kic command.

Previously, KongAir teams working on Kong Konnect or Kong Gateway used the full suite of decK's features using Kong configuration files. However, those focusing on the Kong Ingress Controller had to rely on Kubernetes manifests only. With deck file kong2kic, API teams at KongAir can leverage decK's capabilities, streamlining governance and consolidating separate APIOps pipelines.

The KongAir API Community of Practice has established a set of governance rules across all API teams:

• Every API team within KongAir, including those responsible for the Flights and Routes APIs, adopts OpenAPI specifications to define their API contracts.
• These teams are allowed to employ Kong’s Transformation and Validation plugins. They have the autonomy to manage these plugins’ configurations through modular decK state files.
• The KongAir API Community of Practice has also defined a set of API Design Guidelines to standardize API development. These guidelines are implemented and monitored through a linting file overseen by the API Platform Team, ensuring adherence to best practices.
• The API Platform Team assumes responsibility in configuring plugins related to Observability, Security, and Traffic Control within Kong, centralizing expertise and governance for these essential aspects.
• Furthermore, this team is tasked with the management of environment-specific variables across different stages of the development lifecycle.

The following diagram illustrates KongAir’s approach to deploying APIs with decK, irrespective of the target runtime platform, which now includes the Kong Ingress Controller.