Как мы ищем деградации на нодах в кластерах Kubernetes

Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито. В этой статье я расскажу про инструмент, который мы используем для обнаружения деградаций на нодах в кластерах Kubernetes, а также покажу дашборд, где мы наблюдаем за состоянием всех наших нод.

Причины деградаций на нодах
Инфраструктура Авито — это тысячи bare-metal серверов, большая часть из которых объединена в десятки Kubernetes-кластеров. Понятно, что в таких масштабах отказ отдельных кубонод — событие регулярное. Причины могут быть разные: от поломки планки памяти до возникновения проблем с container runtime.

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

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

https://habr.com/ru/companies/avito/articles/847466/

👉 @devops_star

Введение в Docker и Kubernetes: основы контейнерных технологий. Часть 1

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

https://habr.com/ru/companies/sibur_official/articles/826964/

👉 @devops_star

Основы Docker: контейнеризация, Dockerfile и Docker Compose. Часть 2

Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному.

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

https://habr.com/ru/companies/sibur_official/articles/846350/

👉 @devops_star

DevToys

DevToys помогает в ежедневных задачах разработки, предлагая набор небольших инструментов, предназначенных для быстрого выполнения конкретных задач. Нет необходимости использовать множество ненадежных сайтов для простого декодирования текста или сжатия изображения. С помощью функции Smart Detection приложение интуитивно выбирает лучший инструмент для данных, находящихся в буфере обмена.

DevToys 2.0 включает 30 инструментов по умолчанию:

Конвертеры: JSON <> YAML, Дата, Числовые системы и т.д.
Кодировщики/Декодировщики: HTML, URL, Base64, GZip, JWT, QR-код и т.д.
Форматтеры: JSON, SQL, XML и т.д.
Генераторы: Хэш и Контрольная сумма, Lorem Ipsum, Пароли и т.д.
Инструменты для графики: Симулятор цветовой слепоты, Сжатие PNG/JPEG и т.д.
Тестеры: JSONPath, RegEx, XML и т.д.
Текстовые утилиты: Предварительный просмотр Markdown, Сравнение текста, Анализ и утилиты...

https://github.com/DevToys-app/DevToys

👉 @devops_star

Mount — ещё один способ уменьшения размера Docker-образа

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby. Пришли со словами: предыдущий разработчик не передал исходный код, но систему нужно развивать. Я уверен, что по условиям контракта передавали исходный код, но заказчики всегда относятся попустительски: им присылают архив на почту, а они потом стирают старое барахло, чтобы ящик почистить.

Так вот, зайдя на продакшен-сервер, я нашел развернутую платформу, да ещё и с .git папочкой. Ура, у меня были исходники с историей (она потом мне ни разу не понадобилась). Загрузил в нашу репу исходники, поизучал. В ходе контракта нужно было изменить деплой с rsync на контейнеризацию и перетащить все на Alt Linux (или Astra, уже не помню).

Обновили Ruby-пакеты (gems), обновили под них код и написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.

https://habr.com/ru/articles/851384/

👉 @devops_star

Какие инструкции есть у Dockerfile?


FROM Задаёт базовый (родительский) образ.

LABEL. Описывает метаданные. Например — сведения о том, кто создал и поддерживает образ.

ENV Устанавливает постоянные переменные среды.

RUN. Выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов.

COPY. Копирует в контейнер файлы и директории.

ADD. Копирует файлы и директории в контейнер, может распаковывать локальные .tar-файлы.

CMD Описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD.

WORKDIR. Задаёт рабочую директорию для следующей инструкции.

ARG Задаёт переменные для передачи Docker во время сборки образа.

ENTRYPOINT Предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются.

EXPOSE Указывает на необходимость открыть порт.

VOLUME Создаёт точку монтирования для работы с постоянным хранилищем.

👉 @devops_star

ContainerSSH

SSH-сервер, запускающий контейнеры в Kubernetes и Docker

https://github.com/ContainerSSH/ContainerSSH

👉 @devops_star

Чем отличается CMD от ENTRYPOINT в Dockerfile?

Инструкции CMD и ENTRYPOINT выполняются в момент запуска контейнера, тольо инструкция CMD позволяет переопределить передаваемые команде аргументы.

Пример 1. CMD: Опишем сборку образа в Dockerfile.
FROM alpine
CMD ["ping", "8.8.8.8"]


В инструкцию CMD передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер.
$ docker run test
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=32.976 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=31.998 ms
64 bytes from 8.8.8.8: seq=2 ttl=43 time=31.843 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 31.708/33.316/36.823 ms


Теперь передадим 2 новых аргумента для запуска контейнера.
$ docker run test traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
1 172.17.0.1 (172.17.0.1) 0.017 ms 0.016 ms 0.009 ms
2 192.168.168.1 (192.168.168.1) 0.996 ms 1.553 ms 2.069 ms
3 * * *
4 lag-2-435.bgw01.samara.ertelecom.ru (85.113.62.125) 1.454 ms 1.427 ms 1.984 ms
5 172.68.8.3 (172.68.8.3) 19.685 ms 15.722 ms 15.565 ms
6 172.68.8.2 (172.68.8.2) 15.846 ms 22.696 ms 35.093 ms
7 one.one.one.one (1.1.1.1) 17.439 ms 17.670 ms 24.202 ms

ping заменен на traceroute, IP адрес заменен на 1.1.1.1.


Пример 2. ENTRYPOINT: Опишем сборку образа в Dockerfile.
FROM alpine
ENTRYPOINT ["ping", "8.8.8.8"]


В инструкцию ENTRYPOINT передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер.
$ docker run test2
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=36.189 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=44.120 ms
64 bytes from 8.8.8.8: seq=2 ttl=43 time=44.584 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 36.189/41.631/44.584 ms


Теперь передадим изменим один из аргументов для запуска контейнера.

$ docker run test2 ping 1.1.1.1
BusyBox v1.31.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

-4,-6 Force IP or IPv6 name resolution
-c CNT Send only CNT pings
-s SIZE Send SIZE data bytes in packets (default 56)
-i SECS Interval
-A Ping as soon as reply is recevied
-t TTL Set TTL
-I IFACE/IP Source interface or IP address
-W SEC Seconds to wait for the first response (default 10)
(after all -c CNT packets are sent)
-w SEC Seconds until ping exits (default:infinite)
(can exit earlier with -c CNT)
-q Quiet, only display output at start
and when finished
-p HEXBYTE Pattern to use for payload


Как видим, аргумент передать контейнеру нельзя.

👉 @devops_star

Чем отличается COPY от ADD в Dockerfile?

Инструкция COPY копируют файлы и директории с хостовой машины внутрь контейнера, инструкция ADD копирует файлы и директории с хостовой машины внутрь контейнера и может распаковывать .tar архивы.

👉 @devops_star

🚀 Подборка полезных IT каналов в Max


Системное администрирование, DevOps 📌

https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.

1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С

Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика

Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика

Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика

GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных

Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков

Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов

Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻

Шутки программистов 📌
https://max.ru/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free

Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров

Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике

Вакансии 📌
https://max.ru/progjob Вакансии в IT

Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных


Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы

KubeSkoop

KubeSkoop — это инструмент диагностики сетей Kubernetes для различных CNI плагинов и провайдеров IAAS. KubeSkoop автоматически строит граф сетевого трафика Pod в кластере Kubernetes, осуществляет мониторинг и анализ критических путей ядра с помощью eBPF, чтобы решать большинство сетевых проблем кластера Kubernetes.

https://github.com/alibaba/kubeskoop

👉 @devops_star

Molecule

Проект Molecule предназначен для помощи в разработке и тестировании ролей Ansible.

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

Molecule поощряет подход, который приводит к последовательному развитию ролей, которые хорошо написаны, легко понимаются и поддерживаются.

https://github.com/ansible/molecule

👉 @devops_star

Как определить состояние контейнера Docker?


1. Проверить статус всех контейнеров:

   docker ps -a
   

Эта команда выводит список всех контейнеров, их идентификаторы, имена, статус и время работы. В колонке "STATUS" можно увидеть текущее состояние контейнера, например:
- Up X hours — контейнер работает.
- Exited (code) — контейнер завершил работу с определённым кодом выхода.

2. Проверить состояние конкретного контейнера:
Используйте команду docker inspect, чтобы получить подробную информацию о состоянии контейнера:

   docker inspect <container_id>
   

Эта команда выводит всю информацию о контейнере, включая статус, ошибки, время работы и другие параметры. Для удобства можно использовать фильтрацию JSON-вывода, например:

   docker inspect -f '{{.State.Status}}' <container_id>
   

Возможные статусы:
- running — контейнер запущен.
- exited — контейнер завершил работу.
- paused — контейнер приостановлен.
- restarting — контейнер перезапускается.

3. Проверить логи контейнера:
Чтобы увидеть последние действия контейнера, можно просмотреть его логи:

   docker logs <container_id>
   

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

#devops #девопс

👉 @devops_star

Топ 4 лучших типа сервисов Kubernetes в одной диаграмме.

🔹 ClusterIP
ClusterIP - это стандартный и наиболее распространенный тип службы. Kubernetes назначает сервису ClusterIP внутренний IP-адрес кластера. Это делает службу доступной только в пределах кластера.

🔹 NodePort
Это позволяет вывести сервис за пределы кластера, добавив общекластерный порт поверх ClusterIP. Мы можем запросить сервис по NodeIP:NodePort.

🔹 LoadBalancer
Этот способ раскрывает сервис извне, используя балансировщик нагрузки облачного провайдера.

🔹 ExternalName
Сопоставляет службу с доменным именем. Обычно это используется для создания службы в Kubernetes для представления внешней базы данных.

#devops #девопс

👉 @devops_star

Технологический стек Netflix - CI/CD Pipeline


Эта статья основана на материалах многих инженерных блогов Netflix и проектов с открытым исходным кодом.

Планирование: Netflix Engineering использует JIRA для планирования и Confluence для документирования.

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

Сборка: Для сборки в основном используется Gradle, а для поддержки различных вариантов использования создаются плагины Gradle.

Упаковка: Пакет и зависимости упаковываются в машинный образ Amazon (AMI) для выпуска.

Тестирование: Тестирование подчеркивает ориентацию продакшен-культуры на создание хаос-инструментов.

Развертывание: Для развертывания Netflix использует самостоятельно созданный Spinnaker.

Мониторинг: Метрики мониторинга централизованы в Atlas, а для выявления аномалий используется Kayenta.

Отчет об инцидентах: Инциденты рассылаются в соответствии с приоритетом, а для их обработки используется PagerDuty.

#devops #девопс

👉 @devops_star

Kargo

Это платформа следующего поколения для организации непрерывной доставки и оркестрации жизненного цикла приложений для Kubernetes. Она основывается на принципах GitOps и интегрируется с существующими технологиями, такими как Argo CD, чтобы упростить и автоматизировать поэтапный выпуск изменений на различных этапах жизненного цикла приложения.

https://github.com/akuity/kargo

#devops #девопс

👉 @devops_star