CoreDNS is the default Domain Name System (DNS) server of Container Service for Kubernetes (ACK) clusters. This topic introduces the plug-ins provided by CoreDNS and how to configure the plug-ins in various scenarios.
Prerequisites
Description
dnsPolicy: ClusterFirst
is specified in the DNS policy configuration of the pod. Example:apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: default
spec:
containers:
- image: alpine
command:
- sleep
- "10000"
imagePullPolicy: Always
name: alpine
dnsPolicy: ClusterFirst
For more information about how to set the dnsPolicy parameter in various scenarios, see Introduce and configure the DNS service in ACK clusters.
Default configurations of CoreDNS
Corefile: |
.:53 {
errors
log
health {
lameduck 15s
}
ready
kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {
pods verified
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf {
prefer_udp
}
cache 30
loop
reload
loadbalance
}
ClusterDomain
with the cluster domain name that you specify when you create the cluster. The default
cluster domain name is cluster.local
.
Parameter | Description |
---|---|
errors | Prints errors to standard output (stdout). |
health | Generates health check reports for CoreDNS. The default listening port is 8080. This
plug-in is used to evaluate the health status of CoreDNS. You can visit http://localhost:8080/health to view the health check report of CoreDNS.
|
ready | Reports the status of CoreDNS plug-ins. The default listening port is 8181. This plug-in
is used to evaluate the readiness of CoreDNS plug-ins. You can visit http://localhost:8181/ready to view the readiness of the CoreDNS plug-ins. After all plug-ins are in the running
state, a 200 response code is returned for the readiness of CoreDNS plug-ins.
|
kubernetes | The kubernetes plug-in of CoreDNS is used to provide DNS resolution for services in an ACK cluster. |
prometheus | Exports CoreDNS metrics. You can visit http://localhost:9153/metrics to view CoreDNS metrics in Prometheus format.
|
forward or proxy | Forwards DNS queries to the predefined DNS server. By default, DNS queries of domain names beyond the cluster domain of Kubernetes are forwarded to the predefined DNS resolver (/etc/resolv.conf). The default configurations are based on the /etc/resolv.conf file on the host. |
cache | Enables DNS caching. |
loop | Performs loop detection. If a loop is detected, CoreDNS is suspended. |
reload | Allows automatic reload of a changed Corefile. After you edit the ConfigMap, wait 2 minutes for the changes to take effect. |
loadbalance | Works as a round-robin DNS load balancer to randomize the order of A, AAAA, and MX records in the answer. |
Configure extended features based on CoreDNS
- Scenario 1: Enable log collectionTo collect the log of all DNS resolution records performed by CoreDNS, you can enable the log plug-in by adding the log parameter to Corefile. Example:
Corefile: | .:53 { errors log health { lameduck 15s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { prefer_udp } cache 30 loop reload loadbalance }
- Scenario 2: Customize DNS servers for specified domain namesIf domain names with a suffix of example.com need to be resolved by a user-defined DNS server (for example, DNS server 10.10.0.10), you must add a custom resolution setting for the domain names. Example:
The following code block shows the complete Corefile configuration:example.com:53 { errors cache 30 forward . 10.10.0.10 }
Corefile: | .:53 { errors health { lameduck 15s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { prefer_udp } cache 30 loop reload loadbalance } example.com:53 { errors cache 30 forward . 10.10.0.10 }
- Scenario 3: Customize DNS servers for external domain namesIf the domain names that need to be resolved by user-defined DNS servers do not contain the same suffix, you can use user-defined DNS servers to perform DNS resolution for all external domain names. In this scenario, you must forward the domain names that cannot be resolved by the user-defined DNS servers to Alibaba Cloud DNS. Do not modify the /etc/resolv.conf files on Elastic Compute Service (ECS) instances of the ACK cluster. For example, if the IP addresses of the user-defined DNS servers are 10.10.0.10 and 10.10.0.20, you can modify the forward parameter. Example:
Corefile: | .:53 { errors health { lameduck 15s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . 10.10.0.10 10.10.0.20{ prefer_udp } cache 30 loop reload loadbalance }
- Scenario 4: Customize hosts for specified domain namesYou can configure the hosts plug-in if you want to customize hosts for specified domain names, for example, you may need to point www.example.com to 127.0.0.1. Example:
Corefile: | .:53 { errors health { lameduck 15s } ready hosts { 127.0.0.1 www.example.com fallthrough } kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { prefer_udp } cache 30 loop reload loadbalance }
Notice You must specify fallthrough. Otherwise, domain names other than the specified one may fail to be resolved. - Scenario 5: Enable external access to services in an ACK cluster
If you want to enable a process on an ECS instance in an ACK cluster to access services in the cluster, you can specify the cluster IP address of kube-dns in the cluster as the value of the
nameserver
parameter in the /etc/resolv.conf file on the ECS instance. Do not modify other settings in the /etc/resolv.conf file.In an internal network, you can use an internal-facing Server Load Balancer (SLB) instance to allow internal access to services in the ACK cluster. Then, log on to the Alibaba Cloud DNS PrivateZone console and add an A record that points to the private IP address of the SLB instance.
- Scenario 6: Use a domain name to allow access to your service in an ACK cluster or
enable CNAME resolution for an ACK clusterYou can use foo.example.com to allow all access to your service in an ACK cluster from the Internet, internal networks, and inside an ACK cluster. The following section describes how to enable this feature:
- Your service
foo.default.svc.cluster.local
is exposed to external access through an Internet-facing SLB instance. The domain namefoo.example.com
is resolved to the IP address of the Internet-facing SLB instance. - Your service
foo.default.svc.cluster.local
is exposed to internal access through an internal-facing SLB instance. Log on to the Alibaba Cloud DNS PrivateZone console to pointfoo.example.com
to the IP address of the internal-facing SLB instance in the virtual private cloud (VPC) where the ACK cluster is deployed. For more information about the procedure, see the preceding section Scenario 4: Customize hosts for specified domain names. - Inside the ACK cluster, you can use the rewrite plug-in to add a CNAME record to point
foo.example.com
tofoo.default.svc.cluster.local
. Example:Corefile: | .:53 { errors health { lameduck 15s } ready rewrite stop { name regex foo.example.com foo.default.svc.cluster.local answer name foo.default.svc.cluster.local foo.example.com } kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { prefer_udp } cache 30 loop reload loadbalance }
- Your service