Kubernetes для ИТ-специалистов: компоненты и строительные блоки

Мир меняется, и если вы все еще работаете только с IaaS (инфраструктура как услуга), вы упускаете много новых вещей, таких как PaaS (платформа как услуга) и настоящую революцию. по разработке приложений — микросервисы. Если вы не хотите стать последним стрелком (мне пришлось сослаться на «Темную башню» Стивена Кинга) и отстать от мира, который ушел в прошлое, пришло время освежить свои навыки и посмотреть, как новые приложения разрабатываются и настраиваются как контейнеры в облачную эпоху. И хорошей стартовой площадкой в любом обсуждении Kubernetes для ИТ-специалистов являются компоненты, составляющие архитектуру.

Мы рассмотрели Docker и контейнеры в некоторых из моих предыдущих статей на TechGenix. Вот их список, чтобы дать вам представление о том, откуда мы пришли, и они зададут тон этой статье:

• Начало работы с контейнерами
• Контейнеры Windows Server
• Создание образов Docker
• Использование Dockerfile для создания образов Docker

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

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

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

Kubernetes для ИТ-специалистов: общий обзор

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

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

Описать весь Kubernetes в одной статье было бы невозможно. Цель этой статьи — показать высокоуровневую архитектуру продукта и некоторые основные концепции. Если вам интересно, сообщество использует Kubernetes.io в качестве источника всей документации по продукту, и это отличная отправная точка для изучения Kubernetes!

Высокоуровневая архитектура Kubernetes

В Kubernetes есть две разные роли: master и worker. Мы можем (и должны) иметь более одного сервера для каждой роли, чтобы обеспечить высокую доступность и избыточность. На следующей диаграмме (извините за некоторые значки, мой набор элементов Visio содержит только объекты Azure) показаны роли и взаимодействие между главной и рабочей ролями.

Главная роль — это мозг операции, и она состоит из четырех компонентов: API-сервера, планировщика, etcd и диспетчера контроллеров.

• Сервер API (Kube-apiserver): это связь с общественностью Kubernetes. Подавляющее большинство ролей Kubernetes взаимодействуют с серверами API. Этот компонент доступен из инструментов управления (kubectl) и аналогичен концепции Azure Resource Manager (ARM) для администраторов Azure.
• Планировщик (Kube-scheduler): Логистическая роль. Каждый раз, когда запрашивается новое приложение или запрос, эта роль будет выбирать, какие узлы будут выполнять это действие, основываясь на встроенной в роль логике.
• etcd: это база данных (хранилище пар ключей), содержащая всю информацию о рабочих нагрузках, объявленных для кластера Kubernetes.
• Диспетчер контроллеров (Kube-controller-manager): серия небольших контроллеров, которые всегда запущены и выполняют действия, чтобы убедиться, что мы близки к желаемому состоянию кластера.

Другая роль в нашей истории — роль узла. Это роль, в которой выполняется работа, а это означает, что ваши будущие контейнерные приложения будут работать в роли узла. Роль узла состоит из трех компонентов: kubelet, прокси и среды выполнения контейнера.

• Kubelet: это агент Kubernetes, который взаимодействует с сервером API, чтобы предоставить информацию и статус о его работоспособности и получить задания для выполнения.
• Прокси (Kube-proxy): отвечает за сетевую маршрутизацию и IP-адреса, которые назначаются модулям и службам.
• Среда выполнения контейнера: это соединение с контейнерным решением на узле. В будущем мы будем использовать Docker.

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

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

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

Kubernetes и высокая доступность

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

Цель этого раздела — показать, как простая высокая доступность ролей будет работать для обеспечения отказоустойчивости.

Мы должны начать как минимум с трех серверов, где пять серверов могут быть оптимальным решением, чтобы допустить два сбоя оборудования, не влияя на окружающую среду. (Эта математика основана на компоненте etcd.)

Сервер API будет активен во всех экземплярах, и единственное требование — наличие перед ним балансировщика нагрузки. Роль сервера API не имеет состояния. Поэтому компоненты и агенты узла Kubernetes могут в любой момент времени взаимодействовать с любым сервером.

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

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

Kubernetes для ИТ-специалистов: есть о чем поговорить

Мы будем делать больше в Kubernetes для ИТ-специалистов, так что следите за обновлениями на TechGenix!