TOC

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

1. Обзор

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

  • Необходим инструмент для оркестровки контейнера

  • Особенности Kubernetes

  • Kubernetes архитектура

  • Kubernetes API

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

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

В этой ссылке:/dockerizing-spring-boot-application[предыдущая статья]мы уже обсуждали некоторые основы Docker, а также способы упаковки и развертывания пользовательских приложений.

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

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

На рынке доступно довольно много инструментов. Тем не менее, Kubernetes становится все более и более существенным конкурентом.

3. Особенности Kubernetes

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

  • Планирование ресурсов: это гарантирует, что Pods распределены оптимально

по всем доступным узлам ** Автоматическое масштабирование: при увеличении нагрузки кластер может динамически

выделить дополнительные узлы и развернуть на них новые Pods ** Самовосстановление: кластер контролирует контейнеры и перезапускает их, если

требуется, на основе определенных политик ** Обнаружение службы: Pods и Services зарегистрированы и опубликованы

через DNS ** Скользящие обновления/откаты: поддерживает прокручиваемые обновления на основе

последовательное перемещение контейнеров и контейнеров ** Секрет/управление конфигурацией: поддерживает безопасную обработку конфиденциальных

данные, такие как пароли или ключи API ** Хранение оркестровки: несколько сторонних решений хранения

поддерживается, который может использоваться как внешние тома для сохранения данных

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

_ Master поддерживает желаемое состояние кластера. Когда мы взаимодействуем с нашим кластером, e. г. используя интерфейс командной строки kubectl_ , мы всегда общаемся с хозяином нашего кластера.

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

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

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

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

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

5. Объекты API Kubernetes

  • Объект API - это «запись намерений» ** - как только мы создадим объект, система кластеров будет непрерывно работать, чтобы гарантировать, что объект существует.

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

В следующем разделе мы обсудим наиболее важные объекты.

После этого мы рассмотрим пример того, как спецификация и статус выглядят в реальности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязательные атрибуты:

  • Каждый объект должен иметь Пространство имен (мы уже обсуждали, что

до). Если не указано явно, объект принадлежит пространству имен default .

  • A Name - это уникальный идентификатор объекта в его пространстве имен.

  • A Uid - это уникальное во времени и пространстве значение. Это помогает отличить

между объектами, которые были удалены и воссозданы.

Есть также дополнительные атрибуты метаданных. Вот некоторые из наиболее важных:

  • Метки - это пары ключ/значение, которые можно прикрепить к объектам

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

  • Селекторы меток помогают нам идентифицировать набор объектов по их

этикетки.

  • Аннотации также являются парами ключ/значение. В отличие от этикеток, они

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

5.4. Пример

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

Объекты 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 ) ** template: указывает один Pod

  • В этом Pod, мы можем использовать spec: container: , чтобы назначить один или

больше контейнеров для нашего Pod. В этом случае у нас есть один контейнер с именем demo-backend , который создается из изображения, также называемого demo-backend , версия latest , и он слушает порт 8080 ** Мы также прикрепляем labels к нашему модулю: app: demo-backend и __tier:

backend ** С selector: matchLabels: мы связываем наш Pod с Deployment__

контроллер (отображение на ярлыки 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 может быть самым простым выбором: он позволяет нам запускать кластер с одним узлом на локальной рабочей станции для разработки и тестирования . **

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

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

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

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

  • Почему нам может понадобиться инструмент оркестровки контейнера

  • Некоторые из наиболее важных особенностей Kubernetes

  • Kubernetes архитектура и ее наиболее важные компоненты

  • Kubernetes API и как мы можем использовать его, чтобы указать желаемое состояние

наш кластер

Related