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

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

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

假设我们有一个服务，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或kubectl apply -f patched-coredns-deployment.yaml -n kube-system将其添加到ConfigMap，我们必须等待10-15分钟。最近的CoreDNS版本包括reload plugin。

---

重装

Name

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

Description

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

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

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

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

---

运行我们的测试吊舱，我们可以看到这个工作：

$ 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)
/ #