И не очень понимаю доводы против rke, когда зависимость от докера вдруг стала проблемой ?
Видимо в тот момент, когда K8s перевел Docker в статус deprecated и он перестал быть индустриальным стандартом как container runtime. По этой же причине, по заявлению SUSE, разработка и поддержка RKE первой версии завершится в 2025 году и всем придется мигрировать на RKE2 для дальнейшей поддержки и обновлений.
на rke2 откатываться крайне сложно (понятно, что кейс редкий, но все же) да и обновлять его весело, одна операция systemctl restart rke2-server чего стоит.
А вот это печально. Надо попробовать в ближайшее время. А если в этом плане RKE2 сравнивать с другими инструментами, например с kubeadm?
Дайте знать, если напишете статью по этой теме. Если такой информации нет в документации и во всех статьях по развертыванию, то должен выйти максимально полезный материал.
Поправил финальный абзац в главе про балансировку внешнего трафика: написал там не то, что хотел. Безусловно, в пуле адресов нужно указывать IP узлов и использовать health чеки, а не ту DNS запись.
А вариант с DNS в качестве fixed registration address, кажется, не так критичен, учитывая, что узел обращается к нему только разово, когда мы делаем его join в кластер. Соответственно, по round-robin он доберется до рабочего узла и подключится к кластеру. Но соглашусь, что даже тут лучше рассмотреть другой вариант для HA.
Спасибо за комментарий, роль для Ansible попробую. Круто, что ей же можно сразу задеплоить кастомные манифесты на этапе установки RKE.
К вышеперечисленному добавлю базовое знание сетей. Я обращаю внимание на основы: администрирование Linux + навыки автоматизации + понимание и опыт работы с Docker. Остальные знания уже как дополнительный плюс кандидату.
Наличие курсов необязательно, но отмечаю это при просмотре резюме. Из недавнего - наняли выпускника Яндекс Практикума, который закончил их курс по DevOps, а ранее работал системным администратором.
Рассказываю как устроено у нас. Для примера возьму объекты Deployment.
Имеется 25 деплойментов в dev среде, столько же нужно запустить в проде. В процессе переноса из композа в кубер мы быстро убедились, что описания объектов довольно однотипные. Шаблонизация позволила соблюсти принцип DRY — не повторять похожие друг на друга куски конфигурации. Вместо 50 yaml манифестов у нас всего 1 файл-шаблон и 3 values файла. Если мне нужно будет поправить базовую конфигурацию манифеста, то я делаю это в файле-шаблоне. Если мне нужно поправить параметры специфичные для конкретного деплоймента, то я делаю это в values-файле – редактирую для него команду запуска, задаю requests/limits, количество реплик. Плюс у некоторых деплойментов могут быть опциональные параметры, которые не нужны для всех (напр. topologyspreadconstraints). В таком случае вместо того, чтобы плодить еще один шаблон я добавляю if-else условие в существующий и включаю опцию для конкретных объектов с помощью переменной.
Если понадобятся примеры конфигов, то они есть в статье, глава про Helm.
Если конфигурируется большое количество объектов, а еще и подразумевается их запуск в нескольких окружениях, то описанный в статье подход с использованием универсальных шаблонов просто удобнее. Нужно смотреть по потребностям, где-то хватит и связки стандартных манифестов + sed, как вы описали.
@vasyakrg
Видимо в тот момент, когда K8s перевел Docker в статус deprecated и он перестал быть индустриальным стандартом как container runtime. По этой же причине, по заявлению SUSE, разработка и поддержка RKE первой версии завершится в 2025 году и всем придется мигрировать на RKE2 для дальнейшей поддержки и обновлений.
А вот это печально. Надо попробовать в ближайшее время. А если в этом плане RKE2 сравнивать с другими инструментами, например с kubeadm?
Дайте знать, если напишете статью по этой теме. Если такой информации нет в документации и во всех статьях по развертыванию, то должен выйти максимально полезный материал.
Поправил финальный абзац в главе про балансировку внешнего трафика: написал там не то, что хотел. Безусловно, в пуле адресов нужно указывать IP узлов и использовать health чеки, а не ту DNS запись.
А вариант с DNS в качестве fixed registration address, кажется, не так критичен, учитывая, что узел обращается к нему только разово, когда мы делаем его join в кластер. Соответственно, по round-robin он доберется до рабочего узла и подключится к кластеру. Но соглашусь, что даже тут лучше рассмотреть другой вариант для HA.
Спасибо за комментарий, роль для Ansible попробую. Круто, что ей же можно сразу задеплоить кастомные манифесты на этапе установки RKE.
Большое спасибо!
К вышеперечисленному добавлю базовое знание сетей. Я обращаю внимание на основы: администрирование Linux + навыки автоматизации + понимание и опыт работы с Docker. Остальные знания уже как дополнительный плюс кандидату.
Наличие курсов необязательно, но отмечаю это при просмотре резюме. Из недавнего - наняли выпускника Яндекс Практикума, который закончил их курс по DevOps, а ранее работал системным администратором.
А вы как обучаетесь?
Про ЗП не могу раскрыть информацию)
Рассказываю как устроено у нас. Для примера возьму объекты Deployment.
Имеется 25 деплойментов в dev среде, столько же нужно запустить в проде. В процессе переноса из композа в кубер мы быстро убедились, что описания объектов довольно однотипные. Шаблонизация позволила соблюсти принцип DRY — не повторять похожие друг на друга куски конфигурации. Вместо 50 yaml манифестов у нас всего 1 файл-шаблон и 3 values файла. Если мне нужно будет поправить базовую конфигурацию манифеста, то я делаю это в файле-шаблоне. Если мне нужно поправить параметры специфичные для конкретного деплоймента, то я делаю это в values-файле – редактирую для него команду запуска, задаю requests/limits, количество реплик. Плюс у некоторых деплойментов могут быть опциональные параметры, которые не нужны для всех (напр. topologyspreadconstraints). В таком случае вместо того, чтобы плодить еще один шаблон я добавляю if-else условие в существующий и включаю опцию для конкретных объектов с помощью переменной.
Если понадобятся примеры конфигов, то они есть в статье, глава про Helm.
Если конфигурируется большое количество объектов, а еще и подразумевается их запуск в нескольких окружениях, то описанный в статье подход с использованием универсальных шаблонов просто удобнее. Нужно смотреть по потребностям, где-то хватит и связки стандартных манифестов + sed, как вы описали.