Добавление хоста без www not работы с ресурсом Ingress - PullRequest
Новая
       3

Добавление хоста без www not работы с ресурсом Ingress

1 голос
/ 26 февраля 2020

У меня есть пара вопросов

  1. Когда мы вносим изменения во входной ресурс, есть ли случаи, когда нам нужно удалить ресурс и заново создать его, или kubectl apply -f <file_name> достаточно?

  2. Когда я добавляю атрибут хоста без www i.e. (my-domain.in), я не могу получить доступ к своему приложению, но с www i.e. (www.my-domain.in) оно работает, в чем разница?

Ниже представлен мой входной ресурс

Когда для хоста установлено значение my-domain.in, я не могу получить доступ к своему приложению, но когда я установил для хоста значение www.my-domain.in, я могу получить доступ к приложению .

мой домен принадлежит другому провайдеру, и я добавил CNAME (www), указывающий на DNS-имя моего ALB. 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: eks-learning-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:a982529496:cerd878ef678df
  labels:
    app: eks-learning-ingress
spec:
  rules:
  - host: my-domain.in **does not work**
    http:
      paths:
        - path: /*
          backend:
            serviceName: eks-learning-service
            servicePort: 80

1 Ответ

1 голос
/ 26 февраля 2020
  • Первый ответ на ваш вопрос 1:

    Когда мы вносим изменения во входной ресурс, есть ли случаи, когда нам нужно удалить ресурс и заново его создать или применяется kubectl - достаточно? ?

Теоретически, да, kubectl apply - это правильный путь , либо он покажет ingress unchanged, либо ingress configured.

Другая допустимая документированная опция - kubectl edit ingress INGRESS_NAME, которая сохраняет и применяется в конце издания, если выходные данные верны.

Я сказал теорию, потому что ошибки случается, поэтому мы не можем полностью отказаться от него, но ошибка - это худший сценарий.

  • Теперь размытый вопрос 2:

    Когда я добавляю атрибут host без www i.e. (my-domain.in), я не могу получить доступ к своему приложению, но с www i.e. (www.my-domain.in) оно работает, в чем разница?

Для устранения неполадок нам нужно изолировать процессы, как в цепочке, мы должны найти, какая ссылка нарушена. Один за другим:

Конечная точка> Провайдер домена> Провайдер облака> Вход> Служба> Под.

  1. Разрешение DNS (провайдер домена )
  2. Разрешение DNS (облачный провайдер)
  3. Вход Kubernetes (вход> Служба)

Разрешение DNS

Провайдер домена:

Для Inte rnet, который отвечает за my-domain.in, является вашим провайдером домена.

  • Каковы правила для my-domain.in а это субдомены (вроде www.my-domain.in или admin.my-domain.in)? Вы сказали, что "домен принадлежит другому провайдеру, и я добавил CNAME (www), указывающий на DNS-имя моего ALB."
    • my-domain.in и my-domain.in перенаправляются на ALB адрес инстинктивно?
    • Как он обрабатывает поддомен URL? как запрос передается в ваше облако?

Облачный провайдер:

Хорошо, облачный провайдер получает запрос правильно и отчетливо.

Kubernetes Ingress

Обычно мы начинаем устранение неполадок с этой части, но поскольку вы упомянули, что это работает с www.my-domain.in мы можем предположить, что ваша служба, развертывание и даже структура входа работает правильно.

Вы можете проверить Типы входных документов , чтобы получить несколько примеров того, как это должно работа.

Итог: Я считаю, что у вашего DNS есть маршрут для www.my-domain.in, но у домена root нет маршрута к вашему облачному провайдеру, поэтому он работает только при включении вход для www.

...