How MicroOps Enables Easy Deployment and Management of Virtual Networks on Kubernetes

Feature Overview

The platform creates a virtual network simulation on Kubernetes that is easy to deploy, closely matches real‑world topologies, is manageable and configurable, and supports real‑time metric and log collection as well as fault‑scenario injection.

Deployment Options

Manual parameter setting : Users specify subnets, routers, switches, host count, and interconnections, then click the Deploy button to name and launch a testbed that manages the virtual network.

Intent‑driven deployment : Users input deployment intent, click Generate Configuration , and the platform calls an LLM to generate all parameters, which can be previewed before deployment.

Topology Visualization and Adjustment

All virtual network nodes run as pods on a single worker node, limiting the scale to roughly 50 nodes due to pod resource constraints. The topology module displays a network with five subnets and a router, plus a large‑model chat box for user commands. Users can modify topology, device configurations, or request actions via the chat box; the platform automatically applies basic configurations to ensure connectivity.

Current node types include hosts, layer‑2 switches, and routers. Recent experiments have added layer‑3 switches and firewalls (transparent mode), which will be integrated soon.

Node Menus

Host menu : View routing tables.

Switch menu : List bridge ports; restart (replace) a node by deleting the old pod and recreating a new one with the same configuration.

Router menu : Same operations as switch.

Edge : Delete or disconnect links between devices.

Monitoring (Data Collection)

Metrics are collected with Prometheus ; logs are collected with Fluentd . Tracing via Jaeger is currently geared toward microservice anomaly detection and may not apply to the virtual network. Only metric data is displayed now; log data will be added later, and users can download collected data to build datasets.

Fault Injection

Two fault‑injection modules are provided:

Chaos module : Built on chaosmesh for pod‑level faults. It works for some faults (e.g., stress series, pod failure) but has limitations: certain faults cannot be injected, fault effects are not obvious, and the impact scope is small (e.g., network‑loss or delay affect only a single pod interface).

VN_Chaos : Extends fault injection to the virtual network by disrupting forwarding device configurations (MAC table, flow table, port security, ACL, VLAN/trunk, security policies, NAT, routing tables), forwarding processes, databases, and can simulate broadcast storms or DoS attacks.

VN_Chaos currently supports a limited set of fault types, with more to be added.

Future Development Plans

Alarm system : Multi‑modal support. The platform currently trains models on metric data only; future work will incorporate multi‑modal datasets for anomaly detection.

Self‑healing : Generate troubleshooting steps and repair suggestions based on alarm content.