Развёртывание распределённого кластера Kubernetes через Termux на Android‑устройствах с помощью K3s и Helm

Распределённые кластеры Kubernetes на «железе, которое всегда под рукой» — задача не из простых, но решаемая. В этой статье описан практический подход к развёртыванию распределённого кластера Kubernetes на Android‑устройствах с использованием Termux, K3s (лёгкого Kubernetes) и Helm. Акцент сделан на корректной сетевой связности узлов и управляемости состояния кластера.

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

Что понадобится

Android‑устройства (минимум 2 для распределённого кластера; 3 — для более реалистичной схемы).
Termux на каждом устройстве.
Сетевая связность между узлами: устройства должны быть в одной локальной сети (Wi‑Fi), либо иметь локальную связность через VPN/туннель для построения локальной сети между узлами.
Достаточные ресурсы: хотя K3s лёгкий, устойчивость кластера зависит от CPU/RAM. Рекомендуется начинать с 2–4 ГБ RAM на узел.
Образ приложений и/или возможность публикации в доступный registry (например, локальный registry в вашей сети).

Архитектура: master/agent на Android

Для распределённого кластера мы обычно выделяем:

Control Plane (master) — узел, который хранит состояние кластера и выполняет контролирующие компоненты.
Worker (agent) — узлы, на которых запускаются ваши приложения.

В K3s это разделение обеспечивается режимами установки: на master K3s поднимается как сервер, на agent — как агент с присоединением к серверу.

Подготовка Termux: общие принципы

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

На каждом Android‑устройстве запустите Termux и выполните базовую подготовку.

pkg update -y
pkg upgrade -y
pkg install -y curl tar ca-certificates openssh wget

Проверьте базовую связность между устройствами: с master попробуйте пинг/подключение к агенту по IP (если ICMP доступен в вашей сети). Часто проще проверить доступность портов.

Сетевая модель: локальная сеть и адреса

Чтобы узлы Kubernetes могли обмениваться данными, они должны видеть друг друга по IP в одной локальной сети.

Узнайте IP адреса устройств в сети Wi‑Fi (например, в настройках роутера или в информации о соединении).
Убедитесь, что нет правил изоляции между клиентами (некоторые настройки Wi‑Fi “Guest” или “AP isolation” мешают).
Если требуется — организуйте локальную сеть через VPN, только для установления локальной связности между устройствами, а не для обхода ограничений.

Далее потребуется переменная MASTER_IP — IP устройства, где будет развернут server K3s.

Установка K3s на master (server)

На узле master установите K3s в режиме сервера. K3s можно поднять стандартным установщиком; ключевой момент — корректно указать адреса, а также интерфейс, если у вас есть несколько сетей.

Пример для установки K3s Server:

curl -sfL https://get.k3s.io | sh -s - server --node-ip <MASTER_IP>

После завершения проверьте статус службы K3s. На Android (Termux) это будет зависеть от того, как устроен запуск (daemon/service). Практически полезно проверить наличие сокета и вывод логов.

ls -la ~/.k3s
ps aux | grep k3s

Также часто необходимо получить токен для присоединения агентам. В типичной конфигурации K3s хранит его в файле.

cat ~/.k3s/server/node-token

Скопируйте токен и сохраните его в безопасном месте — он понадобится на worker‑узлах.

Установка K3s на worker (agent) и присоединение к master

На каждом worker‑устройстве установите K3s в режиме agent. Здесь используется токен и адрес master.

Пример:

curl -sfL https://get.k3s.io | sh -s - agent --server https://<MASTER_IP>:6443 --token <NODE_TOKEN> --node-ip <WORKER_IP>

После установки убедитесь, что агент появился в кластере с точки зрения control plane.

На master выполните:

kubectl get nodes -o wide

Если kubectl не установлен или не настроен, его можно использовать из K3s. На практике это зависит от того, как установлен K3s в Termux. Если используется локальный kubeconfig, можно временно экспортировать переменные или скопировать kubeconfig.

Настройка kubectl и kubeconfig

Обычно K3s формирует kubeconfig в домашней директории. Проверьте наличие файла.

ls -la ~/.k3s
ls -la ~/.k3s/kubeconfig.yaml

Если kubeconfig.yaml доступен, настройте переменную:

export KUBECONFIG=~/.k3s/kubeconfig.yaml
kubectl get nodes

Для удобства можно создать alias, но в лабораторных условиях достаточно экспорта.

Проверка работоспособности кластера

Перед тем как идти дальше, выполните базовую проверку:

Состояние нод: все ноды должны быть в статусе Ready.
Работа CoreDNS: проверьте системные поды.

kubectl get nodes
kubectl get pods -A
kubectl get svc -A

Если поды не стартуют, в первую очередь проверяйте сетевые правила в локальной сети, доступность портов и корректность --node-ip на всех узлах.

Установка Helm в среду управления

Helm — стандартный инструмент управления пакетами в Kubernetes. Для работы с Helm не обязательно устанавливать его на всех узлах; достаточно рабочего места (например, на master или отдельном Android/ПК).

На узле master в Termux установите Helm (вариант зависит от текущих инструкций проекта). Примерно используйте загрузку релиза и распаковку.

HELM_VERSION="v3.14.4"
wget -qO- https://get.helm.sh/helm-$HELM_VERSION-linux-arm64.tar.gz | tar -xz
mv linux-arm64/helm ~/$USER/bin/helm
chmod +x ~/$USER/bin/helm

Проверьте:

helm version

Если ваша архитектура не arm64, используйте правильный архив. Лабораторно удобнее сначала узнать архитектуру через Termux:

uname -m

Конфигурация Helm: работа через kubeconfig

Чтобы Helm корректно использовал ваш kubeconfig, убедитесь, что переменная KUBECONFIG экспортирована в текущем сеансе:

export KUBECONFIG=~/.k3s/kubeconfig.yaml
helm repo list

Деплой приложения через Helm: практический сценарий

Для демонстрации деплоя удобно использовать готовый чарт. Например, Nginx Ingress Controller или простой веб‑сервис. Рассмотрим типовой подход:

добавить репозиторий чартов;
обновить индексы;
выполнить установку в namespace;
проверить состояние ресурсов.

Пример для установки простого приложения из репозитория:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
kubectl create namespace demo || true
helm install web-demo bitnami/nginx-ingress --namespace demo

Далее проверьте:

kubectl get pods -n demo
kubectl get svc -n demo

Если вы используете сервис типа LoadBalancer, в локальной среде он может не быть доступен. Для Android‑лаборатории чаще применяют NodePort, ClusterIP с проксированием или Ingress с контроллером.

Ingress в локальном кластере: важные нюансы

Ingress добавляет удобство доступа к приложениям по URL, но требует контроллера Ingress и маршрутизации.

Убедитесь, что контроллер Ingress поднят.
Проверьте, что сервис контроллера доступен из вашей локальной сети (например, через NodePort).
Если используете TLS, настройте сертификаты для тестовой доменной зоны или применяйте самоподписанные сертификаты (для лабораторной среды).

Устойчивость на Android: жизненный цикл, ресурсы и автозапуск

Android может ограничивать фоновые процессы, особенно при уходе экрана в спящий режим. Для лабораторных экспериментов стоит учитывать:

использование режима энергосбережения/оптимизации: проверьте, не убивает ли система Termux или дочерние процессы;
перевод Termux/K3s в исключения батареи (если разрешено политиками устройства);
логирование и мониторинг: периодически смотрите kubectl get events и поды.

Базовая проверка событий:

kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -n 50

Практика: масштабирование узлов

Чтобы добавить ещё один worker, повторите процесс установки агента на новом устройстве, используя тот же --server https://<MASTER_IP>:6443 и тот же node-token. После этого на master вы должны увидеть ноду в списке.

kubectl get nodes -o wide

В случае проблем чаще всего виноваты:

неверно указан --node-ip (узел анонсирует не тот интерфейс);
IP адреса поменялись (DHCP) и один из узлов «отвалился»;
локальная сеть блокирует peer‑to‑peer трафик.

Обслуживание: обновления K3s и перезапуски Helm релизов

Обновления K3s и Helm релизов лучше выполнять поэтапно:

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

Для Helm удобно использовать:

helm list -A
helm status web-demo -n demo
helm upgrade web-demo bitnami/nginx-ingress --namespace demo

Безопасность и доступы: базовые рекомендации

Храните node-token конфиденциально.
Ограничьте доступ к API server в вашей локальной сети (если есть возможность — сегментируйте Wi‑Fi, запретите гостевым клиентам).
Для лаборатории используйте минимально необходимые права и аккуратнее относитесь к публикации сервисов наружу.

Заключение

Развёртывание распределённого кластера Kubernetes через Termux на Android с K3s и Helm — выполнимая инженерная задача при условии корректной сетевой связности узлов и внимательной настройки IP адресов. Для лабораторной практики такой подход даёт быстрый старт, гибкость в экспериментах и понятный путь к дальнейшему усложнению (Ingress, мониторинг, управление релизами Helm).

Если вы хотите сделать это быстрее, стабильнее и с учётом ваших условий (количество устройств, тип сети, требования к доступности приложений), обратитесь за консультацией и настройкой в РыбинскЛАБ — поможем спроектировать схему, подготовить инфраструктуру и довести кластер до рабочего состояния.