Автоматизация поддержки субдоменов подстановочных знаков для Kubernetes с помощью оператора Helm - PullRequest
0 голосов
/ 28 декабря 2018

Вот мой пример использования: у нас есть клиент, где каждая из его услуг должна быть доступна на выделенном поддомене.Соглашение об именах должно быть service-name.customerdomain.com, где service-name - развернутая служба, а customerdomain.com - домен клиента.Когда создается новая служба, она должна быть доступна автоматически , т. Е. После развертывания службы service-name в кластере она должна быть доступна на service-name.customerdomain.com.

Я знаю,это можно сделать вручную , выполнив следующие действия:

  1. Добавить входящий контроллер в кластер

  2. Создать подстановочный знак DNS *.customerdomain.com и укажите его для контроллера Ingress

  3. Сопоставьте поддомен для каждой работающей службы.Для каждой существующей службы из кластера создайте отдельный раздел в файле ресурсов Ingress ingress.yaml, например,
Spec:     
    rules: 
    - host: helloworld.awesome-customer.com 
    http: 
        paths: 
        - path: /* 
        backend: 
            serviceName: helloworld 
            servicePort: 8080 
    - host: nextfineapp.awesome-customer.com 
    http: 
        paths: 
        - path: /* 
        backend: 
            serviceName: nextfineapp 
            servicePort: 8080 
    - [...]
Добавить файл ресурсов Ingress новый раздел -host для каждой вновь развернутой службы Удалить файл ресурсов Ingress -host раздел для каждой удаленной службы

В основном - я бы хотелавтоматизировать шаги 4 и 5. Я знаю, что Ingress не может справиться с этим сам, однако, прибегая к помощи, кажется, что обновление файла ingress.yaml при каждом развертывании новой службы / удалении существующей может быть достигнуто с помощью Helm и файлы его значений.

Я был бы признателен, если бы можно было указать / описать пример решения.

Ответы [ 2 ]

0 голосов
/ 28 декабря 2018

Я бы порекомендовал пойти с предложением @ coderanger.Если вы добавите Ingress в рулевую диаграмму, то ею можно будет управлять через файл values.yaml.Это то, что делают официальные диаграммы руля kubernetes.Однако это не совсем автоматизация создания Ingress, так как шаблонный исходный файл Ingress все еще там.Это скорее шаблонизация, чем автоматизация.

Для дальнейшей автоматизации вы можете посмотреть на контроллер доступа Jenkins-X.Это необходимо будет развернуть в вашем кластере, а затем он будет отслеживать, какие службы развернуты и какие у них есть пометки для автоматического создания Ingresses.При этом вам по-прежнему нужны аннотации, поскольку вы должны указать, какие сервисы выставлять и какую логику маршрутизации применять к ним.Если вы используете helm, ваши файлы значений в конечном итоге будут одинаковыми, независимо от того, используете ли вы контроллер expose или помещаете ресурсы Ingress в диаграммы.

Контроллер открытости Jenkins-X также может работать с подстановочными символами DNS.На самом деле Jenkins-X использует подстановочный DNS и выставляет контроллер по умолчанию, так что вы можете следовать одному из их руководств, чтобы увидеть это в действии.Поскольку они поддерживают это для разных платформ, их документы могут помочь узнать, как настроить подстановочный DNS для разных облачных провайдеров, например https://aws.amazon.com/blogs/opensource/continuous-delivery-eks-jenkins-x/

0 голосов
/ 28 декабря 2018

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

...