One of the most critical requirements for an Application Modernization project is to support workloads running on multiple platforms. In fact, such projects naturally include in their transformation process migrating workloads approach using the hybrid model.
Another typical technical decision that commonly comes up is the adoption of Kubernetes as the main platform for the existing services and microservices originated by the modernization project.
Kubernetes has become a de facto standard as a new platform for developing modern applications. Among the vast collection of technological resources offered by Kubernetes, perhaps the most important is the provision of a standardized environment for the complete life cycle of an application. In other words: regardless of the context where the application will be installed, whether once again On Premises or Cloud Computing, there will be a distribution of Kubernetes available.
This is exactly the purpose of the Amazon EKS Anywhere (EKS-A) service: to provide the well known Amazon EKS technology across multiple environments.
The principles of the Kong Gateway Enterprise provide natively several capabilities which are totally aligned with the flexibility provided by EKS Anywhere. For example:
In fact, a Kong Gateway hybrid deployment should consider the complete separation of the control plane (CP) and data plane (DP). In this context, the control plane, responsible for administration tasks, and the data plane, exclusively used by API consumers, would be running in completely separate environments.
In summary, the synergic combination of both technologies results in a powerful platform to run critical applications.
Amazon EKS Anywhere is based on the concept of providers. Each provider is capable of deploying EKS clusters in a specific environment. The first Amazon EKS Anywhere version, released in September 2021, supported Docker for local development clusters and VMware vSphere for production clusters.
With this new version, Amazon EKS Anywhere provides another deployment target to support bare metal.
Ultimately, a Kong Gateway Enterprise Hybrid Deployment on Amazon EKS and Amazon EKS Anywhere platforms is represented on the diagram below:
EKS Anywhere is build based on three main technologies:
The following diagram describes an Amazon EKS Anywhere Bare Metal and Kong Gateway Enterprise Architecture Topology:
For a better diagram description we’re going to detail the two main processes to get a Hybrid Kong Gateway Enterprise deployment running the Control Plane on EKS and Data Plane on EKS Anywhere:
An EKS Anywhere cluster deployment process starts with an Admin Server node. This server has two main components:
The EKS Anywhere CLI used in the Admin Server node abstracts all the underlying components. Its fundamental command takes as input two configuration files to create both Bootstrap and Workload Clusters. Here’s an example:
The two configuration files are:
ClusterSpec.yml : it describes how the EKS Anywhere Workload Cluster should be created by the Bootstrap Cluster.
Hardware.csv : it lists where the Bare Metal servers are, including their MAC Addresses, so the Tinkerbell Stack can use iPXE remote boot to provision them.
During the cluster creation process, the EKS Anywhere CLI creates a bootstrap Kind cluster on the Admin Server node and installs Cluster-API (CAPI) and Cluster-API-Provider-Tinkerbell (CAPT) components.
CAPI creates cluster node resources and CAPT maps hardware to nodes and powers up the corresponding bare metal servers. The bare metal servers iPXE boot and run the OS provisioning process by communicating with the Tinkerbell infrastructure. Both servers are provisioned with Ubuntu OS.
The Cluster management resources are transferred from bootstrap cluster to target EKS Anywhere workload cluster. Finally, the local bootstrap Kind cluster is deleted from the Admin Server node.
After executing the eksctl-anywhere create cluster command, the two bare metal servers are ready to receive the Kong Gateway deployment, more precisely the Kong Data Plane.
Before deploying the Kong Data Plane on the EKS Anywhere Worker Node, we need to take care of the Kong Control Plane. As described in the diagram, it will be running on a regular Amazon EKS Cluster in AWS Cloud.
The eksctl CLI can be used to get a fresh Amazon EKS Cluster available. For example:
And then, using the Kong Gateway Helm Charts, the Control Plane can be deployed. Here’s an example of a Helm command:
The most important settings for the Kong Control Plane are:
Check the Kong Workshop available in AWS Portal for a more detailed description of the Kong Gateway Enterprise Hybrid Deployment.
In fact, Kong Gateway can be deployed not just with Helm Charts but with other usual Kubernetes mechanisms, including YAML declarations, Operators, etc. Likewise, combining these tools with IaC (Infrastructure as Code) technologies can be very helpful to automate the deployment processes. For example, AWS CloudFormation and AWS CDK (Cloud Development Kit) are great services to provision Kong Gateway across multiple platforms including not just EKS but ECS, EC2/ASG, etc. Check the Kong and CDK tutorial and CDK Construct Library for Kong for more information.
After submitting the Helm command the Control Plane should be available for the administrators. The Control Plane can configured with new APIs and Policies through some mechanisms:
Kong Manager: the official Kong Gateway Admin GUI. A Kong Manager screen shot is shown below:
With the Control Plane available, it’s time to deploy the Kong Data Plane on the Worker Node of the EKS Anywhere Workload Cluster. Here’s the Helm command:
Again, the most important settings are:
Since the Data Plane is exposed as a NodePort service, an external Load Balancer, sitting in front of the EKS Anywhere Cluster, could be deployed. Check the documentation to see how to use Kube-VIP or MetalLB in the Amazon EKS Anywhere Cluster.
After deploying the Data Plane, it should be already connected to the Kong Control Plane. It can be checked by sending a REST Admin request to the /clustering/status endpoint exposed by the Control Plane. For example:
The HTTPie result shows that the Data Plane has successfully connected to the Control Plane.
With both Kong Control Plane and Data Plane running it’s time to create the first API. A Kong API is based on two constructs:
The following Kong Service is based on the external and public HTTPbin service:
The following Kong Route exposes the previously created Kong Service with the /httpbin path:
The Kong Control Plane is responsible for publishing any construct defined, including Kong Services and Routes, to the Kong Data Plane. So, both should be available for consumption:
Kong Gateway Enterprise and Amazon EKS Anywhere make it easy to run services in hybrid deployments across multiple platforms, supporting on-prem and cloud workloads. You can learn more about products showcased in this blog through the official documentation: Amazon Elastic Kubernetes Services and Kong Gateway Enterprise.
Feel free to apply and experiment your API policies like caching with AWS ElastiCache for Redis, log processing with AWS Opensearch Services, OIDC-based authentication with AWS Cognito, canary, GraphQL integration and more with the extensive list of plugins provided by Kong Gateway Enterprise.
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
We’re at it again, bringing more incremental improvements to Kong Mesh! Built on top of Kuma, Kong Mesh brings much-needed simplicity and production-grade tooling. Kong Mesh is built for smooth operations with platform teams in mind, providing secu