В большой production пришёл не только Docker, но и Kubernetes. И если даже с контейнерами далеко не всегда всё достаточно просто, то уж «кормчий» и подавно остаётся за гранью правильного понимания среди многих системных администраторов, DevOps-инженеров, разработчиков. В этой небольшой статье предпринята попытка ответить на один из вечных вопросов (в контексте Kubernetes) с помощью наглядного объяснения идеи и особенностей данного проекта. Возможно, именно этого вам не хватало для того, чтобы начать плотное знакомство с Kubernetes или даже его эксплуатацию?

Соучредитель и архитектор крупного онлайн-сервиса Box (около 1400 сотрудников) Sam Ghods в своём прошлогоднем выступлении на KubeCon указал на типовую ошибку восприятия Kubernetes. Многие рассматривают этот продукт как очередной фреймворк для оркестровки контейнеров. Но если бы всё действительно было так, то зачем его разработчики неустанно напоминают про «корни Kubernetes API, уходящие в архитектуру*, создаваемую более 10 лет в рамках проекта Google Borg»?..

6 июня на конференции RootConf 2017, проходившей в рамках фестиваля «Российские интернет-технологии» (РИТ++ 2017), в секции «Непрерывное развертывание и деплой» прозвучал доклад «Наш опыт с Kubernetes в небольших проектах». В нём рассказывалось об устройстве, принципах работы и основных возможностях Kubernetes, а также о нашей практике использования этой системы в небольших проектах.

По традиции мы рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.

В высоконагруженных проектах всегда повышенные требования к избыточности и надежности. Одним из важнейших звеньев инфраструктуры является маршрутизатор, потому что от его устойчивости зависит доступность сети в целом. Именно на таких узлах мы используем одну из схем реализации отказоустойчивого виртуального роутера на базе GNU/Linux с использованием iproute2, NetGWM, keepalived, ISC DHCPD, PowerDNS. Как мы всё это настраиваем, читайте в этой статье.

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


«Два типа людей в эксплуатации: кто уже сломал production, кто ещё только собирается это сделать»

Опубликованная 10 дней назад заметка собрала более 23 тысяч положительных голосов на Reddit и разошлась по другим специализированным ресурсам вроде The New Stack. Суть истории такова:

Unattended upgrades — это родной для Debian/Ubuntu (и других основанных на них дистрибутивов GNU/Linux) механизм автоматических обновлений. По умолчанию он включён в системе благодаря наличию установленного пакета unattended-upgrades и конфигурационного файла /etc/apt/apt.conf.d/50unattended-upgrades, а настроен на обновления пакетов только из security-репозитория, куда попадают, например, критичные исправления для пакета libssl, которые выходят в результате очередного пополнения базы уязвимостей CVE.


Примечание: здесь и далее рассматриваются unattended upgrades в контексте серверных редакций Ubuntu, что скорее всего применимо «как есть» и к другим дистрибутивам, но могут встречаться свои особенности, оставшиеся вне рамок статьи.

Итак, какие дополнительные возможности предоставляют unattended upgrades (помимо включённых по умолчанию security updates) и к каким проблемам они могут привести?

Все пользователи облачных сервисов Amazon давно знают про родной консольный инструмент для работы с ними — aws-cli. Но оказалось, что далеко не всем его достаточно: по этой причине компания WALLIX выпустила альтернативное и более функциональное решение под названием awless.

Исходный код awless написан на языке Go (использует AWS Go SDK) и опубликован на GitHub под свободной лицензией (Apache License 2.0). Текущая версия awless — 0.1.0. Поддерживаются операционные системы GNU/Linux, Mac OS X и Windows. Что же позволяет эта утилита?

В статье кратко рассмотрены сторонние Open Source-утилиты для Kubernetes, реализующие разные возможности и призванные помочь в повседневной работе. 4 из них взяты из англоязычного материала и помогают в: автоматическом обновлении конфигураций, отслеживании нагрузки по контейнерам/подам/нодам, переключении контекстов, создании DIND-кластеров (Docker in Docker). Остальные — найдены на GitHub и представлены коротким списком.

На прошлой неделе фонд CNCF (Cloud Native Computing Foundation) объявил о принятии под своё крыло 10-го Open Source-проекта — CNI (Container Networking Interface). Его задача — обеспечить всё необходимое для стандартизированного управления сетевыми интерфейсами в Linux-контейнерах и гибкого расширения сетевых возможностей. В CNCF объяснили необходимость такого проекта активным распространением контейнеризированных приложений в мире production и утверждают, что «подобно тому, как Kubernetes позволяет разработчикам массово запускать контейнеры на тысячах машинах, этим контейнерам в больших масштабах требуется сетевое управление [и реализующий его фреймворк]».

Как же появился CNI и что он предлагает?

Предисловие переводчика: Когда мы собрались наконец-то подготовить свой материал по разворачиванию Ceph в Kubernetes, нашли уже готовую и, что немаловажно, свежую (от апреля 2017 года) инструкцию от компании Cron (из Боснии и Герцеговины) на английском языке. Убедившись в её простоте и практичности, решили поделиться с другими системными администраторами и DevOps-инженерами в формате «как есть», лишь добавив в листинги один небольшой недостающий фрагмент.

Программно-определяемые хранилища данных набирают популярность последние несколько лет, особенно с масштабным распространением частных облачных инфраструктур. Такие хранилища являются критической частью Docker-контейнеров, а самое популярное из них — Ceph. Если хранилище Ceph уже используется у вас, то благодаря его полной поддержке в Kubernetes легко настроить динамическое создание томов для хранения (volume provisioning) по запросу пользователей. Автоматизация их создания реализуется использованием Kubernetes StorageClasses. В этой инструкции показано, как в кластере Kubernetes реализуется хранилище Ceph.

На прошлой неделе компания CoreOS порадовала очередным Open Source-проектом — zetcd. На самом деле о нём было известно ещё с прошлого года, но теперь состоялся первый релиз, который перевёл продукт в статус бета-тестирования — заявил о готовности продукта к серьёзным испытаниям перед выпуском в мир production. Авторы позиционируют zetcd как готовую замену для ZooKeeper внутри таких распределённых/кластерных решений, как Mesos, Apache Kafka и Apache Drill. Их настрою не препятствует даже тот факт, что etcd предлагает «плоское» хранение ключей-значений против иерархического подхода своего конкурента. Как они к этому пришли?

Месяц назад компания Docker на конференции DockerCon 2017 официально представила свой новый Open Source-проект — Moby. Если это просто ещё один дополнительный проект, нужный кому-то, кто работает с Docker… то почему, как заметили внимательные пользователи, основной репозиторий компании в GitHub — docker/docker — стал пересылать на moby/moby?



Забегая вперёд и заранее отвечая на вопросы разработчиков, использующих Docker как простой способ запуска приложений в контейнерах: Moby — проект не для вас. Несмотря на его появление и происходящие внутри перестановки, «внешне» (для пользователей Docker как готового продукта) ничего не изменится. А для тех, кто настроен более глубоко разобраться в этих перестановках (весьма значимых!) и, возможно, даже воспользоваться ими для решения своих задач… начну с краткого экскурса в новейшую историю развития Docker.

Предисловие переводчика: Буквально через неделю после нашей публикации знакомства с CockroachDB состоялся первый финальный релиз этой распределённой и масштабируемой СУБД с открытым кодом, что ознаменовало её официальную готовность для применения в production. А значит — самое время научиться её «готовить» в реалиях микросервисов с Kubernetes.

В этой статье показано, как осуществлять оркестровку деплоя и управление небезопасным кластером CockroachDB из 3 узлов с помощью Kubernetes и его функции StatefulSet, находящейся в бета-версии.

Да, запуск stateful-приложения вроде CockroachDB на Kubernetes требует использования сложных возможностей системы, пока что поддерживаемых на уровне бета-версии. Запустить CockroachDB на Kubernetes для тестирования можно и проще, однако описанный здесь подход предназначен для разворачивания СУБД в production, когда необходимые функции в Kubernetes окончательно созреют для этого. (Прим. перев.: о проблеме stateful-приложений в Kubernetes и одном из подходов её решения мы рассказывали в материале про Kubernetes Operators.)

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


Kubernetes хранит базу данных нод кластера, просмотреть которую можно командой kubectl get nodes. Это мощный фундамент для автоматизации и интеграции с существующими инструментами. Одним из таких инструментов является SSH-утилита Fabric, известная ещё как fabfile.py.

В минувший понедельник стало известно о доступности видео с конференции DockerCon 2017, прошедшей во второй половине апреля. В одном из прозвучавших там докладов представитель компании Alibaba Cloud (или Aliyun) — подразделения Alibaba Group, специализирующегося на облачных вычислениях, IaaS, PaaS, SaaS и Big Data — рассказал о статистике и историях успеха Docker в Китае.

В этой статье, продолжающей нашу недавнюю публикацию о глобальной статистике по внедрению Docker, собраны наиболее интересные факты из доклада Alibaba Group, основанные на опросе 1000+ пользователей её публичного облака в апреле этого года и известных случаях применения Docker. Но начнём с предыстории «появления» Docker в мире китайских информационных технологий…

Предисловие от переводчика: CockroachDB — достаточно молодая реляционная СУБД с открытым кодом (лицензия Apache 2.0), изначально созданная быть распределённой (с горизонтальным масштабированием «из коробки») и отказоустойчивой. Её авторы из компании Cockroach Labs, созданной в 2015 году, задаются целью «совместить богатство функциональности SQL с горизонтальной доступностью, привычной для NoSQL-решений». Данное руководство написано одним из сотрудников компании-разработчика и опубликовано на сайте облачного провайдера DigitalOcean для того, чтобы познакомить ИТ-специалистов с этой СУБД и продемонстрировать её использование.

Введение

CockroachDB — распределённая СУБД (SQL) с открытым кодом, обеспечивающая согласованность данных, масштабируемость и выживаемость.

Настройка CockroachDB проста: устанавливаете её на нескольких серверах (узлах) и объединяете их в единое целое для совместной работы (кластер). Все узлы кластера действуют «симметрично» и предлагают доступ к одинаковым данным. Если хранилище для данных необходимо увеличить, то при используемой архитектуре достаточно создать новые узлы и присоединить к кластеру.

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

tl;dr: Service mesh — это выделенный слой инфраструктуры для обеспечения безопасного, быстрого и надёжного взаимодействия между сервисами. Если вы создаёте приложение для запуска в облаке (т.е. cloud native), вам нужен service mesh.

За прошедший год service mesh стал критически важным компонентом в облачном стеке. Компании с большим трафиком, такие как PayPal, Lyft, Ticketmaster и Credit Karma, уже добавили service mesh в свои приложения в production, а в январе Linkerd — Open Source-реализация service mesh для облачных приложений — стал официальным проектом фонда Cloud Native Computing Foundation (в этот же фонд недавно передали containerd и rkt, а ещё он известен как минимум по Kubernetes и Prometheus — прим. перев.). Но чем же является service mesh? И почему он стал внезапно необходим?


В этой статье я дам определение service mesh и прослежу его происхождение через изменения в архитектуре приложений, произошедшие за последнее десятилетие. Я отделю service mesh от связанных, но отличающихся концепций: шлюза API, edge proxy, корпоративной сервисной шины. Наконец, я опишу, где нужен service mesh, и что ожидать от адаптации этой концепции в мире cloud native.

На дворе 2017 год, а в различных статьях и, тем более, комментариях к ним то и дело приходится встречаться с мнением, что Docker — удел неопытных энтузиастов, экзотических компаний-однодневок и каких угодно экспериментов, максимально удалённых от реального production. И вот пока коллеги готовят новые технические материалы, я решил на публично доступных примерах и фактах показать, что это скорее миф и стереотип, чем мир, в котором живёт ИТ сегодня.

Масштабы и тенденции докеризации

Отправная точка для этой статьи — статистика от сервиса мониторинга Datadog, которая впервые появилась в 2015 году и в последний раз была обновлена буквально на днях, в апреле 2017 года. Datadog — это не какая-то традиционная аналитическая компания, а известная своей дружелюбностью к облачным окружениям система мониторинга (код её агента написан на Python и опубликован как Open Source).

Проблема stateful-приложений в Kubernetes

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

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).

В кластере Kubernetes нода может умереть или перезапуститься.

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

Однако вы можете заметить: когда нода падает, поды сломанной ноды на протяжении какого-то времени всё ещё запущены и получают запросы, которые уже не выполняются.

И по умолчанию это время, как мне кажется, слишком велико — его можно уменьшить. На него влияют несколько параметров, настраиваемых в Kubelet и Controller Manager.

В середине марта стало известно, что компания Docker предложила свой проект containerd независимому фонду Cloud Native Computing Foundation (кстати, произошло это одновременно с rkt от CoreOS). Событие последовало за обещанием компании, данным в декабре прошлого года, когда containerd был официально отделён от Docker Engine. Что же это за компонент и зачем его отделили?

Как устроен containerd

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