Развёртывание и управление Kubernetes‑кластерами из Termux через kubeadm и kubectl

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

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

Требования и ограничения

Termux на Android (желательно актуальная версия).
Один или несколько узлов Linux, где будет работать kubeadm (например, VM в локальной сети или на сервере).
Сеть между Termux и узлами кластера: доступ по SSH/с протоколами управления (как минимум возможность доставить файлы и выполнить команды на узлах).
Для управления из Termux нужен файл kubeconfig (обычно ~/.kube/config на вашей стороне).

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

Архитектура решения: что делает Termux

В типовой схеме Termux выполняет следующие роли:

Подготовка рабочих директорий, манифестов и kubeconfig.
Запуск kubectl для управления кластером.
При необходимости — генерация шаблонов, проверка YAML и помощь в администрировании (например, выбор контекстов, быстрые запросы, логическая валидация).

А kubeadm используется на узлах кластера (control-plane и workers) для инициализации и подключения узлов.

Подготовка Termux: установка инструментов

Сначала подготовьте базовые пакеты. В Termux используйте менеджер пакетов и установите то, что требуется для работы с YAML и SSH, а также для kubectl.

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

Далее установите kubectl. Удобный способ — скачать бинарник подходящей архитектуры. Если вы не уверены в архитектуре, выполните проверку:

uname -m

Затем установите kubectl (пример для распространённых вариантов — при необходимости подставьте нужную версию и архитектуру):

KUBECTL_VERSION="v1.30.0"
curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl"
install -m 0755 kubectl $PREFIX/bin/kubectl
rm -f kubectl

Проверьте:

kubectl version --client=true

Подготовка kubeconfig для управления из Termux

Чтобы kubectl работал, ему нужен kubeconfig файл. Обычно он находится на control-plane узле. Вы можете:

Скопировать файл из кластера на Termux (через scp или ssh).
Либо создать kubeconfig на месте (но чаще это не нужно).

Считайте kubeconfig с control-plane узла. На Termux создайте каталог:

mkdir -p $HOME/.kube

Пример копирования (замените user/host):

scp user@CONTROL_PLANE_IP:/etc/kubernetes/admin.conf $HOME/.kube/config

Права:

chmod 600 $HOME/.kube/config

Проверка подключения:

kubectl get nodes

Если узлы видны — база готова.

Развёртывание кластера через kubeadm: control-plane

Далее предполагается, что вы настраиваете Kubernetes на узлах Linux с использованием kubeadm. Termux здесь не заменяет роль узлов, но помогает вам хранить манифесты и управлять кластером.

На control-plane узле выполните базовую подготовку (ниже — концептуальный порядок, конкретные параметры зависят от ОС и сети):

Убедитесь, что отключены swap и настроены сетевые требования Kubernetes.
Установите container runtime (например, containerd) и необходимые пакеты.
Настройте cgroups и сетевой модуль согласно документации для вашей ОС.
Инициализируйте кластер через kubeadm init.

Пример инициализации (замените значения под ваш стенд):

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

После успешной инициализации сохраните kubeconfig, чтобы потом перенести его на Termux:

sudo cp /etc/kubernetes/admin.conf /home/youruser/.kube/config
sudo chown youruser:youruser /home/youruser/.kube/config

Установка Pod Network (CNI) после kubeadm init

Чтобы Pod’ы могли общаться между узлами, нужен CNI. На control-plane установите CNI‑провайдер. Варианты зависят от вашей модели сети (flannel/calico/cilium и т.д.). Общая логика:

Применить манифесты CNI в кластер.
Дождаться перехода системных Pod’ов в состояние Running.

Пример (условно) применения манифеста:

kubectl apply -f ./cni-manifest.yaml

Проверка:

kubectl get pods -A

Подключение worker‑узлов через kubeadm join

После настройки control-plane вы получите команду для подключения workers. Её можно вывести:

kubeadm token create --print-join-command

На каждом worker узле выполните полученную команду (примерно в виде):

kubeadm join CONTROL_PLANE_IP:6443 --token YOUR_TOKEN --discovery-token-ca-cert-hash sha256:YOUR_HASH

После присоединения worker узлы должны появиться в списке:

kubectl get nodes -o wide

Управление кластером из Termux: kubectl и базовые сценарии

Когда kubeconfig на месте, вы можете полноценно управлять кластером. Рассмотрим практические команды.

Проверка доступности и контекста

kubectl config current-context
kubectl cluster-info

Работа с ресурсами: pods, deployments, services

Список namespace:

kubectl get ns

Список подов в текущем namespace:

kubectl get pods

Показать события в namespace:

kubectl get events -A --sort-by=.metadata.creationTimestamp

Описать сервис:

kubectl describe svc YOUR_SERVICE_NAME

Деплой тестового приложения

Создайте манифест в Termux (пример). Например, файл app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: termux-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: termux-demo
  template:
    metadata:
      labels:
        app: termux-demo
    spec:
      containers:
        - name: app
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: termux-demo-svc
spec:
  selector:
    app: termux-demo
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Применение:

kubectl apply -f app.yaml

Проверка:

kubectl get deploy,svc
kubectl get pods -l app=termux-demo

Логи, exec и диагностика

Логи пода:

POD_NAME="$(kubectl get pods -l app=termux-demo -o jsonpath='{.items[0].metadata.name}')"
kubectl logs "$POD_NAME" --tail=200

Shell внутри контейнера (если образ поддерживает):

kubectl exec -it "$POD_NAME" -- sh

Быстрая диагностика проблем планирования:

kubectl describe pod "$POD_NAME"

Практики безопасности при работе из Termux

Храните kubeconfig защищённым: права на файл и ограничение доступа к устройству.
Не коммитьте kubeconfig в репозитории.
Используйте минимально необходимые права: отдельные ServiceAccounts/roles для задач (если вы строите модель доступа).
Проверяйте контексты перед применением: kubectl config current-context.

Эксплуатация: обновления, токены, health‑check

Токены kubeadm и join

Если нужно присоединять новые узлы, используйте:

kubeadm token create --print-join-command

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

Проверка здоровья компонентов

Обычно удобно смотреть системные namespace:

kubectl get pods -A
kubectl get deployments -A
kubectl get daemonsets -A

Управление версиями kubectl

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

Автоматизация: локальные скрипты и шаблоны в Termux

Termux хорош для подготовки инфраструктурных артефактов: манифестов, генерации переменных, сборки пакетов конфигураций. Например, вы можете хранить YAML‑шаблоны и подставлять значения, а затем применять их через kubectl.

Если вы используете параметры, удобен подход: хранить kustomization.yaml или простые env‑замены через jq/sed. Однако соблюдайте аккуратность с безопасностью секретов: не встраивайте их в публичные файлы.

Частые ошибки и как их диагностировать

kubectl не видит кластер: проверьте kubeconfig и доступность API server. Команда kubectl cluster-info поможет локализовать проблему.
Поды CNI не Running: проверьте сетевой модуль, pod-network-cidr и корректность параметров CNI.
Nodes в NotReady: проверьте swap, runtime, cgroups, состояние kubelet и firewall.
Проблемы с приложением: смотрите kubectl describe и kubectl logs конкретного пода.

Заключение

Развёртывание Kubernetes‑кластера через kubeadm и управление им через kubectl из Termux — практичный лабораторный и эксплуатационный подход: вы получаете мобильную консоль для администрирования, при этом развёртывание сохраняете на реальных узлах Linux, где Kubernetes и так должен работать. Главное — корректно подготовить kubeconfig, обеспечить связность сети до API server и строго соблюдать принципы диагностики через команды kubectl.

Если вам нужен консультационный аудит стенда, помощь в проектировании сети, подборе CNI, настройке kubeadm или ведении эксплуатации — обращайтесь в РыбинскЛАБ. Мы поможем выстроить стабильный Kubernetes под ваши задачи.