Разрешить pod доступ к доменным именам службы через вход

Question

У меня есть сервис и входная настройка на моем кластере minikube kubernetes, который предоставляет доменное имя hello.life.com Теперь мне нужно получить доступ к этому домену из другого модуля как 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

Я нашел хорошее объяснение вашей проблемы и ее решение в Пользовательских записях DNS для 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)Убедитесь, что вы используете правильное имя службы и имя пространства имен.

Как только мы добавим это в ConfigMap через kubectl edit configmap coredns -n kube-system или kubectl apply -f patched-coredns-deployment.yaml -n kube-system, нам придется ждать 10-15 минут.Последние версии CoreDNS включают плагин перезагрузки .

---

перезагрузка

Имя

перезагрузка - позволяет автоматическую перезагрузку измененногоCorefile.

Описание

Этот плагин периодически проверяет, изменился ли Corefile, читая его и вычисляя контрольную сумму MD5.Если файл изменился, он перезагружает CoreDNS с новым Corefile.Это избавляет от необходимости посылать SIGHUP или SIGUSR1 после изменения Corefile.

Перезагрузки изящны - вы не должны видеть никаких потерь в обслуживании, когда происходит перезагрузка.Даже если в новом Corefile будет ошибка, CoreDNS продолжит запуск старой конфигурации, и в журнал будет выведено сообщение об ошибке.Но см. Раздел «Ошибки» для режимов отказа.

В некоторых средах (например, 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)
/ #