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
- 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.
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!