Вероятно, вы не должны иметь прямой доступ к Docker API из любой точки Kubernetes. Kubernetes будет совершенно не в курсе всего, что вы вручную docker run (или эквивалент), и, как вы заметили, обычные административные вызовы, такие как kubectl get pods, не увидят этого; ЦП и память, используемые модулем, не будут известны интерфейсу узла, и это может привести к чрезмерному использованию узла. Сетевое окружение Kubernetes также довольно сложное, и если вы не знаете подробностей вашего конкретного поставщика CNI, вам будет сложно сделать ваш контейнер вообще доступным, а тем более из модуля, работающего на другом узле.
Процесс, запущенный в модуле, может напрямую обращаться к API Kubernetes . На этой странице отмечается, что все официальные клиентские библиотеки знают о соглашениях, которые используются. Это означает, что вы должны иметь возможность напрямую создать задание, которое запускает ваш целевой модуль, и службу, которая подключается к нему, и получать обычные функции Kubernetes для этого. (Например, servicename.namespacename.svc.cluster.local является действительным DNS-именем, которое достигает любого Пода, подключенного к Сервису.)
Вы также должны подумать, нужен ли вам этот интерфейс. Для многих приложений также будет работать развертывание некоторой системы очереди сообщений (, например, , RabbitMQ), а затем запуск пула рабочих, подключенных к нему. Вы можете контролировать размер рабочей очереди, используя Развертывание. Его легче разработать, поскольку он позволяет избежать жесткой зависимости от Kubernetes, и им легче управлять, поскольку он предотвращает переполнение кластера динамическими заданиями.