В этой статье будут рассмотрены инструменты наблюдения за сетевой инфраструктурой Kubernetes и основные составляющие Observability/Наблюдаемости – мониторинг, журналы событий, метрики, распределенная трассировка и оповещения. Обсудим, как эти инструменты могут помочь обеспечить надежную и эффективную работу кластеров Kubernetes и запущенных на них микросервисах, а также какие преимущества и недостатки существуют при использовании этих решений.

Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.

HashiCorp Vault имеет в своём арсенале SSH secrets engine, который позволяет организовать защищённый доступ к вашим машинам по ssh, через создание клиентских сертификатов и одноразовых паролей. Про последнее – создание одноразовых паролей (OTP) – мы и поговорим в этой статье.

Привет, Хабр!

В этой статье я расскажу о своем опыте изучения английского языка и поделюсь вещами которые работали и не работали для меня. Процесс изучения языка очень индивидуален, и никогда нельзя утверждать что верный какой-то один метод / схема (хотя некоторые статьи на Хабре прямо говорят: вот этот метод правильный, а вот этот нет).

Начнем с бекграунда и причин.

Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.

Начал свой путь изучения языка я в январе 2022 года с около нулевого уровня. В всех моих школах преподование английского языка было не на самомом высоком уровне, а в университете было достаточно выучить 30 предложений наизусть чтобы получить достойную оценку на экзамене.

Конечно, перед началом обучения я прочитал много статей на хабре о том как люди учат языки. Некоторые из них поражали скоростью овладения материалом (что-то вроде с нуля до fluent за 4 месяца). Но одна вещь была неизменна – у всех был какой-то план изучения языка.

Hello world!

В первой части шпаргалки (вопросника, если угодно) на высоком уровне рассматриваются такие вещи, как сеть, HTTP, операционная система, виртуализация, хранилище etc., а также несколько технологий, используемых в сфере DevOps, таких как Prometheus, OpenStack, Puppet, Elastic etc. (вопросы с ответами из основного репозитория оригинала). Полагаю, шпаргалка будет интересна всем, кто связан с разработкой программного обеспечения, прежде всего, с разработкой веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий/терминов, а также в обнаружении очепяток.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

Привет, Хабр!

Меня зовут Илья Зимин, я аналитик-исследователь угроз в компании R-Vision. Сегодня в статье я расскажу о возможностях обнаружения атак на контейнеризированные приложения с помощью такого инструмента, как eBPF, на примере приемов, связанных с побегом из Docker-контейнеров на Linux-системах.

eBPF (extended Berkeley Packet Filter) — это технология, которая предоставляет программный интерфейс в ядре Linux для обработки его событий в режиме реального времени. Он позволяет загружать и выполнять пользовательские программы в ядре без необходимости модификации самого ядра. Программы выполняются в виртуальной машине, что не позволяет ошибке в пользовательской программе повлиять на всю систему.

Используя возможности eBPF, мы можем отслеживать любое (или почти любое) взаимодействие в системе на уровне ядра, "присоединяясь" к вызовам системных функций, и получать информацию о них: контекст, аргументы, выходные значения и другие. Также на уровне пользователя можно добавить дополнительную логику для обработки этих данных.

В мире, где Kubernetes доминирует в управлении контейнеризированными приложениями, один вопрос часто встаёт перед теми, кто стремится понять его внутренние механизмы: 'Как на самом деле работает k8s scheduler?' Эта статья предназначена для развенчания мифов и предоставления чёткого объяснения работы Kubernetes планировщика. Мы исследуем ключевые моменты этого процесса, начиная от того, назначает ли планировщик модули узлам один за другим в очереди или выполняет эту задачу параллельно, и заканчивая более сложными аспектами его работы. Погрузитесь в детали этой сложной, но увлекательной темы вместе с нами, чтобы лучше понять, как Kubernetes оптимизирует размещение подов в вашем кластере

В ночь с 15 на 16 августа официально выйдет новая версия Kubernetes — 1.28. Среди главных изменений — оптимизация работы с sidecar-контейнерами и задачами (Job). Клиенты теперь будут переадресовываться на тот сервер API, который способен обработать их запрос, что упростит скользящие обновления. Проект Kubernetes продолжает размежевание с инфраструктурой Google — KEP 1731 описывает ряд шагов, направленных на оптимизацию и упрощение релизного процесса.

Мы подробно разобрали все новые фичи Kubernetes 1.28.

Привет! Меня зовут Петр Бобров, в QIWI я отвечаю за отказоустойчивость, расскажу немного историй про сторонних вендоров, у всех они разные. У нас есть карточный процессинг, потому что мы банк, у нас банковская лицензия, проводим много платежей. Еще можно черными ящиками считать и базы данных: кто знает, как там работает Oracle, кто знает, как работает Linux внутри? Думаю, очень немного людей разбирается в этом, как оно работает на низком уровне. 

Мониторить такие вещи достаточно проблематично, особенно, если нужно соответствовать стандарту PCI/DSS, который запрещает выкладывать логи приложений в общий доступ, потому что там потенциально хранятся определенные карточные данные в открытом виде, а в софте отсутствуют какие-то вменяемые интерфейсы, которые тебе могут посылать данные в твои системы мониторинга. В общем, проблем достаточно много, даже бывает такое, что говорили: «Не лезьте со своими SQL-запросами в нашу базу, вы портите нам производительность». Ситуация удручающая, так что мы захотели как-то это поправить. 

Сейчас я покажу пример самописного мониторинга, который я сам мог сделать своим ограниченным интеллектуальным ресурсом. В этом примере мне хочется сфокусироваться на (не)сложности его реализации, а не на содержательном компоненте постановки задачи, хотя мне он тоже был довольно интересен.

В этом докладе я расскажу о мониторинге: о том, как собрать множество метрик из разных мест в одном, как разруливать права для разных частей этих метрик и как хранить большие объемы данных. Еще поговорим о выборе системы мониторинга на примере небольшого сериала о вымышленной компании, система мониторинга которой эволюционирует вместе с ростом инфраструктуры.

Привет! Меня зовут Владислав Попов, я автор курса «Go-разработчик» Яндекс Практикума. Когда-то я сам был студентом — хотел учиться Go, но такого курса в Практикуме не было, поступил на Python. Прошёл вводную часть — и тут стартовал желанный курс по Go. В тот же вечер оформил возврат и перепоступил. Попал в первый поток, прошёл его, и после сдачи итогового проекта мне предложили стать тестером курса «Продвинутый Go-разработчик».

Оба курса были ещё не идеальны — что-то требовало доработки, некоторые темы казались мне недостаточно раскрытыми. Я сообщил об этом команде курса и предложил варианты, что можно улучшить. В какой-то момент о них узнал продакт-менеджер — и так я получил приглашение поработать с командой Практикума. Мне предстояло разработать концепцию и внести предложения по рефакторингу курса, но я сделал бросок пантеры и написал несколько уроков с нуля. Команде они понравились. Так я стал работать в Практикуме.

За время работы с Go я понял, что сам язык не очень сложный и подходит даже в качестве первого, но нужно выучить синтаксис и погрузиться в некоторые особенности, которые отличают Go от других языков: например, интерфейсы и особенности встраивания. А ещё важно на старте хорошо знать Git и ориентироваться в работе SQL (причём любого).

Эта подборка составлена менторами нашего курса по Go-разработке для практикующих программистов. Она родилась благодаря коллективному разуму наших наставников, которые занимают позиции синьор-разработчиков на Go в разных компаниях.

В этой статье мы поговорим об использовании Chaos Mesh — опенсорс-фреймворка для хаос-инжиниринга в Kubernetes. Все развёртывания из этой статьи доступны на GitLab. Клонируйте репозиторий и продолжайте читать.

TL;DR

- отнеситесь серьезно к качеству интернет-соединения. Из РФ ВПН не нужен

- популярные курсы не охватывают экзамен полностью (есть смысл поискать старые дампы на github)

- назначайте первую попытку хотя бы за месяц до окончания времени сдачи экзамена, таким образом, если завалите первую попытку, будет время подготовится ко второй

- за несколько дней пройдите killer.sh, получите выкладку ответов и после прохождения несколько раз пройдите у себя в домашней лабораторной

- обязательно будет задание на анализ поведения, на выбор дают falco и sysdig. Возьмите sysdig, на экзамене он сэкономит время, потренируйтесь в этом перед сдачей.

Замечали, как часто в ИТ-отрасли появляется модное словечко, и тут же все начинают вставлять его в описание своих продуктов, чтобы привлечь побольше внимания?

Сейчас у нас в тренде observability (наблюдаемость), и многие вендоры уже берут его на вооружение.

Что такое observability? Просто навороченная версия мониторинга? Быстрее, выше, сильнее, настоящий Чак Норрис среди DevOps-инструментов! Так и хочется прикупить себе наблюдаемости, правда?

Давайте не будем поддаваться всеобщему ажиотажу и попробуем разобраться, что это такое и откуда вся шумиха.

Kubernetes является фактическим лидером среди систем оркестрации. С ростом популярности микросервисной разработки Kubernetes проявил себя незаменимым инструментом для управления крупномасштабными приложениями и их развёртыванием. Правда, с обилием возможностей, которые предоставляет Kubernetes, этой системой подчас непросто управлять.

В этой статье мы заострим внимание на журналах аудита Kubernetes, чтобы записи всех протекающих событий в нашем кластере можно было заполучить по щелчку пальцев.

В данной статье я постарался изложить на что обратить внимание при написании оператора на golang и на нюансы, которые описываются вскользь или вовсе не описываются в официальном туториале или других статьях подобного вида.

Привет, Олимпийский Хабр! Меня зовут Аня, я работаю в Ozon: строю и развиваю инфраструктуру мониторинга в Observability-платформе. Моя команда помогает разработчикам следить за своими сервисами и своевременно получать алерты, если что-то идёт не так.

На Хабре довольно много статей о том, что такое кроны, как и где можно запускать их по расписанию, о плюсах и минусах каждого варианта и о том, как запускает кроны Kubernetes. Поэтому в моей статье об этом мы говорить не будем.

Я расскажу, как мы решали конкретную проблему мониторинга CronJob, запущенных в Kubernetes.

В Ceph можно распределять пулы с данными по разным типам серверов: «горячие» данные хранить и реплицировать на SSD, «холодные» — на HDD. Кроме того, пулы одного кластера можно разделять физически. В статье расскажем, как это сделать.

Статья подготовлена на основе лекции Александра Руденко, ведущего инженера группы разработки «Облака КРОК». Лекция доступна в рамках курса по Ceph в «Слёрме». Тема была добавлена уже после релиза видеокурса, в январе 2021. Также в январе в рамках развития курса появились новые практические задания:

• Установка при помощи cephadm.
• Установка при помощи Ansible.
• Использование Ceph: объектное хранилище.
• Пулы и классы хранения Ceph.

Фото ETA+, Unsplash.com

Первые шаги в сторону observability — собираем метрики с Prometheus

Представьте себе человека, который бьется над решением загадки, а вокруг собралось с десяток советчиков, которые помогают ему «найти убийцу». Знакомая ситуация? В таких случаях возникает больше вопросов, чем ответов, и если отвечать на все эти вопросы, ни на что другое времени уже не останется.

Сложно найти то, чего не знаешь и не понимаешь. Вот тут-то на помощь и приходит observability (наблюдаемость). Она помогает понять, что сломалось или плохо работает, и даже позволяет найти причину, чтобы вы могли постоянно вносить улучшения.

Что такое observability

Под observability мы подразумеваем показатель того, насколько эффективно можно определить внутреннее состояние системы по ее выходным данным (телеметрии). Ничего нового в этом нет — мы пытаемся разобраться в работе приложений по логам с начала времен, но сейчас все осложняется облаками, контейнерами, микросервисами, многоязычными средами и т. д.

Три кита observability

Observability основана на трех главных компонентах. Это данные телеметрии, которые можно агрегировать и анализировать, чтобы понять состояние системы:

1. Метрики.
2. Трассировки.
3. Логи.

В этой серии статей мы рассмотрим все три компонента с примерами. Начнем с метрик и опенсорс-проекта Prometheus.

Выбор CEPH. Часть 1

У нас было пять стоек, десять оптических свичей, настроенный BGP, пару десятков SSD и куча SAS дисков всех цветов и размеров, а ещё proxmox и желание засунуть всю статику в собственное S3 хранилище. Не то чтобы это всё было нужно для виртуализации, но раз начал использовать opensource — то иди в своём увлечении до конца. Единственное, что меня беспокоило — это BGP. В мире нет никого более беспомощного, безответственного и безнравственного, чем внутренняя маршртутизация по BGP. И я знал, что довольно скоро мы в это окунёмся.

Задача стояла банальная — имелся CEPH, работал не очень хорошо. Надо было сделать "хорошо".
Доставшийся мне кластер был разнородным, настроенным на скорую руку и практически не тюнингованным. Он состоял из двух групп разных нод, с одной общей сеткой выполняющей роль как cluster так и public network. Ноды были набиты четырьмя типами дисков — два типа SSD, собранными в два отдельных placement rule и два типа HDD разного размера, собранными в третью группу. Проблема с разными размерами была решена разными весами OSD.

Саму настройку разделили на две части — тюнинг операционной системы и тюнинг самого CEPH и его настроек.

• миграция данных из старого Ceph в новый с частичным использованием предыдущих серверов в новом кластере;
• решение проблемы распределения дискового пространства в Ceph.