The ALASCA Tech Stack
From Europe. For Europe.
Dr. Daniel Gerber
26 August 2026
ALASCA Tech Stack
- Overview
- Our projects
- Organic growth
- What belongs together
The stack at a glance
Tarook — Lifecycle Management for Kubernetes
Tarook is a CNCF-certified Kubernetes distribution with end-to-end lifecycle management. It can roll out, operate and scale highly available clusters: on bare metal, OpenStack and Proxmox.
Project leads
- Bruno SchubertCloud & Heat
- Silvio AnkermannCloud & Heat
- Steve StarkeCloud & Heat
Written in
Nix Ansible Terraform Python
License
Apache-2.0
Where to find it
- Code gitlab.com/alasca.cloud/tarook/tarook
- Docs docs.tarook.cloud
- Mailing list tarook@lists.alasca.cloud
Why use Tarook?
Challenges
Complex installation
As soon as high availability and scalability are required, setting up a cluster turns into a lot of work.
Fast-moving ecosystem
Tools, versions and recommendations keep changing; keeping track of them takes effort.
Solution
Grows with you
Scalability and high availability are built in; rising demands do not call for a rebuild.
Best practices included
Tarook takes Kubernetes and its accompanying services through their lifecycle and ships regular updates.
Where it fits
Cluster management
Provisioning, management and scaling follow the same procedure on bare metal, OpenStack & Proxmox.
Certified Kubernetes
Certified by the CNCF for Kubernetes 1.34 to 1.36 and interoperable with other certified distributions.
8 good reasons for Tarook
Simple provisioning
Kubernetes on OpenStack or bare metal, driven from a single central configuration.
Scalable and flexible
Nix-based configuration, a choice of storage solutions and its own load balancer as an alternative to Octavia.
Highly available
keepalived and HAProxy secure the Kubernetes endpoint.
Secrets and identities
Certificates and access rights are managed automatically through HashiCorp Vault.
Modular design
k8s-core runs the kubeadm cluster, the k8s-supplements round out production operation.
GPU and vGPU
NVIDIA support for compute-intensive workloads, including AI training.
Tools already integrated
NGINX Ingress, Cert-Manager, Flux, Prometheus, Rook/Ceph, Calico and etcd backups are built in.
Open Source
Fully open source; development and changes are publicly traceable.
Krake — Workload scheduling across cloud boundaries
Krake is an orchestrator for containerised and virtualised workloads across multi-cloud, private cloud and on-premises — distributed by the metrics you choose: ecological, technical or economic.
Project leads
- Patrick ThiemCloud & Heat
Written in
Python Jinja
License
Apache-2.0
Where to find it
Why use Krake?
Challenges
Container management
Managing containers across distributed infrastructure calls for orchestration that spans them all.
Energy efficiency
Compute-intensive workloads, AI above all, drive up energy costs and CO₂ emissions.
Solution
Central control
One interface for distributed Kubernetes clusters, across sites and automated.
Flexible optimisation
Weighting follows configurable metrics such as performance, cost, energy and security.
Where it fits
Use cases
From the local development environment to the distributed production system, from the microservice to AI training.
Saxon Digital Award 2024 — Open Source category
Photo: © BLEND3 Frank Grätz
8 good reasons for Krake
One common interface
Distributed Kubernetes clusters are managed through a central abstraction layer.
Modular architecture
Microservice-based components; your own developments can be plugged into the orchestration pipeline.
Kubernetes-focused
Orchestration of Kubernetes workloads across different clusters and sites.
Intelligent scheduling
Placement follows configurable metrics such as latency, energy and cost, as well as parameters you define yourself.
Label-based scheduling
Labels and constraints give fine-grained control over which workloads run on which clusters.
Stateless and stateful
Both stateless and stateful workloads are orchestrated, from the microservice to the database system.
Infrastructure provisioning
Kubernetes clusters are provisioned and scaled automatically at different infrastructure providers.
Saxon Digital Award 2024
Awarded in the Open Source category, nominated by the expert jury and chosen in the public vote.
Yake — Installer and lifecycle tool for Gardener
Yake is a GitOps-driven installer and lifecycle manager for Gardener. Flux continuously reconciles the running system with the declarative configuration in Git — deployment and upgrade are the same routine operation.
Project leads
- Christian Berendt23technologies
Written in
Go Go Template Shell Mustache
License
Apache-2.0
Where to find it
- Code github.com/yakecloud/yake
- Docs yake.cloud/docs
Why use Yake?
Challenges
Setting up Gardener
Provisioning, lifecycle management and day-2 operations take time before the first cluster is up.
Specialist knowledge
Running it demands familiarity with many components, which makes adoption harder.
Solution
Ready in minutes
Scripts generate a base configuration that would otherwise have to be assembled by hand, step by step.
Git is the truth
The GitOps workflow keeps the installation declarative; changes are traceable and repeatable.
Where it fits
Self-hosted Gardener
For organisations running Gardener as their own Kubernetes control plane instead of consuming it as a service.
Updates as routine
Upgrade guides describe the move between versions and keep the effort of staying current low.
4 good reasons for Yake
Fast bootstrapping
The helper scripts build a running base installation out of the repository.
Declarative configuration
The entire Gardener installation lives in Git as configuration, and is traceable because of it.
Straightforward updates
Upgrade guides walk you through each version change.
Central control
One control plane for the self-hosted Gardener installation, managed in one place.
Yet another OpenStack on K8s — Fearless automation
Yaook offers fully automated and free OpenStack lifecycle management for provisioning and operating your own cloud infrastructure.
Project leads
- Stefan HoffmannCloud & Heat
- Max HarmathyUhurutec
Written in
Python Cue Shell Jinja
License
Apache-2.0
Where to find it
- Code gitlab.com/yaook/operator
- Docs docs.yaook.cloud
- Mailing list yaook@lists.alasca.cloud
Why use Yaook?
Challenges
Scalability
As a cloud grows, the control plane has to grow with it without availability suffering.
Complex configuration
Special-case settings for hardware, networks and services pile up and become hard to keep track of.
Solution
Operators
The controller pattern from Kubernetes: label changes take effect during operation, with no downtime.
Unambiguous configuration
Options are bound to node labels. Contradictions are rejected rather than merged.
Where it fits
Use cases
Usable in any environment that runs Kubernetes.
Sovereign Cloud Stack
Yaook can be used to operate SCS-compliant OpenStack.
8 good reasons for Yaook
Kubernetes-native
Runs in Kubernetes and uses its features; supports IPv4-only, IPv6-only and dual-stack.
Automated "day 2"
The operators take over ongoing operation, such as replacing failed nodes and version upgrades.
Risk-averse
Data-modifying operations happen only on explicit instruction, and only where there is no alternative.
Label-based placement
Almost every component can be placed via labels and taints.
Secure by default
All cluster-internal communication is TLS-encrypted and managed by the Cert Manager.
Mix & Match
The OpenStack services you need can be picked one by one, from a minimal to a complete installation.
Fully customisable
Every container image can be replaced with one of your own.
Open Source
Yaook is fully open source; development and changes are publicly traceable.
Seconlay — minimal IaaS with strict tenant isolation
Seconlay is an Infrastructure-as-a-Service layer built in Rust for secure tenant isolation: a deliberately minimal trusted computing base, with a control plane kept strictly apart from the data plane.
Project leads
- Felix WalterD3TN
- Georg Alexander MurzikD3TN
Written in
Rust Nix Go
License
EUPL-1.2
Where to find it
Why use Seconlay?
Challenges
Shared hardware
Safely separating other people's workloads on the same hardware remains difficult with classic IaaS.
Expensive workarounds
Physical separation makes up for complexity and poor auditability, and it costs money.
Solution
Lean TCB
Implemented in Rust, with a deliberately small trusted computing base.
Separated planes
Control plane and data plane are strictly separated, for elevated security requirements.
Benefits
Failure-tolerant
A cluster spans several machines and stays available when individual nodes fail.
Declaratively driven
A declarative API, self-healing behaviour and a Terraform provider.
Arko — Monitoring for hybrid cloud infrastructure
Arko is a standardised monitoring platform for hybrid clouds: the state of systems and applications across private and public environments at a glance, with drill-down analyses that find the fault instead of merely showing it.
Project leads
- Ivan VnuckodNation
- Roman HrosdNation
Written in
Jsonnet Go Template Shell
License
Apache-2.0
Where to find it
Why use Arko?
Challenges
Hybrid infrastructure
The state of Azure, Google and on-premises is spread across several consoles.
No vendor lock-in
Monitoring on an open source basis should be possible without being tied to a single vendor.
Solution
Intuitive
🟢 green, 🟠 orange, 🔴 red - a three-step colour code shows whether anything needs doing.
Only what matters
Each level shows only the metrics that matter at that level.
Where it fits
Hierarchical drill-down
From the overview down to the single container, details can be opened up step by step.
8 good reasons for Arko
20+ platforms & apps
Preconfigured dashboards for more than twenty platforms and applications.
10+ alert channels
Notifications can be delivered over more than ten channels.
Traffic-light status
🟢 green, 🟠 orange, 🔴 red - a three-step colour code shows the status at each level.
Only relevant metrics
Each level shows only the metrics that matter at that level.
Drill-down
Four levels, from the overview to the single container.
Logs beside metrics
Utilisation figures and log messages are shown on a shared timeline.
Hybrid
Public cloud and on-premises systems appear in one common view.
Open Source
Built on Grafana, Prometheus and Loki; no vendor lock-in is created.
Level 0 — the overview
Level 1 — the cluster
Level 2 — the nodes
Level 3 — the container
IXpect — continuous monitoring of IXP peering LANs
IXpect watches the peering LANs of internet exchanges continuously. It analyses BUM traffic to spot misconfigurations and attacks, pulls in the routers' configuration data, and reports what it finds in one place.
Project leads
- Marcel KochDD-IX
- Thomas LiskeDD-IX
Written in
Rust Nix Python Jinja
License
GPL-2.0
Where to find it
- Code codeberg.org/ixpect/ixpect
- Docs ixpect.net
- Issues codeberg.org/ixpect/ixpect/issues
Why use IXpect?
Challenges
Misconfigured routers
A faulty configuration at the network edge disturbs the routing between all networks at the IXP.
Hard to find
Such faults degrade performance, are hard to pin down and often go unnoticed.
Solution
Reading BUM traffic
IXpect evaluates the BUM traffic in the peering LAN; misconfigurations and attacks leave conspicuous patterns there.
Reporting to the NOC
Incidents are logged and, depending on severity, reported by email, Matrix or HTTP callout.
Benefits
One tool instead of many
The analyses of arpwatch, IXP-watch and ndmon are brought together in a single tool.
Knows the routers
The network parameters are taken from the existing IXP Manager; there is no second set of data to keep.
Organic growth - ALASCA's 🧊⛏️ Ice Picks
Thanos Helm chart
When the Bitnami images were restricted, Arko and Tarook lost their foundation. The community build pulls Thanos straight from upstream and is rebuilt daily.
SONiC Community Build (SCOMB)
Commercial SONiC is platform-bound, licence-bound and not open source. ALASCA is putting together an open and documented community build.
GitLab Fleeting Plugin for OpenStack
Scales GitLab runners on OpenStack. Worker instances are created and torn down again in step with the pipeline load.
Woodpecker CI
Open source CI software from the upstream project, run on our own infrastructure and independent of Microsoft and GitLab.
EU Tech Sovereignity Package
-
Chips Act 2.0, Cloud and AI Development Act, EU Open Source
Strategy
- R&D&I: support for developing the next generation of state-of-the-art cloud and AI technologies
- Capacity: 3x the EU's data centre capacity within 5 to 7 years
- Autonomy: promotion of open source solutions to strengthen resilience
-
Chips Act 2.0 - stimulating demand and industry adoption
“Creating synergies with the Cloud and AI Development Act to benefit from the demand for European chips arising from the growth of sectors such as data centres, cloud service providers and AI gigafactories.” Chips Act 2.0 — European Commission
Thank you. Stay in touch.
Web
- Website alasca.cloud
- Docs docs.alasca.cloud
- Summit 2026 alasca.cloud/alasca-summit-2026
- Tech-Talks alasca.cloud/alasca-tech-talks
- Podcast alasca.cloud/alasca-opensnac-der-podcast
- GitLab gitlab.com/alasca.cloud
Community
- Mastodon mastodon.social/@alasca
- LinkedIn linkedin.com/company/alasca-cloud
- Mailing lists lists.alasca.cloud
- Matrix #ALASCA:matrix.org
- YouTube youtube.com/@alasca_e.V.