Kubernetes *

Прим. перев.: Эта статья написана Julia Evans — инженером международной компании Stripe, специализирующейся на интернет-платежах. Разбираться во внутренностях работы планировщика Kubernetes её побудил периодически возникающий баг с «зависанием» пода, о котором около месяца назад также сообщили специалисты из Rancher Labs (issue 49314). Проблема была решена и позволила поделиться деталями о техническом устройстве одного из базовых механизмов Kubernetes, которые и представлены в этом статье с необходимыми выдержками из соответствующего кода проекта.



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

Продолжаем рассказывать на примере известных компаний о том, что Kubernetes в production — это не только мечты и надежды. Эта статья — снова про технарей с мировым именем: SAP и её конвергентное облако на базе OpenStack и Kubernetes. Однако начнём с менее известной Concur и вот почему…

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



Примечание: все примеры рассказывают об использовании оригинального upstream-дистрибутива Kubernetes, а не его производных вроде OpenShift (Red Hat) и Tectonic (CoreOS).

Начнём с eBay, специалисты которой серьёзно работают с Kubernetes уже более 2 лет и значительно продвинулись в этом…

Предисловие переводчика: Эта статья — комбинация из перевода двух материалов от проекта CoreOS (см. ссылки в конце публикации), посвящённых работе с консольным инструментом для выполнения команд на кластерах Kubernetes — kubectl. Листинг, приведённый автором оригинала для Mac OS X, был адаптирован под Linux, в других листингах было исправлено форматирование YAML, а для удобства чтения всего материала в него были добавлены подзаголовки.

Kubectl — инструмент, который знаком пользователям Kubernetes и обладает широкими функциональными возможностями. Овладение ими занимает время, но позволяет увидеть, что это более мощный инструмент, чем многие предполагали. Представляю набор советов, позволяющих улучшить ваши возможности при работе с kubectl. Не забудьте также посмотреть на cheat sheet в секции официальной документации Kubernetes!

Предисловие переводчика: Minikube — удобный инструмент, который мы применяем в компании для локальных экспериментов с Kubernetes (в частности, для выполнения лабораторных работ по этой системе при обучении сотрудников). Эта статья показалась мне полезной во время моего знакомства с Kubernetes. Она написана год назад автором, использующим Mac OS X, а я проделывал все операции в Ubuntu 16.04 совсем недавно и с актуальными версиями основного софта: Minikube 0.20, Docker 17.06.0-ce, kubectl 1.7.0. Поэтому все выводы команд были переделаны под новые версии и незначительно отличаются от приведённых в оригинальной статье.

На образовательной онлайн-площадке edX появился курс «Introduction to Kubernetes», созданный некоммерческой организацией The Linux Foundation и проводимый специалистом из компании CloudYuga Technologies.

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

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

Две недели назад Open Source-проект CoreDNS отметился своим очередным релизом — 008. Авторы называют свой продукт «DNS-сервером, состоящим из цепочки промежуточных компонентов (middleware), каждый из которых реализует какую-то возможность DNS». Что примечательно, они уже успели добиться включения CoreDNS в список официальных проектов организации CNCF (Cloud Native Computing Foundation), пополнив ряды Kubernetes, Prometheus, CNI, containerd, rkt и других разработок, активно применяемых в мире контейнеров, микросервисов и «родных облачных приложений» (cloud native).

Как появился CoreDNS, для чего он предназначен и как его можно использовать?

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

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

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

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

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

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

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

Предисловие переводчика: Буквально через неделю после нашей публикации знакомства с 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.

Проблема 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.

22 марта в Avito прошёл второй митап московского Kubernetes коммьюнити, а сегодня мы делимся материалами встречи. Денис Измайлов сделал обзор последних изменений инструмента, Евгений Ольков и Павел Селиванов рассказали про то, как используется Kubernetes, соответственно, в Avito и Центре Недвижимости от Сбербанка, а Сергей Орлов сделал короткий доклад про пакетный менеджер Helm. Приятного просмотра!

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.