What problems will enterprises face after in-depth use of microservices? Cloud native full link grayscale gives new ideas

Author: Kui Yu,

How to implement grayscale, observable, and rollback safety production capabilities to meet the demands of rapid iteration and careful verification in the context of rapid business development is a problem that enterprises must face in the process of deepening microservices. With the popularity of cloud native, there are some new ideas and solutions to this problem.

Kubernetes Ingress Gateway

Let's start with the Ingress gateway and talk about configuring routing forwarding through Ingress.

The network inside the Kubernetes cluster is isolated from the outside, that is, the services inside the Kubernetes cluster cannot be directly accessed outside the Kubernetes cluster. How to provide the services inside the Kubernetes cluster to external users? The Kubernetes community has three solutions: NodePort, LoadBalancer, and Ingress. The following figure is a comparison of these three solutions:

By comparison, it can be seen that Ingress is a more suitable way for business use, and it can do more complex secondary routing distribution based on it, which is also the mainstream choice of users at present.

With the deepening of cloud-native application microservices, users need to face complex routing rule configuration, support for multiple application layer protocols (HTTP, HTTPS, QUIC, etc.), service access security, and traffic observability. Kubernetes hopes to use Ingress to standardize the rule definition of cluster ingress traffic, but the actual business needs far more function points than that provided by Ingress. In order to meet the growing business demands, users can easily deal with the traffic management of cloud native applications. The class Ingress-Provider also has various extensions under the Ingress standard.

How various Ingress-Providers route and forward

Below I will briefly introduce the implementation of various Ingress gateways under Kubernetes, and how to configure routing and forwarding rules.

Nginx Ingress

Nginx Ingress consists of resource objects Ingress, Ingress Controller, and Nginx. Ingress Controller is used to assemble the Ingress resource instance into an Nginx configuration file (nginx.conf), and reload Nginx to make the changed configuration take effect. Ingress-nginx is an Ingress controller provided by the Kubernetes community. It is the easiest to deploy, but limited by performance, its function is relatively simple, and updating the Nginx configuration requires reload.

1. Configure routing forwarding based on Nginx Ingress Controller

Based on the Kubernetes cluster deployed with the Nginx Ingress Controller component, the routing and forwarding function can be implemented, routing and forwarding can be performed according to domain names and paths, and it can also support gray-scale traffic management with simple rules based on Ingress Annotations, such as weights, headers, etc. Among the current trends, Nginx Ingress is still the most widely used.

ALB Ingress

1. ALB product introduction

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 super elasticity and large-scale seven-layer traffic processing capabilities.

2. ALB features

Elastic Auto Scaling: ALB provides both domain name and VIP (Virtual IP address), supports traffic distribution to multiple cloud servers to expand the service capability of the application system, and improves the availability of the application system by eliminating single points of failure. ALB allows you to customize the combination of Availability Zones and supports elastic scaling within the Availability Zone to avoid resource bottlenecks in a single Availability Zone.
Advanced protocol: supports ALB and QUIC, the application transmission protocol. In mobile Internet application scenarios such as real-time audio and video, interactive live broadcast and games, the access speed is faster and the transmission link is more secure and reliable. ALB also supports the gRPC framework, which enables efficient API communication between massive microservices.
Advanced Content-Based Routing: ALB supports multiple rules based on HTTP headers, cookies, HTTP request methods, etc. to identify specific business traffic and forward it to different backend servers. At the same time, ALB also supports advanced operations such as redirection, rewriting, and custom HTTPS headers.
Security blessing "ALB comes with distributed denial of service DDoS (Distributed Denial of Service) protection, and one-click integration of Web Application Firewall (WAF). At the same time, ALB supports full-link HTTPS encryption. HTTPS interaction between end servers; supports efficient and secure encryption protocols such as TLS 1.3, is oriented to encryption-sensitive services, and meets the requirements of Zero-Trust's next-generation security technology architecture; supports pre-made security policies, and you can customize security policies.
Cloud-native applications: In the cloud-native era, the PaaS platform will sink into the infrastructure and become part of the cloud. With the gradual maturity of cloud native, many industries such as the Internet, finance, and enterprises choose cloud native deployment when creating new businesses, or perform cloud native transformation on existing businesses. ALB is deeply integrated with Alibaba Cloud Container Service for Kubernetes (ACK) and is the official cloud-native Ingress gateway of Alibaba Cloud.
Flexible and flexible billing: ALB provides public network capabilities through Elastic IP Address (EIP) and shared bandwidth to achieve flexible billing on the public network; Pricing scheme based on capacity units (LCUs).

3. Configure route forwarding based on ALB Ingress Controller

The ALB Ingress Controller obtains changes in Ingress resources through the API Server, dynamically generates AlbConfig, and then sequentially creates ALB instances, monitoring, routing and forwarding rules, and backend server groups. In Kubernetes, Service, Ingress and AlbConfig have the following relationships:

Service is an abstraction of real backend services. 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: according to the different Host and URL paths in the request, forward the request to different Services.
AlbConfig is the CRD resource provided by the ALB Ingress Controller. Use the AlbConfig CRD to configure the ALB instance and monitor. An AlbConfig corresponds to an ALB instance.

ALB Ingress provides a more powerful Ingress traffic management method based on Alibaba Cloud Application Load Balancer (ALB), is compatible with Nginx Ingress, has the ability to handle complex business routes and automatic certificate discovery, and supports HTTP, HTTPS and QUIC protocols , fully meet the demand for super elasticity and large-scale seven-layer traffic processing capacity in cloud-native application scenarios.

APISIX Ingress

The main difference between APISIX Ingress and Kubernetes Ingress Nginx is that APISIX Ingress uses Apache APISIX as the data plane that actually carries business traffic. As shown in the figure below, when a user requests a specific service/API/web page, the entire business traffic/user request is transmitted to the Kubernetes cluster through an external proxy, and then processed by APISIX Ingress.

As you can see from the above figure, APISIX Ingress is divided into two parts. Part of it is the APISIX Ingress Controller, which serves as the control plane for configuration management and distribution. Another part of APISIX Proxy Pod is responsible for carrying business traffic, which is implemented by means of CRD (Custom Resource Definitions). In addition to supporting custom resources, Apache APISIX Ingress also supports native Kubernetes Ingress resources.

1. Application routing based on APISIX Ingress Controller

As shown in the figure above, we have deployed a cluster of APISIX Ingress Controller components, which can implement routing configuration based on Ingress resources and custom resources ApisixRoute, the controller monitors resource change events, and calls apisix-admin api for persistent storage of rules. The traffic goes through the APISIX-configured LoadBalancer-type Service gateway to synchronize the configuration from the ETCD and forward the request to the upstream.

APISIX Ingress Controller is based on Apache APISIX, and supports routing configuration of Ingress resources in Kubernetes, and also supports routing, plug-ins, upstream and other resource configurations connected to APISIX through custom resources. It supports dynamic configuration of routing rules, hot-swappable plug-ins, and richer routing rule support. APISIX cloud native gateway can also provide observability, fault injection, link tracking and other capabilities. Use the highly reliable ETCD cluster as the configuration center to store and distribute the apisix configuration.

MSE Cloud Native Gateway Ingress

The MSE cloud native gateway is a next-generation gateway launched by Alibaba Cloud. It combines traditional traffic gateways and microservices gateways to provide users with refined traffic governance capabilities while reducing resource costs by 50%. It supports ACK container services, Nacos, Eureka, fixed address, FaaS and other service discovery methods, support multiple authentication login methods to quickly build a security defense line, and provide a comprehensive and multi-perspective monitoring system, such as indicator monitoring, log analysis, and link tracking.

1. Application routing based on MSE cloud native gateway Ingress Controller

The above figure shows the application scenario of MSE cloud native gateway for traffic management of business applications in multi-cluster mode. The MSE cloud native gateway is deeply integrated with Alibaba Cloud Container Service ACK, which can automatically discover services and corresponding endpoint information and dynamically take effect in seconds. Users only need to associate the corresponding Kubernetes ACK cluster on the MSE management and control platform, and configure the routes in the routing management module to expose the services in the ACK to the outside world. At the same time, traffic distribution and failover can be performed according to the cluster dimension. In addition, users can implement additional policies for service routing, such as common throttling, cross-domain or rewriting.

The traffic governance capability provided by the MSE cloud native gateway is decoupled from the specific service discovery method. Regardless of the service discovery method adopted by the back-end service, the cloud native gateway lowers the threshold for getting started with a unified interactive experience and meets the ever-increasing traffic governance of user businesses. appeal.

The routing forwarding and configuration of five types of Ingress, Nginx Ingress, ALB Ingress, APISIX Ingress, and MSE Cloud Native Gateway Ingress, are introduced above. We can choose the appropriate Ingress implementation according to our business needs and complexity.

Assuming that we have configured the routing and forwarding of Ingress, how can we simply play the full-link grayscale in a multi-application environment?

Realize full-link traffic grayscale based on Ingress

Based on the practice of full-link grayscale, we put forward the concept of "swimming lane", which is not a new word in the field of distributed software.

Glossary

lane: A set of isolated environments defined for the same version of the application. Only the request traffic that satisfies the flow control routing rules will be routed to the marking application in the corresponding swimlane. An application can belong to multiple swimlanes, and a swimlane can contain multiple applications. There is a many-to-many relationship between applications and swimlanes.
Lane Group: A collection of lanes. The role of swimlane groups is mainly to distinguish between different teams or different scenarios.
Baseline: means that all services of the business are deployed into this environment. Unmarked applications belong to the baseline stable version of the application, here we refer to the stable online environment.
entry application: The traffic entry in the system. The entry application can be an Ingress gateway, or a self-built Spring Cloud Gateway, Netflix Zuul Gateway engine type gateway, or Spring Boot, Spring MVC, Dubbo applications, etc.

Why distinguish between ingress and egress applications? Because in the full-link grayscale scenario, we only need to configure the routing and forwarding rules for the ingress application, and subsequent microservices only need to perform color routing according to the transparently transmitted labels (to achieve the "swimlane" traffic closed-loop capability).

As you can see from the above figure, we have created swimlane A and swimlane B respectively, which involve two applications of transaction center and commodity center, namely tag label 2, in which lane A diverts 30% of the online traffic, lane B 20% of the online traffic is diverted, and the baseline environment (ie, the unmarked environment) is diverted 50% of the online traffic.

Technical Analysis of Full Link Grayscale

We identify the gray version of the application by configuring the annotation alicloud.service.tag: gray on the deployment, and register it in the registration center with the tag, and open the full-link swimming lane on the gray version application (automatic coloring of traffic through the machine), support Grayscale traffic automatically adds grayscale x-mse-tag: gray tag, and forwards the traffic with grayscale tag to the target grayscale application by extending the routing capability of the consumer.

Full link grayscale based on various Ingress gateways

Based on the full-link grayscale capability and a suitable ingress routing gateway, the full-link traffic grayscale can be realized. For example, the cloud native gateways of Ingress-Nginx, Ingress-APISIX, ALB, and MSE can be used as traffic portals.

Full-link grayscale product realization

Functionality and ease of use are points that must be considered in productization. From the perspective of users, we need to think end-to-end how to practice and implement the whole process. Regarding the full-link grayscale capability of microservices on Alibaba Cloud, the following two products provide a complete full-link grayscale solution.

MSE full-link grayscale scheme

As the core function of MSE Microservice Governance Professional Edition, full-link grayscale has the following six characteristics:

Full link isolation traffic lane

By setting traffic rules to 'dye' the desired traffic, the 'dye' traffic will be routed to the grayscale machine.
The grayscale traffic carries the grayscale mark and is passed downstream to form a grayscale-exclusive environment traffic lane. Applications without a grayscale environment will select an unmarked baseline environment by default.
End-to-end stable baseline environment

Unmarked applications belong to the baseline stable version of the application, that is, the stable online environment. When we will release the corresponding grayscale version code, we can then configure rules to direct specific online traffic to control the risk of grayscale code.

One-click dynamic flow

After the traffic rules are customized, one-click stop and start, additions, deletions, and changes can be performed according to requirements, and they will take effect in real time. Grayscale drainage is more convenient.

Low-cost access, based on Java Agent technology, no need to modify a line of business code

The MSE microservice governance capability is implemented based on the Java Agent bytecode-enhanced technology, which seamlessly supports all Spring Cloud and Dubbo versions on the market for nearly 5 years. Users can use it without changing a line of code, and do not need to change the existing architecture of the business. , can be up or down at any time, no binding. Just open the MSE Microservice Governance Professional Edition, configure it online, and take effect in real time.

capability

Single-application observability at the swimlane level

It has the observability of full-link applications, and can observe whether traffic escapes from a global perspective. Gray is not gray, it is clear at a glance.

has the ability to go online and offline without loss, making the release smoother

After the MSE microservice governance is enabled, the application has the ability to go online and offline without loss. In scenarios such as release, rollback, capacity expansion, and capacity reduction under large traffic, the traffic can be guaranteed to be lossless.

1. Create a traffic lane group

The applications involved in the swimlane need to be added to the swimlane group involved applications

2. Create a traffic lane

Before using the swimlane feature, by default, we already have a baseline (unqualified) environment that includes all services.

We need to deploy the isolated version of the application Deployment, label them at the same time, and select the corresponding label for the swimlane (the test swimlane is associated with the gray label)

Then you need to configure the Ingress rules for the traffic entry. For example, visit www.base.com to route to the base version of application A, visit www.gray.com to route to the gray version of application A.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
spec:
  rules:
  - host: www.gray.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

EDAS full-link grayscale solution

1. EDAS product introduction

EDAS is a cloud-native PaaS platform for application hosting and microservice management. It provides full-stack solutions such as application development, deployment, monitoring, and operation and maintenance. It also supports microservice operating environments such as Spring Cloud and Apache Dubbo, helping your applications to be easily launched. cloud.

In the EDAS platform, users can quickly deploy applications to various underlying server clusters through WAR packages, JAR packages or images, without cluster maintenance, and can easily deploy baseline and grayscale versions of applications. EDAS seamlessly accesses the MSE micro-service governance capabilities. Applications deployed in EDAS can obtain advanced features such as non-destructive application online and offline, canary release, and full-link flow control without installing additional agents.

At present, EDAS supports the full-link grayscale capability with microservice applications as the entrance. The following briefly introduces the method for configuring full-link grayscale traffic in EDAS.

2. Create a flow lane group and lane

When creating a swimlane, you need to select the entry type. Currently, only the entry application deployed in EDAS is supported as the entry application of the swimlane. You need to add the baseline version and grayscale version involved in the swimlane to the applications involved in the swimlane group.

When creating a swimlane, it supports the directed introduction of specific online traffic based on path configuration rules, and configures the marking traffic application to form a grayscale environment link. Swimlane supports flow control based on cookies, headers, and parameters.

After the swimlane is configured successfully, you can select the target swimlane group on the full-link flow control interface for traffic observation, including the overall monitoring graph of the ingress application, the monitoring graph of the unmarked part, the monitoring graph of the marked part, and the monitoring of all applications in the swimlane group. picture.

3. Application routing as traffic entry to achieve full link grayscale

The EDAS platform supports users to create application routes for Kubernetes applications based on Nginx Ingress. Combined with EDAS's support for full-link flow control, users can directly implement full-link grayscale using Nginx Ingress as the traffic ingress gateway on the EDAS console.

After the baseline version application, grayscale version application, and portal application are deployed on the EDAS platform, and the grayscale swimlane is created according to the above steps for creating traffic lane groups and swimlanes, the portal application can be bound to Kubernetes Service resources to provide traffic portals. LoadBalancer type Service can be configured for the ingress application to provide external access to the ingress application, or based on the existing Nginx Ingress gateway in the Kubernetes cluster, ClusterIP type Service and application routing can be configured for the ingress application to avoid additional allocation of public network IPs.

The following briefly describes how to configure application routing as a traffic entry for an entry application.

On the application details page after deployment, the configuration of the access mode of the application is supported. Here, you can choose to bind the LoadBalancer type Service for the entry application for direct external access, or you can create a ClusterIP type Service, as shown in the following figure:

After the configuration is successful, you can click Create Application Route on the EDAS Application Routing page, select the cluster where the entry application is located, the namespace, the application name, the service name and port created in the above steps to configure the Ingress resource, as shown in the following figure:

After the configuration is successful, you can use the domain name and path configured by the Ingress resource and combine the grayscale traffic rules configured in the swimlane to achieve full-link grayscale.

4. Go further

The full-link traffic control in EDAS currently only supports ingress applications deployed in EDAS as traffic portals. Under the cloud-native trend dominated by Kubernetes, EDAS will support the use of Ingress as traffic portals. Users do not need to deploy additional gateway applications. Use the Ingress resource to configure forwarding rules to serve as traffic entry. Not only that, EDAS will also support ALB Ingress, APISIX Ingress and MSE cloud native gateway Ingress, and on this basis, the full-link grayscale capability will be further upgraded to support the full-link grayscale capability based on various Ingress-Provider gateways .

tail

We found that under the cloud-native abstraction of Ingress, when we talk about full-link grayscale, all problems have become more standardized and simpler. In this paper, by introducing the routing and forwarding capabilities implemented by various Ingress gateways, and in conjunction with the Ingress full-link grayscale solution based on "swim lanes", enterprises can quickly implement the full-link grayscale microservice core capability.

Click " here " at the end of the article to learn more about products~