Прим. перев.: эта поучительная история Omio — европейского агрегатора путешествий — проводит читателей от базовой теории до увлекательных практических тонкостей в конфигурации Kubernetes. Знакомство с такими случаями помогает не только расширять кругозор, но и предотвращать нетривиальные проблемы.
Доводилось ли вам сталкиваться с тем, что приложение «застревало» на месте, переставало отвечать на запросы о проверке состояния (health check'и) и вы не могли понять причину такого поведения? Одно из возможных объяснений связано с лимитом квот на ресурсы CPU. О нем и пойдет речь в этой статье.
TL;DR:
Мы настоятельно рекомендуем отказаться от CPU limit'ов в Kubernetes (или отключить квоты CFS в Kubelet), если используется версия ядра Linux с ошибкой CFS-квот. В ядре имеется серьезный и хорошо известный баг, который приводит к избыточному троттлингу и задержкам.
В переводе третьей части серии материалов, посвящённых Docker, мы продолжим вдохновляться выпечкой, а именно — бубликами. Нашей сегодняшней основной темой будет работа с файлами Dockerfile. Мы разберём инструкции, которые используются в этих файлах.
Kubernetes отличная платформа как для оркестрации контейнеров так и для всего остального. За последнее время Kubernetes ушёл далеко вперёд как по части функциональности так и по вопросам безопасности и отказоустойчивости. Архитектура Kubernetes позволяет с лёгкостью переживать сбои различного характера и всегда оставаться на плаву.
Сегодня мы будем ломать кластер, удалять сертификаты, вживую реджойнить ноды и всё это, по возможности, без даунтайма для уже запущенных сервисов.
etcd — это быстрая, надёжная и устойчивая к сбоям key-value база данных. Она лежит в основе Kubernetes и является неотъемлемой частью control-plane, именно поэтому критически важно уметь бэкапить и восстанавливать работоспособность как отдельных нод, так и всего etcd-кластера.
В предыдущей статье мы подробно рассмотрели перегенерацию SSL-сертификатов и static-манифестов для Kubernetes, а также вопросы связанные c восстановлением работоспособности Kubernetes-кластера. Эта статья будет посвящена целиком и полностью восстановлению etcd.
Привет! Меня зовут Александр Голиков, я работаю в компании Bercut. Наша компания разрабатывает и развивает IT-решения для операторов цифровых услуг и мобильных сервисов. Коротко говоря, мы помогаем цифровизации бизнеса. В компании я занимаюсь виртуализацией, СХД, мониторингом, разработкой и интеграцией продуктов Bercut c операционными системами. Для агрегации данных и анализа мы используем Prometheus.
В этой статье рассмотрю одну из конфигураций Prometheus в отказоустойчивом режиме, познакомлю вас с Karma alert dashboard и продемонстрирую написание алертов. Напишу несколько простых включений Go Template и рассмотрю ситуацию, где такие включения противопоказаны. Продемонстрирую, как на основе меток можно сделать исключения из общих правил и обучу Prometheus самостоятельно чинить поломки.
Одной из базовых функций языка запросов Prometheus является агрегация временных рядов в режиме реального времени. Также язык запросов Prometheus можно использовать для обнаружения аномалий в данных временных рядов.
Статья Основы мониторинга (обзор Prometheus и Grafana) оборвалась на самом интересном месте. Автор предложил искать и использовать актуальные экспортеры, а читатель такой – окей, где референс? Что ж, давайте рассмотрим топ-10 наиболее полезных экспортеров на начало 2023 года – возможно именно их вам не хватало, чтобы построить свою идеальную систему мониторинга!
Как известно, системные администраторы делятся на 3 категории - кто еще не делает резервные копии, кто уже делает и кто уверен, что из них можно восстановиться. В нашу эпоху DevOps вопрос автоматизации управления резервным копирования стал еще более актуальным, поскольку каждая система предлагает свой уникальный способ создания (и восстановления) дампа и даже в пределах одной системы может быть множество разных способов хранения данных. В этой статье мы обсудим возможные стратегии и доступные технологические решения для создания резервных копий данных для развертываний в Kubernetes и поговорим о возможностях автоматизации и мониторинга процесса резервного копирования.
В первой части мы рассмотрели подходы к созданию резервных копий контейнеров в кластере Kubernetes с использованием restic над каталогом данных и относительно новых возможностей CSI для создания и восстановления мгновенных снимков. Пришло время поговорить о возможностях автоматизации управления резервными копиями, о мониторинге процесса и иных важных DevOps-задачах.
Стандартной Helm-библиотеки и привычных подходов к написанию Helm-чартов обычно хватает для автоматизации несложных приложений. Но когда количество и сложность Helm-чартов растут, то минималистичных Go-шаблонов и неоднозначной стандартной Helm-библиотеки быстро перестаёт хватать. В этой статье речь пойдет о том, как сделать ваши Helm-шаблоны гораздо более гибкими и динамичными, реализуя свои собственные «функции» в Helm, а также эксплуатируя tpl.
NB. Всё описанное было проверено с werf, но так как шаблоны в этой утилите практически идентичны Helm-шаблонам, то и всё нижеприведенное будет полностью или почти полностью совместимо с обычным Helm обеих версий (v2 и v3).
А теперь разберем, как получить от Helm-шаблонов всё, что можно… и даже всё, что нельзя!
В докладе я препарирую Istio, дабы понять, как он работает, какие у него подводные камни и как им правильно пользоваться.
Это мой второй доклад про Istio и Service Mesh. Первый я сделал на конференции Kuber Conf 2021: «Что ждать от внедрения Istio?». Рекомендую ознакомиться сначала с ним, будет несколько проще.
Посмотрим, как использовать опубликованные в Ansible Galaxy роли (Role) в качестве операторов (Operator), управляющих приложениями в Kubernetes, и разберем это на примере создания оператора, который просто устанавливает приложение, гибко настраивая свое поведение в зависимости от среды.
Мы будем использовать Ansible Operator и модуль k8s, чтобы показать, как применять Ansible для создания Kubernetes-приложений.
Нередко при диагностике проблем в кластере Kubernetes мы замечаем, что иногда моросит* один из узлов кластера и, конечно же, происходит это редко и странно. Так мы пришли к необходимости в инструменте, который бы делал ping с каждого узла на каждый узел и отдавал результаты своей работы в виде метрик Prometheus. Нам бы оставалось лишь нарисовать графики в Grafana и быстро локализовать сбойный узел (и при необходимости убрать с него все pod'ы, после чего произвести соответствующие работы**)…
Данная статья написана с целью расширить уже существующую, но рассказывает про особенности связки именно с Microsoft ActiveDirectory, а так же дополняет ее.
В этой статье я расскажу как установить и настроить:
Keycloak — это проект с открытым исходным кодом. Который обеспечивает единую точку входа для приложений. Работает с множеством протоколов, в том числе с LDAP и OpenID которые нас интересуют.
Поиск оптимальных значений для ограничения ресурсов Kubernetes — непростая задача, поскольку вам нужно найти золотую середину между слишком жесткими и недостаточными ограничениями.
В этой статье, которая является продолжением серии статей о рациональном использовании ресурсов в Kubernetes, вы узнаете, как выбрать правильные ограничения ресурсов Kubernetes: от обнаружения контейнеров без каких-либо ограничений до определения оптимальных параметров, которые вы должны установить в своем кластере.
Prometheus — одно из самых популярных решений для мониторинга кластеров Kubernetes. Поэтому каждый шаг в этом руководстве содержит примеры запросов PromQL.
Мы в Badoo постоянно мониторим свежие технологии и оцениваем, стоит ли использовать их в нашей системе. Одним из таких исследований и хотим поделиться с сообществом. Оно посвящено Loki — системе агрегирования логов.
Loki — это решение для хранения и просмотра логов, также этот стек предоставляет гибкую систему для их анализа и отправки данных в Prometheus. В мае вышло очередное обновление, которое активно продвигают создатели. Нас заинтересовало, что умеет Loki, какие возможности предоставляет и в какой степени может выступать в качестве альтернативы ELK — стека, который мы используем сейчас.
Ansible — инструмент управления конфигурациями. Задачи, которые решаются с его помощью, часто повторяются у разных людей и команд. Как и в случае программирования, где общий код выделяют в библиотеку, Ansible выделяет повторяющиеся вещи в роли. В статье объясним, в чём основная идея ролей, а также подробно разберём процесс их создания.
Прим. перев.: Этот материал, озаглавленный в оригинале как «What happens when… Kubernetes edition!» и написанный Jamie Hannaford из компании Rackspace, является отличной иллюстрацией работы многих механизмов Kubernetes, которые зачастую скрыты от нашего глаза, но весьма полезны для лучшего понимания устройства этой Open Source-системы, алгоритма работы и взаимосвязей её компонентов. Поскольку вся статья весьма объёмна, её перевод разбит на две части. В первой речь идёт про работу kubectl, kube-apiserver, etcd и initializers.
P.S. Некоторые оригинальные ссылки на код в master-ветках были заменены на последние к моменту перевода коммиты, чтобы актуальность номеров строк, к которым отсылает автор, сохранялась долгое время.
Представим, что я хочу задеплоить nginx в кластере Kubernetes. Я введу в терминале нечто такое:
kubectl run --image=nginx --replicas=3
… и нажму на Enter. Через несколько секунд увижу 3 пода с nginx, распределённые по всем рабочим узлам. Работает — словно по волшебству, и это здорово! Но что на самом деле происходит под капотом?
В большинстве IT-компаний сейчас сезон ревью и профессиональной рефлексии: что я сделал за год и вырос ли профессионально? Ответить на эти экзистенциальные вопросы проще, если у вас есть PDP, или персональный план развития. Это инструмент, который помогает системно и экологично по отношению к себе двигаться к цели.
Я — Лена Насыбуллина, методист продуктовых образовательных программ в Selectel. В этом тексте расскажу, чем полезен PDP и как его составить.
