KubeEdge перевірили на RISC-V: VisionFive2 став edge-вузлом Kubernetes і запустив Nginx

Спільнота KubeEdge опублікувала практичну перевірку роботи платформи на одноплатному комп’ютері StarFive VisionFive2 з архітектурою RISC-V. Мета експерименту — не синтетичний benchmark, а повний операційний шлях: підготувати Ubuntu-образ, зібрати сумісні компоненти, приєднати пристрій як edge-вузол та розгорнути на ньому звичайний Kubernetes workload.

VisionFive2 завантажено з Ubuntu перед установленням edge-компонентів KubeEdge.
Чому RISC-V важлива для edge
Відкрита ISA дає виробникам більше свободи у створенні спеціалізованих енергоефективних SoC, але програмна екосистема ще не настільки рівномірна, як ARM64 або x86-64. Для edge-платформи недостатньо, щоб окремий бінарник просто запускався: потрібні container runtime, мережа, сертифікати, стабільне з’єднання з control plane і сумісні образи застосунків.
У тесті cloud-side компоненти працювали на звичайній машині, а VisionFive2 виконувала роль edge node. Команда підготувала RISC-V збірки edgecore та інструментів, налаштувала containerd і використала стандартний процес join. Це показує, що модель KubeEdge не прив’язана до одного сімейства процесорів, хоча пакети й контейнери мають бути зібрані саме для riscv64.
Команда join завершує реєстрацію RISC-V пристрою в edge-кластері.
Control plane бачить VisionFive2 як готовий edge-вузол.
Перевірка реальним workload
Після приєднання автор розгорнув Nginx із node selector для нового вузла. Маніфест пройшов cloud-to-edge канал, container runtime отримав сумісний образ, а pod перейшов у Running. Окрема перевірка HTTP підтвердила, що сервіс відповідає безпосередньо на пристрої.
Deployment спрямовано на VisionFive2 через Kubernetes scheduling.
HTTP-відповідь підтверджує запуск контейнера Nginx на RISC-V edge-вузлі.
Що це означає для розробників
RISC-V пристрій можна включити до звичного GitOps та Kubernetes API, не створюючи окремий механізм доставки застосунків. Для команд IoT це означає єдину модель deployment, status і lifecycle для неоднорідного парку. При цьому container images повинні бути multi-arch або мати riscv64 variant, а сторонні агенти спостережуваності, CNI-компоненти й драйвери потрібно перевіряти окремо.
Практичний checklist починається з фіксації версії firmware та Ubuntu, перевірки cgroups і containerd, відтворюваної cross-compilation, підпису артефактів та окремого node label для RISC-V. У CI варто додати збірку manifest list, smoke test запуску контейнера й перевірку оновлення edgecore без втрати керованості вузла.
Обмеження експерименту
Один Nginx pod не доводить production-продуктивність платформи. У матеріалі немає тривалого soak test, вимірювань енергоспоживання, пропускної здатності мережі, часу cold start чи поведінки під час розриву cloud-edge каналу. Також не кожен популярний container image має riscv64 build. Тому результат слід сприймати як підтвердження сумісності й повного життєвого циклу, а не як гарантію готовності будь-якого workload.
Автор першоджерела: KubeEdge Community.
Ліцензія: Apache License 2.0 — https://github.com/kubeedge/website/blob/master/LICENSE. Матеріал перекладено, переказано й адаптовано українською мовою.