• Наш опыт разработки CSI-драйвера в Kubernetes для Яндекс.Облака



      Рады объявить, что компания «Флант» пополняет свой вклад в Open Source-инструменты для Kubernetes, выпустив альфа-версию драйвера CSI (Container Storage Interface) для Яндекс.Облака.

      Но перед тем, как перейти к деталям реализации, ответим на вопрос, зачем это вообще нужно, когда у Яндекса уже есть услуга Managed Service for Kubernetes.
      Читать дальше →
      • +44
      • 3.1k
      • 1
    • Взгляд на технологии последнего десятилетия

      • Translation
      Прим. перев.: Эта статья, ставшая хитом на Medium, — обзор ключевых (за 2010-2019 годы) изменений в мире языков программирования и связанной с ними экосистемы технологий (особое внимание уделяется Docker и Kubernetes). Её оригинальным автором является Cindy Sridharan, которая специализируется на инструментах для разработчиков и распределённых системах — в частности, она написала книгу «Distributed Systems Observability» — и достаточно популярна в интернет-пространстве среди IT-специалистов, особенно интересующихся темой cloud native.



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

      Хочу сразу оговориться, что в этой статье я не охватываю изменения в таких областях, как наука о данных (data science), искусственный интеллект, frontend engineering и т.п., поскольку лично у меня отсутствует достаточный опыт в них.
      Читать дальше →
    • Почему у CockroachDB меняют Open Source-лицензию

      • Translation
      Прим. перев.: Гибкость и свободы, предлагаемые Open Source-лицензиями, позволили современным поставщикам крупных SaaS-решений поставить под большой вопрос успешность бизнеса у небольших компаний, стоящих за разработкой востребованных Open Source-проектов. В этой заметке от авторов CockroachDB — распределённой и отказоустойчивой РСУБД — в полной мере раскрывается суть проблемы и возможный путь её решения.



      CockroachDB задумывалась как программное обеспечение с открытым кодом. В те годы, что прошли с момента появления проекта на GitHub (впервые код был опубликован в феврале 2014 года — прим. перев.), мы придерживались относительно типичного пути развития, балансируя между философией открытого исходного кода и созданием жизнеспособного бизнеса. Основной код выходил под лицензией Apache License 2 (APL), был запущен управляемый сервис, часть дополнений для компаний выпускалась под enterprise-лицензией.

      Но наши прошлые представления о верной бизнес-модели основывались на ключевой норме OSS-мира: можно строить бизнес вокруг мощного Open Source-продукта, не предполагая, что придет более крупная технологическая компания, предлагающая тот же продукт как услугу. Эта норма больше не действует.
      Читать дальше →
    • KubeCon Europe 2019: Как мы впервые посетили главное событие по Kubernetes

        На прошлой неделе, 19—23 мая, в Барселоне проходила главная европейская конференция по Kubernetes и связанным технологиям, одно из крупнейших Open Source-событий в мире — KubeCon + CloudNativeCon Europe 2019. Мы впервые приняли участие в ней, став серебряным спонсором мероприятия и первой российской компанией на KubeCon со своим стендом. На него была отправлена делегация из шести сотрудников «Фланта», и вот что мы увидели…

        Читать дальше →
      • Эксперименты с kube-proxy и недоступностью узла в Kubernetes

        • Translation
        Прим. перев.: В этой статье, написанной техническим консультантом и сертифицированным администратором Kubernetes из Великобритании — Daniele Polencic, — наглядно показывается и рассказывается о том, какую роль играет kube-proxy в доставке пользовательских запросов до подов и что происходит, когда на одном из узлов кластера возникают проблемы.

        Код приложений, развёрнутых в Kubernetes, запускается на одном или более рабочих узлов. Узел может располагаться как на физической или виртуальной машине, так и в AWS EC2 или Google Compute Engine, а наличие множества таких площадок означает возможность эффективного запуска и масштабирования приложения. Например, если кластер состоит из трёх узлов и вы решаете отмасштабировать приложение на четыре реплики, Kubernetes равномерно распределит их среди узлов следующим образом:

        Читать дальше →
        • +30
        • 10.5k
        • 9
      • Понимая, как используется дисковое пространство в Linux

        • Translation
        Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

        Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?



        Ответы на эти вопросы кажутся очевидными. У всех нас есть инстинктивное понимание работы файловых систем и зачастую мы представляем хранение файлов на диске аналогично заполнению корзины яблоками.

        Однако в современных Linux-системах такая интуиция может вводить в заблуждение. Давайте разберёмся, почему.
        Читать дальше →
      • В защиту swap'а [в Linux]: распространенные заблуждения

        • Translation
        Прим. перев.: Эта увлекательная статья, в подробностях раскрывающая предназначение swap в Linux и отвечающая на распространённое заблуждение на этот счёт, написана Chris Down — SRE из Facebook, который, в частности, занимается разработкой новых метрик в ядре, помогающих анализировать нагрузку на оперативную память. И начинает он своё повествование с лаконичного TL;DR…

        Читать дальше →
      • Сравнение производительности сетевых решений для Kubernetes

        • Translation


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

        Цель этого исследования — найти решение с наименьшими задержками, наибольшей пропускной способностью и самой небольшой стоимостью настройки. Поскольку наша нагрузка зависит от задержек, мы измеряем задержки высоких перцентилей при достаточно активной сетевой нагрузке. В частности, мы сфокусировались на производительности в районе 30-50 процентов от максимальной нагрузки, поскольку это лучше всего отражает типовые ситуации для неперегруженных систем.
        Читать дальше →
        • +23
        • 17.8k
        • 6