Переход с обычных кубернетов на руль без простоев

У меня есть несколько приложений, развернутых в кластере Kubernetes. У меня есть квитанции и т. Д. В виде файлов yaml, и я развертываю и применяю все с помощью kubectl.

Я решил перейти на helm из-за его функций и избежать репликации кода между dev и prod (я мог использовать переменные и т. Д.).

Проблема в том, что мои сервисы - это AWS ELB, и, насколько я узнал, чтобы перенести что-то, уже развернутое с помощью kubectl, на helm, мне нужно удалить его и снова установить с помощью helm, что уничтожит и воссоздает мои ELB. , поэтому мне нужно будет изменить записи DNS и т. д. Вдобавок ко всему у меня будут простои, что на самом деле нежелательно.

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

Другая стратегия - запустить новый кластер, чего я действительно не хочу делать.

Есть ли другие альтернативы?


kubernetes kubernetes-helm
person caarlos0    schedule 04.12.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Правильно спроектированная диаграмма должна размещать ресурсы в пространстве имен на .Release.Name. Таким образом вы сможете развернуть диаграмму вместе с имеющимся у вас программным обеспечением. Вполне вероятно, что вы сможете создать большую часть своего стека параллельно, а затем обновить свои внекартовые сервисы, чтобы они указывали на модули на диаграмме, таким образом вы можете определить как сервисы на диаграмме, так и вне диаграммы и работать с двумя различные ELB, и если вы хотите избавиться от нестандартных значений, просто отредактируйте DNS и дайте ему возможность распространиться, а затем, через день, неделю или месяц, вы можете отбросить его и оставить только диаграмму.

person Radek 'Goblin' Pieczonka    schedule 04.12.2017
comment
да, проблема в том, что я хочу, чтобы обе диаграммы управления имели то же имя, что и предыдущая развернутая служба / развертывание / и т. д., поэтому, если у меня helm install --name foo ./Charts/foo и у меня уже есть сервис, развертывание и т. д. с именем foo, он сломается, Правильно? - person caarlos0; 04.12.2017
comment
вот почему имена руля по умолчанию - это случайные вещи, такие как funky-penguin, я использую такие вещи, как <env>-<name>, т.е. prod-myapps (работая в основном с зонтичными диаграммами, которые объединяют несколько поддиаграмм), таким образом было бы легко получить сервис вне диаграммы mysvc1 с селектором, жестко запрограммированным на что-то вроде app: prod-myapps-myapp1 с svc на диаграмме prod-myapps-mysvc1 - person Radek 'Goblin' Pieczonka; 04.12.2017
comment
хм, да, проблема в том, что у нас уже есть все, как foo, так что команда привыкла к kubectl get pods -l app=foo или просто _3 _... - person caarlos0; 04.12.2017