Kubernetes
Kubernetes — это платформа оркестровки контейнеров с открытым исходным кодом, которая автоматизирует развертывание, управление и масштабирование приложений. Узнайте, как Kubernetes обеспечивает экономичную облачную разработку.
Что такое Kubernetes?
Kubernetes — также известный как «k8s» или «kube» — это платформа оркестровки контейнеров для планирования и автоматизации развертывания, управления и масштабирования контейнерных приложений.
Kubernetes был впервые разработан инженерами Google до того, как в 2014 году был запущен открытый исходный код. Он является потомком Borg, платформы оркестровки контейнеров, используемой внутри Google. Kubernetes по-гречески означает «рулевой» или «пилот», отсюда и «штурвал» в логотипе Kubernetes (ссылка находится за пределами csc-ua).
Сегодня Kubernetes и более широкая экосистема контейнеров превращаются в универсальную вычислительную платформу и экосистему, которая конкурирует — если не превосходит — виртуальные машины (ВМ) в качестве основных строительных блоков современной облачной инфраструктуры и приложений. Эта экосистема позволяет организациям предоставлять высокопроизводительную платформу как услугу (PaaS), которая решает множество связанных с инфраструктурой и операциями задач и проблем, связанных с облачной разработкой, чтобы группы разработчиков могли сосредоточиться исключительно на кодировании и инновациях.
Что такое контейнеры?
Давайте начнем с определения: контейнер — это исполняемая единица программного обеспечения, в которой код приложения упакован — вместе с библиотеками и зависимостями — обычным образом, чтобы его можно было запускать где угодно на настольном компьютере, в традиционной ИТ-среде или в облаке.
Контейнеры используют одну из форм виртуализации операционной системы (ОС), которая позволяет нескольким приложениям совместно использовать ОС, изолируя процессы и контролируя объем ЦП, памяти и диска, к которым эти процессы могут получить доступ.
Containers vs. virtual machines vs. traditional infrastructure
Возможно, будет проще или полезнее понять, что контейнеры — это последний этап в непрерывности автоматизации и абстракции ИТ-инфраструктуры.
В традиционной инфраструктуре приложения запускаются на физическом сервере и захватывают все ресурсы, которые могут получить. Это оставляет вам выбор: запускать несколько приложений на одном сервере и надеяться, что одно из них не потребляет ресурсы за счет других, или выделять один сервер для каждого приложения, что тратит ресурсы и не масштабируется.
Виртуальные машины (ВМ) — это серверы, абстрагированные от реального компьютерного оборудования, что позволяет запускать несколько виртуальных машин на одном физическом сервере или на одной виртуальной машине, которая охватывает более одного физического сервера. Каждая виртуальная машина запускает свой собственный экземпляр ОС, и вы можете изолировать каждое приложение в своей собственной виртуальной машине, уменьшая вероятность того, что приложения, работающие на одном и том же базовом физическом оборудовании, будут влиять друг на друга. Виртуальные машины лучше используют ресурсы, их гораздо проще и экономичнее масштабировать, чем традиционную инфраструктуру. И они одноразовые — когда вам больше не нужно запускать приложение, вы отключаете виртуальную машину.
Контейнеры выводят эту абстракцию на более высокий уровень — в частности, помимо совместного использования базового виртуализированного оборудования, они также совместно используют базовое виртуализированное ядро ОС. Контейнеры предлагают такую же изоляцию, масштабируемость и удобство использования виртуальных машин, но поскольку они не несут полезную нагрузку собственного экземпляра ОС, они легче (то есть занимают меньше места), чем виртуальные машины. Они более ресурсоэффективны — они позволяют запускать больше приложений на меньшем количестве машин (виртуальных и физических) с меньшим количеством экземпляров ОС. Контейнеры легче переносить между настольными компьютерами, центрами обработки данных и облачными средами. И они отлично подходят для практик Agile и DevOps разработки.
Что такое Docker?
Docker — самый популярный инструмент для создания и запуска контейнеров Linux®. В то время как ранние формы контейнеров были представлены несколько десятилетий назад (с такими технологиями, как FreeBSD Jails и AIX Workload Partitions), контейнеры были демократизированы в 2013 году, когда Docker представил их в массы с новой удобной для разработчиков и облачной реализацией.
Docker начинался как проект с открытым исходным кодом, но сегодня он также относится к Docker Inc., компании, которая производит Docker — коммерческий контейнерный инструментарий, который основан на проекте с открытым исходным кодом (и вносит эти улучшения обратно в сообщество с открытым исходным кодом).
Docker был построен на основе традиционной технологии контейнеров Linux (LXC), но обеспечивает более детальную виртуализацию процессов ядра Linux и добавляет функции, упрощающие разработчикам создание контейнеров, развертывание, управление и безопасность.
Хотя сегодня существуют альтернативные контейнерные платформы (такие как Open Container Initiative (OCI), CoreOS и Canonical (Ubuntu) LXD), Docker настолько популярен, что фактически является синонимом контейнеров и иногда ошибочно принимается за конкурента дополнительных технологий, таких как Kubernetes (см. Видео «Kubernetes vs Docker ниже).
Оркестровка контейнеров с Kubernetes
По мере распространения контейнеров — сегодня в организации их могут быть сотни или тысячи — операционные группы должны были планировать и автоматизировать развертывание контейнеров, создание сетей, масштабируемость и доступность. Так родился рынок оркестровки контейнеров.
В то время как другие варианты оркестровки контейнеров — в первую очередь Docker Swarm и Apache Mesos — получили некоторую поддержку на раннем этапе, Kubernetes быстро стал наиболее широко распространенным (фактически, в какой-то момент это был самый быстрорастущий проект в истории программного обеспечения с открытым исходным кодом) .
Разработчики выбрали (и продолжают выбирать) Kubernetes из-за его широты функциональности, его обширной и растущей экосистемы инструментов поддержки с открытым исходным кодом, а также его поддержки и переносимости между ведущими облачными провайдерами (некоторые из которых теперь предлагают полностью управляемые сервисы Kubernetes).
Что делает Kubernetes?
Kubernetes планирует и автоматизирует эти и другие задачи, связанные с контейнерами:
- Развертывание: разверните указанное количество контейнеров на указанном хосте и поддерживайте их работу в желаемом состоянии.
- Внедрение: внедрение — это изменение развертывания. Kubernetes позволяет запускать, приостанавливать, возобновлять или откатывать развертывание.
- Обнаружение службы: Kubernetes может автоматически открывать контейнер для Интернета или других контейнеров, используя DNS-имя или IP-адрес.
- Предоставление хранилища: настройте Kubernetes для подключения постоянного локального или облачного хранилища для ваших контейнеров по мере необходимости.
- Балансировка и масштабирование нагрузки: когда трафик к контейнеру резко возрастает, Kubernetes может использовать балансировку и масштабирование нагрузки, чтобы распределить его по сети для поддержания стабильности.
- Самовосстановление для обеспечения высокой доступности: при сбое контейнера Kubernetes может перезапустить или заменить его автоматически; он также может разбирать контейнеры, которые не соответствуют вашим требованиям к проверке здоровья.
Kubernetes vs. Docker
Если вы дочитали до этого места, вы уже понимаете, что, хотя Kubernetes является альтернативой Docker Swarm, он не является (вопреки стойкому распространенному заблуждению) альтернативой или конкурентом самого Docker.
Фактически, если вы с энтузиазмом приняли Docker и создаете крупномасштабные развертывания контейнеров на основе Docker, оркестровка Kubernetes станет следующим логическим шагом для управления этими рабочими нагрузками. Чтобы узнать больше, посмотрите «Kubernetes vs. Docker:
Архитектура Kubernetes
К основным компонентам архитектуры Kubernetes относятся следующие:
Clusters and nodes (compute) | (Кластеры и узлы)
Кластеры — это строительные блоки архитектуры Kubernetes. Кластеры состоят из узлов, каждый из которых представляет собой один вычислительный хост (виртуальную или физическую машину).
Каждый кластер состоит из нескольких рабочих узлов, которые развертывают, запускают и управляют контейнерными приложениями, и одного главного узла, который контролирует и контролирует рабочие узлы.
Главный узел запускает службу планировщика, которая автоматизирует, когда и где развертываются контейнеры, в зависимости от требований к развертыванию, установленных разработчиком, и доступной вычислительной мощности. Каждый рабочий узел включает в себя инструмент, который используется для управления контейнерами, например Docker, и программный агент, называемый Kubelet, который получает и выполняет заказы от главного узла.
Pods and deployments (software) | Модули и развертывания (программное обеспечение)
Pods (поды) — это группы контейнеров, которые используют одни и те же вычислительные ресурсы и одну сеть. Они также являются единицей масштабируемости в Kubernetes: если контейнер в модуле получает больше трафика, чем может обработать, Kubernetes реплицирует модуль на другие узлы кластера. По этой причине рекомендуется сохранять поды компактными, чтобы они содержали только контейнеры, которые должны совместно использовать ресурсы.
Развертывание контролирует создание и состояние контейнерного приложения и поддерживает его работу. Он указывает, сколько реплик модуля должно работать в кластере. В случае сбоя модуля при развертывании будет создан новый.
Сервисная сетка Istio
Kubernetes может развертывать и масштабировать поды, но не может управлять или автоматизировать маршрутизацию между ними и не предоставляет никаких инструментов для мониторинга, защиты или отладки этих подключений. По мере роста количества контейнеров в кластере количество возможных путей соединения между ними увеличивается экспоненциально (например, два контейнера имеют два потенциальных соединения, а 10 модулей — 90), создавая потенциальный кошмар конфигурации и управления.
Откройте для себя Istio, слой сервисной сетки с открытым исходным кодом для кластеров Kubernetes. К каждому кластеру Kubernetes Istio добавляет дополнительный контейнер — по сути невидимый для программиста и администратора — который настраивает, отслеживает и управляет взаимодействиями между другими контейнерами.
С Istio вы устанавливаете единую политику, которая настраивает соединения между контейнерами, так что вам не нужно настраивать каждое соединение отдельно. Это упрощает отладку соединений между контейнерами.
Istio также предоставляет панель мониторинга, которую команды DevOps и администраторы могут использовать для отслеживания задержки, ошибок времени обслуживания и других характеристик соединений между контейнерами. Кроме того, он обеспечивает безопасность — в частности, управление идентификацией, которое не позволяет неавторизованным пользователям подделывать вызов службы между контейнерами, — а также возможности аутентификации, авторизации и аудита (AAA), которые специалисты по безопасности могут использовать для мониторинга кластера.
Knative and serverless computing | Нативные и бессерверные вычисления
Knative (произносится как «kay-native») — это платформа с открытым исходным кодом, которая находится поверх Kubernetes и предоставляет два важных класса преимуществ для облачной разработки:
Knative обеспечивает простой переход к бессерверным вычислениям
Бессерверные вычисления — это относительно новый способ развертывания кода, который делает облачные приложения более эффективными и экономичными. Вместо развертывания текущего экземпляра кода, который простаивает во время ожидания запросов, безсерверный запускает код по мере необходимости — масштабируя его вверх или вниз по мере колебания спроса — а затем отключает код, когда он не используется. Бессерверность предотвращает потерю вычислительной мощности и мощности, а также снижает затраты, поскольку вы платите только за запуск кода, когда он действительно выполняется.
Knative позволяет разработчикам один раз создать контейнер и запустить его как программную службу или как бессерверную функцию. Все это прозрачно для разработчика: Knative обрабатывает детали в фоновом режиме, а разработчик может сосредоточиться на коде.
Knative упрощает разработку и оркестровку контейнеров
Для разработчиков контейнеризация кода требует множества повторяющихся шагов, а оркестровка контейнеров требует большого количества настроек и сценариев (таких как создание файлов конфигурации, установка зависимостей, управление ведением журнала и трассировкой, а также написание скриптов непрерывной интеграции / непрерывного развертывания (CI / CD).)
Knative упрощает эти задачи, автоматизируя их с помощью трех компонентов:
- Сборка: компонент Knative Build автоматически преобразует исходный код в облачный контейнер или функцию. В частности, он извлекает код из репозитория, устанавливает необходимые зависимости, создает образ контейнера и помещает его в реестр контейнеров для использования другими разработчиками. Разработчикам необходимо указать расположение этих компонентов, чтобы Knative мог их найти, но как только это будет сделано, Knative автоматизирует сборку.
- Обслуживание: компонент обслуживания запускает контейнеры как масштабируемые службы; он может масштабироваться до тысяч экземпляров контейнеров или уменьшаться до нуля (это называется масштабированием до нуля). Кроме того, у Serve есть две очень полезных функции:
- Конфигурация, которая сохраняет версии контейнера (называемые моментальными снимками) каждый раз, когда вы запускаете контейнер в производство, и позволяет запускать эти версии одновременно.
- Маршрутизация службы, которая позволяет направлять в эти версии разный объем трафика. Вы можете использовать эти функции вместе для постепенного поэтапного развертывания контейнера или для проведения канареечного тестирования контейнерного приложения перед его запуском в глобальное производство.
- Событие: событие позволяет указанным событиям запускать службы или функции на основе контейнера. Это особенно важно для бессерверных возможностей Knative; что-то должно сказать системе, что нужно вызывать функцию, когда это необходимо. Событие позволяет командам выражать интерес к типам событий, а затем автоматически подключается к источнику событий и направляет события в контейнер, устраняя необходимость в программировании этих подключений.
