На переправе оркестратор не меняют.
После того как мне окончательно надоел Docker Swarm из-за своей псевдопростоты и постоянного допиливания, не очень удобной работой с распределенными файловыми системами, немного сыроватым web-интерфейсом и узкой функциональностью, а также отсутствие поддержки «из коробки» GitLab интеграции, было принято решение развернуть свой Kubernetes cluster на собственном железе, а именно, путем развертывания Rancher Management Server 2.0.
Опыт установки, схема отказоустойчивости, работа с haProxy и два dashboard под катом:
Входные данные:
Host Server HP Proliant DL320e Gen8 — 2 шт.
VM Ubuntu Server 16.04, 2Gb RAM, 2vCPU, 20Gb HDD — 1 шт. on each Host (VM-haProxy).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 40Gb HDD, 20 Gb SSD — 3 шт. on each Host (VM-*-Cluster).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 100Gb HDD — 1 шт. on anyone Host (VM-NFS).
Схема сети:
Приступаем:
VM-haProxy имеет на борту haProxy, fail2ban, правила iptables. Исполняет роль шлюза для всех машин за ним. У нас два шлюза и все машины в случае потери связи шлюза на своем хосте переключатся на другой.
Главная задача этих узлов (VM-haProxy) распределять доступ к backend, балансировать, пробрасывать порты, собирать статистику.
Мой выбор пал на haProxy, как более узко направленному инструменту относительно балансирования и health checking. При всем этом нравится синтаксис директив конфигураций и работа с белыми и черными списками IP, а также работа с мультидоменным SSL подключением.
Конфигурация haProxy:
Важно: Все машины должны «знать» друг друга по имени хоста.
VM-Master-Cluster — главная машина управления. Отлично от других нод имеет на борту Puppet Master, GlusterFS Server, Rancher Server (container), etcd (container), control manager (container). В случае отключения этого хоста, production сервисы продолжают работать.
VM-Node-Cluster — Ноды, воркеры. Рабочие машины, ресурсы которых будут объединены в одну отказоустойчивую среду. Ничего интересного.
VM-NFS — NFS сервер (nfs-kernel-server). Главная задача — это предоставление буфферного пространства. Хранит конфигурационные файлы и всякое. Не хранит ничего важного. Его падение можно исправлять не спеша, попивая кофе.
Важно: Все машины окружения должны иметь на борту: docker.io, nfs-common, gluster-server.
Монтирование nfs-volume и настройку GlusterFS описывать не буду, так как это щедро описано в большом количестве.
Если вы заметили, в описании спецификации, есть SSD диски, они заготовлены для работы распределенной файловой системы Gluster. Создайте разделы, и хранилища на высокоскоростных дисках.
Примечание. На самом деле, для запуска Rancher не требуется зеркально идентичной среды. Все вышеописанное — это мое видение кластера и описание того, каких практик придерживаюсь я.
Для запуска Rancher достаточно одной машины, с 4CPU, 4Gb RAM, 10Gb HDD.
5 минут до Rancher.
На VM-Master-Cluster выполняем:
Проверьте доступность:
Если вы увидели API — я Вас поздравляю ровно половина пути пройдена.
Взглянув на схему сети снова, мы вспомним что будем работать извне, через haProxy, в конфигурации у нас опубликована ссылка rancher.domain.ru, переходим, устанавливаем свой пароль.
Следующая страница — страница создания кластера Kubernetes.
В меню Cluster Options, выберите Flannel. С другими провайдерами сетей не работал. Советовать не могу.
Стоит обратить внимание на то, что мы установили чекбоксы etcd и Control Plane, чекбокс worker не установлен, в том случае, если вы не планируете использовать менеджер в режиме воркера.
Мы работаем внутри локальной сети, с одним адресом на NIC, поэтому в полях Public и Internal Address указали один и тот же IP.
Скопируйте получившийся код выше, запустите его в консоли.
Спустя некоторое время в web интерфейсе вы увидите сообщение о добавлении ноды. А еще через некоторое время у вас запустится кластер Kubernetes.
Чтобы добавить воркер, перейдите в редактирование кластера в web интерфейсе Rancher, увидите то же меню, которое генерирует команду подключения.
Установите чекбокс только в положение worker, укажите IP будущего воркера, скопируйте команду и выполните ее в консоли нужной вам ноды.
Через некоторое время мощность кластера увеличится, ровно как и количество нод.
Установка Kubernetes Dashboard:
Перейдите в меню Projects/Namespaces.
После установки вы увидите, что namespaces, относящиеся к Kubernetes, будут содержаться вне проектов. Чтобы полноценно работать с этими пространствами имен их необходимо поместить в проект.
Добавьте проект, назовите по своему усмотрению. Переместите namespaces (cattle-system, ingress-nginx, kube-public, kube-system) в созданный вами проект с помощью контекстного меню «Move». Должно получится так:
Щелкните прямо по имени проекта, вы попадете в панель управления workload. Именно здесь далее мы разберем, как создать простой сервис.
Нажмите «Import YAML» в правом верхнем углу. Скопируйте и вставьте содержимое этого файла в текстбокс открывшегося окна, выберите namespace «kube-system», нажмите «Import».
Через некоторое время запустится pod kubernetes-dashboard.
Перейдите в редактирование pod, раскройте меню публикации портов, установите следующие значения:
Проверьте доступ на ноде на которой запущен pod.
Увидели ответ? Публикация завершена, осталось достучаться до административной части.
На главной странице управления кластером в Rancher, есть очень удобные инструменты, такие как, kubectl — консоль управления кластером и Kubeconfig File — файл конфигурации, содержащий адрес API, ca.crt и т.д.
Заходим в kubectl и выполняем:
Мы создали сервис аккаунт с высшими привелегиями, теперь нам нужен токен для доступа в Dashboard.
Найдем секрет созданного аккаунта:
Увидим имя аккаунта с неким хэшем в конце, копируем его и выполняем:
Снова вспомним о том, что у нас все благополучно опубликовано через haProxy.
Переходим по ссылке kubernetes.domain.ru. Вводим полученный токен.
Радуемся:
P.S.
Общим итогом хотелось бы выразить благодарность Rancher за то, что создали интуитивно понятный интерфейс, легко развертываемый инстанс, простую документацию, возможность быстрого переезда и масштабируемость на уровне кластеров. Возможно, я слишком резко высказался в начале поста о том, что Swarm надоел, скорей очевидные тренды развития, своеобразно заставляли засматриваться на сторону и не доводить скучные рутинные дела до конца. Docker создал эпоху развития. И судить этот проект уж точно не мне.
После того как мне окончательно надоел Docker Swarm из-за своей псевдопростоты и постоянного допиливания, не очень удобной работой с распределенными файловыми системами, немного сыроватым web-интерфейсом и узкой функциональностью, а также отсутствие поддержки «из коробки» GitLab интеграции, было принято решение развернуть свой Kubernetes cluster на собственном железе, а именно, путем развертывания Rancher Management Server 2.0.
Опыт установки, схема отказоустойчивости, работа с haProxy и два dashboard под катом:
Входные данные:
Host Server HP Proliant DL320e Gen8 — 2 шт.
VM Ubuntu Server 16.04, 2Gb RAM, 2vCPU, 20Gb HDD — 1 шт. on each Host (VM-haProxy).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 40Gb HDD, 20 Gb SSD — 3 шт. on each Host (VM-*-Cluster).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 100Gb HDD — 1 шт. on anyone Host (VM-NFS).
Схема сети:
Рис.1
Приступаем:
VM-haProxy имеет на борту haProxy, fail2ban, правила iptables. Исполняет роль шлюза для всех машин за ним. У нас два шлюза и все машины в случае потери связи шлюза на своем хосте переключатся на другой.
Главная задача этих узлов (VM-haProxy) распределять доступ к backend, балансировать, пробрасывать порты, собирать статистику.
Мой выбор пал на haProxy, как более узко направленному инструменту относительно балансирования и health checking. При всем этом нравится синтаксис директив конфигураций и работа с белыми и черными списками IP, а также работа с мультидоменным SSL подключением.
Конфигурация haProxy:
haproxy.conf с комментариями
##########################################################
#Global #
##########################################################
global
log 127.0.0.1 local0 notice
maxconn 2000
user haproxy
group haproxy
tune.ssl.default-dh-param 2048
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
timeout connect 5000
timeout client 10000
timeout server 10000
option forwardfor
option http-server-close
##########################################################
#TCP #
##########################################################
#Здесь мы пробрасываем порт API Сервера Kubernetes
listen kube-api-tls
bind *:6443
mode tcp
option tcplog
server VM-Master-Cluster Master:6443
##########################################################
#HTTP/HTTPS - Frontend and backend #
##########################################################
#В текущем блоке конфигурации мы разделяем "белки от желтков", frontend от backend.
frontend http-in
bind *:80
acl network_allowed src -f /path/allowed-ip # Путь к белому списку IP. Применимо в любом блоке директивы.
http-request deny if !network_allowed # Правило отклонения подключений в случае отсутствия IP в списке.
reqadd X-Forwarded-Proto:\ http
mode http
option httpclose
acl is_haproxy hdr_end(host) -i haproxy.domain.ru
acl is_rancher hdr_end(host) -i rancher.domain.ru
acl is_kubernetes hdr_end(host) -i kubernetes.domain.ru
use_backend kubernetes if is_kubernetes
use_backend rancher if is_rancher
use_backend haproxy if is_haproxy
frontend https-in
bind *:443 ssl crt-list /path/crt-list # Путь к списком сертификатов. Отличный инструмент для работы с большим количеством сертификатов.
acl network_allowed src -f /path/allowed-ip
http-request deny if !network_allowed
reqadd X-Forwarded-Proto:\ https
acl is_rancher hdr_end(host) -i rancher.etraction.ru
acl is_kubernetes hdr_end(host) -i kubernetes.etraction.ru
use_backend kubernetes if is_kubernetes { ssl_fc_sni kubernetes.domain.ru }
use_backend rancher if is_rancher { ssl_fc_sni rancher.domain.ru }
# Backend статистики haProxy. Незаменимый инструмент мониторинга балансировщика.
backend haproxy
stats enable
stats uri /haproxy?stats
stats realm Strictly\ Private
stats auth login:passwd
cookie SERVERID insert nocache indirect
# Ну и, собственно, backend для наших dashboard rancher и kubernetes.
backend rancher
acl network_allowed src -f /path/allowed-ip
http-request deny if !network_allowed
mode http
redirect scheme https if !{ ssl_fc }
server master master:443 check ssl verify none
backend kubernetes
acl network_allowed src -f /path/allowed-ip
http-request deny if !network_allowed
mode http
balance leastconn
redirect scheme https if !{ ssl_fc }
server master master:9090 check ssl verify none
Важно: Все машины должны «знать» друг друга по имени хоста.
add-host-entry.pp puppet манифест для добавления имени хостов в /etc/hosts
class host_entries {
host { 'proxy01':
ip => '10.10.10.11',
}
host { 'proxy02':
ip => '10.10.10.12',
}
host { 'master':
ip => '10.10.10.100',
}
host { 'node01':
ip => '10.10.10.101',
}
host { 'node02':
ip => '10.10.10.102',
}
host { 'node03':
ip => '10.10.10.103',
}
host { 'node04':
ip => '10.10.10.104',
}
host { 'node05':
ip => '10.10.10.105',
}
host { 'nfs':
ip => '10.10.10.200',
}
}
VM-Master-Cluster — главная машина управления. Отлично от других нод имеет на борту Puppet Master, GlusterFS Server, Rancher Server (container), etcd (container), control manager (container). В случае отключения этого хоста, production сервисы продолжают работать.
VM-Node-Cluster — Ноды, воркеры. Рабочие машины, ресурсы которых будут объединены в одну отказоустойчивую среду. Ничего интересного.
VM-NFS — NFS сервер (nfs-kernel-server). Главная задача — это предоставление буфферного пространства. Хранит конфигурационные файлы и всякое. Не хранит ничего важного. Его падение можно исправлять не спеша, попивая кофе.
Важно: Все машины окружения должны иметь на борту: docker.io, nfs-common, gluster-server.
must-have-packages.pp puppet манифест для установки нужного ПО
class musthave {
package { 'docker.io':
ensure => 'installed',
}
package { 'nfs-common':
ensure => 'installed',
}
package { 'gluster-server':
ensure => 'installed',
}
}
Монтирование nfs-volume и настройку GlusterFS описывать не буду, так как это щедро описано в большом количестве.
Если вы заметили, в описании спецификации, есть SSD диски, они заготовлены для работы распределенной файловой системы Gluster. Создайте разделы, и хранилища на высокоскоростных дисках.
Примечание. На самом деле, для запуска Rancher не требуется зеркально идентичной среды. Все вышеописанное — это мое видение кластера и описание того, каких практик придерживаюсь я.
Для запуска Rancher достаточно одной машины, с 4CPU, 4Gb RAM, 10Gb HDD.
5 минут до Rancher.
На VM-Master-Cluster выполняем:
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancherПроверьте доступность:
curl -k https://localhostЕсли вы увидели API — я Вас поздравляю ровно половина пути пройдена.
Взглянув на схему сети снова, мы вспомним что будем работать извне, через haProxy, в конфигурации у нас опубликована ссылка rancher.domain.ru, переходим, устанавливаем свой пароль.
Следующая страница — страница создания кластера Kubernetes.
Рис.2
В меню Cluster Options, выберите Flannel. С другими провайдерами сетей не работал. Советовать не могу.
Стоит обратить внимание на то, что мы установили чекбоксы etcd и Control Plane, чекбокс worker не установлен, в том случае, если вы не планируете использовать менеджер в режиме воркера.
Мы работаем внутри локальной сети, с одним адресом на NIC, поэтому в полях Public и Internal Address указали один и тот же IP.
Скопируйте получившийся код выше, запустите его в консоли.
Спустя некоторое время в web интерфейсе вы увидите сообщение о добавлении ноды. А еще через некоторое время у вас запустится кластер Kubernetes.
Рис.3
Чтобы добавить воркер, перейдите в редактирование кластера в web интерфейсе Rancher, увидите то же меню, которое генерирует команду подключения.
Установите чекбокс только в положение worker, укажите IP будущего воркера, скопируйте команду и выполните ее в консоли нужной вам ноды.
Через некоторое время мощность кластера увеличится, ровно как и количество нод.
Установка Kubernetes Dashboard:
Перейдите в меню Projects/Namespaces.
После установки вы увидите, что namespaces, относящиеся к Kubernetes, будут содержаться вне проектов. Чтобы полноценно работать с этими пространствами имен их необходимо поместить в проект.
Добавьте проект, назовите по своему усмотрению. Переместите namespaces (cattle-system, ingress-nginx, kube-public, kube-system) в созданный вами проект с помощью контекстного меню «Move». Должно получится так:
Рис.4
Щелкните прямо по имени проекта, вы попадете в панель управления workload. Именно здесь далее мы разберем, как создать простой сервис.
Рис.5
Нажмите «Import YAML» в правом верхнем углу. Скопируйте и вставьте содержимое этого файла в текстбокс открывшегося окна, выберите namespace «kube-system», нажмите «Import».
Через некоторое время запустится pod kubernetes-dashboard.
Перейдите в редактирование pod, раскройте меню публикации портов, установите следующие значения:
Рис.6
Проверьте доступ на ноде на которой запущен pod.
curl -k https://master:9090 Увидели ответ? Публикация завершена, осталось достучаться до административной части.
На главной странице управления кластером в Rancher, есть очень удобные инструменты, такие как, kubectl — консоль управления кластером и Kubeconfig File — файл конфигурации, содержащий адрес API, ca.crt и т.д.
Заходим в kubectl и выполняем:
kubectl create serviceaccount cluster-admin-dashboard-sa
kubectl create clusterrolebinding cluster-admin-dashboard-sa --clusterrole=cluster-admin --serviceaccount=default:cluster-admin-dashboard-sa
Мы создали сервис аккаунт с высшими привелегиями, теперь нам нужен токен для доступа в Dashboard.
Найдем секрет созданного аккаунта:
kubectl get secret | grep cluster-admin-dashboard-sa
Увидим имя аккаунта с неким хэшем в конце, копируем его и выполняем:
kubectl describe secret cluster-admin-dashboard-sa-$(некий хэш)
Снова вспомним о том, что у нас все благополучно опубликовано через haProxy.
Переходим по ссылке kubernetes.domain.ru. Вводим полученный токен.
Радуемся:
Рис.7
P.S.
Общим итогом хотелось бы выразить благодарность Rancher за то, что создали интуитивно понятный интерфейс, легко развертываемый инстанс, простую документацию, возможность быстрого переезда и масштабируемость на уровне кластеров. Возможно, я слишком резко высказался в начале поста о том, что Swarm надоел, скорей очевидные тренды развития, своеобразно заставляли засматриваться на сторону и не доводить скучные рутинные дела до конца. Docker создал эпоху развития. И судить этот проект уж точно не мне.