Question

我在minikube kubernetes集群上有一个服务和入口设置，它公开了域名hello.life.com 现在我需要从另一个吊舱内部访问该域卷曲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中执行此操作，我们使用 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。

重新加载

名称

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

说明

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

重新加载非常顺畅-重新加载发生时，您应该不会看到任何服务损失。即使新的Corefile出错，CoreDNS仍将继续运行旧的配置，并且错误消息将被打印到日志中。但是请参阅“错误”部分以了解失败模式。

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

只要重新加载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)
/ #

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

1 个答案:

重新加载

名称

说明