Введение в Кубернет

1. Обзор

В этом уроке у нас будет краткое теоретическое введение в Kubernetes. В частности, мы обсудим следующие темы:

• Необходимость в инструменте оркестрации контейнеров
• Возможности Кубернета
• Архитектура Кубернета
• Кубернетес API

Для более глубокого понимания мы также можем взглянуть на официальную документацию .

2. Контейнерная оркестровка

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

В двух словах, Docker — это среда выполнения контейнера: она предоставляет функции для упаковки, доставки и запуска отдельных экземпляров приложения стандартизированным способом, также известным как контейнер.

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

Инструментов на рынке довольно много. Однако Kubernetes все больше и больше становится серьезным конкурентом.

3. Возможности Kubernetes

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

• Планирование ресурсов: гарантирует оптимальное распределение модулей по всем доступным узлам .
• Автомасштабирование: при увеличении нагрузки кластер может динамически выделять дополнительные узлы и развертывать на них новые поды .
• Самовосстановление: кластер контролирует контейнеры и при необходимости перезапускает их на основе определенных политик.
• Обнаружение службы: модули и службы регистрируются и публикуются через DNS .
• Последовательные обновления/откаты: поддерживает последовательные обновления на основе последовательного повторного развертывания модулей и контейнеров.
• Управление секретами/конфигурацией: поддерживает безопасную обработку конфиденциальных данных, таких как пароли или ключи API.
• Оркестрация хранилища: поддерживаются несколько сторонних решений для хранения, которые можно использовать в качестве внешних томов для хранения данных.

4. Понимание Kubernetes

Мастер поддерживает желаемое состояние кластера. Когда мы взаимодействуем с нашим кластером, например, используя интерфейс командной строки kubectl , мы всегда взаимодействуем с мастером нашего кластера.

Узлы в кластере — это машины (виртуальные машины, физические серверы и т. д.), на которых выполняются наши приложения. Мастер контролирует каждый узел.

Узлу требуется среда выполнения контейнера . Docker — это наиболее распространенная среда выполнения, используемая в Kubernetes.

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

API Kubernetes обеспечивает абстракцию концепций Kubernetes, заключая их в объекты (мы рассмотрим их в следующем разделе).

kubectl — это инструмент командной строки, мы можем использовать его для создания, обновления, удаления и проверки этих объектов API.

5. Объекты API Kubernetes

Объект API — это «запись о намерениях» : как только мы создадим объект, кластерная система будет постоянно работать, чтобы убедиться, что объект существует.

Каждый объект состоит из двух частей: спецификации объекта и статуса объекта. Спецификация описывает желаемое состояние объекта. Статус описывает фактическое состояние объекта и предоставляется и обновляется кластером.

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

5.1. Основные объекты

Pod — это базовая единица, с которой работает Kubernetes. Он инкапсулирует один или несколько тесно связанных контейнеров, ресурсов хранения, уникальный сетевой IP-адрес и конфигурации того, как должны работать контейнеры, и, таким образом, представляет собой один экземпляр приложения.

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

Используя Volumes , контейнеры могут получать доступ к ресурсам внешнего хранилища (поскольку их файловая система эфемерна), а также читать файлы или хранить их постоянно. Тома также поддерживают совместное использование файлов между контейнерами. Поддерживается длинный список типов томов .

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

5.2. Контроллеры

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

Контроллер развертывания предоставляет декларативные обновления для модулей Pod и наборов реплик. Мы описываем желаемое состояние в объекте Deployment, а контроллер Deployment меняет фактическое состояние на желаемое.

ReplicaSet гарантирует , что указанное количество реплик Pod будет запущено в любой момент времени.

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

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

GarbageCollection обеспечивает удаление определенных объектов, которые когда-то имели владельца, но больше не имеют его . Это помогает экономить ресурсы, удаляя объекты, которые больше не нужны.

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

5.3. Метаданные объекта

Метаданные — это атрибуты, предоставляющие дополнительную информацию об объектах.

Обязательными атрибутами являются:

• У каждого объекта должно быть пространство имен (мы уже обсуждали это ранее). Если это не указано явно, объект принадлежит пространству имен по умолчанию .
• Имя — это уникальный идентификатор объекта в его пространстве имен .
• Uid — это значение, уникальное во времени и пространстве. Это помогает различать объекты, которые были удалены и созданы заново.

Существуют также необязательные атрибуты метаданных. Вот некоторые из наиболее важных:

• Метки — это пары ключ/значение, которые можно прикреплять к объектам для их классификации. Это помогает нам идентифицировать набор объектов, которые удовлетворяют определенному условию. Они помогают нам отображать наши организационные структуры на объектах слабо связанным образом.
• Селекторы меток помогают нам идентифицировать набор объектов по их меткам.
• Аннотации также являются парами ключ/значение. В отличие от меток они не используются для идентификации объектов. Вместо этого они могут хранить информацию о соответствующем объекте, например информацию о сборке, выпуске или образе.

5.4. Пример

После теоретического обсуждения Kubernetes API мы теперь рассмотрим пример.

Объекты API могут быть указаны в виде файлов JSON или YAML. Однако документация рекомендует YAML для ручной настройки.

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

Спецификация приложения под названием demo-backend может выглядеть так:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-backend
spec:
  selector:
      matchLabels:
        app: demo-backend
        tier: backend
  replicas: 3
  template:
    metadata:
      labels:
        app: demo-backend
        tier: backend
    spec:
      containers:
        - name: demo-backend
          image: demo-backend:latest
          ports:
            - containerPort: 8080

Как мы видим, мы указываем объект Deployment , который называется demo-backend . Приведенная ниже часть spec: на самом деле является вложенной структурой и содержит следующие объекты API, обсуждавшиеся в предыдущих разделах:

• replicas: 3 указывает ReplicationSet с коэффициентом репликации 3 (т.е. у нас будет три экземпляра Deployment )
• шаблон: указывает один Pod
• Внутри этого пода мы можем использовать spec:Containers: для назначения одного или нескольких контейнеров нашему поду. В этом случае у нас есть один контейнер с именем demo-backend , экземпляр которого создается из образа, также называемого demo-backend , последней версии , и он прослушивает порт 8080 .
• Также прикрепляем к нашему поду метки : app: demo-backend и tier: backend
• С помощью селектора: matchLabels: мы связываем наш модуль с контроллером развертывания (сопоставление с метками app: demo-backend и tier: backend ) .

Если мы запросим состояние нашего Deployment из кластера, ответ будет выглядеть примерно так:

Name:                   demo-backend
Namespace:              default
CreationTimestamp:      Thu, 22 Mar 2018 18:58:32 +0100
Labels:                 app=demo-backend
Annotations:            deployment.kubernetes.io/revision=1
Selector:               app=demo-backend
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=demo-backend
  Containers:
   demo-backend:
    Image:        demo-backend:latest
    Port:         8080/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   demo-backend-54d955ccf (3/3 replicas created)
Events:          <none>

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

У нас есть развертывание с коэффициентом репликации, равным 3, с одним подом, содержащим один контейнер, созданный из образа demo-backend:latest .

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

6. Начало работы с Kubernetes

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

Для начала Minikube может быть самым простым выбором: он позволяет нам запустить кластер с одним узлом на локальной рабочей станции для разработки и тестирования.

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

7. Заключение

В этой статье мы кратко рассмотрели некоторые основы Kubernetes.

Проще говоря, мы рассмотрели следующие аспекты:

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