AppCat v4.188.0 ist ein kleineres Release mit technischen Verbesserungen im Hintergrund – aber es enthält eine wichtige Ankündigung: VSHN PostgreSQL with StackGres erreicht am 31. August 2026 das End of Life.
VSHN PostgreSQL with StackGres – End of Life am 31. August 2026
VSHN PostgreSQL with StackGres erreicht am 31. August 2026 das End of Life. Alle neuen PostgreSQL-Instanzen verwenden bereits CloudNativePG – das im letzten AppCat-Release zum Standard wurde. Wer noch nicht migriert hat, sollte jetzt damit beginnen.
Eine neue PostgreSQL-Instanz auf CloudNativePG von Grund auf neu erstellen.
Bei Fragen stehen wir gerne zur Verfügung.
Das grössere Bild: ein reifes souveränes Ökosystem
Die Ablösung von StackGres ist Teil der breiteren Weiterentwicklung von AppCat als operativer Grundlage des souveränen Managed-Services-Ökosystems von VSHN.
Wer verstehen möchte, wie AppCat ins grosse Bild passt – von Framework 0.1 im Jahr 2021 bis hin zu Servala und AppSlap 2.0 heute – findet die Antworten in unserem aktuellen Beitrag: Eine Tour durch unser digital souveränes Ökosystem.
Kontinuierliche Verbesserungen im Hintergrund
Wie bei den meisten AppCat-Releases enthält auch v4.188.0 eine Reihe kleinerer technischer Verbesserungen, die die Plattform stabil und wartbar halten. Das sind die Änderungen, die keine Schlagzeilen machen – aber genau dafür sorgen, dass produktive Workloads zuverlässig laufen.
VSHN AppCat Update – CloudNativePG wird neuer Standard für PostgreSQL
28. Mai 2026
Das neueste VSHN AppCat Release v4.187.0 setzt den Wandel der Plattform hin zu einem Kubernetes-nativeren PostgreSQL-Erlebnis fort.
Mit diesem Release wird CloudNativePG offiziell zur Standard-PostgreSQL-Implementierung für alle neu erstellten PostgreSQL-Instanzen in AppCat. Bestehende Instanzen bleiben unverändert, neue Deployments verwenden jedoch künftig automatisch das CloudNativePG-basierte Setup.
Dies markiert einen weiteren wichtigen Meilenstein in der Reifung des PostgreSQL-Betriebs innerhalb von AppCat.
CloudNativePG ist nun Standard für PostgreSQL
CloudNativePG hat sich über die letzten Releases stetig innerhalb von AppCat weiterentwickelt und den Punkt erreicht, an dem es zur Standardwahl für neue PostgreSQL-Deployments wird.
Für Nutzerinnen und Nutzer bedeutet das:
Neue PostgreSQL-Instanzen verwenden automatisch CloudNativePG
Verbesserter Kubernetes-nativer Betrieb
Bessere langfristige Wartbarkeit
Fortlaufende Investitionen in das CloudNativePG-Ökosystem
Teams, die bereits ältere PostgreSQL-Implementierungen betreiben, können diese weiterhin normal nutzen, während die Migrationsplanung im eigenen Zeitrahmen erfolgen kann.
Verbesserungen über die gesamte Plattform hinweg
Neben dem PostgreSQL-Wandel enthält das Release auch mehrere betriebliche Verbesserungen und Fehlerbehebungen über die gesamte Plattform hinweg.
Bessere Handhabung der Garage-CRD-Versionen
Das Release verbessert wie Garage-CRD-Versionen intern gehandhabt werden. Dies trägt zu einem vorhersehbareren Verhalten bei Upgrades und Plattformwartung bei.
Verbesserte Handhabung des topologyKey für CloudNativePG
Die Topologie-Handhabung für CloudNativePG-Deployments wurde verfeinert, um die Scheduling-Konsistenz in Kubernetes-Clustern zu verbessern.
Bessere Warnungen für enableSSHInRelease
Die Handhabung von enableSSHInRelease bietet nun ein verbessertes Warnverhalten und hilft Nutzerinnen und Nutzern, mögliche Auswirkungen bei Deployments und Wartungsarbeiten besser zu verstehen.
Kontinuierliche Verbesserungen hinter den Kulissen
Viele AppCat Releases konzentrieren sich auf operative Exzellenz statt auf auffällige, nach aussen sichtbare Features – und genau das hält Produktionsplattformen über die Zeit zuverlässig. Indem AppCat CloudNativePG zur Standard-PostgreSQL-Grundlage macht und das Plattformverhalten kontinuierlich verfeinert, bewegt es sich weiter in Richtung einer stabileren, Kubernetes-nativen und zukunftssicheren Applikationsplattform.
Writing a Kubernetes Cluster Autoscaler Provider with externalgrpc
27. Mai 2026
Teaching Cluster Autoscaler to speak cloudscale.ch without forking the autoscaler or waiting for an upstream provider integration.
Introduction
What do you do when Kubernetes Cluster Autoscaler supports the scaling logic you need, but not the cloud provider you run on?
That was the problem behind this experiment. I wanted Cluster Autoscaler to work on cloudscale.ch. There was no upstream provider for it, and I did not want to fork the autoscaler or carry an in-tree provider forever.
The answer was externalgrpc: a cloud provider integration mode that lets Cluster Autoscaler keep its core decision logic while delegating cloud-specific actions to a separate gRPC service.
This post walks through how Cluster Autoscaler makes scaling decisions, what the provider contract looks like, how externalgrpc fits into the architecture, and the practical gotchas I ran into while building an autoscaler provider for cloudscale.ch.
The autoscaler knows when, not how
The first important mental model is this:
Cluster Autoscaler knows when the cluster should scale, but it does not inherently know how to create or delete machines.
The core autoscaler logic decides things like:
Are there pending Pods that cannot be scheduled anywhere?
Would those Pods fit on a node from a configured node group?
Has a node been idle long enough that its Pods could be moved elsewhere?
Which node group should be increased or decreased?
What it does not know is how to create a VM, which image to use, how to pass bootstrap data, how the node joins the cluster, or how to delete the machine again.
That part is delegated to a cloud provider plugin.
For large providers, there are already in-tree implementations. But if your provider is not on the list, you need another strategy.
What happens every 10 seconds
By default, Cluster Autoscaler runs a reconciliation loop roughly every 10 seconds. In each loop, it asks a set of questions:
Are there unschedulable Pods?
Would those Pods fit on a node from a configured node group?
If yes, call NodeGroupIncreaseSize(group, delta).
Are there nodes that have been idle for long enough?
Can their Pods be rescheduled elsewhere?
If yes, call NodeGroupDeleteNodes(group, nodes).
The provider does not make these decisions. The provider only receives the result of the decision, for example: “increase this node group by three nodes.”
That separation is useful. It means a provider implementation can stay relatively small. The hard Kubernetes scheduling logic remains in Cluster Autoscaler.
The simulator is the scheduler
Cluster Autoscaler does not reimplement Kubernetes scheduling from scratch. It imports the Kubernetes scheduler framework and uses the same kinds of filter logic the scheduler uses.
That includes scheduling constraints such as:
node resource fit
node affinity
taints and tolerations
topology spread constraints
inter-pod affinity
volume binding
node ports
volume limits
The autoscaler runs these checks against an in-memory snapshot of the cluster. For scale-down, it can simulate removing candidate nodes and see whether their Pods would fit elsewhere. For scale-up, it can simulate whether pending Pods would fit on a hypothetical node from a node group.
That is where one of the most important provider methods comes in: NodeGroupTemplateNodeInfo.
Node groups, flavours, and choosing what to scale
If the cloud provider supports multiple VM types, sizes, or flavours, the provider usually exposes those as separate node groups. For example, one node group might represent small general-purpose workers, another might represent larger memory-optimized workers, and another might represent nodes with different labels or taints.
Cluster Autoscaler then runs the simulation against the configured node groups. If more than one group could fit the pending Pods, the configured expander decides which group wins. Depending on configuration, that can be random, most-pods, least-waste, price, priority, or another supported strategy.
This gives you a useful amount of flexibility, but it is still not Karpenter. Cluster Autoscaler chooses from node groups that already exist as configured abstractions. Karpenter has a more dynamic provisioning model and can reason more directly about instance types, constraints, and provisioning choices.
So the mental model is:
Cluster Autoscaler: choose between predefined node groups
Karpenter: more dynamic node provisioning based on workload requirements and available instance types
For an externalgrpc provider, this means the provider should model each relevant cloudscale.ch flavour as a node group, return accurate template node information for each one, and let the autoscaler’s simulator and expander decide which group should grow.
Why externalgrpc?
If your cloud provider is not supported upstream, there are three realistic options:
Approach
What it means
Trade-off
Upstream in-tree provider
Add your provider to kubernetes/autoscaler
High review and maintenance burden, tied to upstream release cycles
Fork Cluster Autoscaler
Maintain your own autoscaler build
Maximum control, but you own the fork forever
externalgrpc
Run a standalone provider service over gRPC
Separate release cycle, language-agnostic, small provider surface
For cloudscale.ch, externalgrpc was the pragmatic option.
It avoids the need to become an upstream autoscaler maintainer. It avoids carrying a fork. And because the provider is just a gRPC service, it can be implemented in any language. In this case, I used Go.
At the time of writing, it also aligns well with where the autoscaler project appears to be heading. The ongoing SIG Autoscaling refactor proposal points toward splitting provider implementations out of the main autoscaler repository. In that future, providers would either consume the autoscaler core as a library or communicate out of process via externalgrpc.
For an independent provider implementation, that makes externalgrpc a good escape hatch.
Architecture
At a high level, the architecture looks like this:
Pending Pods
|
v
Cluster Autoscaler
|
| gRPC over mTLS
v
autoscaler-cloudscale
|
| cloudscale.ch REST API
v
cloudscale.ch VMs
|
v
VM boots, kubelet joins, CCM stamps providerID
The Cluster Autoscaler remains the brain. It watches the Kubernetes cluster, notices pending Pods, runs scheduling simulations, and decides whether a node group should grow or shrink.
The external provider is the hands. It receives requests from Cluster Autoscaler and performs cloud-specific actions:
list cloudscale.ch servers
create VMs
tag VMs
delete VMs
map Kubernetes nodes back to cloudscale.ch servers
The provider also needs configuration for node groups, for example:
In my setup, the VM bootstrap is handled through Talos Linux machine configuration passed as user data. The VM boots, Talos configures the node, kubelet joins the cluster, and the cloud controller manager stamps the node with a provider ID.
That provider ID is critical. Without it, the autoscaler cannot reliably connect a Kubernetes Node back to the corresponding cloud VM. Scale-down depends on this mapping.
The provider contract: six important RPCs
The externalgrpc proto contains more methods, but the core provider behavior is built around a small set of RPCs:
RPC
Purpose
Refresh
Reconcile provider state with the cloud
NodeGroups
Return configured node groups
NodeGroupForNode
Map a Kubernetes node to a node group
NodeGroupTemplateNodeInfo
Describe what a new node would look like
NodeGroupIncreaseSize
Create new servers for a node group
NodeGroupDeleteNodes
Delete specific servers
The remaining methods are either bookkeeping or can be implemented as explicit Unimplemented stubs, as long as the service satisfies the proto contract.
The most important design decision is to make the cloud provider the source of truth. Do not trust only local state. VMs can be manually deleted, failed creates can leave partial state, and API calls can fail halfway through.
In practice, Refresh lists servers from the cloud provider API, filtered by tags, and rebuilds the provider’s internal view.
Conceptually:
servers, err := api.Servers.List(ctx, cloudscale.WithTagFilter(tags))
if err != nil {
return err
}
byUUID := make(map[string]*cloudscale.Server, len(servers))
for i := range servers {
byUUID[servers[i].UUID] = &servers[i]
}
cache.Store(byUUID)
Tags are what scope the provider to the right cluster and node group. In this implementation, group membership is represented with a tag such as:
k8s-autoscaler-group=<name>
TemplateNodeInfo: modelling future nodes
When scaling from zero, there may be no real worker node in the cluster. So how can Cluster Autoscaler know whether a pending Pod would fit on a node that does not exist yet?
The provider has to describe what a future node would look like.
NodeGroupTemplateNodeInfo returns a synthetic Kubernetes Node object. This object tells the autoscaler things like:
CPU capacity
memory capacity
disk-related properties
labels
taints
allocatable resources
maximum Pod count
special devices or constraints
This is where the provider has to “lie” to the autoscaler, but only in a very specific sense. The node is not real yet. It is a placeholder used for scheduling simulation.
As an analogy, this is conceptually similar to the idea of virtual nodes: an object that represents capacity that is not currently a normal worker node. This is only an analogy, not Virtual Kubelet and not a real virtual-node implementation. Cluster Autoscaler does not schedule Pods onto this synthetic node. It uses the template to answer the question: “If I created a node like this, would these pending Pods fit?”
In other words, the template node is not runtime capacity. It is simulated future capacity.
One easy mistake is to expose the raw VM flavor as the node capacity without accounting for kubelet reservations, system reservations, or eviction thresholds. A VM with 8 GiB of memory does not have 8 GiB of allocatable memory for workload Pods.
Another easy mistake is forgetting to set ResourcePods. If the template node says it can run zero Pods, the autoscaler will correctly conclude that no workload can ever fit there.
That bug is wonderfully frustrating: everything looks wired up, the autoscaler runs, but nothing scales.
Creating nodes: target size first, VM later
When Cluster Autoscaler decides to increase a node group, it calls NodeGroupIncreaseSize with a delta.
The provider then needs to:
Increase the target size in its own node group state.
Create the requested number of VMs.
Tag them correctly.
Pass the bootstrap configuration.
Wait for the nodes to appear in Kubernetes.
Let Refresh reconcile the actual cloud state again.
It is important to distinguish three different states: desired capacity, in-flight capacity, and joined Kubernetes nodes. A VM may be requested but not yet visible, booting but not yet joined, or joined but not yet Ready. During that period, Cluster Autoscaler must not repeatedly create more and more machines every 10 seconds.
Cluster Autoscaler also has guardrails for failed provisioning. If a node does not join within the configured provisioning duration, the autoscaler can treat that scale-up as failed and move on.
Bootstrapping with Talos
In this implementation, node bootstrap is intentionally kept outside the autoscaler’s core logic.
The node group config contains the Talos machine configuration as user data. When autoscaler-cloudscale creates a VM, it passes that user data to cloudscale.ch. Talos then handles the rest:
boot the custom image
apply machine configuration
use the configured certificates and join tokens
start kubelet
join the Kubernetes cluster
This keeps the provider focused on VM lifecycle management rather than becoming a full cluster lifecycle engine.
The one hard requirement is that the cluster has a working cloud controller manager. It must stamp Kubernetes nodes with a provider ID, because that is the bridge between Kubernetes objects and cloudscale.ch servers.
No provider ID means no reliable scale-down.
Demo: scale from zero workers
The demo shows a Kubernetes cluster on cloudscale.ch starting with only a control plane node and no workers. Workload pressure is then applied to trigger the autoscaler and the external provider.
To generate that pressure, the demo deploys 50 replicas of the Kubernetes pause container with small CPU and memory requests – a deliberately boring Deployment that exists only to create scheduling demand.
The Pods could not be scheduled because there were no worker nodes. Cluster Autoscaler noticed the pending Pods, simulated whether they would fit on a node from the configured worker group, and called the external provider.
The provider created three cloudscale.ch VMs. They booted the Talos image, installed to disk, rebooted, joined the cluster, and eventually became Ready. At that point, Kubernetes could schedule some of the pending Pods onto the new workers.
The important part of the demo is not the exact terminal output. It is the separation of responsibilities:
Kubernetes produced pending Pods.
Cluster Autoscaler simulated future capacity using TemplateNodeInfo.
The expander selected a configured node group.
The externalgrpc provider created the cloudscale.ch VMs.
Talos bootstrapped the nodes into the cluster.
The CCM stamped provider IDs so the autoscaler could map Kubernetes nodes back to cloud VMs.
That makes the demo a useful validation of the whole architecture without turning the blogpost into a screen-recording transcript.
Gotchas
1. TemplateNodeInfo is easy to get subtly wrong
The autoscaler’s decision quality depends heavily on the synthetic node returned by NodeGroupTemplateNodeInfo.
If allocatable CPU or memory is too optimistic, the autoscaler may under-scale. If it is too pessimistic, it may over-scale. If ResourcePods is missing or zero, nothing will schedule at all.
This method feeds both scale-from-zero and the internal “upcoming node” logic. Treat it as part of the scheduling model, not as a cosmetic metadata method.
2. Tags are not optional
Tags are how the provider knows which cloud VMs belong to which cluster and node group.
Without consistent tags, Refresh cannot reliably reconcile state. Scale-down becomes dangerous because the provider cannot know which machine corresponds to which Kubernetes node.
3. The cloud is the source of truth
Local state is useful, but it is not authoritative.
Manual deletes, failed creates, partial outages, quota issues, and API timeouts all happen. Refresh should reconcile against the provider API every loop and rebuild the cache from reality.
4. Lock ordering matters
Provider implementations often keep shared caches plus per-node-group state. If multiple mutexes are involved, lock ordering needs to be consistent.
One subtle bug here was a potential deadlock between Refresh and target-size updates. The fix was to always acquire locks in the same order.
5. No CCM, no reliable scale-down
A cloud controller manager is not just a nice addition. It is what stamps the Kubernetes node with the providerID that lets the autoscaler map a Kubernetes Node to a cloud VM.
Scale-up can appear to work without a complete mapping. Scale-down will not be safe.
Takeaways
Writing a Cluster Autoscaler provider is less about reimplementing autoscaling and more about providing the missing cloud-specific glue.
Cluster Autoscaler already knows how to:
detect pending Pods
simulate scheduling
account for DaemonSets
apply backoff
choose node groups
avoid duplicate scale-ups
decide when nodes can be removed
The provider needs to know how to:
describe a future node accurately
create VMs
delete VMs
tag resources
reconcile cloud state
map Kubernetes nodes back to cloud resources
bootstrap machines into the cluster
With externalgrpc, that provider can live as a standalone binary with its own release cycle. For unsupported clouds, lab environments, private infrastructure providers, or sovereign cloud platforms, that is a very practical integration model.
In this case, the result was a small Go service that taught Cluster Autoscaler how to operate on cloudscale.ch without modifying the autoscaler itself.
The autoscaler remained the brain. The external provider became the hands.
That is the real value of externalgrpc. It is not the most glamorous integration point, but it is exactly the right abstraction when you want to keep autoscaling logic upstream and put cloud-specific lifecycle logic in your own hands.
If you’d like to dive deeper, check out the blog post on my personal blog, where I explore the topic in more detail.
Marco De Luca
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
Mit AppCat v4.186.0 ist im Hintergrund einiges passiert. Dieses Release dreht sich weniger um sichtbare UI-Änderungen und vielmehr um die Grundlage für das, was als Nächstes kommt: tiefere Servala-Integration, verbesserte Storage-Operations und neue Services am Horizont.
Von zusätzlichen Networking- und Storage-Funktionen für Servala über die Vorbereitung von Migrationen von MinIO zu Garage bis hin zur stillen Einführung erster OpenBao-Unterstützung – dieses Release baut die nächste Plattformschicht.
Ein grosser Teil dieses Releases fokussiert sich auf den Ausbau der technischen Grundlage hinter Servala – Sovereign App Store.
Mehrere neue Funktionen wurden in AppCat ergänzt, um zukünftige Services und Integrationen zu unterstützen, darunter Generic Object Buckets, HTTPRoute, TCPRoute sowie TCP Gateway Support.
Auch wenn viele dieser Verbesserungen aktuell für Endnutzer noch unsichtbar bleiben, sind sie wichtige Bausteine für flexiblere und produktionsreife Services über Servala.
Das ist eines dieser Releases, dessen Wirkung erst mit der Zeit sichtbar wird.
Wir haben begonnen, Metrics und Monitoring-Daten für Garage Object Storage zu sammeln.
Dadurch verbessern wir Alerting, operative Transparenz und die Zuverlässigkeit unserer Managed Object Storage Services.
Gleichzeitig starten wir offiziell den Migrationspfad von MinIO zu Garage.
Garage entwickelt sich zur zukünftigen Standardlösung für Object Storage Services innerhalb von AppCat und Servala. Bestehende Nutzer werden bald von uns hören, damit wir Migrationen gemeinsam planen können.
Das Ziel ist einfach: bessere Operations, höhere Skalierbarkeit und eine langfristig bessere Experience.
Eine kleine Zeile im Changelog deutet möglicherweise bereits auf eine der spannendsten Ergänzungen der letzten Monate hin: OpenBao.
Der Service ist aktuell noch nicht öffentlich verfügbar, aber die ersten Bausteine landen bereits in AppCat.
OpenBao ist ein Open Source Fork von HashiCorp Vault mit Fokus auf offene Governance und Community-getriebene Entwicklung. Für Organisationen, die sich mit sicherem Secret Management, Verschlüsselung und Identity Workflows ohne Vendor Lock-in beschäftigen, ist das ein sehr spannendes Thema.
Wir freuen uns sehr auf die Möglichkeiten hier – mehr Informationen folgen bald.
PostgreSQL mit CloudNativePG ist jetzt produktionsreif
Ein weiterer wichtiger Meilenstein: PostgreSQL by VSHN mit CloudNativePG ist jetzt offiziell produktionsreif.
In den letzten Monaten hat sich CloudNativePG von einer vielversprechenden neuen PostgreSQL-Grundlage zur zukünftigen Standardrichtung für PostgreSQL Services in AppCat entwickelt.
Mit Self Service Restore, operativer Reife und vorhandenen Migrationstools empfehlen wir Nutzern, Migrationen auf CloudNativePG-basierte PostgreSQL-Instanzen zu planen.
Ihr könnt entweder selbst der Migrationsanleitung folgen oder euch bei der Migration von uns unterstützen lassen.
Nicht jedes AppCat Release dreht sich um grosse neue Features. Oft passiert die wichtigste Arbeit in den Plattform-Grundlagen: Networking, Observability, Migrationen, Zuverlässigkeit und die Vorbereitung der nächsten Service-Generation.
AppCat v4.186.0 ist genau so ein Release.
Und auch wenn einige Verbesserungen heute noch unsichtbar bleiben, prägen sie bereits jetzt, was Nutzer morgen bauen und betreiben können.
VSHN AppCat Update – CloudNativePG PostgreSQL ist jetzt vollständig in AppCat verfügbar
28. Apr. 2026
Mit AppCat v4.185.0 ist PostgreSQL auf Basis von CloudNativePG jetzt vollständig in AppCat verfügbar. Was als neue Grundlage für den Betrieb von PostgreSQL auf Kubernetes begonnen hat, ist damit funktional komplett umgesetzt.
Ein wichtiger Schritt auf dem Weg dorthin war das Schliessen der letzten verbleibenden Lücke: Self Service Restore.
Self Service Restore vervollständigt den Funktionsumfang
Self Service Restore für PostgreSQL war das letzte fehlende Element. Mit dieser Funktion ist der auf CloudNativePG basierende PostgreSQL-Service in AppCat nun vollständig verfügbar.
Du kannst deine PostgreSQL-Instanzen jetzt selbst wiederherstellen und den Prozess mithilfe des bereitgestellten Restore-Guides testen.
Im Zuge dieses Releases wird CloudNativePG PostgreSQL zur Standarddatenbank für neue Nextcloud-Deployments.
Diese Änderung betrifft nur neu bereitgestellte Instanzen. Bestehende Setups bleiben unverändert.
Beim Erstellen einer neuen Nextcloud-Instanz kannst du weiterhin eine bereits bestehende PostgreSQL-Datenbank anbinden. Wenn du eine Migration planst, erhältst du bei Bedarf Unterstützung.
Aufräumen im Object Storage mit dem Garage Operator
Dieses Release adressiert auch ein praktisches Problem im Umgang mit Object Storage.
Bisher wurden Buckets, die zur Löschung markiert waren, nicht entfernt, wenn sie noch Daten enthielten. Dadurch haben diese weiterhin Speicherplatz belegt.
Mit der Einführung von Garage Cleanup werden nun alle Objekte innerhalb eines Buckets automatisch gelöscht, sobald dieser in den Löschstatus wechselt. Dadurch kann der Bucket vollständig entfernt werden und es bleibt kein unnötig belegter Speicher zurück.
Zusammenfassung
Mit der Einführung von Self Service Restore ist PostgreSQL mit CloudNativePG in AppCat jetzt vollständig verfügbar. Gleichzeitig wird es zur Standardwahl für neue Nextcloud-Deployments, während Verbesserungen wie automatisches Bucket Cleanup operative Randfälle sauber lösen.
VSHN AppCat Update – Grosse PostgreSQL Upgrades und mehr Kontrolle über Kosten
16. Apr. 2026
Der Betrieb von zustandsbehafteten Services auf Kubernetes gehört seit jeher zu den komplexeren Herausforderungen – insbesondere wenn es um Datenbanken wie PostgreSQL geht.
Mit dem neuesten VSHN AppCat Release führen wir einen wichtigen Meilenstein für unser PostgreSQL-Angebot auf Basis von CloudNativePG ein, zusammen mit Verbesserungen, die dir mehr Kontrolle darüber geben, wie deine Services verwaltet und betrieben werden.
Dieses Release konzentriert sich auf drei zentrale Bereiche: Datenbank Lifecycle Management, Nutzerkontrolle und Kostenoptimierung.
Was ist VSHN AppCat?
VSHN AppCat ist der VSHN Application Catalog – eine kuratierte Sammlung produktionsreifer Anwendungen, die mit minimalem Aufwand auf Kubernetes bereitgestellt und betrieben werden können.
Anstatt komplexe Software-Stacks manuell zu installieren und zu betreiben, ermöglicht AppCat Teams, Services wie Datenbanken, Identity Provider oder Kollaborationsplattformen als vollständig gemanagte Anwendungen zu nutzen.
AppCat umfasst:
Automatisierte Betriebs- und Lifecycle-Prozesse
Integriertes Monitoring, Backups und Wartung
Konsistente Deployments über verschiedene Kubernetes-Umgebungen hinweg
Dadurch können sich Teams auf ihre Anwendungen konzentrieren, während VSHN die operative Komplexität im Hintergrund übernimmt.
Grosse PostgreSQL Versions-Upgrades mit CloudNativePG
Dieses Release bringt eine wichtige neue Funktion für PostgreSQL in AppCat: Major-Version-Upgrades mit CloudNativePG.
Zum ersten Mal können Nutzer die Hauptversion ihrer PostgreSQL-Instanzen direkt innerhalb der AppCat-Umgebung upgraden.
Major-Version-Upgrades gehören zu den sensibelsten Operationen im Datenbank Lifecycle Management. Diese Funktion als Teil eines Managed Services bereitzustellen, ist ein wichtiger Schritt für nachhaltige und langfristig stabile PostgreSQL-Workloads auf Kubernetes.
Zusätzlich haben wir User-Management-Funktionen für PostgreSQL in unserem CloudNativePG-basierten Angebot eingeführt.
Während PostgreSQL selbst schon immer Benutzerverwaltung unterstützt hat, ist diese Funktionalität nun direkt in das von AppCat gemanagte CloudNativePG Setup integriert.
Das gibt dir mehr direkte Kontrolle über Datenbankzugriffe und Rollen innerhalb deiner gemanagten PostgreSQL-Instanzen.
Eine weitere wichtige Neuerung in diesem Release ist die “Bring Your Own Bucket”-Funktion.
Du kannst jetzt deinen eigenen, nicht von AppCat verwalteten Object Storage Bucket für Backups verwenden, anstatt automatisch bereitgestellten Storage zu nutzen.
Wenn ein Bucket angegeben wird, verwendet AppCat die bereitgestellten Zugangsdaten und überspringt die interne Bucket-Provisionierung vollständig.
Das ist besonders interessant für Organisationen, die:
Bereits eigene Storage-Infrastruktur betreiben
Storage über mehrere Services hinweg konsolidieren möchten
Der Betrieb von Datenbanken und zustandsbehafteten Services auf Kubernetes entwickelt sich stetig weiter – und dieses Release ist ein wichtiger Schritt nach vorne.
Mit Major-Version-Upgrades, integriertem User Management und mehr Kontrolle über Backup-Infrastruktur erweitert AppCat kontinuierlich die Möglichkeiten von Managed Services auf Kubernetes.
Wie immer bleibt das Ziel gleich: komplexe Operationen einfacher, sicherer und planbarer für Teams zu machen, die produktive Workloads betreiben.
Espejote (grosser Spiegel auf Spanisch) verwaltet beliebige Ressourcen in einem Kubernetes-Cluster. Von Grund auf entwickelt, um Server-Side Apply und Jsonnet-Templating optimal zu nutzen.
Wir betreiben bei VSHN eine grosse Anzahl von Kubernetes-Clustern für unsere Kunden und wir versuchen, so viel wie möglich zu automatisieren, um unsere Betriebsabläufe effizient und nachhaltig zu gestalten. Wir nutzen GitOps-Prinzipien, aber manchmal muss externer Zustand mit dem in Git definierten Zielzustand zusammengeführt werden. Diese GitOps-Reise führte uns von Ansible-Playbooks, die direkt YAML anwenden, über verschiedene Operatoren, hin zu Bash-„Reconcilern“ und schliesslich zu Espejote, unserem neuen GitOps-Operator.
Kapitel 1: Die Ansible-Ära und erste Operator-Versuche
Am Anfang nutzten wir Ansible-Playbooks und eigene Rollen, um unsere OpenShift 3 Kubernetes-Cluster zu verwalten. Wir hatten eine Sammlung von YAML-Dateien, die den gewünschten Zustand unserer Cluster definierten und führten Ansible-Playbooks aus, um diese auf die Cluster anzuwenden. Das funktionierte, war aber nicht besonders effizient. Wir mussten die Playbooks manuell ausführen, und wenn wir das vergassen, drifteten die Cluster vom gewünschten Zustand ab.
Die Sammlung von Rollen erhielt den Spitznamen „mungg“, das schweizerdeutsche Wort für „Murmeltier“. Niemand weiss genau warum, aber der Name blieb.
Wir begannen gerade erst damit, Operatoren zu entwickeln und entwickelten espejo, um Ressourcen schnell zwischen Namespaces zu synchronisieren. Es war die sehr frühe Phase unserer Operator-Reise.
Kapitel 2: Das Meer der Operatoren und der Tränen
Um das Problem der manuellen Eingriffe zu lösen (und weil wir auf OpenShift 4 migrierten, wo das Installationsverfahren kein Ansible mehr nutzt), begannen wir, uns mit Kubernetes-Operatoren zu beschäftigen. So schwer kann es doch nicht sein, ein Kubernetes-Manifest zu patchen. Oder? Falsch. Einige Operatoren waren fehlerhaft, andere nicht flexibel genug, manche gerieten zufällig in Reconcile-Loops und die meisten verbrauchten zu viele Ressourcen. Einige brachten sogar unsere API-Server zum Absturz. Wir begannen mit resource-locker-operator, migrierten zu patch-operator, verursachten Ausfälle mit Kyverno und testeten alle Policy-Engines, die wir finden konnten. Kubewarden war die einzige, die uns wirklich gefiel, aber die Cluster-Context-API war noch nicht flexibel genug für unsere Anwendungsfälle.
Espejo war ein guter Anfang, aber wir hatten noch nicht die Erfahrung, gut designte Operatoren zu bauen. Das zeigte sich. Jedes Event löste eine vollständige Reconciliation aller Ressourcen aus, wodurch die Synchronisation in grösseren Clustern drastisch langsamer wurde. Uns fehlte viel Flexibilität.
Kapitel 3: Verzweifelte Suche nach stabilen Landungen
Wir hatten genug von den ständigen Bugs und Breaking Changes in Kyverno und patch-operator wurde kaum gepflegt. Espejo war an seine Grenzen gestossen.
Verzweifelte Zeiten erfordern verzweifelte Massnahmen, also begannen wir, eine Mischung aus Bash-„Reconcilern“ – Hacks mit Cronjobs, kleinen eigenen Controllern und Vorverarbeitung von Ressourcen in Project Syn.
Ein wachsendes Problem waren unsere stark angepassten OpenShift-Alerting-Regeln. Wir kuratieren Upstream-Regeln und aktivieren nur diejenigen, die wir benötigen. Einige sind stark modifiziert. Mit jeder OpenShift-Version werden die Upstream-Definitionen verschoben und sind teilweise nur noch in Go-Code eingebettet verfügbar. Wir brauchten etwas, das bereits im Cluster deployte Regeln patchen kann, da dies die einzige stabile Schnittstelle war.
Kapitel 4: Espejote, der neue GitOps-Operator
Mit wachsender Operator-Erfahrung und unserer Begeisterung für Jsonnet entschieden wir uns, unseren eigenen Operator zu bauen – einen, der alles kann. Wir wollten etwas Flexibles, Effizientes und Einfaches. Etwas, das all unsere Anwendungsfälle abdeckt, vom Synchronisieren von Ressourcen zwischen Namespaces bis hin zum Patchen von OpenShift-Alerting-Regeln.
Espejote ist das Ergebnis dieser Reise. Es kombiniert Cluster-Zustand mit GitOps-Prinzipien und nutzt Jsonnet zur Definition des gewünschten Zustands. Es cached den Cluster-Zustand effizient, und die Reconcile-Trigger-Logik ist explizit definiert. Sinnvolle controller-runtime Rate Limits kommen zum Einsatz. Jsonnet bietet enorme Flexibilität, und natives Server-Side Apply macht das Hinzufügen und Entfernen von Schlüsseln einfach. Jeder Espejote „Resource Manager“ – also der dynamische Controller pro Konfigurationseinheit – nutzt eine eigene ServiceAccount für Least Privilege.
Espejote ist genau der Operator, den wir immer wollten und wir freuen uns, ihn mit der Welt zu teilen.
Was ist Espejote?
Espejote ist ein Kubernetes-Operator, mit dem du beliebige Ressourcen in einem Kubernetes-Cluster verwalten kannst. Er kombiniert GitOps-Prinzipien mit dem Zustand im Cluster.
Warum Espejote?
Es gibt viele ähnliche Tools (und Policy-Engines), aber Espejote hebt sich durch drei zentrale Säulen ab:
1. Powered by Jsonnet
Espejote nutzt Jsonnet als Templating-Engine. Im Gegensatz zu YAML kombiniert mit Go-Templates behandelt Jsonnet Konfigurationen als Datenstruktur. Es versteht Objekte, Arrays und Strings. Es kann nicht versehentlich fehlerhaftes YAML erzeugen, da Jsonnet sicherstellt, dass die interne Datenstruktur gültig ist, bevor überhaupt eine Datei exportiert wird.
2. Native Server-Side Apply
Espejote wurde von Grund auf für Server-Side Apply (SSA) entwickelt. Das bedeutet, dass Espejote gut mit anderen Controllern und Operatoren zusammenarbeitet. Es kann einzelne Annotationen oder komplette Ressourcen verwalten – SSA sorgt dafür, dass Änderungen sauber zusammengeführt werden, ohne andere Tools zu überschreiben.
3. Zuverlässigkeit
Zuverlässigkeit ist kein nachträglicher Gedanke. Espejote entstand aus der Frustration über Operatoren, die in Endlosschleifen geraten oder Cluster zum Absturz bringen. Es bietet:
Sinnvolle Rate Limits und Backoff-Strategien.
Jede Konfigurationseinheit („Resource Manager“) läuft als eigener, dynamisch erzeugter Controller, sodass fehlerhafte Einheiten andere nicht beeinflussen.
Least Privilege: Jeder Resource Manager nutzt eine eigene ServiceAccount.
Volle Kontrolle: Keine impliziten Watches oder „magischen“ Trigger – du bestimmst genau, was wann reconciled wird.
Praxisbeispiele
Was kannst du konkret mit Espejote machen? Hier einige Beispiele aus dem produktiven Einsatz bei VSHN:
Secret-Synchronisation: Automatisches Replizieren von Secrets (z.B. Image Pull Secrets oder Zertifikate) über mehrere Namespaces hinweg.
Autoscaler-Patching: Anpassung des OpenShift Cluster Autoscalers über Admission Webhooks.
Alerting-Regel-Management: Kuratieren und Patchen von OpenShift-Alerting-Regeln über verschiedene Cluster-Versionen hinweg.
Die Zukunft: WASM und mehr
Die Roadmap umfasst einen kro-ähnlichen API-Builder zur einfachen Erstellung eigener Ressourcen sowie Unterstützung für WebAssembly-Plugins. Damit können Entwickler eigene Logik in nahezu jeder Sprache schreiben und sicher im Espejote-Controller ausführen.
Dieses Beispiel ManagedResource patcht die RedHat OperatorHub-Konfiguration, um alle Standardquellen zu deaktivieren. Es zeigt den einfachsten Anwendungsfall: ein statisches Manifest bedingungslos patchen. Komplexere Anwendungsfälle findest du im Abschnitt „Erste Schritte“.
VSHN AppCat Update – Mehr Flexibilität für PostgreSQL und höhere Betriebssicherheit auf der Plattform
13. Apr. 2026
Anwendungen auf Kubernetes zu betreiben bedeutet nicht nur, sie zu deployen – sondern sie langfristig zuverlässig zu betreiben. Dazu gehört das Management von Datenbanken, der Umgang mit Authentifizierung und sicherzustellen, dass sich Services ohne riskante Änderungen weiterentwickeln können.
Mit dem neuesten Release von VSHN AppCat führen wir Verbesserungen ein, die sich auf mehr Flexibilität bei Datenbanken, bessere Integrationsmöglichkeiten und sicherere Betriebsprozesse auf der gesamten Plattform konzentrieren.
Wie immer passieren viele dieser Verbesserungen im Hintergrund – sie wirken sich aber direkt darauf aus, wie Teams ihre Services betreiben und nutzen.
Was ist VSHN AppCat?
VSHN AppCat ist der VSHN Application Catalog – eine kuratierte Sammlung produktionsreifer Anwendungen, die sich mit minimalem Aufwand auf Kubernetes deployen und betreiben lassen.
Anstatt komplexe Software-Stacks manuell zu installieren und zu betreiben, ermöglicht AppCat Teams, Services wie Datenbanken, Identity Provider oder Kollaborationsplattformen als vollständig gemanagte Anwendungen zu nutzen.
Das umfasst:
Automatisierten Betrieb und Lifecycle-Management
Integriertes Monitoring, Backup und Wartung
Konsistente Deployments über verschiedene Kubernetes-Umgebungen hinweg
So können sich Teams auf ihre Anwendungen konzentrieren, während VSHN den Betrieb der zugrunde liegenden Services übernimmt.
Eine der zentralen Verbesserungen in diesem Release betrifft PostgreSQL auf Basis von CloudNativePG.
Wir haben zusätzliche Konfigurationsmöglichkeiten für PostgreSQL Extensions eingeführt. Damit kannst du extensionspezifische Libraries aktivieren und konfigurieren, wenn diese benötigt werden. Das schafft mehr Flexibilität für Teams, die auf erweiterte PostgreSQL-Funktionalitäten angewiesen sind.
Zusätzlich wurde VACUUM als Teil der geplanten Wartung integriert. Regelmässige VACUUM-Operationen sind entscheidend, um Performance und Speichereffizienz von Datenbanken langfristig sicherzustellen.
Diese Verbesserungen geben dir mehr Kontrolle darüber, wie sich deine PostgreSQL-Instanzen verhalten – ohne die Vorteile eines gemanagten Services zu verlieren.
Verbesserte Integration mit Forgejo
Dieses Release verbessert auch die Integrationsmöglichkeiten für Entwicklerplattformen.
Wir haben die notwendigen Parameter zur Konfiguration von OAuth2-Clients in Forgejo verfügbar gemacht. Damit kannst du Forgejo-basierte Services einfacher mit bestehenden Authentifizierungs- und Identity-Systemen verbinden.
Das ist besonders hilfreich für Teams, die ihre Entwicklungsprozesse mit zentralen Identity-Management-Lösungen integrieren möchten.
Sicherer Betrieb für Nextcloud
Zuverlässiger Betrieb bedeutet auch, unsichere Konfigurationen zu verhindern.
Mit diesem Release haben wir eine Schutzmassnahme für Nextcloud eingeführt: Downgrades zwischen Major-Versionen sind jetzt explizit blockiert.
Da Nextcloud selbst keine Major-Downgrades unterstützt, könnten solche Versuche zu fehlerhaften Instanzen oder Dateninkonsistenzen führen. Durch diese Einschränkung stellt AppCat sicher, dass Upgrades sicher und vorhersehbar bleiben.
Für dich bedeutet das: bleib auf dem aktuellen Stand und folge den vorgesehenen Upgrade-Pfaden bei Versionswechseln.
Anwendungen auf Kubernetes zuverlässig zu betreiben ist ein kontinuierlicher Prozess.
Dieses AppCat-Release konzentriert sich darauf, mehr Flexibilität dort zu schaffen, wo sie gebraucht wird – und Sicherheit dort durchzusetzen, wo sie entscheidend ist. Von besser konfigurierbaren PostgreSQL Extensions bis hin zu sicheren Upgrade-Pfaden und verbesserten Integrationen helfen diese Änderungen dabei, Services stabil und zuverlässig zu betreiben.
VSHN AppCat entwickelt sich kontinuierlich weiter, um den Betrieb von produktiven Workloads auf Kubernetes einfacher, zuverlässiger und konsistenter zu machen.
VSHN AppCat Update – Verbesserte Zuverlässigkeit, Betrieb und Entwicklerplattformen
16. März 2026
Moderne Anwendungen auf Kubernetes zu betreiben ist leistungsfähig – bringt aber auch Komplexität mit sich. Datenbanken, Identity-Services, Kollaborationsplattformen und Entwickler-Tools benötigen sorgfältiges Lifecycle-Management, Upgrades, Monitoring und Sicherheitskonfigurationen. Genau hier kommt VSHN AppCat ins Spiel. Mit der neuesten AppCat-Version führen wir mehrere Verbesserungen ein, die die Zuverlässigkeit und operative Konsistenz der auf der Plattform betriebenen Anwendungen weiter stärken. Viele der Änderungen passieren im Hintergrund – sie verbessern jedoch direkt den täglichen Betrieb für Teams, die Produktions-Workloads auf Kubernetes betreiben.
Was ist VSHN AppCat?
VSHN AppCat ist der VSHN Application Catalog – eine kuratierte Sammlung produktionsreifer Anwendungen, die sich mit minimalem Aufwand auf Kubernetes deployen und betreiben lassen. Anstatt komplexe Software-Stacks manuell zu installieren und zu betreiben, können Teams mit AppCat weit verbreitete Services wie Datenbanken, Identity Provider, Kollaborationsplattformen oder Entwickler-Tools als vollständig gemanagte Anwendungen deployen. AppCat bietet:
Produktionsreife Kubernetes Deployments
Automatisierten Betrieb und Lifecycle-Management
Integrierte Monitoring-, Backup- und Wartungsprozesse
Konsistente Deployments über verschiedene Kubernetes-Umgebungen hinweg So können sich Plattformteams und Entwickler auf das Entwickeln und Betreiben ihrer Anwendungen konzentrieren, während VSHN die operative Komplexität im Hintergrund übernimmt.
Zuverlässiger Betrieb erfordert gutes Alerting – aber Alerts sollten handlungsrelevant sein und nicht überwältigend. In diesem Release haben wir das Endnutzer-Alerting verbessert, um unnötige Alert-Flut zu reduzieren und gleichzeitig wichtige Signale sichtbar zu halten. Zum Beispiel wurden Alerts für Speicherplatzprobleme bisher jede Minute ausgelöst. Technisch korrekt, aber oft unnötig laut im Alltag. Die neue Konfiguration erhöht das Intervall auf 15 Minuten. Dadurch wird Alert-Flapping reduziert, während Nutzer weiterhin ausreichend Zeit haben, auf potenzielle Probleme zu reagieren. Wenn du Alerting für deine AppCat-Instanzen noch nicht konfiguriert hast, empfehlen wir dringend, es zu aktivieren.
Verbesserte PostgreSQL-Zuverlässigkeit
Mehrere Verbesserungen in diesem Release zielen darauf ab, den Betrieb von PostgreSQL robuster zu machen. Ein Problem konnte auftreten, wenn mehrere Datenbanken gleichzeitig erstellt wurden. In seltenen Fällen führte dies zu Race Conditions bei der Benutzerverwaltung. Durch Anpassungen im Bootstrap-Prozess der Datenbank und die Verwendung einer geeigneteren Template-Datenbank wurde dieses Problem behoben. Solche Verbesserungen sind für Nutzer oft unsichtbar – sie sind jedoch entscheidend, um Plattformbetrieb zuverlässig und skalierbar zu machen.
CloudNativePG für Keycloak
Wir haben auch das PostgreSQL-Backend verbessert, das für den Keycloak Identity Service in AppCat verwendet wird. Neue Keycloak-Instanzen nutzen künftig CloudNativePG, einen speziell für cloud-native Umgebungen entwickelten PostgreSQL-Operator für Kubernetes. Bestehende Keycloak-Installationen bleiben unverändert und funktionieren weiterhin wie bisher. Das neue Backend wird automatisch verwendet, wenn neue Keycloak-Instanzen erstellt werden.
Dieses Release enthält auch Updates für Forgejo und Codey, sodass diese Services weiterhin auf unterstützten Upstream-Versionen laufen.
Was ist Codey?
Codey ist VSHNs europäische Code-Collaboration-Plattform, die auf dem Open-Source-Projekt Forgejo basiert. Anstatt eine eigene Git-Plattform zu betreiben, können Teams vollständig gemanagte Forgejo-Instanzen nutzen, die von VSHN betrieben werden – inklusive Monitoring, Backups und Lifecycle-Management. Codey bietet Funktionen wie:
Git Repository Hosting
Pull Requests und Code Reviews
CI/CD kompatibel mit GitHub Actions Workflows
Package- und Container-Registries
Integrierte Projektmanagement-Tools Codey läuft auf europäischer Cloud-Infrastruktur, unter anderem in der Schweiz, wodurch Organisationen Kontrolle über ihre Entwicklungsdaten behalten und gleichzeitig von einem vollständig gemanagten Service profitieren.
Dieses Release enthält außerdem Verbesserungen an der Sicherheitskonfiguration des Nextcloud Cronjobs. Zuvor konnte der Job in einigen Kubernetes-Umgebungen mit falschen Benutzerrechten ausgeführt werden. Die neue Konfiguration stellt sicher, dass der Job mit dem korrekten Security Context läuft und verbessert damit die Kompatibilität mit Kubernetes-Plattformen wie Vanilla Kubernetes und OpenShift.
Für Services mit PostgreSQL-Abhängigkeiten – etwa Keycloak und Nextcloud – haben wir Edge Cases behoben, bei denen Wartungsfenster leicht von der konfigurierten Zeit abweichen konnten. Wartungsoperationen werden nun konsistenter über abhängige Services hinweg durchgeführt.
Kontinuierliche Plattformverbesserungen
Anwendungen zuverlässig auf Kubernetes zu betreiben erfordert kontinuierliche Verbesserungen bei Automatisierung, Observability und operativen Prozessen. Dieses AppCat-Release konzentriert sich genau darauf: mehr Zuverlässigkeit, Konsistenz und bessere Betriebserfahrung auf der Plattform. Viele Verbesserungen passieren im Hintergrund – sie helfen Teams jedoch dabei, kritische Services sicherer und mit weniger Betriebsaufwand zu betreiben. Wenn du nach einer einfacheren Möglichkeit suchst, produktionsreife Services auf Kubernetes zu betreiben, bietet VSHN AppCat eine bewährte Grundlage.
Cloud Native Computing Switzerland Meetup – März 2026 Recap
10. März 2026
Am 10. März traf sich die Cloud Native Computing Switzerland Meetup Community erneut im VSHN Tower in Zürich zu einem Nachmittag voller technischer Talks, Diskussionen und Austausch innerhalb der Cloud-Native-Community.
Mit inzwischen 3.000 Mitgliedern gehört die Gruppe zu den aktivsten Cloud-Native-Communities in der Schweiz und bringt regelmässig Platform Engineers, DevOps Engineers, Architektinnen und Architekten sowie Open-Source-Enthusiasten zusammen.
Die März-Ausgabe bot vier Talks rund um Themen wie Kubernetes Security, Plattform-Engineering und MLOps.
Begrüssung und Community Updates
Aarno Aukia und Patrick Mathers – VSHN
Das Meetup begann mit einer kurzen Begrüssung und Community-Updates durch die Organisatoren. Die CNC Switzerland Meetups folgen dabei einigen klaren Prinzipien:
Alle Vorträge sind technisch und Open-Source-orientiert
Keine Produkt- oder Sales-Pitches
Die Talks finden auf Englisch statt
Speaker aus unterrepräsentierten Gruppen sind ausdrücklich willkommen
Diese Grundsätze sorgen dafür, dass das Meetup eine echte technische Community-Veranstaltung bleibt und keine Marketingplattform wird.
Der erste Vortrag widmete sich einer praktischen Herausforderung im Betrieb von Kubernetes-Clustern: TLS-Zertifikatsrotation.
Janne Kataja von SIX erklärte, wie Anwendungen TLS-Zertifikate im laufenden Betrieb neu laden können, ohne dass Pods neu gestartet werden müssen.
In Kubernetes werden Zertifikate häufig in Secrets gespeichert und in Pods gemountet. Wenn ein Zertifikat beispielsweise durch cert-manager erneuert wird, aktualisiert Kubernetes automatisch das gemountete Secret. Anwendungen mit Hot-Reload-Mechanismen können diese Änderungen erkennen und die Zertifikate dynamisch neu laden.
Der Ansatz ermöglicht:
nahtlose Zertifikatsrotation
höhere Verfügbarkeit
den Einsatz kurzlebiger Zertifikate für bessere Sicherheit
Der Vortrag zeigte eindrücklich, wie bereits kleine architektonische Entscheidungen die Stabilität und Betriebssicherheit von Plattformen deutlich verbessern können.
Application-Centric Platforms mit OAM und KubeVela
Der zweite Talk beschäftigte sich mit einem Thema, das in vielen Organisationen aktuell stark an Bedeutung gewinnt: Platform Engineering und Internal Developer Platforms.
Raffael Klingler von AXA stellte das Open Application Model (OAM) vor und zeigte, wie dieser Ansatz den Fokus von Kubernetes-Infrastruktur auf applikationszentrierte Definitionen verschiebt.
Statt komplexe Kubernetes-Manifeste zu schreiben, definieren Entwickler ihre Anwendungen über modulare, wiederverwendbare Bausteine. KubeVela übersetzt diese abstrakten Definitionen anschliessend in konkrete Infrastruktur- und Kubernetes-Ressourcen.
Der Ansatz ermöglicht unter anderem:
standardisierte Deployment-Patterns
weniger Kubernetes-Komplexität für Entwickler
Integration von Cloud-Services und GitOps-Workflows
Gerade im Kontext von Internal Developer Platforms zeigt OAM, wie Kubernetes für Entwicklungsteams zugänglicher und produktiver werden kann.
DevOps für AI: Machine Learning mit Kubeflow in Produktion bringen
Fabrizio Lazzaretti (Wavestone) & Marco Crisafulli (enki)
Künstliche Intelligenz ist aktuell eines der dominierenden Themen in der IT. Dennoch scheitern viele AI-Initiativen daran, Modelle zuverlässig in Produktion zu betreiben.
Fabrizio Lazzaretti und Marco Crisafulli zeigten in ihrem Vortrag, wie MLOps-Praktiken und Kubeflow helfen können, die Lücke zwischen Data Science und produktiven Systemen zu schliessen.
Anhand eines durchgängigen Praxisbeispiels zeigten die Speaker, wie Organisationen von experimentellen AI-Projekten zu skalierbaren, produktionsreifen ML-Plattformen gelangen können.
Eine zentrale Erkenntnis des Talks: AI-Systeme brauchen starke DevOps-Grundlagen – oft sogar noch mehr als klassische Software.
Der letzte Vortrag beschäftigte sich mit einem wichtigen Wandel im Kubernetes-Netzwerk-Ökosystem.
Urs Zurbuchen von Airlock erklärte, warum das traditionelle Ingress-Modell, das lange Zeit stark vom NGINX Ingress Controller geprägt war, zunehmend an seine Grenzen stösst.
Viele Kubernetes-Nutzer kennen Herausforderungen wie:
komplexe Konfigurationen
eine starke Abhängigkeit von Annotationen
Sicherheitsprobleme bei älteren Implementierungen
Die Gateway API entwickelt sich derzeit zu einem neuen Standard, der diese Einschränkungen adressieren soll.
Der Vortrag zeigte:
die architektonischen Vorteile der Gateway API
warum sie als zukünftiger Standard gilt
mögliche Migrationspfade für bestehende Cluster
Für viele Teilnehmende bot der Vortrag einen hilfreichen Überblick darüber, wohin sich Kubernetes Networking in Zukunft entwickelt.
Networking und Apéro
Nach den Vorträgen blieb Zeit für Diskussionen, Austausch und das traditionelle Meetup-Apéro.
Solche Veranstaltungen zeigen immer wieder, wie stark die Schweizer Cloud-Native-Community ist: Engineers aus unterschiedlichsten Unternehmen teilen ihre Erfahrungen, diskutieren neue Technologien und lernen voneinander.
Talks ansehen
Die Aufzeichnungen der Vorträge werden auf dem VSHN TV YouTube Channel veröffentlicht.
Abonniere den Channel, um benachrichtigt zu werden, sobald die Videos online sind.
Teil der Community werden
Das Cloud Native Computing Switzerland Meetup richtet sich an Entwicklerinnen und Entwickler, Architektinnen und Architekten sowie Engineers, die sich für Cloud-Native-Technologien und Open Source interessieren.
Wenn du selbst ein Projekt vorstellen oder einen Talk halten möchtest, kannst du deinen Vorschlag hier einreichen.
Wir freuen uns darauf, dich beim nächsten Meetup zu sehen.
Markus Speth
Marketing, Communications, People
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
DevOps für AI: LLMs in Produktion mit Kubernetes und Kubeflow betreiben
9. März 2026
Large Language Models (LLMs) werden zunehmend Teil moderner Softwaresysteme. Von Chatbots und Copilots über Retrieval-Systeme bis hin zu AI-Agenten – immer mehr Organisationen integrieren generative AI in echte Produktionsumgebungen. Während es heute einfacher denn je geworden ist, AI-Prototypen zu bauen, bleibt der zuverlässige Betrieb von LLMs in Produktion eine grosse Herausforderung.
Auf den Kubernetes Community Days New York teilte Aarno Aukia praktische Einblicke, was es braucht, um LLMs mit bewährten DevOps-Praktiken zu betreiben. Sein Vortrag machte eine wichtige Realität deutlich: AI-Systeme benötigen weiterhin starke DevOps-Fundamente – möglicherweise sogar mehr als klassische Softwaresysteme.
Aarno Aukia’s Talk am KCD New York
DevOps trifft auf AI
DevOps war schon immer darauf ausgerichtet, die Lücke zwischen Entwicklung und Betrieb zu schliessen. Entwickler konzentrieren sich auf die Anwendungslogik und Daten, während Operations-Teams dafür sorgen, dass Software zuverlässig in Produktion läuft. In den letzten zehn Jahren haben sich DevOps-Praktiken rund um Automatisierung, Observability und Continuous Delivery stark weiterentwickelt.
In vielen Organisationen folgt Software heute einer etablierten Pipeline: Entwickler committen Code in Git, automatisierte CI/CD-Pipelines bauen und paketieren die Anwendung, und Kubernetes deployt und betreibt sie in Produktion. Monitoring- und Logging-Systeme schaffen Transparenz darüber, wie sich die Anwendung verhält, sodass Entwickler sie kontinuierlich verbessern können.
Diese Feedback-Schleife ist zum Rückgrat moderner Cloud-Native-Entwicklung geworden.
Wenn jedoch AI ins Spiel kommt, verändert sich dieses Modell in mehreren wichtigen Punkten.
AI-Systeme verhalten sich anders
Einer der grössten Unterschiede zwischen klassischen Anwendungen und AI-basierten Systemen ist die Deterministik. Traditionelle Software verhält sich vorhersehbar: Bei gleichem Input entsteht immer derselbe Output. LLMs funktionieren dagegen völlig anders.
Large Language Models sind probabilistische Systeme. Sie erzeugen Antworten, indem sie das nächste Token basierend auf dem Kontext vorhersagen und damit statistische Entscheidungen darüber treffen, was als Nächstes folgt. Das bedeutet, dass selbst kleine Änderungen im Prompt oder in der Eingabe zu sehr unterschiedlichen Ergebnissen führen können.
Eine scheinbar harmlose Anpassung eines System-Prompts kann das Verhalten eines Modells komplett verändern. In einem Beispiel führte bereits das Hinzufügen eines saisonalen Themas zu einem Chatbot-Prompt dazu, dass das Modell grundlegende Fragen nicht mehr korrekt beantworten konnte.
Für Operations-Teams entsteht dadurch eine neue Kategorie von Komplexität. Anstatt deterministische Systeme zu debuggen, müssen sie nun Systeme betreiben, deren Ergebnisse sich je nach Kontext subtil verändern können.
Testing wird dadurch deutlich komplexer.
Die Herausforderung beim Testen von AI
Klassisches Software-Testing ist vergleichsweise einfach. Ein Test liefert einen Input und überprüft, ob der Output exakt dem erwarteten Wert entspricht.
AI-Systeme passen nicht in dieses Modell. Wenn ein LLM eine Antwort generiert, kann diese korrekt sein, auch wenn sie sich in der Formulierung vom erwarteten Ergebnis unterscheidet. Gleichzeitig kann sie subtile sachliche Fehler oder Halluzinationen enthalten.
Zu bestimmen, ob eine Antwort akzeptabel ist, erfordert daher oft eine semantische Bewertung statt eines strikten Vergleichs. In manchen Fällen verwenden Organisationen sogar ein weiteres LLM, um die Ausgabe des ersten Modells zu bewerten. Dadurch entsteht ein völlig neues Testing-Paradigma, das viele Teams erst noch lernen zu beherrschen.
Mehr Artefakte zu verwalten
AI-Systeme bringen ausserdem zusätzliche Artefakte mit sich, die verwaltet und versioniert werden müssen.
In klassischen DevOps-Pipelines bestehen die wichtigsten Artefakte aus Source Code und Container Images. Bei AI-Workloads kommen jedoch weitere Komponenten hinzu: Datensätze, Trainingsartefakte, Prompts und Modelldateien. Diese Modelle sind oft sehr gross – teilweise mehrere Dutzend Gigabyte – und müssen sorgfältig gespeichert und versioniert werden.
Ohne saubere Versionierung wird es extrem schwierig, Probleme zu debuggen oder Ergebnisse später zu reproduzieren. Wenn sich ein Modell unerwartet verhält, müssen Teams genau wissen, welche Modellversion, welcher Datensatz und welche Konfiguration beim Deployment verwendet wurden.
Das erhöht die operative Komplexität von AI-Systemen erheblich.
Observability wird kritisch
Da LLMs nicht deterministisch sind, wird Observability noch wichtiger als in klassischen Systemen.
Logging muss deutlich mehr Kontext erfassen als bisher. Statt nur Anwendungsereignisse zu protokollieren, müssen Teams möglicherweise den vollständigen Prompt, die Modellantwort, die Modellversion und weitere Konfigurationsparameter speichern. Nur so können Betreiber später nachvollziehen, was genau passiert ist.
Ohne detaillierte Observability kann das Debugging von AI-Systemen schnell unmöglich werden.
Offene Modelle vs. gehostete APIs
Eine weitere wichtige operative Entscheidung ist die Wahl zwischen geschlossenen und offenen Modellen.
Gehostete AI-APIs bieten Komfort und leistungsstarke Funktionen, bringen aber auch Einschränkungen mit sich. In vielen Fällen haben Organisationen keine Kontrolle darüber, wann Modellupdates stattfinden oder welche Minor-Version gerade aktiv ist. Das kann Debugging und Reproduzierbarkeit erschweren.
Open-Weight- oder Open-Source-Modelle bieten dagegen mehr Kontrolle im Betrieb. Sie können heruntergeladen, versioniert, lokal getestet und auf eigener Infrastruktur betrieben werden. Organisationen können so selbst entscheiden, wann und wie Updates ausgerollt werden.
Gerade für regulierte Branchen wie Finanzwesen, Gesundheitswesen oder öffentliche Verwaltung ist dieses Mass an Kontrolle entscheidend.
Kubernetes als Fundament
Hier kommt Kubernetes als zentraler Bestandteil der AI-Infrastruktur ins Spiel.
Kubernetes löst bereits viele operative Herausforderungen beim Betrieb verteilter Systeme. Es bietet Mechanismen für Container-Orchestrierung, Ressourcenmanagement, Autoscaling und Fehlertoleranz. Für AI-Workloads besonders wichtig ist die Fähigkeit, auch GPU-Ressourcen zu verwalten.
Kubeflow erweitert Kubernetes um spezialisierte Komponenten für Machine-Learning-Workflows. Es hilft dabei, den gesamten Lebenszyklus von AI-Modellen zu verwalten – vom Training bis zum Betrieb der Inferenz.
Mit Kubeflow Pipelines können Teams Workflows für die Modellentwicklung und das Training automatisieren. Diese Pipelines orchestrieren komplexe Prozesse wie Datenvorverarbeitung, Trainingsläufe, Evaluationen und das Verpacken von Modellen für Deployments.
Für viele Organisationen, die LLMs einsetzen, liegt der Fokus jedoch nicht auf dem Training eigener Modelle, sondern darauf, bestehende Modelle zuverlässig in Produktion zu betreiben.
Hier kommt KServe ins Spiel.
LLMs mit KServe betreiben
KServe ist ein Kubernetes-natives Framework für Model Serving, das das Deployment und den Betrieb von AI-Modellen vereinfacht. Es ermöglicht Teams, Inferenzservices auf Kubernetes über standardisierte APIs bereitzustellen.
Ein typisches Deployment besteht aus einem Container, der einen Model Server betreibt, häufig basierend auf Runtimes wie vLLM. Der Container lädt das Modell, nutzt GPU-Ressourcen für die Inferenz und stellt einen API-Endpunkt für Anwendungen bereit.
KServe integriert sich mit Kubernetes-Autoscaling-Mechanismen und Observability-Tools, sodass AI-Workloads dynamisch skaliert und ihr Verhalten in Produktion überwacht werden kann.
Da alles als Kubernetes-Ressource läuft, können Teams dieselben DevOps-Praktiken nutzen, die sie bereits für andere Anwendungen einsetzen.
Ein schnell wachsendes Ökosystem
Das Ökosystem rund um AI-Infrastruktur entwickelt sich derzeit extrem schnell. Neue Projekte entstehen laufend, um die besonderen Herausforderungen beim Betrieb von LLMs im grossen Massstab zu adressieren.
Ein Beispiel ist LLMD, ein Kubernetes-Operator speziell für LLM-Inferenz. Er baut auf bestehenden Technologien wie vLLM auf, ergänzt diese jedoch um zusätzliche Funktionen wie Request-Routing, Modellselektion, Caching und intelligentes Scaling.
Solche Tools zeigen, wie sich das Cloud-Native-Ökosystem an die operativen Anforderungen von AI-Workloads anpasst.
AI braucht weiterhin DevOps
Trotz des grossen Hypes rund um generative AI bleibt eine zentrale Erkenntnis bestehen: AI-Systeme brauchen weiterhin starke operative Grundlagen.
LLMs in Produktion zu betreiben bedeutet weit mehr, als einfach eine API aufzurufen. Es erfordert sorgfältiges Management von Modellen, Infrastruktur, Observability und Deployment-Prozessen.
Kubernetes und Kubeflow bieten eine leistungsfähige Plattform, um diese Herausforderungen zu bewältigen. Durch die Anwendung bewährter DevOps-Prinzipien auf AI-Systeme können Organisationen Plattformen aufbauen, die nicht nur intelligent, sondern auch zuverlässig und skalierbar sind.
Während AI zunehmend zum Standardbestandteil moderner Anwendungen wird, wird die Fähigkeit, diese Systeme effizient zu betreiben, genauso wichtig wie die Modelle selbst.
Genau hier kommen Plattformansätze ins Spiel. Anstatt dass jedes Team komplexe Stacks selbst aufbauen und betreiben muss, können Plattformen fertige Services auf Kubernetes bereitstellen. Ein Beispiel dafür ist Servala – Sovereign App Store, ein Kubernetes-nativer Marktplatz, der Organisationen mit einem Katalog von Managed Cloud-Native-Services verbindet, darunter Datenbanken, Storage, Developer Tools und AI-fähige Infrastrukturkomponenten.
Markus Speth
Marketing, Communications, People
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
How we used Crossplane for the things we should not have
30. Sep. 2025
At Swiss Cloud Native Day 2025 in Bern, our colleague Liene Luksika shared an honest and entertaining story about VSHN’s journey with Crossplane. What started as a simple use case evolved into a complex architecture, full of learnings, mishaps, and valuable lessons for anyone building managed services on Kubernetes.
From healthcare to cloud native
Liene comes from the healthcare sector, so when she joined the cloud native world at VSHN, she had to quickly get used to Kubernetes lingo – namespaces, instances, and of course, the obsession with laptop stickers. Luckily, VSHN has been around for more than 10 years, providing 24/7 managed services and building cloud native platforms for customers in Switzerland, Germany, and beyond.
Why Crossplane?
As customers increasingly asked VSHN to run their software as a service – databases, Nextcloud, and other critical apps – we needed a solid way to provision and manage infrastructure across private and public clouds. Crossplane seemed like the perfect fit:
It lets engineers define desired state vs. observed state
It automatically reconciles the two – like making coffee appear if that is your desired state
It provides flexible building blocks to expose clean APIs for managed services on Kubernetes
VSHN has used Crossplane in production since early 2021 (around v0.14) and runs the Crossplane Competence Center in Switzerland.
The evolution: from simple to complex
Our first use case was straightforward: a customer wanted two types of databases (Redis and MariaDB), T-shirt sized, no extras. Crossplane handled this beautifully.
Then reality hit. Customers wanted backups and restores, logs and metrics, alerting, maintenance and upgrades, scaling and user management, special features like Collabora for Nextcloud, and the freedom to choose infrastructure. To serve this, we adopted a split architecture:
A control cluster for all Crossplane logic
Separate service clusters for customer workloads
This runs today with customers like health organizations in Gesundheitsamt Frankfurt and HIN in Switzerland, on providers such as Exoscale and Cloudscale, keeping data sovereign and operations reliable.
When things go wrong
Building complex platforms means learning in production:
Deletion protection surprise: a minor Crossplane change removed labels before deletion, wiping our safeguard. Backups saved the day
Race conditions: a split approach to connection details occasionally made apps unreachable until we cleaned up code
The big one: during a planned „no-downtime“ maintenance for a fleet with 1’300+ databases, objects hit an invalid state and Kubernetes garbage collection deleted 230 database objects. Some restores were fresh, some older. We pulled in 20 people overnight, communicated openly, and recovered together with the customer
Key lessons: test at realistic scale and keep recent, tested backups. Also, practice the restore path, not just the backup.
Crossplane 2.0 – where next?
Crossplane 2.0 introduces major breaking changes. Staying put is not an option, but migrating means real effort, especially for our split control plane architecture. We are evaluating whether Crossplane 2.0 fits our needs or if alternatives are a better match. As always, we will document our decisions openly in VSHN’s Architecture Decision Records.
Final thoughts
Cloud native success is not just about tools. It is about learning fast, designing for failure, and communicating clearly with customers. Crossplane has enabled a lot of innovation for us, and it has also tested us. Whether we proceed with Crossplane 2.0 or chart a different course, we will keep building sovereign, reliable, open managed services for our customers.
👉 Watch the whole video on YouTube:
Markus Speth
Marketing, Communications, People
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
Jetzt verfügbar: DevOps in der Schweiz Report 2025 🚀
25. Juni 2025
Wir freuen uns riesig, die sechste Ausgabe unseres „DevOps in der Schweiz“ Reports zu veröffentlichen – und diesmal mit einem ganz besonderen Fokus: Platform Engineering und künstliche Intelligenz (AI)! 🤖
Von Januar bis April 2025 haben wir eine Studie mit Fachleuten aus der Schweizer Tech-Community durchgeführt. Das Ergebnis: ein aufschlussreicher Einblick, wie DevOps-Teams in der Schweiz heute arbeiten – welche Tools sie einsetzen, wie ihre Teams aufgebaut sind, welche Herausforderungen sie beschäftigen und wo AI bereits konkret eingesetzt wird.
💡 Sneak Peek gefällig?
💡 Schweizer Unternehmen fragen nicht mehr ob sie DevOps einführen sollen – sondern wie sie es skalieren können.
📈 Platform Engineering und KI verändern, wie Teams Software schneller, sicherer und intelligenter ausliefern.
💡 Jede dritte Schweizer DevOps-Organisation nutzt bereits KI in der Produktion – etwa für Code-Reviews, CI/CD-Optimierung und Architekturunterstützung.
Ein weiteres Drittel steht kurz davor, nachzuziehen.
💡 54 % der Schweizer Unternehmen haben inzwischen dedizierte Platform-Engineering-Teams.
Internal Developer Platforms (IDPs) werden zur Geheimwaffe, um Autonomie zu ermöglichen und Komplexität zu reduzieren.
💡 Devs sagen Ja zu KI!
79 % der Schweizer Entwickler:innen fühlen sich wohl dabei, KI in ihren Workflows einzusetzen – aber nur 20 % halten sie für vollständig bereit.
Der Report zeigt: KI ist vielversprechend, braucht aber bessere Messbarkeit und mehr Vertrauen, um skalieren zu können.
All das (und noch viel mehr!) findest du kompakt zusammengefasst im PDF-Report (nur auf Englisch). Wie schon im Vorjahr enthält der Report eine Executive Summary zu Beginn – perfekt für alle mit wenig Zeit.
📥 Jetzt herunterladen
Viel Spass beim Lesen – wir freuen uns sehr auf dein Feedback! 🙌
Redis 8 jetzt im VSHN Application Catalog verfügbar und Redis ist wieder Open Source!
11. Juni 2025
Redis 8 ist ab sofort im VSHN Application Catalog verfügbar und Redis ist als Open Source zurück! Wir freuen uns riesig, dir mitzuteilen: Redis 8 ist ab sofort im VSHN Application Catalog verfügbar – und dieses Release ist etwas ganz Besonderes: Redis ist offiziell wieder Open Source!
Aber das ist noch nicht alles: Redis ist jetzt auch auf Servala verfügbar – dem offenen, cloud-nativen Service Hub von VSHN, der Entwickler:innen, Softwareanbieter und Cloud Provider über verschiedene Infrastrukturen hinweg verbindet.
Warum das so wichtig ist
Redis gehört seit Jahren zu den beliebtesten In-Memory-Datenbanken für Entwickler:innen und DevOps-Teams. Doch Lizenzänderungen in den letzten Versionen haben für viele Cloud-native Nutzer:innen und offene Ökosysteme Probleme verursacht. Mit Version 8 ändert sich das endlich: Redis kehrt zu seinen Open-Source-Wurzeln zurück und steht jetzt unter der GNU AGPLv3-Lizenz.
„Redis 8 bringt Redis zurück zu seinen Open-Source-Wurzeln. Die zukünftige Entwicklung von Redis wird unter der AGPLv3-Lizenz stattfinden.“ – Redis-Team, offizielle Ankündigung
Das bedeutet: mehr Transparenz, bessere Zusammenarbeit und langfristige Nachhaltigkeit für alle, die Redis als festen Bestandteil ihres Tech-Stacks einsetzen.
Redis 8 mit VSHN und Servala: Vollständig gemanagt & hochverfügbar
Mit Redis 8 im VSHN Application Catalog und auf Servala bekommst du mehr als nur die neueste Open-Source-Version:
Produktionsreife Deployments auf Kubernetes und OpenShift
Garantierte Verfügbarkeit, Monitoring und automatisches Failover
Lifecycle-Management inkl. Updates und Sicherheitspatches
Flexibilität beim Cloud-Anbieter – in deiner Infrastruktur oder über unsere Partner
Self-Service-Provisionierung über Servala mit integrierter Automatisierung
Egal ob du Redis intern nutzt oder als Service für Teams und Kund:innen bereitstellst – wir kümmern uns darum.
Unterstützte Versionen
Wir unterstützen weiterhin die meistgenutzten Redis-Versionen – ab sofort gehört auch Redis 8 offiziell zu unserem gepflegten Portfolio. 👉 Schau dir die vollständige Liste auf unserer VSHN Redis Produktseite oder der Servala Redis Seite an.
Warum Redis 8 über VSHN oder Servala nutzen?
✅ Wieder vollständig Open Source und Community-getrieben ✅ Kubernetes-native, GitOps-fähige Deployments ✅ Hochverfügbar mit Failover- und Backup-Strategien ✅ Integriert in deine Infrastruktur oder als Managed Service ✅ Unterstützt von VSHN – den DevOps-Experten hinter Servala
Redis 8 ist ein Meilenstein für die Open-Source-Welt – und wir bringen es in deine produktive Umgebung!
Die technischen Herausforderungen hinter Servala: Standardisierung der Applikationsbereitstellung
14. Apr. 2025
In diesem Nachfolgeartikel zu unserer Einführung in Servala werfen wir einen Blick auf die technischen Herausforderungen, Managed Services für Cloud Provider überall verfügbar zu machen. Erfahre, wie die wiederholte und inkonsistente Natur von Applikationspaketierung, -bereitstellung und -betrieb unsere Vision für Standardisierung inspiriert hat.
Wir gehen auf die Probleme ein, mit denen Platform Engineers heute konfrontiert sind – darunter inkonsistentes Verhalten von Containern, unvorhersehbare Helm Charts und das Chaos des Day-2-Betriebs im Hinblick auf Sicherheit, Konfiguration und Abhängigkeiten.
Lerne, wie Servalas vorgeschlagene Open Standards die Landschaft für folgende Gruppen verändern können:
Softwareanbieter – Schnellere Markteinführung und grössere Reichweite ohne operativen Aufwand
Cloud Provider – Erweiterung der Servicekataloge mit Enterprise-fähigen Managed Services
Endnutzer – Selbstbedienung mit konsistenten, sicheren und konformen Applikationen
Begleite uns auf dieser Reise, um Applikationsbereitstellung zu vereinfachen und Managed Services für alle zugänglich zu machen.
In unserer Einführung in Servala haben wir die technischen Herausforderungen erwähnt, Softwareanbieter dazu zu befähigen, sich selbst auf unserer Plattform zu integrieren. Während wir Servala 2025 weiter aufbauen, widmen wir uns der grundlegendsten Herausforderung: Einen standardisierten Ansatz für Applikationsbereitstellung zu schaffen. Lass uns diese Herausforderungen und unsere vorgeschlagene Lösung im Detail anschauen.
Die wiederholende Natur des Applikationsmanagements
In den letzten Jahren haben wir bei VSHN unzählige Applikationen im Rahmen unseres Managed Services-Angebots betreut – dem Fundament von Servala. Für jede einzelne Applikation mussten wir immer wieder dieselben mühsamen Aufgaben erledigen:
Packaging: Die Applikation in ein deploybares Format bringen, typischerweise durch Erstellen eines OCI-konformen Container-Images, das mit Docker, Podman, Kubernetes und OpenShift kompatibel ist. Der Packaging-Prozess wird automatisiert, sodass er bei jeder neuen Version ausgelöst wird.
Deployment: Die verpackte Applikation automatisiert auf das Zielsystem ausrollen – nicht manuell. Die meisten Deployments umfassen mehrere Umgebungen wie Test, Staging, Pre-Prod und Produktion oder ermöglichen Self-Service-Bereitstellung für SaaS. Oft ist dies mit dem Erstellen von Helm Charts und dem Aufsetzen von Automatisierungspipelines oder APIs verbunden, z.B. über Kubernetes-Operatoren (wie Crossplane).
Day-2-Betrieb: Nach dem Deployment kommen Aufgaben wie das Sammeln von Metriken, Einrichten von Alerts, Updaten der Applikation, Skalierung bei Performanceproblemen, Backup und Restore von Daten, Log-Analyse, 24/7-Support und die Einhaltung von Compliance-Vorgaben dazu – sowie viele weitere Betriebsaufgaben.
Die aktuelle Herausforderung für Servala
Diese Schritte immer und immer wieder durchzuführen, wird ermüdend. Die gleichen Probleme zu lösen, sobald wir uns um eine neue Applikation kümmern, fühlt sich nicht wirklich wertstiftend an. In der Realität müssen wir mit einer Vielzahl unterschiedlicher Herangehensweisen umgehen. Es ist eine grosse Belastung für Engineers, all diese Varianten zu unterstützen. Einzelne Teile der oben erwähnten Funktionen sind meist schon erledigt – zum Beispiel gibt es bereits Container-Images, aber jedes davon verhält sich anders. Das bedeutet, dass wir müssen jedes Mal herausfinden müssen, wie es in den nächsten Schritt integriert werden kann. Dasselbe gilt für die verschiedenen Helm Charts da draussen. Standardisierung würde uns diese Last abnehmen, den Prozess effizienter und weniger repetitiv machen.
Das Kernproblem liegt in der Flexibilität der verwendeten Tools. Container-Images unterscheiden sich massiv in ihrer Bauweise und ihrem Verhalten. Helm Charts akzeptieren Parameter in inkonsistenten Formaten. Zum Beispiel kann ein Container-Image in einem Chart als img, image oder image-registry bezeichnet sein – je nachdem, wer es geschrieben hat.
Security Scans und Compliance Reports sind von Applikation zu Applikation unterschiedlich. Manche bringen SBOMs (Software Bill of Materials) mit, bei anderen müssen diese manuell erstellt werden. Die Konfigurationshandhabung ist genauso inkonsistent: Manche Applikationen setzen auf Umgebungsvariablen, andere erwarten Konfigurationsdateien an bestimmten Orten, wieder andere benötigen eigene Konfigurations-APIs.
Auch der Day-2-Betrieb unterscheidet sich stark. Manche Applikationen exportieren Metriken im Prometheus-Format, andere gar nicht. Identische Metriken haben unterschiedliche Namen, und Logging-Formate reichen von strukturiertem JSON bis zu einfachem Plaintext. Abhängigkeitsmanagement wird oft vernachlässigt – es gibt kaum Infos zu benötigten Services oder Komponenten. Das Betreiben dieser Applikationen wird zum nervenaufreibenden „Whack-a-Mole“-Spiel.
Wir müssen diese grundlegenden Inkonsistenzen lösen, damit Servala skalieren kann und Softwareanbieter ihre Applikationen einfacher onboarden können.
Unsere vorgeschlagene Lösung: Standardisierung
Wie lassen sich diese Hindernisse überwinden? Unser Vorschlag: eine Sammlung von Dokumenten definieren, die Muster für alle notwendigen Teile der Applikationsbereitstellung über Servala beschreiben. Du kannst diese Dokumente auch als Spezifikationen, Golden Paths, Patterns, Standards, Konventionen oder Defaults verstehen. Ziel ist es, einen gemeinsam abgestimmten Weg zu dokumentieren, um die genannten Aufgaben zu lösen – sodass wir sie nicht immer wieder neu durchdenken müssen.
Aber das nur für uns zu machen, fühlt sich nicht richtig an. Wir bei VSHN leben Open Source und Open Standards und wollen gemeinsam mit anderen einen definierten Weg finden. Daher schlagen wir vor, eine Gruppe von Menschen aus verschiedenen Unternehmen zusammenzubringen, um diese Muster gemeinsam zu dokumentieren und sich darauf zu einigen.
Unsere Vision: Eine transformierte Landschaft der Applikationsbereitstellung
Wie wird Applikationsbereitstellung aussehen, wenn die Servala-Spezifikationen weit verbreitet sind? Die Vorteile wären für alle Beteiligten transformativ:
Für Softwareanbieter:
Schnellere Markteinführung: Anstatt Monate in den Aufbau von Deployment-, Monitoring- und Wartungssystemen zu investieren, können Anbieter sich auf ihr Kernprodukt konzentrieren und auf Servalas standardisierte Delivery-Mechanismen setzen, um global Cloud Provider zu erreichen.
Weniger operativer Aufwand: Wer sich an die Servala-Spezifikation hält, übernimmt automatisch bewährte Praktiken wie Monitoring, Metriken, Logs, Backups etc. – ganz ohne eigenes Operations-Team.
Grössere Marktreichweite: Die Möglichkeit, auf jedem Servala-kompatiblen Cloud Provider zu deployen, eröffnet neue Märkte ohne zusätzlichen Engineering-Aufwand.
Bessere Sicherheitslage: Standardisierte Security-Scans, Compliance-Berichte und Konfigurationsmanagement senken Risiken drastisch – selbst ohne dediziertes internes Security-Know-how.
Für Cloud Provider:
Erweiterte Servicekataloge: Provider können sofort Dutzende Managed Services mit einheitlichen Betriebsstandards anbieten – ein enormer Mehrwert.
Operationale Konsistenz: Alle Services folgen denselben Mustern für Monitoring, Alerts und Wartung – das reduziert die Komplexität beim Betrieb verschiedenster Third-Party-Applikationen.
Wettbewerbsdifferenzierung: Kleinere Cloud Provider können mit Hyperscalern mithalten, indem sie vergleichbare Kataloge an Managed Services anbieten.
Für EndnutzerInnen:
Dank Servalas standardisierten Bereitstellungsmechanismen kannst du komplexe Managed Services mit Vertrauen deployen – in dem Wissen, dass sie konsistenten betrieblichen Mustern folgen. Dieses Empowerment gibt dir Kontrolle und Sicherheit im Betrieb.
Die operativen Schnittstellen bleiben unabhängig von der jeweiligen Applikation konsistent, was dir ein vorhersehbares und sicheres Nutzungserlebnis bietet. Diese Vorhersehbarkeit stärkt das Vertrauen in Stabilität und Zuverlässigkeit des Systems.
Enterprise-Readiness: Alle Services beinhalten automatisch Sicherheitsfunktionen, Backup/Restore, Monitoring und andere Enterprise-Features – ganz ohne individuellen Integrationsaufwand.
Vereinfachte Compliance: Standardisierte Security-Scans und Compliance-Reports machen regulatorische Audits einfacher und weniger ressourcenintensiv.
Klarheit bei Abhängigkeiten: Durch transparente Darstellung von Service-Abhängigkeiten und Kompatibilitätsanforderungen werden Deployment-Fehler und Konfigurationsprobleme reduziert.
Die Spezifikationsbereiche von Servala
Wir planen, Muster für folgende Bereiche zu dokumentieren:
Verhalten von Container-Images: Wo werden Daten gespeichert? Wie werden Ports freigegeben? Wie verhält sich der Entry Point? Mit welchen Berechtigungen läuft die Applikation?
Helm Chart „API“: Wie verhalten sich die Standardwerte? Wie sieht die Struktur der Konfiguration aus?
Einheitlicher Betriebsrahmen:
Backup und Restore: Standardisierte Schnittstellen für konsistente Backups von Applikationen und Daten, mit klar definierten Wiederherstellungspfaden und Verifikationsmethoden
Metriken: Klar definierte Endpunkte für Applikationsmetriken zur Alarmierung, Überwachung und Performance-Einblicke
Alerting und Monitoring: Gemeinsame Alarmdefinitionen, Schweregrade und Reaktionserwartungen über alle Applikationen hinweg
Logging-Standards: Einheitliche Logformate, Aufbewahrungsrichtlinien und Suchmöglichkeiten zur Vereinfachung der Fehleranalyse
SLA-Definitionen: Standardisierte Metriken zur Messung und Berichterstattung von Verfügbarkeit, Performance und Zuverlässigkeit
Wartungsfenster: Klare Protokolle zur Koordination und Kommunikation von Wartungen mit minimaler Unterbrechung
Abrechnung: Einheitliche Art der Abrechnung der Service-Nutzung
Security Scanning und Compliance: Standardisierte Ansätze für Schwachstellenmanagement, Sicherheitsrichtlinien und Compliance-Berichterstattung über alle Applikationen hinweg
Konfigurationsmanagement: Einheitliche Muster für Konfigurationshandling, Secret Management und Laufzeit-Rekonfiguration
Abhängigkeitsmanagement: Klare Deklaration und Handhabung von Service-Abhängigkeiten, inklusive Versionierungsanforderungen und Kompatibilitätsmatrizen
Self-Service API-Architektur: Standardisierte Strukturen für Kubernetes-Ressourcen vorschlagen, um vorhersehbare Schnittstellen für Applikationsmanagement in verschiedenen Umgebungen zu schaffen
Bisherige Arbeiten, auf denen wir aufbauen möchten
Es gibt bereits erfolgreiche Standardisierungsinitiativen, auf die wir aufbauen wollen:
OCI Image Format
Nach Jahren der Fragmentierung im Container-Bereich hat das Open Container Initiative (OCI) einen einheitlichen Image-Standard geschaffen, der von Tools wie Docker und Podman genutzt wird. Dieser Standard definiert Dateisystempfade (z. B. /var/lib/docker/), Image-Layering und Interoperabilität mit Registries wie Docker Hub, GHCR und Quay.
Kubernetes als Container-Orchestrator
Kubernetes hat sich als De-facto-Standard zur Verwaltung von Containerflotten etabliert. Es bietet eine einheitliche API zur Steuerung von Rechenleistung, Netzwerk und Storage – unabhängig vom Infrastrukturanbieter.
Pod- und Container-Lifecycle-Konventionen in Kubernetes
Die Community hat das Verhalten von Applikationen bei Lifecycle-Events wie Start, Shutdown und Health Checks standardisiert. Anwendungen reagieren nun vorhersehbar auf Restarts und Node Drainings, was den Alltag von Platform Engineers stark vereinfacht. Lifecycle Hooks sind zum Standard geworden.
Prometheus-Metriken
Viele Applikationen exportieren Metriken im Prometheus/OpenMetrics-Format über einen /metrics-Endpunkt. Es gibt etablierte Namenskonventionen (z. B. http_requests_total). Obwohl nicht alles einheitlich ist, ist dies einer der am weitesten akzeptierten inoffiziellen Standards – genutzt von Applikationen, Exportern, Sidecars und Service Monitors.
SBOM (Software Bill of Materials)
Dank offener SBOM-Standards und Unterstützung durch Tools wie GitHub, GitLab und Docker ist das Erstellen und Konsumieren von SBOMs heute Best Practice. Die EU Cyber Resilience Act (CRA) verpflichtet mittlerweile zur Nutzung von SBOMs – sowohl für proprietäre als auch für Open-Source-Software.
12-Factor App
Auch wenn es noch Unterschiede gibt, verdient das 12factor.net-Manifest eine lobende Erwähnung. Es legte 2011 den Grundstein für Cloud-Native Applikationen und beeinflusst Architektur und Plattformdesign bis heute: Konfiguration über Umgebungsvariablen, Statelessness, Logging auf stdout – vieles davon ist heute Best Practice und wird von Plattformen oft indirekt erzwungen.
Helm Chart Best Practices
Die Helm-Community hat auf die strukturelle Inkonsistenz von Charts reagiert und Best Practices, Guidelines sowie Tools wie helm lint und helm create bereitgestellt. Auch wenn diese nicht überall angewendet werden, setzen Projekte wie Bitnami, KubeApps und Backstage zunehmend auf diese Konventionen – ein solides Fundament für Servalas Standardisierungsbemühungen.
OpenAPI / Swagger
Die OpenAPI-Initiative hat die API-Standardisierung stark vorangetrieben. Sie erlaubt maschinenlesbare API-Definitionen, automatisierte SDK-Generierung, Tests, Mocks und lesbare Dokumentation. Sie ist breit akzeptiert – von Kubernetes CRDs bis hin zu GitHub APIs – und bringt Konsistenz und Interoperabilität in API-Design und -Nutzung.
OpenServiceBroker API
Wir haben diese API bereits implementiert und nutzen sie mit einigen Kunden. Sie bietet jedoch keinen deklarativen, Cloud-Nativen Ansatz für Service Listing und Provisionierung.
Crossplane
Wir sind Fans von Crossplanes deklarativem Ansatz für Service-Definitionen und -Instanziierung. Die „Composite Resource Definitions“ (XRDs) erlauben das Erstellen von benutzerdefinierten CRDs mit konsistenter Struktur. Servala ersetzt Crossplane nicht – wir nutzen es unter der Haube.
Open Application Model (OAM)
OAM unterstützt Servalas Mission, indem es einen plattformagnostischen, standardisierten Weg bietet, Cloud-Native Applikationen zu definieren. Es trennt sauber Kernlogik (Components), Betriebsfeatures (Traits) und Abhängigkeiten (Scopes). Mit wiederverwendbaren Definitionen für Metriken, Backups und Autoscaling hilft OAM, die Fragmentierung von Helm Charts und Container Images zu überwinden – eine interessante Grundlage für Servalas Spezifikation.
Platform Specification
Die Platform Spec-Initiative passt perfekt zu Servalas Vision: Sie definiert eine standardisierte YAML-basierte Schnittstelle zwischen Entwicklern und Platform Engineers für Deployment und Management – inklusive Container Images, Umgebungsvariablen, Secrets, Service Bindings und Regeln fürs Ausrollen. Damit lassen sich viele der Inkonsistenzen in Helm Charts und beim Laufzeitverhalten lösen. Durch die Übernahme oder Anlehnung an Platform Spec kann Servala Onboarding vereinfachen, Integrationsaufwand reduzieren und Plattformunabhängigkeit fördern.
Cloud Native Application Bundle (CNAB)
Die CNAB-Spezifikation unterstützt Servalas Ziele durch ein portables, standardisiertes Format für das Packaging und die Verteilung komplexer Applikationen – inklusive Kubernetes-Manifeste, Helm Charts, Terraform-Pläne und Skripte. CNAB definiert ein konsistentes Format für Code, Konfiguration und Lifecycle-Operationen (Install, Upgrade, Uninstall). Damit lässt sich ein einheitliches, wiederholbares Deployment ermöglichen – ideal für komplexe Managed Services über verschiedene Umgebungen hinweg.
Der Weg nach vorn
Servala will das Onboarding von Applikationen um den Faktor 10 beschleunigen – von Wochen auf Stunden oder Tage – und gleichzeitig die Zuverlässigkeit durch bewährte, konsistente Muster für Deployment und Betrieb dramatisch steigern. Wir haben begonnen, diese Standards in unsere Entwicklungs-Roadmap zu integrieren, doch für den Erfolg ist eine breite Zusammenarbeit in der Branche entscheidend.
Wir laden Softwareanbieter, Cloud Provider und Platform Engineers ein, gemeinsam mit uns an der offenen und kollaborativen Gestaltung dieser Standards zu arbeiten. Mit einem soliden Fundament kann Servala die Art und Weise, wie Managed Services bereitgestellt werden, neu definieren: Cloud Provider können ihre Kataloge erweitern und Softwareanbieter werden zu SaaS-Providern – ohne grossen operativen Aufwand.
Bleib auf dem Laufenden
Erfahre immer als Erste oder Erster die neuesten Nachrichten zu Servala. Gib einfach deine E-Mail-Adresse unten ein:
Was kommt als Nächstes?
Im Jahr 2025 werden wir uns darauf konzentrieren, Softwareanbietern die Möglichkeit zu geben, sich selbst in die Servala-Service-Plattform einzubinden. Mehr Informationen zu Warum wir Servala gestartet haben findest du auch in unserem Servala Launch Announcement.
Kontaktiere uns
Interessiert, mehr zu erfahren? Buche ein Meeting oderschreib uns und finde heraus, wie Servala dir helfen kann. Erlebe die Zukunft von Cloud Native Services auf servala.com. 🚀
Markus Speth
Marketing, Communications, People
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
Why VSHN Managed OpenShift Customers Are Safe from the Recent Ingress NGINX Vulnerability
26. März 2025
A recently disclosed set of vulnerabilities, known as IngressNightmare, has raised alarms for Kubernetes users relying on the Ingress NGINX Controller. These vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974), with a critical CVSS score of 9.8, could allow attackers to gain unauthorized access to a Kubernetes cluster, potentially leading to remote code execution and full cluster compromise. However, OpenShift 4.x customers are not affected by this exploit, as OpenShift uses the OpenShift Ingress Operator, based on HAProxy, as the default ingress controller.
The vulnerabilities affect the Ingress NGINX Controller, which is responsible for managing external traffic and routing it to internal services in a Kubernetes cluster. Specifically, they target the admission controller, which, if exposed without authentication, allows attackers to inject malicious configurations, resulting in remote code execution. Since OpenShift 4.x uses the OpenShift Ingress Operator (based on HAProxy) as the ingress controller, customers are not exposed to these risks.
OpenShift 4.x further enhances security by restricting permissions and not permitting the default ingress controller to access sensitive data, such as secrets stored across Kubernetes namespaces. This design decision helps protect OpenShift customers from potential exploits by preventing unauthorized access to critical cluster resources.
As a result, VSHN Managed OpenShift users can be confident that their clusters remain secure without having to worry about this specific vulnerability.
Markus Speth
Marketing, Communications, People
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
Announcing Redis by VSHN – Enhance Your Containerized Workloads
6. Nov. 2024
We are thrilled to announce the general availability of Redis by VSHN, now available in OpenShift through the VSHN Application Marketplace. This powerful, in-memory data structure store, known for its blazing-fast performance and versatility, is now optimized for containerized environments on OpenShift. Whether you’re building microservices, real-time analytics, or caching layers, Redis by VSHN offers the reliability and scalability your applications need.
Why Redis on OpenShift?
Redis has been a favorite among developers for its simplicity, performance, and robustness. By integrating Redis into OpenShift, we are enabling seamless deployment and management of Redis instances within your containerized infrastructure. This means you can now leverage Redis’s capabilities while enjoying the benefits of OpenShift’s orchestration and container management.
Key Features
Containerized Deployment: Effortlessly deploy and manage Redis instances in your OpenShift environment.
Scalability: Scale your Redis instances up or down based on your application needs.
High Availability: Ensure your data is always available with Redis’s built-in replication and persistence mechanisms.
Integrated Monitoring: Utilize OpenShift’s monitoring tools to keep an eye on your Redis performance and health.
Security: Benefit from OpenShift’s security features to protect your Redis instances and data.
Benefits for Your Containerized Applications
Performance: Redis’s in-memory data structure ensures lightning-fast read and write operations, ideal for real-time applications.
Flexibility: Support for a variety of data structures, including strings, hashes, lists, sets, and more.
Compatibility: Seamlessly integrate with your existing OpenShift applications and services.
Developer Productivity: Simplified deployment and management allow developers to focus on building features rather than infrastructure.
Getting Started
To get started with Redis by VSHN, visit our Redis product page on the OpenShift Application Marketplace. Our comprehensive documentation will guide you through the setup process, ensuring you can quickly and efficiently integrate Redis into your workflows.
Do you want to see all our open documentation for how to create or use any of the services in the marketplace? You can find them all openly available here VSHN AppCat User Documentation
Be on the lookout for more services as we continue expanding our marketplace. Let’s keep those containers humming!
VSHN Managed OpenShift: What you need to know about OpenShift 4.16
16. Okt. 2024
Upgrade to OpenShift version 4.16
As we start to prepare the upgrade to OpenShift v4.16 for all our customers clusters, it is a good opportunity to look again at what’s new in the Red Hat OpenShift 4.16 release. The release is based on Kubernetes 1.29 and CRI-O 1.29 and brings a handful of exciting new features which will make VSHN Managed OpenShift even more robust. Additionally, the new release also deprecates some legacy features which may require changes in your applications.
The Red Hat infographic highlights some of the key changes:
Red Hat OpenShift 4.16: What you need to know Infographic by Ju Lim
Changes which may require user action across all VSHN Managed OpenShift, including APPUiO
For VSHN Managed OpenShift, we’re highlighting the following changes which may require user action in our Release notes summary
Clusters which use OpenShift SDN as the network plugin can’t be upgraded to OpenShift 4.17+
This doesn’t affect most of the VSHN Managed OpenShift clusters since we’ve switched to Cilium as the default network (CNI) plugin a while ago and most of our older managed clusters have been migrated from OpenShift SDN to Cilium over the last couple of months.
The proxy service for the cluster monitoring stack components is changed from OpenShift OAuth to kube-rbac-proxy
Users who use custom integrations with the monitoring stack (such as a Grafana instance which is connected to the OpenShift monitoring stack) may need to update the RBAC configuration for the integration. If necessary, we’ll reach out to individual VSHN Managed OpenShift customers once we know more.
The ingress controller HAProxy is updated to 2.8
HAProxy 2.8 provides multiple options to disallow insecure cryptography. OpenShift 4.16 enables the option which disallows SHA-1 certificates for the ingress controller HAProxy. If you’re using Let’s Encrypt certificates for your applications no action is needed. If you’re using manually managed certificates for your Routes or Ingresses, you’ll need to ensure that you’re not using SHA-1 certificates.
Legacy service account API token secrets are no longer generated
In previous OpenShift releases, a legacy API token secret was created for each service account to enable access to the integrated OpenShift image registry. Starting with this release, these legacy API token secrets aren’t generated anymore. Instead, each service account’s image pull secret for the integrated image registry uses a bound service account token which is automatically refreshed before it expires.
If you’re using a service account token to access the OpenShift image registry from outside the cluster, you should create a long-lived token for the service account. See the Kubernetes documentation for details.
Linux control groups version 1 (cgroupv1) deprecated
The default cgroup version has been v2 for the last couple OpenShift releases. Starting from OpenShift 4.16, cgroup v1 is deprecated and it will be removed in a future release. The underlying reason for the pending removal is that Red Hat Enterprise Linux (RHEL) 10 and therefore also Red Hat CoreOS (RHCOS) 10 won’t support booting into cgroup v1 anymore.
If you’re running Java applications, we recommend that you make sure that you’re using a Java Runtime version which supports cgroup v2.
Warning for iptables usage
OpenShift 4.16 will generate warning event messages for pods which use the legacy IPTables kernel API, since the IPTables API will be removed in RHEL 10 and RHCOS 10.
If your software still uses IPTables, please make sure to update your software to use nftables or eBPF. If you are seeing these events for third-party software that isn’t managed by VSHN, please check with your vendor to ensure they will have an nftables or eBPF version available soon.
Other changes
Additionally, we’re highlighting the following changes:
RWOP with SELinux context mount is generally available
OpenShift 4.16 makes the ReadWriteOncePod access mode for PVs and PVCs generally available. In contrast to RWO where a PVC can be used by many pods on a single node, RWOP PVCs can only be used by a single pod on a single node. For CSI drivers which support RWOP, the SELinux context mount from the pod or container is used to mount the volume directly with the correct SELinux labels. This eliminates the need to recursively relabel the volume and can make pod startup significantly faster.
However, please note that VSHN Managed OpenShift doesn’t yet support the ReadWriteOncePod access mode on all supported infrastructure providers. Please reach out to us if you’re interested in this feature.
Monitoring stack replaces prometheus-adapter with metrics-server
OpenShift 4.16 removes prometheus-adapter and introduces metrics-server to provide the metrics.k8s.io API. This should reduce load on the cluster monitoring Prometheus stack.
Exciting upcoming features
We’re also excited about multiple upcoming features which aren’t yet generally available in OpenShift 4.16:
Node disruption policies
We’re looking forward to the “Node disruption policy” feature which will allow us to deploy some node-level configuration changes without node reboots. This should reduce the need for scheduling node-level changes to be rolled out during maintenance, and will enable us to say confidently whether a node-level change requires a reboot or not.
Route with externally managed certificates
OpenShift 4.16 introduces support for routes with externally managed certificates as a tech preview feature. We’re planning to evaluate this feature and make it available in VSHN Managed OpenShift once it reaches general availability.
This feature will allow users to request certificates with cert-manager (for example from Let’s Encrypt) and reference the cert-manager managed secret which contains the certificate directly in the Route instead of having to create an Ingress resource (that’s then translated to an OpenShift Route) which references the cert-manager certificate.
Changes not relevant to VSHN customers
There are a number of network related changes in this release, but these are not relevant for VSHN managed clusters as these are mostly running Cilium. In particular, OVNKubernetes gains support for AdminNetworkPolicy resources, which provide a mechanism to deploy cluster-wide network policies. Please note that similar results should be achievable with Cilium’s CiliumClusterWideNetworkPolicy resources, and Cilium is actively working on implementing support for AdminNetworkPolicy.
Summary
OpenShift 4.16 brings deprecates some features which may require changes to your applications in order to make future upgrades as smooth as possible. Additionally, OpenShift 4.16 is the last release that supports OpenShift SDN as the network plugin and disables support for SHA-1 certificates in the ingress controller. For those interested in the nitty gritty details of the OpenShift 4.16 release, we refer you to the detailed Red Hat release notes, which go through everything in detail.
VSHN customers will be notified about the upgrades to their specific clusters in the near future.
Interested in VSHN Managed OpenShift?
Head over to our product page VSHN Managed OpenShift to learn more about how VSHN can help you operate your own OpenShift cluster including setup, 24/7 operation, monitoring, backup and maintenance. Hosted in a public cloud of your choice or on-premises in your own data center.
Simon Gerber
Simon Gerber ist ein DevOps-Ingenieur bei VSHN.
Latest news
Allgemein
Open Source
Sovereignty
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten
Announcing General Availability of PostgreSQL by VSHN – On OpenShift
3. Okt. 2024
We have some fantastic news – our PostgreSQL service is now generally available on OpenShift in our Application Catalog through the VSHN Application Marketplace. After seeing our container-based database solution work wonders for a few lucky customers, we’re excited to open it up for all to enjoy!
Why You’ll Love It
Always On: our high availability setup keeps your data accessible.
Safety First: top-notch security features to keep your data safe.
Grow As You Go: easily scale with your business needs.
Hands-Free Maintenance: automatic updates and backups? Yes, please!
Expert Help: our team is always here to support you.
Do you have an application that you run in containers or are moving to containers that uses PostgreSQL? Do you not want the complexity of running your database within a Kubernetes cluster?
Then check out PostgreSQL by VSHN to dive into the details and get started today.
Do you want to see all our open documentation for how to create or use any of the services in the marketplace? You can find them all openly available here VSHN AppCat User Documentation
Be on the lookout for more services as we continue expanding our marketplace. Let’s keep those containers humming!
Jetzt verfügbar: DevOps in der Schweiz Report 2024
12. Sep. 2024
Wir freuen uns, die fünfte Ausgabe unseres Reports „DevOps in der Schweiz“ vorstellen zu dürfen!
Von Januar bis April 2024 haben wir eine Studie durchgeführt, um zu erfahren, wie Schweizer Unternehmen DevOps-Prinzipien umsetzen und anwenden.
Wir haben die Ergebnisse in einer PDF-Datei zusammengefasst (nur in englischer Sprache verfügbar) und wie in der vorherigen Ausgabe geben wir auf den ersten Seiten eine kurze Zusammenfassung unserer Ergebnisse.
