APISIX Ingress Controller Integrates with Service Discovery

Is Service Discovery Required in Cloud-Native Applications?

Background

Microservice architecture is one of the most popular application architectures nowadays. With the increase in application sizes, management of the application becomes more difficult. The microservice architecture tries to solve this problem by splitting the application into multiple smaller service components, which cooperate together to complete the specific business logic and functions.

These components must communicate dynamically to work well together. It is usually necessary to introduce service discovery tools. We wrote an article introducing service discovery in microservices earlier: What Is Service Discovery in Microservices - API7.ai.

By introducing the service discovery, components can be obtained dynamically. They only need to pay attention to the names of other components without paying attention to other information such as deployment location or deployment IP.

Service Discovery in Kubernetes

In the Kubernetes environment, pods are the smallest deployable unit.

And in Kubernetes, components are more difficult to communicate with each other because the IP of the Pod is not persistent and often changes.

Therefore, it is even more important to adapt to this dynamic environment when deploying applications in Kubernetes.

Kubernetes considers this requirement and provides its own DNS-based service discovery mechanism.

Kubernetes provides a concept called Service, similar to a reverse proxy. The client only needs to use Service, and does not need to know the pods encapsulated behind.

Each Service will be assigned a persistent ClusterIP. So, when the pod IP changes, other components can still collaborate through the fixed ClusterIP of the Service.

At the same time, the service in Kubernetes will automatically update an A/AAAA record to the DNS in the cluster.

The record looks like:

my-svc.my-namespace.svc.cluster-domain.example

The client can parse across namespaces or in the same namespace, greatly facilitating service discovery between components.

However, for the traditional microservice architecture not in Kubernetes, we usually use service discovery tools to achieve collaboration between services. To fully adapt to the DNS-based service discovery mechanism in the Kubernetes environment, a certain transformation/migration cost is required.

Therefore, you must maintain the original service discovery mechanism if you want lower transformation costs.

Under this premise, what’s the best way to expose services newly migrated to Kubernetes?

How APISIX Ingress Works With Service Discovery?

APISIX Ingress is an implementation of the Ingress controller in Kubernetes. It uses Apache APISIX as the data plane and supports the configuration of proxy rules through Ingress, custom CRD, and Gateway API. At the same time, it also provides integration with service discovery tools, which makes it easy to proxy the services registered and expose them to the client.

We will explain it in detail in this section.

APISIX’s Support for Service Discovery

APISIX is a high-performance, fully dynamic cloud-native API gateway that provides 80+ out-of-the-box plugins, covering most usage scenarios.

One of the excellent capabilities is the integration with service discovery tools.

APISIX can be integrated with the following service discovery tools:

• Consul
• DNS
• Eureka
• Nacos

Just add the following configuration to the APISIX configuration file (take DNS as an example):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # use the real address of your dns server

This way, when configuring the upstream, APISIX can dynamically resolve the actual upstream address information through service discovery and proxy the request.

How Does APISIX Ingress Do It?

APISIX Ingress uses APISIX as the data plane proxy component. When first integrating service discovery, we considered two options.

• Control plane integration: configure service discovery in the Ingress controller, parse and analyze the configuration, and send the results to APISIX for proxy.
• Data plane integration: configure service discovery on the APISIX data plane, and the data plane performs configuration parsing and proxying.

These two solutions have their own advantages, but considering the configuration’s real-time update and the solution's maturity, we chose the data plane integration solution.

When using this solution, users can integrate it at a lower cost, and this solution is quite mature that has undergone many production verifications.

How to use APISIX Ingress?

First, ensure that the correct service discovery configuration has been included in the APISIX configuration. The following uses DNS as an example:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

Create an ApisixUpstream resource, and modify its configuration related to discovery according to the usage scenario. For example, type: dns and serviceName to be proxied are set here:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

Finally, create an ApisixRoute resource whose upstreams refers to the ApisixUpstream resource just created:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

After the above resources are created correctly, you can access httpbin.default.svc.cluster.local registered in DNS through local.httpbin.org.

Benefits and Outlook

Through this integration, it is very convenient to expose services to clients through APISIX Ingress for applications that are already using the service discovery tools. This APISIX Ingress feature is distinctive as most Ingress controllers do not provide this integration solution.

Thanks for reading. We are still on our way to building APISIX Ingress to provide the best user experiences!

For more information about API gateway, please visit our blogs or contact us.