In TAP 1.5, an amazing addition was made, with the inclusion of an additional package "Spring Cloud Gateway For Kubernetes"! This is a VMware product which was initially released in February 2021 as a standalone product, and is now included as part of TAP!
Spring Cloud Gateway for Kubernetes is based on the open source Spring Cloud Gateway project.
What Is Spring Cloud Gateway For Kubernetes
Spring Cloud Gateway for Kubernetes is based on the open source Spring Cloud Gateway project, and is targetted to be the API gateway solution that application developers love, and IT Operators are so happy that it exists! Spring Cloud Gateway for Kubernetes handles cross-cutting concerns on behalf of development teams, such as:
- Single Sign-On (SSO)
- access control
- rate limiting
- resiliency
- security SCG helps to accelerate API delivery using modern cloud native patterns, using any programming language you choose, and integration with your existing CI/CD pipeline strategy.
What Does SCG For Kubernetes Add On Top Of The Open Source Project
Beyond the upstream SCG capabilities, the SCG for Kubernetes offering, enhances the offering by integrating with other Spring ecosystem projects such as Spring Security and Spring Session.
Beyond these key additions, we also get additional features, only available in the commercial offering which include:
- Kubernetes native integration, using a set of CRDs, managed by the SCG for Kubernetes operator
- Dynamic API route configuration
- Support for API updates through existing CI/CD pipelines
- Simple SSO configuration
- Commercial API route filters to enable authentication and access control
- OpenAPI v3 auto-generated documentation
- Horizontal and Vertical scaling configuration, to reach High Availability and meet performance requirements
What Does the UX look like
The first step, after installing SCG from the TAP package repository, is to create a gateway instance, which can be as simple as:
apiVersion: tanzu.vmware.com/v1
kind: SpringCloudGateway
metadata:
name: my-api-gateway
spec:
count: 1
While this resource seems very simple, we can actually add a lot of logic here as well at the gateway level. a more advance setup may look more like this:
apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGateway
metadata:
name: my-advanced-api-gateway
namespace: platform-ops-system
spec:
api:
serverUrl: https://my-advanced-api-gateway.example.com
title: my advanced api gateway
description: Micro Gateway to control internal APIs of my app
version: 0.1.0
cors:
allowedOrigins:
- api-portal.example.com
count: 3
sso:
secret: sso-secret
extensions:
secretsProviders:
- name: vault-jwt-keys
vault:
roleName: scg-role
filter:
jwtKey:
enabled: true
secretsProviderName: vault-jwt-keys
env:
- name: spring.cloud.gateway.httpclient.connect-timeout
value: "90s"
healthCheck:
enabled: true
interval: 30s
observability:
tracing:
wavefront:
enabled: true
metrics:
wavefront:
enabled: true
wavefront:
secret: wavefront-secret
source: my-advanced-api-gateway
application: my-app
service: my-advanced-api-gateway
prometheus:
enabled: true
serviceMonitor:
enabled: true
labels:
release: my-advanced-api-prometheus"
As you can see, we can add a lot of logic in a gateway, and by abstracting it away from our applications, this makes everyone’s lives, so much easier!
Once we have a Gateway, we now need to define our routes. This is done in a separate CR called "SpringCloudGatewayRouteConfig". Lets see an example of what this may look like:
apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGatewayRouteConfig
metadata:
name: suppliers-routes-config
spec:
service:
name: suppliers-api
routes:
- predicates:
- Path=/list-outgoing-payments/
- Method=GET
filters:
- RateLimit=2,10s
- CircuitBreaker="suppliersCircuitBreaker,forward:/alternative-payments-service"
- predicates:
- Path=/process-payment/*/supplier/**
- Method=POST,PUT,DELETE
ssoEnabled: true
As you can see, we can easily define, based on many characteristics of a request, how it should be handled.
The upside of splitting the route configuration from the gateway is huge, because the configuration at the gateway level, are the platform and IT teams concerns, while the routes themselves, are what developers own. by splitting these concerns into separate APIs, we give a much cleaner boundry and seperation of concerns between the relevant teams in the organization.
The final resource we have is the glue that stiches this all together which is the 3rd and final CR added as part of SCG which is called "SpringCloudGatewayMapping".
This resource simply binds a route configuration to a specific gateway.
This would for example look like:
apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGatewayMapping
metadata:
name: suppliers-routes-mapping
spec:
gatewayRef:
name: my-advanced-api-gateway
namespace: platform-ops-system
routeConfigRef:
name: suppliers-routes-config
The power we get with SCG for kubernetes is amazing, and having it in a kubernetes native implementation, allows us to manage our API Gateway configuration using industry standards such as GitOps. We also, because this is being defined as a kubernetes resource, can apply any policy tooling to enforce certain organizational requirements. for Example we could create OPA based policies using Tanzu Mission control, that dont allow any routes without SSO enabled, or we could require cirtuit breaker configs to exist for every route.
Summary
Having SCG for Kubernetes now at our fingertips when using TAP unlocks a wide range of advanced use cases, making the possibilities endless.
SCG also integrate with App Live View, allowing us to easily visualize the status of our metrics directly in TAP GUI alongside our applications themselves!
I am truly excited to see how organizations adopt this technology in their own paths to production, and make everyone’s lives easier, while at the same time, increasing security, application resilience, and visibility!