The OpenInfra Foundation‘s open source, edge-computing cloud stack StarlingX‘s latest version, StarlingX 6.0 is out and ready to run. It’s optimized for low-latency and high-performance applications. In other words, it’s meant for Edge and Internet of Things (IoT) platforms. It does this by combining Ceph, OpenStack, Kubernetes, and other open source packages.

StarlingX’s main market to date has been telecom carriers, such as T-Systems, Verizon, and Vodafone. But enterprises, which need to deploy an edge cloud on a few to hundreds of servers are also embracing it.

Upgraded Linux Operating System

Its most fundamental new feature is that StarlingX upgraded its core Linux operating system to the Linux kernel 5.10. This was done primarily for this kernel’s support of Virtual Routing and Forwarding (VRF). With VRF, you gain the power to create virtual routing and forwarding domains in the network stack. One use case is the multitenancy problem where each tenant has its own unique routing tables, or at the very least, needs different default gateways. The Linux kernel 5.10 also has user-space tooling to configure VRF’s routing and forwarding interfaces.

The new StarlingX also comes with security enhancements. These include automated certificate management and alarms. This is done with Cert-Manager. Now platform services can use cert-manager to simplify the management (e.g. auto-renewals) of the following Platform certificates: RESTAPI /GUI certificate; registry.local certificate; and OIDC/DEX certificate.

This new certificate functionality also enables you to update the Kubernetes Root CA certificate on a running system, with either an uploaded certificate or an auto-generated certificate. Certificate orchestration is also provided for both Cloud and Distributed Cloud deployments.

With this you can also avoid the headache of expired certificates, StarlingX now will send you an alarm for expiring or already expired certificates. You can also make a separate Certificate Authority (CA) for Kubernetes and etcd. This is done with the etcd Root CA certificate. It signs etcd server and client certificates, and kube-apiserver etcd client certificates. This is also the CA certificate used to verify various server and client certificates signed by etcd Root CA certificate. With this, you can now provide a separate Root CA for Kubernetes and etcd.

Another security enhancement is its support of the Linux Auditing System, auditd. With this, you can track security violation events based on preconfigured audit rules. The events are recorded in a log file by the auditd daemon and you can use it to detect misuse or unauthorized activities. Armed with this information, you can take the appropriate actions.

Duplex Configuration

Since StarlingX’s beginnings in 2018 you could install it in an all-in-one setup Transitioning over to a different configuration was another story. Now, you can migrate the deployment to a duplex configuration that includes two controller nodes. With this, you can move from one sub-cloud deployment to the other without a fresh installation.

This also means StarlingX will soon be able to be used for disaster recovery. As part of this effort, you can now move sub-clouds between distributed cloud systems while restoring the System Controller. You can also use this technique to consolidate a deployment and shut down some unused edge sites.

Sounds interesting? You can download the StarlingX 6.0 code today and see if it meets your needs. Personally, I’ve liked StarlingX from day one, and I recommend trying it.

Featured image via Pixabay.