DevOps

❓ В чем разница между балансировщиком нагрузки и API-шлюзом? 1️⃣ NLB (Network Load Balancer) обычно разворачивается перед API-шлюзом и отвечает за маршрутизацию трафика на основе IP-адресов. Он не анализирует HTTP-запросы 2️⃣ ALB (Application Load Balancer) маршрутизирует запросы на основе HTTP-заголовков или URL, предоставляя более сложные правила маршрутизации. Выбор балансировщика нагрузки зависит от требований к маршрутизации. Для простых сервисов с меньшим масштабом достаточно одного балансировщика 3️⃣ API-шлюз работает на уровне приложения и решает задачи, отличные от тех, которые выполняет балансировщик нагрузки 💡 На схеме выше показаны подробности. Чаще всего они используются в комбинации для обеспечения масштабируемой и безопасной архитектуры современных веб-приложений. 🌟 Вариант A: ALB используется для распределения запросов между различными сервисами. Поскольку сервисы сами реализуют ограничение скорости, аутентификацию и т.д., такой подход более гибкий, но требует больше работы на уровне сервиса 🌟 Вариант B: API-шлюз берёт на себя задачи по аутентификации, ограничению скорости, кэшированию и другим функциям, что снижает нагрузку на уровне сервисов. Однако этот вариант менее гибкий по сравнению с использованием ALB @devopsitsec

💻Разрешения Kubernetes RBAC, о которых вы могли не знать, но должны знать! 🌟 K8s RBAC предлагает три разрешения со скрытыми полномочиями, которые могут быть использованы злонамеренно. Узнайте, как контролировать их использование! 🔗 Читать: *клик* @devopsitsec

👩‍💻Эта полезная для новичков статья описывает основы работы с сетями в Docker. Она объясняет типы сетей, такие как bridge, host, none, и overlay, которые Docker использует для подключения контейнеров 🌟 В статье также приведены примеры настройки и использования этих сетевых типов для эффективного взаимодействия между контейнерами. Рассматриваются сценарии применения каждого типа сети, а также полезные команды для управления сетями Docker 🔗 Ссылка: *клик* @devopsitsec

🖥Полезная шпаргалка по консольным командам Git В Git есть много команд, и если ты часто их забываешь, эта шпаргалка специально для тебя. В этом репозитории можно быстро ознакомиться с основными командами и концепциями, а затем одним лёгким нажатием на Ctrl+C скопировать их. Дополнительный плюс — всё написано на русском. Так что сохраняем! 🔗Шпаргалка #git#шпаргалка @devopsitsec

🖥kobs — это платформа для наблюдаемости за Kubernetes. Она помогает разработчикам и администраторам управлять своими Kubernetes-кластерами и отслеживать метрики, логи и события в рамках единого интерфейса. Платформа поддерживает интеграцию с различными инструментами для мониторинга и логирования, такими как Prometheus, Jaeger и Grafana. 🔍 Основные функции: 🌟 Мониторинг и логирование — сбор данных из различных источников для анализа и визуализации 🌟 Плагины — расширяемая архитектура с возможностью добавления плагинов для подключения сторонних сервисов 🌟 Kubernetes API — взаимодействие с Kubernetes API для управления ресурсами и сбором метрик 💡 Проект написан на Go для бэкенда и TypeScript/React для фронтенда, что позволяет легко расширять и адаптировать его под нужды компании 🔐 Лицензия: MIT ▪️Github @devopsitsec

🖥Курс по сертификации младшего администратора AWS SysOps! (2024) 🌟 Огромный курс на 68 (!) часов, который идеально подходит для младших инженеров DevOps или системных администраторов, которые хотят поддерживать и обслуживать существующую облачную инфраструктуру! 🕞 Продолжительность: 2:20:24:00 🔗 Ссылка: *клик* @devopsitsec

❓Как Kubernetes определяет готовность узла: детальный разбор 💡 В Kubernetes узлы играют ключевую роль, предоставляя ресурсы для запуска контейнеров. Чтобы гарантировать, что узел может эффективно выполнять свои функции, Kubernetes использует статус "Node Ready", который указывает, что узел готов к обработке рабочих нагрузок. Однако этот статус не статичен и может изменяться в зависимости от состояния различных компонентов узла. ❓ Как работает определение готовности узла? ❗️ Kubernetes использует компонент kubelet для управления состоянием узла. Kubelet — это агент, который работает на каждом узле кластера и отвечает за запуск и мониторинг контейнеров через контейнерный runtime (например, Docker или containerd). Этот агент регулярно отправляет обновления в контроллер управления жизненным циклом узлов (node lifecycle controller), который определяет состояние узла и решает, может ли узел принимать новые задачи. 💡 Чтобы узел считался "готовым", kubelet проверяет состояние различных критичных компонентов, включая: 🌟Контейнерный runtime. Он отвечает за выполнение контейнеров, и если он не функционирует корректно, узел будет считаться неготовым. 🌟Сетевые компоненты. Узел должен иметь рабочее сетевое соединение, чтобы взаимодействовать с другими узлами кластера и внешними ресурсами. 🌟Физическое состояние узла. Например, узел может стать неготовым, если заканчиваются ресурсы (память, процессор и т.д.). 🔍 Проверка состояния узла 💡 Kubelet периодически отправляет Heartbeat сигналы, которые содержат данные о состоянии узла. Если контроллер не получает такие сигналы в течение определённого времени, он считает, что узел "упал", и изменяет его статус на Unknown (неизвестно), чтобы предотвратить отправку задач на этот узел. Если хотя бы один из критичных компонентов перестает работать, статус узла изменяется на NotReady (не готов). В такой ситуации узел продолжает функционировать, но новые задачи на него не отправляются. 🔍 Метки состояния узла Каждый узел в Kubernetes имеет набор меток (conditions), которые описывают его текущее состояние. Например, для статуса "Node Ready" используются следующие метки: 🌟Ready: True, False или Unknown. Определяет, может ли узел принимать новые задачи. 🌟MemoryPressure: указывает, если на узле нехватка оперативной памяти. 🌟DiskPressure: показывает, есть ли проблемы с дисковым пространством. 🌟PIDPressure: информирует о том, что узел исчерпал лимиты процессов. Эти метки позволяют Kubernetes принимать автоматические решения, например, мигрировать рабочие нагрузки с узла, который испытывает проблемы ❓ Как отслеживать готовность узлов? Чтобы узнать статус узлов в кластере, можно использовать команду: kubectl get nodes 💡 Она покажет список всех узлов и их состояние. Узлы со статусом "NotReady" могут временно не принимать задачи, что может быть вызвано, например, недостатком ресурсов или проблемами с контейнерным runtime. Для более детальной информации можно использовать: kubectl describe node <node-name> 💡 Это предоставит подробное описание всех меток состояния и диагностики узла, что поможет быстрее обнаружить причину проблем @devopsitsec

🖥kubernetes-the-hard-way-aws — пошаговое руководство по настройке кластера Kubernetes вручную на AWS. Оно предназначено для тех, кто хочет глубже понять внутреннюю архитектуру Kubernetes без использования автоматизированных инструментов вроде AWS EKS или Kubernetes Operations (kops) 🌟 Процесс включает настройку сетей, машин и всех компонентов кластера, включая контрольные узлы и рабочие ноды ▪️Github @devopsitsec

🖥 Docker и микросервисы для начинающих: полный курс с практическими примерами использования Docker Compose! 🕞 Продолжительность: 1:35:01 🔗 Ссылка: *клик* @devopsitsec

🖥oci-registry — это реализация спецификации OCI Registry, предназначенная для работы в качестве pull-through кэша (зеркала) для контейнерных регистров. Поддерживает два хранилища данных: локальную файловую систему и S3. Модель потребляет меньше ресурсов по сравнению с аналогами, но пока не реализует push-запросы и аутентификацию. Используется для создания зеркал публичных или приватных реестров, но требует внешних решений для шифрования TLS 🔐 Лицензия: MIT ▪️Github @devopsitsec

🖥Ubuntu или Kubuntu: в чем разница? 🌟 Ubuntu — самый популярный дистрибутив Linux для пользователей настольных компьютеров. Он включает в себя настраиваемый рабочий стол GNOME, обеспечивающий бесперебойный пользовательский опыт 🌟 С другой стороны, Kubuntu — это одна из версий Ubuntu, включающая рабочий стол KDE Plasma . 🌟 По своей сути оба дистрибутива схожи, а главное отличие заключается в среде рабочего стола . ❓ В чем именно различия? Один из них лучше другого? Какой дистрибутив идеально подходит для вашего варианта использования? Узнаете в этой статье! 🔗 Ссылка: *клик* @devopsitsec

👣helm-chartsnap — предоставляет инструмент для Snapshot тестов (snapshot testing)Helm-чартов. 💡Snapshot тесты — это тесты, которые делают скриншот экрана (эталонный скриншот) и сравнивают с актуальным скриншотом, который делается во время прогона тестов. Helm - это менеджер пакетов для Kubernetes. Этот инструмент позволяет нам обернуть Kubernetes приложения в удобные пакеты, называемые чартами, которые можно легко развертывать, обновлять и управлять ими в любой момент времени. Чарты – это пакеты, которые могут включать в себя все для запуска приложения в Kubernetes, от deployments до services. helm-chartsnap помогает тестировать Kubernetes Helm-чарты, автоматически сравнивая текущее состояние с предыдущими снимками, что позволяет выявлять изменения и предотвращать нежелательные конфигурации 🔐 Лицензия: MIT ▪️Github @golang_google