Comments 13
Объекты DeploymentConfig накапливаются до определённого количества (типа retention-history limit) или сразу удаляются по завершению работы его pod-а ? В любом случае если возможно указать экземпляр DeploymentConfig в OwnerReferences ReplicaSet-а его pod-a, этот pod будет удалён автоматически с удалением экземпляра DeploymentConfig
Они обновляются кмк, но автор ответит лучше.
при удалении реплика сет просто поднимет новый - деплоймент конфиг те же яйца только в профиль от редхата.
контроллеры - постоянная величина, она просто есть :) никто никуда ничего не удаляет после завершения работы пода
самое забавное - что ReplicationController, это старая версия ReplicaSet, о котором умлочали в "статье"
Здесь я перепутал - ReplicaSet создаётся Deployment-ом, а вот конфигурация деплоймента самого компонента DeploymentConfig запускает создание ReplicationController-а (и его pod-a).
простите - что? :)
DPC-RS ок, конфигурация компонента ? вы имеете в виду количество реплик?
Я имел ввиду конфигурацию развёртываемого компонента, описанного в DeploymentConfig. Впервые о деталях OpenShift деплоймента читаю, так что путаюсь.
коллеги, какой ReplicationController я не понимаю - это старая сущность, автор вещал о ОКД4+, в свежем кубере нет этого
А зачем вы отдали билд на OCP?
почему не отдать его на Jenkins/GCI/Bamboo/etc ?
почему отказались от helm?
imagestreams - imho плохо, зачем тегировать, и отдавать на контейнерную платформу, какой OCP и является, такую важную часть процесса, как сборка и обновление?
как вы смотрите и дебажите билды? что у вас с IAC - в плане сборки?
"— это та же штука, что и деплоймент," - это не так - вы сами описываете различия в этих сущностях.
Далее - я бы для первой статьи о "особенностях" рассмотрел скорее темплейты OCP, чем сравнение "родной" сущности и кастомной.
"Я бы назвал это некой заменой инструмента CI/CD, упрощающей жизнь разработчику" - сложно с Вами согласиться. Разработчик должен получать доступ до пайпалайна, как понимать как он работает. Главная особенность OCP - доступ до терминала, логов, мониторинга, да и в принципе через GUI решение OCP.
Вносить изменения вместе с командой DevOps - а так же, иметь гибкие настройки пайплайна, втч и обращение к секретам, которые не лежат в b64 etcd - вы же банкинг??? =).
А было бы здорово, например использовать Vault? Вы рассматривали интеграцию с волтом при такой сборке?
Как можно таким прямым инструментом заменить тот же jenkins/gitlab-ci? вопрос в теорию, конечно.
"реквестов/лимитов ресурсов для POD’ов" - если Вы пишете о лимитах, то добавьте еще квоты и для самих контейнеров, они так же присутствуют в OCP и чаще более важны, чем то, о чем вы пишите. Вы же наверняка используете пре-стартеры/сопутствующие и сайдкары?
Так же - для знакомства коллег с OCP - приложили бы пример с лимитами к NS, раз у нас тут ямлы.
oc delete pod --field-selector=status.phase==Succeeded -> вы используете это на продуктиве? Тут все же странно, есть прекрасный хелм, о котором я писал выше.
"из maxSurge;" - стоит добавить, что это необязательное значение. Многие компании работают на OKD3, не совсем актуально. Хотя сущности, которые Вы описали - есть в обоих версиях. Тут могу ошибаться.
"Поддержка prehook и posthook" - про HPA расскажите пожалуйста, и кастомные метрики, информация которую Вы взяли из базы знаний редхат не так интересна, ее, я думаю все читали.
Еще несколько вопросов, если у Вас будет время ответить:
"Build клонирует git-репозиторий от ветки main" - мы работаем только по мастеру? Какой это юзкейс для команд? Вы автобилдите что-то? А кастомные ветки? Прошу пояснить.
"репозиторий битбакета или гитхаба" - других систем хранения кода нет/не поддерживается?
"пушит собранный образ в репозиторий кластера"
Как вы пушите в репозиторий кластера и за ним следите? GC? правила версионирования? Это реджестри внутри OCP? Какие правила для обновления для этого необходимы? По каким правилам вы пушите - latest? Или 7ver? Или что вы используете и как тегируете? Как происходит тегирование образа? по ветке/хеш комиту? - тут то и интересно, а не копипаст.
"создаётся новый deployer POD с суффиксом -deploy, который контролирует процесс развёртывания";
как контролирует?
или вы имеете ввиду - что создается дефолтный под с суффиксом деплой при разворачивании компонента? тогда зачем об этом писать?
"создаётся ещё один ReplicationController, который создаёт новый экземпляр POD с нашим приложением""
т.е создается именно новый контроллер? зачем? объясните пожалуйста
после успешного старта контейнера внутри нового POD’а deployer POD завершает работу и переходит в состояние Completed;
как это работает? Readiness проба отработала? Как вы аккумулируете логи? и анализируете ли их?
И самое главное - как вы интегрируете такую сборку с QG?
Если не ошибаюсь - здесь описана работа деплоймента в OpenShift
хорошая статья, так держать!!!
Отличия DeploymentConfig от Deployment и примеры использования