Introduction

StarlingX is a fully integrated edge cloud software stack that provides everything needed to deploy an edge cloud on one, two, or up to 100 servers.

Key features of StarlingX include:

  • Provided as a single, easy to install package that includes an operating system, storage and networking components, and all the cloud infrastructure needed to run edge workloads.

  • Optimized software that meets edge application requirements.

  • Designed with pre-defined configurations to meet a variety of edge cloud deployment needs.

  • Tested and released as a complete stack, ensuring compatibility among open source components.

  • Included fault management and service management capabilities, which provide high availability for user applications.

  • Optimized by the community for security, ultra-low latency, extremely high service uptime, and streamlined operation.

Download the StarlingX ISO image from the StarlingX mirror.

Learn more about StarlingX:

Projects

StarlingX contains multiple sub-projects that include additional edge cloud support services and clients. API documentation and release notes for each project are found on the specific project page:

Supporting projects and repositories:

For additional information about project teams, refer to the StarlingX wiki.

New features in StarlingX 11.0

Platform Component Upversion

The following platform component versions have been updated in StarlingX Release Stx 11.0

  • kernel version 6.12.40

Supported Kubernetes versions in StarlingX 11.0:

  • 1.29.2

  • 1.30.6

  • 1.31.5

  • 1.32.2

  • nginx-ingress-controller

    • ingress-nginx 4.13.3

  • cert-manager 1.17.2

  • platform-integ-apps 3.11.0

    • ceph-csi-rbd-3.13.1

    • ceph-csi-cephfs-3.13.1

    • ceph-pools-audit-1.0.1

    Note

    The Ceph pools audit chart is now disabled by default. It can be enabled through user-overrides based on user preference, if required.

  • rook-ceph

    • rook-ceph-1.16.6

    • rook-ceph-cluster-1.16.6

    • rook-ceph-provisioner-2.1.0

    • rook-ceph-floating-monitor-2.1.0

  • oidc-auth-apps 2.42.0

    • dex-0.23.0

    • secret-observer-0.1.8

    • oidc-client-0.1.24

  • Helm chart metrics-server: 3.12.2 (deploys Metrics Server 0.7.2)

  • kubevirt-app 1.5.0

  • node-feature-discovery 0.17.3

  • sriov-fec-operator 2.11.1

  • node-interface-metrics-exporter 0.1.4

  • security-profiles-operator 0.8.7

  • dell-storage

    • csi-powerflex 2.13.0

    • csi-powermax 2.13.0

    • csi-powerscale 2.13.0

    • csi-powerstore 2.13.0

    • csi-unity 2.13.0

    • csm-observability 1.11.0

    • csm-replication 1.11.0

    • csm-resiliency 1.12.0

  • oran-o2 2.2.1

  • snmp 1.0.5

  • auditd 1.0.3

  • portieris 0.13.28

    Warning

    Kubernetes upgrade fails if Portieris is applied.

  • intel-device-plugins-operator

    • intel-device-plugins-operator-0.32.5

    • intel-device-plugins-qat-0.32.1

    • intel-device-plugins-gpu-0.32.1

    • intel-device-plugins-dsa-0.32.1

    • secret-observer-0.1-1

  • kubernetes-power-manager 2.5.1

    Note

    Intel has stopped support for the kubernetes-power-manager application. This is still being supported by StarlingX and will be removed in a future release. For more information, see Configurable Power Manager.

    cpu_busy_cycles metric is deprecated and must be replaced with cpu_c0_state_residency_percent for continued usage (if the metrics are customized via helm overrides).

  • power-metrics

    • cadvisor 0.52.1

    • telegraf 1.34.4

  • app-istio

    • Istio 1.26.2

    • Kiali 2.11.0

  • FluxCD helm-controller 1.2.0

  • FluxCD source-controller 1.5.0

  • FluxCD notification-controller 1.5.0

  • FluxCD kustomize-controller 1.5.1

  • Helm 3.17.1 for Kubernetes 1.29-1.32

  • volume-snapshot-controller

    • snapshot-controller 6.1.0 for K8s 1.29.2

    • snapshot-controller 6.3.3 for K8s 1.30.6

    • snapshot-controller 8.0.0 for K8s 1.31.5 - 1.32.2

    • snapshot-controller 8.1.0 for K8s 1.33.0

  • ptp-notification 2.0.75

  • app-netapp-storage (NetApp Trident CSI) 25.02.1

  • Mellanox (OFED) ConnectX 24.10-2.1.8

  • Mellanox ConnectX-6 DX firmware 22.43.2566

  • ice: 2.3.10

    • Intel E810 - Required NVM/firmware: 4.80

    • Intel E825 - Required NVM/firmware: 4.02

    • Intel E830 - Required NVM/firmware: 1.11

  • i40e: 2.28.9 / Required NVM/firmware: 9.20

See: Application Reference

OpenBao is not supported

Warning

OpenBao is not supported in StarlingX Stx 11.0. Do not upload/apply this application on a production system.

Secure Pod-to-Pod Communication of Inter-Host Network Traffic

To strengthen security across the StarlingX, new measures have been implemented to protect selected pod-to-pod network traffic from both passive and active network attackers including those with access to the cluster host network.

On StarlingX, inter-host pod-to-pod traffic for a service can be configured to be protected by IPsec in tunnel mode over cluster host network. The configurations are defined as IPsec policies and managed by the ipsec-policy-operator Kubernetes system application.

See:

Threat Mitigation

  • Passive attackers: Defend against traffic snooping and unauthorized data observation

  • Active attackers: Blocked from attempting unauthorized connections to StarlingX cluster hosts

Secure Pod-to-Pod Communication

The StarlingX now supports encryption of Calico-based inter-hosts networking using IPsec, ensuring secure Pod-to-Pod traffic across the cluster-host network.

  • Applies to application pod-to-pod traffic on the cluster-host network

  • Applications, and applications’ pod-to-pod traffic can selectively be protected

  • Excludes SR-IOV VF interface traffic

  • Configuring IPSec policies on pod-to-pod traffic may degrade the CPU performance. Ensure that adequate resources are available to support sustained and peak inter-node traffic

See:

Install IPsec Policy Operator System Application

The ipsec-policy-operator system application is managed by the system application framework and will be automatically uploaded once the system is ready. Subsequently, the application can be installed by applying its manifest.

See:

Platform Networks Address Reduction for AIO-SX

To reduce the number of IP addresses required for Distributed Cloud AIO-SX Subcloud deployments, platform networks are updated to allocate only a single IP address per subcloud, removing the need for additional unit-specific addresses that are no longer required.

However, the platform network IP address must be assigned from a shared subnet, allowing multiple subclouds to use the same network address range. This enables more efficient IP management across large-scale deployments. The OAM network serves as a reference model, as it already supports the necessary capabilities and expected behavior for this configuration.

See:

Intermediate CA Support for Kubernetes Root CA

StarlingX now supports the use of server certificates signed by an Intermediate Certificate Authority (CA) for the external kube-apiserver endpoint. This enhancement ensures that external access to the Kubernetes API can be validated under the same root of trust as other platform certificates, improving consistency and security across the system.

Intermediate CA Support for External Connections to kube-apiserver

External connections to kube-apiserver are now routed through HAProxy, which listens on port 6443. HAProxy uses the REST API / GUI certificate issued by system-local-ca, supporting Intermediate CAs, to perform SSL termination with the external client. It then initiates a new SSL connection to kube-apiserver, now operating on port 16443 behind the firewall, on behalf of the client. External clients must recognize and trust the public certificate of system-local-ca’s Root CA.

See: Kubernetes Certificates.

Unified PTP Notification Overall Sync State

The overall sync state notification (sync-state) describes the health of the timing chain on the local system. A locked state is reported when the system has reference to an external time source (GNSS or PTP) and the system clock is synchronized to that time source.

See: PTP Notification Status Conditions

New Default/Static Platform API/CLI/GUI Access-Control Roles for Configurator and Operator

In StarlingX, 5 different keystone roles are supported: admin, reader, configurator, operator and member.

In StarlingX Release 11.0, the following new keystone roles are introduced:

  • configurator

  • operator

See: Keystone Account Roles

Multi-Node Upgrades

In StarlingX Release 11.0, the restriction on K8s multi-node orchestrated upgrades has been removed. You can now perform upgrades across multiple nodes in a single orchestration strategy.

Example: Upgrading from v1.29.2 to v1.32.2

See: About Kubernetes Upgrade Cloud Orchestration

Docker Size updates

In StarlingX Release 11.0 the default Docker filesystem size is 30GB. Resize the Docker filesystem on all controllers to a minimum 50GB or more prior to upgrading the system using the following command:

system host-fs-modify <controller-name> docker=<GB>

A new deploy precheck script is added to ensure the docker filesystem size is not less than 50GB.

VIM Rollback Orchestration

StarlingX Release 11.0 introduces expanded rollback capabilities to improve system recovery during software deployments:

Manual Rollback is supported across all configurations, including AIO-SX, AIO-DX, Standard, and Standard with dedicated storage.

VIM Orchestrated Rollback is supported on duplex configurations (AIO-DX, AIO-DX+, Standard, and Standard with dedicated storage) for the following scenarios:

  • Rollback of Major Release software deployments

  • Rollback of Patch Release software deployments

  • Rollback of Patched Major Release deployments

  • Recovery from aborted or failed deployments

These enhancements aim to streamline recovery workflows and reduce downtime across a broader range of deployment scenarios.

See:

Upgrade / Rollback Process Optimization

To accelerate recovery from failed operations during software updates and upgrades, a new snapshot-based restore capability is introduced in StarlingX Release 11.0. Unlike traditional backup and restore, this feature leverages OSTree deployment management and LVM volume snapshots to revert the system to a previously saved state without requiring a full reinstall. Snapshots will be created for select LVM volumes, excluding directories such as /opt/backup, /var/log, and /scratch, as outlined in the “Filesystem Summary” below. This capability is currently limited to Simplex systems (AIO-SX).

FileSystem Summary

LVM Name

Mount Path

DRBD

Versioned**

Snapshot

root-lv

/sysroot

N

N*

var-lv

/var

N

Y

log-lv

/var/log

N

N

backup-lv

/var/rootdirs/opt/backups

N

N

ceph-mon-lv

/var/lib/ceph/mon

N

N

docker-lv

/var/lib/docker

N

Y

kubelet-lv

/var/lib/kubelet

N

Y

pgsql-lv

/var/lib/postgresql

drbd0

Y

Y

rabbit-lv

/var/lib/rabbitmq

drbd1

Y

Y

dockerdistribution-lv

/var/lib/docker-distribution

drbd8

N

N

platform-lv

/var/rootdirs/opt/platform

drbd2

Y

Y

etcd-lv

/var/rootdirs/opt/etcd

drbd7

Y

Y

extension-lv

/var/rootdirs/opt/extension

drbd5

N

N

dc-vault-lv

/var/rootdirs/opt/dc-vault

drbd6

Y

N

scratch-lv

/var/rootdirs/scratch

N

N

  • Managed by OSTree

** Versioned subpaths

See:

Platform Real Time Kernel Robustness

Stalld can be configured to use the queue_track backend, which is based on eBPF. Stalld protects lower priority tasks from starvation.

Unlike other backends, queue_track reduces CPU usage and more accurately identifies which tasks can be excecuted even if they are currently blocked waiting for a lock.

See: Configure stall daemon.

Enable CONFIG_GENEVE Kernel Configuration

StarlingX Release 11.0 supports geneve.ko kernel module, controlled by the CONFIG_GENEVE kernel config option.

Cloud User Management GUI/CLI/RESTAPI Enhancements; Deletion Restriction

In StarlingX Release 11.0, existing Local LDAP users in the sudo group do not need to be migrated to the sys_admin group.

Administrators may retain their existing configuration if required. However, to better align with the platform’s security and access control standards, it is recommended to assign restricted sudo privileges through the sys_admin group.

Administrators may optionally update their configurations by transitioning Local LDAP users from the sudo group to the sys_admin group. This can be done using ONLY the following method:

via pam_group & /etc/security/group.conf to map users into additional groups

See: Local LDAP Linux User Accounts.

In-tree and Out-of-tree drivers

In StarlingX Release 11.0 only the out-of-tree versions of the Intel ice, i40e, and iavf drivers are supported. Switching between in-tree and out-of-tree driver versions are not supported.

See:

CaaS Traffic Bandwidth Configuration

Previously, the max_tx_rate parameter was used to set the maximum transmission rate for a VF interface, with the short form -r. With the introduction of the max_rx_rate parameter that is used to configure the maximum receiving rate, both max_tx_rate and max_rx_rate can now be applied to define bandwidth limits for platform interfaces. To align with naming conventions:

  • -t short form for max_tx_rate parameter allows the configuration of the maximum transmission rate for both VF and platform interfaces.

  • r short form for max_rx_rate parameter is used to set the maximum receiving rate for platform interfaces.

See:

Rook Ceph Updates and Enhancements

Rook Ceph is an orchestrator that provides a containerized solution for Ceph Storage with a specialized Kubernetes Operator to automate the management of the cluster. It is an alternative solution for the bare-metal Ceph storage. See https://rook.io/docs/rook/latest-release/Getting-Started/intro/ for more details.

ECblock pools are renamed: Both data and metadata pools for ECblock on Rook Ceph changed names to comply with the new standards for upstream Rook Ceph.

  • Data pool was renamed from ec-data-pool to kube-ecblock

  • Metadata pool was renamed from ec-metadata-pool to kube-ecblock-metadata

Ceph version upgrade

Ceph version is upgraded from 18.2.2 to 18.2.5, with minimal impact on the upgrade.

Rook Ceph OSDs Management

To add, remove or replace OSDs in a Rook Container-based Ceph, see Remove a Host From a Rook Ceph Cluster

Note

Host-based Ceph is deprecated in StarlingX Release 11.0.

For any new StarlingX deployments Rook Ceph is mandatory in order to prevent any service disruptions during migration procedures.

User Management GUI/CLI Enhancements

For critical operations performed via the StarlingX CLI or GUI such as delete actions or operations that may impact services the system will display a warning indicating that the operation is critical, irreversible, or may affect service availability. Also the system will prompt the user to confirm before proceeding with the execution of the operation.

A user confirmation request can optionally be used to safeguard critical operations performed via the CLI. When the user CLI confirmation request is enabled, CLI users are prompted to explicitly confirm a potentially critical or destructive CLI command, before proceeding with the execution of the CLI command.

See:

Optimized Platform Processing and Memory Usage- Ph1

StarlingX Release 11.0 requires approximately 1 GB less memory, enabling more efficient deployment in resource-constrained environments.

This feature is designed to optimize platform resource utilization, specifically targeting processing and memory efficiency. This enables greater flexibility for StarlingX deployments in use cases with tighter footprint constraints.

Kubernetes Upgrade Procedure Optimization - Multi-Node

This feature enhances Kubernetes version upgrades across all StarlingX configurations including AIO-DX, AIO-DX with worker nodes, standard configurations with controller storage, and standard configurations with dedicated storage extending beyond AIO-SX.

The following enhancements are introduced:

  • Pre-caching of container images for all relevant versions during the upgrade’s preliminary phase.

  • The upgrade system now supports multi-node multi-K8s-version K8s upgrade (both manual, and orchestrated), ie.:

    • it supports multi-node upgrades of multiple Kubernetes versions in a single manual upgrade

    • it supports multi-node upgrades of multiple Kubernetes versions in a single orchestration

Previously, for multi-node environments, the Kubernetes upgrade process had to be repeated end-to-end for each version in sequence.

Now, the upgrade system checks for kubelet version skew, allowing kubelet components to run up to three minor versions behind the control plane. This enhancement enables multi-version upgrades in a single cycle, eliminating the need to upgrade kubelet through each intermediate version. As a result, the overall number of upgrade steps is significantly reduced.

See:

New features in StarlingX 10.0

See: https://docs.starlingx.io/r/stx.10.0/releasenotes/index.html#release-notes

New features in StarlingX 9.0

See: https://docs.starlingx.io/r/stx.9.0/releasenotes/index.html#release-notes

New features in StarlingX 8.0

See: https://docs.starlingx.io/r/stx.8.0/releasenotes/index.html#release-notes

New features in StarlingX 7.0

See: https://docs.starlingx.io/r/stx.7.0/releasenotes/index.html#new-features-and-enhancements