Apache APISIX is a dynamic, real-time, high-performance cloud native API gateway that provides rich traffic management features such as load balancing, dynamic upstream, grayscale publishing, service meltdown, identity authentication, observability, and more. Apache APISIX also integrates multiple service discovery capabilities as a cloud native API gateway, and this article shows you how to configure CoreDNS in Apache APISIX.

Background information

In traditional physical machine and VM deployment, services can be invoked using fixed IP addresses and ports. With the advent of the cloud native era, enterprise services tend to be deployed as cloud native containers. However, in containerized environment, the startup and destruction of service instances are very frequent. Manual maintenance by operation and maintenance personnel is not only a heavy workload, but also ineffective. Therefore, a mechanism is needed to automatically detect the service status and dynamically bind the new service address when the service address changes. The service discovery mechanism emerged.

Introduction to Service Discovery

The service discovery mechanism can be divided into two parts:

  • Service registry: Information about hosts and ports for storage services.

If a container provides a service to calculate the average, we use the service name of Average as a unique identifier, which is stored in the service registry as a key-value pair (Average :192.168.1.21).

  • Service discovery: Allows other users to discover information stored during the service registration phase. It can be divided into client discovery mode and server discovery mode.

Client service discovery mode

In client discovery mode, the client queries the storage information of the service registry to obtain the actual network address of the available service, selects an available service instance using the load balancing algorithm, and sends the request to the service.

Advantages: Simple architecture and flexible expansion facilitate load balancing.

Disadvantages: Heavy client, strong coupling, some development costs.

The client discovery mode implementation logic is as follows:

  1. When a new service is started, register with the service registry. The service registry stores the service name and address of the new service.
  2. When the client needs this service, it initiates a query to the service registry using the service name.
  3. The service registry returns the available addresses, and the client selects one based on the specific algorithm to initiate the call.

In this process, except for service registration, the work of service discovery is basically completed by the client independently, and the address of the registry and server is also fully visible to the client.

Server service discovery mode

The client sends a request to the Load Balancer. The Load Balancer queries the service registry based on the client’s request, finds the available service, and forwards the request to the service. The service needs to be registered and deregistered in the registry in the same way as the client service discovery mode.

Advantages: The discovery logic of the service is transparent to the client.

Disadvantages: Additional load balancers need to be deployed and maintained.

The logic of server discovery mode is as follows:

  1. When a new service is started, register with the service registry. The service registry stores the service name and address of the new service.
  2. When a client needs a service, it queries the load balancer using the service name.
  3. The load balancer sends a request to the service registry based on the service name requested by the client.
  4. After obtaining the returned address, the load balancer selects one of the returned addresses based on the specific algorithm to initiate the call.

Advantages of using CoreDNS

CoreDNS is an open source DNS server written in Go language. Due to its flexibility and extensibility, it is often used for DNS services and service discovery in multi-container environments. CoreDNS is built on Caddy, the HTTP/2 Web server, to achieve a plug-in chain architecture, a lot of DNS-related logic is abstracted into a layer of plug-in, implementation is more flexible and easy to expand, users will choose the plug-in will be compiled into the final executable file, running efficiency is also very high. CoreDNS is one of the first cloud native open source projects to join CNCF (Cloud Native Computing Foundation) and is the default DNS service in Kuberneters.

What are the advantages of CoreDNS for service discovery compared to common service discovery frameworks (Zookeeper and Consul)?

The principle of service discovery is similar to that of the DNS domain name system, an important infrastructure in computer networks. The DNS domain name system binds a rarely changing domain name to a frequently changing server IP address, while the service discovery mechanism binds a rarely changing service name to a service address. Therefore, we can use DNS to realize the function of similar service registry. We only need to convert the domain name stored in DNS into the service name. Since DNS is built into many computers, you don’t need to do much extra work by simply changing the configuration on your existing DNS system.

The principle of architecture

  1. The client makes a request to APISIX to invoke the service.
  2. APISIX accesses the upstream service node based on the configured route (see the detailed configuration below). You can configure APISIX to obtain the upstream information through DNS. APISIX automatically sends a request to the DNS server IP address as long as it is correctly configured. Obtain the IP address of the DNS service.
  3. CoreDNS returns a list of available addresses based on the requested service name.
  4. APISIX selects one of the available addresses and the configured algorithm to initiate the call.

The overall structure is as follows:

How to use

The premise condition

The operations in this article are based on the following environment.

  • Operating system Centos 7.9.

  • Apache APISIX 2.12.1. For details, see How to Build Apache APISIX.

  • CoreDNS 1.9.0, please refer to CoreDNS Installation Guide for details.

  • Node.js 10.15.0. For details, see Node.js Installation.

steps

  1. Using Node. JsKoaIn the framework of3005Port starts a simple test service.

Accessing this service returns the Hello World string, and we’ll get the address of this service via CoreDNS later.

// Use the Koa framework to build the service
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3005);
Copy the code
  1. Configuration CoreDNS.

CoreDNS listens on port 53 by default and reads the Corefile configuration file in the same directory. Initially, there is no Corefile file in the same directory, so we need to create and complete the configuration.

Corefile functions mainly by configuring plug-ins, so we need to configure three plug-ins:

  • hosts: You can use this parameter to bind the service name to the IP address.fallthroughIndicates that a request can be forwarded to the next plug-in if it exists if the current plug-in cannot return normal data.
  • forward: proxies requests to a specified address, usually the address of an authoritative DNS server.
  • log: If no parameter is specified, logs are printed to the console interface for debugging.
J: 1053 {Listen on port 1053Hosts {10.10.10.10 helloBind service name coreDNS to IP addressFallthrough} forward. 114.114.114.114:53log
}
Copy the code
  1. Configure Apache APISIX.

Add the configuration to conf /config.yaml and reload Apache APISIX.

# config.yml
# ...other config
discovery:   
   dns:     
     servers:       
        - "127.0.0.1:1053"          Use the real address of the DNS server. This is port 1053 on the local server
Copy the code
  1. Configure routing information in Apache APISIX.

Next we configure the relevant routing information by requesting the Admin API

The curl http://127.0.0.1:9080/apisix/admin/routes/1 - H'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/core/*", "upstream": {"service_name": "hello:3005", # change the server name to coreDNS. "Roundrobin ", "discovery_type":" DNS"
Copy the code
  1. Validation. A. Verify the authentication on the local machine
Curl 127.0.0.1:9080 / core/hello - I HTTP / 1.1 200 OK the content-type: text/plain. charset=utf-8 Content-Length: 11 Connection: keep-alive Date: Wed, 16 Feb 2022 08:44:08 GMT Server: APISIX / 2.12.1 Hello WorldCopy the code

B. Perform the verification on other hosts

Curl 10.10.10.10:9080 / core/hello - I HTTP / 1.1 200 OK the content-type: text/plain. charset=utf-8 Content-Length: 11 Connection: keep-alive Date: Wed, 16 Feb 2022 08:43:32 GMT Server: APISIX / 2.12.0 Hello WorldCopy the code

As you can see from the above results, the service is running normally.

  1. The IP address of the simulated container is changed because the container cannot provide services for various reasons.

We need to set up the same service on another server, also running on port 3005, but with the IP address changed, and the return string changed to Hello, Apache APISIX.

// Use the Koa framework to build the service
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello, Apache APISIX';
});

app.listen(3005);
Copy the code

Modify the Corefile configuration and restart CoreDNS. Leave other configurations unchanged. The configuration example is as follows:

J: 1053 {Listen on port 1053Hosts {10.10.10.11 hello# Change the service IP address
        Bind service name coreDNS to IP addressFallthrough} forward. 114.114.114.114:53log
}
Copy the code

DNS has a caching mechanism, when we use the dig command to request resolution of a new domain name, in the returned DNS record will see a number field, that is, the *TTL* field, generally 3600, that is, an hour. Requests sent to the domain name within the TTL period do not request resolution addresses from the DNS server, but directly obtain the address corresponding to the domain name from the local cache.

Verification shows that the request has been redirected to the new address. The verification is as follows:

Curl 127.0.0.1:9080 / core/hello - I HTTP / 1.1 200 OK the content-type: text/plain. charset=utf-8 Content-Length: 11 Connection: keep-alive Date: Wed, 16 Feb 2022 08:44:08 GMT Server: APISIX / 2.12.0 Hello, Apache APISIXCopy the code

conclusion

This article focuses on the types of service discovery and how to use CoreDNS in Apache APISIX. You can use Apache APISIX and CoreDNS based on your business needs and past technology architecture.

The Apache APISIX project is currently developing additional plug-ins to support the integration of additional services, and if you are interested, you can initiate a discussion through GitHub Discussions, or communicate via the mailing list.