Как установить и настроить Kubernetes поверх кластера CoreOS

Вступление

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

В этом руководстве мы покажем, как начать работу с Kubernetes в кластере CoreOS. Эта система позволит нам группировать связанные службы для развертывания в виде единого узла на одном компьютере, используя то, что Kubernetes называет «модулями». Он также обеспечивает функциональность проверки работоспособности, высокую доступность и эффективное использование ресурсов.

Этот учебник был протестирован с Kubernetes v0.7.0. Имейте в виду, что это программное обеспечение часто меняется. Чтобы увидеть вашу версию, после ее установки, запустите:

kubecfg -version

Предпосылки и цели

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

Это даст вам три сервера для настройки. Хотя каждый узел по существу взаимозаменяемы на уровне CoreOS, в Kubernetes нам необходимо назначить более специализированные роли. Нам нужен один узел, который будет действовать как мастер, он будет запускать несколько дополнительных сервисов, таких как сервер API и диспетчер контроллеров

Для этого руководства мы будем использовать следующие детали:

Hostname	Public IPv4	Private IPv4	Role
coreos-1	192.168.2.1	10.120.0.1	Master
coreos-2	192.168.2.2	10.120.0.2	Minion1
coreos-3	192.168.2.3	10.120.0.3	Minion2

В конфигурации, которой мы будем следовать, мастер также будет полнофункциональным сервером миньонов, способным завершать работу. Идея этой конфигурации была взята из Brian Ketelson’s руководство по настройке Kubernetes на CoreOS здесь.

Если вы следовали приведенному выше руководству по созданию кластера, и + etcd + и + fleet + должны быть настроены на использование частного IPv4 каждого сервера для связи. Общедоступный IP-адрес можно использовать для подключения с вашего локального компьютера.

Это руководство возьмёт этот базовый кластер CoreOS и установит несколько сервисов поверх него.

Во-первых, мы настроим + flannel +, слой сетевой структуры, который предоставляет каждой машине отдельную подсеть для связи контейнера. Это относительно новый проект CoreOS, созданный в значительной степени для адаптации к предположениям Kubernetes о сетевой среде.

Мы настроим Docker для использования этого сетевого уровня для развертываний. Помимо этого, мы создадим Kubernetes. Это включает в себя несколько штук. Нам нужно настроить службу прокси, уровень API и систему управления «pod» на уровне узла под названием Kubelet.

Создайте слой Flannel Network Fabric

Первое, что нам нужно сделать, это настроить сервис + flannel +. Это компонент, который предоставляет отдельные подсети для каждой машины в кластере. Docker будет настроен на использование этого для развертываний. Поскольку это базовое требование, это отличное место для начала.

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

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

Все приложения, которые мы будем устанавливать, будут помещены в каталог + / opt / bin +, который не создается автоматически в CoreOS. Создайте каталог сейчас:

sudo mkdir -p /opt/bin

Теперь мы можем построить проект с помощью контейнера Go. Просто запустите команду Docker, чтобы извлечь образ из Docker Hub, запустить контейнер, загрузить и собрать пакет внутри контейнера:

docker run -i -t google/golang /bin/bash -c "go get github.com/coreos/flannel"

Когда операция завершена, мы можем скопировать скомпилированный двоичный файл из контейнера. Во-первых, нам нужно знать идентификатор контейнера:

docker ps -l -q

Результатом будет идентификатор, который выглядит следующим образом:

Мы можем использовать этот идентификатор для указания операции копирования в каталог + / opt / bin +. Двоичный файл был помещен в + / gopath / bin / flannel + внутри контейнера. Поскольку каталог + / opt / bin + недоступен для записи нашим пользователем + core +, нам придется использовать + sudo +:

sudo docker cp :/gopath/bin/flannel /opt/bin/

Теперь у нас есть фланель на нашей первой машине. Чуть позже мы скопируем это на другие наши машины.

Построить бинарники Kubernetes

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

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

Первым шагом является клонирование проекта из его репозитория GitHub. Мы клонируем его в наш домашний каталог:

cd ~
git clone https://github.com/GoogleCloudPlatform/kubernetes.git

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

cd kubernetes/build
./release.sh

Этот процесс займет довольно много времени. Он запустит Docker-контейнер для сборки необходимых двоичных пакетов.

Когда процесс сборки будет завершен, вы сможете найти двоичные файлы в каталоге + ~ / kubernetes / _output / dockerized / bin / linux / amd64 +:

cd ~/kubernetes/_output/dockerized/bin/linux/amd64
ls

e2e          kube-apiserver           kube-proxy      kubecfg  kubelet
integration  kube-controller-manager  kube-scheduler  kubectl  kubernetes

Мы перенесем их в каталог + / opt / bin +, который мы создали ранее:

sudo cp * /opt/bin

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

Передача исполняемых файлов на другие серверы

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

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

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

Когда вы подключились к своему первому компьютеру, вы должны были перенаправить информацию о вашем агенте SSH, подключившись с флагом + -A + (после запуска агента и добавления вашего ключа). Это важный шаг. Отключите и снова подключите, если вы не прошли этот флаг ранее.

Вам нужно будет выполнить команды + eval + и + ssh-add + из раздела * Step 2-Authenticate * на https://www.digitalocean.com/community/tutorials/how-to-connect-to- your-droplet-with-ssh # ssh-login-as-root [это руководство] перед соединением с + -A +.

Начните с перехода в каталог, в который мы поместили наши двоичные файлы:

cd /opt/bin

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

Команда SSH, которую мы будем использовать, создаст каталог + / opt / bin + на нашем другом хосте, перейдет в каталог и распакует информацию, полученную через туннель SSH. Вся команда выглядит так:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Это перенесет все исполняемые файлы на указанный вами IP-адрес. Запустите команду еще раз, используя ваш третий хост:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Теперь у вас есть все исполняемые файлы на ваших трех машинах.

Настройка мастер-специфичных сервисов

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

Мы будем помещать эти файлы в каталог + / etc / systemd / system. Переместись туда сейчас:

cd /etc/systemd/system

Теперь мы можем начать создавать наши сервисные файлы. Мы создадим два файла только на главном и пять файлов, которые также принадлежат миньонам. Все эти файлы будут в + / etc / systemd / system / *. Service +.

Основные файлы:

+ + Apiserver.service
+ Контроллер-manager.service +

Файлы Minion для всех серверов:

+ + Scheduler.service
+ + Flannel.service
+ + Docker.service
+ + Proxy.service
+ + Kubelet.service

Создайте файл модуля сервера API

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

Мы будем называть этот файл модуля + apiserver.service + для простоты. Создайте и откройте этот файл сейчас:

sudo vim apiserver.service

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

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Далее мы завершим раздел + [Service] +. Это будет в основном использоваться для запуска сервера API с некоторыми параметрами, описывающими нашу среду. Мы также настроим условия перезагрузки:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

Приведенный выше раздел устанавливает сетевой адрес и порт, на котором будет работать сервер, а также место, где + etcd + прослушивает. Параметр + portal_net + определяет диапазон сети, который будет использовать служба + flannel +.

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

Наконец, нам нужно будет установить этот блок. Мы можем сделать это с разделом + [Install] +, который скажет нашему хосту запустить эту службу, когда машина полностью загрузится:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Когда вы закончите, закройте файл.

Создайте файл модуля диспетчера контроллеров

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

Откройте файл с именем + controller-manager.service + в том же каталоге:

sudo vim controller-manager.service

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

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

Для части + [Service] + этого файла нам просто нужно передать несколько параметров в исполняемый файл. Главным образом мы указываем приложение на местоположение нашего сервера API. Здесь мы передали частные IP-адреса каждого из наших компьютеров, разделенные запятыми. Измените эти значения, чтобы отразить вашу собственную конфигурацию. Опять же, мы позаботимся о том, чтобы этот модуль перезагружался при сбое, поскольку это требуется для правильной работы нашего кластера Kubernetes:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

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

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните и закройте файл, когда вы закончите.

Настройка кластерных сервисов

Теперь, когда у нас настроены наши основные сервисы, мы можем настроить файлы модулей, которые должны присутствовать на * всех * наших машинах. Это означает, что вы должны добавить эти файлы как на главный, так и на серверы minion и настроить их соответствующим образом.

Эти пять файлов должны быть созданы на всех машинах, в + / etc / systemd / system / *. Service +.

+ + Scheduler.service
+ + Flannel.service
+ + Docker.service
+ + Proxy.service
+ + Kubelet.service

Создайте файл модуля планировщика

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

Создайте и откройте файл для этого устройства сейчас:

sudo vim scheduler.service

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

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

Сам раздел обслуживания очень прост. Нам нужно только указать исполняемый файл на сетевой адрес и порт, на котором расположен сервер API. Опять же, мы перезапустим службу в случае сбоя.

Раздел установки отражает другие, которые мы видели до сих пор:

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-scheduler -master=127.0.0.1:8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Когда вы закончите, сохраните и закройте файл.

Создайте файл фланелевого блока

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

Опять же, на каждом из ваших компьютеров перейдите в каталог конфигурации + systemd +:

cd /etc/systemd/system

Создайте и откройте файл модуля + flannel + в своем текстовом редакторе:

sudo vim flannel.service

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

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

Для раздела + [Service] + мы сначала собираемся получить файл + / etc / environment +, чтобы иметь доступ к частному IP-адресу нашего хоста.

Следующим шагом будет размещение строки + ExecStartPre = +, которая пытается зарегистрировать диапазон подсети с помощью + etcd +. Он будет постоянно пытаться зарегистрироваться в etcd, пока не добьется успеха. Для этого руководства мы будем использовать диапазон + 10.100.0.0 / 16 +.

Затем мы начнем + flannel + с частного IP-адреса, который мы получаем из файла среды.

После этого мы хотим проверить, записал ли + flannel + свою информацию в свой файл (чтобы Docker мог прочитать ее в одно мгновение), и спим, если этого не произошло. Это гарантирует, что служба Docker не будет пытаться прочитать файл до того, как он станет доступным (это может произойти на первом сервере, подключенном к сети). Мы настроим перезагрузку, используя обычные параметры, и снова установим модуль, используя + multi-user.target +:

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/bin/bash -c "until /usr/bin/etcdctl set /coreos.com/network/config '{\"Network\": \"10.100.0.0/16\"}'; do echo \"waiting for etcd to become available...\"; sleep 5; done"
ExecStart=/opt/bin/flannel -iface=${COREOS_PRIVATE_IPV4}
ExecStartPost=-/bin/bash -c "until [ -e /run/flannel/subnet.env ]; do echo \"waiting for write.\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните и закройте файл, когда вы закончите. Создайте тот же файл на других ваших хостах.

Создайте файл модуля Docker

Следующий файл, который мы создадим, на самом деле не связан с исполняемыми файлами в нашем каталоге + / opt / bin +. Нам нужно создать файл службы Docker, чтобы служба запускалась с учетом только что настроенного сетевого оверлея + flannel +.

Создайте соответствующий файл модуля в текстовом редакторе:

sudo vim docker.service

Начните с обычных метаданных. Нам нужно запустить его после того, как служба + flannel + была настроена и переведена в режим онлайн:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

Для секции + [Service] + нам потребуется исходный файл, который + flannel + использует для хранения переменных среды, которые он создает. Это будет иметь информацию о подсети текущего хоста.

Затем мы отключаем текущий интерфейс моста + docker0 +, если он работает, и удаляем его. Это позволяет нам перезапустить Docker с чистого листа. Процесс настроит интерфейс + docker0 +, используя сетевую информацию + flannel +.

Мы используем тот же перезапуск и + [Install] + детали, которые мы использовали с другими нашими модулями:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

[Service]
EnvironmentFile=/run/flannel/subnet.env
ExecStartPre=-/usr/bin/ip link set dev docker0 down
ExecStartPre=-/usr/sbin/brctl delbr docker0
ExecStart=/usr/bin/docker -d -s=btrfs -H fd:// --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните и закройте файл, когда вы закончите. Создайте этот же файл на каждом из ваших хостов.

Создайте файл прокси-модуля

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

Откройте файл прокси-модуля в текстовом редакторе:

sudo vim proxy.service

Для раздела метаданных нам нужно определить зависимости от + etcd + и Docker. Для секции + [Service] + нам просто нужно запустить исполняемый файл с адресом локального сервера + etcd +. Перезапуск конфигурации и детали установки будут отражать наши предыдущие сервисные файлы:

[Unit]
Description=Kubernetes proxy server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-proxy -etcd_servers=http://127.0.0.1:4001 -logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните файл, когда вы закончите. Создайте этот же файл на каждом из ваших хостов.

Создайте файл модуля Kubelet

Теперь мы создадим файл модуля Kubelet. Этот компонент используется для управления развертыванием контейнеров. Это гарантирует, что контейнеры находятся в том состоянии, в котором они должны находиться, и контролирует систему на предмет изменений в желаемом состоянии развертываний.

Создайте и откройте файл в вашем текстовом редакторе:

sudo vim kubelet.service

Раздел метаданных будет содержать ту же информацию о зависимости от + etcd + и Docker:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Для раздела + [Service] + мы снова должны получить файл + / etc / environment +, чтобы получить доступ к частному IP-адресу хоста. Затем мы вызовем исполняемый файл + kubelet +, установив его адрес и порт. Мы также переопределяем имя хоста, чтобы использовать тот же частный IP-адрес, и указываем сервис на локальный экземпляр + etcd +. Мы предоставляем те же сведения о перезапуске и установке, которые мы использовали:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
EnvironmentFile=/etc/environment
ExecStart=/opt/bin/kubelet \
-address=${COREOS_PRIVATE_IPV4} \
-port=10250 \
-hostname_override=${COREOS_PRIVATE_IPV4} \
-etcd_servers=http://127.0.0.1:4001 \
-logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните и закройте файл, когда вы закончите.

Включение Сервисов

Теперь, когда у вас запущены все служебные файлы, вы можете включить эти устройства. При этом обрабатывается информация в разделе + [Install] + каждого модуля.

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

Для этого перейдите в каталог + / etc / systemd / system:

cd /etc/systemd/system

Отсюда мы можем включить все скрипты:

sudo systemctl enable *

Это создаст каталог + multi-user.target.wants + с символическими ссылками на наши файлы модулей. Этот каталог будет обработан + systemd + в конце процесса загрузки.

Повторите этот шаг на каждом из ваших серверов.

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

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

sudo reboot

Как только мастер вернется в онлайн, вы можете перезагрузить серверы миньонов:

sudo reboot

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

systemctl status

Или вы можете пойти в журнал, набрав:

journalctl -b -u

Ищите указание на то, что службы работают и работают правильно. Если есть какие-либо проблемы, перезапуск конкретной службы может помочь:

sudo systemctl restart

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

kubecfg list minions

Minion identifier
----------

В будущем руководстве мы поговорим о том, как использовать Kubernetes для планирования и управления службами в вашем кластере CoreOS.

Заключение

Теперь вы должны настроить Kubernetes в своем кластере CoreOS. Это дает вам отличный интерфейс управления и планирования для работы со службами в логических группах.

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

Файлы облачной конфигурации достаточно гибки, чтобы вы могли внедрить большинство файлов модулей без каких-либо изменений (за исключением файла + apiserver.service +, который требует доступа к IP-адресам каждого узла) и запускать их как CoreOS узел загружается. Это выходит за рамки данного руководства, но является хорошим следующим шагом с точки зрения автоматизации процесса.

TOC