DevOps

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

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

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

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

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

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

#devops #девопс

📲 Мы в MAX

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

🔍 EKS взломали. Где искать следы?

Первый порыв - удалить подозрительный pod. Но вместе с ним можно потерять состояние процессов и изменения файловой системы, которые помогут разобраться в атаке.

Synacktiv выпустили практический разбор расследований в Amazon EKS. Главная мысль: готовиться к расследованию нужно до инцидента.

Что пригодится DevOps-инженеру:

🔹 Kubernetes audit logs - кто создавал pod’ы, менял RBAC и с каких IP приходил. Экспорт логов control plane в CloudWatch по умолчанию выключен.

🔹 Container Insights - централизованные логи контейнеров, kubelet и ОС рабочих узлов.

🔹 CloudTrail - проверка, не использовал ли атакующий украденную IAM-роль за пределами кластера.

🔹 GuardDuty - отправная точка расследования. Алерт нужно проверять: привилегированные контейнеры бывают и у штатных инфраструктурных компонентов.

⚠️ Сетевая изоляция не обезвредит уже украденные credentials. Их отзыв требует отдельного внимания.

Практический вывод: проверьте сбор логов и сроки хранения сейчас. После перезапуска pod’а включать наблюдаемость может быть поздно.

Разбор Synacktiv с примерами запросов CloudWatch Logs Insights https://www.synacktiv.com/en/publications/aws-eks-forensics-data-sources-and-investigation-tooling

#DevOps #Kubernetes #AWS #EKS #DevSecOps #Security

📲 Мы в MAX

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

В чем разница между 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 #devops #девопс

📲 Мы в MAX

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