Posted on by vrabbi

TAP 1.5 – Spring Cloud Gateway

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!

Leave a Reply

%d