Sovereign Cloud Stack R9: Broadening applicability
Europe, 2025-09-29: Sovereign Cloud Stack Release 9 completed
The inspiring and sold-out SCS Summit 2025 in Berlin clearly displayed continued interest from both the public sector and the industry to leverage the SCS standards and software to reduce dependencies and risks when adopting and implementing digital solutions. For many participants, there was no question that building open standards and open source software together is what we need to do now in order to make progress with digitization and ensure that we have control, innovation and value creation capabilities.
The SCS community does also produce a complete modular open source software stack that implements the SCS standards and that is used in pieces or as a whole by more than half a dozen providers to offer public or private cloud services. The technology can certainly be considered tried and proven powering public clouds for years without any unplanned outages and for example providing the cloud platform for the "BayernCloud Schule" which is used by many hundreds of thousands of students and parents and teachers in Bavaria every day.
The SCS software receives continuous updates by the community. Twice a year, it goes the extra mile to craft a release and take extra time to communicate the progress and plan the next half year. In the summit week, the release 9 of the software was completed.
Improved hardware management
While users have the power of standardized APIs to manage their virtual machine and container environments, the cloud operators have to deal with their hardware which tends to grow more diverse over time. With the work on netbox-manager, the capabilities to generate configuration for the hardware have been extended especially for networking gear. A web-interface has been added to make it easier to keep an overview over events and status.
Current software
On the virtualization side, OSISM-10.x now provides the current OpenStack 2025.1 (Epoxy) release. As SCS operators have come to expect, the upgrade from the previous version has been validated extensively. For the first time, skipping over one release is supported, so a one-step upgrade from OSISM-8.x (with OpenStack 2024.1 Caracal) is also possible, not just from OSISM-9.x (with OpenStack 2024.2 Dalmatian).
The newer OpenStack releases come with the upstreamed domain manager role that the SCS community has worked on and contributed, providing a well-defined role for enabling self-service user and project management. The handling of pass-through PCI devices has been improved, supporting live-migrations in a broader range of scenarios despite the pass-through. This can help specifically with GPU accelerated AI workloads.
The mature ceph storage technology has been upgrade to the Reef release. Ubuntu 24.04 LTS is now used as the default operating system on the hosts, bringing support for the latest server hardware and improved performance.
The provided container node images also used Ubuntu 24.04 LTS now. Having the latest kernel optimizations is also relevant for the guest images; and with the more and more relevant GPU pass-through for AI acceleration, sometimes even hardware support. With current kernels, it is also ensured that latest innovation e.g. with eBPF being used for container networking with cilium can be leveraged.
The latest version for kubernetes cluster-API and the cluster-API provider are used, staying in sync with the upstream progress. SCS R9 comes with support for Kubernetes-1.33.x, bringing enhancements with scalability, token handling and pod management.
Simplifying maintenance with new cluster stack
SCS Kubernetes clusters need the ability to talk to the underlying OpenStack platform to create resources such as persistent volumes or load balancers and thus need a secret to authenticate their requests. The duality of two different secret formats has been cleaned up, also making it possible to support self-signed CAs without hassle. Given this change, the community has taken the opportunity to rationalize the ClusterClass variables that users use to customize their clusters. The helm charts for the add-ons (such as CNI, CSI, CCM, metrics) no longer need to be bundled in the releases but are pulled alongside the images now.
This simplifies maintenance going forward. It does however introduce a breaking change, so the "scs2" cluster stack series was started, succeeding the old "scs" series. Documentation and tooling to automate the conversion will be provided soon. The community has committed to maintain the new cluster stack series and to continuously provide the artifacts to ensure that users can easily deploy the kubernetes patch levels short-term order to stay secure.
Future
Beyond following the upstream technology evolution and continuing to adapting to it, the SCS community will work on improving the technology e.g. with respect to performance and federation capabilities. Many of the contributing companies are inspired and driven by the requests of their customers, e.g. by the increasing number of VMware to SCS migrations. The SCS community continues to provide the well-established mechanisms to encourage for communication and collaboration on those. This increase the chances that features (and of course bug-fixes) can be reintegrated in the common code base of the larger SCS community and the upstream communities. This extends beyond the current scope of the software releases. Additional software that implements the SCS standards is encouraged to leverage those same mechanisms.
The next releases are open to including more alternatives for the existing software platform, but the focus is mainly on doing the standardization and software implementation work to be the ideal foundation to run services and workloads on top of SCS-standardized suitable standards and software that supports it.
