Kubernetes

wasmCloud работает в Kubernetes как оператор: среда исполнения разворачивается в кластер, а компоненты планируются как рабочие нагрузки. Эта глава излагает устройство по документации wasmCloud — без условий обслуживания платформы.

Два способа запустить Wasm в кластере

Первый способ — RuntimeClass и шим (shim). Kubernetes исполняет контейнеры через CRI — интерфейс контейнерного рантайма. Шим с поддержкой WebAssembly исполняет модуль Wasm как контейнер. Ресурс RuntimeClass выбирает шим: под с полем runtimeClassName уходит не в обычный рантайм, а в шим. Для таких подов Wasm-модуль и есть контейнер.

Второй способ — оператор wasmCloud. Хосты wasmCloud работают обычными подами. Оператор планирует компоненты по хостам и связывает их с сервисами кластера. Отдельный шим на узлах не нужен: исполнение остаётся внутри подов-хостов.

Платформа WasmBox строится на wasmCloud, поэтому дальше речь о втором способе.

Оператор wasmCloud

Оператор устанавливается Helm-чартом и вводит ресурсы группы runtime.wasmcloud.dev/v1alpha1:

WorkloadDeployment — развёртывание и масштабирование рабочих нагрузок;
Workload — отдельная рабочая нагрузка;
WorkloadReplicaSet — реплики, которыми управляет WorkloadDeployment;
Host — хост wasmCloud;
Artifact — артефакт компонента в реестре.

Pod и Deployment

В модели оператора Deployment не нужен: его роль играет WorkloadDeployment. Ресурс держит нужное число реплик компонента и обновляет их по политике из поля deployPolicy. По умолчанию это последовательное обновление (rolling update): новые реплики поднимаются, затем замещают старые.

Обновление версии — смена ссылки image на новый тег или digest. Оператор обновляет реплики по этой политике. Откат — возврат прежней ссылки; digest не меняется, поэтому откат воспроизводим байт в байт.

Поды в этой модели — хосты. Чарт оператора поднимает группу подов-хостов с меткой hostgroup; рабочая нагрузка выбирает группу селектором hostSelector. Разные группы хостов изолируют нагрузки друг от друга или дают особые возможности — селектор решает, где жить компоненту.

Масштабирование — штатное. WorkloadDeployment реализует подресурс /scale, поэтому kubectl scale, Horizontal Pod Autoscaler и KEDA работают без специальных надстроек.

Service и Ingress

HTTP-трафик принимает обычный Service. Оператор поддерживает EndpointSlice этого сервиса: записи указывают на поды-хосты, где исполняется компонент. Стандартные DNS и маршрутизация кластера доводят запрос до компонента.

Ingress остаётся стандартным: правила маршрутизации HTTP лежат поверх Service. Оператору достаточно ссылки на сервис в спецификации нагрузки — поле kubernetes.service.name.

Пример манифеста

Минимальная нагрузка — один артефакт в реестре и один интерфейс:

apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: WorkloadDeployment
metadata:
  name: hello-world
spec:
  replicas: 1
  template:
    spec:
      hostSelector:
        hostgroup: default
      kubernetes:
        service:
          name: hello-world
      components:
        - name: hello-world
          image: registry.example/hello-world:0.1.0
      hostInterfaces:
        - namespace: wasi
          package: http
          interfaces:
            - incoming-handler

Прочтите поля так:

hostSelector.hostgroup — группа хостов, на которой планируется нагрузка; чарт оператора создаёт группу default;
kubernetes.service.name — сервис, чей EndpointSlice ведёт к компоненту;
components.image — ссылка на артефакт в реестре OCI: wash oci push из главы «Платформа» кладёт компонент именно туда;
hostInterfaces — интерфейсы WASI, которые хост предоставляет компоненту. Без явной записи интерфейс недоступен.

Конфигурация

Конфигурация приходит из среды, не из артефакта. Интерфейсу сопоставляется значение конфигурации — например, имя хоста, на котором компонент отвечает:

      hostInterfaces:
        - namespace: wasi
          package: http
          interfaces:
            - incoming-handler
          config:
            host: hello.example.com

Секреты хранятся в среде: в переменных, томах и внешних хранилищах секретов кластера. Артефакт .wasm секретов не содержит — это же правило действует в любой среде исполнения.

Ресурсы и масштабирование

Ресурсы компонента настраиваются в описании компонента нагрузки:

poolSize — число инстансов компонента в пуле хоста;
maxConcurrency — предел одновременных вызовов;
maxInvocations — предел вызовов на инстанс;
reclaimWindowSeconds — окно возврата неиспользуемых инстансов в пул.

Исходящие сетевые вызовы ограничиваются отдельно: списки разрешённых хостов и портов локальной сети описываются в ресурсах компонента.

Поды-хосты ограничиваются штатно — запросами и лимитами контейнера.

Диагностика

Начните с состояния нагрузки и хостов:

kubectl get workloaddeployments
kubectl get workloads
kubectl get pods

События планирования покажет kubectl describe — по ресурсу нагрузки или поду. Журналы хоста читает kubectl logs. Контракт артефакта перед запуском проверяет wash inspect — неожиданные импорты видны до развёртывания.

Открытый стек

Инфраструктура WasmBox: Yandex Serverless Containers, Cloud Functions и wasmCloud — описание технологии, не партнёрства. Эта глава описывает открытый стек, на котором платформа построена: манифесты Kubernetes из главы работают в любом кластере с оператором wasmCloud.

WasmBox — Документация