Overview of Apache APISIX Ingress

Apache APISIX Ingress definition

In the K8s ecosystem, Ingress is a resource that represents the entrance of K8s traffic. To make it effective, an Ingress Controller needs to monitor the Ingress resources in K8s, analyze the corresponding rules of these resources and actually carry the traffic. In current trends, Ingress Controller implementations like Kubernetes Ingress Nginx are the most widely used.

APISIX Ingress is another implementation of Ingress Controller. The difference between Kubernetes Ingress Nginx and Kubernetes Ingress Nginx lies in that APISIX Ingress uses Apache APISIX as the actual data plane to carry the service 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 K8s cluster through an external agent, and then APISIX Ingress for subsequent processing.

As you can see from the image above, APISIX Ingress is divided into two parts. One part is the APISIX Ingress Controller, which serves as the control surface for configuration management and distribution. APISIX Proxy Pod is responsible for carrying business traffic through Custom Resource Definitions (CRD). Apache APISIX Ingress supports native K8s Ingress resources in addition to custom resources.

Apache APISIX briefly

We mentioned earlier that APISIX Ingress uses Apache APISIX as the actual data surface to carry business traffic. So what does the Apache APISIX project do?

Apache APISIX is the Apache Foundation’s top open source project and the most active open source gateway project. As a dynamic, real-time, high-performance open source API gateway, Apache APISIX provides rich traffic management features such as load balancing, dynamic upstream, grayscale publishing, service meltdown, authentication, observability, and more.

Apache APISIX helps enterprises quickly and securely handle API and microservice traffic, such as traffic limiting authentication, log security features, and support for a wealth of custom plug-ins. It is currently integrated with many open source projects such as Apache SkyWalking, Prometheus, and other components.

APISIX Ingress vs K8s Ingress Nginx

Because I have participated in the development and maintenance of APISIX Ingress and K8s Ingress Nginx projects at the same time, many people will ask me, how should I choose when comparing these two projects? Or why Nginx is making APISIX Ingress with K8s Ingress

The configuration level

In APISIX Ingress, we added some rich and flexible configurations, such as grayscale deployment through a single configuration file. K8s Ingress Nginx requires at least two Ingress resource files.

richness

In terms of richness, Apache APISIX is rich in its own functions and allows a variety of plug-ins to be extended, so using APISIX Ingress can save the tedious steps of configuring additional functions, and more time can be invested in the actual development.

Architectural separation

APISIX Ingress uses a separate architecture for the data side and control side, so users can choose to deploy the data side inside/outside the K8s cluster. However, K8s Ingress Nginx puts the control plane and the data plane into the same Pod. If the Pod or the control plane has a glitch, the whole Pod will hang, which affects the traffic.

This architecture separation provides users with convenient deployment choices, and facilitates data migration and use in service architecture adjustment scenarios.

APISIX Ingress details

Because Apache APISIX is a full-dynamic high-performance gateway, APISIX Ingress itself supports full-dynamic routing, SSL certificates, upstream, plug-ins, and more.

APISIX Ingress also has the following features:

  • CRD support for easier understanding of declarative configuration; At the same time, the status check ensures that you can quickly learn the synchronization status of declared configurations

  • Support advanced routing matching rules and custom resources, and can be extended with Apache APISIX official more than 50 plug-ins and custom plug-ins

  • Supports K8s native Ingress configuration

  • Supports traffic sharding

  • Support gRPC Plaintext with TCP layer 4 proxy

  • Automatic service registration discovery, no fear of scaling

  • Flexible load balancing policies and health check functions

We will discuss CRD and custom resources in detail.

CRD extension

We mentioned CRD in the previous introduction, so how does APISIX Ingress use the CRD extension?

At the user level, when the Client initiates a request and arrives at Apache APISIX, it directly transfers the corresponding Service traffic to the back-end (such as Service Pod) to complete the forwarding process. This process does not need to go through the Ingress Controller, which ensures that users and service traffic will not be affected if problems occur, or if changes, scaling, or migrations are made.

On the configuration side, users can apply the custom CRD configuration to the K8s cluster through Kubectl Apply. Ingress Controller will continue to watch these resource changes to apply the configuration to Apache APISIX.

Custom Resources

APISIX Ingress currently supports the following five categories of custom resources: routing, upstream, consumer, certificate related, and cluster common configuration related categories.

APISIX Route

The top-level configuration of the spec attribute in the custom resource APISIX Route is HTTP. Spec supports both configurations. One is spec.http, which is used for layer 7 proxies. The other is spec.stream, which is used for 4-tier proxies. In the configuration file, we first define a rule for it, which is related parameters under match.

For example, the back-end configuration in the preceding figure uses the same Service. You can adjust the Service based on the actual situation. Note that the weight attribute is used to configure the associated Service weights. This section describes how to implement a complete set of customized route resources.

APISIX Upstream

When configuring APISIX Upstream, ensure that the name of the APISIX Ingress Controller is consistent with the Service of the K8s cluster to ensure that the APISIX Ingress Controller accurately matches the corresponding traffic.

In the configuration file, sspec.loadbalancer is responsible for setting load balancing policies. Multiple policy modes are available. Spec. scheme is a protocol configuration that supports only HTTP and gRPC. Spec. healthCheck configures the healthCheck function, such as the active status, valid protocol and path, and final feedback.

APISIX Consumer

In the APISIX Consumer configuration, authentication functions are added, such as spec.authParameter, which currently supports BasicAuth and KeyAuth, two common authentication types.

You can use value to directly configure the username and password, or use secret to directly configure the password, which is safer than the plaintext configuration.

APISIX TLS (Certificate)

APISIX TLS is mainly used for certificate management. As shown in the example, you can configure multiple domain names through hosts. The parameter in secret is the corresponding configuration certificate.

APISIX TLS is also equipped with spec.client, which is used to configure mTLS bidirectional authentication.

APISIX Config related

The Config types supported by custom resources are described in two ways.

One is APISIX Cluster Config, which is mainly used for some common configurations. The Prometheus plugin/SkyWalking configuration is currently supported globally in K8s or Apache APISIX, and other general configurations will be added in future development.

The other is the APISIX Plugin Config that we are currently working on in PR. If you are interested, you can also click on the link to join the discussion. Plugin Config is mainly a unified collection of common plug-in configurations. For example, users can apply the same configurations to multiple routes through APISIX Plugin Config, saving the tedious steps of additional multiple independent configurations.

APISIX Ingress hands-on practice

Currently, APISIX Ingress can be deployed by using Helm Charts. With a single command, you can deploy Apache APISIX and APISIX Ingress at the same time, including the etCD required by Apache APISIX.

Practice Scenario 1: Traffic segmentation

You can use APISIX Ingress to implement traffic sharding in proportion as follows:

Step 1: Configure APISIX Upstream

Step 2: Configure the APISIX Route

Backends configures subsets and weights to realize the splitting of incoming user request traffic. In the following example, 90% of the traffic goes to V1 and 10% to V2.

Through the above two steps, the traffic can be easily segmented in proportion to achieve the requirements of scenarios such as gray release.

Practice Scenario 2: Configuring authentication

If you want to configure Basic Auth for certain routes in APISIX Ingress, you can do the following:

Step 1: Create the APISIX Consumer resource

As mentioned earlier, you can add basicAuth to the APISIX Consumer configuration and give it a user name and password.

Step 2: Configure APISIX Route and add related parameters

In the APISIX Route resource, add authentication to the backend, enable authentication, and specify the authentication type.

Through the above steps, you can use Consumer to complete configuration authentication.

Practice Scenario 3: K8s resource expansion

As we mentioned at the beginning, APISIX Ingress supports not only custom resources, but also K8s native Ingress resources.

Above is the K8s Ingress resource. Normally, if you want to do rewrite on a resource, you can configure the annotation property by adding the annotation property. This way, when a user carries an httpbin.org request, it can be redirected to/IP via the path /sample.

When the above requirements using APISIX Ingress, simply by increased a kubernetes Ingress IO/Ingress. Class: APISIX, to specify APISIX Ingress Controller to monitor the resources, At the same time by configuring k8s.apisix.apache.org/rewrite-target: / IP, can complete the redirect to/IP path.

The above example is only one of the ways that APISIX Ingress supports native K8s Ingress at present. For more examples, you can check the specific documentation

(apisix.apache.org/docs/ingres…). For reference.

The future planning

APISIX Ingress will continue to update its functions and ecology. At present, the integration between APISIX Ingress and CERt-Manager has been completed. The following goals will be gradually achieved in the future:

  1. Complete Kubernetes V1.22+ support for CRD V1 (already done, soon to be released in APISIX Ingress V1.3)

  2. Gateway API support (expected in Q4 phase)

  3. Extend the new architecture so that users can use APISIX Ingress without the need to use ETCD

  4. Enrich the product ecosystem and expand the APISIX Ingress community

Finally, we hope that you can participate in the project as much as possible. For example, there will be an APISIX Ingress community meeting every two weeks at 2 PM on Wednesday to keep abreast of the current project progress or problems encountered. You can continue to follow the Apache APISIX video number and participate directly in the live community meeting.

About the author

Reviewer, Contributor to multiple cloud native open source projects.

About the Apache APISIX

Apache APISIX is a dynamic, real-time, high-performance open source API gateway that provides rich traffic management features such as load balancing, dynamic upstream, grayscale publishing, service circuit breaker, authentication, observability, and more. Apache APISIX helps enterprises quickly and securely handle API and microservice traffic, including gateways, Kubernetes Ingress, and service grids.

Apache APISIX Landing Users (partial)

  • Apache APISIX GitHub: github.com/apache/apis…
  • Apache APISIX website: apisix.apache.org/
  • Apache APISIX document: apisix.apache.org/zh/docs/api…