Давайте поговорим о записи логов событий, происходящих в кластере Kubernetes. Эти логи можно использовать для устранения неполадок на уровне кластера, чтобы восстановить, когда и как конфигурация кластера была изменена, что привело к нежелательному или нарушенному поведению во время выполнения. Записи логов также можно использовать для отслеживания атаки, которая может происходить прямо сейчас, в качестве средства для принятия контрмер.
В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.
В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктам, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.
Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.
Привет, с вами команда разработки dBrain.cloud! Хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.
Узел K8s — это физическая или виртуальная машина, участвующая в кластере K8s, которая может использоваться для запуска подов. Когда узел выключается, выходит из строя или процесс kubelet сталкивается с проблемой, узел переходит в состояние NotReady. Он не может использоваться для запуска подов. В этом случае все запускаемые на узле поды становятся недоступными.
Обычными причинами перехода узла K8s в состояние NotReady являются:
Эффективность – как часто в своей жизни мы слышим это слово. Эффективность бывает самая разная и обычно под ней подразумевают улучшение тех или иных бизнес-процессов.
Мы же поговорим сегодня об эффективности чисто технологической – как бы нам так сделать, чтобы сервера были загружены поплотнее, и управлять ими было удобней, а результат получился надежным и безопасным.
Я - Антон Будкевич, глава разработки IT-решений НСПК Мир Plat.Form, и сегодня с мы Олегом Чирухиным @olegchir - деврелом в Axiom JDK и топ-1 контрибьютором в блог Java на Хабре - поговорим о контейнеризации.
Кубернетес использует примитивы Linux в качестве строительных блоков для своей собственной сетевой модели. Сеть в Кубернетес представляет из себя сложную для понимания и для администрирования систему. Однако, большая часть из привычных для системных администраторов и сетевых инженеров, инструментов доступна и для Кубернетес. Навыки, приобретенные, за годы работы с привычным технологическим стеком можно применить для решения проблем в системе Кубернетес.
Аннотации в Kubernetes (K8s) — это метаданные с дополнительной информацией, связанной с ресурсом или объектом. В этой статье разберемся, что они из себя представляют, для чего служат и чем отличаются от меток.
Продолжая серию статей про знания, полученные на работе, хочу рассказать про свои навыки DevOps, которые были на нуле, когда я пришла в компанию GlowByte.
Это история о том, на что нужно обращать внимание, изучая инструменты DevOps с нуля, и как достичь успеха в этом.
В статье расскажу свою историю накопления знаний, какие задачи помогли лучше понять DevOps и как это все помогает специалисту поддержки.
Привет! Меня зовут Михаил Черешнев, я работаю в компании Swordfish Security, где занимаюсь вопросами внедрения DevSecOps. Сегодня мы в команде много внимания уделяем направлению Software Supply Chain Security. Если заглянуть в Рунет, можно найти в нем немало статей, рассказывающих о проблемах в обеспечении безопасности цепочки поставок. Но о том, что с ними делать и какое решение применять, ничего нет. И в этой статье мы постарались восполнить этот пробел. Рассказываем все о Chainloop: верхнеуровневая архитектура, преимущества, то какие проблемы закрывает. Поехали!
AppArmor — это модуль безопасности ядра Linux, который дополняет стандартные разрешения Linux для пользователей и групп, ограничивая программы набором ресурсов. AppArmor можно настроить для любого приложения, чтобы уменьшить потенциальную поверхность атаки и обеспечить более глубокую защиту. Он настраивается с помощью профилей, настроенных так, чтобы разрешить доступ, необходимый для конкретной программы или контейнера, например возможности Linux, доступ к сети, права доступа к файлам и т. д. Каждый профиль можно запускать либо в принудительном режиме, который блокирует доступ к запрещенным ресурсам, либо в режиме жалобы - режим, который сообщает только о нарушениях.
AppArmor может помочь вам выполнить более безопасное развертывание, ограничив возможности контейнеров и/или предоставив лучший аудит с помощью системных журналов. Однако важно иметь в виду, что AppArmor не является серебряной пулей и может сделать очень мало для защиты от эксплойтов в коде вашего приложения.
Привет Хабр! Поговорим о безопасности в k8s, и начнем с безопасности подов, как базового строительного блока нашего кластера.
DevOps- и SRE-командам важно знать как можно больше о работе приложений, за которые они отвечают: как эти приложения работают в разных условиях, как их показатели меняются со временем, в какой точке можно ускорить работу, тем самым улучшив показатели производительности и доступности сервисов. Для всех этих задач важны показатели наблюдаемости (observability). Реализовать наблюдаемость можно при помощи технологии eBPF, которой уже более 10 лет.
Чтобы легко адаптировать статистику eBPF и получать из нее полезную информацию, нужен дополнительный инструмент. Одним из них и является Open Source-решение Coroot. Coroot — это observability-инструмент, который превращает данные телеметрии в полезную информацию, помогая быстро выявлять и устранять проблемы с приложениями. В статье проверим, какие у него есть возможности.
Хабр, привет!
Меня зовут Александр Кузьмин, я старший инженер в КРОК, занимаюсь облачными технологиями, микросервисами и всеми новомодными DevOps-методологиями.
В этом посте хочу поговорить про Kubernetes, а именно — про организацию доступа в кластер. Развернуть кластер несложно, а вот постоянно поддерживать его в рабочем состоянии — это задачка уровнем выше. И здесь не избежать вечного вопроса «как сделать так, чтобы Вася не сломал то, что придумал Петя». В посте рассказываю, как мы работаем с этим в КРОК: какие механизмы ограничения доступа используем, как их подбираем и какие важные моменты учитываем. Всё в деталях, как мы любим на Хабре — с подробными пошаговыми описаниями, лайфхаками из личного опыта и удобной шпаргалкой в конце.
Пост основан на моем докладе на последнем DevOops Conf, так что если видео вам заходит лучше, приглашаю по ссылке.
Как работает связь между подами в Kubernetes?
Как трафик достигает пода?
В этой статье вы узнаете, как работает низкоуровневая сеть в Kubernetes.
Привет Хабр!
Реальный кластер Kubernetes управляет сотнями или даже тысячами подов. Для каждого пода есть как минимум один контейнер, в котором запущен процесс. Каждый процесс может производить вывод журнала в стандартный поток вывода или стандартные потоки ошибок. Крайне важно записывать выходные данные журнала, чтобы точно определить основную причину ошибки приложения. Кроме того, компоненты кластера создают журналы (логи и далее будут логи) для диагностических целей.
Как видите, механизм ведения логов Kubernetes имеет решающее значение для отслеживания ошибок и мониторинга компонентов и приложений кластера. Kubernetes можно настроить для входа на уровне кластера или узла. Подходы к реализации и их потенциальные компромиссы могут отличаться друг от друга.
Не так давно мы в департаменте информационных систем (далее – ДИС) ИТМО начали выстраивать новую инфраструктуру для деплоя наших проектов. Образовательным организациям обычно с бюрократической точки зрения сложно прийти к масштабным внедрениям. Нам повезло ― мы смогли путем проб и ошибок выбрать удобные проверенные технологии и реализовать единую среду, которая задала формат взаимодействия между администраторами и разработчиками.
В общей сложности подбор инструментов и их внедрение заняли полтора года. Конечно, иногда был непросто: наступали на “грабли” и возвращались, чтобы выбрать более удачный путь. И это несмотря на то, что в общих чертах было изначально понятно, куда двигаться.
Проанализировав свой опыт, мы решили поделиться основными предпосылками и выводами. Хочется надеяться, что это облегчит внедрение тем, кто пойдет аналогичной дорогой.
В рамках университетского блога мы вводим новую рубрику по DevOps, в которой Lead DevOps инженер ДИС Михаил Рыбкин расскажет, как вместе с командой внедрил платформу деплоя для разработчиков.
