Короткий совет по Linux 💡

Если вы хотите очистить пустые каталоги, команда find может упростить эту работу:
$ find . -type d -empty -exec rmdir -v {} +
Параметр -type d выполняет поиск каталогов, -empty выбирает пустые каталоги, а -exec rmdir {} выполняет команду rmdir для их удаления.

Команда rmdir гарантирует, что каталог пуст перед его удалением.

В качестве альтернативы, вы также можете использовать эту команду для выполнения той же задачи:
$ find . -type d -empty -delete

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Kubelab: Виртуальная лаборатория Kubernetes

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

https://github.com/natrontech/kubelab

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Как создать отказоустойчивые системы

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Dragonfly Operator — это Kubernetes-оператор, используемый для развертывания и управления экземплярами Dragonfly внутри ваших Kubernetes-кластеров. Основные возможности включают:

- Автоматическое переключение при сбоях (failover)
- Масштабирование по горизонтали и вертикали с пользовательской стратегией развёртывания
- Аутентификация и поддержка TLS для сервера
- Автоматические снимки (snapshots) в PVC и S3
- Мониторинг с помощью Prometheus и Grafana
- Широкие возможности конфигурации

https://github.com/dragonflydb/dragonfly-operator

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Pghero

Панель управления производительностью для Postgres

https://github.com/ankane/pghero

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Как можно контролировать использование ресурсов в POD?

В Kubernetes контроль использования ресурсов в Pod осуществляется через механизмы запросов (requests) и лимитов (limits), которые задаются для контейнеров в манифестах Pod'ов. Это позволяет управлять доступом к вычислительным ресурсам (CPU и память) и предотвращать чрезмерное потребление, которое может повлиять на работу кластера.

Основные способы контроля:

1. Запросы (Requests):
- Указывают минимальный объем ресурсов, который необходим контейнеру для работы.
- Kubernetes использует эту информацию для планирования Pod'ов на узлах (nodes), гарантируя, что на узле достаточно ресурсов для Pod'а.

Пример:

   resources:
     requests:
       memory: "256Mi"
       cpu: "500m"
   

2. Лимиты (Limits):
- Устанавливают максимальный объем ресурсов, который контейнер может использовать.
- Если контейнер превышает лимит памяти, он будет завершен. Если превышен лимит CPU, его использование будет ограничено (throttled).

Пример:

   resources:
     limits:
       memory: "512Mi"
       cpu: "1"
   

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

     resources:
       requests:
         memory: "256Mi"
         cpu: "500m"
       limits:
         memory: "512Mi"
         cpu: "1"
     

4. Использование ResourceQuota:
- Устанавливает ограничения на объем ресурсов, которые могут использоваться на уровне namespace.
- Пример:

     apiVersion: v1
     kind: ResourceQuota
     metadata:
       name: compute-resources
       namespace: example-namespace
     spec:
       hard:
         requests.cpu: "4"
         requests.memory: "8Gi"
         limits.cpu: "10"
         limits.memory: "16Gi"
     

5. LimitRange:
- Определяет минимальные/максимальные запросы и лимиты для Pod'ов и контейнеров в namespace.
- Пример:

     apiVersion: v1
     kind: LimitRange
     metadata:
       name: mem-cpu-limits
       namespace: example-namespace
     spec:
       limits:
       - default:
           cpu: "1"
           memory: "512Mi"
         defaultRequest:
           cpu: "500m"
           memory: "256Mi"
         type: Container
     

Мониторинг использования ресурсов:
- Используйте встроенные метрики Kubernetes через kubectl top:

  kubectl top pod --namespace=<namespace>
  kubectl top node
  

- Интеграция с инструментами наблюдаемости, такими как Prometheus, Grafana или Kubernetes Dashboard, для анализа метрик ресурсов в реальном времени.


#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

20 000 бонусов на тестирование сервисов Cloud․ru ☁️

От подбора нужного сервиса, выделения гранта или тестового периода до помощи в миграции в облако.

До 31 декабря для юридических лиц облачный провайдер Cloud.ru предлагает специальное предложение — 20 000 бонусов на использование своих сервисов.

С какими задачами помогут:

▶️Инфраструктура в облаке: вычислительные мощности для размещения, тестирования и прототипирования проектов.

▶️Хранилище данных: универсальное масштабируемое хранилище для создания резервных копий данных, размещения сайтов и приложений с высокой скоростью доступа и надежности.

▶️Облако для 1С: высокопроизводительное и защищенное облако для бесперебойной работы всех систем 1С.

▶️Бессерверные вычисления: контейнерные приложения в облаке без необходимости управлять собственной инфраструктурой.

▶️Разработка под Data Science: приложения на основе машинного обучения.

▶️Сайт в облаке: развертывание сайта в облаке, чтобы справиться с любой нагрузкой и трафиком.

👉Получить бонусы 👈

Для чего используется Kubectl?

kubectl — это командная утилита для взаимодействия с Kubernetes-кластером. Она используется для выполнения различных операций по управлению кластерами и развертыванию приложений. С kubectl можно выполнять следующие задачи:

1. Управление ресурсами: создавать, обновлять и удалять ресурсы в кластере (например, Pod, Deployment, Service).
2. Мониторинг и отладка: просматривать информацию о текущем состоянии ресурсов и кластера, диагностировать проблемы.
3. Запуск команд в кластере: запускать команды внутри контейнеров, например, для проверки их состояния или выполнения отладочных задач.
4. Обновление приложений: управлять версиями и состоянием развернутых приложений, поддерживать их обновление и масштабирование.
5. Настройка кластера: управлять конфигурациями, такими как сетевые настройки и политика безопасности.

Пример команды kubectl для получения списка всех подов в текущем пространстве имён:

kubectl get pods

Эта команда возвращает информацию обо всех запущенных подах, их состоянии и доступных IP-адресах.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Чем отличается StatefulSet от Deployment?

Deployment — ресурс Kubernetes предназнваенный для развертывания приложения без сохранения состояния. При использовании PVC все реплики будут использовать один и тот же том, и ни один из них не будет иметь собственного состояния.

StatefulSet — поддерживают состояние приложений за пределами жизненного цикла отдельных модулей pod, например для хранилища. Используется для приложений с отслеживанием состояния, каждая реплика модуля будет иметь собственное состояние и будет использовать свой собственный том.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Unused

CLI-инструмент, экспортер для Prometheus и модуль на Go для перечисления неиспользуемых дисков во всех облачных провайдерах

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

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

https://github.com/grafana/unused

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Kubernetes для баз данных? CloudNativePG делает PostgreSQL по-настоящему Cloud-Native

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

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

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

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Что такое docker и какие инструменты linux лежат в основе? Для чего он используется?

Docker базируется на технологиях:

🔸 namespaces — обеспечивает изоляцию (например, можно айдишники процессов разместить в разных контейнерах)
🔸 cgroups — позволяет управлять группой процессов, и управлять их ресурсами
🔸 capabilities — позволяет дать некоторые рут привелегии процессам или исполняемым файлам. Например, изменить UID процесса на 0, или дать возможность монтировать файловые системы.
🔸 overlay namespaces — (overlayFS, overlay2-драйвер) - файловая система, которая умеет работать "слоями". Не сохранять каждый раз новые файлы, а наслаивать один слой на другой, тем самым экономя место на диске и время создания контейнера.

А вот докер — это уже штука, которая всеми этими технологиями рулит, удобным для нас образом.

Компоненты докера:

🔻 Docker Daemon — тот самый Container Engine; запускает контейнеры.
🔻 Docker CLI — утилита по управлению Docker.
🔻 Dockerfile — инструкция по тому, как собирать образ.
🔻 Image — образ, из которого раскатывается контейнер.
🔻 Container
🔻 Docker registry — хранилище образов.

На Docker_host работает Docker daemon и запускает контейнеры.
Client — передаёт команды: собери образ, скачай образ, запусти контейнер. Docker daemon ходит в registry и выполняет их. Docker-клиент может обращаться и локально (к юникс-сокету), и по TCP с удалённого хоста.

Docker daemon (демон) — это серверная часть, работающая на хост-машине: скачивает образы и запускает из них контейнеры, создаёт сеть между контейнерами, собирает логи. Когда мы говорим «создай образ», этим тоже занимается демон.

Docker CLI — клиентская часть Docker, консольная утилита для работы с демоном. Может работать не только локально, но и по сети.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Инженеры перебрали... Linux-кейсов 🤩

У K2 Cloud и K2Тех вышла запись митапа по Linux —
pебята разобрали реальные инженерные кейсы из практики про поломанный SSH, обновление ядер, поломку сети в ВМ и балансировщики с одинаковыми конфигами, но разными результатами.

А еще в конце дали специальный кейс для зрителей — можно решить его и забрать приз до 5 июня.

Смотреть здесь

В чем разница между Latency, Throughput и Bandwidth? Разбираемся раз и навсегда 🌐

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

📌 1. Latency (Задержка)

• Что это: Время, за которое один пакет данных долетает от отправителя к получателю.
• Аналогия: Скорость одной машины. Если дорога пустая и ты жмешь на газ, машина доедет быстро. В сетях это измеряется в миллисекундах (ms). Чем меньше задержка, тем быстрее открываются сайты и тем меньше «пингует» в онлайн-играх.
• На инфографике: 40 ms.

📌 2. Bandwidth (Ширина канала)

• Что это: Максимальная теоретическая вместимость сети. То, за что ты платишь провайдеру (например, «интернет до 100 Мбит/с»).
• Аналогия: Количество полос на шоссе. Чем больше полос, тем больше машин в теории могут ехать одновременно. Но это не значит, что они будут ехать быстро, если впереди пробка.
• На инфографике: 100 Mbps.

📌 3. Throughput (Реальная пропускная способность)

• Что это: Количество данных, которое фактически доставляется за единицу времени.
• Аналогия: Реальное количество машин, которое успевает пересечь мост за минуту с учетом пробок, аварий и сужений дороги. Из-за потерь пакетов и сетевых протоколов throughput почти всегда меньше, чем bandwidth.
• На инфографике: 62 Mbps.


🤖 Короткий итог для собеседований:

• Bandwidth - сколько полос на дороге.
• Throughput - сколько машин реально едет по дороге прямо сейчас.
• Latency - сколько времени занимает поездка у одной машины.

Сохраняй картинку, чтобы не потерять! 💾

#сети #devops #architecture #backend

📲 Мы в MAX

👉 @i_odmin

Для чего нужна команда git commit --amend?

Команда git commit --amend используется для изменения последнего коммита в локальном репозитории. Она позволяет исправить сообщение коммита, добавить в него изменения, которые не были учтены, или удалить файлы, которые не должны были быть в коммите.

Основные случаи использования:

1. Изменение сообщения коммита: если было допущено опечатку или необходимо уточнить содержание сообщения коммита.

   git commit --amend -m "Новое сообщение коммита"
   

2. Добавление изменений в последний коммит: если были забыты изменения, которые нужно включить в последний коммит, можно их добавить, выполнить git add для этих файлов и затем git commit --amend, чтобы объединить их с предыдущим коммитом.

3. Удаление ненужных файлов: если случайно добавлен лишний файл, можно удалить его с помощью git rm, затем выполнить git commit --amend, чтобы пересобрать коммит без этого файла.

После выполнения git commit --amend создается новый коммит с измененной историей, что важно помнить, если работа ведется в команде.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

🔈 Новый VPS/VDS-сервис от упоротых инфраструктурщиков

Давно дружим с CORTEL, это ребята про enterprise решения для крупняка. Сейчас они запустили отдельный бренд для аренды VPS/VDS — Serverum.

Это сервис, где можно выбрать VPS, оплатить и сразу начать пользоваться. Подойдёт для dev/stage-сред, тестовых стендов, ботов, pet-проектов, небольших сервисов и других задач, где нужен сервер без лишней возни.

Внутри:
— собственная проприетарная платформа
— отечественные решения
— защищённая инфраструктура
— низкие цены
— живая поддержка от инженерной команды

Сейчас ребята запускают первых пользователей и собирают честную обратную связь от тех, кто реально работает с инфраструктурой.
Можно зайти, потыкать, взять VPS под задачу и написать фидбек.

👉 Serverum.ru

💡 Сегодня немного про боль Kubernetes-кластеров

Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.

👉 У каждого пода должны быть requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.

👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.

👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.

В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps