CoreDNS 为 Kubernetes 服务发现助力，见证第二次

CoreDNS 现已完全符合 Kubernetes DNS 服务发现规范。

阅读 6 分钟修改于：2021-09-06
John Belamaric

几个月前，我们发布了一篇博文，讲述了如何在 Kubernetes 中将 CoreDNS 用于取代 kube-dns，地址为：https://community.infoblox.com/t5/Community-Blog/CoreDNS-for-Kubernetes-Service-Discovery/ba-p/8187。自那以后，我们已经取得了许多进展。我们与社区合作，为 [Kubernetes 基于 DNS 的服务发现] 制定了一项规范 (https://github.com/kubernetes/dns/blob/master/docs/specification.md), 这使我们能够确保在现有的 Kube-DNS 实现和我们在 CoreDNS 中的新实现中实现兼容性。该规范的 1.0.0 版大部分遵循 Kube-DNS 的当前行为。CoreDNS 的 005 及更高版本实现了完整规范以及更多内容。

在博文发布时，CoreDNS Kubernetes 插件仅支持使用普通服务群集 IP 为 A 记录提供服务。现已包含以下内容：

A、SRV 和 PTR 记录，分别用于常规服务和无头服务
A 记录，用于属于服务的一部分的命名端点（即，“宠物”的记录）
A 记录，用于 Pod，可选，如规范所述
TXT 记录，用于发现正在使用的 DNS 架构版本

并非所有群集中都需要 Pod A 记录支持，默认情况下已将其禁用。此外，CoreDNS 对此用例的支持超出了您在 Kube-DNS 中找到的标准行为。在 Kube-DNS 中，这些记录不反映群集的状态。对 w-x-y-z.namespace.pod.cluster.local 的任何查询都将返回具有 w.x.y.z 的 A 记录，即使该 IP 不属于指定的命名空间，甚至不属于群集地址空间也是如此。此方法背后的最初想法是允许将通配符 SSL 证书用于 *.namespace.pod.cluster.local 等域。CoreDNS 可以使用配置选项 pods insecure 复制此行为。我们认为它“不安全”，因为验证缺失会打破通配符证书的身份保证。

CoreDNS 集成提供了选项 pods verified，它将验证返回的 IP 地址 w.x.y.z 实际上是指定命名空间中 Pod 的 IP。这防止了命名空间中 DNS 名称的欺骗。然而，它可能会大幅增加 CoreDNS 实例的内存占用，因为现在它需要监视所有 Pod，而不仅仅是服务端点。

好的，引言说到这里就足够了——我们来看看如何部署它。就像在之前的博客中提到的，我们使用 ConfigMap 和 Deployment。为了更轻松，我们创建了一个小的实用程序脚本和部署清单模板，您可用于部署。要使用它，只需将它们都放在同一目录中，然后运行 deploy.sh 脚本，将您的服务的 CIDR 传递给它。这将使用必要的 Corefile 生成 ConfigMap。它还将查找现有的 kube-dns 服务的群集 IP。例如，运行

$ ./deploy.sh 10.3.0.0/24 cluster.local

在 kubectl 指向群集并使用群集 IP 10.3.0.10 的 kube-dns 服务时，将生成下面的清单文件。¹

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        log
        health
        kubernetes cluster.local 10.3.0.0/24
        forward . /etc/resolv.conf
        cache 30
    }    
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
  labels:
    k8s-app: coredns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "CoreDNS"
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: coredns
  template:
    metadata:
      labels:
        k8s-app: coredns
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
        scheduler.alpha.kubernetes.io/tolerations: '[{"key":"CriticalAddonsOnly", "operator":"Exists"}]'
    spec:
      containers:
      - name: coredns
        image: coredns/coredns:latest
        imagePullPolicy: Always
        args: [ "-conf", "/etc/coredns/Corefile" ]
        volumeMounts:
        - name: config-volume
          mountPath: /etc/coredns
        ports:
        - containerPort: 53
          name: dns
          protocol: UDP
        - containerPort: 53
          name: dns-tcp
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 5
      dnsPolicy: Default
      volumes:
        - name: config-volume
          configMap:
            name: coredns
            items:
            - key: Corefile
              path: Corefile
---
apiVersion: v1
kind: Service
metadata:
  name: kube-dns
  namespace: kube-system
  labels:
    k8s-app: coredns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "CoreDNS"
spec:
  selector:
    k8s-app: coredns
  clusterIP: 10.3.0.10
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP

我们详细了解一下 Corefile。它真的与前一篇博文中的非常相似。

.:53 {
    errors
    log
    health
    kubernetes cluster.local 10.3.0.0/24
    forward . /etc/resolv.conf
    cache 30
}

尽管如此，唯一不同的是增加了 10.3.0.0/24 区域。这告诉 Kubernetes 插件它负责为反向区域 0.3.10.in-addr.arpa. 提供 PTR 请求。换句话说，这就是允许反向 DNS 解析服务的原因。我们尝试一下

$ ./deploy.sh 10.3.0.0/24 | kubectl apply -f -
configmap "coredns" created
deployment "coredns" created
service "kube-dns" configured
$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools
Waiting for pod default/dnstools to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
/ # host kubernetes
kubernetes.default.svc.cluster.local has address 10.3.0.1
/ # host kube-dns.kube-system
kube-dns.kube-system.svc.cluster.local has address 10.3.0.10
/ # host 10.3.0.1
1.0.3.10.in-addr.arpa domain name pointer kubernetes.default.svc.cluster.local.
/ # host 10.3.0.10
10.0.3.10.in-addr.arpa domain name pointer kube-dns.kube-system.svc.cluster.local.
/ #

好，它工作了。现在，我们看一下 CoreDNS 日志

$ kubectl get --namespace kube-system pods
NAME                                    READY     STATUS    RESTARTS   AGE
coredns-3558181428-0zhnh                1/1       Running   0          2m
coredns-3558181428-xri9i                1/1       Running   0          2m
heapster-v1.2.0-4088228293-a8gkc        2/2       Running   0          126d
kube-apiserver-10.222.243.77            1/1       Running   2          126d
kube-controller-manager-10.222.243.77   1/1       Running   2          126d
kube-proxy-10.222.243.77                1/1       Running   2          126d
kube-proxy-10.222.243.78                1/1       Running   0          126d
kube-scheduler-10.222.243.77            1/1       Running   2          126d
kubernetes-dashboard-v1.4.1-gi2xr       1/1       Running   0          24d
tiller-deploy-3299276078-e8phb          1/1       Running   0          24d
$ kubectl logs --namespace kube-system coredns-3558181428-0zhnh
2017/02/23 14:48:29 [INFO] Kubernetes plugin configured without a label selector. No label-based filtering will be performed.
.:53
2017/02/23 14:48:29 [INFO] CoreDNS-005
CoreDNS-005
10.2.6.127 - [23/Feb/2017:14:49:44 +0000] "AAAA IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR 107 544.128µs
10.2.6.127 - [23/Feb/2017:14:49:44 +0000] "MX IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR 107 7.576897ms
10.2.6.127 - [23/Feb/2017:14:49:52 +0000] "A IN kube-dns.kube-system.default.svc.cluster.local. udp 64 false 512" NXDOMAIN 117 471.176µs
23/Feb/2017:14:49:52 +0000 [ERROR 0 kube-dns.kube-system.default.svc.cluster.local. A] no items found
10.2.6.127 - [23/Feb/2017:14:50:00 +0000] "PTR IN 10.0.3.10.in-addr.arpa. udp 40 false 512" NOERROR 92 752.956µs
$ kubectl logs --namespace kube-system coredns-3558181428-xri9i
2017/02/23 14:48:29 [INFO] Kubernetes plugin configured without a label selector. No label-based filtering will be performed.
.:53
2017/02/23 14:48:29 [INFO] CoreDNS-005
CoreDNS-005
10.2.6.127 - [23/Feb/2017:14:49:44 +0000] "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR 70 1.10732ms
10.2.6.127 - [23/Feb/2017:14:49:52 +0000] "A IN kube-dns.kube-system.svc.cluster.local. udp 56 false 512" NOERROR 72 409.74µs
10.2.6.127 - [23/Feb/2017:14:49:52 +0000] "AAAA IN kube-dns.kube-system.svc.cluster.local. udp 56 false 512" NOERROR 109 210.817µs
10.2.6.127 - [23/Feb/2017:14:49:52 +0000] "MX IN kube-dns.kube-system.svc.cluster.local. udp 56 false 512" NOERROR 109 796.703µs
10.2.6.127 - [23/Feb/2017:14:49:56 +0000] "PTR IN 1.0.3.10.in-addr.arpa. udp 39 false 512" NOERROR 89 694.649µs
$

在这里，我们可以看到这些查询在两个 CoreDNS 副本之间实现了负载平衡。在生产环境中，最好禁用所有查询的日志记录，因为日志记录会显著降低查询速度（通常降低一个数量级）。要执行此操作，只需从 Corefile 删除 log 行。

这就是全部内容。请随时在 CoreDNS GitHub 上将任何问题、问题或功能建议作为问题提交。

重要信息：如果您正在使用 Google 容器引擎，还有一些其他流程不允许您替换 kube-dns 部署（或复制控制器）。如果您尝试应用上述内容，它将成功更改服务，但很快会中止您的 CoreDNS 部署并重新启动 Kube DNS 复制控制器。由于服务已更新，您实际上将在集群中丢失 DNS，因为服务的服务选择器不再指向 Kube DNS 复制控制器创建的 Pod。可能有一种方法可以解决此问题，但我还没有找到解决方法。 ↩︎

约翰·贝拉马里奇
发布： 2017-03-01 并标记发现、文档说明、Kube-DNS、Kubernetes 和服务，使用了 1224 个单词。