Modern microservices-based architectures require companies to change not just the way they build applications but also how to deploy them. Basically, the new microservices foundation should be based on two main pillars: hybrid deployments and Kubernetes orchestrator.

With the complete separation of the control plane (CP) and data plane (DP), Kong Gateway fully supports hybrid deployments. In this context, the control plane is responsible for administration tasks, while the data plane is exclusively used by API consumers. In a hybrid deployment, the control plane and data planes run in completely separate environments.

On the other hand, Amazon Elastic Kubernetes Service (EKS) is one of the most solid and robust Kubernetes distribution services in the marketplace today, providing highly available and secure clusters for mission-critical systems. In this sense, a Kong Konnect Gateway deployment running on AWS EKS clusters is a natural technology combination and an ideal platform to run new microservices-based applications.

Benefits of Hybrid EKS-Based Kong Deployment

Considering the capabilities provided by the Kubernetes platform, running data planes on this platform delivers a powerful environment. Here are some capabilities leveraged by the data plane on Kubernetes:

• High Availability: One of the main  capabilities of Kubernetes is “self-healing.” If a “pod” crashes, Kubernetes takes care of it by reinitializing the “pod.”
• Scalability/Elasticity: HPA (“Horizontal Pod Autoscaler”) is the capability to initialize and terminate “pod” replicas based on previously defined policies. The policies define “thresholds” to tell Kubernetes the conditions where it should initiate a brand new “pod” replica or terminate a running one.
• Load Balancing: The Kubernetes Service notion defines an abstraction level on top of the “pod” replicas that might have been up or down (due HPA policies, for instance). Kubernetes keeps all the “pod” replicas hidden from the “callers” through services.

Kong Konnect and Amazon EKS Anywhere

The synergy of the two products just got stronger with the launch of Amazon EKS Anywhere. Based on EKS Distro (Amazon’s open source distribution for Kubernetes) and the Cluster API Project (https://github.com/kubernetes-sigs/cluster-api), EKS Anywhere gives you the flexibility to start, run and scale Kubernetes applications in the AWS Cloud or on-prem.

This capability is particularly important for the Kong Konnect data plane. That is, new instances of the data plane can be created to support the workload movement that the microservices project might decide along the way.

The diagram below illustrates the scenario:

• The control plane runs on an EKS cluster in AWS Cloud. It is used by admins to create APIs, policies and API documentation based on Swagger, OpenAPI, etc.
• Data plane #1 runs on an on-prem EKS Anywhere cluster to expose the services and microservices deployed in all environments we may have, including application servers, legacy systems and EKS Anywhere clusters.
• Data Plane #1 leverages AWS services like Cognito for OIDC-based authentication processes, Elasticsearch for log processing, etc. to implement policies to make sure the microservices or services are being safely consumed.
• The architecture includes Data Plane #2, which is running on the AWS Cloud along with the control plane, to support the microservices and services that have been migrated from the on-prem environment or new microservices developed in cloud environments like ECS, EC2/ASG, etc.
• The communication between the control plane and the data planes is based on mTLS tunnels. The control plane publishes APIs and policies across all existing data planes using a specific tunnel. On the other hand, using another tunnel, each data plane reports back the control plane with metrics regarding API request processing.

Control Plane and Data Plane Deployment

The control plane and data planes can be deployed using usual Kubernetes mechanisms, including YAML declarations, Helm Charts, DevOps, etc.

For example, a control plane can be deployed using Helm commands like this:

helm install kong kong/kong -n kong \

--set ingressController.enabled=true \

--set ingressController.installCRDs=false \

--set ingressController.image.repository=kong/kubernetes-ingress-controller \

--set ingressController.image.tag=1.3.1-alpine \

--set image.repository=kong/kong-gateway \

--set image.tag=2.5.0.0-alpine \

--set env.database=postgres \

--set env.role=control_plane \

--set env.cluster_cert=/etc/secrets/kong-cluster-cert/tls.crt \

--set env.cluster_cert_key=/etc/secrets/kong-cluster-cert/tls.key \

--set cluster.enabled=true \

--set cluster.type=LoadBalancer \

--set cluster.tls.enabled=true \

--set cluster.tls.servicePort=8005 \

--set cluster.tls.containerPort=8005 \

--set clustertelemetry.enabled=true \

--set clustertelemetry.type=LoadBalancer \

--set clustertelemetry.tls.enabled=true \

--set clustertelemetry.tls.servicePort=8006 \

--set clustertelemetry.tls.containerPort=8006 \

--set proxy.enabled=true \

--set proxy.type=ClusterIP \

--set admin.enabled=true \

--set admin.http.enabled=true \

--set admin.type=LoadBalancer \

--set enterprise.enabled=true \

--set enterprise.portal.enabled=true \

--set portal.enabled=true \

--set portal.http.enabled=true \

--set env.portal_gui_protocol=http \

--set portal.type=LoadBalancer \

--set portalapi.enabled=true \

--set portalapi.http.enabled=true \

--set portalapi.type=LoadBalancer \

--set enterprise.rbac.enabled=false \

--set enterprise.smtp.enabled=false \

--set manager.enabled=true \

--set manager.type=LoadBalancer \

--set secretVolumes[0]=kong-cluster-cert \

--set postgresql.enabled=true \

--set postgresql.postgresqlUsername=kong \

--set postgresql.postgresqlDatabase=kong \

--set postgresql.postgresqlPassword=kong \

--set enterprise.license_secret=kong-enterprise-license

From the data plane communication perspective, the most important settings are:

• env.role=control_plane  to configure this Kong Konnect instance as the control plane
• cluster.type=LoadBalancer  to expose the control plane with a load balancer, while the data planes refer to it to get the mTLS tunnels in place
• cluster.tls.servicePort=8005 as the API and policy publication mTLS tunnel port
• clustertelemetry.type=LoadBalancer  to expose the telemetry endpoint to the data plane
• clustertelemetry.tls.servicePort=8006  as the tunnel port that the data plane will use to report back the control plane with metrics

A data plane can be deployed with a Helm command similar to this:

helm install kong kong/kong -n kong \

--set ingressController.enabled=false \

--set image.repository=kong/kong-gateway \

--set image.tag=2.5.0.0-alpine \

--set env.database=off \

--set env.role=data_plane \

--set env.cluster_cert=/etc/secrets/kong-cluster-cert/tls.crt \

--set env.cluster_cert_key=/etc/secrets/kong-cluster-cert/tls.key \

--set env.lua_ssl_trusted_certificate=/etc/secrets/kong-cluster-cert/tls.crt \

--set env.cluster_control_plane=<Control_Plane_LoadBalancer>:8005 \

--set env.cluster_telemetry_endpoint=<Control_Plane_LoadBalancer>:8006 \

--set proxy.enabled=true \

--set proxy.type=NodePort \

--set enterprise.enabled=true \

--set enterprise.portal.enabled=false \

--set enterprise.rbac.enabled=false \

--set enterprise.smtp.enabled=false \

--set manager.enabled=false \

--set portal.enabled=false \

--set portalapi.enabled=false \

--set env.status_listen=0.0.0.0:8100 \

--set secretVolumes[0]=kong-cluster-cert \

--set enterprise.license_secret=kong-enterprise-license

Again, the most important settings are:

• env.role=data_plane  to configure this Kong Konnect instance as a data plane
• env.database=off , which unlike the control plane, does not require a database to store its metadata and instead gets all API and policy definition using the specific mTLS tunnel it builds with the control plane.
• env.cluster_control_plane=<Control_Plane_LoadBalancer>:8005  referring to the exposed control plane IP and port
• env.cluster_telemetry_endpoint=<Control_Plane_LoadBalancer>:8006  referring to the second control plane IP and port
• proxy.type=NodePort  to define how to expose the data plane to the API consumers

Conclusion

Kong Konnect 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 Konnect Enterprise.

Feel free to apply and experiment your API policies like caching with AWS ElastiCache for Redis, log processing with AWS Elasticsearch Services, OIDC-based authentication with AWS Cognito, canary, GraphQL integration and more with the extensive list of plugins provided by Kong Konnect.

This is Part 1 of the Kong Konnect Enterprise and AWS EKS Anywhere blog post series. Part 2 will give a detailed tutorial on how to deploy Konnect on EKS Anywhere.