Проблемы взаимодействия разработчиков с облачными инфраструктурами на базе Kubernetes в тестовых средах

УДК 004.451.26

doi: 10.21685/2072-3059-2023-3-3

Проблемы взаимодействия разработчиков с облачными инфраструктурами на базе Kubernetes в тестовых средах

Д. С. Фомин1, А. В. Бальзамов2, А. В. Савкина3, С. А. Федосин4

1,2'3,4Национальный исследовательский Мордовский государственный университет имени Н. П. Огарева, Саранск, Россия

1nkfominsa@gmail.com, 2balzamovav@yandex.ru, 3av-savkina@yandex.ru, 4fedosinsa@mrsu.ru

Аннотация. Актуальность и цели. Объектом исследования являются проблемы, возникающие во время взаимодействия разработчиков с облачными инфраструктурами. Предметом исследования являются методы обеспечения корректной работы облачных инфраструктур с Kubernetes в тестовых средах. Цель работы - поиск оптимального метода решения проблем непосредственного сетевого доступа к контейнерам Kubernetes и взаимодействия с его нодами кластера извне. Материалы и методы. Исследования проводились в области архитектурных решений и DevOps при построении высоконагруженных систем с использованием инструментов для построения виртуального DNS и для упрощенного взаимодействия с нодами кластера. Результаты. Проведен анализ проблем, возникающих при работе с кластерами Kubernetes в тестовых средах и предложены методы решения рассмотренных проблем. Выводы. Предложенные подходы позволяют использовать дополнительные инструменты для работы с тестовыми и рабочими кластерами Kubernetes, что помогает снизить сложность взаимодействия разработчиков с ними и повысить скорость развертывания и масштабируемость. Кроме того, описанные методы позволяют упростить администрирование крупных сетей.

Ключевые слова: дистрибутив, система, контейнеры, безопасность, приложение Для цитирования: Фомин Д. С., Бальзамов А. В., Савкина А. В., Федосин С. А. Проблемы взаимодействия разработчиков с облачными инфраструктурами на базе Ku-bernetes в тестовых средах// Известия высших учебных заведений. Поволжский регион. Технические науки. 2023. № 3. С. 31-40. doi: 10.21685/2072-3059-2023-3-3

Issues of developer interaction with Kubernetes-based cloud infrastructures in test environments

D.S. Fomin1, A.V. Bal'zamov2, A.V. Savkina3, S.A. Fedosin4

1,2'3,4Ogarev Mordovia State University, Saransk, Russia 1nkfominsa@gmail.com, 2balzamovav@yandex.ru, 3av-savkina@yandex.ru, 4fedosinsa@mrsu.ru

Abstract. Background. The object of the study is the issues that arise during the interaction of developers with cloud infrastructures. The subject of the research is methods for ensuring their correct operation with Kubernetes in test environments. The purpose of the study is to find the optimal method for solving the problems of direct network access to Kuber-netes containers and interaction with its cluster nodes from the outside. Materials and

© Фомин Д. С., Бальзамов А. В., Савкина А. В., Федосин С. А., 2023. Контент доступен по лицензии Creative Commons Attribution 4.0 License / This work is licensed under a Creative Commons Attribution 4.0 License.

methods. Research in the field of architectural solutions and DevOps in building high-load systems. Tools for building a virtual DNS and for simplified interaction with cluster nodes. Results. The paper analyzes the problems that arise when working with Kubernetes clusters in test environments and proposes methods for solving the problems considered. Conclusions. The proposed approaches allow the use of additional tools for working with test and production Kubernetes clusters, which reduces the complexity of developer interaction with them and increases deployment speed and scalability. In addition, the described methods make it possible to simplify the administration of large networks. Keywords: distribution kit, system, containers, security, application For citation: Fomin D.S., Bal'zamov A.V., Savkina A.V., Fedosin S.A. Issues of developer interaction with Kubernetes-based cloud infrastructures in test environments. Izvestiya vys-shikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2023;(3):31-40. (In Russ.). doi: 10.21685/20723059-2023-3-3

Введение

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

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

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

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

При изучении указанных проблем были определены методы их решения для упрощения дальнейшей работы с кластером.

Проблема взаимодействия с нодами кластера Kubernetes

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

Самым эффективным способом решения указанной проблемы является использование программного обеспечения Ansible - системы управления конфигурациями, которая применяется для автоматизации настройки и развертывания программного обеспечения [1]. Основной операционной системой, на которой используется Ansible, является Linux. В этом случае связь нод кластера с хостовой машиной производится по сетевому протоколу SSH, что упрощает доступ к командам администратора без дополнительных настроек.

Для использования Ansible на каждой машине, на которой предположительно будет располагаться нода кластера, должны быть установлены SSH и Python [2].

Следующим шагом будет копирование открытого SSH-ключа с хостовой машины на рабочие. После переноса открытых ключей можно написать первый тестовый Playbook и заполнить файл hosts. Файл hosts содержит описание адресов и данных машин, с которыми Ansible будет взаимодействовать. Пример файла hosts представлен на рис. 1.

[controT._pl.ane]

controll ansible_host=192.168.74.138 ansible_user=root ansible_pas [workers]

workerl ansible_host=192.168.74.139 ansible_user=root ansib"Le_pass worker2 ansible_host=192.168.74.140 ansibte_user=root ansible_pass шогкегЗ ansible_host=192.168.74.141 ansible_user=root ansible_pass

[all:vars]

ansible_python_interpreter=/usr/bin/python3

Рис. 1. Файл hosts

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

Playbook - конфигурационный выполняемый файл для Ansible, в котором описываются выполняемые действия на требуемых машинах. Указанный файл может включать самые гибкие настройки и запоминать переменные, заполняемые на одной машине, для переноса их на другие. На рис. 2 представлен код playbook файла для настройки master ноды с генерацией и сохранением секретного ключа для присоединения worker нод.

hosts', control._plano bacon): yD5

tutu:

- nam: initialize the cluster

shall: kuboadn init —pod-notwork-cidr=10. 2JIM .8,6/16 --nodo~naHC=aast«r

- nut! wait kubeadii init conmaivd wait_for:

tinoout; 129

- nuc: create .kube directory shall: nfcdir -/.hufae

- naiier copy adnin.conf to user's kube con fig

shell: In -s /etc/kubernetes/adwin.conf /root/.Uube/config

- nan«; install Pod network beceae: yes

b*c«a_user: ansiblehost

shall: kubectl apply -f https://raw.githubusnrcontontcan/cproos/flannol/astar/Docuncntatipn/tmbo-Flannol-yal » pod_network_sotup.txt argj:

ctodir: J HOME

crcrjtDi: pod_natvOrk_satup.txt

Рис. 2. Playbook файл

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

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

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

Кроме того, после установки инструмента Ansible можно использовать Kubespray - специально настроенный набор команд для ускоренного развертывания кластера с дополнительными настройками, который позволит установить желаемые стартовые настройки для кластера и развернуть его одной командой [3].

Для использования Kubespray необходимо сделать копию GitHub репо-зитория: https://github.com/kubernetes-sigs/kubespray.git, а затем перейти в загруженный каталог. Сделать копию папки /inverntory/sample, перейти в нее и настроить требуемые параметры будущего кластера в файлах group_vars/k8s_cluster/addons.yml и group_vars/k8s_cluster/k8s-cluster.yml. Для описания стека серверов, на которые необходимо установить кластер, нужно внести изменения в файл inventory.ini, аналогично файлу hosts, представленному на рис. 1.

Kubespray работает на базе утилиты Ansible, и потому необходимо также провести стартовую настройку виртуальных машин, описанную ранее. Одним из преимуществ Kubespray является то, что устанавливать Ansible на master ноду не нужно, так как его компиляция и выполнение происходят в пространстве проекта Python, предоставляемого с Kubespray. Для сбора необходимых зависимостей для развертывания следует выполнить следующий набор команд в папке Kubespray: mkdir venv

python3 -m venv ./venv source ./venv/bin/activate pip install -r requirements.txt

Затем выполняется следующая команда, запускающая развертывание кластера: ansible-playbook -i ./inventory/lab/inventory.ini --become --become-user=root cluster.yml [4]. Развертывание занимает от 15 до 30 мин в зависимости от скорости интернет-соединения и вычислительных мощностей виртуальных машин. По завершении работы Kubespray можно проверить состояние нового кластера с одной master нодой и тремя worker нодами с помощью следующей команды на master ноде: kubectl get nodes. Результат ее выполнения представлен на рис. 3.

NAME STATUS ROLES AGE VERSION

masterl Ready control-plane 51m vl.24.6

workerl Ready <попе> 49m vl.24.6

worker2 Ready <none> 49m vl.24.6

worker3 Ready <none> 49m vl.24.6

Рис. 3. Развернутый кластер Kubemetes

Для упрощенного доступа к сервисам из сети хостовой машины на этапе заполнения параметров Kubespray включается поддержка ingress-nginx контроллера и балансировщика нагрузки MetalLB в режиме Layer2 [5]. Для MetalLB выделяется пул IP-адресов, которые могут быть заняты новыми сервисами. MetalLB берет адрес из указанного диапазона, назначает его одной из нод и сообщает об этом окружающим посредством ARP или BGP. Все запросы, приходящие на заданный адрес, он направляет соответствующему сервису Kubernetes. Если нода внезапно перестает работать, то MetalLB переназначает IP другой ноде [6].

Проблема непосредственного сетевого доступа к контейнерам Kubernetes

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

Одним из вариантов, предлагаемых самими разработчиками Kubernetes, является использование proxy для доступа к необходимым сервисам. К примеру, для доступа к панели управления кластером необходимо добавить сервис proxy, и производить вход в панель администрирования с помощью генерируемого при каждом запуске уникального ключа.

Второй вариант от производителя - это запускать сервис proxy на одной из master нод. Данный способ также включает обновляемый секретный ключ.

Указанные способы рекомендуются разработчиком только для тестовых сред и строго запрещены при production (производственном) развертывании. В реальности оба способы неприменимы даже для тестовых сред, так как во время тестирования нередко происходят плановые перезагрузки, что влечет повторное развертывание.

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

До выпуска версии Kubernetes 1.11 служба Kubernetes DNS была основана на kube-dns. В версии 1.11 появилась версия службы CoreDNS, устраняющая ряд проблем kube-dns со стабильностью и безопасностью.

Вне зависимости от того, какое программное обеспечение обрабатывает записи DNS, оба варианта работают одинаково:

- создается служба с именем kube-dns и один или несколько подов;

- служба kube-dns прослушивает события службы и события конечных точек, которые активируются при создании, обновлении или удалении служб Kubernetes и связанных с ними подов через Kubernetes API, и обновляет записи DNS по мере необходимости;

- происходит проверка создания подов kubelet, которая задает опцию /etc/resolv.conf nameserver для каждого нового пода как IP-адрес кластера службы kube-dns с соответствующими опциями поиска, позволяющими использовать более короткие имена хостов;

- для работающих в контейнерах приложений можно разрешать такие имена хостов, как example-service.namespace, и они будут считаться корректными IP-адресами кластера [7].

Для внутренней маршрутизации Kubernetes по стандарту также использует домен svc.cluster.local, которому дописывается имя сервиса и его namespace. Полное имя для внутреннего доступа к сервису будет выглядеть так: service.namespace.svc.cluster.local (рис. 4), но данное доменное имя доступно только внутри кластера Kubernetes (при развертке сервисов каждому поду приложения). Из этого следует, что для тестирования и разработки приложений, которые в последующем будут размещаться и функционировать на кластере Kubernetes, необходимо, как было уже описано выше, использовать proxy или создавать DNS-записи в файле hosts на компьютере разработчика с конфигурацией подов на использование внешнего IP-адреса (IP-адреса хо-стовой машины, на которой в данный момент развернут под). Так как сеть Kubernetes закрытая, компьютер разработчика ничего про нее не знает и не имеет к ней доступа. Поскольку под - это расходный материал в Kubernetes и у него есть жизненный цикл, то после перезапуска Kubernetes может развернуть его на другой ноде, и внешний адрес пода изменится, что делает разработку и отладку всей программной инфраструктуры трудоемкой.

Для устранения данных проблем у Kubernetes имеется объект Сервис. Сервис в Kubernetes - это абстрактный объект, который определяет логический набор подов и политику доступа к ним. Сервисы создают слабую связь между подами, которые от них зависят, позволяют приложениям принимать трафик, могут быть по-разному открыты, в зависимости от указанного поля type в ServiceSpec.

• ClusterIP (по умолчанию) - открывает доступ к сервису по внутреннему IP-адресу в кластере. Этот тип делает сервис доступным только внутри кластера.

• NodePort - открывает сервис на одном и том же порту каждого выбранного узла в кластере с помощью NAT. Делает сервис доступным вне кластера, используя <NodeIP>:<NodePort>. Является надмножеством ClusterlP.

• LoadBalancer - создает внешний балансировщик нагрузки в текущем облаке (если это поддерживается) и назначает фиксированный внешний IP-адрес для сервиса. Является надмножеством NodePort.

• ExternalName - открывает доступ к сервису с указанным именем (определенным в поле externalName в спецификации) и возвращает запись CNAME; proxy не используется. Для этого типа требуется версия kube-dns 1.7 или выше [8].

resolv.conf

nameserver 19.32.е.IB

search namespace.svc.cluster.local svc.cluster.local cluster.local options ndots:5

Рис. 4. Конфигурация пода DNS Kubernetes

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

Рис. 5. Схема работы сервисов в Kubernetes

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

Эффективным и масштабируемым решением для организации внешнего сетевого доступа является использование Ingress-контроллера в кластере

Kubemetes и установка локального DNS-сервера. Ingress-контроллер - это сущность Kubernetes кластера, которая отвечает за работу с внешним трафиком и его маршрутизацию.

Основные преимущества использования ingress контроллеров:

• Реализация Ingress-контроллера может быть на базе различного популярного и проверенного программного обеспечения: nginx, haproxy, traefik и др. Стандартно Kubernetes использует контроллер на базе Nginx.

• Так как Ingress-контроллер работает на седьмом уровне модели OSI, в то время как сервис на третьем, использование Ingress контроллеров позволяет разворачивать поды вместе с сервисами в режиме NodeType, а также настраивать все внутреннее и внешнее сетевое общение на основе доменных имен.

• Существует единая точка для конфигурации, управления и мониторинга всего внешнего и внутреннего взаимодействия [9].

После конфигурации Ingress-контроллера необходимо развернуть локальный DNS-сервер. В качестве примера можно использовать популярный и проверенный DNS-сервер BIND9. Данный программный продукт очень легкий и работает на всех популярных операционных системах. После его установки и настройки необходимо добавить свою собственную зону (домен) и перенаправление на master ноды Kubernetes-сервера, где, в свою очередь, запросы уже будет перехватывать и обрабатывать Ingress-контроллер (рис. 6) [10].

fetc/bind/zones/db.nyc3.example.com — updated

JTTL 604800

IN SOA nsl. пусЗ .example. corn . admir. nyc3.example. com . (

3 ; Serial

604800 ; Refresh 86400 ; Retry 2419200 ; Expire 664860 ) ; Negative Cache TTL

name servers  IN MS

IN MS

NS records

nsl.nyc3.example. com . ns2.nyc3.example. com .

; name servers - A records

rsl. ryc3.exannple.com. IN A 10.128.10.11

rs2.ryc3.example.com. IN A 13.128.20.12

; 16.128.0.0/16 - A records

hostl.nyc3.example.com. IN A 10.128.100.101

host2.nyc3.example.com. IN A 10.128.200.102

Рис. 6. Пример конфигурации DNS сервера BIND9 Заключение

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

рами Kubernetes в тестовых и продуктивных средах, к тому же, что очень важно отметить, чем больше кластеры и их количество, тем более эффективными окажутся мероприятия по внедрению Ansible и BIND9.

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

Список литературы

1. Ansible. URL: https://www.ansible.com/ (дата обращения: 01.02.2023).

2. SSH Essentials: Working with SSH Servers, Clients, and Keys. URL: https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys (дата обращения: 03.02.2023).

3. Установка HA Master Kubernetes кластера с помощью Kubespray. URL: https://habr.com/ru/post/344704/ (дата обращения: 05.02.2023).

4. Kubespray - Deploy a Production Ready Kubernetes Cluster. URL: https://kubespray.io/ (дата обращения: 10.02.2023).

5. Введение в современную сетевую балансировку и проксирование. URL: https://habr.com/ru/company/vk/blog/347026/ (дата обращения: 13.02.2023).

6. Bare-metal considerations - NGINX Ingress Controller. URL: https://kubernetes. github.io/ingress-nginx/deploy/baremetal/ (дата обращения: 14.02.2023).

7. Создание сервиса для открытия доступа к приложению. URL: https://kubernetes.io/ru/docs/tutorials/kubernetes-basics/expose/expose-intro/ (дата обращения: 16.02.2023).

8. Основы Kubernetes. URL: https://habr.com/ru/articles/258443/ (дата обращения: 16.02.2023).

9. Маркелов А. Введение в технологии контейнеров и Kubernetes. М. : ДМК Пресс, 2019. С. 110-152.

10. Bilgin Ibryam, Roland Huft. Kubernetes Patterns. CA : O'Reilly Media, 2016. 42 с.

References

1. Ansible. Available at: https://www.ansible.com/ (accessed 01.02.2023).

2. SSH Essentials: Working with SSH Servers, Clients, and Keys. Available at: https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys (accessed 03.02.2023).

3. Ustanovka HA Master Kubernetes klastera spomoshch'yu Kubespray = Installation on HA Master Cyber cluster using Kubespray. (In Russ.). Available at: https://habr.com/ru/ post/344704/ (accessed 05.02.2023).

4. Kubespray - Deploy a Production Ready Kubernetes Cluster. Available at: https://kubespray.io/ (accessed 10.02.2023).

5. Vvedenie v sovremennuyu setevuyu balansirovku i proksirovanie = Introduction to Modern Network Balancing and Proxying. (In Russ.). Available at: https://habr.com/ru/ company/vk/blog/347026/ (accessed 13.02.2023).

6. Bare-metal considerations - NGINX Ingress Controller. Available at: https://kubernetes.github.io/ingress-nginx/deploy/baremetal/ (accessed 14.02.2023).

7. Sozdanie servisa dlya otkrytiya dostupa k prilozheniyu = Creating a service to open access to the application. (In Russ.). Available at: https://kubernetes.io/ru/docs/ tutorials/kubernetes-basics/expose/expose-intro/ (accessed 16.02.2023).

8. Osnovy Kubernetes = Kubernetes Basics. Available at: https://habr.com/ru/articles/ 258443/ (accessed 16.02.2023).

9. Markelov A. Vvedenie v tekhnologii konteynerov i Kubernetes = Introduction to container technologies and Kubernetes. Moscow: DMK Press, 2019:110-152.

10. Bilgin Ibryam, Roland Huß. Kubernetes Patterns. CA: O'Reilly Media, 2016:42.

Информация об авторах / Information about the authors

Дмитрий Сергеевич Фомин аспирант, Национальный исследовательский Мордовский государственный университет имени Н. П. Огарева

E-mail: nkfominsa@gmail.com

Dmitriy S. Fomin

Postgraduate student, Ogarev Mordovia State University

Александр Витальевич Бальзамов аспирант, Национальный исследовательский Мордовский государственный университет имени Н. П. Огарева

E-mail: veron13rus@yandex.ru

Aleksandr V. Bal'zamov

Postgraduate student, Ogarev Mordovia State University

Анастасия Васильевна Савкина

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

E-mail: av-savkina@yandex.ru

Anastasiya V. Savkina Candidate of engineering sciences, associate professor, associate professor of the sub-department of automated information processing and control systems, Ogarev Mordovia State University

Сергей Алексеевич Федосин

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

E-mail: fedosinsa@mrsu.ru

Sergey A. Fedosin

Candidate of engineering sciences, professor, head of the sub-department of automated information processing and control systems, Ogarev Mordovia State University

Авторы заявляют об отсутствии конфликта интересов / The authors declare no conflicts of interests.

Поступила в редакцию / Received 15.03.2023

Поступила после рецензирования и доработки / Revised 11.05.2023 Принята к публикации / Accepted 19.08.2023