Planning and Prerequisites⚓︎

xCore runs on a Kubernetes cluster that you provide. This page lists what that cluster must have before the operator is installed, what to obtain from Expeto and from xControl, and the addressing and identity decisions the Site definition will ask for. Work through it once per Site; the operator install and Site definition pages assume it is done.

Cluster requirements⚓︎

Requirement	Detail
Kubernetes	Version 1.25 or later, with `kubectl` access that can create namespaces and CustomResourceDefinitions. The operator itself is namespaced; the CRDs it installs are cluster-scoped and shared by every xCore on the cluster.
Nodes	Worker nodes with a network interface on every VLAN or segment the core attaches to (radio, data network, inter-site). The operator's user planes attach to those interfaces with macvlan or ipvlan through Multus. Node sizes are in the sizing guide; each Ignite replica reserves 11 GiB of memory by default and each MariaDB replica needs its own node when Galera is used.
Multus CNI	Required. Every N2, S1, N3, N6 and N9 interface is a `NetworkAttachmentDefinition`; the install fails fast when the Multus CRD is absent. The containernetworking reference plugins (`macvlan`, `ipvlan`, `static`) must be present in the nodes' CNI plugin directory; some distributions ship Multus without them.
whereabouts IPAM	Optional. Needed only when an attachment uses `ipam.type: whereabouts` for cluster-wide address assignment; static IPAM needs nothing extra.
cert-manager	Required. The operator's admission webhook is served with a cert-manager issued certificate. Install cert-manager once per cluster; the chart cannot bundle it.
MariaDB and Dragonfly operators	Bundled with the chart and enabled by default. Disable the bundled copy on a cluster that already runs the same operator; two controllers reconciling the same resources is undefined behaviour.
netcfg operator	Required. Expeto's node-configuration operator, a cluster singleton shared by xControl, xCore and xRouter. The chart bundles it and enables it by default; on a cluster where another Expeto release already runs it, install with `netcfg.enabled=false`, and the install checks that the running one is present.
MetalLB with FRR-K8s	Optional. Required when the Site has a BGP router with `impl: metallb`, the default, which every service-address announcement uses, or exposes an N2 or S1 endpoint as a LoadBalancer address. A router with `impl: gobgp` runs in the user-plane pods and needs no MetalLB. MetalLB can be bundled by the chart on clusters that have no load balancer.
Storage	A default StorageClass providing `ReadWriteOnce` volumes. Ignite claims 25 GiB per replica by default, MariaDB and the Agent claim their own volumes.
Kernel	SCTP support on the nodes that run the AMF or MME (the N2 and S1 transports), the `tun` module on user-plane nodes, and the network buffer sizes the user plane expects. The Site's `nodeConfig` block applies these through a privileged DaemonSet, or a MachineConfig on OpenShift; omit it if you manage node tuning yourself.
Outbound access	Nodes pull images from `docker.expeto.io`; the machine running Helm pulls charts from `repo.expeto.io`. The Agent connects to xControl over HTTPS. No inbound connection from xControl is needed.
xControl	Release 3.3.22 or later. The Agent of xCore 4.0.6 must not be newer than the xControl it registers with. xControl must present a certificate the Agent trusts: one issued by a public certificate authority.

The platform notes describe how each of these is met on MicroK8s, OpenShift, Tanzu Kubernetes Grid and Amazon EKS.

Tools⚓︎

kubectl (or oc) configured for the cluster.
Helm 3.
helm test uses no extra tooling; the preflight check runs inside the cluster.
For a core with a subscriber store, OpenSSL on the offline machine the key custodians use; see Load the subscriber-store keys.

What to obtain⚓︎

Item	Source	Used as
Registry credentials	Expeto Support. One username and password for the Helm repository and the container registry.	`global.imageCredentials.username` and `.password` on the chart.
Site identifier	xControl: the numeric ID of the Site you create for this core; see Connect the first Site.	`agent.connections.siteId` on the chart.
Site API token	xControl: the API Tokens tab of that Site.	`agent.apiToken` on the chart.
xControl URL	The hostname of your xControl installation, or Expeto's hosted service.	`agent.connections.serverUri` and `.brokerUri` on the chart.
System identifiers	xControl: each System under the Site has a numeric ID. Mobile Assets are provisioned with the System they belong to.	`systemId` on each anchor user plane (one with N6) in the Site definition.
Customer identifier	xControl: the numeric ID of the Customer that owns the Site.	`customerId` in the Site definition.
HSS Identifiers	xControl: the Keyset Mapping of each SIM batch on the Site.	The name each transport key is loaded under in the subscriber store.
Transport keys and SUCI keys	Your SIM vendor and your key custodians: the transport key of each SIM batch, and the home network's SUCI private key with its key identifier.	Loaded into the subscriber store after installation, never into xControl or the Site definition.

Network plan⚓︎

The Site definition declares every network the core touches. Expeto Support writes it with you from the plan below during the design phase, so have the following agreed with the network team before that conversation.

Item	Needed for	Notes
Parent interface per segment	every attachment	The node interface (for example `ens192` or `bond0.2001`) that carries each VLAN. Confirm the name on the worker nodes; it differs between platforms.
N2 (5G) or S1-MME (4G) transit address	AMF, MME	One address per mobility function in the radio control-plane subnet, written as a host address with prefix length (`10.0.2.10/24`). The radios point their control-plane connection at it.
N3 or S1-U transit address	every user plane that faces the radios	One per such user plane in the radio user-plane subnet. The radios send GTP-U to it.
N6 or SGi transit address and gateway	every user plane with a data network	One per data network per user plane, with the gateway that routes traffic onward.
N9 or S5-U transit addresses	user-plane chains (SGW-U to PGW-U, intermediate UPF to anchors)	Either an attachment with one address per user plane, or the pod network.
UE address pools	every data network	The CIDR blocks Mobile Assets get their addresses from, one or more per user plane, and how each pool reaches the outside: source NAT on the UPF (default), static routes installed by the network team, or BGP advertisement.
DNS servers	every data network	Handed to Mobile Assets at session setup.
BGP peers	pools or service addresses advertised over BGP	Local ASN, peer address and ASN, and which segment the session rides. The peer must be adjacent on the N6 segment for advertised pools.
MTU	attachments with jumbo or reduced frames	Set on the attachment or per interface; the default is 1500.

Reserve addresses so that no two pods on the same attachment share one; every transit address is pinned by the Site.

Identity plan⚓︎

Item	Needed for	Notes
PLMN	AMF, MME, subscriber store	MCC and MNC as one string (`310410`); the MNC length is part of the identity and must match the SIMs and the radios. A core with an MME needs a 3-digit MNC: with a 2-digit MNC, 4G attach fails.
Tracking area codes	AMF, MME	The TACs the radios broadcast; 1 to 65535 for the MME. The AMF accepts an N2 connection from any gNodeB that reaches it with the PLMN and a served TAC; there is no gNodeB allow-list.
Data network names	SMF, AMF, MME	The DNNs or APNs the core serves; the first one is the default. They must match the APNs of the Mobile Assets' System Profiles.
Slices	AMF	The S-NSSAIs the core serves, when Mobile Assets are provisioned for slices other than SST 1.
NAS security algorithms	AMF, MME	Integrity and ciphering preference order. Agree them explicitly for every AMF and MME; the defaults are listed in the Site resource reference.
AMF and MME identities	combined core	Region, set and pointer for the AMF; MME group and code for the MME. They must not collide in a combined core.

One Site per namespace⚓︎

The operator manages exactly one Site in its own namespace. To run a second core on the same cluster, install the chart again in another namespace; the CRDs are shared. The examples in this section use xcore as the namespace and the release name.