Прим. перев.: авторы этой статьи — инженеры из небольшой чешской компании pipetail. Им удалось собрать замечательный список из [местами банальных, но всё ещё] столь актуальных проблем и заблуждений, связанных с эксплуатацией кластеров Kubernetes.



За годы использования Kubernetes нам довелось поработать с большим числом кластеров (как управляемых, так и неуправляемых — на GCP, AWS и Azure). Со временем мы стали замечать, что некоторые ошибки постоянно повторяются. Однако в этом нет ничего постыдного: мы сами совершили большинство из них!

В статье собраны наиболее распространенные ошибки, а также упомянуто о том, как их исправлять.

Прим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.

Краткое резюме всей статьи: fio и etcd

Производительность кластера etcd сильно зависит от скорости хранилища, лежащего в его основе. Для контроля за производительностью etcd экспортирует различные метрики Prometheus. Одной из них является wal_fsync_duration_seconds. В документации к etcd говорится, что хранилище можно считать достаточно быстрым, если 99-й процентиль этой метрики не превышает 10 мс…

Прим. перев.: Jaana Dogan — опытный инженер из Google, которая в данный момент занимается вопросами наблюдаемости production-сервисов компании, написанных на Go. В этой статье, снискавшей большую популярность у англоязычной аудитории, она в 17 пунктах собрала важные технические детали, касающиеся СУБД (а иногда — распределённых систем в целом), которые полезно учитывать разработчикам крупных/требовательных приложений.



Подавляющее большинство компьютерных систем отслеживают свое состояние и, соответственно, нуждаются в некой системе хранения данных. Я накапливала знания о базах данных в течение длительного времени, попутно совершая ошибки при проектировании, приводившие к потере данных и перебоям в работе. В системах, обрабатывающих большие объемы информации, базы данных лежат в сердце системной архитектуры и выступают ключевым элементом при выборе оптимального решения. Несмотря на то, что работе БД уделяется пристальное внимание, проблемы, которые пытаются предусмотреть разработчики приложений, часто оказываются лишь верхушкой айсберга. В этой серии статей я делюсь некоторыми идеями, которые будут полезны для разработчиков, не специализирующихся в этой области.

Прим. перев.: этот материал от образовательного проекта learnk8s — ответ на популярный вопрос при проектировании инфраструктуры на базе Kubernetes. Надеемся, что достаточно развёрнутые описания плюсов и минусов каждого из вариантов помогут сделать оптимальный выбор и для вашего проекта.



TL;DR: один и тот же набор рабочих нагрузок можно запустить на нескольких крупных кластерах (на каждый кластер будет приходиться большое число workload'ов) или на множестве мелких (с малым числом нагрузок в каждом кластере).

Ниже приведена таблица, в которой оцениваются плюсы и минусы каждого подхода:

Прим. перев.: оригинальную статью написал Josh Rosso — архитектор из VMware, ранее работавший в таких компаниях, как CoreOS и Heptio, а также являющийся соавтором Kubernetes alb-ingress-controller. Автор делится небольшим рецептом, который может оказаться очень полезным для инженеров по эксплуатации «старой школы», предпочитающих vim даже в эпоху победившего cloud native.



Пишете YAML-манифесты для Kubernetes в vim? Провели бесчисленные часы в попытках понять, где в этой спецификации должно быть очередное поле? А может быть, будете рады быстрому напоминанию о разнице args и command? Есть хорошие новости! Vim легко привязать к yaml-language-server, чтобы получить автоматическое дополнение, валидацию и другие удобства. В статье поговорим о том, как для этого настроить клиента языкового сервера.

Прим. перев.: эта поучительная история Omio — европейского агрегатора путешествий — проводит читателей от базовой теории до увлекательных практических тонкостей в конфигурации Kubernetes. Знакомство с такими случаями помогает не только расширять кругозор, но и предотвращать нетривиальные проблемы.



Доводилось ли вам сталкиваться с тем, что приложение «застревало» на месте, переставало отвечать на запросы о проверке состояния (health check'и) и вы не могли понять причину такого поведения? Одно из возможных объяснений связано с лимитом квот на ресурсы CPU. О нем и пойдет речь в этой статье.

TL;DR:
Мы настоятельно рекомендуем отказаться от CPU limit'ов в Kubernetes (или отключить квоты CFS в Kubelet), если используется версия ядра Linux с ошибкой CFS-квот. В ядре имеется серьезный и хорошо известный баг, который приводит к избыточному троттлингу и задержкам.

Прим. перев.: Эта статья входит в состав опубликованных в свободном доступе материалов проекта learnk8s, обучающего работе с Kubernetes компании и индивидуальных администраторов. В ней Daniele Polencic, руководитель проекта, делится наглядной инструкцией о том, какие шаги стоит предпринимать в случае возникновения проблем общего характера у приложений, запущенных в кластере K8s.



TL;DR: вот схема, которая поможет вам отладить deployment в Kubernetes:

Прим. перев.: Это продолжение цикла статей от технологического евангелиста из AWS (Adrian Hornsby) про довольно новую ИТ-дисциплину — chaos engineering, — в рамках которой инженеры проводят эксперименты, призванные смягчить последствия сбоев в системах. Первый материал этого цикла рассказывал про концепцию chaos engineering в целом, второй — о том, как эта деятельность способствует позитивным культурным изменениям внутри организаций.



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

Прим. перев.: service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов» или «сервисная сетка», а чуть позже некоторые коллеги стали продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.


Комикс от Sebastian Caceres

Введение

Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.

Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.

В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по сервисным сеткам. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.

Прим. перев.: Эта статья, написанная Galo Navarro, что занимает должность Principal Software Engineer в европейской компании Adevinta, — увлекательное и поучительное «расследование» в области эксплуатации инфраструктуры. Её оригинальное название было немного дополнено в переводе по причине, которую объясняет автор в самом начале.



Примечание от автора: Похоже, эта публикация привлекла гораздо больше внимания, чем ожидалось. Я до сих пор получаю гневные комментарии о том, что название статьи вводит в заблуждение и что некоторые читатели опечалены. Я понимаю причины происходящего, поэтому, несмотря на риск сорвать всю интригу, хочу сразу рассказать, о чем эта статья. При переходе команд на Kubernetes я наблюдаю любопытную вещь: каждый раз, когда возникает проблема (например, рост задержек после миграции), первым делом обвиняют Kubernetes, однако потом оказывается, что оркестратор, в общем-то, не виноват. Эта статья повествует об одном из таких случаев. Ее название повторяет восклицание одного из наших разработчиков (потом вы убедитесь, что Kubernetes тут вовсе ни при чем). В ней вы не найдете неожиданных откровений о Kubernetes, но можете рассчитывать на пару хороших уроков о сложных системах.

Пару недель назад моя команда занималась миграцией одного микросервиса на основную платформу, включающую CI/CD, рабочую среду на основе Kubernetes, метрики и другие полезности. Переезд носил пробный характер: мы планировали взять его за основу и перенести еще примерно 150 сервисов в ближайшие месяцы. Все они отвечают за работу некоторых из крупнейших онлайн-площадок Испании (Infojobs, Fotocasa и др.).

Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.

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


«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*

Жуть! Никто и никогда не должен требовать от пользователя поделиться логином и паролем, его учётными данными, с другим сервисом. Нет никакой гарантии, что организация, стоящая за этим сервисом, будет хранить данные в безопасности и не соберет больше персональной информации, чем нужно. Это может показаться дикостью, но некоторые приложения до сих пор применяют подобную практику!

Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).

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

Как известно, учиться на чужом опыте дешевле, а посему — пусть эти истории помогут быть готовыми к возможным неожиданностям. Кстати, большая и регулярно обновляемая подборка ссылок на такие «failure stories» публикуется на этом сайте (по данным из этого Git-репозитория).

Прим. перев.: Тема безопасности Docker, пожалуй, одна из вечных в современном мире IT. Поэтому без лишних объяснений представляем перевод очередной подборки соответствующих рекомендаций. Если вы уже интересовались этим вопросом, многие из них будут вам знакомы. А саму подборку мы дополнили списком из полезных утилит и несколькими ресурсами для дальнейшего изучения вопроса.



Предлагаю вниманию руководство по обеспечению безопасности Docker'а. Обратная связь приветствуется, так как это скорее сборник отрывков с разных ресурсов, и не все они были подвергнуты доскональной проверке. Рекомендации разделены на три категории:

1. Необходимые меры внутри операционной системы хоста при работе с Docker'ом;
2. Инструкции, относящиеся к файлу конфигурации сборки и созданию контейнеров;
3. Инструменты для безопасности, которые могут интегрироваться со специфическими функциями Docker Enterprise.

Прим. перев.: автор статьи — Erkan Erol, инженер из SAP — делится своим изучением механизмов функционирования команды kubectl exec, столь привычной для всех, кто работает с Kubernetes. Весь алгоритм он сопровождает листингами исходного кода Kubernetes (и связанных проектов), которые позволяют разобраться в теме настолько глубоко, насколько это требуется.



В одну из пятниц ко мне подошел коллега и поинтересовался, как выполнить команду в pod'е с помощью client-go. Я не смог ему ответить и внезапно осознал, что ничего не знаю о механизме работы kubectl exec. Да, у меня были определенные представления о его устройстве, однако я не был уверен на 100% в их правильности и потому решил заняться этим вопросом. Проштудировав блоги, документацию и исходный код, узнал много нового, и в этой статье хочу поделиться своими открытиями и пониманием. Если что-то не так, пожалуйста, свяжитесь со мной в Twitter.

Прим. перев.: Ведущий инженер из компании Zalando — Henning Jacobs — не раз замечал у пользователей Kubernetes проблемы в понимании предназначения liveness (и readiness) probes и их корректного применения. Посему он собрал свои мысли в эту ёмкую заметку, которая со временем станет частью документации K8s.



Проверки состояния, известные в Kubernetes как liveness probes (т.е., дословно, «тесты на жизнеспособность» — прим. перев.), могут быть весьма опасными. Рекомендую по возможности избегать их: исключениями являются только случаи, когда они действительно необходимы и вы полностью осознаете специфику и последствия их использования. В этой публикации речь пойдет о liveness- и readiness-проверках, а также будет рассказано, в каких случаях стоит и не стоит их применять.

Прим. перев.: Автор оригинального материала — Henning Jacobs из компании Zalando. Он создал новый веб-интерфейс для работы с Kubernetes, который позиционируется как «kubectl для веба». Почему новый Open Source-проект появился и каким критериям не удовлетворили уже существующие решения — читайте в его статье.



В этой публикации я рассматриваю различные веб-интерфейсы Kubernetes с открытым исходным кодом, предъявляю свои требования к универсальному UI и рассказываю, почему разработал Kubernetes Web View — интерфейс, призванный облегчить поддержку и устранение неполадок сразу во множестве кластеров.

Сценарии использования

В Zalando мы обслуживаем большое количество пользователей Kubernetes (900+) и кластеров (100+). Есть пара типичных случаев использования, в которых бы очень пригодилась помощь специализированного веб-инструмента:

1. общение с коллегами в рамках поддержки;
2. реагирование на инциденты и расследование их причин.

Прим. перев.: Эта заметка была написана исследователем ИТ-безопасности из компании Aqua Security, специализирующейся на DevSecOps. Она является прекрасной иллюстрацией тех тонкостей в конфигурации Kubernetes, что важно всегда держать в голове, обслуживая кластеры в production. Конечно, если вы думаете про их безопасность…



Kubernetes состоит из множества компонентов, и иногда их комбинирование определенным образом приводит к неожиданным результатам. В этой статье я покажу, как pod, запущенный с привилегиями root'а и примонтированной директорией /var/log узла, может раскрыть содержимое всей файловой системы хоста пользователю с доступом к его логам. Мы также обсудим варианты решения этой проблемы.

Прим. перев.: Этот материал продолжает замечательный цикл статей от технологического евангелиста из AWS — Adrian Hornsby, — задавшегося целью просто и понятно объяснить важность экспериментов, призванных смягчить последствия сбоев в ИТ-системах.

«Если провалил подготовку плана, то планируешь провал». — Бенджамин Франклин

В первой части данной серии статей я представил концепцию chaos engineering'а и объяснил, как он помогает находить и исправлять изъяны в системе до того, как они приведут к сбоям production. Также было рассказано о том, как хаос-инжиниринг способствует позитивным культурным изменениям внутри организаций.

В конце первой части я пообещал рассказать об «инструментах и способах внедрения сбоев в системы». Увы, у моей головы на сей счет имелись собственные планы, и в этой статье я попытаюсь ответить на самый популярный вопрос, возникающий и людей, желающих заняться хаос-инжинирингом: Что ломать в первую очередь?

Прим. перев.: Если вы задаётесь вопросами безопасности в инфраструктуре, основанной на Kubernetes, этот замечательный обзор от компании Sysdig станет отличной отправной точкой для беглого знакомства с актуальными на сегодняшний день решениями. В него включены и комплексные системы от известных игроков рынка, и значительно более скромные утилиты, закрывающие ту или иную проблему. А в комментариях мы как всегда будем рады узнать о вашем опыте использования этих инструментов и увидеть ссылки на другие проекты.


Программные продукты для обеспечения безопасности Kubernetes… их так много, и у каждого свои цели, область применения и лицензии.

Именно поэтому мы решили создать этот список и включили в него как открытые проекты, так и коммерческие платформы от разных поставщиков. Надеемся, он поможет вам выбрать те из них, что представляют наибольший интерес и направят в верном направлении в зависимости от конкретных потребностей в деле обеспечения безопасности Kubernetes.

Прим. перев.: Автор этого материала — Cindy Sridharan, инженер из компании imgix, занимающаяся вопросами разработки API и, в частности, тестирования микросервисов. В этом материале она делится своим развёрнутым видением актуальных проблем в области распределённой трассировки, где, по её мнению, наблюдается недостаток по-настоящему эффективных инструментов для решения насущных задач.


[Иллюстрация заимствована из другого материала про распределенную трассировку.]

Считается, что распределенную трассировку сложно внедрять, да и отдача от нее в лучшем случае сомнительная. «Проблемность» трассировки объясняют множеством причин, при этом часто ссылаются на трудоемкость настройки каждого компонента системы для передачи соответствующих заголовков вместе с каждым запросом. Хотя эта проблема действительно имеет место, ее вовсе нельзя назвать непреодолимой. Она, кстати, не объясняет, почему разработчики не очень любят трассировку (даже уже функционирующую).