允许pod通过ingress访问service的域名答案

【问题标题】：Allow pod to access domain names of service through ingress允许pod通过ingress访问service的域名
【发布时间】：2019-07-01 04:21:14
【问题描述】：

我的 minikube kubernetes 集群上有一个服务和入口设置，它公开了域名 hello.life.com 现在我需要从另一个 pod 内部访问这个域卷曲http://hello.life.com 这应该返回正确的 html

我的服务如下：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: bulging-zorse-key
    chart: key-0.1.0
    heritage: Tiller
    release: bulging-zorse
  name: bulging-zorse-key-svc
  namespace: abc
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    name: bulging-zorse-key
  type: ClusterIP
status:
  loadBalancer: {}

我的入口如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  labels:
    app: bulging-zorse-key
    chart: key-0.1.0
    heritage: Tiller
    release: bulging-zorse
  name: bulging-zorse-key-ingress
  namespace: dev
spec:
  rules:
  - host: hello.life.com
    http:
      paths:
      - backend:
          serviceName: bulging-zorse-key-svc
          servicePort: 80
        path: /
status:
  loadBalancer:
    ingress:
    - {}

有人可以帮助我了解我需要进行哪些更改才能使其正常工作吗？

提前致谢！！！

【问题讨论】：

标签： kubernetes-helm minikube nginx-ingress

【解决方案1】：

我在Custom DNS Entries For Kubernetes 文章中找到了对您的问题和解决方案的很好解释：

假设我们有一个服务，foo.default.svc.cluster.local，外部客户可以使用foo.example.com。也就是说，在集群外部查找时，foo.example.com 将解析为负载均衡器 VIP——服务的外部 IP 地址。在集群内部，它将解析为相同的事物，因此在内部使用此名称将导致流量发夹 - 离开集群，然后通过外部 IP 返回。

解决办法是：

相反，我们希望 foo.example.com 解析到内部 ClusterIP，避免发夹。

为了在 CoreDNS 中执行此操作，我们使用了 rewrite 插件。这个插件可以在查询被发送到任何后端将要回答它之前修改它。

为了得到我们想要的行为，我们只需要添加一个重写规则映射foo.example.com到foo.default.svc.cluster.local：

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        rewrite name foo.example.com foo.default.svc.cluster.local
        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
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-01-09T15:02:52Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "8309112"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: a2ef5ff1-141f-11e9-9043-42010a9c0003

注意：在您的情况下，您必须将入口服务名称作为别名的目的地。
（例如：rewrite name hello.life.com ingress-service-name.ingress-namespace.svc.cluster.local）确保使用正确的服务名称和命名空间名称。

一旦我们通过 kubectl edit configmap coredns -n kube-system 或 kubectl apply -f patched-coredns-deployment.yaml -n kube-system 将其添加到 ConfigMap，我们必须等待 10-15 分钟。最近的 CoreDNS 版本包括 reload plugin。

重新加载

名称

reload - 允许自动重新加载已更改的 Corefile。

说明

此插件通过读取并计算其 MD5 校验和来定期检查 Corefile 是否已更改。如果文件已更改，它会使用新的 Corefile 重新加载 CoreDNS。这消除了在更改核心文件后发送 SIGHUP 或 SIGUSR1 的需要。

重新加载是优雅的 - 当重新加载发生时，您应该不会看到任何服务丢失。即使新的 Corefile 有错误，CoreDNS 也会继续运行旧的配置，并且会在日志中打印一条错误消息。但请参阅错误部分了解故障模式。

在某些环境（例如 Kubernetes）中，可能有许多 CoreDNS 实例几乎同时启动并且都共享一个共同的 Corefile。为了防止这些都同时重新加载，在重新加载检查间隔中添加了一些抖动。这是从多个 CoreDNS 实例的角度来看的抖动；每个实例仍会定期检查，但所有这些实例的重新加载都将分布在抖动持续时间中。鉴于重新加载是正常的，这并不是绝对必要的，并且可以通过将抖动设置为 0 来禁用。

每次重新加载 Corefile 时都会重新计算抖动。

运行我们的测试 pod，我们可以看到这是有效的：

$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools
If you don't see a command prompt, try pressing enter.
/ # host foo
foo.default.svc.cluster.local has address 10.0.0.72
/ # host foo.example.com
foo.example.com has address 10.0.0.72
/ # host bar.example.com
Host bar.example.com not found: 3(NXDOMAIN)
/ #

【讨论】：