Kubernetes: Ingress: разрешить несколько хостов

+1 за это тоже. Как указано мной и https://github.com/kubernetes/kubernetes/issues/41881 , это будет иметь большое значение.

Я предпочитаю иметь подстановочный знак или параметр только для поддомена, поэтому я могу указать host: web.* или host: api.web.* и получить все, что _starts_ с этим шаблоном, пройдя через этот шаблон, оставив службу в неведении относительно ее конечного домена (работает ли он в .example.com ? .prod.example.com ? .beta.example.com ? .it.internal ?), но все, что перемещает его за пределы текущего монолитного ", должно содержать список всего одного домена в host: - большой шаг вперед.

Лично я также считаю, что входной контроллер (который обычно развертывается администраторами кластера) должен иметь ограничение, которое гласит: «Обслуживать только следующие домены или их поддомены ...», но это отдельная проблема.

Еще +1. Я думаю, что от этого выиграет почти любой, у кого нетривиальный пример использования входящего трафика.

+1

+1

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Предотвратить автоматическое закрытие проблем с помощью комментария /lifecycle frozen .

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или @fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Видимо не могу удалить из устаревшего ...

похоже, это сработало @deitch !

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

spec:
  rules:
  - host: foobar.com
    http: &http_rules
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80
  - host: api.foobar.com
    http: *http_rules
  - host: admin.foobar.com
    http: *http_rules
  - host: status.foobar.com
    http: *http_rules

Мне нечего добавить, кроме как сказать, что это было бы очень приятно. Будем надеяться, что правила для бета-интерфейсов API по-прежнему допускают некоторую гибкость для изменения этого.

то же самое здесь - нужно добавить несколько доменов, т.е.

*.foobar.com
*.foobar.net
*.foobar.biz

что не совсем удобно в текущей реализации ...

итак, голосуйте за ...

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв на sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Это очень нужно: ((

+1 за эту функцию.

Я также попробовал предложить обходной путь @kramarz и получил следующую ошибку:
Error: YAML parse error on mysite-web/templates/ingress.yaml: error converting YAML to JSON: yaml: line 4: mapping values are not allowed in this context

+1 за эту функцию.

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв на sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

функция действительно нужна

Пример использования, который я еще не видел, у нас есть несколько доменов, которые выглядят как api[0-9].domain.io - существующие домены с подстановочными знаками не охватывают этот случай. Набор достаточно мал, чтобы управлять вручную с использованием идентификаторов yaml, но был бы идеальным, чтобы не требовать этого запасного варианта (например, доменных имен регулярных выражений).

Нам действительно нужна эта функция

Еще один голос за эту функцию

другая работа с использованием цикла диапазона:

rules:
          {{- range .Values.ingress.hosts }}
    - host: {{ . }}
      http:
        paths:
          - path: /
            backend:
              serviceName: {{ $fullName }}
              servicePort: 80
              {{- end }}

и в значениях yaml:

ingress:
  hosts:
    - "bla.blub"
    - "foo.bar"

и установите переменную fullName ...

Тем не менее, я бы предпочел массив или регулярное выражение или ... для элемента hosts

Это почти наверняка не происходит в Ingress, но мы должны помнить об этом, чтобы API следил за Ingress (скоро появятся предложения?)

API для подписки на Ingress, @thockin? Есть замена в работе?

В Ingress этого почти наверняка не происходит.

Нет? Кажется, это часто запрашиваемая функция, позволяющая избежать большого количества дублирования. - Какие у нас альтернативы?

Может быть полезно для кого-то, я использую опцию server-alias на входе nginx, чтобы иметь несколько доменов для одного входа.

Может быть полезно для кого-то, я использую опцию server-alias на входе nginx, чтобы иметь несколько доменов для одного входа.

@catalinpan как это работает с вашей стороны? Мой псевдоним сервера не работает с этой конфигурацией.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foobar-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-alias: "two-app.foobar.dev"
spec:
  tls:
  - secretName: tls-secret
  rules:
  - host: "one-app.foobar.dev"
    http:
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80

@angelogwapo стоит проверить, поддерживает ли здесь, как должен выглядеть синтаксис rewrite-target .
Есть случай, когда ваш псевдоним не будет работать, если есть другой вход, который использует тот же домен, вот объяснение.

Если приведенный выше случай не относится к вам и запись DNS для two-app.foobar.dev указывает на тот же балансировщик нагрузки, что и one-app.foobar.dev ваш пример должен работать.

Я управляю псевдонимом сервера в Route 53 с помощью terraform из-за моего конкретного варианта использования, нескольких развертываний в разных регионах = несколько псевдонимов сервера CNAME, указывающих на несколько хостов с проверками работоспособности и еще несколькими параметрами.

пример:
CNAME two-app.foobar.dev -> one-app-ew1.foobar.dev
CNAME two-app.foobar.dev -> one-app-ase1.foobar.dev

Ниже приведен пример того, что я использую.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-alias: public_url
  name: app1
spec:
  tls:
  - hosts:
    - public_region_url
      secretName: my_wildcard
  rules:
    - host: public_region_url
      http:
        paths:
          - path: /
            backend:
              serviceName: app1
              servicePort: 80

Эту функцию было бы здорово иметь для пользователей traefik, которые также используют автоматическую функцию Let's Encrypt. Здесь traefik ожидает в качестве Хоста список доменов, разделенных запятыми (https://docs.traefik.io/v1.7/configuration/acme/#onhostrule), где первый домен станет основным доменом сертификата, а все остальные будут SAN s.

@catalinpan Я также
Конфигурация у меня почти такая же, как у @angelogwapo. У меня два домена:

• one-app.one-domain.dev
• two-app.two-domain.dev

Оба указывают на один и тот же балансировщик нагрузки. У обоих есть действующий сертификат TLS.
Ниже моего config. Я попадаю на нужную страницу, но сертификат TLS действителен только для домена, указанного в качестве хоста. Когда я перехожу к другому домену, мне предоставляется поддельный сертификат Kubernetes Ingress Controller. Наоборот. Любая помощь приветствуется ...

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    app.kubernetes.io/instance: ngress-rules
    cert-manager.io/issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/server-alias: two-app.two-domain.dev
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: ingress-rules
  namespace: default
spec:
  rules:
  - host: one-app.one-domain.dev
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /
      - backend:
          serviceName: service2
          servicePort: 80
        path: /portal/
  tls:
  - hosts:
    - one-app.one-domain.dev
    secretName: one-app-tls
  - hosts:
    - two-app.two-domain.dev
    secretName: two-app-tls

Кстати, я использую версию 0.27, которая должна содержать это изменение: https://github.com/kubernetes/ingress-nginx/pull/4472/files#diff -9bba411a7c28f1ef63c3a5339db109d5

@jacqinthebox : ваша конфигурация Ingress фактически настраивает только один хост ( one-app.one-domain.dev ). Конечно, ваш tls настраивает их оба, но вам все равно нужно одно правило для каждого домена. В частности, смотрите массив под spec.rules . В настоящее время нет ничего, что указывало бы NGINX, к какой службе должен подключаться 2-й домен.

РЕДАКТИРОВАТЬ : Моя проблема, я был слишком быстр. Я не понимал, что вы говорили об аннотации псевдонима сервера.

@jacqinthebox

Оба указывают на один и тот же балансировщик нагрузки. У обоих есть действующий сертификат TLS.

вы можете использовать несколько независимых доменов в одном секрете TLS
`` tls:

• хосты:
  
  
  
  • one-app.one-domain.dev
  
  
  • two-app.two-domain.dev
    
    secretName: all-app-tls
    
    `` ''
  
  

Вы всегда можете использовать диаграмму управления для создания конфигурации дублирования для каждого домена в массиве. "Если" вы, конечно, пользуетесь штурвалом :)

+1

@kramarz , Спасибо, этот workround у меня поработал.

Обходной путь также отлично работает с https://github.com/jetstack/cert-manager .
Вот мой пример

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
   name: site
   annotations:
      cert-manager.io/issuer: letsencrypt-prod
      nginx.ingress.kubernetes.io/server-alias: host2.com
spec:
   rules:
   - host: host1.com
     http:
      paths:
      - path: /
        backend:
           serviceName: site
           servicePort: 8080
   tls:
   - secretName: nice-name
     hosts:
     - host1.com
     - host2.com

@AndreKoepke спасибо за это. У меня это сработало, но после добавления domain.com к spec.rules[0].host и www.domain.com,domain.se,www.domain.se к nginx.ingress.kubernetes.io/server-alias я получаю следующую ошибку: controller.go:1155] Conflicting hostname (domain.com) and alias (www.domain.se). Removing alias to avoid conflicts.

Какие-либо предложения?