В преддверии запуска Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.
... а также 5 вопросов, чтобы проверить, насколько успешно у вас идет цифровая трансформация.
Подборка новых шпаргалок, вебинаров, свежих статей и полезных книг в самом полезном дайджесте на просторах #Хабр! Оставайтесь с нами – станьте частью DevNation!
Привет, Хабр! Поговорим о возможностях микросервисной архитектуры и о том, как избежать миллионных трудозатрат на управление жизненным циклом контейнеров?
Развернуть кластер Kubernetes можно легко и быстро. Но чем больше становится приложений, построенных на микросервисной архитектуре, чем они сложнее, тем больше ресурсов и компетенций нужно для управления. А некоторые задачи решить «вручную» просто невозможно. Управление контейнерной инфраструктурой и жизненным циклом контейнеров в мультиоблачной среде оборачивается миллионными трудозатратами.
Встретимся 14 сентября на онлайн-митапе «Не 1 на 1 с Kubernetes: как упростить управление контейнерами». Расскажем, как преодолеть основные препятствия при переходе к микросервисной архитектуре с помощью продуктов семейства VMware Tanzu.
Соберем экспертов КРОК и VMware в области виртуализации и развития бизнеса, чтобы подойти к вопросу комплексно. Обсудим технические особенности решения, его влияние на управление инфраструктурой, разработку и бизнес в целом. Развеем популярные мифы и поделимся опытом реальных внедрений в крупнейших компаниях.
Интересно? Регистрируйтесь по ссылке:
Kubernetes произвел настоящую революцию в распределенных вычислениях. Хотя он решает ряд сверхсложных проблем, появляются и новые вызовы. Одна из таких проблем - обеспечение того, чтобы кластеры Kubernetes были спроектированы с учетом доменов отказов. Проектирование с учетом доменов отказов включает в себя такие аспекты, как предоставление инфраструктуры в зонах доступности, обеспечение того, чтобы физические серверы находились на разных стойках, также необходимо убедиться, что поды, поддерживающие ваше приложение, не окажутся в одном и том же физическом воркере Kubernetes.
Для решения последней задачи можно использовать правила совместного или раздельного существования между подами (inter-pod affinity and anti-affinity rules), и в официальной документации Kubernetes они описаны очень хорошо:
“Сходство между подами (inter-pod affinity) и анти-сходство (anti-affinity) позволяет вам ограничивать, на каких узлах может быть запланирован ваш под, основываясь на метках подов, которые уже запущены на узле, а не на основе меток на узлах. Правила имеют вид "этот под должен (или, в случае anti-affinity, не должен) работать на узле X, если на этом X уже работает один или несколько подов, удовлетворяющих правилу Y". Y выражается как LabelSelector с опциональным ассоциированным списком пространств имен; в отличие от узлов, поскольку поды разделены по именам (и поэтому метки на поды также неявно разделены по именам), селектор меток должен указать, к каким пространствам имен он должен применяться. Концептуально X - это домен топологии, такой как узел, стойка, зона облачного провайдера, регион облачного провайдера и т. д. Вы выражаете его с помощью topologyKey, который является ключом для метки узла, используемой системой для обозначения такого топологического домена; например, см. ключи меток, перечисленные выше в разделе "Интерлюдия: встроенные метки узлов".
Kalm — бесплатное приложение с открытым исходным кодом. Представляет собой стандартный контроллер Kubernetes, который можно установить в любой кластер (версии v1.15 и выше), включая Amazon EKS и Google GKE. Основная цель Kalm — предоставить разработчикам простой пользовательский интерфейс, чтобы упростить работу с K8s.
В этой статье я кратко расскажу о своих любимых инструментах для Kubernetes, уделяя особое внимание новейшим и малоизвестным, которые, как мне кажется, скоро станут популярными.
В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»
Мы в KTS на многих проектах пользуемся услугами managed database от selectel. За этими кластерами нужно следить, и делать это хотелось бы из одной точки. Этой точкой у нас является prometheus, alertmanager и grafana.
Из коробки у selectel нет prometheus exporter для manage-баз данных. Есть внутренние графики и мониторинг, но использовать их затруднительно. Поэтому мы написали свой selectel-exporter, который использует selectel API.
В статье расскажем, почему решили его написать и расскажем, что он умеет.
В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.
Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…
Прошло уже 8 месяца времени с момента первой и пока единственной статьи о инструменте для композинга helm чартов – helmwave.
Что появилось нового? Какие планы?
Сегодня мы поговорим об Azure DevOps и процессах непрерывной интеграции/развертывания.
Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему "как к коду" для развертывания, то вместо классического Azure DevOps в качестве решения можно применить Azure DevOps yaml deployment. В этом примере будет рассказано о шагах по развертыванию в среде kubernetes.
Во-первых, для развертываний Kubernetes можно управлять версиями во время миграций с помощью шаблона helm, а затем вы можете включить независимые от среды миграции, изменив файл values.yaml в шаблоне helm для каждого приложения и среды.
Mattermost - это решение для обмена сообщениями с открытым исходным кодом, созданное для современных компаний и управляемое с помощью Kubernetes. Mattermost предназначен для одновременного обслуживания десятков тысяч пользователей, распределенных по всему миру. Однако в таких масштабах управление через Kubernetes может стать сложным, поэтому команда Mattermost создала K8s оператор, который помогает автоматизировать процессы установки, обновления и восстановление после сбоев.
Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание. В этой статье разберём работу двух Open Source-утилит для аудита безопасности кластера от известных экспертов этой области — Aqua Security.
Инструкция была основана на базе видео "Установка кластера Kubernetes с помощью Kubespray" в Youtube.
Код был форкнут из репозитория https://git.cloud-team.ru/lections/kubernetes_setup и добавлен с патчами в репозиторий https://github.com/patsevanton/kubespray_terraform_yandex_cloud
Самое интересное в этом посте для devops специалистов с опытом это скрипт для создания ansible inventory файла из terraform структур.
В этой статье мы рассмотрим, как более-менее прилично организовать процесс тестирования и публикации чартов, встреченные при этом подводные камни, а также рассмотрим пару великолепных инструментов, которые совершенно незаслуженно получили крайне мало внимания не только на Хабре, но и вообще в русскоязычном сегменте интернета.
Очень кстати, в недавно вышедшем релизе Gitlab 14.1, появился долгожданный функционал хранения Helm-чартов во встроенном Package Registry. Отлично, заодно и разберемся, как его использовать.
Kubernetes используют так или иначе сейчас примерно все, но и задачи решаются совсем разные. Я расскажу про наши требования и разработанные под них решения для управления множеством кластеров. По теме GitOps не так много статей и обсуждений на Хабре, в отличие от англоязычных источников, поэтому будет интересно и услышать мнение тех, кто применял подход на своей практике.
Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.
В таких случаях приходят на помощь «мини-кластеры». Их можно запустить на рабочем ПК, «поиграться» с примитивами, построить новую структуру, а после завершения эксперимента — безвозвратно удалить (ведь это уже отработанный материал!).
Отвечая на эту потребность, разработчики со всего мира пришли со своими решениями для быстрого запуска облегчённого варианта Kubernetes. Все они по-разному организованы и, конечно, обладают разными возможностями. Чем пользоваться, зависит от нужд и предпочтений. Чтобы получше разобраться в них или вообще понять, с чего стоит начать, предлагаем результаты нашего беглого знакомства с некоторыми популярными решениями. Благо, все они достаточно хорошо документированы (как на сайтах, так и в CLI), что существенно ускоряет первое погружение и взаимодействие с ними. В конце статьи будет сводная таблица с основными особенностями решений.
Несколько больших нод или много маленьких?
Управление Kubernetes-кластером - это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь - это обеспечение стабильной и отказоустойчивой работы приложений.
Как site-reliability и DevOps инженерам вам нужно иметь в виду потребности приложений, которые будут запускаться в кластере, и учитывать различные факторы при его проектировании.
Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших - это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?
Здравый смысл подсказывает нам, что ответ лежит где-то посередине, но давайте рассмотрим те факторы, которые могут повлиять на наше решение. Посмотрим на специфику обеих крайностей, прежде чем сделать выбор.
За последние 4,5 года Kubernetes значительно улучшилась с точки зрения удобства использования, и теперь начать работу с Kubernetes стало проще, чем когда-либо. Облачные провайдеры, такие как Amazon AWS, теперь располагают продуктами Kubernetes, которые создают кластеры для вас и управляют ими. Это существенное преимущество по сравнению с созданием собственного кластера Kubernetes.
Один из самых заметных сдвигов в нашей отрасли, который я наблюдал за последние 2 года, заключается в том, что теперь все больше компаний используют Kubernetes в своих производственных нагрузках. Именно сейчас все становится интересным для SRE. Мы получаем возможность учиться друг у друга, обсуждать общие проблемы в области надежности и делиться ее принципами, которым нужно следовать, чтобы укрепить кластеры Kubernetes.
Если у ваших приложений есть конфигурационные файлы, то вам должна быть знакома такая ситуация: создаете приложение, создаете конфигурационный файл, документируете его и через какое-то время понимаете, что нужно добавить еще настроек. Старые настройки теперь уже не отвечают всем требованиям, да и в целом структуру лучше поменять. Что делать? Если формат конфигурации никогда не менять, то с годами конфиг-файл превратится в горы “исторически сложилось”. А если его менять... В таком случае вам всегда придется следить за тем, что конфиги подходят версии продукта, которую вы устанавливаете заказчику. Парни из эксплуатации, клиенты и много кто еще вас за это особо любить не будут.
Решение всех этих проблем — мульти-версионные конфигурации, которые мы подсмотрели у Kubernetes, развили и применили. А теперь мы готовы рассказать и вам, как это работает.
Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.
