New Gateway Capabilities Enhanced

Background

Serverless Kubernetes (ASK)

ASK cluster is a serverless Kubernetes container service launched by Alibaba Cloud. You can directly deploy container applications without purchasing nodes, without the need for node maintenance and capacity planning for the cluster, and pay on demand based on the CPU and memory resources configured for the application. ASK clusters provide comprehensive Kubernetes compatibility while lowering the threshold for Kubernetes usage, allowing you to focus more on applications rather than managing underlying infrastructure.

Implementing Serverless on Kubernetes mainly achieves the following two points:

Firstly, how to focus more on business applications online.

Here, we focus on business applications through Knative, further abstract Kubernetes resources, and provide the ability to use automatic elasticity on demand. Knative is an open-source serverless application framework based on Kubernetes, which helps you deploy and manage modern serverless workloads, creating an enterprise level serverless platform.

Knative mainly includes two core modules: Serving and Eventing

Serving provides a Service application model that supports traffic based grayscale publishing, version management, scaling to 0, and automatic elasticity.

Eventing provides event driven capabilities. Support rich event sources, as well as Broker/Trigger models for event flow and filtering.

Secondly, how to reduce users' attention to infrastructure downward

By using IaaS resources for free operation and maintenance, we reduce attention to infrastructure and achieve node free operation and maintenance. By combining virtual nodes with elastic container instance ECI in Serverless Kubernetes, users can completely break free from the operation and maintenance of IaaS.

Pain points encountered using the default gateway

After discussing what Serverless Kubernetes is, we will continue to discuss the current issues encountered with using the default gateway in ASK. Currently, Nginx Ingress is used by default in ASK, but users need to face the following issues:

Self owned components for maintenance and upgrading

• Manually configuring elastic policies

• Manual performance tuning

Obviously, it cannot meet the demands of serverless on-demand use and node free operation and maintenance. So next, let's talk about how to enhance the gateway in Serverless Kubernetes.

Knative and ALB

ALB

Application Load Balancer (ALB) is a load balancing service launched by Alibaba Cloud specifically for application layer load scenarios such as HTTP, HTTPS, and QUIC. It has strong elasticity and large-scale application layer traffic processing capabilities. ALB has the ability to handle complex business routing, deeply integrates with cloud native related services, and provides a cloud native Ingress gateway.

Application based load balancing ALB has the characteristics of ready to use, super performance, stability and reliability, elastic scaling, and on-demand payment, making it more suitable for 7-layer application delivery scenarios.

Application based load balancing ALB is targeted at 7 layers and supports numerous protocols such as HTTP/HTTPS/HTTP2/WSS/QUIC/GRPC. A single instance can support up to 1 million QPS, leading the industry in performance.

Product advantages

Compared to traditional load balancing (formerly SLB), ALB has the following advantages in product positioning, performance, functional features, operation and maintenance, and cloud native support:

Elastic enhancement

ALB has been upgraded from 0 to 1 million QPS, smooth and seamless, without the need for additional operations, and is fully paid as you go.

Performance Enhancement

How to achieve stronger performance than SLB mainly comes from multi-level load and multi-level scheduling: • Providing domain names, supporting up to 99 VIPs per instance, and multi-level traffic scheduling. • Intelligent scaling between AZs based on traffic growth, without the need for users to perceive The flow is evenly distributed on all AZs and RSs to prevent avalanche effect.

Operations Enhancement

Real time access log center built on massive big data computing capabilities

High precision real-time traffic second level monitoring. Steep increase and steep decrease, with sharp peaks and spikes visible at a glance.

• Instance configuration management. Manage configuration like Git and roll back with one click.

ALB Ingress Controller

How can we use Kubernetes in conjunction with ALB's own product advantages? Here we provide cloud provider: ALB Ingress Controller. Create ALB instances and rules directly through Kubernetes Ingress. Implement integration between Kubernetes and ALB.

The ALB Ingress Controller obtains changes in Ingress resources through the API Server, dynamically generates AlbConfig, and then creates ALB instances, listening, routing and forwarding rules, and backend server groups in sequence. The relationship between Service, Ingress, and AlbConfig in Kubernetes is as follows:

Service is an abstraction of real backend services, where a service can represent multiple identical backend services.

• Ingress is a reverse proxy rule that specifies which service HTTP/HTTPS requests should be forwarded to. For example, forwarding requests to different services based on different Host and URL paths in the request.

AlbConfig is a CRD resource provided by the ALB Ingress Controller, which uses AlbConfig CRD to configure ALB instances and listen. One AlbConfig corresponds to one ALB instance.

Rich forwarding features

1. Forward based on headers and cookies.

2. Domain URL forwarding: Support traffic scheduling based on different domain names and URLs, improving application system flexibility.

High elasticity and high throughput

1. Performance guaranteed instances: Launch performance guaranteed instances to achieve performance isolation between different instances and provide performance guarantees under corresponding specifications.

2. Ultra large performance specifications: Provide ultra large load balancing instances for high-performance requirements to solve performance bottlenecks.

• Facing cloud native applications

1. Based on native Kubernetes Ingress

2. Natural support for Alibaba Cloud container service Kubernetes products

3. Compatible with Nginx Ingress semantics

• More secure and reliable

1. ALB comes with DDoS protection and can integrate with a web application firewall with just one click.

2. Integrated WAF protection capability

3. Support full link HTTPS encryption and efficient and secure encryption protocols such as TLS 1.3.

ALB Ingress Controller Architecture

The architecture of the ALB Ingress Controller is as follows:

Instance level configuration

• Custom CR: ALBConfig

concurrency control

Same Lb serial configuration, different Lb parallel configuration.

Serial configuration of the same RsPool, parallel configuration of different RsPools.

Lb transformation and Rs transformation are independent of each other

Speed limit control

The Lb and Rs configurations processed by the controller simultaneously can be configured separately

The Lb and Rs changes processed by the Controller per second can be configured separately

When Lb configuration change or Rs configuration change fails, the time control, retry count, and retry interval for re Reconcile can be configured separately.

Knative traffic management

So with this bridge, we can easily use ALB as a Knative gateway. Let's first introduce the traffic management of Knative.

Knative provides powerful traffic management capabilities, including traffic based grayscale publishing, traffic based automatic resilience, and request event driven capabilities.

Implementation of Knative combined with ALB

Next, let's take a look at the implementation of Knative combined with ALB. The key design here is to convert Knative Ingress into Kubernetes Ingress, and then create ALB and forwarding rules through the ALB Ingress Controller.

Advantages of combining native and ALB

So what does the combination of Knative and ALB bring us?

Gateway fully hosted and maintenance free

• Based on traffic elasticity

• Header/Cookie/Weighted Grayscale Publishing

• Automatic certificate discovery

MSE Cloud Native Gateway

Under the virtualized microservice architecture, businesses typically adopt a two-layer architecture of traffic gateways and microservice gateways. Traffic gateways are responsible for north-south traffic scheduling and security protection, while microservice gateways are responsible for east-west traffic scheduling and service governance. In the cloud native era dominated by containers and Kubernetes, Ingress has become the gateway standard for the Kubernetes ecosystem, giving gateways new missions, Make it possible to integrate traffic gateway and microservice gateway into one. The MSE cloud native gateway is the next generation gateway that is compatible with the Kubernetes Ingress standard, merging traditional traffic gateways and microservices gateways to reduce resource costs by 50%.

MSE Cloud Native Gateway - Integrated with ASK to support microservice capabilities

The cloud native gateway integrates container service ASK by default, supports one click import of Kubernetes services, and automatically synchronizes Endpoints; And the self-developed Multi Ingress Controller component supports multiple ASK clusters to reuse the same gateway instance, and supports seamless conversion of Nginx Ingress core function annotations. Here is only a brief introduction. For more content on MSE Cloud Native Gateway, you can follow the specialized introduction in the future.

Usage Scenario

The current supported scenarios for Serverless Kubernetes include high elastic internet scenarios, low latency scenarios in the video and audio industry, and on-demand usage scenarios for cloud native applications. By combining with the ALB gateway, new functions can be launched in grayscale and business traffic simulation can be achieved. Combined with the MSE cloud native gateway, rapid service discovery can be achieved at the end of the microservice architecture.