Развёртывание локального Kubernetes‑кластера в Termux с помощью k3s и kubeadm

Termux позволяет запускать полноценные пользовательские сервисы в среде Android, а с правильно настроенной сетью — даже имитировать инфраструктуру для обучения и тестов. В этой статье рассмотрим развёртывание локального Kubernetes‑кластера на устройствах под Android через Termux. Практический фокус — на двух подходах: k3s (лёгкий Kubernetes для edge/Dev) и kubeadm (классический процесс инициализации кластера). Оба варианта ориентированы на локальные сценарии: обучение, лабораторные стенды, проверка манифестов и пайплайнов.

Важно: Kubernetes требует сетевого взаимодействия узлов (pod/pod, node/pod). На Android вы упрётесь в ограничения окружения, поэтому ниже мы будем делать акцент на “локальность” и управляемость: один узел для k3s или многоузловость в пределах вашей локальной сети/нескольких устройств.

Что нужно подготовить

Минимальные требования:

Android‑устройство с установленным Termux
Свободное место (K3s/kubeadm + контейнерный runtime + образы)
Сеть: желательно стабильный Wi‑Fi. Вариант “локальной сети” через VPN возможен только как способ связать устройства в одной приватной сети (например, WireGuard в режиме роутинга/bridge внутри вашей сети), но не для обхода блокировок.
Доступ к root‑правам не обязателен для большинства лабораторных сценариев, но может упростить отдельные вещи (например, сетевые ограничения).

Рекомендации по среде:

Делайте лабораторию на одной подсети или обеспечьте L2/L3 связность устройств.
Планируйте статичные IP для “узлов” (DHCP reservation или ручная настройка в вашей среде).
Если используете несколько устройств, проверьте, что они видят друг друга по IP.

Подготовка Termux: обновление пакетов и базовые утилиты

Начните с подготовки окружения.

pkg update -y && pkg upgrade -y
pkg install -y curl wget git nano tar jq

Для Kubernetes обычно также потребуется контейнерный runtime. Для k3s это часто решается автоматически (в зависимости от сборки и режима). Для kubeadm вы обычно выбираете runtime (containerd).

Вариант 1: локальный кластер на k3s в Termux

k3s — популярный способ поднять Kubernetes быстро и с меньшими требованиями к ресурсам. Для Termux самый практичный путь — стартовать кластер как минимум в режиме “один узел” (single node) на одном устройстве, а затем при необходимости расширять до нескольких узлов, если у вас есть связность между устройствами.

1) Установка k3s

Выполните установку бинарника k3s. В Termux удобнее ставить в файловую систему приложения и запускать через user service‑подход. Ниже — один из типовых вариантов.

curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644

Если команда ругается на SELinux/файловые права — исправляйте права каталога или запускайте с корректным окружением. Важно: зависимости и расположения файлов могут отличаться в зависимости от версии и сборки k3s.

2) Проверка работы кластера

Обычно kubeconfig указывает на локальный API сервер, либо требуется скопировать kubeconfig из каталога k3s.

export KUBECONFIG="/etc/rancher/k3s/k3s.yaml"
kubectl get nodes -o wide

Если kubectl не установлен в Termux автоматически, установите его. В некоторых схемах k3s включает kubectl‑обёртку, но в лабораторных условиях удобнее явно поставить kubectl.

pkg install -y kubectl

Проверьте состояние системных pod’ов:

kubectl get pods -A -o wide

3) Подключение кластера с других устройств (локальная сеть)

Чтобы обращаться к API серверу k3s из других устройств в вашей локальной сети, вам нужно сделать кластер “доступным” через сеть. Конкретные параметры зависят от того, как k3s слушает интерфейсы. В лабораторных целях лучше:

Убедиться, что узлы имеют IP в одной подсети
Проверить порты (обычно 6443/TCP для Kubernetes API)
Использовать локальный доступ без “обхода блокировок”

Пример настройки может отличаться, но общий принцип — указать адрес advertise/Bind для API (если это поддерживается в вашей конфигурации). В k3s часто используется файл конфигурации или параметры запуска.

Проверьте доступность с другого устройства:

ping <IP_uzla_termux>
# затем с другого устройства
curl -k https://<IP_uzla_termux>:6443/healthz

Если доступ запрещён политиками Android/фаерволом — вы будете видеть таймауты. Тогда нужно переоценить сетевую схему (например, через VPN в режиме локальной сети между устройствами или через корректную настройку маршрутизации в вашей домашней сети).

4) Развёртывание тестового приложения

Для проверки используйте простой деплой, например Nginx.

kubectl create deployment nginx --image=nginx:stable
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get svc -o wide

Далее откройте NodePort через IP узла:

kubectl get svc nginx -o wide

В поле NODE-PORT укажите порт в браузере/через curl.

Вариант 2: кластер на kubeadm в Termux

kubeadm — “классика” для создания Kubernetes. По сравнению с k3s, это больше ручной работы: подготовка control-plane, настройка containerd, генерация сертификатов, bootstrap токенов и присоединение worker’ов.

Для Termux kubeadm имеет смысл как лабораторный учебный сценарий. Практически обычно стартуют с single control-plane, а затем при наличии нескольких устройств — подключают worker’ы.

1) Установка containerd

Вариант установки зависит от того, доступны ли пакеты containerd в вашей сборке Termux. Типовой маршрут — установить необходимые пакеты и затем развернуть containerd.

pkg install -y proot-distro
# если вы используете proot-окружение для более совместимого linux-слоя, рассмотрите это отдельно

Если containerd установить напрямую не получается, используйте подход с более “совместимым” userland (например, proot‑distro). Поскольку конкретные инструкции зависят от вашей сборки и версии Termux, ниже — общий каркас шагов:

Установить containerd
Сгенерировать конфиг (containerd config)
Запустить containerd
Проверить, что runtime доступен

2) Подготовка системной конфигурации (swap, sysctl)

Kubernetes требует согласованной конфигурации ядра/системы. На Android есть ограничения, и вы можете уткнуться в невозможность применить некоторые sysctl/модули. Для учебной лаборатории часто используют “обходные” режимы (например, отключение swap в userland, где это возможно), но это зависит от вашего уровня прав и конкретных ограничений устройства.

Проверьте swap:

swapon --show

Если swap включен — отключите его (если это возможно в вашем окружении). Далее вам потребуется оценить sysctl‑параметры, которые kubelet пытается выставить. Если sysctl запрещён, вам придётся либо смириться с ошибками и смотреть на фактические требования конкретной версии Kubernetes, либо выбирать более совместимое окружение.

3) Установка kubeadm, kubelet и kubectl

Смысл kubeadm‑подхода — поставить компоненты Kubernetes нужной версии и согласовать их.

В Termux пакеты могут быть недоступны “из коробки”, поэтому часто делают установку из официальных релизов (tarballs) или используют proot‑окружение. Общий пример:

# В реальности URL и версии подставьте под ваши требования
# (команды ниже — шаблон логики, не привязанный к точным версиям)
curl -LO https://dl.k8s.io/release/<version>/bin/linux/amd64/kubeadm
curl -LO https://dl.k8s.io/release/<version>/bin/linux/amd64/kubectl
curl -LO https://dl.k8s.io/release/<version>/bin/linux/amd64/kubelet
chmod +x kubeadm kubectl kubelet

Далее разместите бинарники в каталогах PATH, например:

mv kubeadm kubectl kubelet $HOME/bin/ 2>/dev/null || true

Проверьте версии:

kubeadm version
kubectl version --client

4) Инициализация control-plane: kubeadm init

Инициализация выполняется примерно так (шаблон; параметры подставьте под вашу схему):

kubeadm init --pod-network-cidr="10.244.0.0/16"

Обычно kubeadm выводит инструкции для установки CNI. На Termux CNI особенно важен: без него pod’ы не получат сеть.

После успешного init вы получите kubeconfig для kubectl.

mkdir -p $HOME/.kube
cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
kubectl get nodes

5) Установка CNI (сетевой плагин)

Наиболее распространённый вариант — Flannel или Calico. Для лаборатории можно использовать Flannel:

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Проверьте, что системные pod’ы перешли в Running:

kubectl get pods -A -o wide

6) Добавление worker’ов (если есть несколько устройств)

Для multi-node сценария на kubeadm нужно использовать token discovery и инструкции kubeadm join. На control-plane выполните:

kubeadm token create --print-join-command

На worker’е выполните команду join (с подстановкой). Важно обеспечить, чтобы worker по сети мог достучаться до API server control-plane.

Сетевая часть — ключевой момент: проверьте reachability по IP и порты.

Сетевые нюансы и типовые ошибки в Termux

Даже при успешной установке k3s/kubeadm вы можете столкнуться с проблемами сети:

Подов “нет” или Pending — чаще всего CNI не установлен/не работает.
API недоступен с другого устройства — нужен доступ к порту 6443 и корректная привязка/адресация.
MTU и фрагментация — иногда проявляется в виде нестабильных подключений.
Ограничения Android — некоторые sysctl/модули ядра могут быть недоступны.
DNS — проверьте, что kube-system компоненты и CoreDNS функционируют.

Практичный минимум диагностики:

kubectl get nodes -o wide
kubectl describe node <node>
kubectl get pods -A -o wide
kubectl describe pod <pod> -n <ns>

Если кластер создаётся в “одном устройстве”, многие сетевые сложности уходят, но проблема изоляции/доступа остаётся. Если же вы строите многоузловость — ориентируйтесь на стабильную локальную сеть.

Сравнение подходов: k3s vs kubeadm

Критерий	k3s	kubeadm
Сложность старта	Ниже	Выше
Назначение	Edge/лаборатории, быстрый кластер	Обучение и максимально “каноничный” процесс
Гибкость настройки	Ограниченно/сценарно	Широко, но требует ручной сборки компонентов
Вероятность сетевых проблем в Termux	Обычно ниже при single-node	Может быть выше из-за зависимостей runtime/CNI/sysctl

Практический сценарий “с чего начать”

Для быстрого результата начните с k3s в режиме single node на одном Termux‑устройстве.
Проверьте: узлы Running, CNI ок, тестовое приложение доступно.
Если ваша цель именно “как в проде” — переходите к kubeadm и отдельно фиксируйте версии Kubernetes и CNI.
Для многоу слоевности добавляйте устройства только после подтверждения сетевой достижимости по IP и портам.

Заключение

Развёртывание локального Kubernetes‑кластера в Termux — реальная лабораторная практика, особенно если вы начинаете с k3s для быстрого подтверждения жизнеспособности сети и базовых компонентов. Когда цель — изучение канонического процесса, используйте kubeadm, но закладывайте больше времени на согласование runtime, сети (CNI) и системных ограничений Android.

Если вам нужна помощь с подбором архитектуры стенда, настройкой сети для нескольких устройств или разбором ошибок (CNI, API доступ, runtime), команда РыбинскЛАБ поможет: от консультации до сопровождения внедрения.