В новом релизе Kubernetes-платформы Deckhouse v1.43 появилась система виртуализации, основанная на современных технологиях: KubeVirt, Cilium, LINSTOR. Она позволяет в удобном и привычном для пользователя платформы режиме запускать виртуальные машины и управлять их жизненным циклом.
В статье мы рассмотрим это на практике: развернем Deckhouse на bare-metal-сервере, запустим в нем виртуальную машину и протестируем, как обеспечивается связь между компонентами кластера с помощью магии Cilium.
Виртуализация в кластере
С новой системной виртуализации появилась возможность запускать привычные виртуальные машины (ВМ) прямо в Kubernetes и работать с ними как с ресурсами кластера.
Это может быть полезно, если для работы приложений требуются какие-то специфические инструменты, работа которых невозможна в K8s. А также в случае перехода от старой инфраструктуры с ВМ к контейнеризации приложений. В этом случае можно развернуть одну часть приложения в кластере, а другую поднять рядом в отдельной ВМ, созданной средствами Deckhouse и объединенной с кластером одной сетью.
Подготовка сервера
Для установки нам понадобится сервер, соответствующий минимальным требованиям:
не менее 4 ядер CPU;
не менее 8 Гб RAM;
не менее 40 Гб дискового пространства;
HTTPS-доступ к хранилищу образов контейнеров registry.deckhouse.io;
на сервере не должно быть установлено пакетов container runtime, например containerd или Docker.
Также понадобится персональный компьютер, с которого будет производиться установка. Он должен соответствовать следующим требованиям:
ОС: Windows 10+, macOS 10.15+, Linux (Ubuntu 18.04+, Fedora 35+);
установленный Docker для запуска инсталлятора Deckhouse (инструкции по установке для Ubuntu, macOS, Windows);
HTTPS-доступ к хранилищу образов контейнеров registry.deckhouse.io;
SSH-доступ по ключу к серверу, который будет master-узлом будущего кластера.
В качестве сервера для тестов у нас будет 1U-сервер Supermicro со следующими характеристиками:
2 процессора Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 16 ядер;
40 Гб оперативной памяти;
256 Гб SSD под корень ОС;
320 Гб на отдельном диске для хранения данных виртуальных машин.
В первую очередь установим ОС, выбрав подходящую из списка поддерживаемых:
РЕД ОС 7.3;
AlterOS 7;
Astra Linux Special Edition 1.7.2;
CentOS 7, 8, 9;
Debian 9, 10, 11;
Rocky Linux 8, 9;
Ubuntu 18.04, 20.04, 22.04.
В нашем случае это будет Ubuntu Server 22.04.2 LTS. Устанавливаем ее в обычном режиме, не разбивая диск на разделы и не выбирая в конце установки никакого дополнительного софта, кроме OpenSSH-сервера.
Загружаемся в свежую ОС и настраиваем доступ по ключу с основного ПК:
$ ssh-copy-id <IP-адрес сервера>Команда не сработает, если ключ не был заранее сгенерирован. Сгенерировать его можно командой ssh-keygen -t rsa.
Подключимся к серверу, чтобы убедиться, что все настроено как нужно:
$ ssh 192.168.2.38
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-60-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Wed Mar 1 11:23:13 AM UTC 2023
System load: 0.0 Temperature: 46.0 C
Usage of /: 2.7% of 292.35GB Processes: 135
Memory usage: 2% Users logged in: 0
Swap usage: 0% IPv4 address for enp3s0: 192.168.2.38
* Introducing Expanded Security Maintenance for Applications.
Receive updates to over 25,000 software packages with your
Ubuntu Pro subscription. Free for personal use.
https://ubuntu.com/pro
Expanded Security Maintenance for Applications is not enabled.
0 updates can be applied immediately.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
Last login: Wed Mar 1 10:34:01 2023 from 192.168.2.35Все работает. Отключаемся от сервера, выполнив команду exit или нажав сочетание клавиш Ctrl + D.
Установка Deckhouse на сервер
Конфигурация будущего кластера
Перейдем на страницу конфигурации будущего кластера в разделе Getting Started официального сайта Deckhouse. Здесь нужно указать шаблон доменных имен для веб-интерфейсов будущих компонентов кластера, таких как Grafana или Kubernetes Dashboard:
Шаблон имеет формат %s.example.com, где %s — имена доменов системных приложений кластера.
Нажмем кнопку Далее: Установка.
На следующей странице отобразится сгенерированное содержимое для файла конфигурации config.yml. Введенный ранее шаблон доменных имен появится в секции publicDomainTemplate:
# Cекция с общими параметрами кластера (ClusterConfiguration).
# Используемая версия API Deckhouse Platform.
apiVersion: deckhouse.io/v1
# Тип секции конфигурации.
kind: ClusterConfiguration
# Тип инфраструктуры: bare metal (Static) или облако (Cloud).
clusterType: Static
# Адресное пространство Pod'ов кластера.
podSubnetCIDR: 10.111.0.0/16
# Адресное пространство для Service'ов кластера.
serviceSubnetCIDR: 10.222.0.0/16
# Устанавливаемая версия Kubernetes.
kubernetesVersion: "1.23"
# Домен кластера.
clusterDomain: "cluster.local"
---
# Секция первичной инициализации кластера Deckhouse (InitConfiguration).
# Используемая версия API Deckhouse.
apiVersion: deckhouse.io/v1
# Тип секции конфигурации.
kind: InitConfiguration
# Секция с параметрами Deckhouse.
deckhouse:
# Используемый канал обновлений.
releaseChannel: Stable
configOverrides:
global:
modules:
# Шаблон, который будет использоваться для составления адресов системных приложений в кластере.
# Например, Grafana для %s.example.com будет доступна на домене grafana.example.com.
publicDomainTemplate: "%s.example.com"
# Включить модуль cni-cilium.
cniCiliumEnabled: true
# Конфигурация модуля
cniCilium:
# Режим работы туннеля.
tunnelMode: VXLAN
---
# Cекция с параметрами bare metal кластера (StaticClusterConfiguration).
# Используемая версия API Deckhouse.
apiVersion: deckhouse.io/v1
# Тип секции конфигурации.
kind: StaticClusterConfiguration
# Список внутренних сетей узлов кластера (например, '10.0.4.0/24'), который
# используется для связи компонентов Kubernetes (kube-apiserver, kubelet...) между собой.
# Если каждый узел в кластере имеет только один сетевой интерфейс,
# ресурс StaticClusterConfiguration можно не создавать.
internalNetworkCIDRs:
- '192.168.2.0/24'Здесь нужно обратить внимание на два момента:
В последней секции сгенерированного конфигурационного файла —
StaticClusterConfiguration— нужно указать сеть, в которую смотрит основной сетевой интерфейс сервера, т. к. на борту их несколько.
☝️ Если на вашей машине один сетевой интерфейс — эту секцию можно удалить.Модуль, реализующий CNI, заменен с cni-flannel на cni-cilium. Это необходимо для работы виртуальных машин — их сетевое взаимодействие организовано на базе Cilium. Также у него указан параметр работы туннелей
tunnelMode: VXLAN.
Сохраним полученное содержимое в файле config.yml, положив его в любой отдельный каталог.
Установка Deckhouse
Для установки платформы используется специальный подготовленный Docker-образ, в который необходимо передать созданный конфигурационный файл и SSH-ключи доступа на master-узел.
Перейдем в каталог с созданным файлом и выполним команду:
docker run --pull=always -it -v "$PWD/config.yml:/config.yml" -v "$HOME/.ssh/:/tmp/.ssh/" registry.deckhouse.io/deckhouse/ce/install:stable bashЧерез некоторое время образ скачается из хранилища, запустится, и в терминале будет отображено приглашение командной строки внутри созданного контейнера:
[deckhouse] root@9134e1cd790b / #Выполним команду:
dhctl bootstrap --ssh-user=<username> --ssh-host=<master_ip> --ssh-agent-private-keys=/tmp/.ssh/id_rsa \
--config=/config.yml \
--ask-become-passНа запрос пароля sudo введем пароль пользователя на сервере.
Если sudo на сервере настроен таким образом, чтобы не запрашивать пароль, не вводите параметр --ask-become-pass.
Установка может занять от 15 до 30 минут, в процессе будет отображаться подробный лог. По завершении мы снова увидим приглашение командной строки контейнера.
Финальная настройка кластера
Осталось выполнить несколько шагов, чтобы кластер был готов к работе.
Добавим конфигурацию kubectl для обычного пользователя, чтобы не вызывать каждый раз sudo:
$ mkdir ~/.kube
$ sudo cat /etc/kubernetes/admin.conf >> ~/.kube/configУбедимся, что теперь вызов команды доступен без повышенных привилегий:
$ kubectl get no
NAME STATUS ROLES AGE VERSION
virtualization-habr Ready control-plane,master 3d20h v1.23.15Так как наш кластер состоит из одного узла, нужно снять с него taint. Для этого выполним на сервере команду:
kubectl patch nodegroup master --type json -p '[{"op": "remove", "path": "/spec/nodeTemplate/taints"}]'Если ваш кластер будет состоять из нескольких узлов, вместо снятия taint'а добавьте в кластер дополнительные узлы.
После этого нужно подождать несколько минут, пока Deckhouse переконфигурируется. Проверить статус можно командой:
kubectl -n d8-system exec deploy/deckhouse -- deckhouse-controller queue listВ ответ будет отображено много текста с описанием модулей, но нас интересует последняя часть:
Summary:
- 'main' queue: empty.
- 68 other queues (1 active, 67 empty): 1 task.
- total 1 task to handle.Если в строке queue значение не empty, значит процесс еще не завершен.
Установка Ingress-контроллера
Создадим на master-узле файл ingress-nginx-controller.yml в отдельном каталоге:
$ mkdir templates
$ cd templates
~/templates$ vim ingress-nginx-controller.ymlСкопируем в файл конфигурацию контроллера:
# Cекция, описывающая параметры nginx ingress controller.
# Используемая версия API Deckhouse.
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
name: nginx
spec:
# Имя Ingress-класса для обслуживания Ingress NGINX controller.
ingressClass: nginx
# Версия Ingress-контроллера (используйте версию 1.1 с Kubernetes 1.23+).
controllerVersion: "1.1"
# Способ поступления трафика из внешнего мира.
inlet: HostPort
hostPort:
httpPort: 80
httpsPort: 443
# Описывает, на каких узлах будет находиться компонент.
# Возможно, захотите изменить.
nodeSelector:
node-role.kubernetes.io/control-plane: ""
tolerations:
- operator: ExistsПрименим его, выполнив команду:
kubectl create -f ingress-nginx-controller.ymlЕсли все прошло успешно, в ответ отобразится сообщение:
ingressnginxcontroller.deckhouse.io/nginx createdСоздание пользователя для доступа в веб-интерфейсы кластера
Чтобы получить доступ в веб-интерфейсы кластера, необходимо создать пользователя, под которым будет выполняться вход. Скопируем содержимое в файл user.yml:
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
name: admin
spec:
# Список учётных записей Kubernetes RBAC.
subjects:
- kind: User
name: admin@deckhouse.io
# Предустановленный шаблон уровня доступа.
accessLevel: SuperAdmin
# Разрешить пользователю делать kubectl port-forward.
portForwarding: true
---
# Секция, описывающая параметры статического пользователя.
# Используемая версия API Deckhouse.
apiVersion: deckhouse.io/v1
kind: User
metadata:
name: admin
spec:
# E-mail пользователя
email: admin@deckhouse.io
# Это хэш пароля byul2sbqfb, сгенерированного сейчас.
# Сгенерируйте свой или используйте этот, но только для тестирования.
# echo "byul2sbqfb" | htpasswd -BinC 10 "" | cut -d: -f2
# Возможно, захотите изменить.
password: '$2a$10$pnQvwsl.gibQ1oM/z3D9g.g6o8v7dkbyqT0wFh7MsA7sUu3GhRwl6'Обратите внимание на раздел password: в комментариях показан пример генерации нового пароля. Обязательно измените пароль, если готовите кластер не для ознакомительных целей!
Применим созданный файл в кластере:
kubectl create -f user.ymlВ случае успешного создания пользователя отобразится сообщение:
clusterauthorizationrule.deckhouse.io/admin created
user.deckhouse.io/admin createdПодготовка DNS-записей
Для доступа к веб-интерфейсам кластера необходимо настроить DNS-записи, ведущие на IP-адрес master-узла кластера. Сделать это можно различными способами: настроить DNS-сервер, прописать соответствие в админ-панели хостера, предоставляющего доменное имя, или же указать нужные записи в файле hosts.
Добавим следующие строки в /etc/hosts на рабочей машине, с которой велась установка:
api.example.com
argocd.example.com
dashboard.example.com
deckhouse.example.com
dex.example.com
grafana.example.com
hubble.example.com
istio.example.com
istio-api-proxy.example.com
kubeconfig.example.com
openvpn-admin.example.com
prometheus.example.com
status.example.com
upmeter.example.comНе забудьте поменять example.com на адрес, указанный в config.yml.
Проверка работоспособности
Теперь убедимся, что кластер развернут и готов к работе. Зайдем в веб-интерфейс Grafana по адресу grafana.example.com. Нас перебросит на страницу входа Dex, где нужно ввести данные созданного ранее пользователя:
После ввода учетных данных откроется главный дашборд Grafana:
Здесь отображается основная информация о компонентах кластера, а также его нагрузка.
Кластер работает. Настало время развернуть в нем виртуальные машины!
Развертывание виртуальных машин
Включение LINSTOR
Для работы с виртуальными жесткими дисками используется модуль linstor, реализующий в кластере поддержку LINSTOR — системы для оркестрации блочных устройств хранения данных в Kubernetes.
Создадим файл linstor.yml:
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: linstor
spec:
enabled: trueИ применим его в кластере:
$ kubectl create -f linstor.yml
moduleconfig.deckhouse.io/linstor createdПодождем пару минут и убедимся, что модуль запущен и работает:
$ kubectl get moduleconfigs
NAME STATE VERSION AGE STATUS
cni-cilium Enabled 1 3d22h
deckhouse Enabled 1 3d22h
global Enabled 1 3d22h
linstor Enabled 1 96sКонфигурация хранилища
Теперь нужно сконфигурировать хранилище.
Добавим alias для удобного управления LINSTOR:
alias linstor='kubectl exec -n d8-linstor deploy/linstor-controller -- linstor'Для сохранения настроек пропишите эту команду в ~/.bashrc — и в новом сеансе SSH команда станет доступна сразу после входа.
Посмотрим список всех доступных для организации хранилища дисковых устройств:
$ linstor physical-storage list
+----------------------------------------------------+
| Size | Rotational | Nodes |
|====================================================|
| 500107862016 | True | officeserver[/dev/sda] |
+----------------------------------------------------+Обратите внимание, что здесь отображаются только пустые диски!
Для некоторых действий с хранилищем может понадобиться использование мастер-пароля, поэтому создадим Secret с ним (файл pass.yml):
apiVersion: v1
kind: Secret
metadata:
name: linstor-passphrase
namespace: d8-system
immutable: true
stringData:
MASTER_PASSPHRASE: *!пароль* # Мастер-пароль для LINSTORИ применим его в кластере:
$ kubectl create -f pass.yml
secret/linstor-passphrase createdТеперь создадим новый пул LVM на отдельном диске /dev/sda, найденном выше:
$ sudo vgcreate vg0 /dev/sda --add-tag linstor-data
Physical volume "/dev/sda" successfully created.
Volume group "vg0" successfully createdПодождем несколько минут пока пул будет создан, и убедимся, что следом за ним создался и StorageClass, в котором будут храниться диски будущих виртуальных машин:
$ kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
linstor-data-r1 linstor.csi.linbit.com Delete Immediate true 2m46sХранилище готово! Можно создавать виртуальные машины.
Включение модуля виртуализации
По умолчанию модуль виртуализации отключен.
Создадим файл virtualization.yml со следующим содержимым:
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: virtualization
spec:
version: 1
enabled: true
settings:
vmCIDRs:
- 10.10.10.0/24В параметре vmCIDRs мы указали подсеть, из которой будут выделяться IP-адреса виртуальным машинам.
Применим модуль на master-узле:
$ kubectl create -f virtualization.yml
moduleconfig.deckhouse.io/virtualization createdПодождем пару минут и проверим, что модуль запустился:
$ kubectl get moduleconfigs
NAME STATE VERSION AGE STATUS
cni-cilium Enabled 1 80m
deckhouse Enabled 1 80m
global Enabled 1 80m
linstor Enabled 1 40m
virtualization Enabled 1 3m26sВ последней строчке состояние модуля должно быть Enabled.
Создание виртуальных машин
Посмотрим перечень ОС, доступных для развертывания на создаваемых виртуальных машинах:
$ kubectl get cvmi
NAME AGE
ubuntu-18.04 80s
ubuntu-20.04 80s
ubuntu-22.04 80sПри первом вызове команда может показать ошибку error: the server doesn't have a resource type "cvmi" — нужно просто подождать и еще раз выполнить запрос.
Создадим файл habr-vm.yml с описанием будущей виртуальной машины:
apiVersion: deckhouse.io/v1alpha1
kind: VirtualMachine
metadata:
name: habr-vm
namespace: default
spec:
running: true
resources:
memory: 8192M
cpu: "4"
userName: ubuntu
sshPublicKey: "ssh-rsa AAAAB3NzaC1yc2EAAAADA ..."
bootDisk:
source:
kind: ClusterVirtualMachineImage
name: ubuntu-22.04
size: 50Gi
storageClassName: linstor-data-r1
autoDelete: trueЗдесь нужно указать параметры будущей виртуальной машины: количество оперативной памяти, имя пользователя, количество ядер CPU и ключ SSH для аутентификации. А также в разделе storageClassName указать созданный ранее StorageClass.
Применим файл на master-узле:
$ kubectl create -f habr-vm.yml
virtualmachine.deckhouse.io/habr-vm createdПодождем некоторое время, пока машина развернется, и убедимся, что она запущена:
$ kubectl get virtualmachines
NAME IPADDRESS STATUS AGE
habr-vm 10.10.10.0 Provisioning 40sСтатус Provisioning говорит о том, что машина успешно создана и в данный момент разворачивается. Как только процесс завершится, статус изменится на Running.
Если вы обнаружили ошибку в конфиге и хотите пересоздать ВМ, сначала удалите развернутую машину, а затем исправьте конфиг и создайте ВМ заново:
$ kubectl delete virtualmachines master-vm
virtualmachine.deckhouse.io "master-vm" deletedПроверка работоспособности
Итак, виртуальная машина развернута и успешно работает. Cilium обеспечивает сетевую связность элементов кластера таким образом, что получить доступ к созданной ВМ можно из любого места, например из Pod'а, развернутого в кластере непосредственно рядом с ВМ.
Создадим демо-Pod для проверки:
$ kubectl run demo --image=ubuntu --rm -it --command -- bash
If you don't see a command prompt, try pressing enter.
root@demo:/#И попробуем «достучаться» до развернутой рядом виртуальной машины. Для этого сначала установим утилиту ping, которой по умолчанию нет в образе Ubuntu, а затем «постучимся» по IP-адресу ВМ:
/# apt update
/# apt install iputils-ping
/# ping 10.10.10.0
PING 10.10.10.0 (10.10.10.0) 56(84) bytes of data.
64 bytes from 10.10.10.0: icmp_seq=1 ttl=63 time=0.310 ms
64 bytes from 10.10.10.0: icmp_seq=2 ttl=63 time=0.356 ms
64 bytes from 10.10.10.0: icmp_seq=3 ttl=63 time=0.410 ms
64 bytes from 10.10.10.0: icmp_seq=4 ttl=63 time=0.384 ms
^C
--- 10.10.10.0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3063msКак видно из лога, прямой доступ из Pod'а в кластере к ВМ есть.
Получение доступа к виртуальной машине извне
Сейчас виртуальная машина доступна только внутри сервера. В таком режиме можно работать, если она требуется только для развертывания отдельного сервиса. Но иногда нужен доступ к ней или ее сервисам снаружи. Предоставить его можно с помощью Service с настроенными externalIPs:
apiVersion: v1
kind: Service
metadata:
labels:
run: master-service
name: master-service
namespace: default
spec:
ports:
- port: 15022
protocol: TCP
targetPort: 22
selector:
vm.kubevirt.io/name: habr-vm
externalIPs:
- 192.168.2.45Здесь мы пробрасываем порт 15022 снаружи кластера на порт 22 ВМ с именем habr-vm, чтобы получить SSH-доступ к машине извне кластера.
Сохраним его в файл external-ip.yml и применим:
$ kubectl create -f external-ip.yml
service/master-service createdУбедимся, что Service создан и работает:
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.222.0.1 <none> 443/TCP 3h50m
master-service ClusterIP 10.222.158.22 192.168.2.45 15022/TCP 6sЗдесь мы воспользовались простым пробросом порта снаружи на ресурс внутри кластера. Такой подход не очень удобен, т. к. требует явного указания порта для соединения по SSH с внутренней ВМ. Если обратиться на порт по умолчанию (22), то мы попадем на master-узел основного кластера.
Для элегантного решения этой проблемы можно воспользоваться модулем metallb Deckhouse, который доступен в Enterprise-версии платформы. С его помощью можно настроить доступ так, чтобы из сети казалось, что у master-узла кластера есть несколько IP-адресов. Это позволит получить доступ к ВМ напрямую по ее IP без проброса разных портов.
Проверим, что теперь мы можем попасть на внутреннюю ВМ снаружи:
$ ssh 192.168.2.45 -p 15022
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-57-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Tue Mar 21 13:24:57 UTC 2023
System load: 0.0 Processes: 128
Usage of /: 2.9% of 48.28GB Users logged in: 0
Memory usage: 3% IPv4 address for enp1s0: 10.10.10.0
Swap usage: 0%
0 updates can be applied immediately.
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Last login: Tue Mar 21 13:16:49 2023 from 192.168.2.35
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
zhbert@habr-vm:~$Заключение
В статье мы рассмотрели пример использования нового модуля виртуализации Deckhouse. С его помощью можно развернуть полноценную виртуальную машину и работать с ней как с ресурсом Kubernetes, используя привычные команды kubectl.
Магия Cilium, основанного на eBPF проекта для реализации сетевого взаимодействия, позволяет обеспечить сетевую связность всех компонентов таким образом, чтобы доступ к виртуальной машине был возможен из любой точки кластера. Благодаря этому ВМ можно использовать для развертывания сервисов, которые по каким-либо причинам невозможно развернуть внутри кластера привычным способом. Более того, на созданных ВМ можно развернуть еще один кластер под управлением Deckhouse, а затем получить доступ к отдельной ВМ уже из него.
С любыми вопросами и предложениями ждем вас в комментариях к статье, а также в Telegram-чате deckhouse_ru, где всегда готовы помочь. Будем рады issues (и, конечно, звёздам) в GitHub-репозитории Deckhouse.
P.S.
Читайте также в нашем блоге:
