Нередко при диагностике проблем в кластере Kubernetes мы замечаем, что иногда моросит* один из узлов кластера и, конечно же, происходит это редко и странно. Так мы пришли к необходимости в инструменте, который бы делал ping с каждого узла на каждый узел и отдавал результаты своей работы в виде метрик Prometheus. Нам бы оставалось лишь нарисовать графики в Grafana и быстро локализовать сбойный узел (и при необходимости убрать с него все pod'ы, после чего произвести соответствующие работы**)…

Прим. перев.: Service mesh'и определённо стали актуальным решением в современной инфраструктуре для приложений, следующих микросервисной архитектуре. Хотя Istio может быть на слуху у многих DevOps-инженеров, это довольно новый продукт, который, будучи комплексным в смысле предоставляемых возможностей, может потребовать значительного времени для знакомства. Немецкий инженер Rinor Maloku, отвечающий за облачные вычисления для крупных клиентов в телекоммуникационной компании Orange Networks, написал замечательный цикл материалов, что позволяют достаточно быстро и глубоко погрузиться в Istio. Начинает же он свой рассказ с того, что вообще умеет Istio и как на это можно быстро посмотреть собственными глазами.

Istio — Open Source-проект, разработанный при сотрудничестве команд из Google, IBM и Lyft. Он решает сложности, возникающие в приложениях, основанных на микросервисах, например, такие как:

Необходимость подхвата ресурсов кластера Kubernetes может возникнуть в боевых условиях, когда нельзя просто пересоздать их инструментами Helm. Можно выделить две основные причины:

• Будет простой — вне зависимости от того, облако у вас или bare metal.
• При удалении могут потеряться сервисы в облаках, а также слетят связанные Load Balancer'ы в Kubernetes.

В нашем же случае, решение потребовалось для подхвата работающих ingress-nginx'ов при интеграции нашего оператора Kubernetes.

За проектом containerd мы следим с самого его начала. Посему не можем обойти вниманием значимое событие: минувшей ночью организация CNCF, стоящая за Kubernetes и другими выдающимися Open Source-решениями для мира cloud native, объявила containerd своим «выпускником». Этот проект стал уже пятым с таким статусом, пополнив ряды K8s, Prometheus, Envoy и CoreDNS.

На прошлой неделе было объявлено о том, что отныне все новые сервисы Reddit запускаются в production на инфраструктуре, основанной на Kubernetes-кластерах. Эта значимая веха на пути миграции на K8s одного из популярнейших онлайн-ресурсов, и вот как к ней пришли…

В начале года появился новый веб-сервис KubeSail, созданный двумя американскими Kubernetes-энтузиастами, задавшимися целью «сделать преимущества Kubernetes более доступными для всех разработчиков». Для её достижения они предложили K8s-кластер в виде управляемой услуги (managed service), в рамках которой имеется бесплатный тарифный план.

На днях американский инженер Andrew Rynhard представил интересный проект: компактный дистрибутив Linux, предназначенный специально для запуска Kubernetes-кластеров. Он получил название из древнегреческой мифологии — Talos.

Прим. перев.: Оригинальная статья была написана инженером из Швеции — Christian Abdelmassih, — который увлекается архитектурой уровня enterprise, ИТ-безопасностью и облачными вычислениями. Недавно он получил степень магистра в области Computer Science и спешит поделиться своим трудом — магистерской диссертацией, а точнее — её частью, посвящённой проблемам изоляции контейнеризированного [и запущенного в Kubernetes] приложения. В качестве «клиента», для которого была подготовлена эта исследовательская работа, выступает ни много ни мало полиция его родины.



Оркестровка контейнеров и облачные (cloud-native) вычисления стали очень популярными в последние годы. Их адаптация дошла до такого уровня, что интерес к ним проявляют даже финансовые предприятия, банки, госсектор. На фоне других компаний их выделяют обширные требования в области безопасности информации и ИТ.

Прим. перев.: Минувшей ночью Aleksa Sarai, старший инженер по контейнерам из SUSE Linux, сообщил в почтовой рассылке oss-sec о критической уязвимости в безопасности runc/LXC, которая позволяет злоумышленнику, имеющему доступ в изолированный контейнер, получить привилегии root на хостовой системе. Поскольку проблема выявлена в эталонной реализации исполняемой среды для контейнеров — runc, — она затрагивает многочисленные контейнерные системы включая Docker/Moby, Podman, cri-o (и собственно Kubernetes). Ниже представлены подробности в виде перевода сообщения инженера в почтовую рассылку.


Я являюсь одним из мейнтейнеров runc (нижележащей среды исполнения контейнеров, используемой в Docker, cri-o, containerd, Kubernetes и т.п.). Недавно стало известно об уязвимости, которую мы проверили и пропатчили.

Как и любое другое решение, Helm — пакетный менеджер для Kubernetes — имеет плюсы, минусы и область применения, поэтому при его использовании стоит правильно оценивать свои ожидания…


Мы используем Helm в своём арсенале инструментов непрерывного выката. На момент написания статьи в наших кластерах более тысячи приложений и примерно 4000 инсталляций этих приложений в различных вариациях. Периодически мы сталкиваемся с проблемами, но в целом довольны решением, не имеем простоев и потерь данных.

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

Прим. перев.: Оригинальную статью написал Miłosz Smółka — один из основателей небольшой польской компании Three Dots Labs, специализирующейся на «продвинутых backend-решениях». Автор опирается на свой опыт активной эксплуатации GitLab CI и делится накопленными советами для других пользователей этого Open Source-продукта. Прочитав их, мы поняли, насколько нам близки описанные им проблемы, поэтому решили поделиться предлагаемыми решениями с более широкой аудиторией.



На этот раз я затрону более продвинутые темы в GitLab CI. Частой задачей здесь является реализация в пайплайне нестандартных возможностей. Большинство советов специфичны для GitLab, хотя некоторые из них можно применить и к другим системам CI.

Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.

Резонный вопрос: зачем вообще может понадобится переписывать программу, которая уже написана и нормально работает?

Вы не одиноки в этом мире, если вот уже долгое время не рады тому, как выглядит стандартный вывод docker ps. Хотя и существуют различные workarounds на эту тему (см. в конце материала), однажды какой-нибудь энтузиаст должен был сделать «что-то ещё»… и это произошло в наступившем 2019 году. Имя ему — docker-pretty-ps.

Задумка автора банальна донельзя: горизонтальный вывод и цвета для наглядности.



А в качестве аудитории утилиты называются «скорее разработчики, чем хардкорные DevOps'ы или SRE-инженеры».

Прим. перев.: Это уже не первая статья с общими рекомендациями по безопасности в Kubernetes, что мы переводим в своём блоге. Однако её актуальность — по меньшей мере, как напоминание о простых и важных вещах, на которые не стоит закрывать глаза из-за нехватки времени, — только подтверждается недавними событиями, упоминаемыми автором в начале материала. К слову, автором является Connor Gilbert — менеджер продуктов компании StackRox, предлагающей готовую платформу для обеспечения безопасности приложений, разворачиваемых в рамках Kubernetes-кластеров. Итак, вот что он советует читателям блога CNCF…

NB: Чтобы сделать статью более информативной, для некоторых из упоминаемых автором терминов/методов мы добавили ссылки на соответствующую документацию.



В прошлом месяце в Kubernetes, самой популярной в мире системе оркестровки контейнеров, обнаружили первую крупную уязвимость в безопасности, что ударило по экосистеме проекта. Уязвимость CVE-2018-1002105 даёт возможность злоумышленникам скомпрометировать кластеры через API-сервер Kubernetes, что позволяет исполнять вредоносный код для установки malware и т.п.

В конце прошлого года на Reddit представили плагин к kubectl, помогающий производить отладку в pod'ах кластера Kubernetes — kubectl-debug. Эта идея сразу же показалась интересной и полезной нашим инженерам, так что мы решили посмотреть на её воплощение и рады поделиться своими результатами с читателями хабры.

Прим. перев.: Автор статьи — Marshall Brekka — занимает позицию директора по проектированию систем в компании Fair.com, предлагающей своё приложение для лизинга автомобилей. В свободное же от работы время он любит применять свой обширный опыт для решения «домашних» задач, которые вряд ли удивят любого гика (посему вопрос «Зачем?» — применительно к описанным дальше действиям — априори опущен). Итак, в своей публикации Marshall делится результатами недавнего развёртывания Kubernetes на… ARM-платах.



Как и у многих других гиков, за прошедшие годы у меня накопились разнообразные платы для разработки вроде Raspberry Pi. И как и у многих гиков, они пылились на полках с мыслью, что когда-нибудь пригодятся. И вот для меня этот день наконец-то настал!

Прим. ред.: Этой статьёй мы начинаем цикл публикаций, посвящённых английскому языку и подготовленных нашим штатным учителем для инженеров компании (в данном случае — на основе видеоурока engVid, JamesESL English Lessons). С одной стороны — нам нужно изучать язык, с другой — нравится это делать, а с третьей — почему бы не разбавить технические материалы своего блога? Ваши отзывы очень приветствуются!

Слово «very» очень популярно в английском языке, да и не только. Однако, употребляя его слишком часто, вы можете прослыть косноязычным или попросту Эллочкой-людоедочкой.



Как известно, в великом романе-эпопее «Война и Мир» Лев Николаевич не совершает повторов на протяжении каждых трех страниц(!). Не это ли искусство? Однако, не будем долго мечтать — let's get down to business.

Прим. перев.: Эта статья продолжает цикл материалов о базовом устройстве сетей в Kubernetes, что описывается в доступной форме и с наглядными иллюстрациями (впрочем, конкретно в этой части иллюстраций уже практически не оказалось). Переводя две предшествующие части этого цикла, мы объединили их в одну публикацию, в которой рассказывалось о сетевой модели K8s (взаимодействие внутри узлов и между узлами) и оверлейных сетях. Её предварительное чтение желательно (рекомендуется самим автором). Продолжение же посвящено сервисам Kubernetes и обработке исходящего и входящего трафика.
NB: Текст автора для удобства дополнен ссылками (преимущественно — на официальную документацию K8s).

Рады анонсировать новую Open Source-разработку компании «Флант» для DevOps-специалистов и не только — kubedog. Это написанная на Go библиотека и CLI на её основе для отслеживания событий ресурсов Kubernetes и сбора их логов.


На данный момент библиотека поддерживает слежение за следующими ресурсами: Pod (и Container), Job, Deployment, StatefulSet и DaemonSet. События и логи передаются через callback’и.

Минувшим вечером один из сотрудников нашей компании «внезапно и без объявления войны» получил следующую весть от корпоративного Slack'а про санкции США «к определённым странам и регионам, таким как Куба, Иран, Северная Корея, Сирия и регион Украины Крым»:



Особенно неприятным прозвучало завершение: «closing the account effective immediately».