Что такое архитектура Kubernetes? Важность + лучшие практики

С 2014 года популярность Kubernetes значительно возросла. Вдохновленный внутренним решением Google для управления кластерами Borg, Kubernetes упрощает развертывание и администрирование ваших приложений. Как и все программное обеспечение для оркестрации контейнеров , Kubernetes становится популярным среди ИТ-специалистов благодаря своей безопасности и простоте. Однако, как и в случае с любым инструментом, понимание того, как его архитектура помогает использовать его более эффективно.

Давайте узнаем об основах архитектуры Kubernetes, начнем с того, что это такое, что он делает и почему он важен.

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

Однако Kubernetes — это не только оркестратор контейнеров . Точно так же настольные приложения работают в MacOS, Windows или Linux; это операционная система для облачных приложений, поскольку она служит облачной платформой для этих программ.

Что такое контейнер?

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

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

Для чего используется Kubernetes?

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

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

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

Kubernetes часто выбирают из-за следующих преимуществ.

• Инфраструктура Kubernetes превосходит многие технологии DevOps.
• Kubernetes разбивает контейнеры на более мелкие компоненты для точного управления.
• Kubernetes быстро и регулярно развертывает обновления программного обеспечения.
• Kubernetes предоставляет платформу для разработки облачных приложений.

Архитектура и компоненты Kubernetes

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

• Базовая архитектура Kubernetes состоит из плоскости управления, которая управляет узлами, и рабочих узлов, которые выполняют контейнерные приложения.
• В то время как плоскость управления управляет выполнением и связью, рабочие узлы фактически запускают эти контейнеры.
• Кластер Kubernetes — это группа узлов, и в каждом кластере есть как минимум один рабочий узел.

Схема архитектуры Kubernetes

Плоскость управления Kubernetes

Плоскость управления — это центр центральной нервной системы конструкции кластера Kubernetes, в котором размещены компоненты управления кластером. Он также записывает конфигурацию и состояние всех объектов Kubernetes в кластере.

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

Плоскость управления состоит из нескольких основных элементов, включая сервер интерфейса прикладного программирования (API), планировщик, диспетчер контроллера и т. д. Эти основные компоненты Kubernetes гарантируют, что контейнеры работают с соответствующими ресурсами. Все эти компоненты могут функционировать на одном первичном узле, но многие компании дублируют их на нескольких узлах для обеспечения высокой доступности.

1. API-сервер Kubernetes

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

2. Планировщик Kubernetes

kube-scheduler записывает статистику использования ресурсов для каждого вычислительного узла, оценивает работоспособность кластера и решает, следует ли развертывать новые контейнеры и где. Планировщик оценивает общее состояние кластера и потребности модуля в ресурсах, таких как центральный процессор (ЦП) или память. Затем он выбирает соответствующий вычислительный узел и планирует задачу, модуль или службу с учетом ограничений или гарантий ресурсов, местоположения данных, требований к качеству обслуживания, анти-аффинити или стандартов сходства.

3. Диспетчер контроллеров Kubernetes

В среде Kubernetes несколько контроллеров управляют состоянием конечных точек (модулей и служб), токенов и учетных записей служб (пространства имен), узлов и репликации (автоматическое масштабирование). Диспетчер kube-controller, часто называемый диспетчером облачного контроллера или просто контроллером, представляет собой демон, который управляет кластером Kubernetes, выполняя различные обязанности контроллера.

Контроллер отслеживает объекты в кластере во время выполнения основных циклов управления Kubernetes. Он отслеживает их желаемое и существующее состояние через сервер API. Если текущее и предполагаемое состояния управляемых объектов не совпадают, контроллер предпринимает корректирующие действия, чтобы приблизить состояние объекта к желаемому состоянию. Контроллер Kubernetes также выполняет важные задачи жизненного цикла.

4. и т. д.

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

Алгоритм консенсуса плота используется для сохранения состояния кластера в etcd. Это помогает справиться с типичной проблемой в контексте реплицированных конечных автоматов и требует, чтобы многие серверы согласовывали значения. Raft устанавливает три роли: лидера, кандидата и последователя и создает консенсус путем голосования за лидера.

В результате etcd является единым источником достоверной информации (SSOT) для всех компонентов кластера Kubernetes, отвечающим на запросы плоскости управления и собирающим различную информацию о состоянии контейнеров, узлов и модулей. etcd также используется для хранения информации о конфигурации, такой как ConfigMap, подсети, секреты и данные о состоянии кластера.

Рабочие узлы Kubernetes

Рабочие узлы — это системы, на которых запущены контейнеры, которыми управляет плоскость управления. kubelet — основной контроллер Kubernetes — работает на каждом узле в качестве агента для взаимодействия с плоскостью управления. Кроме того, на каждом узле работает механизм выполнения контейнера, например Docker или rkt. Другие компоненты для мониторинга, ведения журнала, обнаружения служб и дополнительные функции также выполняются на узле.

Вот некоторые ключевые компоненты кластерной архитектуры Kubernetes.

Узлы

В кластере Kubernetes должен быть хотя бы один вычислительный узел, но их может быть и больше в зависимости от требований к емкости. Поскольку модули скоординированы и запланированы для выполнения на узлах, для увеличения емкости кластера требуются дополнительные узлы. Узлы выполняют работу кластера Kubernetes. Они связывают приложения, а также сетевые ресурсы, вычислительные ресурсы и ресурсы хранения.

Узлы в центрах обработки данных могут быть облачными виртуальными машинами (ВМ) или серверами без ПО.

Механизм выполнения контейнера

Каждый вычислительный узел использует механизм выполнения контейнера для работы и управления жизненными циклами контейнера. Kubernetes поддерживает среды выполнения, соответствующие инициативе открытых контейнеров, такие как Docker, CRI-O и rkt.

Кубелет сервис

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

Kube-прокси сервис

Каждый вычислительный узел имеет сетевой прокси-сервер, известный как kube-proxy, который помогает сетевым службам Kubernetes. Для управления сетевыми соединениями внутри и вне кластера kube-proxy либо перенаправляет трафик, либо зависит от уровня фильтрации пакетов операционной системы.

Процесс kube-proxy работает на каждом узле, чтобы обеспечить доступность служб для других сторон и справиться с определенными подсетями хоста. Он действует как сетевой прокси и балансировщик нагрузки службы на своем узле, обрабатывая сетевую маршрутизацию для трафика протокола пользовательских дейтаграмм (UDP) и протокола управления передачей (TCP). На самом деле kube-proxy направляет трафик для всех конечных точек службы.

стручки

До сих пор мы рассмотрели внутренние идеи и идеи, связанные с инфраструктурой. Поды, однако, имеют решающее значение для Kubernetes, поскольку они являются основными внешними компонентами, с которыми взаимодействуют разработчики.

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

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

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

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

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

Другие компоненты архитектуры Kubernetes

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

Том Kubernetes — это каталог, в котором модуль может получать доступ и хранить данные. Тип тома определяет содержимое тома, его происхождение и носитель, который его поддерживает. Постоянные тома (PV) — это ресурсы хранения для конкретного кластера, которые часто предоставляются администратором. PV также могут пережить данный модуль.

Kubernetes зависит от образов контейнеров , которые хранятся в реестре контейнеров . Это может быть сторонний реестр или реестр, созданный организацией.

Пространства имен — это виртуальные кластеры, существующие внутри физического кластера. Они предназначены для создания независимых рабочих сред для многочисленных пользователей и групп. Они также не позволяют командам мешать друг другу, ограничивая объекты Kubernetes, к которым они могут получить доступ. Контейнеры Kubernetes внутри модуля могут взаимодействовать с другими модулями через локальный хост и совместно использовать IP-адреса и сетевые пространства имен.

Kubernetes против Docker Swarm

И Kubernetes, и Docker — это платформы, обеспечивающие управление контейнерами и масштабирование приложений. Kubernetes предоставляет эффективное решение для управления контейнерами, идеально подходящее для приложений с высокими требованиями и сложной настройкой. Напротив, Docker Swarm создан для простоты, что делает его отличным выбором для важных приложений, которые быстро развертываются и обслуживаются.

• Docker Swarm легче развернуть и настроить, чем Kubernetes.
• Kubernetes обеспечивает комплексную масштабируемость на основе трафика, тогда как Docker Swarm отдает приоритет быстрому масштабированию.
• Автоматическая балансировка нагрузки доступна в Docker Swarm, но не в Kubernetes. Однако сторонние решения могут связать внешний балансировщик нагрузки с Kubernetes.

Требования вашей компании определяют правильный инструмент.

Решения для оркестрации контейнеров

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

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

Лучшие практики архитектуры Kubernetes и принципы проектирования

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

• Убедитесь, что у вас всегда самая последняя версия Kubernetes.
• Инвестируйте в обучение команд разработки и эксплуатации.
• Установите общекорпоративное управление . Убедитесь, что ваши инструменты и поставщики совместимы с оркестровкой Kubernetes.
• Повысьте безопасность , включив методы сканирования изображений в рабочий процесс непрерывной интеграции и доставки (CI/CD). К открытому исходному коду, загруженному из репозитория GitHub, всегда следует относиться с осторожностью.
• Внедрите управление доступом на основе ролей (RBAC) во всем кластере. Модели, основанные на минимальных привилегиях и нулевом доверии, должны стать нормой.
• Используйте только пользователей без полномочий root и сделайте файловую систему доступной только для чтения для дополнительной защиты контейнеров.
• Избегайте значений по умолчанию, поскольку простые объявления менее подвержены ошибкам и лучше сообщают о цели.
• Будьте осторожны при использовании базовых образов Docker Hub, поскольку они могут содержать вредоносное ПО или быть раздутыми ненужным кодом. Начните с простого, чистого кода и продвигайтесь вверх. Изображения меньшего размера растут быстрее, занимают меньше места в хранилище и загружаются быстрее.
• Держите контейнеры максимально простыми . Один процесс на контейнер позволяет оркестратору сообщать, является ли этот процесс работоспособным.
• Сбой , когда есть сомнения. Не перезапускайте при сбое, так как Kubernetes перезапустит сбойный контейнер.
• Будьте описательными . Описательные ярлыки приносят пользу нынешним и будущим разработчикам.
• Когда дело доходит до микросервисов, не будьте слишком конкретны . Каждая функция в компоненте логического кода не должна быть его микросервисом.
• По возможности автоматизировать . Вы можете полностью отказаться от ручного развертывания Kubernetes, автоматизировав рабочий процесс CI/CD.
• Используйте зонды живости и готовности, чтобы помочь в управлении жизненными циклами модулей ; в противном случае поды могут быть остановлены во время инициализации или получения пользовательских запросов до того, как они будут готовы.

Рассмотрите свои контейнеры

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

Заинтригованы, чтобы изучить тему больше? Узнайте о растущей актуальности контейнеризации в облачных вычислениях!