用于服务的 GKE 自定义内部域答案

【问题标题】：GKE custom internal domain for services用于服务的 GKE 自定义内部域
【发布时间】：2018-09-02 09:12:00
【问题描述】：

我很少有 internal 服务与一个或多个 internal .example.com 通信。如何部署对 .example.com 的调用将路由到实际服务的集群？注意：没有

注意，我可能需要创建别名，例如 .interal.example.com ---> .example.com

这个想法是，架构中的许多组件都有对.example.com 域的http 调用，并且迁移工作。我希望 Kubernetes 负责将适当的 .example.com 映射到集群内的服务，而不是外部服务。并且不必将所有 .example.com 重命名为 .svc.cluster.local

这些服务不应该暴露在外部，只有入口会暴露在外部。

实现这一目标的最佳方法是什么？

【问题讨论】：

标签： kubernetes google-cloud-platform google-kubernetes-engine

【解决方案1】：

这可行，这里的假设是服务<service_name>.example.com 映射到<service_name>.svc.cluster.local。通常会涉及命名空间，因此重写看起来更像{1}.{1}.svc.cluster.local（其中<service_name> 也是<namespace_name>），或者命名空间可以根据需要硬编码{1}.<namespace_name>.svc.cluster.local。

请记住不要将kubernetes.io/cluster-service: "true" 设置为true，因此它会被注释掉，否则如果它设置为true，GKE 会继续删除该服务。我没有研究为什么会这样。

CoreDNS proxy plugin 不会采用 DNS 名称，它采用 IP、IP:PORT 或 FILENAME（例如 /etc/resolv.conf）。

需要代理/上游，因为一旦将 DNS 解析交给 CoreDNS 并且 CoreDNS 将其重写到本地集群服务，则必须解析本地集群服务 DNS 条目，请参阅 kubernetes 文档中的effects on pods。最终解析到 IP 发生在代理上，甚至可能使用指向 kube-dns.kube-system.svc.cluster.local 的上游服务器。

apiVersion: v1
kind: ConfigMap
metadata:
  name: internal-dns
  namespace: kube-system
data:
  Corefile: |
    example.com:53 {
      log
      errors
      health
      prometheus :9153
      rewrite name regex (.*).example.com {1}.svc.cluster.local
      proxy . 10.10.10.10 ### ip of kube-dns.kube-system.svc.cluster.local
    }
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: internal-dns
  namespace: kube-system
  labels:
    k8s-app: internal-dns
    kubernetes.io/name: "CoreDNS"
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: internal-dns
  template:
    metadata:
      labels:
        k8s-app: internal-dns
    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
        - key: "CriticalAddonsOnly"
          operator: "Exists"
      containers:
      - name: coredns
        image: coredns/coredns:1.2.6
        imagePullPolicy: IfNotPresent
        resources:
          limits:
            memory: 170Mi
          requests:
            cpu: 100m
            memory: 70Mi
        args: [ "-conf", "/etc/coredns/Corefile" ]
        volumeMounts:
        - name: config-volume
          mountPath: /etc/coredns
          readOnly: true
        ports:
        - containerPort: 53
          name: dns
          protocol: UDP
        - containerPort: 53
          name: dns-tcp
          protocol: TCP
        - containerPort: 9153
          name: metrics
          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: internal-dns
  namespace: kube-system
  annotations:
    prometheus.io/port: "9153"
    prometheus.io/scrape: "true"
  labels:
    k8s-app: internal-dns
    #kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "CoreDNS"
spec:
  selector:
    k8s-app: internal-dns
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP

正如@patrick-w 和@danny-l 在上面的 cmets 中指出的那样，需要将存根域插入 kube-dns，然后将调用委托给 example.com 或 CoreDNS。

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"example.com": ["10.20.20.20"]} ### ip of internal-dns.kube-system.svc.cluster.local.

存根域具有获取 DNS 名称的能力，internal-dns.kube-system.svc.cluster.local 本来可以工作，但由于 bug in kube-dns (dnsmasq)，dnsmasq 容器无法启动并最终出现 CrashLoopBackOff。

internal-dns.kube-system.svc.cluster.local 是 CoreDNS/internal-dns 服务的名称。

dnsmasq 错误：

I1115 17:19:20.506269       1 main.go:74] opts: {{/usr/sbin/dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053] true} /etc/k8s/dns/dnsmasq-nanny 10000000000}
I1115 17:19:20.506570       1 sync.go:167] Updated stubDomains to map[example.com:[internal-dns.kube-system.svc.cluster.local]]
I1115 17:19:20.506734       1 nanny.go:94] Starting dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053 --server /example.com/internal-dns.kube-system.svc.cluster.local]
I1115 17:19:20.507923       1 nanny.go:116]
I1115 17:19:20.507952       1 nanny.go:116] dnsmasq: bad command line options: bad address
I1115 17:19:20.507966       1 nanny.go:119]
W1115 17:19:20.507970       1 nanny.go:120] Got EOF from stderr
I1115 17:19:20.507978       1 nanny.go:119]
W1115 17:19:20.508079       1 nanny.go:120] Got EOF from stdout
F1115 17:19:20.508091       1 nanny.go:190] dnsmasq exited: exit status 1

在stubdomain中使用ip时dnsmasq成功：

I1115 17:24:18.499937       1 main.go:74] opts: {{/usr/sbin/dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053] true} /etc/k8s/dns/dnsmasq-nanny 10000000000}
I1115 17:24:18.500605       1 sync.go:167] Updated stubDomains to map[example.com:[10.20.20.20]]
I1115 17:24:18.500668       1 nanny.go:94] Starting dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053 --server /example.com/10.20.20.20]
I1115 17:24:18.850687       1 nanny.go:119]
W1115 17:24:18.850726       1 nanny.go:120] Got EOF from stdout
I1115 17:24:18.850748       1 nanny.go:116] dnsmasq[15]: started, version 2.78 cachesize 1000
I1115 17:24:18.850765       1 nanny.go:116] dnsmasq[15]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
I1115 17:24:18.850773       1 nanny.go:116] dnsmasq[15]: using nameserver 10.20.20.20#53 for domain example.com
I1115 17:24:18.850777       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain ip6.arpa
I1115 17:24:18.850780       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain in-addr.arpa
I1115 17:24:18.850783       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain cluster.local
I1115 17:24:18.850788       1 nanny.go:116] dnsmasq[15]: reading /etc/resolv.conf
I1115 17:24:18.850791       1 nanny.go:116] dnsmasq[15]: using nameserver 10.20.20.20#53 for domain example.com
I1115 17:24:18.850796       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain ip6.arpa
I1115 17:24:18.850800       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain in-addr.arpa
I1115 17:24:18.850803       1 nanny.go:116] dnsmasq[15]: using nameserver 127.0.0.1#10053 for domain cluster.local
I1115 17:24:18.850850       1 nanny.go:116] dnsmasq[15]: read /etc/hosts - 7 addresses

【讨论】：

【解决方案2】：

因此，通过阅读一些 Kubernetes 文档，看起来 kube-dns 处理了集群中的所有 DNS 解析。默认情况下，这只是节点所做的事情（即使用公共 DNS 解析），因此它实际上会尝试与 *.example.com 对话。

所以我认为这样做的方法是覆盖 kube-dns 的行为。 Kubernetes 文档在这里有一些关于它的信息：https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/

我不太擅长 DNS 的东西，但从文档页面看，CoreDNS 选项看起来很有趣，因为它有一个重写配置。因此，将service.example.com 重写为对service.svc.cluster.local 的调用可能很容易。

【讨论】：

我实际上有 CoreDNS，但 GKE 尚不支持它。我不能在那里替换它..
您始终可以部署另一个用于您的 internal.example.com 域的 DNS pod，并将其添加为 kube-DNS ConfigMap 中的 upstreamNameserver
我相信帕特里克指的是this