home page » News » SCS R5 released

SCS R5 released

20 September 2023

Kubernetes – digitally sovereign

Sovereign Cloud Stack releases version 5

The Sovereign Cloud Stack project has released its fifth version. Release 5 focuses on expanding quality assurance, further standardising the technology components, and expanding and further developing the container layer based on Kubernetes Cluster API and Cluster Stacks.

As with every release of open source projects, bugs have been fixed and new features added. However, more important than the individual pieces of the puzzle is the overall picture, which is becoming increasingly complete:

Felix Kronlage-Dammers, Product Owner IaaS Reference Implementation & Operations: „SCS provides building blocks for a digital, sovereign cloud infrastructure. But we are also changing the way infrastructure is operated.“

Michael Bayr, CEO of artcodix UG, said on the occasion of the launch of his SCS Cloud: „We are grateful for all the support we have received from the SCS team and the community. We are very happy with our decision to implement SCS and look forward to working closely with the community in the future.“

SCS provides all the cloud technology fundamentals needed to achieve digital sovereignty and implement open source strategies. Many users of cloud services from the public sector, but also from the private sector and academia, expect „cloud“ to be container-based technology that, in the best case scenario, can be hosted and operated with digital sovereignty. This is possible: SCS offers a digitally sovereign, secure, complete open-source container layer as the basis for all containerised applications. And that's not all.

Automated quality assurance guarantees high reliability

„As a rapidly growing project, we need to invest more in automated testing to ensure quality even at a fast development speed. My personal highlight in the R5 cycle is therefore the successful integration of Kubernetes CNCF E2E tests into our zuul test infrastructure. This ensures consistently high quality for the container platform as well,“ says Kurt Garloff, CTO of the Sovereign Cloud Stack project at the OSB Alliance.

An important element of quality assurance is to regularly update the technologies used to the latest version. In R5, the core services of OpenStack 2023.1 (Antelope), ceph Quincy and OVN 2023.06 were implemented for the infrastructure. The container platform now officially supports Kubernetes v1.25 to v1.27; older versions still work as well. (The new version v1.28 is also available and has been successfully tested, but is currently still marked as a technical preview due to a lack of official capi support.)

The previously existing support for IPv6 has been put into regular operation at one of the partners and is now an officially supported and tested feature.

Expansion of the container layer

The solution for managing container clusters continues to be based on the CNCF Cluster API project and has been improved to meet user requirements. It can now also be used on OpenStack infrastructure with a private certificate authority and offers new control options for network addresses and access. The container registry built with Harbor technology has been integrated into cluster management, so that a registry can be rolled out with each cluster with just a few settings. This registry – or the registry.scs.community operated by the SCS project – can now also be used as a cache for upstream container registries.

For container network integration, the default setting was changed from Calico to Cilium after all E2E tests were finally completed successfully. Both solutions continue to be officially supported. With the help of Cilium, the future Gateway API can also be used, although this is currently still in technical preview status.

A new tool, the Cluster Stack Operator, will make it possible in future (planned for R6) to use the container layer (KaaS) independently of the underlying infrastructure layer (IaaS). The Cluster Stack Operator obtains information from predefined cluster stacks based on the ClusterClass cluster API feature, enabling it to create and manage Kubernetes clusters on any provider. Preliminary work was carried out for this in R5. This brings SCS's vision of developing a complete, easy-to-use cloud and container stack, whose modules can also be used individually as required, a significant step closer. The cluster stacks can be tested with a technical preview that uses the Docker provider and can be found on GitHub: https://github.com/SovereignCloudStack/cluster-stacks-demo.

User federation using Keycloak has been further improved – improvements for upstream projects (especially Keystone) have also been developed and successfully implemented. SCS is thus fulfilling its commitment to contribute to the integration of open source projects rather than further fragmentation.

Standardisation is progressing: interoperability of components and scalability of services further expanded

Standards ensure the interoperability of all components and enable the federation of services. This allows applications to be ported from one platform to another (or from one service provider to another) with minimal effort. Standardisation also allows resources to be easily scaled through federation.

There are plans to certify the SCS standards in the near future so that customers can be sure of the interoperability of the services they purchase or build themselves. The existing SCS standards are already being tested nightly by service providers using automated compliance tests. The results of these tests can be viewed online by every customer: (https://docs.scs.community/standards/) After a one-time fundamental change was necessary for SCS flavours with the transition to v2 names, no similarly difficult changes were necessary in the R5 development cycle, nor are any expected in the future. The new SSD flavours are expected to become mandatory in December 2023 with the new certification suite. (More on more flexible, diskless flavours in a blog post)

Summary of the release

SCS is standardised The standardisation of flavours has been completed: (https://scs.community/2023/08/21/diskless-flavors/Extensive tests have been implemented to regularly verify the standards of SCS-based CSPs. All current and planned standards are documented on this page: (https://docs.scs.community/standards)

SCS is understandable The new, complete documentation of the SCS is now available: (https://docs.scs.community/docs) In addition to project documentation, it also contains feedback from SCS integrators and from individuals and organisations encountering SCS for the first time, to ensure that SCS becomes even more comprehensible.

SCS enables SCS enables – on a variety of levels and not only operators, but also integrators, developers and, above all, users of infrastructures based on SCS – to use and operate a fully digital, sovereign cloud infrastructure and platform. With the new release, the cloud stack has been expanded to include essential components of the container layer, enabling SCS to also be used as an application platform and making it available for all containerised applications.

SCS is transparent Transparency is one of the core values of the project, and the community wants to ensure that all development efforts are actively geared towards transparency. This ranges from the development culture and the open operations movement to technical elements such as SBOMs for the entire stack. But it is not only the entire development process that is transparent; all results, all protocols and all documentation are open and accessible. Every decision is documented and traceable. Every error is rectified transparently.

SCS is continuously built and tested As part of the development work, the R4 cycle began with the Working on your own Zuul instance. This has now become the backbone of the test infrastructure – from executing CI for various components in the SCS stack to end-to-end testing for the CAPI provider.

SCS is opinionated While the SCS project offers a modular stack and works hard towards interoperability, the community in our reference implementation is idiosyncratic. Opinion-forming at this level leads to focus and prevents the project from getting bogged down in arbitrary „both/and“ scenarios. This forces us to make well-informed decisions. These decisions must be well documented, which is why we started using an ADR framework early on. This, in turn, pays off for SCS. Focusing on a specific toolset and dedicated open-source projects ensures deep integration, targeted development, and a stable, production-ready cloud stack that offers all users the desired benefits.

Release notes There are detailed release notes (in English).

Further links