Today, we’re excited to release the Kong Konnect EKS Marketplace add-on as a means to deploy your Kong Gateway dataplanes in AWS. The add-ons are a step forward in providing fully managed Kubernetes clusters. It is here to simplify the post-procurement process of bootstrapping Kong Konnect gateway data planes, avoid context switching among tools during the installation process, and provide notifications when a new version of Kong Gateway is available, making upgrades seamless.
Not to be confused with the Amazon EKS Blueprint AddOns, Amazon EKS add-ons are also intended to help AWS customers to configure, deploy, update, and maintain operational software that provides key functional support to EKS clusters. Amazon EKS Add-ons are software components such as storage, networking, observability, and gateways, among others.
The core purpose of the EKS add-ons is to simplify the installation and management of a curated set of platform components while ensuring security, stability, and compatibility with Amazon EKS.
The experience is intended to simplify the platform experience of standing up a production-ready cluster, by streamlining the post-procurement process of standing up these components.
How so? The add-ons provide three key features:
Gateways are clearly operational requirements for your EKS clusters, in addition to the need to have a clear Federated API management strategy for your AWS resources. This is what Kong Konnect and our add-on deliver for you. All within AWS, you can procure Kong Konnect, and then immediately leverage the kong_konnect_ri add-on to deploy Kong Gateway dataplanes.
It simplifies deployment and management, both upgrade and downgrade, of Kong Gateway dataplanes, without having to leave the AWS tooling ecosystem. Under the hood, the helm chart, the chart configuration, and the Kong Gateway images have been already vetted and approved by AWS to work on the EKS cluster.
The high-level post-procurement experience and samples of the AWS commands to manage your Kong Gateway add-on are shown below.
Let’s walk through a demo together. We will use the AWS Console to deploy Kong Gateway Dataplanes, then we will use the AWS CLI to describe and delete it.
Step 1 - From the AWS Console, navigate to your EKS Cluster and locate the Add-ons tab.
Step 2 - Use the search bar to quickly locate the Kong Konnect add-on.
Step 3 - Now, we’ll start the configuration.
First, subscribe to the add-on, this will direct you to AWS Marketplace to procure the add-on. The add-on itself is free with Konnect. (If you don’t have Konnect already, you can start for free with Kong Konnect Plus.)
Then select the version of the gateway you want to install. The add-on versioning system aligns with the Kong Gateway image version system.
v3.4.1-eksbuild.1 == kong gateway 3.4.1
Step 4 - We actually have to step away from the AWS Console for a bit to run some prerequisites in Konnect — namely create the control plane, generate the data plane certificates, and gather control plane configuration. In reality, much of this can be handled with Konnect APIs but we are going to step through it via the Konnect Console.
Start by creating the Kong namespace on your EKS cluster
Log in to Kong Konnect and create a Control Plane of type Kong Gateway.
From Gateway Manager, create a New Dataplane, this is really to generate certs, create the k8s secret for those certs, and gather the control plane configuration.
In the same window, copy the control plane configuration, you won’t need all the values, just the endpoints. See below.
You’re done in Konnect for now.
Step 5 - Navigate back to your AWS Console, and we’re going to paste in the control plane configuration into the Konnect Add-On Configuration.
And you should be done, finish approving the install and from Kong Konnect you should be able to see those dataplanes spin up on your EKS cluster.
From Kong Konnect, navigate Gateway Manager → select your control plane → into Data Plane Nodes → you should see those data planes are in sync and healthy.
Similarly, you should also see those pods in the kong namespace:
Just to give you an idea of the console capabilities, we will use the AWS CLI to delete the add-on:
It’s that simple.
For those who want to move away from using the AWS and Konnect consoles, there are options available.
As mentioned earlier, the AWS CLI and eksctl command line tools are available.
Alternatively, because the add-ons are part of the AWS API, Infrastructure as Code solutions are available in both the Terraform AWS Provider and CloudFormation. Take a look at the terraform aws_eks_addon resource below:
For more examples of how to leverage the different tooling available, take a look at the example github repository.
We're always excited to launch a new integration with AWS, and we're excited to see our AWS customer’s reaction to using this add-on for managing your Kong Gateway dataplanes.
If this has piqued your interest, subscribe to the marketplace listing. As we mentioned before, it’s free so give it a test run.
Two of the best (in my opinion) features in Konnect are the ServiceHub and Dev Portal. However, they're also two of the most misunderstood. Aren't they the same thing? Why would you need a ServiceHub vs. Dev Portal? Well, I'm glad you asked! The r
The challenges of an acquisition frequently appear in a number of critical areas, especially when dealing with a platform as important as Kafka: API Instability and Change : Merged entities frequently rationalize or re-architect their services, whic
In the Kubernetes world, the Ingress API has been the longstanding staple for getting access to your Services from outside your cluster network. Ingress has served us well over the years and can be found present in several dozen different implementa
Modern software design relies heavily on distributed systems architecture, requiring all APIs to be robust and secure. GraphQL is no exception and is commonly served over HTTP, subjecting it to the same management concerns as any REST-based API. In
While JSON-based APIs are ubiquitous in the API-centric world of today, many industries adapted internet-based protocols for automated information exchange way before REST and JSON became popular. One attempt to establish a standardized protocol sui
Jeff Broberg, William Seaton and Peter Sullivan from Styra also contributed to this post API Gateway Authentication (AuthN) and Authorization (AuthZ) are important ways to control the data that is allowed to be transmitted using your APIs. Basically