1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/AliyunContainerService-swarmkit

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

SwarmKit — это набор инструментов для управления распределёнными системами любого масштаба. Он включает в себя примитивы для обнаружения узлов, консенсуса на основе Raft, планирования задач и многого другого.

Основные преимущества:

  • Распределённость: SwarmKit использует алгоритм консенсуса Raft для координации и не полагается на единую точку отказа для принятия решений.
  • Безопасность: связь между узлами и членство в Swarm по умолчанию безопасны. SwarmKit применяет взаимный TLS для аутентификации узлов, авторизации ролей и шифрования транспорта, автоматизируя выдачу и ротацию сертификатов.
  • Простота: SwarmKit прост в эксплуатации и минимизирует зависимости от инфраструктуры. Для работы ему не нужна внешняя база данных.

Обзор

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

  • Рабочие узлы отвечают за выполнение задач с помощью исполнителя. SwarmKit поставляется со стандартным исполнителем контейнеров Docker, который можно легко заменить.
  • Управляющие узлы, напротив, принимают спецификации от пользователя и отвечают за согласование желаемого состояния с фактическим состоянием кластера. Оператор может динамически обновлять роль узла, повышая рабочего до управляющего или понижая управляющего до рабочего. Задачи организованы в сервисы. Сервис — это более высокий уровень абстракции, позволяющий пользователю объявить желаемое состояние группы задач. Сервисы определяют тип задачи, которую следует создать, как её выполнять (например, всегда запускать определённое количество реплик) и как обновлять (например, постепенные обновления).

Функции

Некоторые из основных функций SwarmKit:

  • Оркестровка:
    • Согласование желаемого состояния: SwarmKit постоянно сравнивает желаемое состояние с текущим состоянием кластера и при необходимости согласовывает их. Например, если узел выходит из строя, SwarmKit перепланирует его задачи на другой узел.
    • Типы сервисов: в проекте есть два типа сервисов. В настоящее время проект поставляется с двумя из них:
      • Реплицированные сервисы масштабируются до желаемого количества реплик.
      • Глобальные сервисы запускают одну задачу на каждом доступном узле в кластере.
    • Настраиваемые обновления: в любое время вы можете изменить значение одного или нескольких полей для сервиса. После внесения изменений SwarmKit согласовывает желаемое состояние, обеспечивая использование всеми задачами желаемых настроек. По умолчанию он выполняет пошаговое обновление — все задачи обновляются одновременно. Это можно настроить с помощью различных параметров:
      • Параллелизм определяет, сколько обновлений можно выполнить одновременно.
      • Задержка устанавливает минимальную задержку между обновлениями. SwarmKit сначала завершает предыдущую задачу, запускает новую, ждёт, пока она перейдёт в состояние «РАБОТАЕТ», затем ждёт настроенной задержки. Наконец, он переходит к другим задачам.
    • Политики перезапуска: уровень оркестровки отслеживает задачи и реагирует на сбои в соответствии с указанной политикой. Оператор может определить условия перезапуска, задержки и ограничения (максимальное количество попыток в заданном временном окне). SwarmKit может решить перезапустить задачу на другом компьютере. Это означает, что неисправные узлы будут... Постепенно задачи будут распределяться по-другому.

Планирование

  • Осведомлённость о ресурсах: SwarmKit знает о доступных ресурсах на узлах и будет размещать задачи соответствующим образом.

  • Ограничения: Операторы могут ограничить набор узлов, где может быть запланирована задача, определяя выражения ограничений. Несколько ограничений находят узлы, которые удовлетворяют каждому выражению, то есть соответствуют условию «И». Ограничения могут соответствовать атрибутам узла в следующей таблице. Обратите внимание, что engine.labels собираются из Docker Engine с информацией, такой как операционная система, драйверы и т. д. node.labels добавляются администраторами кластера для операционных целей. Например, некоторые узлы имеют метки соответствия требованиям безопасности для выполнения задач с соответствующими требованиями. | Атрибут узла | Совпадения | Пример | |:------------- |:-------------| :-------------| | node.id | Идентификатор узла | node.id == 2ivku8v2gvtg4| | node.hostname | Имя хоста узла | node.hostname != node-2| | node.ip | IP-адрес узла | node.ip != 172.19.17.0/24| | node.role | Роль менеджера или рабочего узла | node.role == manager| | node.platform.os | Операционная система узла | node.platform.os == linux| | node.platform.arch | Архитектура узла | node.platform.arch == x86_64| | node.labels | Метки узла, добавленные администраторами кластера | node.labels.security == high| | engine.labels | Метки Docker Engine | engine.labels.operatingsystem == ubuntu 14.04|

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

Управление кластером

  • Хранилище состояний: Управляющие узлы поддерживают строго согласованное, реплицированное (на основе Raft) и чрезвычайно быстрое (чтение из памяти) представление о кластере, которое позволяет им быстро принимать решения о планировании, допуская сбои.
  • Управление топологией: Роли узлов (Worker / Manager) можно динамически изменять через вызовы API/CLI.
  • Управление узлами: Оператор может изменить желаемую доступность узла: установка его в Приостановленное состояние предотвратит планирование дальнейших задач на нём, а Осушение будет иметь тот же эффект, но также переназначит его задачи куда-то ещё (в основном для сценариев обслуживания).

Безопасность

  • Взаимный TLS: Все узлы взаимодействуют друг с другом, используя взаимный TLS. Менеджеры Swarm действуют как корневой центр сертификации, выдавая сертификаты новым узлам.
  • Присоединение на основе токенов: Всем узлам требуется криптографический токен для присоединения к рою, который определяет роль этого узла. Токены можно менять так часто, как это необходимо, не затрагивая уже присоединённые узлы.
  • Ротация сертификатов: Сертификаты TLS прозрачно вращаются и перезагружаются на каждом узле, позволяя пользователю установить, как часто должна происходить ротация (текущий дефолт — 3 месяца, минимум — 30 минут).

Сборка

Требования:

  • Go 1.6 или выше
  • Рабочая среда golang
  • Protobuf 3.x или выше для регенерации файлов протокола буфера (например, с помощью make generate)

SwarmKit собирается на Go и использует стандартную структуру проекта для хорошей работы с инструментами Go. Если вы новичок в Go, пожалуйста, обратитесь к BUILDING.md для более подробного руководства.

После того как вы проверили SwarmKit в своём $GOPATH, можно использовать Makefile для общих задач.

Из корневого каталога проекта выполните следующие действия для сборки swarmd и swarmctl:

$ make binaries

Тестирование

Перед запуском тестов в первый раз настройте инструменты:

$ make setup

Затем запустите:

$ make all

Примеры использования

Настройка Swarm

Эти инструкции предполагают, что swarmd и swarmctl находятся в вашем PATH.

(Прежде чем начать, убедитесь, что /tmp/node-N не существует)

Инициализируйте первый узел:

$ swarmd -d /tmp/node-1 --listen-control-api /tmp/node-1/swarm.sock --hostname node-1 Перед присоединением к кластеру необходимо получить токен:

$ export SWARM_SOCKET=/tmp/node-1/swarm.sock
$ swarmctl cluster inspect default
ID : 87d2ecpg12dfonxp3g562fru1 Name : default Orchestration settings: Task history entries: 5 Dispatcher settings: Dispatcher heartbeat period: 5s Certificate Authority settings: Certificate Validity Duration: 2160h0m0s Join Tokens: Worker: SWMTKN-1-3vi7ajem0jed8guusgvyl98nfg18ibg4pclify6wzac6ucrhg3-0117z3s2ytr6egmmnlr6gd37n Manager: SWMTKN-1-3vi7ajem0jed8guusgvyl98nfg18ibg4pclify6wzac6ucrhg3-d1ohk84br3ph0njyexw0wdagx


В двух дополнительных терминалах присоедините два узла. В примере ниже замените `127.0.0.1:4242` на адрес первого узла и используйте `<Worker Token>`, полученный выше. Если присоединяемые узлы работают на том же хосте, что и `node-1`, выберите другой удалённый порт прослушивания, например, `--listen-remote-api 127.0.0.1:4343`.

```sh
$ swarmd -d /tmp/node-2 --hostname node-2 --join-addr 127.0.0.1:4242 --join-token <Worker Token>
$ swarmd -d /tmp/node-3 --hostname node-3 --join-addr 127.0.0.1:4242 --join-token <Worker Token>

При присоединении в качестве менеджера также укажите listen-control-api.

$ swarmd -d /tmp/node-4 --hostname node-4 --join-addr 127.0.0.1:4242 --join-token <Manager Token> --listen-control-api /tmp/node-4/swarm.sock --listen-remote-api 127.0.0.1:4245

В четвёртом терминале используйте swarmctl для изучения и управления кластером. Перед запуском swarmctl, установите переменную среды SWARM_SOCKET в путь к сокету менеджера, который был указан в --listen-control-api при запуске менеджера.

Чтобы вывести список узлов:

$ export SWARM_SOCKET=/tmp/node-1/swarm.sock
$ swarmctl node ls
ID                         Name    Membership  Status  Availability  Manager Status
--                         ----    ----------  ------  ------------  --------------
3x12fpoi36eujbdkgdnbvbi6r  node-2  ACCEPTED    READY   ACTIVE
4spl3tyipofoa2iwqgabsdcve  node-1  ACCEPTED    READY   ACTIVE        REACHABLE *
dknwk1uqxhnyyujq66ho0h54t  node-3  ACCEPTED    READY   ACTIVE
zw3rwfawdasdewfq66ho34eaw  node-4  ACCEPTED    READY   ACTIVE        REACHABLE

Создание сервисов

Запустите сервис redis:

$ swarmctl service create --name redis --image redis:3.0.5
08ecg7vc7cbf9k57qs722n2le

Выведите список запущенных сервисов:

$ swarmctl service ls
ID                         Name   Image        Replicas
--                         ----   -----        --------
08ecg7vc7cbf9k57qs722n2le  redis  redis:3.0.5  1/1

Изучите сервис:

$ swarmctl service inspect redis
ID                : 08ecg7vc7cbf9k57qs722n2le
Name              : redis
Replicas          : 1/1
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Slot    Image          Desired State    Last State                Node
-------                      -------    ----    -----          -------------    ----------                ----
0xk1ir8wr85lbs8sqg0ug03vr    redis      1       redis:3.0.5    RUNNING          RUNNING 1 minutes ago    node-1

Обновление сервисов

Можно обновить любой атрибут сервиса.

Например, можно масштабировать сервис, изменив количество экземпляров:

$ swarmctl service update redis --replicas 6
08ecg7vc7cbf9k57qs722n2le

$ swarmctl service inspect redis
ID                : 08ecg7vc7cbf9k57qs722n2le
Name              : redis
Replicas          : 6/6
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Slot    Image          Desired State    Last State                Node
-------                      -------    ----    -----          -------------    ----------                ----
0xk1ir8wr85lbs8sqg0ug03vr    redis      1       redis:3.0.5    RUNNING          RUNNING 3 minutes ago    node-1
25m48y9fevrnh77til1d09vqq    redis      2       redis:3.0.5    RUNNING          RUNNING 28 seconds ago    node-3
42vwc8z93c884anjgpkiatnx6    redis
``` **Перевод текста на русский язык:**

3 redis:3.0.5 RUNNING RUNNING 28 секунд назад node-2 d41f3wnf9dex3mk6jfqp4tdjw redis 4 redis:3.0.5 RUNNING RUNNING 28 секунд назад node-2 66lefnooz63met6yfrsk6myvg redis 5 redis:3.0.5 RUNNING RUNNING 28 секунд назад node-1 3a2sawtoyk19wqhmtuiq7z9pt redis 6 redis:3.0.5 RUNNING RUNNING 28 секунд назад node-3


Изменение *replicas* с *1* на *6* вынудило *SwarmKit* создать *5* дополнительных задач, чтобы соответствовать желаемому состоянию.

Можно изменить и другие поля, такие как image, args, env и т. д.

Давайте изменим образ с *redis:3.0.5* на *redis:3.0.6* (например, обновим):

$ swarmctl service update redis --image redis:3.0.6 08ecg7vc7cbf9k57qs722n2le

$ swarmctl service inspect redis ID : 08ecg7vc7cbf9k57qs722n2le Name : redis Replicas : 6/6 Update Status State : COMPLETED Started : 3 минуты назад Completed : 1 минута назад Message : обновление завершено Template Container Image : redis:3.0.6

Task ID Service Slot Image Desired State Last State Node


0udsjss61lmwz52pke5hd107g redis 1 redis:3.0.6 RUNNING RUNNING 1 минуту назад node-3 b8o394v840thk10tamfqlwztb redis 2 redis:3.0.6 RUNNING RUNNING 1 минуту назад node-1 efw7j66xqpoj3cn3zjkdrwff7 redis 3 redis:3.0.6 RUNING RUNNING 1 минуту назад node-3 8ajeipzvxucs3776e4z8gemey redis 4 redis:3.0.6 RUNNING RUNNING 1 минуту назад node-2 f05f2lbqzk9fh4kstwpulygvu redis 5 redis:3.0.6 RUNNING RUNNING 1 минуту назад node-2 7sbpoy82deq7hu3q9cnucfin6 redis 6 redis:3.0.6 RUNNING RUNNING 1 минуту назад node-1


По умолчанию все задачи обновляются одновременно.

Это поведение можно изменить, задав параметры обновления.

Например, чтобы обновлять задачи по две за раз и ждать не менее 10 секунд между обновлениями:

$ swarmctl service update redis --image redis:3.0.7 --update-parallelism 2 --update-delay 10s $ watch -n1 "swarmctl service inspect redis" # наблюдать за обновлением


Это обновит 2 задачи, дождётся, пока они станут *RUNNING*, затем подождёт дополнительные 10 секунд, прежде чем перейти к другим задачам.

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

### Управление узлами

*SwarmKit* отслеживает работоспособность узлов. В случае сбоя узла он перераспределяет задачи на другие узлы.

Оператор может вручную определить *Доступность* узла и *Приостановить* и *Осушить* узлы.

Переведём узел `node-1` в режим обслуживания:

$ swarmctl node drain node-1

$ swarmctl node ls ID Name Membership Status Availability Manager Status


3x12fpoi36eujbdkgdnbvbi6r node-2 ACCEPTED READY ACTIVE 4spl3tyipofoa2iwqgabsdcve node-1 ACCEPTED READY DRAIN REACHABLE * dknwk1uqxhnyyujq66ho0h54t node-3 ACCEPTED READY ACTIVE

$ swarmctl service inspect redis ID : 08ecg7vc7cbf9k57qs722n2le Name : redis Replicas : 6/6 Update Status State : COMPLETED Started : 2 минуты назад Completed : 1 минута назад Message : обновление завершено Template Container Image : redis:3.0.7

Task ID Service Slot Image Desired State Last State Node


8uy2fy8dqbwmlvw5iya802tj0 redis 1 redis:3.0.7 RUNNING RUNNING 23 секунды назад node-2 Как вы можете видеть, каждая задача, работающая на узле node-1, была перебалансирована циклом согласования на узлы node-2 или node-3.

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

SwarmKit — это инструментарий для управления распределёнными системами любого масштаба. Он включает в себя примитивы для обнаружения узлов, консенсуса на основе алгоритма Raft, планирования задач и многое другое. Развернуть Свернуть
Apache-2.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/AliyunContainerService-swarmkit.git
git@api.gitlife.ru:oschina-mirror/AliyunContainerService-swarmkit.git
oschina-mirror
AliyunContainerService-swarmkit
AliyunContainerService-swarmkit
master