k8s почему так называется
Русские Блоги
Что такое Kubernetes? Почему он также называется K8S?
С Kubernetes вы можете быстро и эффективно удовлетворить следующие потребности пользователей:
Быстрое и точное развертывание приложений
Масштабируйте ваше приложение на лету
Показать новые функции без проблем
Ограничьте использование оборудования только необходимыми ресурсами
Цель состоит в том, чтобы создать экосистему инструментов и компонентов, чтобы снизить нагрузку на программы, работающие в публичных или частных облаках.
Преимущества Kubernetes:
Подвижный: публичное облако, частное облако, гибридное облако, полиморфное облако
Масштабируемый: модульный, подключаемый, монтируемый, комбинируемый
Самовосстановление: автоматическое развертывание, автоматический перезапуск, автоматическая репликация, автоматическое масштабирование
Google запустил проект Kubernetes в 2014 году. Kubernetes построен на 15-летних масштабных задачах Google на уровне производства, сочетающих лучшие идеи и практический опыт сообщества.
Почему стоит выбрать контейнер?
Хотите знать, почему вы решили использовать контейнеры?
Новый подход к развертыванию контейнеров основан на виртуализации на уровне операционной системы, а не виртуализации оборудования. Контейнеры изолированы друг от друга, а также изолированы от хоста: у них есть свои собственные файловые системы, они не могут видеть процессы друг друга, и назначенные им вычислительные ресурсы ограничены. Их легче построить, чем виртуальные машины. А поскольку они не связаны с инфраструктурой и файловой системой хоста, их можно переносить в разные типы облаков или операционных систем.
Поскольку контейнеры маленькие и быстрые, каждый образ контейнера может быть упакован и загружен программой. Такое соединение «программа-зеркало» «один к одному» приносит много удобства контейнеру. С контейнерами статические образы контейнеров могут создаваться во время компиляции / выпуска, а не во время развертывания. В результате каждому приложению больше не нужно ждать интеграции со всем остальным стеком приложений или идти на компромисс со средой инфраструктуры продукта. Генерация контейнерных изображений во время компиляции / выпуска создает среду, которая непрерывно переводит разработку в производство. Точно так же контейнеры гораздо прозрачнее, чем виртуальные машины, особенно для мониторинга и управления устройствами. Это особенно верно, когда жизненный цикл процесса контейнера управляется инфраструктурой, а не скрывается супервизором процесса внутри контейнера. В конечном итоге, поскольку каждый контейнер загружен одной программой, управление контейнером эквивалентно управлению или развертыванию всего приложения.
Краткое изложение преимуществ контейнера:
Гибкое создание и развертывание приложений. По сравнению с образами виртуальных машин создание образов контейнеров проще и эффективнее.
Непрерывная разработка, интеграция и развертывание: обеспечивает надежную высокочастотную компиляцию и развертывание образа контейнера с быстрым откатом (неизменяемость на основе изображений).
Разделение проблем между разработкой и операциями. Поскольку образ контейнера создается во время компиляции / выпуска, весь процесс отделен от инфраструктуры.
Стабильность окружающей среды на всех этапах разработки, тестирования и производства: результаты на ноутбуках такие же, как на облаке.
Переносимость распространения на облачных платформах и ОС: может работать на Ubuntu, RHEL, CoreOS, локальной системе, Google Container Engine и даже на других платформах.
Ориентированное на приложения управление: от запуска систем на виртуальном оборудовании до запуска программ в системах, использующих логические ресурсы, повышается уровень абстракции системы.
Слабосвязанные, распределенные, эластичные и неограниченные микросервисы: все приложение разбито на более мелкие, более независимые модули, и эти модули можно динамически развертывать и управлять ими, а не хранить на больших специализированных машинах Раздутый стек одного приложения.
Изоляция ресурсов: повышение предсказуемости производительности программы.
Использование ресурсов: эффективное и плотное.
Зачем мне Kubernetes и что он может сделать?
Как минимум, Kubernetes может планировать и запускать программные контейнеры на кластере физических или виртуальных машин. Кроме того, Kubernetes также позволяет разработчикам отрезать «цепочку» физических или виртуальных машин, переходя от архитектуры, ориентированной на хост, к архитектуре, ориентированной на контейнеры. Архитектура в конечном итоге предоставляет разработчикам множество присущих ей преимуществ и удобств. Kubernetes предоставляет действительно контейнерно-ориентированную среду разработки для инфраструктуры.
Kubernetes удовлетворяет общие потребности запуска программ в ряде продуктов, таких как:
Координируйте вспомогательные процессы, помогайте с интеграцией приложений и поддерживайте модель «программа-зеркало» один на один.
Смонтировать систему хранения
Распространенная конфиденциальная информация
Проверьте статус программы
Пример приложения для копирования
Использовать горизонтальное автоматическое масштабирование
Наименование и открытие
Доступ и чтение журналов
Обеспечить аутентификацию и авторизацию
Вышеприведенное объединяет упрощение платформы как услуги (PaaS) и гибкость инфраструктуры как услуги (IaaS) и облегчает миграцию между поставщиками услуг платформы.
Что это за платформа Kubernetes?
Хотя Kubernetes предоставляет множество функций, всегда будет больше новых сценариев, которые выигрывают от новых функций. Рабочие процессы для конкретных приложений можно упростить для ускорения разработки. Сначала приемлема специальная оркестровка, которая часто требует надежных крупномасштабных механизмов автоматизации. Вот почему Kubernetes также спроектирован как платформа для построения экосистемы компонентов и инструментов, облегчающей развертывание, масштабирование и управление приложениями.
Метки позволяют пользователям организовывать ресурсы в соответствии со своими предпочтениями. Аннотация позволяет пользователям добавлять информацию о клиентах в ресурсы для оптимизации рабочего процесса и предоставляет инструментам управления простой способ индикации состояния отладки.
Кроме того, панель управления Kubernetes построена из тех же API, которые могут использовать разработчики и пользователи. Пользователи могут писать свои собственные контроллеры, такие как планировщики, и использовать свои собственные API, которые распознаются общими инструментами командной строки.
Такая конструкция позволяет строить большое количество других систем на Kubernetes.
Что такое Kubernetes?
Kubernetes не является традиционной, всеобъемлющей системой «платформа как услуга» (Paas). Он уважает выбор пользователей, что важно.
Нет ограничений на типы поддерживаемых программ. Он не определяет структуру программы (например, Wildfly) и не ограничивает набор языков, поддерживаемых во время выполнения (например, Java, Python, Ruby). Он не только обслуживает 12-факторные приложения, но и не проводит различия между приложениями и службами. Kubernetes предназначен для поддержки максимально возможного числа типов рабочих нагрузок, включая рабочие нагрузки без сохранения состояния, с сохранением состояния и обработкой данных. Если программа хорошо работает внутри контейнера, она может работать лучше только в Kubernetes.
Нет промежуточного программного обеспечения (такого как шина сообщений), инфраструктуры обработки данных (такой как Spark), базы данных (такой как mysql), ни систем хранения кластера (таких как Ceph) как встроенные сервисы. Но все вышеперечисленные программы могут работать на Kubernetes.
Не существует такого понятия, как рынок услуг «нажми и разверни».
Исходный код не развернут, и программа не скомпилирована. В рабочих процессах с непрерывной интеграцией (CI) разные пользователи и проекты имеют разные потребности и производительность. Поэтому Kubernetes поддерживает иерархические рабочие процессы CI, но не контролирует рабочее состояние каждого слоя.
Позволяет пользователям выбирать собственные системы регистрации, мониторинга и раннего оповещения. (Kubernetes предоставляет некоторые инструменты интеграции для обеспечения реализации этой концепции)
Не предоставляет и не управляет полным языком / системой конфигурации приложения (например, jsonnet).
Не предоставляет и не сотрудничает с какой-либо полной конфигурацией машины, обслуживанием, управлением, системой самовосстановления.
С другой стороны, в Kubernetes работает большое количество систем PaaS, таких как Openshift, Deis и Eldarion. Вы также можете разрабатывать свой собственный PaaS, интегрировать выбранную вами систему CI или развертывать образы контейнеров только в Kubernetes.
Поскольку Kubernetes работает на уровне приложений, а не на аппаратном уровне, он предоставляет некоторые общие применимые функции, которые обычно предоставляет PaaS, такие как развертывание, масштабирование, балансировка нагрузки, ведение журналов и мониторинг. Тем не менее, Kubernetes не является монолитным. Эти решения по умолчанию являются необязательными и могут быть добавлены или удалены самостоятельно.
Что означает слово Kubernetes? K8S?
Переводчик: Linux Китай
Рекомендуемое чтение:
Пожалуйста, поиск “ICT_Architect” или «Размах сметены.» QR-код обратить внимание на публичный номер, нажмите Оригинальная ссылка Получить больше Электронная книга подробность 。
Если вы жаждете знаний, если вы скромны
Kubernetes для чайников: установка, настройка и основы
Содержание:
Контейнеризация приложений — один из главных трендов современных IT-разработок. Однако, у контейнеров есть один существенный недостаток для массового потребителя — сложная настройка масштабирования.
Решением стали автоматические системы управления контейнеризацией, наиболее популярной из которых является Kubernetes. Это программное обеспечение с открытым исходным кодом от компании Google завоевало признание благодаря сочетанию гибкости, безопасности и мощности.
Cтатья «Kubernetes для чайников» поможет разобраться как устроена платформа управления контейнеризацией, как установить ПО и для чего его можно использовать в дальнейшем. Она будет полезна как для начинающих пользователей Kubernetes, так и для профильных IT-специалистов.
История создания
Проект Kubernetes (сокращенно K8s) вырос из системы управления кластерами Borg. Внутренний продукт поискового гиганта Google получил название в честь кибер-рассы боргов из легендарного сериала «Звездный путь».
Команде разработчиков Google Borg была поставлена масштабная задача — создать открытое программное обеспечение для оркестрирования* контейнеров, которое станет вкладом Google в развитие мировых IT-технологий. Приложение было написано на основе языка Go.
* Под «оркестрированием» подразумевается автоматизированное управление связанными сущностями — контейнерами или виртуальными машинами.
На этапе разработки K8s назвался Project Seven («Проект «Седьмая»). Это было прямой отсылкой к персонажу «Звездного пути» Seven of Nine («Седьмая-из-девяти») — андроиду-боргу, сумевшему вернуть себе человечность. Позже проект получил имя «Кубернетес», от греческого слова κυβερνήτης, которое означает «управляющий», «рулевой» или «кормчий».
В 2014 году общественности представили исходные коды, а годом позже появилась первая версия программы Kubernetes 1.0. В дальнейшем все права на продукт были переданы некоммерческому фонду Cloud Native Computing Foundation (CNCF), куда входят Google, The Linux Foundation и ряд крупнейших технологических корпораций.
Как работает технология
Принципы устройства
Основы работы K8s – применение декларативного подхода. От разработчика требуется указать, чего необходимо достичь, а не способы достижения.
Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.
Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.
Основные задачи Kubernetes
Преимущества K8s
Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.
Основные компоненты
Схема взаимодействия основных компонентов K8s
Node (Нода)
Ноды или узлы — виртуальные или физические машины, на которых разворачивают и запускают контейнеры. Совокупность нод образует кластер Kubernetes.
Первая запущенная нода или мастер-нода непосредственно управляет кластером, используя для этого менеджер контроллеров (controller manager) и планировщик (scheduler). Она ответственна за интерфейс взаимодействия с пользователями через сервер API и содержит в себе хранилище «etcd» с конфигурацией кластера, метаданными и статусами объектов.
Namespace (Пространство имен)
Объект, предназначенный для разграничения ресурсов кластера между командами и проектами. Пространства имен — несколько виртуальных кластеров, запущенные на одном физическом.
Pod (Под)
Первичный объект развертывания и основной логический юнит в K8s. Поды — набор из одного и более контейнеров для совместного развертывания на ноде.
Группировка контейнеров разных типов требуется в том случае, когда они взаимозависимы и должны запускаться в одной ноде. Это позволяет увеличить скорость отклика во время взаимодействия. Например, это могут быть контейнеры, хранящие веб-приложение и сервис для его кэширования.
ReplicaSet (Набор реплик)
Объект, отвечающий за описание и контроль за несколькими экземплярами (репликами) подов, созданных на кластере. Наличие более одной реплики позволяет повысить устойчивость от отказов и масштабирование приложение. На практике ReplicaSet создается с использованием Deployment.
ReplicaSet является более продвинутой версией предыдущего способа организации создания реплик (репликации) в K8s – Replication Controller.
Deployment (Развертывание)
Объект, в котором хранится описание подов, количество реплик и алгоритм их замены в случае изменения параметров. Контроллер развертывания позволяет выполнять декларативные обновления (с помощью описания нужного состояния) на таких объектах, как ноды и наборы реплик.
StatefulSet (Набор состояния)
Как и другие объекты, например — ReplicaSet или Deployment, Statefulset позволяет развертывать и управлять одним или несколькими подами. Но в отличие от них, идентификаторы подов имеют предсказуемые и сохраняемые при перезапуске значения.
DaemonSet (Набор даемона)
Объект, который отвечает за то, чтобы на каждой отдельной ноде (или ряде выбранных) запускался один экземпляр выбранного пода.
Job/CronJob (Задания/Задания по расписанию)
Объекты для регулировки однократного или регулярного запуска выбранных подов и контроля завершения их работы. Контроллер Job отвечает за однократный запуск, CronJob — за запуск нескольких заданий по расписанию.
Label/Selector (Метки/Селекторы)
Метки предназначены для маркировки ресурсов. Позволяют упростить групповые манипуляции с ними. Селекторы позволяют выбирать/фильтровать объекты на основе значения меток.
По факту, метки и селекторы не являются самостоятельными объектами Kubernetes, но без них система не сможет полноценно функционировать.
Service (Сервис)
Средство для публикации приложения как сетевого сервиса. Используется, в том числе, для балансировки трафика/нагрузки между подами.
Процесс установки
Установка Kubernetes, рассмотренная ниже, предполагает наличие одного (или более) серверов с операционной системой Centos 7 или Ubuntu 16.04.
Затем открыть «/etc/fstab» с правами root и удалить соответствующую команде строчку «#/swapfile».
Проект Kubernetes действует на основе контейнеров Docker, существенно расширяя их функциональность. Логично, что начинать работу Kubernetes следует именно с установки Docker.
Проще всего остановить выбор на версии, добавленной на текущий момент в репозитории. Ее протестировали разработчики Kubernetes и она работает наиболее стабильно.
Установка контейнеров на Ubuntu 16.04
Чтобы установить Docker на Ubuntu 16.04, необходимо выполнить следующие команды с правами суперпользователя:
Если требуется работать с более новыми версиями контейнеров, запустите команды:
Установка контейнеров в CentOS 7
Для установки Docker на Centos, в консоли нужно выполнить команды:
Установка kubeadm, kubelet и kubectl в Ubuntu
Для работы с Kubernetes понадобится установить компоненты kubeadm, kubelet и kubectl. Эти утилиты понадобятся для создания управления кластером Kubernetes.
В Ubuntu эти компоненты можно установить следующим способом:
Установка kubeadm, kubelet и kubectl в CentOS
В CentOS 7 компоненты устанавливаются следующим образом:
Обращаем внимание! Команда setenforce 0 позволит получить корректный доступ контейнеров к файловой системе хоста. Последняя необходима для функционирования сети у подов.
Нужно убедиться, что «kubelet» и «docker» пользуются одним и тем же драйвером «cgroup». В этом может помочь команда:
Настройка Kubernetes
Инициализация кластера
Нужно указать сервер, на котором установлен K8s (он будет первичным — там будут запускаться остальные операции) и выполнить инициализацию кластера:
Обращаем внимание! Опция «—pod-network-cidr» задает адрес виртуальной сети подов и может отличаться, в зависимости от используемого сетевого плагина.
В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.
При выполнении команды в консоли, есть вероятность появления ошибок или предупреждений. Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production».
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к первичному хосту. Команда может отличаться, в зависимости от структуры кластера. Ее нужно сохранить на будущее.
После выполнения этой команды система выведет примерный результат:
Остается выполнить следующие команды от имени пользователя, который будет управлять кластером:
Настройка CNI
Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.
Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.
Чтобы установить Flannel, выполните в терминале команду:
В выводе будут отображены имена всех созданных ресурсов.
Добавление узлов (нод) в кластер
Чтобы добавить новые ноды в существующий кластер, требуется выполнить следующий алгоритм:
Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.
Если команда не была сохранена, то можно ее составить повторно.
Получение токена авторизации кластера ( )
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
Вывод должен быть примерно таков:
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
Вывод будет примерно таков:
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
Будет получен примерно такой вывод:
Для ввода IPv6-адреса в параметр « : », адрес должен быть заключен в квадратные скобки. Например:
Дополнительные настройки
В дефолтной конфигурации мастер-нода не запускает контейнеры, так как занимается отслеживанием состояния кластера и перераспределением ресурсов. Ввод данной команды даст возможность запускать контейнеры на мастере, собенно, если кластер содержит лишь одну ноду:
Проверка работоспособности кластера
Проверить, что кластер запустился и правильно работает, можно так:
Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.
Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.
Заключение
Несмотря на кажущуюся сложность настройки, K8s стоит времени, потраченного на его изучение. Kubernetes — наиболее совершенный на сегодня инструмент оркестрирования контейнеров. Он позволяет не только автоматизировать процесс развертывания, но и максимально упрощает дальнейший процесс работы с массивами контейнеров.
С помощью этого краткого руководства начать работу с K8s сможет даже начинающий пользователь. В дальнейшей работе с платформой поможет подробная официальная документация, доступная, в том числе, на русском языке.
10 причин [не] использовать k8s
Сегодня мы поговорим про Kubernetes, про грабли, которые можно собрать при его практическом использовании, и про наработки, которые помогли автору и которые должны помочь и вам. Постараемся доказать, что без k8s в современном мире никуда. Противникам k8s также предоставим отличные причины, почему не стоит на него переходить. То есть в рассказе мы будем не только защищать Kubernetes, но и ругать его. Отсюда в названии появилось это [не].
Эта статья основана на докладе Ивана Глушкова (gli) на конференции DevOops 2017. Последние два места работы Ивана так или иначе были связаны с Kubernetes: и в Postmates, и в Machine Zone он работал в инфракомандах, и Kubernetes они затрагивают очень плотно. Плюс, Иван ведет подкаст DevZen. Дальнейшее изложение будет вестись от лица Ивана.
Сперва я пробегусь вкратце по области, почему это полезно и важно для многих, почему этот хайп возникает. Потом расскажу про наш опыт использования технологии. Ну и потом выводы.
В этой статье все слайды вставлены как картинки, но иногда хочется что-нибудь скопировать. Например, там будут примеры с конфигами. Слайды в PDF можно скачать по ссылке.
Я не буду строго всем говорить: обязательно используйте Kubernetes. Есть и плюсы, и минусы, поэтому, если вы пришли искать минусы, вы их найдете. Перед вами выбор, смотреть только на плюсы, только на минусы или в целом смотреть на все вместе. Плюсы мне будет помогать показывать Simon Cat, и черная кошка будет перебегать дорогу, когда есть минус.
Итак, почему вообще произошел этот хайп, почему технология Х лучше, чем Y. Kubernetes — это точно такая же система, и существует их гораздо больше, чем одна штука. Есть Puppet, Chef, Ansible, Bash+SSH, Terraform. Мой любимый SSH помогает мне сейчас, зачем мне переходить куда-то. Я считаю, что критериев много, но я выделил самые важные.
Время от коммита до релиза — очень хорошая оценка, и ребята из Express 42 — большие эксперты в этом. Автоматизация сборки, автоматизация всего pipeline — это очень хорошая вещь, нельзя её перехвалить, она на самом деле помогает. Continuous Integration, Continuous Deployment. И, конечно же, сколько усилий вы потратите на то, чтобы все сделать. Все можно написать на Ассемблере, как я говорю, систему деплоймента тоже, но удобства это не добавит.
Короткую вводную в Kubernetes я рассказывать не буду, вы знаете, что это такое. Я немного коснусь этих областей дальше.
Почему всё это так важно для разработчиков? Для них важна повторяемость, то есть если они написали какое-то приложение, запустили тест, оно будет работать и у вас, и у соседа, и в продакшне.
Второе — стандартизированное окружение: если вы изучили Kubernetes и пойдете соседнюю компанию, где есть Kubernetes, там будет всё то же самое. Упрощение процедуры тестирования и Continuous Integration — это не прямое следствие использования Kubernetes, но всё равно это упрощает задачу, поэтому всё становится удобнее.
Для релиз-разработчиков гораздо больше плюсов. Во-первых, это иммутабельная инфраструктура.
Во-вторых, инфраструктура как код, который где-то хранится. В-третьих, идемпотентность, возможность добавить релиз одной кнопкой. Откаты релизов происходят достаточно быстро, и интроспекция системы достаточно удобная. Конечно, все это можно сделать и в вашей системе, написанной на коленке, но вы не всегда можете это сделать правильно, а в Kubernetes это уже реализовано.
Чем Kubernetes не является, и что он не позволяет делать? Есть много заблуждений на этот счет. Начнем с контейнеров. Kubernetes работает поверх них. Контейнеры — не легковесные виртуальные машины, а совсем другая сущность. Их легко объяснить с помощью этого понятия, но на самом деле это неправильно. Концепция совершенно другая, её надо понять и принять.
Во-вторых, Kubernetes не делает приложение более защищенным. Он не делает его автоматически скалируемым.
Нужно сильно постараться, чтобы запустить Kubernetes, не будет так, что «нажал кнопку, и все автоматически заработало». Будет больно.
Наш опыт. Мы хотим, чтобы вы и все остальные ничего не ломали. Для этого нужно больше смотреть по сторонам — и вот наша сторона.
Во-первых, Kubernetes не ходит в одиночку. Когда вы строите структуру, которая будет полностью управлять релизами и деплоями, вы должны понимать, что Kubernetes — один кубик, а таких кубиков должно быть 100. Чтобы все это построить, нужно все это сильно изучить. Новички, которые будут приходить в вашу систему, тоже будут изучать этот стек, огромный объем информации.
Kubernetes — не единственный важный кубик, есть много других важных кубиков вокруг, без которых система работать не будет. То есть нужно очень сильно беспокоиться об отказоустойчивости.
Из-за этого Kubernetes’у минус. Система сложная, нужно много о чем заботиться.
Но есть и плюсы. Если человек изучил Kubernetes в одной компании, в другой у него не встанут волосы дыбом из-за системы релизов. С течением времени, когда Kubernetes захватит большее пространство, переход людей и обучение будет более простым. И за это — плюс.
Мы используем Helm. Это система, которая строится поверх Kubernetes, напоминает пакетный менеджер. Вы можете нажать кнопку, сказать, что хотите установить *Wine* в свою систему. Можно устанавливать и в Kubernetes. Оно работает, автоматически скачает, запустит, и все будет работать. Он позволяет работать с плагинами, клиент-серверная архитектура. Если вы будете с ним работать, рекомендуем запускать один Tiller на namespace. Это изолирует namespace друг от друга, и поломка одного не приведет к поломке другого.
На самом деле система очень сложная. Система, которая должна быть абстракцией более высокого уровня и более простой и понятной, на самом деле не делает понятнее нисколечко. За это минус.
Давайте сравним конфиги. Скорее всего, у вас тоже есть какие-то конфиги, если вы запускаете в продакшне вашу систему. У нас есть своя система, которая называется BOOMer. Я не знаю, почему мы ее так назвали. Она состоит из Puppet, Chef, Ansible, Terraform и всего остального, там большой флакон.
Давайте посмотрим, как оно работает. Вот пример реальной конфигурации, которая сейчас работает в продакшне. Что мы здесь видим?
Во-первых, мы видим, где запускать приложение, во-вторых, что надо запускать, и, в-третьих, как это надо подготовить к запуску. В одном флаконе уже смешаны концепции.
Если мы посмотрим дальше, из-за того, что мы добавили наследование, чтобы сделать более сложные конфиги, мы должны посмотреть на то, что находится в конфиге common, на который ссылаемся. Плюс, мы добавляем настройку сетей, прав доступа, планирование нагрузки. Все это в одном конфиге, который нам нужен для того, чтобы запустить реальное приложение в продакшне, мы смешиваем кучу концепций в одном месте.
Это очень сложно, это очень неправильно, и в этом огромный плюс Kubernetes, потому что в нем вы просто определяете, что запустить. Настройка сети была выполнена при установке Kubernetes, настройка всего provisioning решается с помощью докера — у вас произошла инкапсуляция, все проблемы каким-то образом разделились, и в данном случае в конфиге есть только ваше приложение, и за это плюс.
Давайте посмотрим внимательнее. Здесь у нас есть только одно приложение. Чтобы заработал деплоймент, нужно, чтобы работала еще куча всего. Во-первых, нужно определить сервисы. Каким образом к нам поступают секреты, ConfigMap, доступ к Load Balancer.
Не стоит забывать, что у вас есть несколько окружений. Есть Stage/Prod/Dev. Это все вместе составляет не маленький кусочек, который я показал, а огромный набор конфигов, что на самом деле сложно. За это минус.
Helm-шаблон для сравнения. Он полностью повторяет шаблоны Kubernetes, если есть какой-то файл в Kubernetes с определением деплоймента, то же самое будет в Helm. Вместо конкретных значений для окружения у вас есть шаблоны, которые подставляются из values.
У вас есть отдельно шаблон, отдельно значения, которые должны подставиться в этот шаблон.
Конечно, нужно дополнительно определить различную инфраструктуру самого Helm, притом что у вас в Kubernetes масса конфигурационных файлов, которые нужно перетащить в Helm. Это все очень непросто, за что минус.
Система, которая должна упрощать, на самом деле усложняет. Для меня это явный минус. Либо нужно надстраивать что-то еще, либо не использовать
Давайте пойдем поглубже, мы недостаточно глубоко.
Во-первых, как мы работаем с кластерами. Я прочитал статью Гугла «Borg, Omega и Kubernetes», в ней очень сильно защищают концепцию, что нужно иметь один большой кластер. Я тоже был за эту идею, но, в конце концов, мы от неё ушли. В результате наших споров, используем четыре разных кластера.
Первый кластер e2e, для тестирования самого Kubernetes и тестирования скриптов, разворачивающих окружение, плагины и так далее. Второй, конечно же, prod и stage. Это стандартные концепции. В-третьих, это admin, в котором сгрузилось все остальное — в частности, у нас там CI, и, похоже, из-за него этот кластер будет самым большим всегда.
Тестирований очень много: по коммиту, по merge, все делают кучу коммитов, поэтому кластеры просто громадные.
Мы пытались посмотреть на CoreOS, но не стали ее использовать. У них внутри TF или CloudFormation, и то и другое очень плохо позволяет понимать, что находится внутри state. Из-за этого возникают проблемы при обновлении. Когда вы хотите обновить настройки вашего Kubernetes, к примеру, его версию, можно столкнуться с тем, что обновление происходит не таким образом, не в той последовательности. Это большая проблема стабильности. Это минус.
Во-вторых, когда вы используете Kubernetes, нужно откуда-то скачивать образы. Это может быть внутренний источник, репозиторий, или внешний. Если внутренний, есть свои проблемы. Я рекомендую использовать Docker Distribution, потому что она стабильная, её сделал Docker. Но цена поддержки все равно высокая. Чтобы она работала, нужно сделать ее отказоустойчивой, потому что это единственное место, откуда ваши приложения получают данные для работы.
Представьте, что в самый ответственный момент, когда вы нашли баг на продакшне, у вас репозиторий упал — приложение обновить вы не сможете. Вы должны сделать его отказоустойчивым, причем от всех возможных проблем, которые только могут быть.
В-третьих, при больших образах, скажем, если у вас есть монолит, размер образа будет очень большим. Представьте, что нужно зарелизить на 30 нод. 2 гигабайта на 30 нод — посчитайте, какой поток, как быстро он скачается на все ноды. Хотелось бы, чтобы нажал кнопку, и тут же зарелизилось. Но нет, нужно сначала дождаться, пока закачается. Надо как-то ускорять эту закачку, а все это работает с одной точки.
При внешних репозиториях есть те же проблемы с garbage collector, но чаще всего это делается автоматически. Мы используем Quay. В случае с внешними репозиториями — это сторонние сервисы, в которых большинство образов публичные. Чтобы не было публичных образов, нужно обеспечивать доступ. Нужны секреты, права доступа к образам, все это специально настраивать. Конечно, это можно автоматизировать, но в случае локального запуска Куба на своей системе вам все равно его придется настраивать.
Для установки Kubernetes мы используем kops. Это очень хорошая система, мы ранние пользователи с тех времен, когда они еще в блоге не писали. Она не до конца поддерживает CoreOS, хорошо работает с Debian, умеет автоматически конфигурировать мастер-ноды Kubernetes, работает с аддонами, есть способность делать нулевое время простоя во время обновления Kubernetes.
Все эти возможности из коробки, за что большой и жирный плюс. Отличная система!
По ссылкам можно найти много вариантов для настройки сети в Kubernetes. Их реально много, у всех свои достоинства и недостатки. Kops поддерживает только часть из этих вариантов. Можно, конечно, донастроить, чтобы работал через CNI, но лучше использовать самые популярные и стандартные. Они тестируются сообществом, и, скорее всего, стабильны.
Мы решили использовать Calico. Он заработал хорошо с нуля, без большого количества проблем, использует BGP, быстрее инкапсуляции, поддерживает IP-in-IP, позволяет работать с мультиклаудами, для нас это большой плюс.
Хорошая интеграция с Kubernetes, с помощью меток разграничивает трафик. За это — плюс.
Я не ожидал, что Calico дойдет до состояния, когда включил, и все работает без проблем.
High Availability, как я говорил, мы делаем через kops, можно использовать 5-7-9 нод, мы используем три. Сидим на etcd v2, из-за бага не обновлялись на v3. Теоретически, это позволит ускорить какие-то процессы. Я не знаю, сомневаюсь.
Хитрый момент, у нас есть специальный кластер для экспериментов со скриптами, автоматическая накатка через CI. Мы считаем, что у нас есть защита от совершенно неправильных действий, но для каких-то специальных и сложных релизов мы на всякий случаем делаем снапшоты всех дисков, мы не делаем бэкапов каждый день.
В качестве источника данных мы используем Active Directory. Kubernetes позволяет через всю структуру авторизации протащить информацию о группе, которая транслируется в namespace и роли. Таким образом сразу разграничиваем, куда человек может заходить, куда не имеет права заходить и что он может релизить.
Чаще всего людям нужен доступ к AWS. Если у вас нет Kubernetes, есть машина с запущенным приложением. Казалось бы, все что нужно — получать логи, смотри их и все. Это удобно, когда человек может зайти на свою машину и посмотреть, как работает приложение. С точки зрения Kubernetes все работает в контейнерах. Есть команда `kubectl exec` — залезть в контейнер в приложение и посмотреть, что там происходит. Поэтому на AWS-инстансы нет необходимости ходить. Мы запретили доступ для всех, кроме инфракоманды.
Более того, мы запретили долгоиграющие админские ключи, вход через роли. Если есть возможность использовать роль админа — я админ. Плюс мы добавили ротацию ключей. Это удобно конфигурировать через команду awsudo, это проект на гитхабе, очень рекомендую, позволяет работать, как с sudo-командой.
Квоты. Очень хорошая штука в Kubernetes, работает прямо из коробки. Вы ограничиваете какие-то namespace, скажем, по количеству объектов, памяти или CPU, которое можете потреблять. Я считаю, что это важно и полезно всем. Мы пока не дошли до памяти и CPU, используем только по количеству объектов, но это все добавим.
Большой и жирный плюс, позволяет сделать много хитрых вещей.
Масштабирование. Нельзя смешивать масштабирование внутри Kubernetes и снаружи Kubernetes. Внутри Kubernetes делает масштабирование сам. Он может увеличивать pod’ы автоматически, когда идет большая нагрузка.
Здесь я говорю про масштабирование самих инстансов Kubernetes. Это можно делать с помощью AWS Autoscaler, это проект на гитхабе. Когда вы добавляете новый pod и он не может стартовать, потому что ему не хватает ресурсов на всех инстансах, AWS Autoscaler автоматически может добавить ноды. Позволяет работать на Spot-инстансах, мы пока это не добавляли, но будем, позволяет сильно экономить.
Когда у вас очень много пользователей и приложений у пользователей, нужно как-то за ними следить. Обычно это телеметрия, логи, какие-то красивые графики.
У нас по историческим причинам был Sensu, он не очень подошел для Kubernetes. Нужен было более метрикоориентированный проект. Мы посмотрели на весь TICK стек, особенно InfluxDB. Хороший UI, SQL-подобный язык, но не хватило немножко фич. Мы перешли на Prometheus.
Он хорош. Хороший язык запросов, хорошие алерты, и все из коробки.
Чтобы посылать телеметрию, мы использовали Cernan. Это наш собственный проект, написанный на Rust. Это единственный проект на Rust, который уже год работает в нашем продакшне. У него есть несколько концепций: есть концепция источника данных, вы конфигурируете несколько источников. Вы конфигурируете, куда данные будете сливать. У нас есть конфигурация фильтров, то есть перетекающие данные можно каким-то образом перерабатывать. Вы можете преобразовывать логи в метрики, метрики в логи, все, что хотите.
При том, что у вас несколько входов, несколько выводов, и вы показываете, что куда идет, там что-то вроде большой системы графов, получается довольно удобно.
Мы сейчас плавно переходим с текущего стека Statsd/Cernan/Wavefront на Kubernetes. Теоретически, Prometheus хочет сам забирать данные из приложений, поэтому во все приложения нужно добавлять endpoint, из которого он будет забирать метрики. Cernan является передаточным звеном, должен работать везде. Тут две возможности: запускать на каждом инстансе Kubernetes, можно с помощью Sidecar-концепции, когда в вашем поле данных работает еще один контейнер, который посылает данные. Мы делаем и так, и так.
У нас прямо сейчас все логи шлются в stdout/stderr. Все приложения рассчитаны на это, поэтому одно из критических требований, чтобы мы не уходили от этой системы. Cernan посылает данные в ElasticSearch, события всей системы Kubernetes посылают туда же с помощью Heapster. Это очень хорошая система, рекомендую.
После этого все логи вы можете посмотреть в одном месте, к примеру, в консоли. Мы используем Kibana. Есть замечательный продукт Stern, как раз для логов. Он позволяет смотреть, раскрашивает в разные цвета разные поды, умеет видеть, когда один под умер, а другой рестартовал. Автоматически подхватывает все логи. Идеальный проект, очень его рекомендую, это жирный плюс Kubernetes, здесь все хорошо.
Секреты. Мы используем S3 и KMS. Думаем о переходе на Vault или секреты в самом Kubernetes. Они были в 1.7 в состоянии альфы, но что-то делать с этим надо.
Мы добрались до интересного. Разработка в Kubernetes вообще мало рассматривается. В основном говорится: «Kubernetes — идеальная система, в ней все хорошо, давайте, переходите».
Но на самом деле бесплатный сыр только в мышеловке, а для разработчиков в Kubernetes — ад.
Не с той точки зрения, что все плохо, а с той, что надо немножко по-другому взглянуть на вещи. Я разработку в Kubernetes сравниваю с функциональным программированием: пока ты его не коснулся, ты думаешь в своем императивном стиле, все хорошо. Для того, чтобы разрабатывать в функциональщине, надо немножко повернуть голову другим боком — здесь то же самое.
Разрабатывать можно, можно хорошо, но нужно смотреть на это иначе. Во-первых, разобраться с концепцией Docker Way. Это не то чтобы сложно, но до конца ее понять довольно проблематично. Большинство разработчиков привыкло, что они заходят на свою локальную, удаленную или виртуальную машину по SSH, говорят: «Давай я тут кое-что подправлю, подшаманю».
Ты говоришь ему, что в Kubernetes так не будет, потому что у тебя read only инфраструра. Когда ты хочешь обновить приложение, пожалуйста, сделай новый образ, который будет работать, а старый, пожалуйста, не трогай, он просто умрет. Я лично работал над внедрением Kubernetes в разные команды и вижу ужас в глазах людей, когда они понимают, что все старые привычки придется полностью отбросить, придумать новые, новую систему какую-то, а это очень сложно.
Плюс придется много делать выборов: скажем, когда делаешь какие-то изменения, если разработка локальная, нужно как-то коммитить в репозиторий, затем репозиторий по pipeline прогоняет тесты, а потом говорит: «Ой, тут опечатка в одном слове», нужно все делать локально. Монтировать каким-то образом папку, заходить туда, обновлять систему, хотя бы компилировать. Если тесты запускать локально неудобно, то может коммитить в CI хотя бы, чтобы проверять какие-то локальные действия, а затем уже отправлять их в CI на проверку. Эти выборы достаточно сложные.
Особенно сложно, когда у вас развесистое приложение, состоящее из ста сервисов, а чтобы работал один из них, нужно обеспечить работу всех остальных рядышком. Нужно либо эмулировать окружение, либо как-то запускать локально. Весь этот выбор нетривиальный, разработчику об этом нужно сильно думать. Из-за этого возникает негативное отношение к Kubernetes. Он, конечно, хорош — но он плох, потому что нужно много думать и изменять свои привычки.
Поэтому здесь три жирных кошки перебежали через дорогу.
Когда мы смотрели на Kubernetes, старались понять, может, есть какие-то удобные системы для разработки. В частности, есть такая вещь, как Deis, наверняка вы все про нее слышали. Она очень проста в использовании, и мы проверили, на самом деле, все простые проекты очень легко переходят на Deis. Но проблема в том, что более сложные проекты могут на Deis не перейти.
Как я уже рассказал, мы перешли на Helm Charts. Но единственная проблема, которую мы сейчас видим — нужно очень много хорошей документации. Нужны какие-то How-to, какие-то FAQ, чтобы человеку быстро стартовать, скопировать текущие конфиги, вставить свои, поменять названия для того, чтобы все было правильно. Это тоже важно понимать заранее, и нужно это все делать. У меня здесь перечислены общие наборы инструментов для разработки, всего этого не коснусь, кроме миникуба.
Minikube — очень хорошая система, в том смысле, что хорошо, что она есть, но плохо, что в таком виде. Она позволяет запускать Kubernetes локально, позволяет видеть все на вашем лэптопе, не надо никуда ходить по SSH и так далее.
Я работаю на MacOS, у меня Mac, соответственно, чтобы запускать локальный апп, мне нужно запускать локально докер. Это сделать никак нельзя. В итоге нужно либо запускать virtualbox, либо xhyve. Обе вещи, фактически, эмуляции поверх моей операционной системы. Мы используем xhyve, но рекомендуем использовать VirtualBox, поскольку очень много багов, их приходится обходить.
Но сама идея, что есть виртуализации, а внутри виртуализации запускается еще один уровень абстракции для виртуализации, какая-то нелепая, бредовая. В целом, хорошо, что он как-то работает, но лучше бы его еще доделали.
CI не относится напрямую к Kubernetes, но это очень важная система, особенно, если у вас есть Kubernetes, если ее интегрировать, можно получать очень хорошие результаты. Мы использовали Concourse для CI, очень богатая функциональность, можно строить страшные графы, что, откуда, как запускается, от чего зависит. Но разработчики Concourse очень странно относятся к своему продукту. Скажем, при переходе от одной версии на другую они поломали обратную совместимость и большинство плагинов не переписали. Более того, документацию не дописали, и, когда мы попытались что-то сделать, вообще ничего не заработало.
Документации мало вообще во всех CI, приходится читать код, и, в общем, мы отказались от Concourse. Перешли на Drone.io — он маленький, очень легкий, юркий, функциональности намного меньше, но чаще всего ее хватает. Да, большие и увесистые графы зависимости — было бы удобно иметь, но и на маленьких тоже можно работать. Тоже мало документации, читаем код, но это ок.
Каждая стадия pipeline работает в своем докер-контейнере, это позволяет сильно упростить переход на Kubernetes. Если есть приложение, которое работает на реальной машине, для того, чтобы добавить в CI, используете докер-контейнер, а после него перейти в Kubernetes проще простого.
У нас настроен автоматический релиз admin/stage-кластера, в продакшн-кластер пока боимся добавлять настройку. Плюс есть система плагинов.
Это пример простого Drone-конфига. Взято из готовой рабочей системы, в данном случае есть пять шагов в pipeline, каждый шаг что-то делает: собирает, тестирует и так далее. При том наборе фич, что есть в Drone, я считаю, что это хорошая штука.
Мы много спорили о том, сколько иметь кластеров: один или несколько. Когда мы пришли к идее с несколькими кластерами, начали дальше работать в этом направлении, создали какие-то скрипты, понаставили кучу других кубиков к нашему Kubernetes. После этого пришли к Google и попросили консультации, все ли сделали так, может, нужно что-то исправить.
Google согласился, что идея одного кластера неприменима в Kubernetes. Есть много недоделок, в частности, работа с геолокациями. Получается, что идея верна, но говорить о ней пока рано. Возможно, попозже. Пока может помочь Service Mesh.
В целом, если хотите посмотреть, как работает наша система, обратите внимание на Geodesic. Это продукт, похожий на тот, что делаем мы. Он с открытыми исходниками, очень похожий выбор концепции дизайна. Мы думаем о том, чтобы объединиться и, возможно, использовать их.
Да, в нашей практике работы с Kubernetes тоже есть проблемы.
Есть боль с локальными именами, с сертификатами. Есть проблема с загрузками больших образов и их работой, возможно, связанная с файловой системой, мы туда еще не копали. Есть уже три разных способа устанавливать расширения Kubernetes. Мы меньше года работаем над этим проектом, и у нас уже три разных способа, годовые кольца растут.
Давайте подобьем все минусы.
Итак, я считаю, что один из главных минусов — большой объем информации на изучение, причем не только новых технологий, но и новых концепций и привычек. Это как новый язык выучить: в принципе, несложно, но сложно немного повернуть голову всем пользователям. Если раньше не работали с подобными концепциями — перейти на Kubernetes тяжело.
Kubernetes будет лишь небольшой частью вашей системы. Все думают, что установят Kubernetes, и всё сразу заработает. Нет, это маленький кубик, и таких кубиков будет много.
Некоторые приложения в принципе сложно запускать на Kubernetes — и лучше не запускать. Также очень тяжелые и большие конфигурационные файлы, и в концепциях поверх Kubernetes они ещё сложнее. Все текущие решения — сырые.
Все эти минусы, конечно, отвратительные.
Компромиссы и сложный переход создают негативный образ Kubernetes, и как с этим бороться — я не знаю. Мы не смогли сильно побороть, есть люди, которые ненавидят все это движение, не хотят и не понимают его плюсы.
Для того, чтобы запустить Minikube, вашу систему, чтобы все работало, придется сильно постараться. Как вы видите, минусов немало, и те, кто не хочет работать с Kubernetes имеют свои причины. Если не хотите слышать про плюсы — закройте глаза и уши, потому что дальше пойдут они.
Первый плюс — с течением времени придется все меньше учить новичков. Часто бывает так, что, придя в систему, новичок начинает вырывать все волосы, потому что первые 1-2 месяца он пытается разобраться, как это все зарелизить, если система большая и живет долго, наросло много годовых колец. В Kubernetes все будет проще.
Во-вторых, Kubernetes не сам делает, но позволяет сделать, короткий цикл релиза. Коммит создал CI, CI создал образ, автоматически подкачался, ты нажал кнопку, и все ушло в продакшн. Это сильно сокращает время релиза.
Следующее — разделение кода. Наша система и большинство ваших систем в одном месте собирают конфиги разных уровней, то есть у вас инфраструктурный код, бизнес код, все логики смешаны в одном месте. В Kubernetes такого не будет из коробки, выбор правильной концепции помогает этого избежать заранее.
Большое и очень активное сообщество, а значит, большое количество изменений. Большинство из того, о чем я упоминал, за последние два года стало настолько стабильным, что их можно выпускать в продакшн. Возможно, часть из них появилась пораньше, но была не очень стабильной.
Я считаю большим плюсом, что в одном месте можно видеть как логи приложения, так и логи работы Kubernetes с вашим приложением, что неоценимо. И нет доступа на ноды. Когда мы убрали у пользователей доступы на ноды, это сразу срезало большой класс проблем.
Вторая часть плюсов немного более концептуальна. Большая часть сообщества Kubernetes видят технологическую часть. Но мы увидели концептуальную менеджмент-часть. После того, как вы перейдете на Kubernetes, и если это все правильно настроить, инфракоманда (или бэкенд — я не знаю, как у вас это называется правильно) больше не нужна для того, чтобы релизить приложения.
Пользователь хочет зарелизить приложение, он не придет с просьбой об этом, а просто запустит новый pod, есть команда для этого. Инфракоманда не нужна для того, чтобы расследовать проблемы. Достаточно посмотреть логи, у нас набор конструкций не такой большой, есть список, по которому найти проблему очень легко. Да, иногда нужна поддержка, если проблема в Kubernetes, в инстансах, но чаще всего проблема с приложениями.
Мы добавили Error Budget. Это следующая концепция: у каждой команды есть статистика, сколько происходит проблем в продакшне. Если проблем происходит слишком много, команде режут релизы, пока не пройдет какое-то время. Это хорошо тем, что команда будет серьезно следить, чтобы их релизы были очень стабильными. Нужна новая функциональность — пожалуйста, релизьте. Хотите релизить в два часа ночи — пожалуйста. Если после релизов у вас в SLA одни «девятки» — делайте, что хотите, все стабильно, можете делать что угодно. Однако, если ситуация хуже, скорее всего, мы не разрешим релизить ничего, кроме фиксов.
Это удобная вещь как для стабильности системы, так и для настроя внутри команды. Мы перестаем быть «Полицией Нравов», не давая релизить поздно вечером. Делайте, что хотите, пока у вас хороший бюджет ошибок. Это сильно сокращает напряжение внутри компании.
Для связи со мной можно использовать почту или написать в Твиттере: @gliush.
И в конце для вас куча ссылок, можете сами всё скачать и посмотреть:
Минутка рекламы. Если вам понравился этот доклад с конференции DevOops — обратите внимание, что 14 октября в Санкт-Петербурге пройдет новый DevOops 2018, в его программе тоже будет много интересного. На сайте уже есть первые спикеры и доклады.