This topic provides an overview of CoreDNS and its plug-ins and the CoreDNS configuration file, and describes how to enable Istio CoreDNS.
CoreDNS and its plug-ins
CoreDNS is an incubation project led by Cloud Native Computing Foundation (CNCF). Formerly known as SkyDNS, the project aims to build a fast and flexible Domain Name System (DNS) server that allows users to access and use data in DNS in different ways. Based on the Caddy server framework, CoreDNS adopts a plug-in chain architecture that provides a large number of plug-ins. Each plug-in implements a DNS feature, such as DNS-based Kubernetes service discovery and Prometheus monitoring.
- Simplified configuration: CoreDNS introduces an expressive domain-specific language (DSL). CoreDNS uses the Corefile configuration file, which is also developed based on the Caddy framework.
- All-in-one solution: CoreDNS provides a simpler solution than kube-dns. CoreDNS is compiled into a binary executable file that has built-in features such as cache, backend storage, and health check. CoreDNS does not require third-party components to implement features. This enables simple deployment and secure memory management.
Corefile overview
- The port on which the server listens and the protocol that the server uses in port listening. You can specify different ports that multiple servers listen on.
- The zone where the server is used as the authoritative DNS server.
- The plug-ins to be loaded by the server.
ZONE:[PORT] {
[PLUGIN] ...
}
The following table describes the parameters in the Corefile configuration file.Parameter | Description |
---|---|
ZONE | The zone where the server is used to resolve domain names. |
PORT | The listening port. The parameter is optional. Default value: 53. |
PLUGIN | The plug-ins to be loaded by the server. Each plug-in can have multiple parameters. |
How the plug-ins work
- If the requested server has multiple zones, the zone that best matches the request is selected by using the greedy principle.
- CoreDNS runs the plug-ins based on the order defined by plugin.cfg.
- Plug-ins determine whether to process the request. The following possibilities exist:
- The current plug-in determines to process the request.
The current plug-in generates a response and returns it to the client. The request ends and the next plug-in, such as whoami, will not be called.
- The current plug-in determines not to process the request.
The next plug-in is called. If the last plug-in fails to process the request, the server returns a SERVFAIL response.
- The current plug-in processes the request in the form of Fallthrough.
The scenario where a request that is being processed is redirected to the next plug-in is called a fallthrough. The fallthrough keyword is used to determine whether to allow this operation. For example, when the host plug-in is processing a request, if the queried domain name is not located in /etc/hosts, the next plug-in is called.
- The request is processed and hints are added to its response.
- The request is processed by the current plug-in and continues to be processed by the next plug-in after information such as a hint is added to its response. The additional information is included in the response to the client. For example, the metric plug-in adds additional information to the response.
- The current plug-in determines to process the request.
CoreDNS and Kubernetes
In Kubernetes 1.11 and later, CoreDNS has reached General Availability as a DNS plug-in for Kubernetes. We recommend that you use CoreDNS for DNS resolution in Kubernetes clusters. In Alibaba Cloud Container Service for Kubernetes 1.11.5 and later, CoreDNS is the default DNS plug-in.
kubectl -n kube-system get configmap coredns -oyaml
command to view the CoreDNS configurations.apiVersion: v1
data:
Corefile: |-
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy . /etc/resolv.conf
cache 30
reload
}
kind: ConfigMap
metadata:
creationTimestamp: "2018-12-28T07:28:34Z"
name: coredns
namespace: kube-system
resourceVersion: "2453430"
selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
uid: 2f3241d5-0a72-11e9-99f1-00163e105bdf
Parameter | Description |
---|---|
errors | The errors that are generated when plug-ins process requests. Errors are included in the standard output. |
health | The health status of CoreDNS. You can view the status at http://localhost:8080/health. |
kubernetes | Responds to DNS query requests based on the IP address of the service. The default cluster domain is cluster.local. |
prometheus | Monitoring data in prometheus format, which can be obtained at http://localhost:9153/metrics. |
proxy | If the local DNS server cannot resolve a domain name, the DNS resolution request is sent to the upper-level DNS server. The default value is /etc/resolv.conf. |
cache | The time used for caching. |
Enable Istio CoreDNS
In the default Istio configuration, Istio CoreDNS is not enabled to perform DNS resolution. After you install Istio, you can update the configuration to enable Istio CoreDNS.
View the CoreDNS configuration in the cluster
Create ServiceEntry to verify DNS resolution
You can use ServiceEntry to add additional entries to the service registry within Istio. This allows services that are automatically discovered in the mesh to access and route to manually added services. ServiceEntry describes the attributes of a service, including the domain name, virtual IP address, port number, protocol, and endpoint. The services may be APIs outside the mesh or services that are deployed within the mesh but are not listed in the service registry. For example, the services may be a group of VM-based services that need to communicate with Kubernetes-based services.
In the following example, wildcard characters are used to define hosts, and the address is specified: