Skip to content

Verify the Installation⚓︎

When the Site reports Ready, confirm each layer before connecting radios or handing the core over: the operator's view of the Site, the workloads it created, the Agent's registration in xControl, and the monitoring path. The commands below use the xcore namespace and release name.

The Site⚓︎

kubectl -n xcore get sites.expeto.io
kubectl -n xcore describe site acmecorp-campus

All conditions must be True. For the combined core example:

Status:
  Conditions:
    Type:     InfrastructureReady   Status: True   Reason: InfrastructureReady
    Type:     GatewaysReady         Status: True   Reason: AllGatewaysReady    Message: 3 child UPF(s) ready
    Type:     ControlPlaneReady     Status: True   Reason: ControlPlaneReady   Message: Control-plane children ready: smf, mm, mme, sdm
    Type:     Ready                 Status: True   Reason: Ready               Message: Site agent and all 3 child UPF(s) are ready
  Last Reconcile Time:  2026-10-26T16:29:11Z

Last Reconcile Time advances on every pass. If it stops moving the operator is not running:

kubectl -n xcore rollout status deployment/xcore-xfabric

Workloads⚓︎

kubectl -n xcore get pods
kubectl -n xcore get smf,upf,udsf,nfcm,mm,mme,sdm,mariadb,dragonfly

Every pod must be Running (the Ignite initialisation Job ends Completed). The set depends on the Site; a public core produces these, with one controller Deployment and one dataplane StatefulSet per user plane:

Workload Kind
smf Deployment
upf-<user plane>-controller, upf-<user plane>-dataplane Deployment, StatefulSet
udsf, udsf-idallocator, udsf-timer Deployment, Deployment, StatefulSet
nfcm-monitoring, nfcm-statistics Deployment
ignite, ignite-proxy, ignite-init StatefulSet, Deployment, Job
mariadb StatefulSet, managed by the MariaDB operator
cache StatefulSet, managed by the Dragonfly operator
xcore-xfabric, xcore-xfabric-agent Deployment, StatefulSet (the operator and the Agent)

The control-plane blocks of a private or combined core add their own workloads:

Workload Kind Present with
mm-ranhandler, mm-communication, mm-uehandler Deployment amf
mme-mme, mme-stc Deployment mme: the MME and its S1 transport controller
mme-cache StatefulSet, managed by the Dragonfly operator mme: the MME's session store
sdm-hss Deployment subscriber store in mode 4G or Dual
sdm-udr, sdm-udm, sdm-ausf Deployment subscriber store in mode 5G or Dual
sdm-cache StatefulSet, managed by the Dragonfly operator subscriber store

The user planes' radio-facing and data-network addresses live on Multus attachments, not on Services. Confirm each dataplane pod holds the addresses the Site pins:

kubectl -n xcore exec upf-psa-upf-dataplane-0 -- ip -br addr

Prerequisite check⚓︎

The operator's preflight lists every dependency it found, with a fix hint for anything missing. Run it as the chart's Helm test or directly on the operator pod:

helm test xcore -n xcore --filter name=xcore-xfabric-test-preflight --logs
kubectl -n xcore exec deployment/xcore-xfabric -- /opt/taiga/app preflight

Taiga preflight check

  ✓  Multus CNI                     installed
  ✓  cert-manager                   installed
  !  MetalLB (optional)             NOT INSTALLED
     → Optional — BGP fabric (Site.Spec.Network.Bgp) is not supported without MetalLB.
  ...
2 of 2 required prerequisites satisfied.

Registration in xControl⚓︎

Open Sites in xControl. The Site whose ID you gave the chart shows Connected, with the Agent version and the address it connects from on its detail page. It turns Disconnected after five minutes without contact.

If it stays Disconnected, check the Agent:

kubectl -n xcore logs statefulset/xcore-xfabric-agent -c agent --tail=100

The usual causes are a siteId that does not match the Site in xControl, a token that was issued for another Site, or an xControl hostname the pod cannot resolve or reach on port 443.

Operations CLI⚓︎

The Agent pod carries a CLI sidecar that reads live state from every network function on the Site:

kubectl -n xcore exec -it xcore-xfabric-agent-0 -c agent-cli -- cli

At the expeto_shell> prompt, ls lists the command folders (lte, nr, nf, ops), and cd nr followed by read smf shows the SMF's sessions. The CLI Guide covers the grammar.

Monitoring path⚓︎

The operator publishes each Site's conditions as a metric on its metrics Service:

kubectl -n xcore port-forward service/xcore-xfabric-metrics 8080:8080 &
curl -s http://127.0.0.1:8080/metrics | grep taiga_site_condition

taiga_site_condition{namespace="xcore",site="acmecorp-campus",type="ControlPlaneReady"} 1
taiga_site_condition{namespace="xcore",site="acmecorp-campus",type="GatewaysReady"} 1
taiga_site_condition{namespace="xcore",site="acmecorp-campus",type="InfrastructureReady"} 1
taiga_site_condition{namespace="xcore",site="acmecorp-campus",type="Ready"} 1

The Agent exposes the Site's network-function metrics on the agent-prom Service (port 9767); the xCore metrics page lists the families. They reach xView the way every site's metrics do: a Prometheus in the Site's namespace scrapes them, and the Agent uploads that Prometheus's federation endpoint to xControl for each Monitoring Endpoint configured on the Site in xControl; see xView architecture. The xfabric chart does not install that Prometheus by default. Use the platform's prometheus-operator, or bundle one with kube-prometheus-stack.enabled=true, set nfMonitoring.enabled=true so that the chart renders the scrape configuration of the network functions, and add the Monitoring Endpoint to the Site in xControl, as agreed with Expeto Support.

Acceptance tests⚓︎

With radios connected and Mobile Assets provisioned, run the installation and upgrade verification set: attach, detach, idle mode, throughput and the other checks an installation must pass before it is handed over.