允许pod通过ingress访问服务的域名

Question

我的 minikube kubernetes 集群上有一个服务和入口设置，它公开了域名 hello.life.com 现在我需要从另一个 pod 内部访问这个域作为 curl 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:
    - {}

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

提前致谢！！！

Answer 1

我在Kubernetes的自定义 DNS 条目文章中找到了对您的问题和解决方案的很好的解释：

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

解决办法是：

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

为了在 CoreDNS 中做到这一点，我们使用了重写插件。这个插件可以在查询被发送到任何后端将要回答它之前修改它。

为了获得我们想要的行为，我们只需要添加一个重写规则映射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或将其添加到 ConfigMap kubectl apply -f patched-coredns-deployment.yaml -n kube-system，我们必须等待 10-15 分钟。最近的 CoreDNS 版本包括重新加载插件。

重新加载

姓名

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

描述

该插件通过读取 Corefile 并计算其 MD5 校验和来定期检查 Corefile 是否已更改。如果文件已更改，它会使用新的 Corefile 重新加载 CoreDNS。这消除了在更改 Corefile 后发送 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)
/ #