WaaS: разворачиваем изолированные рабочие столы прямо в Kubernetes

Если тебе доводилось настраивать удалённые рабочие столы для инженеров или подрядчиков, ты отлично помнишь этот кошмар. Классические VDI-системы вроде Citrix или VMware Horizon стоят колоссальных денег, требуют отдельных серверов виртуализации и сложного лицензирования. А инженеру всего-то нужно: быстро получить чистую среду разработки с графической оболочкой, запустить тесты и не утащить корпоративные исходники на домашний ноутбук.

Открытая платформа WaaS (Workspace-as-a-Service) от команды XoRHub предлагает взглянуть на виртуальные рабочие столы с точки зрения облачной инфраструктуры. Если в компании уже крутится кластер Kubernetes, зачем строить вокруг отдельный зоопарк? WaaS превращает создание графических рабочих мест в декларативную рутину: рабочее окружение описывается стандартным манифестом Custom Resource Definition (CRD), а пользователь подключается к удалённому столу прямо через вкладку браузера.

Архитектура с жёсткими границами: почему оператор не видит базу данных

В WaaS авторы реализовали строгие границы ответственности (Hard boundaries), где ни один компонент не обладает избыточными привилегиями.

Сердце системы — WaaS Operator, написанный на Go с использованием Kubebuilder. Он слушает события ресурсов Workspace и WorkspaceTemplate в домене waas.xorhub.io. Принципиальный момент: оператор общается исключительно с Kubernetes API Server. У него физически нет сетевого доступа и учётных данных к базе PostgreSQL, где хранятся профили пользователей и настройки. Если злоумышленник скомпрометирует оператор, он не получит доступ к данным организации.

API Server платформы обрабатывает запросы интерфейса и отвечает за аутентификацию (поддерживаются локальные пользователи и корпоративные SSO через OIDC). Но он никогда не создаёт поды напрямую — выделение ресурсов оформляется строго созданием CRD в Kubernetes API под контролем кластерного RBAC.

Сетевой трафик сессий изолирован через тандем из прокси wwt и демона Apache Guacamole (guacd). WebSocket-соединение принимает шлюз wwt, который проверяет JWT-токен до того, как будет открыто TCP-соединение к guacd. Сам сервис guacd развёрнут с типом ClusterIP и наглухо закрыт от внешней сети.

Контейнеры для Linux, виртуальные машины KubeVirt для Windows

WaaS разделяет запуск операционных систем под конкретные задачи:

• Рабочие места Linux: для Ubuntu или Alpine поднимается контейнер с X11/Wayland-сервером и веб-шлюзом VNC. Домашняя директория /home монтируется на том PersistentVolumeClaim (PVC). Контейнер стартует за секунды и утилизирует свободные ноды кластера.
• Рабочие места Windows: если требуются специфичные утилиты, WaaS задействует оператор KubeVirt. Вместо контейнера генерируется спецификация виртуальной машины с пробросом нативного протокола RDP.

Развёртывание чарта и создание первого рабочего пространства

Для установки платформы требуется кластер Kubernetes версии 1.28+ и предварительно установленный менеджер сертификатов cert-manager.

Развёртывание платформы выполняется через официальный Helm-чарт:

# Установка платформы WaaS в изолированное пространство имён
helm install waas ./helm/waas \
  --namespace waas-system \
  --create-namespace \
  --set ingress.enabled=true \
  --set ingress.host="waas.corp.example.com" \
  --set postgresql.persistence.size=20Gi

После применения чарта администраторы или GitOps-пайплайны могут декларативно описывать рабочие пространства для сотрудников через манифест:

apiVersion: waas.xorhub.io/v1alpha1
kind: Workspace
metadata:
  name: dev-desktop-ivan
  namespace: waas-workspaces
spec:
  template:
    os: linux
    image: "registry.corp.example.com/waas/ubuntu-desktop:24.04"
    resources:
      limits:
        cpu: "4"
        memory: "8Gi"
      requests:
        cpu: "1"
        memory: "2Gi"
    storage:
      homeSize: "50Gi"
      storageClassName: "fast-nvme"
  userRef:
    username: "ivan.petrov"

Когда манифест применяется в кластере, оператор создаёт StatefulSet с томом fast-nvme и публикует точку подключения в React 19 интерфейсе. Разработчик заходит по адресу https://waas.corp.example.com и в один клик оказывается внутри рабочего стола с терминалом и IDE.

Где VDI на базе Kubernetes спасает, а где создаёт лишнюю сложность

Перевод рабочих мест в Kubernetes — отличный шаг для компаний, которые устали бороться с разрозненными виртуальными машинами и хотят централизовать безопасность. Исходный код остаётся внутри защищённого периметра, сетевые политики NetworkPolicy ограничивают доступ рабочего места к внутренним базам данных, а аудит точно фиксирует время каждой сессии. При этом если инфраструктура компании ещё не созрела для микросервисов, полезно вспомнить материал Миграция с Kubernetes на AWS ECS Fargate, где мы разбирали снижение операционной нагрузки при отказе от избыточных кластеров.

Однако у WaaS есть естественные ограничения:

• Чувствительность к задержкам: передача графики через WebSocket требует стабильного канала с задержкой (RTT) не более 40–50 мс.
• Требования к хранилищу: быстрый NVMe StorageClass обязателен, иначе дисковые операции в IDE будут тормозить.

Если в твоей инфраструктуре уже есть живой кластер Kubernetes, протестировать WaaS стоит ради того, чтобы увидеть, насколько быстро сегодня можно поднять защищённую рабочую среду без покупки неподъёмных лицензий.