Обзор

На этой странице представлен обзор Kubernetes.

Название Kubernetes происходит из греческого языка и означает рулевого или штурмана. В сокращении K8s цифра 8 обозначает восемь букв между "K" и "s". Google открыл исходный код проекта Kubernetes в 2014 году. Kubernetes объединяет более чем 15-летний опыт Google по запуску рабочих нагрузок в production с лучшими идеями и практиками сообщества.

Зачем нужен Kubernetes и что он умеет

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

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

Возможности Kubernetes:

• Обнаружение сервисов и балансировка нагрузки Kubernetes может предоставить доступ к контейнеру по DNS-имени или по его собственному IP-адресу. Если трафик к контейнеру велик, Kubernetes может сбалансировать нагрузку и распределить сетевой трафик так, чтобы развертывание оставалось стабильным.
• Оркестрация хранилища Kubernetes позволяет автоматически подключать выбранную систему хранения: локальное хранилище, хранилища публичных облачных провайдеров и другие варианты.
• Автоматизированные развертывания и откаты С помощью Kubernetes можно описать желаемое состояние развернутых контейнеров, а он будет постепенно приводить фактическое состояние к желаемому. Например, можно автоматизировать создание новых контейнеров для развертывания, удаление существующих контейнеров и перенос их ресурсов на новые контейнеры.
• Автоматическое размещение Вы предоставляете Kubernetes кластер узлов для запуска контейнеризованных задач и указываете, сколько CPU и памяти (RAM) нужно каждому контейнеру. Kubernetes размещает контейнеры на узлах так, чтобы ресурсы использовались эффективнее.
• Самовосстановление Kubernetes перезапускает отказавшие контейнеры, заменяет их, останавливает контейнеры, которые не проходят заданные пользователем проверки работоспособности, и не направляет к ним клиентов, пока контейнеры не будут готовы обслуживать запросы.
• Управление секретами и конфигурацией Kubernetes позволяет хранить секреты, например пароли, OAuth-токены и SSH-ключи, и управлять ими. Секреты и конфигурацию приложений можно развертывать и обновлять без пересборки образов контейнеров и без раскрытия секретов в конфигурации стека.
• Пакетное выполнение Помимо сервисов, Kubernetes может управлять пакетными задачами и нагрузками CI, при необходимости заменяя отказавшие контейнеры.
• Горизонтальное масштабирование Увеличивайте и уменьшайте масштаб приложения простой командой, через пользовательский интерфейс или автоматически на основе использования CPU.
• Двойной стек IPv4/IPv6 Выделение IPv4- и IPv6-адресов для подов и сервисов.
• Расширяемость В кластер Kubernetes можно добавлять возможности, не меняя исходный код основного проекта.

Чем Kubernetes не является

Kubernetes — это не традиционная комплексная PaaS-система (Platform as a Service). Поскольку Kubernetes работает на уровне контейнеров, а не на уровне оборудования, он предоставляет некоторые общие возможности, характерные для PaaS: развертывание, масштабирование и балансировку нагрузки, а также позволяет пользователям интегрировать собственные решения для журналирования, мониторинга и оповещений. При этом Kubernetes не монолитен, а такие решения по умолчанию необязательны и подключаемы. Kubernetes предоставляет базовые компоненты для создания платформ разработчика, сохраняя выбор и гибкость там, где это важно.

Kubernetes:

• Не ограничивает типы поддерживаемых приложений. Kubernetes стремится поддерживать максимальный спектр рабочих нагрузок: без состояния, с состоянием и связанные с обработкой данных. Если приложение может работать в контейнере, оно должно хорошо работать и в Kubernetes.
• Не развертывает исходный код и не собирает приложение. Рабочие процессы непрерывной интеграции, доставки и развертывания (CI/CD) определяются культурой и предпочтениями организации, а также техническими требованиями.
• Не предоставляет встроенные сервисы уровня приложения, такие как промежуточное программное обеспечение (например, шины сообщений), платформы обработки данных (например, Spark), базы данных (например, MySQL), кеши или кластерные системы хранения (например, Ceph). Такие компоненты могут работать в Kubernetes и/или быть доступны приложениям, которые работают в Kubernetes, через переносимые механизмы, такие как Open Service Broker.
• Не навязывает решения для журналирования, мониторинга или оповещений. Kubernetes предоставляет отдельные интеграции как примеры и механизмы для сбора и экспорта метрик.
• Не предоставляет и не требует языка или системы конфигурации (например, Jsonnet). Вместо этого он предоставляет декларативный API, к которому можно обращаться с помощью разных форм декларативных спецификаций.
• Не предоставляет и не берет на себя роль комплексной системы настройки, обслуживания, управления или самовосстановления машин.
• Кроме того, Kubernetes — это не просто система оркестрации. Фактически он устраняет потребность в оркестрации. В техническом смысле оркестрация — это выполнение заданного рабочего процесса: сначала A, затем B, затем C. Kubernetes, напротив, состоит из набора независимых компонуемых процессов управления, которые непрерывно приводят текущее состояние к желаемому. Не важно, как система переходит от A к C. Централизованное управление тоже не требуется. В результате систему проще использовать, и она становится мощнее, надежнее, устойчивее и расширяемее.

Исторический контекст Kubernetes

Давайте вернемся назад и посмотрим, почему Kubernetes так полезен.

Эра традиционного развертывания:

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

Эра виртуализированного развертывания:

Решением стала виртуализация. Она позволяет запускать несколько виртуальных машин (VM) на CPU одного физического сервера. Виртуализация изолирует приложения между VM и обеспечивает определенный уровень безопасности: данные одного приложения не могут быть свободно доступны другому.

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

Каждая VM — это полноценная машина, в которой поверх виртуализированного оборудования работают все компоненты, включая собственную операционную систему.

Эра контейнерного развертывания:

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

Контейнеры стали популярными, потому что дают дополнительные преимущества:

• Гибкое создание и развертывание приложений: создавать образы контейнеров проще и эффективнее, чем использовать образы VM.
• Непрерывная разработка, интеграция и развертывание: надежная и частая сборка и развертывание образов контейнеров с быстрыми и эффективными откатами благодаря неизменяемости образов.
• Разделение зон ответственности Dev и Ops: образы контейнеров приложений создаются во время сборки или выпуска, а не во время развертывания, что отделяет приложения от инфраструктуры.
• Наблюдаемость: доступны не только информация и метрики уровня ОС, но и состояние приложений и другие сигналы.
• Единое окружение в разработке, тестировании и промышленной эксплуатации: приложение работает на ноутбуке так же, как в облаке.
• Переносимость между облаками и дистрибутивами ОС: запуск на Ubuntu, RHEL, CoreOS, в собственной инфраструктуре, в крупных публичных облаках и в других средах.
• Управление с фокусом на приложение: уровень абстракции смещается от запуска ОС на виртуальном оборудовании к запуску приложения в ОС с использованием логических ресурсов.
• Слабосвязанные, распределенные, эластичные и независимые микросервисы: приложения разделяются на небольшие независимые части, которые можно динамически развертывать и которыми можно управлять, вместо монолитного стека на одной большой специализированной машине.
• Изоляция ресурсов: предсказуемая производительность приложений.
• Использование ресурсов: высокая эффективность и плотность размещения.

Что дальше

• Изучите Компоненты Kubernetes
• Изучите API Kubernetes
• Познакомьтесь с kubectl: основным CLI для Kubernetes
• Изучите Архитектуру кластера
• Готовы начать?