A
Пооблизывайтесь, если реально интересно https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Size: a a a
2021 April 06
VC
спасибо, в процессе в принципе
AP
Мало опыта с мониторингом, у нас был готовый уже с настройками IBM Tivoli.
VC
есть разница делать что-то с помощью хорошо знакомого инструмента или практически незнакомого
VR
ну начните с того, что автоматизировать это любой SCM - утилитой - ansible, salt, chef, puppet
еще хороший тон - запретить вносить изменения руками через консоль.
еще хороший тон - запретить вносить изменения руками через консоль.
A
Давно бы уже поставили и за пару вечеров разобрались. Вопросы можно и тут задать.
VR
о рисках того, что инструмент deprecated вас предупредили
в целом, вы правы - знакомым инструментом - меньше рисков накосячить
но в том, что вы описали нет потребностей делать оркестрацию.
в целом, вы правы - знакомым инструментом - меньше рисков накосячить
но в том, что вы описали нет потребностей делать оркестрацию.
VC
автоматизация SCM в процессе, но вот HA на ней делать с помощью резервирования планов нет
A
Оркестрация может быть с двух сторон: правильный pipeline самого ci cd те же конфиги до серверов вам доставит без разницы что у вас кубер или нет, а вот оркестрация контейнеров, серверов и т.п. это уже несколько другая задача.
VC
да проблема не в поставить основная, а в том, чтобы приложение туда завести
VC
по моему опыту (сворм, кубер) она сильно упростит нам жизнь
A
Конвертните ваши compose в формат кубера и попробуйте поднять. https://kompose.io/
VR
мой совет - декомпозировать проблемы:
- проблема раз - решаем так
- проблема два - решаем так
и последовательно закрывать.
мой поинт в том, что миграция на иную платформу не решит текущих проблем, но добавит новых.
другой вопрос, что:
- доработка приложения под требования платформы (12 факторов!) может идти отдельным стримом - разработчики делать будут же
- написание тестов - отдельно
- подготовка миграции на иную платформу (swarm, k8s или nomad - не важно) - отдельно.
- проблема раз - решаем так
- проблема два - решаем так
и последовательно закрывать.
мой поинт в том, что миграция на иную платформу не решит текущих проблем, но добавит новых.
другой вопрос, что:
- доработка приложения под требования платформы (12 факторов!) может идти отдельным стримом - разработчики делать будут же
- написание тестов - отдельно
- подготовка миграции на иную платформу (swarm, k8s или nomad - не важно) - отдельно.
i
Вредные советы тут лол
A
Ну хоть что-то для начала на пощупать :) А что такого сверхвредного?
VR
да тут таких советов просто вагон.
выше вон вообще говорили, что если опыта с кубером нет - то внедрение кубера не ухудшит доступности приложения.
выше вон вообще говорили, что если опыта с кубером нет - то внедрение кубера не ухудшит доступности приложения.
VR
супервредное в совете - утилита kompose ;)
не надо такое советовать.
просто не надо.
не надо такое советовать.
просто не надо.
AP
Стоить ли с помощью Kompose изучать Кубер, если знаю Compose?
VC
щупал я на прошлом проекте: 3 месяца фуллтайм осваивал кубер, хелм, хелмфайл и тп путем перевода с композа В итоге выгорел и уволился