Прим. перев.: как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101». Все статьи сопровождаются простыми и наглядными комиксами. Представляем вниманию перевод материала под названием «Внутри кластера» из этого цикла.

Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.

Недавно мне посчастливилось заниматься переносом кластера PostgreSQL под управлением Patroni на новое железо. Задача казалась простой — я и не думал, что могут возникнуть проблемы. Но в процессе реализации встретились некоторые сложности, которые натолкнули на мысль поделиться полученным опытом. В этой работе описываются практические шаги и нюансы, которые встретились во время переноса кластера на новую платформу. Использовались следующие версии ПО: PostgreSQL 11.13, Patroni 2.1.1, etcd 3.2.17 (API version 2). Итак, поехали!

Прим. перев.: в этой статье инженеры онлайн-сервиса Cloudflare весьма популярно объясняют, что именно (технически) произошло с недоступностью Facebook минувшим вечером (4-го октября 2021), а также затрагивают тему того, как этот сбой повлиял на более глобальные процессы в интернете.

«Разве Facebook может упасть?» — задумались мы на секунду…

Сегодня в 16:51 UTC (в 19:51 MSK — прим. перев.) у нас был открыт внутренний инцидент под названием «Facebook DNS lookup returning SERVFAIL». Мы решили, что это с нашим DNS-ресолвером 1.1.1.1 что-то не так. Однако к моменту размещения соответствующего обновления на публичной статус-странице стало ясно, что здесь что-то серьёзное.

Социальные сети уже разрывались от сообщений о том, что быстро подтвердили и наши инженеры: Facebook и связанные с ним сервисы WhatsApp и Instagram действительно упали. Их DNS-имена больше не ресолвились, а IP-адреса инфраструктуры были недоступны. Выглядело так, как будто кто-то буквально выдернул кабели разом во всех их дата-центрах, отключив от интернета.

Как такое вообще возможно?

Weave Scope — Open Source-утилита для контроля за микросервисными приложениями, развернутыми в Docker и Kubernetes. Утилита визуализирует топологию приложения на уровне контейнеров, помогает находить проблемы и оптимизировать архитектуру. Управление организовано через простой веб-интерфейс; командная строка нужна только для установки и запуска приложения.

Weave Scope можно использовать бесплатно на локальном сервере. Также есть платная SaaS-версия. Создатели Weave Scope — компания Weaveworks, которая известна и другими популярными cloud native-решениями (например, Cortex и Flux).

Чтобы продемонстрировать возможности Weave Scope, развернем утилиту на хосте, потом в кластере Kubernetes, после чего попробуем подключить один из готовых плагинов, который расширяет базовую функциональность Weave Scope.

Прим. перев.: оригинал этой статьи был опубликован минувшим летом в рамках проекта ReadME. Он создан в GitHub с целью стать своеобразной трибуной для многочисленных Open Source-разработчиков, предоставив им возможность поделиться с широким сообществом актуальными для них проблемами. Данный материал несет в себе призыв «перестать воспринимать Open Source как должное» и раскрывает те сложности, с которыми сталкиваются многие авторы свободного ПО, применяемого буквально повсеместно.

Тобиас Копперс (Tobias Koppers) не работает в Instagram. И никогда не работал. Но с 2014 года он отвечает за поддержку важного компонента веб-версии Instagram. Копперс является создателем webpack — Open Source-инструмента для сборки (или «бандлинга») кода JavaScript.

В мире существует множество различных систем для хранения кода. Различаются они как протоколом работы: Git, Mercurial, Bazaar, — так и форматом работы (cloud, self-hosted). Но есть и другой важный параметр: степень интеграции с сопутствующим инструментарием: issue tracker, CI/CD, wiki и т.д. Так сложилось, что мы в компании предпочитаем GitLab (вариант on-premise) и по умолчанию, если клиент не против, предлагаем ему это решение. В статье я расскажу про миграцию из Gitea c Jenkins в GitLab и о том, с какими сложностями пришлось столкнуться, а заодно поделюсь Python-скриптами, которые пригодились для успеха этого мероприятия.

The Update Framework (TUF) — программный фреймворк с открытым кодом для защиты репозиториев, из которых скачиваются обновления. Главная задача TUF — предоставить возможность обновлять софт безопасно, а также минимизировать ущерб в случае, если обновление скомпрометировано. Фреймворк можно использовать для создания собственной системы обновления ПО (например, менеджера пакетов) либо для повышения безопасности существующей.

В 2017 году TUF приняли в экосистему CNCF, а в 2019-м он стал первым выпускником среди проектов из области безопасности. TUF ориентирован на внедрение в любые системы обновления ПО и системы управления конфигурациями (а раз проект в CNCF, то речь, конечно, идет про решения из мира cloud native). Его уже используют Microsoft, Amazon, Google, DigitalOcean, Docker, IBM, Datadog, VMware, Red Hat и другие компании.

Kubernetes стал стандартом для запуска микросервисных (и не только) приложений. Компании разных размеров — от стартапов до enterprise — стараются проектировать свои приложения готовыми для запуска в Kubernetes-кластере.

А для запуска приложения в K8s обычно используют Helm-шаблоны с описанием манифестов. Хотя формат шаблонов легко читается и прост в изучении, он может вызвать определенные сложности, когда логика деплоя приложения разрастается, когда создаются дополнительные тестовые контуры (с деплоем только отдельных частей приложения) и т.д. При активном использовании Go-шаблонов рефакторинг манифестов может превратиться в нетривиальную задачу*.

Что делать, если у разработчиков нет времени разбираться со всеми тонкостями Helm-шаблонов, синтаксисом YAML и Go templates, но нужно запустить приложение в Kubernetes? Ответом на этот вопрос может стать использование cdk8s.

Прим. перев.: в процессе поиска решения проблемы с логированием медленных запросов MySQL наткнулся на довольно познавательную статью. Её автор не только в деталях описывает своё расследование, которое может оказаться полезным для начинающих администраторов, но и попутно пробуждает чувства ностальгии по эпохе VT100.

Сначала краткая предыстория. Я пытался сделать так, чтобы логи медленных запросов в MySQL писались в /dev/stderr и их можно было бы читать с помощью простого docker-compose logs -f mysql без необходимости входить в контейнер с docker-compose exec mysql ash.

Kalm — бесплатное приложение с открытым исходным кодом. Представляет собой стандартный контроллер Kubernetes, который можно установить в любой кластер (версии v1.15 и выше), включая Amazon EKS и Google GKE. Основная цель Kalm — предоставить разработчикам простой пользовательский интерфейс, чтобы упростить работу с K8s.

В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.

Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…

Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание. В этой статье разберём работу двух Open Source-утилит для аудита безопасности кластера от известных экспертов этой области — Aqua Security.

Прим. перев.: автор этой статьи — engineering manager из Испании, работающий в цифровой торговой площадке Adevinta, представленной в 16 странах, — делится своими наблюдениями о частых проблемах, которые он встречал у создателей микросервисов. Об этих вызовах стоит знать заранее, чтобы не столкнуться с ними тогда, когда их решение может оказаться слишком затратным.

Когда пост Мартина Фаулера о микросервисах вышел в 2014 году, команды, в которых я работал, уже занимались SOA-приложениями. Эта статья и последующий хайп коснулись почти каждой команды разработчиков в мире. Стек Open Source-софта от Netflix был самым крутым в то время, поскольку позволял инженерам по всему миру перенимать опыт Netflix в распределенных системах. Если мы взглянем на работу разработчиков программного обеспечения сегодня, более шести лет спустя, большая её часть касается архитектуры микросервисов.

Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.

В таких случаях приходят на помощь «мини-кластеры». Их можно запустить на рабочем ПК, «поиграться» с примитивами, построить новую структуру, а после завершения эксперимента — безвозвратно удалить (ведь это уже отработанный материал!).

Отвечая на эту потребность, разработчики со всего мира пришли со своими решениями для быстрого запуска облегчённого варианта Kubernetes. Все они по-разному организованы и, конечно, обладают разными возможностями. Чем пользоваться, зависит от нужд и предпочтений. Чтобы получше разобраться в них или вообще понять, с чего стоит начать, предлагаем результаты нашего беглого знакомства с некоторыми популярными решениями. Благо, все они достаточно хорошо документированы (как на сайтах, так и в CLI), что существенно ускоряет первое погружение и взаимодействие с ними. В конце статьи будет сводная таблица с основными особенностями решений.

Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.

В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the world» я размышляю о таких типичных проблемах, как эффект второй системы, дилемма инноваторов и других. Может ли проектирование систем дать ответ на вопрос о микросервисах? Да, хотя ответы могут вам не понравиться.

Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.

Этой ночью, 5 августа, состоится новый релиз Kubernetes — 1.22. Рассказываем о наиболее значимых изменениях в новой версии.

Istio — частный случай «сервисной сетки» (Service Mesh), понятия, о котором наверняка все слышали, и многие даже знают, что это такое. Мой доклад на Kuber Conf 2021 (мероприятие Yandex.Cloud, которое проходило 24 июня в Москве) посвящен возможным проблемам, к которым надо готовиться при внедрении Istio. Среди прочего я рассказал о том, как Istio влияет на трафик, какие есть возможности для его мониторинга, насколько безопасен mTLS.

Доклад отчасти отражает наш опыт работы с Istio как с одним из компонентов Kubernetes-платформы Deckhouse, отчасти основан на результатах внутренних нагрузочных тестов.

Сегодня состоялся долгожданный публичный Open Source-релиз нашей платформы для автоматизации обслуживания кластеров Kubernetes — Deckhouse. Этому предшествовало три с половиной года внутренней разработки и эксплуатации платформы на многочисленных и весьма разнообразных проектах. Сейчас с помощью Deckhouse мы обслуживаем в production более 170 кластеров (3500+ узлов), в которых развернуто около 3000 приложений. Deckhouse — это квинтэссенция нашего опыта в эксплуатации Kubernetes-кластеров и кульминация всей связанной с этим производственной деятельности последних лет.

Мы начали выдавать ранний доступ к платформе и демонстрировать её возможности ещё в мае, на конференции HighLoad++. Уже более 300 человек смогли самостоятельно попробовать Deckhouse. Пришло время поделиться нашим опытом автоматизации Kubernetes с более широким сообществом!

Прим. перев.: автор этой статьи — технический архитектор Sudhir Jonathan — рассказывает об одном из тех базовых механизмов, с которым сталкивается каждый пользователь, разработчик и системный администратор. Однако до возникновения определённых (и иногда довольно специфичных) проблем многие не задумываются о том, как всё работает «под капотом». Автор устраняет этот пробел, используя популярные фреймворки, серверы БД и приложений в качестве понятных примеров.

Соединения — это скрытый механизм, который компьютерные системы используют для общения друг с другом. Они стали настолько неотъемлемой частью нашей жизни, что мы часто забываем, насколько они важны, не замечаем, как они работают и терпят неудачу. Часто мы забываем о них до тех пор, пока не возникает проблема. При этом обычно она проявляется массовым отказом именно в то время, когда системы загружены сильнее всего. Поскольку соединения встречаются повсюду и они важны практически для каждой системы, стоит потратить немного времени на их изучение.