Часто от начинающих (и продолжающих) разработчиков и DevOps-инженеров мы слышим, что полной картины, как развивать свои навыки, нет. Поэтому мы в школе Metaclass решили подготовить полную специализацию по DevOps и выбрали 13 важных тем.
Несколько лет назад мы в KTS переводили управление всей инфраструктурой на новый стек и выбирали между разными оркестраторами. Выбрали Kubernetes и не ошиблись. Сейчас у нас больше 10 дев- и продакшн-кластеров.
18 ноября, в 19:00 на вебинаре мы расскажем плюсы и минусы каждой технологии. Будет полезно всем, кто, как и мы, выбирает оркестратор, или просто тем, кому интересен devops.
Также развеем распространенные страхи: подтвердим, что Kubernetes большой и сложный, но подскажем, как с этим жить.
Когда-то этот курс был частью Kubernetes База, но потом мы поняли, что он настолько обширный, что заслуживает отдельного внимания. Мы собрали команду профессионалов и записали видеокурс, чтобы закрыть все вопросы по мониторингу и логированию.
Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный “кластер Kubernetes”. (Это будет намного проще, чем Kubernetes The Hard Way.)
Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!
Эфемерные тома CSI позволили расширять Kubernetes с помощью драйверов CSI для обеспечения поддержки легковесных локальных томов. Этим способом возможно применять произвольные структуры: настройки, секреты, данные для идентификации, переменные и так далее. CSI драйверы должны быть доработаны для поддержки этой функции Kubernetes, поскольку предполагается, что обычные стандартизированные драйверы не будут работать - но предполагается, что такие тома можно использовать на любом узле, выбранном для пода.
Ознакомившись с этим руководством, вы научитесь легко задавать целевые уровни обслуживания (SLO, от англ. Service Level Objectives) для работоспособности сервисов в Kubernetes с помощью Prometheus, базы данных временных рядов с открытым исходным кодом, и Linkerd, сверхлегкой сервисной сетки с открытым исходным кодом. Вы узнаете, как с помощью сервисной сетки можно получать согласованные показатели для параметров, которые вы хотите измерять, что является одним из самых сложных аспектов SLO.
Однако, перед тем как начать, давайте разберемся, почему SLO и Kubernetes идут рука об руку.
Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта?
Мы приготовили для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!
Одновременно с ростом кластера растет количество ресурсов, volume и других API-объектов. Рано или поздно вы упретесь в потолок, будь то etcd, память или процессор. Зачем подвергать себя ненужной боли и проблемам, если можно установить простые — хотя и довольно изощренные — правила? Вы можете настроить автоматизацию и мониторинг, которые будут содержать кластер в аккуратном состоянии. В статье разберемся, как избавиться от лишних нагрузок, через которые утекают ресурсы, и устаревших накопившихся объектов.
По мере своего карьерного роста я все чаще и чаще испытываю чувство дежа вю. Во время личной или деловой встречи моему собеседнику достаточно упомянуть какой-то малозначительный факт — и я сразу же вспоминаю о событии, которое произошло со мной несколько лет (или даже «работ») назад. Чаще всего это касается неверно принятых мною решений, последствия которых пришлось расхлебывать долгие месяцы. Такие флешбеки настолько сильны, что я едва сдерживаюсь, чтобы не закричать человеку в лицо: «Ни в коем случае не делай X!». Почему сдерживаюсь? Всё просто: моих коллег не было в том месте и в то время и они попросту не поймут, каких ужасов я натерпелся в подобной же ситуации.
Именно поэтому я решил написать о худших ошибках, допущенных мною за годы работы. Возможно, эта статья сможет уберечь вас от неприятностей. Не переживайте: свои собственные ошибки вы всегда совершить успеете, на них я не покушаюсь. Но рассказ о моих заключениях наверняка пойдет вам на пользу.
