Introducing AWS Gateway API controller for Amazon VPC Lattice, an implementation of Kubernetes Gateway API

Introduction

Today, AWS announces the general availability of Amazon VPC Lattice a new feature of Amazon Virtual Private Cloud (Amazon VPC) that gives you a consistent way to connect, secure, and monitor communication between your services. As part of the launch of Amazon VPC Lattice, we’re excited to introduce the AWS Gateway API controller, an implementation of the Kubernetes Gateway API. Gateway API is an open-source standard interface to enable Kubernetes application networking through expressive, extensible, and role-oriented interfaces. AWS Gateway API controller extends custom resources, defined by Gateway API, which allows you to create VPC Lattice resources using Kubernetes APIs.

Customers are increasingly architecting their monolith applications as microservices as they modernize their infrastructure and operations with Kubernetes. This decoupled design provides agility and enables more frequent deployments; however, it also introduces a new set of concerns regarding application traffic discovery, security, monitoring, and routing. Customers combine multiple tools, such as load balancers, service discovery, service meshes, and monitoring agents, to satisfy these requirements across ingress. Ingress typically, referred to as north-south and service-to-service communication (also known as east-west communication), which are usually categorized as application networking use cases. Often, these use cases are implemented in Kubernetes by deploying a networking proxy alongside application containers using the sidecar pattern.

Amazon VPC Lattice is a fully managed service built directly into the AWS network infrastructure. Amazon VPC Lattice allows you to:

handle network connectivity seamlessly between services across VPCs and accounts
discover these services spanning multiple Kubernetes clusters
implement defense-in-depth strategy to secure communication between those services
observe the request/response traffic across the services

To implement the features just described, you aren’t required to develop custom code or required to manage Kubernetes sidecar proxies.

In this post, we demonstrate how to install Gateway API controller and configure a sample Amazon VPC Lattice service network using Gateway class implemented by the controller. In addition, we explain Gateway API resources and their mapping to Amazon VPC Lattice objects. Finally, we implement a simple traffic routing use case between services within an Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Mapping Kubernetes Gateway API to Amazon VPC Lattice objects

As per the Kubernetes Gateway API documentation:

Gateway API is an open source project managed by the Kubernetes networking community. It is a collection of resources that model application networking in Kubernetes. Gateway API supports resources such as GatewayClass, Gateway, and Route that have been implemented by many vendors and have broad industry support.

Originally conceived as a successor to the well known Ingress API, the benefits of Gateway API include (but are not limited to) explicit support for many commonly used networking protocols as well as tightly integrated support for Transport Layer Security (TLS).

At AWS, we implement Gateway API to integrate with Amazon VPC Lattice. AWS Gateway API controller is an open-source project and fully supported by Amazon. When AWS Gateway API controller is installed in your cluster, the controller watches for the creation of Gateway API resources such as Gateway and Routes and provisions corresponding Amazon VPC Lattice objects as shown above. To know more about VPC Lattice components, please visit Amazon VPC Lattice user guide.

Getting started with Gateway API on AWS

To get started, you must create an Amazon EKS cluster and install the Gateway API controller on it. You’re required to install prerequisite tools: AWS Command Line Interface (AWS CLI), kubectl, and eksctl. After setting up these tools, create a cluster following the steps listed in the Lattice documentation.

You must allow Amazon EKS worker nodes a security group to receive traffic from the VPC Lattice control plane. You must set up security groups so that they allow all pods communicating with VPC Lattice to allow traffic on all ports from the Amazon managed prefix list as per the steps mentioned in the document.

Next, you need to create the necessary AWS Identity and Access Management (AWS IAM) resources using AWS IAM Roles for Service Accounts (IRSA) for the Gateway API controller to get permissions to create Amazon VPC Lattice objects following the documentation. You can now deploy the controller using the below command. The controller installs the Gateway API CRDs (CustomResourceDefinitions).

kubectl apply -f examples/deploy-v0.0.8.yaml

The Gateway API controller is now active and ready to create Lattice components. Create sample applications using a deployment, which we’ll use to demonstrate application networking capabilities.

kubectl apply -f examples/parking.yaml
kubectl apply -f examples/review.yaml
kubectl apply -f examples/inventory-ver1.yaml
kubectl apply -f examples/inventory-ver2.yaml

How Amazon VPC Lattice Controller works

GatewayClass

The AWS Gateway API controller introduces a new GatewayClass called amazon-vpc-lattice, which allows Kubernetes users to use the Amazon VPC Lattice service. GatewayClass is a cluster-scoped resource and is usually defined by an infrastructure provider such as AWS.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: amazon-vpc-lattice
spec:
  controllerName: application-networking.k8s.aws/gateway-api-controller

kubectl apply -f examples/gatewayclass.yaml

Gateway

A gateway specifies how traffic can be mapped to services inside a cluster. Amazon VPC Lattice recommends creating a gateway in the default namespace for a cluster. Typically, Kubernetes cluster operators are responsible for creating the gateway.

The Gateway API controller creates a service network if one doesn’t exist when you create a gateway and associate a Kubernetes cluster VPC with a service network. A service network is a logical boundary that’s used to automatically implement service discovery and connectivity as well as apply access and observability policies to a collection of services. It offers inter-application connectivity over HTTP, HTTPS, and gRPC protocols within a VPC. As of today, the controller supports HTTP and HTTPS.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-hotel
spec:
  gatewayClassName: amazon-vpc-lattice
  listeners:
    - name: http
      protocol: HTTP
      port: 80

kubectl apply -f examples/my-hotel-gateway.yaml

Once a VPC has been enabled for a service network, clients in the VPC can discover the services in the service network through DNS and can direct all inter-application traffic through Amazon VPC Lattice.

HTTPRoute

An application developer or a service owner creates an HTTP route that defines how traffic is routed to back-end services. The Gateway API controller configures a service with one or more listeners when you apply HTTPRoute to a cluster. In Amazon VPC Lattice, a service is a logical component that can live in any VPC or account. Listeners define the port and protocol that the service is expecting traffic on. The controller registers Kubernetes services (defined as route backend references) as target groups and pods as targets.

Here is an example that shows how a Kubernetes user can use HTTPRoute to specify their desire to route traffic equally across different versions of the service running on the same cluster.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: inventory
spec:
  parentRefs:
  - name: my-hotel
    sectionName: http
  rules:
  - backendRefs:
    - name: inventory-ver1
      kind: Service
      port: 8090
      weight: 50
    - name: inventory-ver2
      kind: Service
      port: 8090
      weight: 50

When you create an HTTPRoute using below commands, Amazon VPC Lattice assigns a DNS name to the service, and the controller annotates route resources with a DNS name.

kubectl apply -f examples/rate-route-path.yaml
kubectl apply -f examples/inventory-route-bluegreen-single-cluster.yaml

You can find the DNS name using the following command.

kubectl get httproute -n default inventory -o jsonpath='{.metadata.annotations.application-networking\.k8s\.aws/lattice-assigned-domain-name}{"\n"}'

You should be able to access the inventory service from within parking, as they both belong to the same service network. You can now examine traffic routing across parking and inventory services.

From inside the parking pod, you can connect to the inventory service.

kubectl exec -ti <parking-pod> -- sh

for ((i=1;i<=30;i++)); do curl "<inventory-service-dns-name-noted-above>"; done

You’ll see traffic distributed equally between inventory-ver1 and inventory-ver2 services.

Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod 
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod 
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver1-74fc59977-wg8br): Inventory-ver1 handler pod....

Cleaning up

To avoid incurring charges, delete all the resources created as part of this post’s exercise. We highly recommend that you delete the HTTPRoutes and Gateway resources using Kubernetes APIs before you delete an Amazon EKS cluster. Log into the Amazon VPC console to confirm that the resources have been deleted.

Conclusion

In this post, we demonstrated how the AWS Gateway API controller for Amazon VPC Lattice supports Kubernetes Gateway API standards to enable application networking. The mapping of Gateway API items to Amazon VPC Lattice resources was also thoroughly discussed. You can create an Amazon VPC Lattice service network, associate services, register targets, and configure listeners using Kubernetes APIs. We discussed the fundamental use cases of service discovery and intra-cluster communication among HTTP applications. The AWS Gateway API Controller documentation contains installation instructions and information on implementing additional use cases.

The AWS Gateway API controller is available to you at no additional cost. However, you’ll be charged for the components created in Amazon VPC Lattice, and data transferred through Lattice. Please refer to the Amazon VPC Lattice pricing page for specifics and pricing assistance.

In the following blog, we’ll examine how the controller enables cross-cluster communication. The blog will also cover security, authentication, and authorization in detail, along with support for custom domain names for services. Additionally, the AWS Gateway API controller implements Kubernetes multi-cluster service APIs to enable the export of Kubernetes services between clusters. Refer to examples for further information on using imported services as backed references under HTTPRoute.

Call to action

The AWS Gateway API controller is an open-source project licensed under the Apache License 2.0. Give it a try, and let us know about features that interest you. We welcome any contributions such as bug reports, new features, corrections, or additional documentation.

To learn more about Amazon VPC Lattice, see the documentation and demo video from AWS reInvent 2022.

Containers