Мы спросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Наша задача была спрогнозировать будущее на основе тенденций в настоящем, а не просто «заглянуть в хрустальный шар» и пофантазировать. В результате родилась эта статья. Присоединяйтесь к нам в комментариях — давайте вместе подумаем, как будут выглядеть важные в нашей работе инструменты через 5–10 лет.
Известно, что с контейнерами бывает огромное количество разнообразных проблем, в том числе, связанных с информационной безопасностью. Как их избежать и не дать взломщику лазеек в ваш сервис — разбираемся в этой статье.
Привет, Хабр! Это Алексей Федулаев и Антон Жаболенко из Wildberries. Мы работаем в сфере информационной безопасности (ИБ) уже больше 10 лет.
Привет всем! В предыдущей статье мы обзорно рассмотрели основные компоненты CI/CD Kubernetes платформы Gitorion. В данной статье подробнее остановимся на реализации хостинга кода, системы управления версиями и непрерывной интеграции CI.
Как-то в конторе появилась мысль, что надо бы продумать как нам распараллелить работу над одни микриком, так чтобы команды не пересекались друг с другом. Есть некоторые API над которыми работают несколько команд. Каждая работает над своей фичей локально и пишет тесты, а вот при деплое на стэнд получается столпотворение потому, что нужно изменения слить в одну ветку аля develop и её закинуть на тест. При этом могут быть конфликты при мерже кода или измениться проперти, которые не совместимы между разными ветка.
Мобильный банк сейчас обслуживает 450+ микриков. Над которыми работают более 90 команд. Так как у нас в проекте нет code ownership, то каждая команда вносит изменения в нужные им микрики. Чтобы избежать различного рода сложностей, которые приводят к увеличению времени time to market, нужно было развести разработку отдельных команд так, чтобы они не влияли друг на друга и могли работать параллельно.
Павел Агалецкий, ведущий разработчик юнита Platform as a Service Авито, написал, как поднять кластер Kubernetes на локальном компьютере Mac с помощью подручных инструментов, а потом задеплоить в него простейшие приложения.
Первым шагом dBrain.cloud на пути к построению кластеров большого объема стало разделение etcd. Далее мы взялись за controller-manager.
Некоторое время назад у нас возникла задача организовать возможность создания managed баз данных. Сложность данной задачи в том, что нам надо развертывать и управлять тысячами баз данных PostgreSQL, которые обеспечивают репликацию, бэкапы, мониторинг и другие полезные пользователям функции. При этом в ядре нашей системы лежит Kubernetes, в котором запускаются приложения пользователей. И по ряду факторов нам требовалось запускать базы данных внутри кластера.
Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.
Продолжаем серию статей про особенности, применение, плюсы и минусы языков, которые используются в «Криптоните». В этой статье наш инженер департамента инфраструктуры Алексей Косов расскажет про Golang.
Ранее наши разработчики делали обзоры Rust, Scala, JavaScript и Spark.
Привет всем! На одном из проектов нам потребовалось внедрить непрерывную интеграцию и доставку CI/CD. Поиск готового решения показал, что все наши потребности может закрыть GitLab CI. Однако GitLab - платный продукт и на момент принятия решения возникли некоторые трудности с его коммерческим использованием. Поиски альтернативы не увенчались успехом, и было принято решение создать CI/CD своими силами из имеющихся OpenSource-инструментов.
Недавно мы закончили работу и получили завершенную платформу, которую можно использовать, как готовый инструмент с выстроенной непрерывной интеграцией и доставкой CI/CD и/или для перевода инфраструктуры в микросервисную архитектуру, согласно концепции инфраструктура как код IaC.
В данной серии статей мы хотим рассказать о нашем пути, этапах работы и компонентах платформы.
Вот мы и подобрались к самому интересному: запуску Kubernetes в Kubernetes. В этой статье мы поговорим о таких технологиях, как Kamaji и Cluster API, а также о том, как интегрировать их с KubeVirt.
В прошлых статьях мы уже рассказывали, как мы готовим Kubernetes на bare metal, и о том, как превратить Kubernetes в средство запуска виртуальных машин. Эта статья завершает серию, объясняя, как, используя всё вышеперечисленное, можно построить полноценный managed Kubernetes service и запускать виртуальные Kubernetes-кластеры по клику.
И начнём мы, пожалуй с Cluster API.
Ранее мы делали обзор инструментов для оценки безопасности кластера Kubernetes. Но что, если нам нужно обучить инженеров основам безопасности Kubernetes на реальных примерах и автоматизировать этот процесс? Недавно компания ControlPlane, специализирующаяся на Cloud Native-решениях, помогла решить этот вопрос. Она выложила в открытый доступ Simulator — инструмент для обучения инженеров поиску уязвимостей в Kubernetes. Мы во «Фланте» решили протестировать этот симулятор и понять, насколько он перспективен и полезен.
В этой статье я расскажу, зачем нужен этот инструмент, как его настроить и установить, а также разберу его возможности. Для этого я решу один из сценариев, который предлагает Simulator. В конце обзора я оставлю своё мнение об инструменте и расскажу о ближайших планах его авторов.
Привет, Хабр!
Хочется рассказать о нашем опыте внедрения CI/CD в компанию. О том, как в целом работать с ним и как это работает у нас.
Статья нацелена на новичков конкретно в этой сфере и хотят чуть детальнее стандартной документации настроить деплой, может внедрить у себя, чуть адаптировать. Примеры достаточно гибкие и подходят для большинства задач в начинающих IT компаниях
Приятного прочтения, всем peace!
Kubernetes в большинстве случаев является стандартом де-факто, когда мы выбираем оркестратор контейнеров. Развернув Kubernetes в облаке, мы получаем возможность масштабировать рабочие ресурсы по мере необходимости при помощи Kubernetes cluster autoscaler механизма. Karpenter был представлен re:Invent 2021 как продукт с открытым исходным кодом, который подходит к процессу масштабирования k8s кластеров по-другому в сравнении с ClusterAutoscaler.
Продолжаем серию постов про то как построить своё собственное облако в экосистеме Kubernetes. В прошлой статье мы разобрали как можно подготовить базовый дистрибутив Kubernetes на базе Talos Linux и Flux CD. Теперь нам предстоит обсудить возможность запуска виртуальных машин и всего что для этого необходимо, а это в первую очередь хранилище и сеть.
Мы поговорим про такие технологии как KubeVirt, LINSTOR и Kube-OVN
Для начала мне стоит рассказать зачем вообще нужны виртуальные машины, почему бы нам не ограничиться только-лишь контейнерами?
Всё дело в том, что контейнеры в ядре Linux не дают должного уровня изоляции. Несмотря на то, что с каждым годом ситуация становится всё лучше, тем не менее довольно часто мы сталкиваемся с уязвимостями, позволяющими покинуть песочницу контейнера и повысить свои привилегии в системе.
Как понять на собеседовании, что человек действительно умеет что-то делать руками, а не просто красиво говорит?
В статье расскажу, как мы сделали аналог онлайн-код-интервью для DevOps-инженеров, чтобы точно увидеть уровень навыков и заинтересовать инженеров интересными задачами.
В начале года на YouTube-канале DevOps Toolkit вышло видео с разбором WebAssembly. Автором ролика является Виктор Фарчич (Viktor Farcic) — developer advocate в Upbound, член CNCF Ambassadors, Google Developer Experts, CDF Ambassadors и GitHub Stars.
Мы перевели видео про WebAssembly в текстовый формат и адаптировали для лучшего понимания. В нём автор разбирает, что такое WebAssembly, стоит ли использовать его в браузерах и кластерах Kubernetes или вообще заменить Kubernetes и прочее.
