APISIX Ingress Controller Integrates with Service Discovery
Is Service Discovery Required in Cloud-Native Applications?
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:
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:
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
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!