Die Experten für Cloud und Hosting on ayedo

Polycrate CLI 0.32.0 released: SDD-Erweiterungen für Agent-Workflows

Mon, 30 Mar 2026 12:00:00 +0000

Polycrate CLI Version 0.32.0 baut auf dem in 0.31.0 eingeführten Spec-Driven Development auf und macht es erheblich robuster für den produktiven Einsatz mit Coding Agents.

Spec-Typen nach Conventional Commits

Specs haben nun einen Typ, der das initiale Sektionsschema steuert und typ-spezifische Validierungsregeln aktiviert:

polycrate spec create --name "Fix login bug"  --type fix      # Problem → Root Cause → Solution
polycrate spec create --name "Add dark mode"  --type feat     # Feature Description → Solution
polycrate spec create --name "Drop v1 API"    --type breaking # wie feat + Migration (Pflicht)

Gültige Typen folgen dem Conventional Commits Standard: fix, feat, breaking, refactor, chore, docs, perf, analysis und weitere.

GitOps-Plattformunabhängigkeit durch Polycrate-Automatisierung

Mon, 30 Mar 2026 11:31:38 +0000

GitOps-Plattformunabhängigkeit durch Polycrate-Automatisierung

Automatisierungsschicht verstehen, die aus dezentralen Spezifikationen eine kohärente, reproduzierbare Deployments-Pipeline für Multi-Cloud- und Hybrid-Umgebungen erzeugt.

Für Unternehmen, die folgende Ziele verfolgen, bietet dieser Ansatz klare Vorteile:

Betriebliche Vereinfachung durch konsistente Deployments über Clouds hinweg.
Schnelleres Onboarding neuer Plattformen oder Regionen ohne Neuentwicklung der Pipelines.
Bessere Governance, Auditierbarkeit und digitale Souveränität durch policy-first-Launches und nachvollziehbare Artefakte.
Wirtschaftliche Vorteile durch geringeren Rechen- und Verwaltungsaufwand sowie geringere Fehlerraten.

Einleitung

Verschlüsselung gilt als Königsdisziplin moderner IT-Sicherheit. Daten sind geschützt, Zugriffe kontrolliert, Systeme abgesichert – zumindest in der Theorie.

In vielen Unternehmen hat sich daraus eine beruhigende Annahme entwickelt: Wenn Daten ausreichend verschlüsselt sind, lassen sich auch regulatorische Risiken beherrschen.

Diese Annahme ist gefährlich.

Denn sie verkennt ein zentrales Spannungsfeld moderner Cloud-Architekturen: Sicherheit ist nicht nur eine technische, sondern auch eine rechtliche Kategorie.

Die Komfortzone der Technik

IT-Teams denken in Architekturen. In Zugriffskonzepten, Schlüsselmanagement, Zero-Trust-Modellen und Ende-zu-Ende-Verschlüsselung.

US-Cloud im Einsatz:

Mon, 30 Mar 2026 10:47:36 +0000

Welche Risiken Unternehmen konkret unterschätzen

Einleitung

Die Nutzung von US-Cloud-Diensten ist für viele Unternehmen heute selbstverständlich. Plattformen wie Microsoft 365, AWS oder Google Cloud sind tief in Geschäftsprozesse integriert und oft alternativlos – zumindest auf den ersten Blick.

Gleichzeitig zeigt sich in der Praxis ein wiederkehrendes Muster: Die tatsächlichen Risiken dieser Nutzung werden systematisch unterschätzt.

Nicht, weil sie unbekannt wären – sondern weil sie falsch eingeordnet werden.

Zwischen Komfort und Kontrollverlust

Cloud-Lösungen versprechen Effizienz, Skalierbarkeit und Innovationsgeschwindigkeit. Für viele IT-Abteilungen sind sie der Schlüssel zur Modernisierung.

Warum europäische Cloud-Strategien ohne US-Risiko neu gedacht werden müssen

Mon, 30 Mar 2026 10:47:12 +0000

Einleitung

Viele Cloud-Strategien in europäischen Unternehmen basieren auf einer Annahme, die lange als pragmatischer Kompromiss galt: Solange Daten in europäischen Rechenzentren gespeichert werden, lassen sich regulatorische Risiken kontrollieren.

Diese Annahme ist nicht mehr haltbar.

Spätestens mit den Erkenntnissen aus dem Gutachten der Universität Köln zur US-Rechtslage rund um FISA, CLOUD Act und RISAA wird deutlich, dass sich das Risikoprofil fundamental verschoben hat. Nicht die physische Datenlokation entscheidet über Zugriffsmöglichkeiten – sondern die Frage, wer Kontrolle über diese Daten ausüben kann.

US-Zugriff auf Cloud-Daten:

Mon, 30 Mar 2026 10:41:14 +0000

Warum Kontrolle wichtiger ist als der Serverstandort

Einleitung

Cloud Computing ist längst mehr als nur ein Infrastrukturthema. Für viele Unternehmen bildet die Cloud heute das Fundament ihrer digitalen Wertschöpfung – von der Softwareentwicklung über datengetriebene Geschäftsmodelle bis hin zu KI-Anwendungen. Gleichzeitig verschiebt sich mit der Auslagerung in externe Plattformen eine zentrale Frage immer stärker in den Vordergrund: Wer hat im Zweifel Zugriff auf diese Daten?

Ein Rechtsgutachten der Universität Köln aus dem März 2025, beauftragt durch das Bundesinnenministerium, liefert dazu eine ernüchternde Antwort. Eine ausführliche Einordnung der Ergebnisse findet sich unter https://datenrecht.ch/us-zugriffsbefugnisse-auf-daten-in-der-cloud-gutachten-uni-koeln-vom-maerz-2025/ und diente als inhaltliche Grundlage für diesen Beitrag. Es zeigt, dass sich viele der gängigen Annahmen über Datenschutz, Datenlokation und technische Abschottung in der Praxis als trügerisch erweisen.

Bring-Your-Own-IP (BYOIP) in regulierten Netzen: Souveränität im Routing

Mon, 30 Mar 2026 09:27:09 +0000

In einer klassischen Cloud-Umgebung erhalten Kunden ihre IP-Adressen vom Cloud-Provider. Das ist bequem, erzeugt aber eine gefährliche Abhängigkeit („Vendor Lock-in"). Für Betreiber kritischer Infrastrukturen ist diese Abhängigkeit ein strategisches Risiko: Wer seine IP-Adressen nicht selbst besitzt, kann seine Plattform im Krisenfall nicht einfach zu einem anderen Anbieter umziehen, ohne dass bei allen Kunden (Netzbetreibern, Stadtwerken, Behörden) hunderte Firewall-Regeln und VPN-Tunnel händisch angepasst werden müssen.

Die Lösung ist Bring-Your-Own-IP (BYOIP). Dabei nutzt der Plattform-Betreiber seinen eigenen, Provider-unabhängigen Adressraum (PI-Space) und „nimmt ihn mit", egal wo die physische Infrastruktur gerade betrieben wird.

Stretched Cluster vs. Multi-Region: Architekturentscheidungen für maximale Resilienz

Mon, 30 Mar 2026 09:21:56 +0000

Wenn Unternehmen entscheiden, ihre Kubernetes-Plattform auf zwei Rechenzentren zu verteilen, stehen sie vor einer Richtungsentscheidung: Baut man einen einzigen, „gestreckten" Cluster (Stretched Cluster), der sich über beide Standorte spannt, oder betreibt man zwei völlig getrennte Cluster (Multi-Region)?

Was auf dem Papier elegant klingt - ein einziger logischer Cluster, in dem man Pods einfach von A nach B schieben kann - erweist sich im KRITIS-Umfeld oft als riskante Fehlentscheidung. Für unser Projekt haben wir uns bewusst für das Multi-Region-Modell entschieden. Hier ist die Begründung für diese architektonische Weichenstellung.

Failover ohne DNS-Latenz: BGP Anycast für KRITIS-Plattformen

Mon, 30 Mar 2026 09:16:14 +0000

In herkömmlichen Hochverfügbarkeits-Szenarien ist DNS (Domain Name System) das Standardwerkzeug für den Failover. Fällt Standort A aus, wird der DNS-Eintrag auf die IP von Standort B umgebogen. Doch in der KRITIS-Welt, insbesondere bei der Steuerung von Strom- oder Gasnetzen, stößt dieser Ansatz an drei kritische Grenzen:

TTL-Verzögerung: DNS-Einträge werden weltweit gecacht. Selbst bei einer niedrigen “Time to Live” (TTL) dauert es Minuten bis Stunden, bis jeder Client die neue IP übernimmt.
Harte IP-Vorgaben: Viele Netzbetreiber nutzen starre Firewall-Regeln oder VPN-Tunnel, die auf eine feste IP-Adresse programmiert sind. Eine Änderung der IP am Zielort erfordert koordinierte manuelle Arbeit bei dutzenden Kunden gleichzeitig.
Client-Verhalten: Manche SCADA-Systeme oder IoT-Gateways cachen IP-Adressen dauerhaft (“Sticky DNS”) und bemerken eine Änderung erst nach einem manuellen Neustart.

Die Lösung für dieses Problem ist BGP Anycast. Hierbei wird die Umschaltung von der Applikationsebene direkt in das Fundament des Internets verschoben: das Routing.

Single Point of Failure Standort: Warum ein Rechenzentrum für KRITIS nicht reicht

Mon, 30 Mar 2026 09:10:01 +0000

In der Welt der kritischen Infrastrukturen (KRITIS) ist “Hochverfügbarkeit” kein bloßes Schlagwort, sondern eine gesetzliche und gesellschaftliche Verpflichtung. Wer Steuerungssysteme für Strom-, Gas- oder Wärmenetze betreibt, agiert in einem Umfeld, in dem Ausfälle unmittelbare Auswirkungen auf die öffentliche Versorgungssicherheit haben können.

Viele Unternehmen wiegen sich in Sicherheit, weil ihre Plattform innerhalb eines Rechenzentrums (RZ) redundant aufgebaut ist: Mehrere Server-Racks, redundante Netzteile, gespiegelte Datenbanken und ein lokaler Kubernetes-Cluster mit mehreren Control-Plane-Nodes. Doch diese Architektur hat eine Achillesferse: Sie schützt vor dem Ausfall einer Komponente, aber nicht vor dem Ausfall des Standorts.

Die hybride Data-Plattform: Kubernetes als universelle Abstraktionsschicht

Mon, 30 Mar 2026 08:53:13 +0000

Industriekonzerne stehen heute vor einer paradoxen Herausforderung: Sie müssen die Agilität und Innovationskraft von Cloud-Startups adaptieren, gleichzeitig aber die kompromisslose Stabilität, Sicherheit und Datensouveränität ihrer On-Premise-Welt wahren. Die digitale Transformation im Bereich Data Engineering scheitert oft daran, dass Teams zwischen diesen Welten hin- und hergerissen sind.

Der Aufbau einer Data-Engineering-Plattform auf Basis von Kubernetes löst dieses Paradoxon. Kubernetes fungiert hierbei als universelle Abstraktionsschicht, die Rechenleistung, Speicher und Netzwerk von der zugrundeliegenden Hardware entkoppelt. Es ist das Bindeglied, das den „Server im Keller" und die „GPU-Instanz in der Cloud" zu einer einzigen, logischen Ressource verschmilzt.

Artifact-Management für Data Science: Versionierung von Modellen und ETL-Jobs mit Harbor

Mon, 30 Mar 2026 08:48:16 +0000

In der Softwareentwicklung ist die Versionierung von Code Standard. Im Data Engineering und bei KI-Projekten reicht das jedoch nicht aus. Ein Modell besteht nicht nur aus Code, sondern aus einer spezifischen Kombination aus Trainingsdaten-Snapshots, Bibliotheks-Abhängigkeiten (Python-Packages) und den gewichteten Parametern des Modells selbst.

Wenn ein KI-Modell zur Qualitätskontrolle in der Produktion eine falsche Entscheidung trifft, muss die IT-Abteilung lückenlos nachweisen können: Welcher Stand des Codes lief in welchem Container? Welche Versionen der Bibliotheken waren installiert? Hier kommt Harbor ins Spiel - eine Enterprise-grade Container Registry, die weit mehr ist als nur ein Ablageort für Images.

S3-kompatibler Speicher On-Prem: CEPH als skalierbares Backend für Data-Lakes

Mon, 30 Mar 2026 08:20:33 +0000

In einer modernen Data-Engineering-Plattform ist der Speicherbedarf nicht nur riesig, sondern auch vielfältig. Wir brauchen Platz für rohe Sensordaten, fertige KI-Modelle, Container-Images und Backups. Klassische File-Server (NFS) stoßen hier schnell an ihre Grenzen, besonders wenn es um parallele Zugriffe von hunderten Kubernetes-Pods geht.

Die Lösung für unseren Industriekonzern ist CEPH. Als hochverfügbares, verteiltes Storage-System verwandelt CEPH Standard-Server-Hardware in einen mächtigen Speicherverbund. Das entscheidende Feature: Es bietet eine S3-kompatible Schnittstelle direkt im eigenen Rechenzentrum.

Analytische Datenbanken im Cluster: ClickHouse und TimescaleDB für High-Volume-Daten

Mon, 30 Mar 2026 08:12:34 +0000

In einem Industriekonzept fallen pro Tag Millionen von Datenpunkten an. Wenn diese Daten in Apache Kafka fließen, stellt sich die nächste kritische Frage: Wo speichern wir sie so, dass Ingenieure und Data Scientists sie effizient abfragen können? Eine herkömmliche relationale Datenbank stößt bei Milliarden von Zeilen schnell an ihre Grenzen. Abfragen über Zeiträume von Monaten dauern dort oft Minuten - für interaktive Dashboards oder KI-Modelle ist das inakzeptabel.

Die Lösung auf unserer Kubernetes-Plattform ist der Einsatz spezialisierter, analytischer Datenbanken wie ClickHouse und TimescaleDB. Diese Systeme sind darauf ausgelegt, riesige Datenmengen (Big Data) blitzschnell zu aggregieren und zu analysieren.

Real-Time Ingestion: Apache Kafka als Event-Streaming-Backbone für die Industrie

Mon, 30 Mar 2026 08:07:23 +0000

In der modernen Fertigung entstehen Daten nicht in Paketen, sondern als kontinuierlicher Strom. Sensoren an Walzstraßen, Durchflussmesser in chemischen Reaktoren und Logistik-Systeme produzieren sekündlich Statusmeldungen. Wer diese Daten erst nachts in einem Batch-Lauf auswertet, verpasst die Chance auf sofortige Reaktion - sei es bei Qualitätsabweichungen oder drohenden Maschinenausfällen.

Um diesen “Daten-Tsunami” zu bändigen, setzen wir auf Apache Kafka innerhalb des Kubernetes-Clusters. Kafka fungiert dabei als hochverfügbares, digitales Nervensystem, das Ereignisse (Events) in Echtzeit aufnimmt, speichert und an die richtigen Analyse-Tools verteilt.

Skalierbare Datenpipelines: Apache Airflow im orchestralen Kubernetes-Betrieb

Mon, 30 Mar 2026 07:58:54 +0000

In der industriellen Datenverarbeitung sind ETL-Prozesse (Extract, Transform, Load) das Nervensystem der Produktion. Wenn Sensordaten aus Werken weltweit zusammengeführt, bereinigt und in Analyse-Modelle gespeist werden sollen, reicht ein einfacher Cronjob nicht mehr aus. In einem globalen Industriekonzern müssen tausende Abhängigkeiten überwacht, Fehler automatisch abgefangen und Ressourcen dynamisch zugewiesen werden.

Apache Airflow hat sich hier als Standard für das Workflow-Management etabliert. Doch die wahre Stärke spielt Airflow erst aus, wenn es nicht auf einer statischen VM, sondern nativ auf Kubernetes betrieben wird. Erst durch diese Kombination wird aus einer sequenziellen Aufgabenliste eine elastische Datenfabrik.

Polycrate API für Teams: Zentrales Monitoring und Remote-Triggering

Mon, 30 Mar 2026 00:00:00 +0000

TL;DR

Die Polycrate API macht aus einzelnen Workspaces eine Team-Plattform: alle Workspaces, Action Runs und SSH-Sessions zentral einsehbar – ideal für Betrieb, Compliance und Audits.
Remote-Triggering über die API ersetzt lokale CLI-Installationen in CI/CD-Pipelines und auf Jump Hosts: Build-Agents reden per HTTP mit Polycrate, der Rest läuft in standardisierten Containern.
Workspace-Validierung und zentrales Encryption Key Management werden zu wiederverwendbaren Services für Ihr gesamtes Team; HTTP-Endpoint-Monitoring der Plattform läuft über API und Polycrate Operator (nicht über einen Block in workspace.poly).
Das Web-Dashboard der Polycrate API gibt Team-Leads und Compliance-Verantwortlichen einen sauberen Überblick: wer hat was, wann, wo ausgelöst – inklusive Reporting-Funktionen.
ayedo stellt mit der Polycrate API ein Enterprise-Feature bereit, das sich nahtlos in Ihre Platform Engineering-Initiativen integrieren lässt – inklusive Unterstützung durch unsere Beratung.

Polycrate API als Team-Plattform statt Einzel-CLI

Mit plain Ansible sieht Automatisierung oft so aus:

Auditierbare Operations: SSH-Sessions und CLI-Aktivitäten mit Polycrate API

Sun, 29 Mar 2026 00:00:00 +0000

TL;DR

Polycrate protokolliert nicht nur Action Runs (Ansible-Playbooks), sondern auch SSH-Sessions, Workspace-Syncs und CLI-Instanzen – alles zentral über die Polycrate API abrufbar.
SSH-Session-Logging beantwortet die klassische Incident-Response-Frage: Wer hat wann per SSH auf welchen Server zugegriffen, wie lange, mit welchem Exit-Code?
Workspace-Sync-Logs halten Git-Branch, Commit-SHA, Encryption-Status und Sync-Ergebnis fest und machen Änderungen an Automatisierung nachvollziehbar und revisionssicher.
Über die Polycrate API lassen sich Encryption Keys für verschlüsselte Workspaces zentral verwalten – ein wichtiger Baustein für NIS‑2- und DSGVO-konforme Betriebsprozesse.
ayedo liefert mit Polycrate, der API und begleitenden Platform-Engineering-Services einen auditierbaren Operations-Stack, der sich in bestehende Compliance- und Security-Prozesse integrieren lässt.

Warum Operations-Audit heute Chefsache ist

Sowohl NIS‑2 als auch DSGVO verschärfen den Druck auf nachvollziehbares, dokumentiertes IT-Betriebsverhalten:

Action Runs und Polycrate API: Jede Automatisierung mit Audit-Log

Sat, 28 Mar 2026 00:00:00 +0000

TL;DR

Polycrate erfasst jede polycrate run-Ausführung automatisch als „Action Run“ – inklusive Block, Action, Exit-Code, Zeitpunkt, Dauer, CLI-Version, Hostname und OS-User.
Über eine einfache Konfiguration in ~/.polycrate/polycrate.yml sendet die Polycrate CLI diese Action Runs an die Polycrate API – ohne zusätzliches Logging- oder Audit-Tooling.
In der Polycrate API (Weboberfläche und API) sehen Sie zentral: Wer hat wann welche Action auf welchem Workspace ausgeführt, können Deployments über Workspaces hinweg nachvollziehen und einzelne Action Runs gezielt erneut triggern. PolyHub ist der Marketplace für Blöcke; Action Runs und Audit-Daten liegen in der API.
Das Fail-Safe-Design sorgt dafür, dass API-Probleme niemals die eigentliche Automatisierung blockieren – die Infrastruktur-Änderung läuft immer durch, das Audit-Log ist „best effort“.
ayedo verbindet diese API-Funktionen mit praxiserprobten Platform Engineering-Ansätzen, um Automatisierung, Compliance und Kollaboration in Teams jeder Größe zusammenzubringen.

Warum Action Runs für Compliance so wichtig sind

„Wer hat am Freitag Abend die Production-Datenbank neu gestartet?“
„Wann ist Version 1.4.3 wirklich in Produktion angekommen?“
„Welche Änderungen wurden vor dem Incident gestern Nacht ausgeführt?“

GPU-Elastizität ohne Lock-in: Hybrid-Cloud-Strategien für KI-Workloads

Fri, 27 Mar 2026 11:11:21 +0000

In der industriellen KI-Entwicklung ist die GPU (Graphics Processing Unit) das neue Gold. Ob für das Training komplexer neuronaler Netze zur Qualitätskontrolle oder für großflächige Simulationen zur Energieoptimierung - ohne massive Rechenpower stehen Projekte still.

Das Problem in vielen Konzernen: On-Premise-Hardware ist teuer, hat lange Lieferzeiten und ist oft starr dimensioniert. Wenn drei Data-Science-Teams gleichzeitig ein Modell trainieren wollen, entsteht ein Stau. Die Lösung liegt in einer hybriden Kubernetes-Architektur, die lokale Ressourcen nutzt, aber bei Spitzenlast nahtlos und souverän in die Cloud ausweicht.

Entwicklungsumgebungen on Demand: Reproduzierbare Stacks mit Coder auf Kubernetes

Fri, 27 Mar 2026 11:06:37 +0000

In vielen Data-Engineering-Teams folgt der Start eines neuen Projekts einem frustrierenden Muster: Zuerst müssen Python-Versionen, R-Bibliotheken, SQL-Treiber und CUDA-Toolkits für die GPU-Nutzung mühsam auf der lokalen Workstation oder einer statischen VM konfiguriert werden. Das Ergebnis ist oft das berüchtigte „Bei mir funktioniert es"-Syndrom Code, der lokal läuft, aber in der Produktion oder beim Kollegen scheitert.

In einem globalen Industriekonzern mit komplexen Sicherheitsrichtlinien und wechselnden Projektteams wird dieser manuelle Setup-Aufwand zum massiven Zeitfresser. Die Lösung ist die Entkoppelung der Entwicklungsumgebung von der Hardware durch den Einsatz von Coder auf einer zentralen Kubernetes–Plattform.

KI im E-Commerce: Lokale LLMs für Textgenerierung sicher betreiben

Fri, 27 Mar 2026 10:53:20 +0000

Künstliche Intelligenz ist im E-Commerce kein Hype mehr, sondern ein Werkzeug zur Skalierung. Ob es um die Generierung von Produktbeschreibungen aus technischen Merkmalen, das Umschreiben von SEO-Texten oder automatisierte Antworten im Kundensupport geht - Large Language Models (LLMs) sparen hunderte Arbeitsstunden.

Doch viele Agenturen und Marken zögern: Werden meine internen Produktdaten zum Training der Modelle von Drittanbietern genutzt? Wo landen die Anfragen meiner Kunden rechtlich gesehen? Die Lösung für dieses Dilemma ist der Betrieb von Open-Source-Modellen wie Llama 3 oder Mistral direkt in der eigenen E-Commerce-Infrastruktur - mittels Ollama auf Kubernetes.

Souveränes Tracking: Server-Side Google Tag Manager im eigenen Container

Fri, 27 Mar 2026 10:48:36 +0000

Im modernen E-Commerce sind Daten die Basis für jede Wachstumsentscheidung. Doch klassisches Client-Side Tracking stößt an seine Grenzen: Ad-Blocker, Intelligent Tracking Prevention (ITP) der Browser und immer strengere Datenschutzvorgaben führen dazu, dass bis zu 30 % der Nutzerdaten schlichtweg nicht im Marketing-Backend ankommen.

Die Lösung für professionelle Shop-Betreiber ist der Wechsel zum Server-Side Tracking. Anstatt dass der Browser des Nutzers Daten direkt an Drittanbieter wie Google oder Meta sendet, übernimmt ein eigener Server im Kubernetes-Cluster die Kontrolle. Wir betreiben den Google Tag Manager (GTM) als souveräne Container-Instanz direkt auf der E-Commerce-Plattform.

Performance-Boost für die Suche: OpenSearch und Typesense im Cluster-Betrieb

Fri, 27 Mar 2026 10:41:07 +0000

Im modernen E-Commerce ist die Suchfunktion weit mehr als ein Eingabefeld. Sie ist der wichtigste Verkäufer im Shop. Nutzer, die die Suche verwenden, haben eine klare Kaufabsicht - doch diese Absicht verfliegt schnell, wenn die Ergebnisse Sekunden auf sich warten lassen oder irrelevant sind.

Viele Agenturen nutzen für die Suche entweder die Standard-Datenbank-Suche (die bei großen Katalogen schnell in die Knie geht) oder externe SaaS-Suchlösungen. Letztere verursachen jedoch oft hohe monatliche Kosten, zusätzliche Latenzen durch externe API-Aufrufe und datenschutzrechtliche Fragen. Die Lösung: Hochperformante Such-Engines wie OpenSearch oder Typesense, die als integraler Bestandteil direkt im Kubernetes-Cluster betrieben werden.

Shopware hochverfügbar: Strategien für 99,9 % Erreichbarkeit

Fri, 27 Mar 2026 10:33:41 +0000

Für einen Onlineshop im Mittelstand oder im D2C-Bereich ist Downtime weit mehr als ein technisches Ärgernis. Jede Minute Unerreichbarkeit bedeutet direkten Umsatzverlust, sinkendes Vertrauen bei den Kunden und verschwendetes Budget für laufende Marketing-Kampagnen.

Wer als Agentur wachsen und größere Marken betreuen möchte, kommt an der Forderung nach Service Level Agreements (SLAs) von 99,9 % nicht vorbei. Doch diese Verfügbarkeit lässt sich mit einem klassischen Single-Server-Setup physikalisch nicht garantieren. Ein Hardware-Defekt, ein hängender Datenbank-Prozess oder eine einfache Kernel-Panik am Host-System führen sofort zum Stillstand. Hochverfügbarkeit erfordert ein Umdenken in der Architektur: Weg vom Einzelserver, hin zum verteilten System.

Von isolierten Instanzen zur E-Commerce-Plattform: Warum klassisches Hosting nicht skaliert

Fri, 27 Mar 2026 10:27:01 +0000

In der Gründungsphase einer E-Commerce-Agentur ist der Weg meist pragmatisch: Jeder neue Kundenshop bekommt sein eigenes Hosting-Paket. Ein Shop bei Anbieter A, der nächste bei Anbieter B, der dritte auf einem dedizierten Root-Server. Das funktioniert am Anfang hervorragend, da jedes Projekt schnell und isoliert startfähig ist.

Doch mit dem Erfolg kommt die Komplexität. Ab einer zweistelligen Anzahl an Shops verwandelt sich dieses Modell schleichend in eine operative Belastung. Was als Flexibilität begann, wird zur Falle aus inkonsistenten Umgebungen und unvorhersehbaren Wartungsaufwänden.

Effiziente Hintergrund-Prozesse: Wie Redis und RabbitMQ die App entlasten

Fri, 27 Mar 2026 10:16:07 +0000

Kennen Sie das? Ein Nutzer klickt in Ihrer SaaS-App auf „PDF-Export generieren" oder „Monatsbericht erstellen", und plötzlich dreht sich das Lade-Icon für 10, 20 oder 30 Sekunden. Im schlimmsten Fall bricht die Verbindung ab (Timeout), oder die gesamte Anwendung wird für alle anderen Nutzer währenddessen träge.

In der frühen Phase einer Anwendung werden solche Aufgaben oft direkt im sogenannten „Request-Response-Zyklus" erledigt. Das bedeutet: Der Server pausiert die Antwort an den Nutzer, bis die schwere Aufgabe erledigt ist. Bei einem technischen SaaS-Anbieter für Bauplanung, der hunderte Nutzer gleichzeitig bedient, führt dieser Ansatz unweigerlich in die Knie. Die Lösung ist die konsequente Entkopplung durch asynchrone Hintergrund-Prozesse.

Die Anatomie einer souveränen Business-Plattform: So greifen Nextcloud, Zammad und Co. ineinander

Fri, 27 Mar 2026 09:39:45 +0000

Wer heute eine moderne IT-Infrastruktur aufbauen will, steht vor einer strategischen Richtungsentscheidung: Entweder man kauft sich in die Bequemlichkeit (und Abhängigkeit) großer US-SaaS-Monolithe ein, oder man baut eine eigene, souveräne Plattform. Doch „selbst hosten" klang für viele IT-Leiter lange Zeit nach einem riskanten Bastelprojekt - geprägt von manuellen Updates, Sicherheitslücken durch vergessene Patches und instabilen Skripten.

Dass es auch anders geht, zeigt die Architektur eines technischen Dienstleisters mit 180 Mitarbeitern. Hier wurde nicht einfach Software auf Servern installiert. Es wurde eine orchestrierte Plattform-Architektur geschaffen, die sich wie eine moderne Cloud-Lösung anfühlt, aber vollständig unter eigener Kontrolle in deutschen Rechenzentren operiert. Der technologische Kern dieser Freiheit ist Managed Kubernetes.

Mattermost in der Industrie: ChatOps für den Außendienst statt privater Messenger

Fri, 27 Mar 2026 09:30:26 +0000

In vielen technischen Service-Teams herrscht beim Thema Kommunikation ein gefährlicher Pragmatismus: Wenn es auf der Baustelle oder an der Maschine schnell gehen muss, wird zum privaten Smartphone gegriffen. Fotos von Defekten, Standortdaten und Absprachen zu Wartungsprotokollen landen in WhatsApp-Gruppen.

Was im Moment effizient wirkt, ist für das Unternehmen ein massives Problem. Nicht nur aus Sicht der DSGVO, sondern auch operativ: Informationen versickern in privaten Silos, sind für die Zentrale nicht dokumentiert und gehen verloren, sobald ein Mitarbeiter das Unternehmen verlässt. Die Lösung für moderne Industriedienstleister heißt Mattermost - integriert als souveräne „ChatOps"-Zentrale.

Dein erster produktiver Polycrate-Workspace: Eine Checkliste für den Start

Fri, 27 Mar 2026 00:00:00 +0000

TL;DR

Ein sauber benannter, klar strukturierter Polycrate-Workspace ist die halbe Miete: ein konsistenter Name (z. B. acme-corp-automation) und eine einfache Verzeichnisstruktur verhindern Chaos, bevor es entsteht.
Starten Sie mit wenigen, gut gewählten Blöcken – je nach Rolle z. B. Linux-Patching, Windows-Basisverwaltung oder Kubernetes-Deployment – und pinnen Sie Block-Versionen konsequent, statt jemals :latest zu verwenden.
Aktivieren Sie frühzeitig Workspace-Verschlüsselung, setzen Sie Git auf und bauen Sie Ihren ersten eigenen Block – diese Checkliste macht den Einstieg reproduzierbar und auditierbar.
Typische Stolperfallen sind unverschlüsselte Secrets, hosts: localhost statt korrekter Inventories und fehlende Version-Pins; mit Polycrate und den Best Practices vermeiden Sie diese Fehler von Anfang an.
ayedo unterstützt Sie mit Polycrate, praxisnahen Best Practices, Projekten und Beratung dabei, aus Ihrem ersten Workspace eine tragfähige Automatisierungsplattform zu machen.

Lange Zeit war die IT-Infrastruktur im B2B-Vertrieb ein Randthema. Man setzte auf die großen US-SaaS-Anbieter, weil sie als „Standard" galten. Doch der Wind hat sich gedreht: In Zeiten verschärfter Compliance-Regeln wie NIS-2 oder DORA wird die Frage nach dem „Wo und Wie" der Datenverarbeitung zum entscheidenden Faktor bei der Auftragsvergabe.

Besonders technische Dienstleister, die für Betreiber kritischer Infrastrukturen (KRITIS) arbeiten, stehen heute vor einer neuen Realität: Wer nachweisen kann, dass auftragsbezogene Daten den europäischen Rechtsraum niemals verlassen, gewinnt nicht nur Vertrauen - er sichert sich einen handfesten Marktvorteil.

Souveräne KI: Warum LLMs (vLLM/Ollama) self-hosted sein müssen

Wed, 25 Mar 2026 12:10:33 +0000

Spätestens seit dem Durchbruch von ChatGPT ist klar: KI kann mehr als nur Zahlen analysieren. Sie kann Berichte schreiben, Wartungsanleitungen zusammenfassen und Anomalien in menschlicher Sprache erklären. Analyse-Software für Sensordaten nutzt LLMs, um Technikern in der Werkhalle präzise Handlungsanweisungen zu geben: „Vibration an Lager 4 deutet auf Fettmangel hin - bitte bis Schichtende nachschmieren."

Doch hier stellt sich eine kritische Frage des Datenschutzes und der Souveränität: Wollen Sie, dass Ihre internen Maschinendaten, Prozessgeheimnisse und Wartungsberichte über die API eines US-Anbieters laufen? Für die deutsche Industrie ist die Antwort meist ein klares Nein. Die Lösung: Self-hosted LLMs auf eigener Infrastruktur.

Observability für MLOps: Mehr als nur CPU und RAM überwachen

Wed, 25 Mar 2026 12:05:24 +0000

In der klassischen IT-Welt ist die Welt binär: Ein Server läuft oder er läuft nicht. Eine Datenbank antwortet oder sie wirft einen Fehler. In der Welt des Machine Learnings ist das tückischer. Ein Modell kann technisch perfekt laufen (CPU bei 20 %, 200 OK Status-Code), aber inhaltlich völlig falschen Unsinn produzieren.

Wir nennen das „Silent Failures". Wenn die Sensorik plötzlich einen Maschinenausfall nicht vorhersagt, obwohl alle Systeme „grün" leuchten, liegt das oft an Phänomenen wie Model Drift. Ohne eine spezialisierte Observability-Strategie bleibt der ML-Betrieb ein Blindflug.

Edge vs. Cloud: Die optimale Verteilung von KI-Workloads in der Fertigung

Wed, 25 Mar 2026 11:59:17 +0000

In der Industrie stellt sich eine fundamentale Architektur-Frage: Soll die KI direkt an der Maschine entscheiden (Edge) oder die Daten für eine tiefere Analyse in ein zentrales System schicken (Cloud)?

Wer versucht, Terabytes an rohen Sensordaten in Echtzeit durch eine schmale Internetleitung in die Cloud zu jagen, scheitert an der Latenz. Wer versucht, komplexe Modelle auf einem kleinen Industrie-PC an der Maschine zu trainieren, scheitert an der Rechenpower.

1. Edge Computing: Wenn Millisekunden über Schrott oder Qualität entscheiden

An der „Edge" - also direkt in der Werkshalle - zählt nur eines: Geschwindigkeit. Wenn ein Sensor eine Anomalie an einer Fräse erkennt, muss der Stopp-Befehl innerhalb von Millisekunden erfolgen.

Cloud-Kosten-Hygiene: Warum ungenutzte GPUs Ihr Budget auffressen

Wed, 25 Mar 2026 11:54:00 +0000

In der Welt der IT-Infrastruktur gibt es kaum etwas Teureres als eine moderne NVIDIA-GPU, die nichts tut. Eine H100- oder A100-Instanz bei den großen Hyperscalern kostet pro Stunde oft so viel wie ein komplettes Office-Team an Kaffee verbraucht. Wenn Data Scientists vergessen, ihre Instanzen nach dem Training abzuschalten, oder wenn Cluster im Leerlauf teure Ressourcen reservieren, explodieren die Kosten innerhalb weniger Tage.

Das Problem bei KI-Projekten ist oft nicht das Modell selbst, sondern die mangelnde Transparenz und Kontrolle über die Hardware. „FinOps für ML" ist kein Luxus, sondern überlebenswichtig für die Wirtschaftlichkeit.

Experiment-Tracking vs. Model-Registry: Den Überblick im KI-Dschungel behalten

Wed, 25 Mar 2026 11:49:24 +0000

In der Softwareentwicklung ist Git die „Source of Truth". Wenn etwas nicht funktioniert, schaut man in die Commit-Historie. In der Welt der Künstlichen Intelligenz reicht das nicht aus. Ein Modell besteht nicht nur aus Code, sondern aus der Kombination von Code, Daten und Hyperparametern.

Ohne ein systematisches Management passiert bei Sensoriq (und vielen anderen) folgendes: Ein Data Scientist trainiert ein Modell, das hervorragende Ergebnisse liefert. Drei Wochen später soll dieses Modell in die Produktion - aber niemand weiß mehr genau, mit welchem Datensatz es trainiert wurde oder welche exakten Einstellungen verwendet wurden. Das Modell ist eine „Blackbox" ohne Geburtsurkunde.

Inferenz unter Druck: Wie man industrielle SLAs von < 500 ms garantiert

Wed, 25 Mar 2026 11:43:15 +0000

In einem Pilotprojekt verzeiht man einer KI vieles. Wenn die Vorhersage einer Anomalie mal zwei Sekunden dauert, ist das kein Weltuntergang. Doch in der industriellen Fertigung - etwa bei der Überwachung von Hochgeschwindigkeits-Pressen oder Roboterarmen - ist Zeit kein relativer Begriff, sondern ein harter Vertragsparameter (SLA).

Wenn eine Sensor-Analyse-Software verspricht, Ausfälle innerhalb von 500 ms zu prognostizieren, darf die Infrastruktur nicht zum Flaschenhals werden. Ein einfacher Python-Prozess auf einem Server reicht hier nicht mehr aus. Wir brauchen eine Architektur, die auf Lastspitzen reagiert, bevor der Nutzer sie bemerkt.

Open Source wird zum Standard:

Wed, 25 Mar 2026 11:27:16 +0000

Warum die EVB-IT-Reform ein Wendepunkt für staatliche IT ist

Die öffentliche IT-Beschaffung in Deutschland war lange von einem strukturellen Widerspruch geprägt. Politisch wurde digitale Souveränität gefordert, praktisch wurden proprietäre Lösungen bevorzugt. Nicht aus Überzeugung, sondern aus juristischer Unsicherheit.

Mit der Reform der EVB-IT-Musterverträge wird dieser Widerspruch aufgelöst. Open Source ist bei neuer Software kein Sonderfall mehr, sondern der Standard. Damit verschiebt sich die Logik staatlicher IT grundlegend.

Ein überfälliger Systemwechsel

Bisher waren die EVB-IT faktisch auf proprietäre Software ausgerichtet. Open-Source-Anbieter mussten Vertragswerke anpassen, Risiken kompensieren oder wurden ganz aus Vergaben gedrängt. Das Ergebnis war ein künstlich eingeschränkter Markt.

Reproduzierbarkeit ist kein Zufall: Standardisierte Workspaces mit JupyterHub

Wed, 25 Mar 2026 11:24:50 +0000

In vielen Data-Science-Teams beginnt der Arbeitstag mit einem Frustmoment: Ein geteiltes Notebook lässt sich nicht ausführen, weil eine Bibliothek fehlt. Ein Modell, das auf dem Rechner von Kollegin A trainiert wurde, liefert auf dem Server von Kollege B andere Ergebnisse. Und das Onboarding neuer Teammitglieder dauert Tage, bis alle CUDA-Treiber, Python-Venv-Umgebungen und Pfade korrekt konfiguriert sind.

Das Problem ist die lokale Fragmentierung. Wenn jeder auf seinem eigenen „Insel-Setup" arbeitet, bleibt Reproduzierbarkeit ein glücklicher Zufall. Die Lösung: JupyterHub auf Kubernetes.

Kafka auf VMs vs. Kubernetes: Warum der „Operator-Ansatz“ das Streaming revolutioniert

Wed, 25 Mar 2026 11:19:39 +0000

In der industriellen KI, wie bei der Predictive Maintenance von Sensordaten-Analyse-Software, sind Datenströme das Lebenselixier. Tausende Sensoren liefern sekündlich Messwerte, die gefiltert, aggregiert und an Inferenz-Modelle weitergereicht werden müssen. Als Herzstück dieser Pipeline hat sich Apache Kafka etabliert.

Doch viele Teams starten mit Kafka auf klassisch verwalteten Virtual Machines (VMs). Was klein anfängt, wird bei steigender Last - etwa durch den Rollout bei einem Großkunden - schnell zur operativen Last. Der Wechsel zu einem Kubernetes-nativen Betrieb mit dem Strimzi Operator ist hier oft der entscheidende Befreiungsschlag.

GPU-Hungersnot im Team? Wie Scheduling und Quotas den Frieden sichern

Wed, 25 Mar 2026 11:13:01 +0000

In vielen Machine-Learning-Teams herrscht ein ungeschriebenes Gesetz: Wer zuerst kommt, mahlt zuerst. Wer am Morgen den ersten Trainings-Job startet, belegt die GPU - oft für den ganzen Tag. Die restlichen Data Scientists warten, schwenken auf langsame CPU-Instanzen um oder buchen teure Schatten-IT in der Public Cloud.

Dieses „Wild-West-Szenario" bei der Hardware-Nutzung ist nicht nur ineffizient, es bremst die Innovation und lässt die Kosten explodieren. Die Lösung liegt nicht in mehr Hardware, sondern in intelligentem GPU-Scheduling und Resource Quotas.

Vom Notebook in die Produktion: Warum „Produktisierung“ kein manueller Schritt sein darf

Wed, 25 Mar 2026 11:06:13 +0000

In der Welt der Künstlichen Intelligenz gibt es ein Phänomen, das wir oft als die „Wall of Confusion" bezeichnen. Auf der einen Seite steht das Data-Science-Team, das in Jupyter Notebooks brillante Modelle entwickelt. Auf der einen Seite steht das Ops-Team, das für Stabilität, Latenz und SLAs in der Produktion verantwortlich ist.

Der kritische Punkt: Der Übergang vom experimentellen Code im Notebook zum stabilen Service in der Cloud ist oft ein manueller, fehleranfälliger Prozess. Wer Modelle manuell in Flask-Skripte umschreibt und auf dedizierte Server schiebt, baut sich eine technische Sackgasse.

Souveränität oder Illusion?

Wed, 25 Mar 2026 10:00:08 +0000

Ein Begriff ohne Substanz

Ein offener Brief von 25 europäischen Cloud- und Digitalunternehmen legt offen, was die europäische Digitalpolitik seit Jahren vermeidet: Der Begriff „digitale Souveränität" wird konsequent verwendet, ohne dass seine Voraussetzungen erfüllt sind.

Die Realität des Marktes

Die Marktrealität lässt daran keinen Zweifel. US-Hyperscaler wie AWS, Microsoft Azure und Google Cloud kontrollieren rund 70 Prozent des europäischen Marktes, während europäische Anbieter gemeinsam auf etwa 15 Prozent kommen. Diese Verteilung ist nicht einfach das Ergebnis technologischer Überlegenheit, sondern Ausdruck politischer Entscheidungen – insbesondere bei Regulierung und öffentlicher Beschaffung.

Frankreichs Open-Source-Strategie

Wed, 25 Mar 2026 09:34:48 +0000

Struktur statt Symbolpolitik

Hauptinhalt

Lima, ein Kommandozeilenwerkzeug zur Bereitstellung lokaler virtueller Maschinen, hat in seiner Version 2.1 bedeutende Neuerungen eingeführt. Ursprünglich entwickelt, um Containern auf Laptops zu helfen, hat sich Lima seit seinem Eintritt in die Cloud Native Computing Foundation (CNCF) im Jahr 2022 weiterentwickelt. Mit der Version 2.1 wird die Unterstützung für macOS- und FreeBSD-Gäste experimentell angeboten, wodurch die Anwendungsmöglichkeiten für Entwickler erweitert werden.

Polycrate vs. plain Ansible: Was du gewinnst – und warum es sich lohnt

Wed, 25 Mar 2026 00:00:00 +0000

TL;DR

Plain Ansible ist ein starkes Werkzeug für Ad-hoc-Automatisierung, schnelle Skripte und einfache Setups – aber Teams stoßen schnell an Grenzen bei Dependencies, Struktur und Sharing.
Polycrate baut auf Ansible auf, kapselt es sauber im Container und bringt ein Block-/Workspace-Modell mit, das Dependency-Chaos, Playbook-Wildwuchs und Secret-Handling systematisch adressiert.
Statt „ansible irgendwo installiert“ bekommst du mit Polycrate eine reproduzierbare, containerisierte Toolchain, Sharable Automation via OCI-Registry, Workspace-Verschlüsselung und Guardrails für größere Teams.
Es gibt valide Szenarien, in denen plain Ansible die bessere Wahl ist – etwa für sehr kleine Umgebungen, temporäre Skripte oder eingeschränkte Umgebungen ohne Container.
ayedo unterstützt dich dabei, den passenden Mix aus Ansible und Polycrate zu finden – von ersten Tests bis hin zu durchgängigem Platform Engineering mit automatisierter Compliance und Betriebssicherheit.

Polycrate und Ansible im direkten Vergleich

Ansible ist seit Jahren ein De-facto-Standard für Automatisierung – von Linux-Servern über Windows-Hosts bis zu Netzwerkkomponenten und IoT. Polycrate setzt genau dort an: Es ersetzt Ansible nicht, sondern strukturiert und operationalisiert es.

Polycrate MCP: KI-Assistenten mit Live-Infrastruktur-Kontext verbinden

Tue, 24 Mar 2026 00:00:00 +0000

TL;DR

Das Model Context Protocol (MCP) ist ein offener Standard: KI-Clients sprechen per JSON-RPC mit Hilfsprogrammen über stdin/stdout (stdio).
polycrate mcp startet genau solch einen MCP-Endpunkt: Er wird vom Client bei Bedarf als Subprozess gestartet – kein separater Dienst, den Sie im Workspace-Root mit cd … „hochfahren“, und nicht der Befehl polycrate mcp server (den es so nicht gibt).
Die mitgelieferten Tools liefern u. a. Polycrate Hub (Blöcke suchen, inspizieren, Versionen), offizielle Dokumentation (docs_get), Schema-Hilfen für workspace.poly / block.poly / CHANGELOG.poly / secrets.poly, Guides (Ansible, Registry, Debugging, Best Practices) sowie CLI-Metadaten (Versionen, Artefakte).
Lokale Workspace-Dateien (Playbooks, inventory.yml, Logs) spiegelt Polycrate MCP nicht automatisch. Dort hilft die IDE (z. B. Cursor), die Ihr Projekt ohnehin einliest – in Kombination mit den MCP-Tools entsteht der volle Kontext.
Vollständige Referenz: MCP Server Integration.

Warum reine KI ohne Polycrate-Kontext an Grenzen stößt

KI-Assistenten sind stark bei allgemeinen Ansible- oder YAML-Fragen – aber schwach, wenn es um Ihre Plattform-Standards, freigegebene Blöcke im Hub und korrekte *.poly-Strukturen geht. Ohne Zugriff auf aktuelle Dokumentation und Hub-Daten raten Modelle leicht daneben.

Trivy-Lieferkette kompromittiert: Was Docker Hub-Nutzer wissen sollten

Mon, 23 Mar 2026 23:25:14 +0000

TL;DR

Die Sicherheitsvorfälle rund um die Trivy-Bilder auf Docker Hub haben dazu geführt, dass CI/CD-Geheimnisse, Cloud-Anmeldeinformationen und SSH-Schlüssel von Nutzern kompromittiert wurden. Betroffene Nutzer sollten unverzüglich betroffene Bilder entfernen und ihre Anmeldeinformationen rotieren.

Hauptinhalt

Ein Sicherheitsvorfall, der Aqua Securitys Trivy-Scanner betrifft, wurde zwischen dem 19. und 23. März 2026 festgestellt. In diesem Zeitraum wurden die Trivy-Images mit den Tags 0.69.4, 0.69.5, 0.69.6 und “latest” auf Docker Hub kompromittiert. Die Angreifer nutzten eine Schwachstelle in Aqua Securitys CI/CD-Pipeline, um Malware in die Trivy-Images einzuschleusen. Diese Malware war in der Lage, CI/CD-Geheimnisse, Cloud-Anmeldeinformationen, SSH-Schlüssel und Docker-Konfigurationen zu exfiltrieren.

Enterprise-Automatisierung: Blöcke bauen, versionieren und im Team teilen

Mon, 23 Mar 2026 00:00:00 +0000

TL;DR

In vielen Enterprise-Organisationen baut jedes Team seine eigene Ansible-Welt – ohne klare Versionierung, ohne zentrale Wiederverwendung, ohne Governance. Das skaliert organisatorisch nicht.
Polycrate macht aus Ansible-Playbooks wiederverwendbare, versionierte Blöcke, die in einer internen OCI-Registry (z. B. Harbor oder registry.acme-corp.com) veröffentlicht und von beliebigen Teams genutzt werden können.
Das Block-Modell schafft Guardrails: Klare Schnittstellen, Semantic Versioning, CHANGELOG.poly und einfache Actions statt Playbook-Wildwuchs – inklusive Compliance-Mechanismen, damit nur freigegebene Block-Versionen in Produktion verwendet werden.
Durch die containerisierte Ausführung von Polycrate entfallen lokale Ansible-Setups und Python- bzw. Dependency-Chaos. Jede Entwickler-Workstation arbeitet mit derselben Toolchain; Blöcke lassen sich sicher teilen und in der Registry versionieren.
ayedo unterstützt Sie mit Platform Engineering, Polycrate-Expertise und einem Enterprise-Platform Workshop dabei, ein unternehmensweites Automatisierungs-Ökosystem aufzubauen, das Teams befähigt und Compliance-Anforderungen erfüllt.

Wenn Sie heute in ein größeres Unternehmen schauen, sehen Sie oft das gleiche Muster:

Polycrate CLI 0.31.0 released: Spec-Driven Development

Sun, 22 Mar 2026 12:00:00 +0000

Polycrate CLI Version 0.31.0 bringt Spec-Driven Development (SDD) — ein strukturiertes Lifecycle-Management für Specs und Releases, das die kollaborative Arbeit zwischen Entwicklern und Coding Agents (Claude Code, Cursor, etc.) auf eine neue Ebene hebt.

Spec-Driven Development

SDD beantwortet drei Kernfragen für jedes Team, das mit Coding Agents arbeitet:

Warum wurde etwas implementiert? (Spec als Archiv)
Was ist der aktuelle Stand? (Index, Status)
Wie kommt eine Änderung von der Idee zum Release? (definierter Lifecycle)

# SDD initialisieren
polycrate spec init

# Neue Spec anlegen
polycrate spec create "Login Timeout Fix"

# Spec ausarbeiten
polycrate spec update 0 --section problem="..."
polycrate spec update 0 --section solution="..."
polycrate spec finalize 0

Agent-Integration

polycrate spec init generiert automatisch Instruktionsdateien für Coding Agents — darunter CLAUDE.md, AGENTS.md und .cursor/rules/sdd.mdc. Diese Dateien enthalten strikte Regeln, die verhindern, dass Agents Spec-Dateien direkt bearbeiten und damit den Index korrumpieren.

IoT und Edge Computing: Raspberry Pi und Edge-Nodes mit Polycrate verwalten

Sun, 22 Mar 2026 00:00:00 +0000

TL;DR

Du kannst mit Ansible hunderte Raspberry Pis und andere Edge-Nodes zentral verwalten – ohne Agent auf den Geräten, nur per SSH.
Polycrate nimmt dir das komplette Ansible-Setup ab: Du brauchst auf deinem Laptop keine Python- oder Ansible-Installation, alles läuft reproduzierbar in einem Container.
Mit einem einzigen Polycrate-Block baust du idempotente OTA-Updates (apt upgrade) inklusive Service-Restart und verteilst Sensor- und Logging-Konfiguration auf deine Geräteflotte.
Über serial: 10 rollst du Updates sicher in Wellen aus, zum Beispiel 50 Raspberry Pis in Gruppen à 10 – ideal für Fabrikhallen, Smart-Home-Flotten oder Industrie-4.0-Setups.
ayedo unterstützt Teams mit praxisnahen Workshops, fertigen Polycrate-Blöcken und Beratung rund um IoT- und Edge-Automatisierung – inklusive Compliance-Themen und sicherer Workspace-Verschlüsselung.

Das IoT-Management-Problem in der Praxis

Stell dir eine typische Fabrikhalle vor:

Workspace-Verschlüsselung: Secrets DSGVO-konform verwalten – ohne externes Tooling

Sat, 21 Mar 2026 00:00:00 +0000

TL;DR

Unverschlüsselte SSH-Keys, Passwörter in Plaintext und Credentials im Wiki sind ein Compliance-Risiko – insbesondere unter DSGVO (seit dem 25.05.2018) und NIS‑2 (tritt am 17.10.2024 in Kraft).
Polycrate bringt Workspace-Verschlüsselung direkt mit: Alle Secrets liegen als Dateien im Workspace, werden mit age verschlüsselt und können sicher im Git-Repository versioniert werden.
secrets.poly enthält sensible Block-Konfiguration (Overrides zu workspace.poly), die zusammen mit Dateien unter artifacts/secrets/ mit einem Workspace-Encryption-Key (v. a. über die Polycrate API oder WORKSPACE_ENCRYPTION_KEY) per age verschlüsselt wird; beim Ausführen stellt Polycrate entschlüsselte Pfade bereit – Zugriff im Playbook über workspace.secrets[...].
Im Alltag ist der Workflow einfach: polycrate workspace decrypt zum Arbeiten, Änderungen vor dem Commit mit polycrate workspace encrypt absichern – keine externen Tools, kein zusätzliches Secret-Management-System.
ayedo verbindet Workspace-Verschlüsselung mit Platform Engineering: Polycrate bietet eine containerisierte Toolchain, Guardrails durch das Block-Modell und ein API-fähiges Ökosystem, das Security- und Compliance-Anforderungen von Anfang an mitdenkt.

Das Secrets-Problem: Wenn Bequemlichkeit zur Haftung wird

Wer länger mit Ansible, Shell-Skripten oder manueller Administration arbeitet, kennt typische Muster:

Ankündigung von Ingress2Gateway 1.0: Ihr Weg zur Gateway API

Fri, 20 Mar 2026 19:00:00 +0000

TL;DR

Die Veröffentlichung von Ingress2Gateway 1.0 bietet eine umfassende Lösung für die Migration von Ingress-NGINX zu Gateway API in Kubernetes. Mit Unterstützung für über 30 Annotations und einem stabilen Migrationsassistenten wird der Übergang zu einer modularen und erweiterbaren API erleichtert.

Hauptinhalt

Die [Kubernetes]-Netzwerklandschaft steht vor einem Wandel, da die Abkündigung von Ingress-NGINX für März 2026 ansteht. Organisationen müssen sich nun der Herausforderung stellen, ihre bestehenden Ingress-Implementierungen sicher auf die Gateway API zu migrieren. Die Gateway API bietet eine modularere und erweiterbare Schnittstelle mit robuster Unterstützung für Kubernetes-native Rollen- und Berechtigungsverwaltung (RBAC), während die Ingress API oft durch spezielle Annotations und Konfigurationsdateien erweitert wird.

Agenten auf Kubernetes mit Agent Sandbox ausführen

Fri, 20 Mar 2026 18:00:00 +0000

TL;DR

Das Agent Sandbox-Projekt für Kubernetes zielt darauf ab, die Herausforderungen bei der Ausführung von stateful, singleton AI-Agenten zu adressieren. Es bietet eine standardisierte API für die Verwaltung dieser Agenten, einschließlich starker Isolation, Lebenszyklusmanagement und stabiler Identität, und ermöglicht eine effiziente Skalierung durch vorab bereitgestellte Umgebungen.

Hauptinhalt

Die Architektur der künstlichen Intelligenz (KI) verändert sich grundlegend, von transienten, zustandslosen Funktionsaufrufen hin zu langlaufenden, autonomen Agenten. Diese Agenten benötigen nicht nur eine konstante Ausführung, sondern auch die Fähigkeit, Kontext zu speichern, externe Tools zu nutzen und über längere Zeiträume miteinander zu kommunizieren. Kubernetes hat sich als bevorzugte Plattform für das Hosting dieser neuen KI-Workloads etabliert, jedoch erfordert die Abbildung dieser Agenten auf traditionelle Kubernetes-Primitiven eine neue Abstraktion.

Sicherheitslücke? Nein – ein strukturelles Informationsproblem

Fri, 20 Mar 2026 09:54:22 +0000

Die aktuellen Warnungen von CISA und Amazon zu aktiven Angriffen auf Cisco FMC, Microsoft SharePoint und Zimbra wirken auf den ersten Blick wie ein routinierter Vorgang in der IT-Sicherheit: Schwachstellen werden identifiziert, bewertet, veröffentlicht – und anschließend gepatcht.

Diese Sicht ist bequem. Und sie ist falsch.

Denn sie blendet den entscheidenden Teil aus: den Zeitraum, in dem Angriffe bereits laufen, ohne dass jemand davon weiß.

Wenn Angriffe vor der Warnung beginnen

Besonders deutlich wird dieses Problem am Beispiel von Cisco.

Policy as Code: Compliance-Anforderungen mit Polycrate automatisieren

Fri, 20 Mar 2026 00:00:00 +0000

TL;DR

Manuelles Compliance-Checking mit Excel-Listen ist langsam, fehleranfällig und kaum nachweisbar reproduzierbar – mit Policy as Code beschreiben Sie Ihre Anforderungen einmal und lassen sie dann automatisch prüfen.
Mit Polycrate kapseln Sie Ansible vollständig im Container: keine lokale Installation, keine Python-Version-Konflikte, gleiche Tooling-Version für alle Beteiligten – ideal für wiederholbare Compliance-Prüfungen.
Ein eigener „Compliance-Block“ trennt Prüfen (check) und Korrigieren (remediate), generiert Audit-Reports als JSON/CSV und legt sie strukturiert im Workspace ab – inklusive Git-Historie als Audit-Trail.
NIS‑2 (Anwendung der Maßnahmen ab dem 18.10.2024) und DSGVO (seit dem 25.05.2018 in Kraft) fordern nachweisbare technische und organisatorische Maßnahmen. Mit Policy as Code können Sie konkrete Controls (z. B. CIS Benchmarks) automatisiert prüfen.
ayedo unterstützt Sie mit Open-Source-Tooling, Platform Engineering und speziell zugeschnittenen Workshops, um Compliance-Automatisierung sicher und verständlich in Ihre Organisation zu bringen.

Warum manuelles Compliance-Checking an Grenzen stößt

Viele Compliance-Teams arbeiten noch mit Excel-Checklisten oder Word-Dokumenten:

Helm-Charts als Polycrate-Block: Mehr Kontrolle über Chart-Deployments

Thu, 19 Mar 2026 00:00:00 +0000

TL;DR

Helm-Charts direkt per CLI zu deployen funktioniert – aber erst mit Ansible und Polycrate werden Deployments wirklich idempotent, versioniert und teamfähig.
block.config macht deine Helm-Values zum zentralen, versionierten Konfigurationspunkt – inklusive Jinja2-Template, das komplexe values.yaml-Strukturen sauber generiert.
Über Ansible-Module wie kubernetes.core.helm_repository, kubernetes.core.helm, kubernetes.core.helm_rollback bekommst du Upgrade-, Diff- und Rollback-Logik als wiederverwendbare Actions in einem Polycrate-Block.
Polycrate löst das Dependency-Problem: Helm, kubectl, Python, Ansible-Collections laufen im Container – keine lokalen Installationsorgien oder Versionskonflikte, Workspaces können verschlüsselt werden.
ayedo unterstützt Teams mit erprobten Patterns, Tooling und Workshops rund um Helm, Ansible und Polycrate – inklusive maßgeschneiderten Kubernetes-Lösungen.

Warum Helm über Ansible und Polycrate?

Helm ist das Standardwerkzeug, um komplexe Anwendungen auf Kubernetes zu deployen. Viele Teams starten mit:

Sichern der Produktions-Debugging in Kubernetes

Wed, 18 Mar 2026 18:00:00 +0000

TL;DR

Die Sicherung von Produktions-Debugging in Kubernetes erfordert eine Kombination aus minimalen Berechtigungen, kurzlebigen, identitätsgebundenen Anmeldedaten und einem SSH-ähnlichen Handshake-Modell. Der Einsatz eines just-in-time Secure Shell Gateways kann temporären Zugriff sicherstellen und gleichzeitig die Überwachung und Protokollierung verbessern.

Hauptinhalt

In Kubernetes-Umgebungen wird häufig auf breite Zugriffsrechte zurückgegriffen, um das Debugging in Produktionsumgebungen zu erleichtern. Dies geschieht oft durch die Verwendung von Cluster-Admin-Rechten oder langlebigen SSH-Schlüsseln. Diese Ansätze bringen jedoch erhebliche Herausforderungen mit sich, insbesondere in Bezug auf die Auditierung und die Gefahr, dass temporäre Ausnahmen zur Norm werden.

Vom Kapitänsstuhl: Naga Santhosh Reddy Vootukuri

Wed, 18 Mar 2026 16:00:12 +0000

TL;DR

Naga Santhosh Reddy Vootukuri, auch bekannt als Sunny, ist Principal Software Engineering Manager bei Microsoft Azure SQL und Docker Captain. Mit über 17 Jahren Erfahrung in der Entwicklung cloudbasierter Systeme hat er sich als Experte in den Bereichen Cloud Computing , Microservices und Docker etabliert. Seine Leidenschaft für Wissensaustausch und Community-Building zeigt sich in seinen Beiträgen zu Open-Source-Projekten sowie in seinen Veröffentlichungen und Vorträgen.

Hauptinhalt

Naga Santhosh Reddy Vootukuri hat seine Karriere im Bereich der Softwareentwicklung bei Microsoft begonnen und ist mittlerweile ein angesehener Docker Captain. Seine Reise mit Docker begann 2016 in Shanghai, wo er durch einen Vortrag über Docker inspiriert wurde. Der Vortrag verdeutlichte die Vorteile von Docker für Entwickler, insbesondere die Möglichkeit, Probleme wie “Es funktioniert auf meinem Rechner” zu vermeiden. Diese Erkenntnis führte dazu, dass er sich intensiv mit Docker und Docker Desktop beschäftigte, was seine berufliche Entwicklung maßgeblich beeinflusste.

Weekly Backlog KW 13/2026

Wed, 18 Mar 2026 13:45:45 +0000

🧠 Editorial

Diese Woche fühlt sich ein bisschen an wie ein Infrastruktur-Realitätscheck.

Während Deutschland plötzlich Rechenzentren im Industriemaßstab bauen will, diskutiert Europa weiterhin darüber, was „Souveränität" eigentlich bedeutet – und die USA zeigen uns ganz nebenbei, wie schnell Sicherheitsstandards weich werden, wenn Abhängigkeiten zu groß sind.

Spoiler: Es ist alles dasselbe Problem.

Nur aus drei Perspektiven.

📰Tech-News:

Bundesregierung plant massive Ausweitung von Rechenzentren bis 2030

Deutschland will Rechenzentren massiv ausbauen: KI-Kapazitäten sollen sich bis 2030 vervierfachen, klassische Infrastruktur mindestens verdoppeln.

SSH-Sessions und kubectl-Debugging: Polycrate als Operations-Werkzeug

Wed, 18 Mar 2026 00:00:00 +0000

TL;DR

Polycrate ist nicht nur ein Deployment-Tool: Mit polycrate ssh und Block-Actions für kubectl wird es zum zentralen Operations-Werkzeug für Linux-, Windows- und Kubernetes-Umgebungen.
SSH-Sessions laufen direkt aus dem Workspace – mit Inventory-basierter Hostauswahl, Tab-Completion und ohne „Wo liegt das Passwort?“-Fragen. Über die Polycrate API werden alle Sessions revisionssicher geloggt.
Kubernetes-Debugging wird zum wiederholbaren Prozess: polycrate run myapp debug startet Ansible-Playbooks mit kubernetes.core.k8s_log und k8s_info im Container – immer mit der richtigen Kubeconfig aus dem Workspace.
Das löst gleich mehrere Probleme klassischer Setups: kein lokales Ansible, kein kubectl-Chaos, keine herumgeschickten Kubeconfigs, klare Audit-Trails für SSH-Zugriffe und K8s-Operationen.
ayedo unterstützt Sie mit Polycrate, maßgeschneidertem Platform Engineering und Beratungsleistungen dabei, Operations und Compliance gemeinsam zu denken – von der ersten Demo bis zum produktiven Betrieb.

Polycrate als Operations-Werkzeug, nicht nur als Deployment-Helfer

Viele Teams nutzen Ansible und kubectl primär für Provisionierung und Deployments. Der Alltag in Operations sieht aber anders aus:

Kubernetes als Grundlage digitaler Souveränität

Tue, 17 Mar 2026 12:37:00 +0000

Digitale Souveränität wird häufig abstrakt diskutiert, lässt sich technisch jedoch relativ klar eingrenzen: Entscheidend ist, woran Systeme gebunden sind. Sobald Anwendungen von spezifischen Infrastrukturen, proprietären APIs oder nicht standardisierten Betriebsmodellen abhängen, entsteht eine Kopplung, die sich später nur mit erheblichem Aufwand auflösen lässt. In der Praxis bedeutet das, dass viele Architekturen zwar formal portierbar sind, faktisch aber nicht bewegt werden.

Kubernetes adressiert dieses Problem nicht über zusätzliche Abstraktionsebenen im klassischen Sinne, sondern über ein anderes Betriebsmodell. Statt Abläufe zu definieren, wird ein gewünschter Zustand beschrieben, der anschließend kontinuierlich durch das System selbst eingehalten wird. Diese Verschiebung hin zu deklarativen Zustandsdefinitionen ist zentral, weil sie dazu führt, dass sich Systeme unabhängig von ihrer Ausführungsumgebung formulieren lassen.

Kubernetes Image Promoter:

Tue, 17 Mar 2026 10:09:45 +0000

Die unsichtbare Modernisierung kritischer Infrastruktur

Es sind oft nicht die sichtbaren Features, die über die Stabilität moderner Plattformen entscheiden, sondern die unscheinbaren Systeme im Hintergrund – jene Komponenten, die zuverlässig funktionieren müssen, ohne Aufmerksamkeit zu erzeugen. Genau ein solches System steht im Mittelpunkt eines aktuellen Beitrags aus dem Kubernetes Blog: der Kubernetes Image Promoter – und dessen umfassende, bewusst „unsichtbare" Neuentwicklung.

Was dabei besonders bemerkenswert ist: Eine der kritischsten Komponenten der Kubernetes-Release-Pipeline wurde grundlegend neu gebaut – schneller, robuster und schlanker – und idealerweise hat es niemand bemerkt. Genau das war das Ziel.

AI Gateway im Kubernetes-Ökosystem:

Tue, 17 Mar 2026 10:02:54 +0000

Warum die nächste Evolutionsstufe der Plattform bereits begonnen hat

Die Diskussion rund um AI-Infrastruktur verschiebt sich spürbar: Weg von reinen Modellfragen, hin zu der eigentlichen Herausforderung, wie sich KI kontrolliert, sicher und effizient in bestehende Plattformen integrieren lässt. Ein aktueller Beitrag aus dem Kubernetes Blog zur neuen AI Gateway Working Group liefert genau dafür einen aufschlussreichen Impuls – und macht deutlich, dass sich die Cloud-Native Welt bereits auf die nächste Architektur-Generation vorbereitet.

CloudFest 2026

Tue, 17 Mar 2026 09:38:38 +0000

Warum wir dieses Jahr bewusst keinen Stand haben – und mehr erwarten als je zuvor

Das CloudFest ist eines der wenigen Events, bei denen die Bezeichnung „Branchentreff" nicht übertrieben ist. Hier trifft sich nicht irgendein Teil der IT, sondern genau die Schicht, die Infrastruktur baut, betreibt und verkauft. Wer verstehen will, wohin sich Hosting, Cloud und Plattformökonomie entwickeln, kommt an diesem Event nicht vorbei.

Die Entwicklung und Implementierung von Agenten hat sich zu einer zentralen strategischen Priorität für Unternehmen entwickelt. In einer umfassenden Umfrage unter über 800 Entwicklern und Entscheidungsträgern weltweit wurde festgestellt, dass Agenten über experimentelle Ansätze hinaus in eine frühe operative Reife übergehen. Dennoch bleibt die vollständige Integration in produktionsreife Plattformen eine Herausforderung. Sicherheitsbedenken und technische Komplexität sind die größten Hindernisse für die Akzeptanz von Agenten.

Weekly Backlog KW 12/2026

Thu, 12 Mar 2026 11:55:30 +0000

Sovereign Washing, KI-Ermittlungen und die Illusion von Kontrolle

🧠 Editorial

Diese Woche im Backlog: AWS liefert Zertifikate statt Antworten, Deutschland diskutiert KI-Ermittlungen und Europa stellt mal wieder fest, dass es eigentlich alles hat – außer Konsequenz.

Dazu kommt die vielleicht wichtigste Erkenntnis: Digitale Souveränität scheitert selten an Technologie. Fast immer an Entscheidungen.

🚨 Die Tech-News der Woche

AWS European Sovereign Cloud: Zertifiziert souverän – oder souverän zertifiziert?

AWS hat seiner European Sovereign Cloud den nächsten Anstrich verpasst – diesmal nicht mit neuen Features, sondern mit Prüfberichten und Zertifikaten. SOC 2 Type 1, ein C5-Type-1-Attest des BSI und gleich sieben ISO-Zertifizierungen sollen zeigen, dass man es mit europäischer Souveränität ernst meint. 69 Services sind laut AWS bereits unter diesem Setup verfügbar, betrieben durch EU-Personal, organisatorisch getrennt und mit Datenhaltung innerhalb der EU.

Hybrid-Automatisierung: Windows und Linux im selben Polycrate-Workspace

Thu, 12 Mar 2026 00:00:00 +0000

TL;DR

Die meisten Umgebungen sind hybrid: Windows-Server fürs AD, Fileservices und Fachanwendungen, Linux für Web, Datenbanken und Automatisierung – getrennte Automatisierung erhöht Komplexität und Risiko.
Mit Polycrate legst du ein gemeinsames YAML-Inventory mit den Gruppen linux_group und windows_group an, kapselst Linux- und Windows-Playbooks in eigenen Blöcken und steuerst alles aus einem Workspace.
Gemeinsame nicht-sensible Werte (z. B. DNS/NTP) trägst du in den Block-config-Einträgen der workspace.poly – pro Block explizit (im Hybrid-Beispiel dieselben Werte zweimal, ohne YAML-Anker); in .poly-Dateien gibt es keine Jinja-Templating.
Dateien (SSH-Keys, Kubeconfig, …) liegen unter artifacts/secrets/ und werden mitverschlüsselt; sensible Block-Konfiguration wie win_admin_password gehört in secrets.poly (nicht als artifacts/secrets/win_admin_password) – siehe Workspace-Verschlüsselung.
Ein Workflow orchestriert die Hybrid-Wartung: erst Linux-Server patchen, dann Windows-Hosts – alles mit einfachen polycrate workflows run … Befehlen, ohne lokal Ansible, Python oder pywinrm installieren zu müssen.
ayedo unterstützt Teams mit praxiserprobten Hybrid-Workspaces, Workshops und Referenz-Blocks (inklusive PolyHub-Registry), damit Windows- und Linux-Admins gemeinsam auf einer strukturierten, compliance-fähigen Automatisierungsbasis arbeiten.

Politik, Wirtschaft und Medien diskutieren regelmäßig darüber, ob Europa einen technologischen Gegenspieler zu den großen Plattformanbietern aus den USA aufbauen sollte. Milliardenprogramme, Förderprojekte und Initiativen versuchen, eine „europäische Cloud" zu schaffen, die mit den großen globalen Plattformökosystemen konkurrieren kann.

Doch vielleicht ist diese Fragestellung von Anfang an falsch gewesen.

Europa muss keine neuen Hyperscaler bauen. Europa braucht vor allem bessere Cloud-Architekturen.

Souveräne Cloud statt Hyperscaler-Ökosystem:

Mon, 09 Mar 2026 12:50:11 +0000

Europas verpasste Chance – und warum sie noch nicht verloren ist

Die Cloud hat sich in den vergangenen zehn Jahren zur zentralen Infrastruktur der digitalen Wirtschaft entwickelt. Anwendungen, Datenplattformen, Entwicklungsumgebungen und zunehmend auch KI-Systeme werden heute überwiegend auf wenigen globalen Plattformen betrieben.

Die Marktstruktur ist dabei bemerkenswert eindeutig. Ein Großteil der digitalen Infrastruktur westlicher Unternehmen läuft auf Plattformen weniger Hyperscaler. Diese Anbieter haben enorme technische Ökosysteme geschaffen – mit Tausenden von Services, globaler Infrastruktur und einer beeindruckenden Innovationsgeschwindigkeit.

Der Exit-Test:

Mon, 09 Mar 2026 12:43:39 +0000

Mon, 09 Mar 2026 12:38:57 +0000

Warum Europas Unternehmen ihre Infrastrukturstrategie überdenken müssen

Künstliche Intelligenz verändert derzeit nicht nur Produkte, Prozesse und Geschäftsmodelle. Sie verändert auch die Struktur digitaler Abhängigkeiten. Während viele Unternehmen noch damit beschäftigt sind, klassische Cloud-Lock-in-Risiken zu verstehen, entsteht bereits eine neue Form technologischer Bindung – tiefer, komplexer und langfristig schwerer aufzulösen.

Der Grund liegt darin, dass KI nicht einfach eine zusätzliche Softwarekomponente ist. KI-Systeme greifen tief in Datenarchitekturen, Entwicklungsprozesse und Plattformstrukturen ein. Wer KI integriert, verändert damit automatisch seine Infrastruktur.

Compliance-by-Design statt Audit-Theater:

Mon, 09 Mar 2026 12:35:35 +0000

Warum Regulierung eine Architekturfrage ist

Kaum ein Thema sorgt in der IT derzeit für so viel Unruhe wie neue regulatorische Anforderungen. DSGVO, NIS-2, DORA, Cyber Resilience Act oder Data Act erweitern den Rahmen, innerhalb dessen digitale Systeme betrieben werden müssen. Für viele Unternehmen wirkt diese Entwicklung zunächst wie eine zusätzliche Belastung. Neue Dokumentationspflichten, zusätzliche Audits, neue Prozesse – all das scheint Innovation zu bremsen.

Doch dieser Blick greift zu kurz.

Warum Hetzner für viele Workloads die strategisch klügere Cloud ist

Mon, 09 Mar 2026 12:31:13 +0000

Die Cloud-Debatte wird seit Jahren von einer simplen Erzählung dominiert: Wer moderne Software betreiben will, kommt an den großen Hyperscalern nicht vorbei. Ihre Plattformen gelten als alternativlos, ihre Funktionsvielfalt als Maßstab für die gesamte Branche. Für viele Unternehmen scheint die Entscheidung daher bereits gefallen, bevor sie überhaupt gestellt wird.

Doch dieses Bild beginnt zu bröckeln.

Immer mehr Organisationen stellen fest, dass der tatsächliche Bedarf vieler Anwendungen deutlich weniger spektakulär ist als die Marketingfolien der großen Plattformen vermuten lassen. Nicht jede Software braucht ein globales Plattform-Ökosystem mit hunderten Spezialdiensten. Viele Anwendungen benötigen vor allem eines: stabile Infrastruktur, nachvollziehbare Kosten, verlässliche Performance und die Möglichkeit, Systeme ohne strukturelle Abhängigkeiten zu betreiben.

Open Source ist nicht gleich Souveränität:

Mon, 09 Mar 2026 12:28:59 +0000

Warum Lizenzfreiheit allein keine Kontrolle schafft

In der europäischen Digitaldebatte gilt Open Source häufig als Synonym für digitale Souveränität. Der Gedanke dahinter ist nachvollziehbar: Wenn der Quellcode offen ist, kann jeder ihn prüfen, verändern und unabhängig betreiben. Abhängigkeiten von einzelnen Herstellern scheinen damit automatisch reduziert.

Diese Gleichsetzung ist jedoch zu einfach.

Open Source kann ein wichtiger Baustein für souveräne IT sein. Aber Open Source allein garantiert weder Kontrolle noch Unabhängigkeit. Zwischen frei verfügbarem Code und tatsächlich souveränem Betrieb liegt eine große Lücke.

Multi-Cloud ist nicht automatisch souverän:

Mon, 09 Mar 2026 12:24:58 +0000

Warum zwei Clouds noch keine Unabhängigkeit bedeuten

In vielen Unternehmen gilt Multi-Cloud inzwischen als Abkürzung für digitale Souveränität. Wer Workloads auf mehrere Anbieter verteilt, so die verbreitete Annahme, reduziert automatisch Abhängigkeiten und gewinnt Kontrolle zurück. Das klingt plausibel. In der Praxis ist es oft ein Missverständnis.

Denn Multi-Cloud und souveräne Cloud beschreiben nicht dasselbe. Das eine ist zunächst ein Architekturmodell. Das andere ist ein Anspruch an Kontrolle, Portabilität, Rechtsklarheit und tatsächliche Handlungsfähigkeit. Wer beides gleichsetzt, verwechselt technische Verteilung mit strategischer Unabhängigkeit.

Vendor Lock-in in der KI-Ära:

Mon, 09 Mar 2026 12:20:36 +0000

Warum Abhängigkeiten gefährlicher werden

Cloud-Lock-in ist kein neues Thema. Seit Jahren diskutieren Unternehmen darüber, wie schwer es sein kann, Infrastruktur, Daten oder Anwendungen von einem Anbieter zu einem anderen zu migrieren. Mit dem Aufstieg von KI-Plattformen bekommt dieses Problem jedoch eine neue Dimension.

Was früher ein technisches Architekturproblem war, wird zunehmend zu einer strategischen Abhängigkeit.

Vom Infrastruktur-Lock-in zum KI-Lock-in

Klassischer Cloud-Lock-in entsteht meist durch proprietäre Infrastrukturservices: Datenbanken, Messaging-Systeme, Identity-Services oder serverlose Plattformen, die stark an einen Anbieter gebunden sind. Wer solche Dienste intensiv nutzt, muss bei einem Wechsel Anwendungen umbauen, Daten migrieren und Betriebsprozesse anpassen.

Cloud-Strategien im Wandel: Zwischen Hyperscalern und Souveränität

Mon, 09 Mar 2026 12:00:27 +0000

Der Cloud-Markt tritt in eine neue Phase ein. Lange war die Rechnung einfach: Wer skalieren wollte, ging zu den Hyperscalern. Wer global verfügbar sein musste, nahm AWS, Microsoft oder Google. Wer Innovation brauchte, kaufte sie als Service ein. Das war effizient, bequem und betriebswirtschaftlich oft plausibel.

Diese Logik trägt in der KI-Ära nur noch teilweise.

Denn mit generativer KI steigt nicht nur der Bedarf an Rechenleistung. Es steigt auch die Sensibilität der Daten, die in Cloud-Systeme fließen. Prompts enthalten heute nicht selten Quellcode, interne Strategiepapiere, Ausschreibungen, Verträge, Gesundheitsdaten oder sicherheitsrelevante Informationen. Öffentliche Stellen und regulierte Unternehmen behandeln diese Daten nicht mehr als Nebensache, sondern als Governance-Frage. Nationale Cyberbehörden weisen inzwischen ausdrücklich darauf hin, dass Eingaben in GenAI-Systeme für den Betreiber sichtbar sind und zusätzliche Kontrollen gegen Datenabfluss und Datenschutzverletzungen nötig werden.

Authentifizierung von Registry-Spiegeln mit Kubernetes-Secrets

Mon, 09 Mar 2026 11:00:00 +0000

TL;DR

Mon, 09 Mar 2026 09:32:48 +0000

TL;DR

Relationale Datenbanken zwingen Entwickler, Daten in starre Tabellen zu pressen. MongoDB sprengt dieses Korsett. Es speichert Daten so, wie moderne Anwendungen sie nutzen: Als flexible JSON-Dokumente. Während Cloud-Provider wie AWS mit “DocumentDB” oft nur veraltete Emulationen anbieten, die Features vermissen lassen, liefert eine echte, selbst betriebene MongoDB-Instanz die volle Power: Neueste Features, echte BSON-Performance und die Freiheit, Datenstrukturen agil anzupassen, ohne die Datenbank für Stunden zu sperren (“Schema Migration”).

Windows-Automatisierung mit Polycrate: Ansible und WinRM ohne Schmerzen

Mon, 09 Mar 2026 00:00:00 +0000

TL;DR

Du richtest WinRM einmal sauber mit HTTPS, Zertifikat und Firewall-Regeln ein und hast danach eine stabile Basis für Ansible-Automatisierung auf Windows-Servern.
Mit Polycrate läuft Ansible inklusive aller WinRM- und Python-Abhängigkeiten im Container – kein pywinrm-Chaos, keine lokalen Installationen, keine Versionsdiskussionen im Team.
Windows-Automatisierung ist im Polycrate-Ansible-Image schon enthalten: u. a. die Collection ansible.windows (z. B. win_service, win_updates), pywinrm und das passende Ansible-Bundle – ohne eigenes Dockerfile, ohne manuelles ansible-galaxy-Nachinstallieren für den üblichen Einsatz. Du konfigurierst nur noch Workspace, Inventory und Playbooks.
Ein eigener Polycrate-Block für Windows bildet deine wiederverwendbare „Windows-Toolbox“: Dienste verwalten, Features installieren, Registry anpassen, Software verteilen, Patches einspielen – alles als klar strukturierte Actions.
Passwörter und andere Secrets landen in secrets.poly und werden über die eingebaute Workspace-Verschlüsselung mit age abgesichert – nicht im inventory.yml.
ayedo unterstützt Windows-Teams mit praxisnahen Automatisierungs-Blueprints, Polycrate-Implementierung und einem fokussierten Windows-Automatisierung Workshop – von WinRM-Basics bis zu skalierbarem Patch-Management.

Warum Windows-Admins sich mit Polycrate + Ansible beschäftigen sollten

Viele Windows-Admins schauen skeptisch auf Ansible:

Automatische Updates und Backups als Polycrate-Workflows

Sun, 08 Mar 2026 00:00:00 +0000

TL;DR

Du baust einen wiederverwendbaren Polycrate-Workflow, der auf deinen Linux-Servern automatisch backup → update → verify ausführt – inklusive Rollback über Ansible block/rescue.
Backups laufen als pg_dump + tar + Upload nach S3 mit rclone (S3-kompatibles Object Storage), Updates via apt upgrade plus Service-Restart und Health-Checks, Verifikation über Systemd-Status und HTTP-Response.
Polycrate-Workflows geben deinen Ansible-Actions einen Namen, eine Reihenfolge und eine Dokumentation – statt lose verteilte Playbooks und README-Dateien.
Alles läuft im Container: Kein lokales Python-/Ansible-Chaos, konsistente Toolchain auf jeder Admin-Workstation, Workspaces sind bei Bedarf komplett verschlüsselt.
ayedo unterstützt Teams dabei, solche Betriebsprozesse als Code zu etablieren – von der ersten Block-Struktur bis zu unternehmensweiten, geteilten Workflows und Operations-Automatisierung Demos.

Polycrate-Workflows: Betriebsprozesse statt CI/CD-Pipelines

Wenn du „Workflow“ hörst, denkst du vielleicht an GitHub Actions oder GitLab CI. Polycrate-Workflows sind etwas anderes:

Viele Server, eine Wahrheit: Multi-Server-Management mit Polycrate-Inventories

Sat, 07 Mar 2026 00:00:00 +0000

TL;DR

Ein einzelner Server ist mit Ansible schnell im Griff – aber sobald 10, 50 oder 200 Hosts dazukommen, wird das Inventory zum kritischen Skalierungsfaktor. Polycrate erzwingt ein zentrales, YAML-basiertes Inventory pro Workspace und verhindert damit Wildwuchs.
Workspaces können Sie wie Umgebungen denken: Sie bündeln logisch zusammengehörige Infrastruktur. Haben Sie z. B. 100 Webserver (10 Dev, 10 Test, 80 Prod), legen Sie idealerweise drei Workspaces an – etwa web-dev, web-test, web-prod – und listen im jeweiligen inventory.yml nur die Hosts dieser Umgebung. Gemeinsame Automatisierung teilen Sie über Blöcke (Block Sharing), nicht über ein einziges Riesen-Inventory.
In Polycrate liegt inventory.yml im Workspace-Root und ist die einzige Wahrheit für alle Blöcke und Actions dieses Workspaces. Ein schlankes Ansible-Inventory (z. B. all.vars, übersichtliche Gruppen) strukturiert Hosts für Playbooks innerhalb dieser Umgebung – Polycrate selbst hat keine eigenen Parameter für Ansible-Tags oder zur Auswahl von Inventory-Gruppen; polycrate run … bezieht sich immer auf den gesamten Workspace.
Komplexe Konditionalität über Ansible-Tags oder ein überladenes Inventory abzubilden, ist nicht Best Practice. Dasselbe sollten Sie über Workspace- und Block-Segmentierung sowie Konfiguration der Block-Instanzen abbilden (siehe Best Practices).
Polycrate führt Ansible immer im Container aus und löst damit das typische Dependency-Chaos (Python-Versionen, Ansible-Version, Module). Einmal definierte Workspaces und Inventories sind im gesamten Team reproduzierbar nutzbar.
In ayedos Multi-Server-Workshops zeigen wir Admin-Teams in Formaten wie Platform Architecture und Platform Operations, wie sie bestehende Ansible-Automatisierung in Polycrate überführen, Inventories konsolidieren und Flotten-Updates sicher und nachvollziehbar betreiben.

Vom Einzelserver zur Flotte: Das eigentliche Skalierungsproblem

Solange Sie nur einen oder zwei Linux-Server verwalten, fühlt sich Ansible oft noch wie ein besseres SSH an: ein Playbook, ein Host, fertig.

Frauen in der KI feiern: 3 Fragen an Cecilia Liu zur Leitung von Dockers MCP-Strategie

Fri, 06 Mar 2026 12:59:30 +0000

TL;DR

Cecilia Liu, Senior Product Manager bei Docker, leitet die Strategie für Docker’s MCP-Lösungen, die darauf abzielen, Entwicklern und Unternehmen eine sichere und skalierbare Nutzung von AI-Tools zu ermöglichen. Ihre Vision fokussiert sich auf die Verbesserung der Benutzerfreundlichkeit, die Unterstützung von Entwicklern bei der Integration von MCP-Servern und die Gewährleistung von Sicherheitsstandards in der Bereitstellung.

Hauptinhalt

Cecilia Liu verantwortet die Produktmanagementstrategie für Docker’s MCP (Machine Control Platform) Lösungen, die speziell für die sichere und skalierbare Ausführung von MCP-Servern konzipiert sind. Mit ihrem technischen Hintergrund in AI-Frameworks und einem MBA von der NYU Stern bringt sie eine fundierte Perspektive in die Entwicklung von Lösungen, die sowohl für Unternehmen als auch für individuelle Entwickler von Bedeutung sind.

KubeCon + CloudNativeCon Europa 2026 Co-located Event Deep Dive: KeycloakCon

Fri, 06 Mar 2026 12:00:00 +0000

TL;DR

KeycloakCon Europe 2026 ist ein spezialisiertes Event, das sich auf Identitäts- und Zugriffsmanagement (IAM) in cloud-nativen Architekturen konzentriert. Es bietet eine Plattform für Fachleute, um Herausforderungen und Lösungen im Bereich der Authentifizierung und Autorisierung zu diskutieren, insbesondere im Kontext von Multi-Cluster-Plattformen und agentenbasierten Systemen.

Hauptinhalt

KeycloakCon Europe 2026 findet im Rahmen von KubeCon + CloudNativeCon Europa statt und zielt darauf ab, die wachsenden Anforderungen an das Identitäts- und Zugriffsmanagement in modernen verteilten Systemen zu adressieren. Da cloud-native Architekturen immer komplexer werden und über mehrere Cluster, Dienste und Vertrauensdomänen hinweg operieren, wird IAM zunehmend als grundlegende Infrastruktur angesehen. Das Event bringt Praktiker, Maintainer und Branchenführer zusammen, um aktuelle Herausforderungen zu besprechen und bewährte Verfahren auszutauschen.

Infrastruktur-Drift erkennen: Wenn die Realität nicht mehr zum Code passt

Fri, 06 Mar 2026 11:20:20 +0000

In einer perfekten Welt ist Ihr Infrastructure as Code (IaC) Repository die absolute „Source of Truth". Jede Änderung an Load Balancern, DNS-Einträgen oder Firewall-Regeln wird über Git-Commits und automatisierte Pipelines gesteuert. In der Realität sieht es oft anders aus: Ein Administrator behebt ein dringendes Problem mitten in der Nacht direkt über die Cloud-Konsole, oder ein automatisches Update verändert eine Konfiguration im Hintergrund.

Diese Abweichung zwischen dem definierten Soll-Zustand (im Code) und dem tatsächlichen Ist-Zustand (in der Cloud) nennen wir Infrastruktur-Drift. Unentdeckter Drift ist einer der größten Risikofaktoren für die Stabilität und Sicherheit moderner Plattformen.

European Tech Map:

Fri, 06 Mar 2026 11:14:08 +0000

Wie eine Plattform europäische Technologie sichtbar macht

Digitale Souveränität gehört inzwischen zu den zentralen Themen europäischer Technologiepolitik. In politischen Strategien, Wirtschaftsgremien und IT-Abteilungen wird immer häufiger diskutiert, wie Europa seine digitale Infrastruktur unabhängiger gestalten kann.

Dabei fällt in vielen Diskussionen ein Argument besonders häufig: Für viele Technologien gebe es schlicht keine europäischen Alternativen.

Wer sich intensiver mit dem europäischen Tech-Ökosystem beschäftigt, erkennt jedoch schnell, dass diese Aussage nur einen Teil der Realität beschreibt. In vielen Bereichen existieren längst leistungsfähige Anbieter aus Europa – von Cloud-Infrastruktur über Kollaborationssoftware bis hin zu Cybersecurity- oder KI-Plattformen.

Vom Modell zum Service: MLOps-Pipelines mit ArgoCD und Kubeflow

Fri, 06 Mar 2026 10:49:43 +0000

In der traditionellen Softwareentwicklung hat sich CI/CD (Continuous Integration / Continuous Deployment) längst als Standard etabliert. Doch in der Welt der Künstlichen Intelligenz reicht das nicht aus. KI-Modelle sind keine statischen Artefakte; sie basieren auf Code, Daten und Parametern, die sich ständig ändern. Ohne eine automatisierte Pipeline - bekannt als MLOps - landen viele Modelle als „Experimente" in der Schublade, anstatt echten Geschäftswert zu liefern.

Bei loopback.cloud setzen wir auf die Symbiose aus Kubeflow für die Orchestrierung des Trainings und ArgoCD für das moderne GitOps-Deployment. So transformieren wir den KI-Lifecycle von manueller Bastelei in einen industriellen Prozess.

Vector Databases auf K8s: Das Gedächtnis für Ihre Agentic AI

Fri, 06 Mar 2026 10:43:07 +0000

Ein Large Language Model (LLM) ohne Zugriff auf aktuelle Unternehmensdaten ist wie ein brillanter Professor ohne Bibliothek: Er hat das Wissen der Welt, kennt aber nicht Ihre spezifischen Projekte, Dokumente oder Kundenhistorien. Um KI-Agenten wirklich nützlich zu machen, nutzen wir Retrieval Augmented Generation (RAG). Das Herzstück dieser Architektur ist die Vektor-Datenbank.

Doch der Betrieb von Systemen wie Milvus, Qdrant oder Weaviate in Kubernetes stellt DevOps-Teams vor neue Herausforderungen. Es geht nicht nur um das Speichern von Daten, sondern um die Bereitstellung eines performanten, persistenten “Langzeitgedächtnisses” für KI-Agenten.

Datensicherheit für KI: Verschlüsselte Datensätze in Multi-Tenant Clustern

Fri, 06 Mar 2026 10:37:01 +0000

In der Goldgräberstimmung rund um Künstliche Intelligenz wird ein kritischer Aspekt oft vernachlässigt: Die Sicherheit der zugrunde liegenden Daten. Wenn Unternehmen KI-Modelle in Shared-Infrastrukturen (Multi-Tenant Clustern) trainieren oder betreiben, entstehen völlig neue Angriffsvektoren. Ein kompromittiertes Modell oder ein bösartiger Container darf niemals in der Lage sein, auf die Trainingsdaten oder IP-Assets anderer Abteilungen oder Kunden zuzugreifen.

Besonders im Hinblick auf die NIS-2-Richtlinie und den EU AI Act wird Datensicherheit 2026 von einer „Nice-to-have"-Option zur gesetzlichen Pflicht für den Mittelstand.

Infrastructure as Code für KI: Cluster-Konfiguration für Heavy Workloads

Fri, 06 Mar 2026 10:32:00 +0000

Wer Large Language Models (LLMs) oder komplexe Deep-Learning-Pipelines in Produktion bringt, merkt schnell: Ein Standard-Kubernetes Cluster stößt bei diesen “Heavy Workloads” sofort an seine Grenzen. Wenn Terabytes an Gewichten in den VRAM geladen werden müssen und Milliarden von Checkpoints über das Netzwerk fließen, entscheiden Nuancen in der Infrastruktur-Konfiguration über Erfolg oder ein technisches Desaster.

Für echte Performance-Gewinne reicht es nicht aus, einfach nur GPUs in die Nodes zu stecken. Wir müssen die Hardware-Abstraktion von Kubernetes durchbrechen und den Stack mittels Infrastructure as Code (IaC) bis auf Kernel-Ebene optimieren.

GPU-Slicing & Kubernetes: Wie man teure KI-Ressourcen effizient teilt

Fri, 06 Mar 2026 10:24:36 +0000

In der modernen IT-Infrastruktur ist die GPU zur neuen CPU geworden. Ob Large Language Models (LLMs), Computer Vision oder komplexe Datenanalysen - der Hunger nach Rechenleistung auf Grafikkarten ist im Mittelstand massiv gestiegen. Doch während CPUs seit Jahrzehnten effizient virtualisiert und geteilt werden, stellen GPUs Plattform-Ingenieure oft vor ein Dilemma: Eine High-End-Grafikkarte (wie eine NVIDIA H100 oder A100) ist für einen einzelnen Microservice oft überdimensioniert, gleichzeitig aber zu teuer, um sie im Leerlauf zu lassen.

Docker-Stacks auf Linux-Servern mit Polycrate verwalten

Fri, 06 Mar 2026 00:00:00 +0000

TL;DR

Docker-Compose ist für viele Linux-Server-Setups weiterhin eine sinnvolle, pragmatische Lösung – besonders wenn Sie einzelne Hosts oder kleine Gruppen verwalten und kein Kubernetes einführen wollen.
Mit Polycrate packen Sie Ihren Docker-Compose-Stack in einen wiederverwendbaren Block: block.poly für Konfiguration, docker-compose.yml.j2 als Template, Ansible-Playbook als Action – alles sauber strukturiert und teamfähig; der Block folgt derselben Registry-Konvention wie im Beitrag Nginx und Let’s Encrypt als wiederverwendbarer Polycrate-Block (registry.acme-corp.com/infra/…, Version per from: …:0.1.0 im Workspace, Veröffentlichung mit polycrate blocks push …).
Geheime Werte liegen nicht in der docker-compose.yml und nicht in der lesbaren workspace.poly, sondern in secrets.poly im gleichen YAML-Format wie workspace.poly (Merge zur Laufzeit); die Datei wird im Rahmen der Workspace-Verschlüsselung geschützt – im Template referenzieren Sie block.config.db_password nach dem Merge.
Rolling Updates und (nahezu) Zero-Downtime-Deployments auf Linux-Servern werden mit Ansible community.docker.docker_compose, Health-Checks und Polycrate-Actions reproduzierbar und für Kolleg:innen einfach ausführbar.
ayedo unterstützt Sie mit Polycrate, Best Practices und individuellen Docker-Automatisierungslösungen – von lokalem Docker-Compose bis hin zu kompletten Plattform-Setups.

Docker-Compose auf Linux-Servern: Wann es Sinn macht

Nicht jedes Team braucht sofort Kubernetes. Viele System-Admins betreiben heute:

API Governance in Kubernetes:

Thu, 05 Mar 2026 14:06:14 +0000

Warum stabile Schnittstellen für das Ökosystem entscheidend sind

Kubernetes ist heute weit mehr als ein Container -Orchestrator. Rund um die Plattform ist ein riesiges Ökosystem entstanden – mit Tools, Erweiterungen, Plattformlösungen und Automatisierungen, die alle auf denselben Grundlagen aufbauen. Diese Grundlage sind APIs. Sie bilden die Schnittstellen, über die Cluster verwaltet, Ressourcen definiert und Komponenten miteinander kommunizieren.

Je größer dieses Ökosystem wird, desto wichtiger wird eine zentrale Frage: Wie lässt sich ein System mit tausenden Mitwirkenden so weiterentwickeln, dass Innovation möglich bleibt, ohne bestehende Nutzer zu gefährden? Genau an dieser Stelle kommt ein Bereich innerhalb der Kubernetes-Community ins Spiel, der oft im Hintergrund arbeitet, aber eine zentrale Rolle für die Stabilität des gesamten Projekts spielt: API Governance.

Ende von Ingress-NGINX: Warum eine einfache Migration oft nicht reicht

Thu, 05 Mar 2026 13:33:10 +0000

Der März hat begonnen – und damit auch der letzte Abschnitt für eine der meistgenutzten Komponenten im Kubernetes-Netzwerkstack: Ingress-NGINX wird in diesem Monat offiziell eingestellt.

Für viele Unternehmen kommt dieser Zeitpunkt überraschend nah. In unzähligen Kubernetes-Clustern läuft Ingress-NGINX seit Jahren stabil und zuverlässig im Hintergrund. Genau das macht die Situation jedoch trügerisch. Denn viele Setups basieren auf impliziten Verhaltensweisen und historischen Defaults, die bei einer Migration zur Gateway API nicht automatisch übernommen werden.

Die große Migration: Warum jede AI-Plattform auf Kubernetes konvergiert

Thu, 05 Mar 2026 12:00:00 +0000

TL;DR

Kubernetes hat sich von einer Plattform für stateless Webanwendungen zu einer zentralen Infrastruktur für die Ausführung von KI-Workloads gewandelt. 66 % der Organisationen, die generative KI-Modelle hosten, nutzen Kubernetes für ihre Inferenzlasten. Die Konvergenz von Datenverarbeitung, Modelltraining und Inferenz auf Kubernetes vereinfacht die Betriebsabläufe und ermöglicht eine effiziente Ressourcennutzung.

Hauptinhalt

Die Entwicklung von Kubernetes über das letzte Jahrzehnt hat eine fundamentale Transformation durchlaufen. Ursprünglich konzipiert, um die Bereitstellung von Microservices zu erleichtern, wird Kubernetes mittlerweile als zentrale Plattform für eine Vielzahl von Anwendungen genutzt, die über einfache stateless Webdienste hinausgehen. Die CNCF-Umfrage von Januar 2026 zeigt, dass 82 % der Container -Nutzer Kubernetes in der Produktion einsetzen, während 66 % der Organisationen, die generative KI-Modelle betreiben, Kubernetes für Inferenzlasten nutzen.

Weekly Backlog KW 11/2026

Thu, 05 Mar 2026 09:03:02 +0000

🧠 Editorial

Schleswig-Holstein. Der echte Norden. schmeißt Microsoft aus der Verwaltung. Nextcloud wird im c’t-Praxistest plötzlich zum ernsthaften Arbeitsplatz-Tool. Die Schwarz Gruppe baut eine europäische Cloud mit Hyperscaler-Ambitionen. Und parallel diskutiert Europa darüber, eigene Social-Plattformen zu entwickeln.

Das Spannende daran: Die Diskussion verschiebt sich.

Lange ging es in der Souveränitätsdebatte vor allem um eine Frage: Gibt es überhaupt Alternativen zu den großen Plattformen?

Die Antwort darauf kennen wir inzwischen.

Nextcloud, OpenDesk, europäische Clouds, spezialisierte Plattformen – technisch existieren viele Optionen längst. Sie sind nicht perfekt, aber sie funktionieren.

Nginx und Let's Encrypt als wiederverwendbarer Polycrate-Block

Thu, 05 Mar 2026 00:00:00 +0000

TL;DR

Du baust einen wiederverwendbaren Polycrate-Block, der Nginx und Let’s Encrypt (via community.general.certbot) automatisiert auf einem Linux-Server bereitstellt – inkl. generischer nginx.conf als Jinja2-Template.
Der Block parametrisiert Domain, Kontakt-E-Mail und Upstream-Port über block.config.* und kann in jedem Workspace mit anderen Werten eingesetzt werden – ohne Code-Kopie oder Wiki-Bastelei.
Polycrate containerisiert Ansible und die gesamte Toolchain: kein lokales Ansible, kein Python-Chaos, keine individuellen Setups – der gleiche Block läuft auf jeder Developer-Workstation identisch.
Über eine Registry (from: cargo.ayedo.cloud/ayedo/infra/nginx-letsencrypt:1.0.0 in workspace.poly) teilst du den Block mit Kolleg:innen: vor dem Push muss name in der block.poly die volle OCI-Referenz ohne Tag sein; polycrate blocks push verwendet genau diesen Namen plus version als Tag – Sharing statt Screenshots.
ayedo unterstützt Teams dabei, solche standardisierten, teilbaren Automationsblöcke aufzubauen – von der Konzeption der Block-Struktur bis zum Betrieb einer Registry und Integration in bestehende Prozesse.

Weekly Backlog KW 10/2026

Tue, 03 Mar 2026 11:49:27 +0000

🧠 Editorial: Cloud ist politisch. Punkt.

Diese Ausgabe dreht sich um ein Thema, das viele gern technisch verpacken: digitale Souveränität.

Aber diese Woche hat ziemlich klar gezeigt, dass das kein Whitepaper-Begriff ist.

Microsoft eröffnet in München ein „Sovereignty"-Studio – bleibt aber ein US-Konzern im US-Rechtsraum.
Zwei AWS-Rechenzentren in den VAE werden von Drohnen getroffen – Availability Zones helfen nicht gegen Geopolitik.
Die Bundesregierung plant eine zentrale Bürger-App – die entscheidende Frage ist: auf welcher Infrastruktur?
Schulen in Sachsen-Anhalt zeigen, dass Linux im Alltag funktioniert.
Ein Hosting-Anbieter betreibt seit Jahren eigene Server in Deutschland – ohne Hyperscaler im Hintergrund.

Das ist kein Kulturkampf „USA vs. Europa". Es geht um Kontrolle, Rechtsräume, Abhängigkeiten und physische Realität.

Blöcke, Actions und Workspaces: Das Baukasten-Prinzip von Polycrate

Tue, 03 Mar 2026 00:00:00 +0000

TL;DR

Polycrate strukturiert Ansible-Automatisierung in drei Bausteine: Blöcke, Actions und Workspaces – damit verschwindet der klassische Playbook-Wildwuchs und Automatisierung wird wiederfindbar und teilbar.
Blöcke bringen ihre eigene Konfiguration, Playbooks, Templates und Artefakte mit. Workspace-Konfiguration überschreibt Block-Defaults per Deep-Merge – ideal für wiederverwendbare Standards plus projektspezifische Anpassungen.
Alle Blöcke laufen in Containern: Kein lokales Ansible-Setup, keine Python-Versionsturbulenzen und eine einheitliche Toolchain für das ganze Team. Distribution erfolgt über eine OCI-Registry und den PolyHub.
Im Vergleich zu Ansible Roles sind Polycrate-Blöcke selbst-enthaltend, versionierbar, über Registries teilbar und bringen einen klaren Ausführungs- und Konfigurationsrahmen mit – inklusive Workflows für komplexere Abläufe.
ayedo entwickelt Polycrate und stellt mit offiziellen Block-Kollektionen im PolyHub sowie Dokumentation zu Polycrate-Blöcken eine praxisnahe Plattform zur Verfügung, die von einzelnen Admins bis zu großen Platform-Teams skalierbar ist.

Block, Action, Workspace: das Grundprinzip

Polycrate baut auf Ansible auf, gibt der Automatisierung aber eine klarere Form. Drei Konzepte stehen im Zentrum:

Polycrate API 0.14.0 released: Domains, DNS, GitLab Auto-Create

Mon, 02 Mar 2026 14:00:00 +0000

Polycrate API 0.14.0 fuehrt Domains und DNS Management als First-Class ManagedObjects ein, erweitert Workspaces um GitLab-Projekt Auto-Create und behebt einen kritischen Bug beim Operator Global Endpoint Monitor.

Domains & DNS

Domains repraesentieren verwaltete Domain-Namen als eigenstaendige Ressourcen. Die Integration mit dem CentralNic Registrar (RRPProxy) ermoeglicht Registrierung, Status-Abfrage und Portfolio-Import.

DNS Management basiert auf PowerDNS. DNSZonen und Records werden synchron mit der PowerDNS-API verwaltet — jede Aenderung wird sofort uebernommen.

Thu, 26 Feb 2026 08:44:46 +0000

Die Cloud-Native-Transformation ist in vollem Gange, doch die Realität in deutschen Rechenzentren sieht oft anders aus: Neben hochmodernen Kubernetes-Clustern verrichten dedizierte Bare-Metal-Server, Core-Switche und unterbrechungsfreie Stromversorgungen (USV) ihren Dienst. Diese Komponenten sind für den Betrieb kritisch, entziehen sich aber oft dem modernen Observability-Stack, da sie keine Prometheus-Metriken nativ über HTTP/OpenMetrics liefern.

Im Jahr 2026 ist die lückenlose Überwachung dieser “Non-Cloud-Native”-Assets kein Luxus mehr, sondern unter regulatorischen Anforderungen wie NIS-2 und DORA zwingend erforderlich. Wer Hardware-Ausfälle oder Netzwerk-Engpässe erst bemerkt, wenn die Applikation steht, gefährdet seine digitale Souveränität. Die Lösung liegt in der Überbrückung der Protokollwelten: Durch den Einsatz spezialisierter Exporter integrieren wir SNMP- und IPMI-Daten nahtlos in den ayedo Managed Stack aus Prometheus und Grafana.

K3s als strategischer Standard für dezentrale Cloud-Native Infrastrukturen

Thu, 26 Feb 2026 08:39:17 +0000

Die Digitalisierung der Fertigung und die Vernetzung dezentraler Standorte stellen den deutschen Mittelstand vor eine fundamentale Herausforderung: Full-Scale KubernetesCluster sind für die Ressourcenbeschränkungen in Fabrikhallen oder Außenstellen oft zu schwerfällig. Werden Applikationen jedoch manuell oder über proprietäre Altsysteme verwaltet, entstehen isolierte IT-Inseln, die weder skalierbar noch sicher sind.

Im Kontext des Jahres 2026, geprägt durch die strikten Anforderungen von NIS-2 und den Bedarf an Echtzeit-Datenverarbeitung für Agentic AI an der Edge, ist eine einheitliche Orchestrierung unumgänglich. Die Lösung liegt in einer radikalen Reduktion der Komplexität bei voller Wahrung der Kubernetes-API-Kompatibilität. K3s hat sich hierbei als der dezentrale Standard etabliert, um Cloud-Native Workloads effizient und sicher direkt am Entstehungsort der Daten zu betreiben.

Secrets Management: Warum Vaultwarden die Brücke zwischen Dev und Ops schlägt

Thu, 26 Feb 2026 08:33:30 +0000

In der modernen Softwareentwicklung ist die ungesicherte Handhabung von Zugangsdaten - sogenannte “Hardcoded Secrets” (static secrets) in Git-Repositories - eines der kritischsten Sicherheitsrisiken. Mit der Verschärfung regulatorischer Anforderungen im Jahr 2026, insbesondere durch NIS-2 und DORA, ist der Schutz von API-Keys, Datenbank-Passwörtern und SSH-Zertifikaten nicht mehr nur eine Best Practice, sondern eine zwingende Compliance -Vorgabe. Unternehmen im Mittelstand stehen vor der Herausforderung, Sicherheit zu gewährleisten, ohne die Agilität ihrer DevOps -Teams zu bremsen.

Distributed Tracing 2026: Mit OpenTelemetry (OTel) Performance-Flaschenhälse eliminieren

Thu, 26 Feb 2026 08:26:48 +0000

Die Komplexität moderner Microservice-Architekturen hat im Jahr 2026 einen Punkt erreicht, an dem klassisches Monitoring an seine Grenzen stößt. Während Metriken uns sagen, dass ein System langsam ist, und Logs uns verraten, warum eine einzelne Instanz einen Fehler wirft, bleibt die Kausalität über Service-Grenzen hinweg oft im Dunkeln. In einer Ära, in der Regulatorien wie NIS-2 und DORA nicht nur Sicherheit, sondern auch die Resilienz und Wiederherstellbarkeit von IT-Systemen fordern, ist blinde Fehlersuche kein tragbares Geschäftsrisiko mehr.

Open WebUI + Docker Model Runner: Selbstgehostete Modelle, keine Konfiguration

Wed, 25 Feb 2026 14:37:33 +0000

TL;DR

Die Integration von Docker Model Runner und Open WebUI ermöglicht eine einfache und konfigurationsfreie Nutzung selbstgehosteter Modelle. Entwickler können innerhalb weniger Minuten mit der Arbeit beginnen, indem sie Docker Model Runner aktivieren und Open WebUI starten, ohne zusätzliche Einstellungen vornehmen zu müssen.

Hauptinhalt

Die Kombination von Docker Model Runner (DMR) und Open WebUI stellt eine bedeutende Entwicklung für Entwickler dar, die selbstgehostete Modelle nutzen möchten. Diese beiden Open-Source-Projekte sind darauf ausgelegt, den Arbeitsablauf für das Entwickeln und Verwalten von Modellen zu optimieren. Open WebUI erkennt automatisch, wenn Docker Model Runner auf dem lokalen Host läuft und verbindet sich ohne zusätzliche Konfiguration.

Polycrate API 0.13.0 released: Pricing & Business Layer, RocketChat Integration

Wed, 25 Feb 2026 14:00:00 +0000

Polycrate API 0.13.0 loest Baserow als Pricing-Backend ab, integriert RocketChat fuer automatisches Channel-Management und vervollstaendigt die Default Product Logik fuer S3 Buckets und Loadbalancer Instances.

Pricing & Business Layer

Preisdaten, Verkaufshistorie und Angebote werden jetzt nativ in der Polycrate API verwaltet. Der neue Product-Katalog differenziert nach kind (Host, Support, Object Storage, Loadbalancer, K8s App) und bildet die Grundlage fuer automatisiertes Billing.

Bestehende Daten aus Baserow werden einmalig ueber Management Commands migriert:

Polycrate CLI 0.30.1 released: Block Pull Bugfix

Wed, 25 Feb 2026 14:00:00 +0000

Polycrate CLI Version 0.30.1 ist ein Bugfix-Release, das einen Regressionsfehler aus 0.30.0 behebt: polycrate block pull schlug fehl, wenn ein Block bereits lokal installiert war und auf eine neue Version aktualisiert werden sollte.

Block Pull Regression Fix

Nach dem Upgrade auf CLI 0.30.0 schlugen Block-Upgrades mit folgendem Fehler fehl:

failed to pull block 'cargo.ayedo.cloud/ayedo/k8s/polycrate-api:0.8.0':
open /path/to/blocks/.../CHANGELOG.poly: no such file or directory

Ursache: In 0.30.0 wurde die Block-Pull-Logik auf eine eigene extract()-Funktion umgestellt. Die vorherige crane.Export-Implementierung erzeugte ein vollständiges Docker-Filesystem-Tar mit einem expliziten Root-Directory-Eintrag, der das Zielverzeichnis automatisch anlegte. Die neue Implementierung enthält nur den reinen OCI-Layer-Inhalt – kein Root-Eintrag, kein automatisches mkdir. Nach dem os.RemoveAll des bestehenden Block-Verzeichnisses fehlte ein os.MkdirAll vor dem Entpacken.

Polycrate CLI 0.30.0 released: Python 3.12, Ansible 13.2, --set Flag

Wed, 25 Feb 2026 12:00:00 +0000

Polycrate CLI Version 0.30.0 ist ein größeres Feature-Release mit einem aktualisierten Container-Image, neuen Möglichkeiten zur Laufzeitkonfiguration und einem verbesserten Koordinationsmodell zwischen CLI, API und Operator.

Python 3.12 + Ansible 13.2

Das Polycrate Container-Image basiert nun auf Python 3.12 und enthält Ansible 13.2.0. Damit steht kubernetes.core >= 6.1.0 zur Verfügung – inklusive neuerer Modul-Parameter wie take_ownership für kubernetes.core.helm. Das vorherige Ansible 10.7.0 war bereits End-of-Life.

Runtime Config Overrides mit `--set`

Das neue --set Flag für polycrate run ermöglicht es, action.config-Werte zur Laufzeit zu überschreiben, ohne workspace.poly oder block.poly zu verändern. Die Syntax folgt dem Helm-Standard mit Dot-Notation für verschachtelte Werte:

Post-Quantum-Readiness: Warum der Mittelstand jetzt seine Ingress-Strategie härten muss

Wed, 25 Feb 2026 10:46:04 +0000

Die Ära des “Harvest Now, Decrypt Later” hat begonnen. Während Quantencomputer, die heute gebräuchliche asymmetrische Verschlüsselungsverfahren wie RSA oder ECC brechen können, noch in der Entwicklung sind, werden verschlüsselte Datenströme bereits heute von Akteuren aufgezeichnet. Für den deutschen Mittelstand, der unter dem Druck von NIS-2 und DORA steht, ist die Post-Quantum-Kryptografie (PQC) kein futuristisches Szenario mehr, sondern eine unmittelbare Anforderung an die digitale Souveränität.

Im Jahr 2026 ist die Agilität der Infrastruktur der entscheidende Sicherheitsfaktor. Wer fest verdrahtete, veraltete Krypto-Stacks nutzt, riskiert nicht nur den Verlust von Intellectual Property, sondern auch die Compliance-Fähigkeit. Die Lösung liegt in einer hybriden Migrationsstrategie, die klassische Verfahren mit quantenresistenten Algorithmen kombiniert, ohne die Performance der Cloud-Native-Infrastruktur zu opfern.

Strategische Netzwerksicherheit: ZeroTrust Mesh-Netzwerke mit Headscale und Netbird als VPN-Ablösun

Wed, 25 Feb 2026 10:39:53 +0000

Im Jahr 2026 hat sich die Bedrohungslage für den Mittelstand fundamental verschärft. Regulatorische Anforderungen wie NIS-2 und DORA fordern nicht mehr nur oberflächliche Absicherung, sondern den Nachweis über granulare Zugriffskontrollen und die Minimierung der Explosionsradius bei Sicherheitsvorfällen. Klassische Client-to-Site VPNs, die auf dem “Castle-and-Moat”-Prinzip basieren, stoßen hier an ihre Grenzen: Einmal authentifiziert, erlaubt ein kompromittierter VPN-Zugang oft fatale Lateral Movement-Möglichkeiten im gesamten Subnetz.

Die Lösung liegt im Paradigma von Zero Trust Networking. Anstatt dem Standort zu vertrauen, wird jedes Device und jeder Service individuell identifiziert und autorisiert. Durch den Einsatz von Mesh-Technologien auf Basis von WireGuard® – konkret realisiert durch Open-Source-Lösungen wie Headscale oder Netbird – eliminieren Unternehmen die Schwachstellen traditioneller Gateway-Architekturen und schaffen eine hochperformante, souveräne Infrastruktur ohne Vendor Lock-in.

Green Ops: Messbare Nachhaltigkeit im Rechenzentrum durch eBPF und Managed Grafana

Wed, 25 Feb 2026 10:35:43 +0000

Im Jahr 2026 ist Nachhaltigkeit im IT-Sektor kein „Nice-to-have" für das Marketing mehr, sondern eine regulatorische Notwendigkeit. Mit der Verschärfung der CSRD-Berichtspflichten und der vollen Wirksamkeit von NIS-2 sowie spezifischen Energieeffizienz-Vorgaben für Rechenzentren steht der Mittelstand unter Druck. Unternehmen müssen den Energieverbrauch ihrer digitalen Wertschöpfungskette nicht nur schätzen, sondern präzise auf Workload-Ebene nachweisen.

Die Herausforderung: Klassische Monitoring-Lösungen erfassen meist nur den Gesamtverbrauch eines Hosts, was in dynamischen Kubernetes Clustern mit hunderten Microservices wertlos ist. Die Lösung liegt in der tiefen Systemintegration via eBPF (Extended Berkeley Packet Filter). In Kombination mit Prometheus und Grafana verwandeln wir abstrakte CPU-Zyklen in belastbare ESG-Daten (Environmental, Social, and Governance), ohne dabei die Performance der Applikationen durch Sidecars zu beeinträchtigen.

Data Sovereignty 2026: Souveräner Datenaustausch unter dem EU Data Act

Wed, 25 Feb 2026 10:31:02 +0000

Die regulatorischen Anforderungen an die europäische Wirtschaft haben im Jahr 2026 eine neue Qualitätsstufe erreicht. Mit dem vollumfänglich greifenden EU Data Act und den verschärften Anforderungen aus NIS-2 und DORA stehen Unternehmen vor der Herausforderung, Daten nicht mehr nur zu speichern, sondern in föderierten Datenräumen (Data Spaces) kontrolliert teilbar zu machen. Der Fokus hat sich von der reinen Storage-Frage hin zur granularen Zugriffskontrolle und Interoperabilität verschoben.

Viele Organisationen stehen vor dem Dilemma: Wie lassen sich wertvolle Datenbestände mit Partnern oder Behörden teilen, ohne in die Abhängigkeit proprietärer Cloud-Ökosysteme (Vendor Lock-in) zu geraten oder die physische Hoheit über die Informationen zu verlieren? Die Lösung liegt in einer Architektur, die auf souveränen Schnittstellen und dedizierten API-Gateways basiert, entkoppelt von den großen US-Hyperscalern.

Self-Healing Infrastructure: Wenn ArgoCD und KI-Agenten autonome Korrekturschleifen schließen

Wed, 25 Feb 2026 10:26:38 +0000

Die Ära des rein manuellen Eingreifens bei Infrastruktur-Incidents neigt sich dem Ende zu. Während GitOps mit ArgoCD den State-of-the-Art für deklaratives Deployment definiert, fehlte bisher die intelligente Brücke zwischen Observability-Daten und automatisierter Remediation. Im Jahr 2026, getrieben durch die regulatorischen Anforderungen von NIS-2 und DORA an die Resilienz kritischer Systeme, wandelt sich die Infrastructure-as-Code (IaC) zur Self-Healing Infrastructure.

Der Schmerzpunkt ist bekannt: Trotz hochverfügbarer Kubernetes-Cluster führen Fehlkonfigurationen oder unvorhergesehene Lastspitzen oft zu nächtlichen Pager-Alarmen. Die Lösung liegt in der Kombination von ArgoCD als “Source of Truth” und dedizierten KI-Agenten, die Anomalien nicht nur melden, sondern via GitOps-Workflow autonom korrigieren.

Identity-First Security: Warum Keycloak das Herzstück Ihrer NIS-2-Strategie ist

Wed, 25 Feb 2026 10:20:41 +0000

Im Jahr 2026 ist die Bedrohungslage für den europäischen Mittelstand so prekär wie nie zuvor. Identitätsdiebstahl hat sich als Angriffsvektor Nummer eins festgesetzt, da klassische Perimeter-Sicherheitsmodelle in dezentralen Cloud-Native-Strukturen versagt haben. Gleichzeitig erhöht der Gesetzgeber den Druck: Die NIS-2-Richtlinie und DORA fordern von Unternehmen nicht nur abstrakte Sicherheitskonzepte, sondern den Nachweis über strikte Zugriffskontrollen und die Integrität digitaler Identitäten.

Die Lösung liegt in einem Identity-First-Ansatz. Es geht nicht mehr darum, das Netzwerk zu schützen, sondern jede einzelne Identität und jeden API-Aufruf zu verifizieren. Innerhalb einer souveränen IT-Infrastruktur nimmt Keycloak hierbei die zentrale Rolle ein. Als Open-Source-Standard ermöglicht es Unternehmen, die volle Kontrolle über ihre Nutzerdaten zu behalten und gleichzeitig moderne Sicherheitsstandards zu implementieren, die über einfache Passwörter weit hinausgehen.

WebAssembly (Wasm) in der Cloud: Die nächste Stufe nach dem Container?

Wed, 25 Feb 2026 10:05:33 +0000

Die Cloud-Native-Landschaft hat sich konsolidiert. Während Kubernetes als De-facto-Standard für die Orchestrierung feststeht, verschieben sich die Grenzen der Runtime-Effizienz. Im Jahr 2026 stehen CTOs und Infrastructure Architects vor der Herausforderung, immer komplexere Microservices-Architekturen bei gleichzeitig steigenden Anforderungen an Energieeffizienz (ESG-Compliance) und Performance zu betreiben.

Docker-Container waren die Revolution der 2010er Jahre, doch sie schleppen Altlasten mit sich: Ein komplettes Root-Filesystem und ein Betriebssystem-Userland nur für eine kleine Go- oder Rust-Binärdatei zu orchestrieren, ist im Kontext von Edge Computing und Serverless-Szenarien oft ineffizient. Hier setzt WebAssembly (Wasm) an. Ursprünglich für den Browser entwickelt, ist Wasm auf dem besten Weg, das Backend zu transformieren – nicht als Ersatz für Container, sondern als deren hochperformante Evolution.

Vom Cost-Center zum Value-Driver

Wed, 25 Feb 2026 09:58:18 +0000

Vom Cost-Center zum Value-Driver

Im Jahr 2026 ist das bloße Versprechen der Cloud-Skalierbarkeit einer harten Realität gewichen: Wer seine Cloud-Native-Infrastruktur nicht ökonomisch steuert, verliert die Kontrolle über seine Margen. In Zeiten von NIS-2 und DORA sind Resilienz und Compliance Pflicht, doch die wirtschaftliche Effizienz – die „Unit Economics" pro Workload – ist zum entscheidenden Wettbewerbsvorteil geworden. Das reine Monitoring von Cloud-Rechnungen am Monatsende ist ein Relikt der Vergangenheit.

Die Lösung liegt in der Shift-Left-Bewegung für Kosten: FinOps 2.0 integriert ökonomische Kennzahlen direkt in die CI/CD-Pipelines und den Kubernetes-Stack. Anstatt auf die Abrechnungen der Hyperscaler zu warten, nutzen Unternehmen Open-Source-basierte Observability-Stacks, um Kosten-Transparenz in Echtzeit zu schaffen und automatisierte Cost-Gates zu etablieren.

Kubernetes als AI-Backbone: Effiziente GPU-Orchestrierung für lokale LLMs

Wed, 25 Feb 2026 09:52:14 +0000

Der Hype um proprietäre SaaS-KI-Modelle weicht 2026 einer nüchternen Kosten-Nutzen-Rechnung. Während Unternehmen anfangs bereitwillig Token-Gebühren an Hyperscaler zahlten, zwingen steigende OpEx, strikte Latenzanforderungen und die Verschärfung regulatorischer Rahmenbedingungen wie der EU AI Act und NIS-2 zum Umdenken. Die Souveränität über die eigenen Daten und die Kontrolle über die Inferenz-Kosten führen zu einer massiven Rückverlagerung von KI-Workloads in die eigene Cloud-Native Infrastruktur.

Kubernetes hat sich hierbei als das Betriebssystem für KI-Workloads etabliert. Es bietet nicht nur die notwendige Skalierbarkeit, sondern durch moderne Abstraktionsschichten auch die Möglichkeit, teure Hardware-Ressourcen wie NVIDIA H100 oder L40S GPUs präzise zu steuern. Wer lokale Large Language Models (LLMs) betreiben will, kommt an einer tiefen Integration von GPU-Ressourcen in den Kubernetes-Scheduler nicht vorbei.

Vom reaktiven Patching zur aktiven Resilienz: Der Cyber Resilience Act (CRA) 2026

Wed, 25 Feb 2026 09:46:50 +0000

Im September 2026 endet die Übergangsfrist des Cyber Resilience Act (CRA). Was als regulatorisches Framework begann, hat sich zur härtesten Prüfung für europäische IT-Infrastrukturen entwickelt. Unternehmen stehen nun in der Pflicht, die gesamte Lieferkette ihrer digitalen Produkte – von der ersten Zeile Code bis zum produktiven Deployment – lückenlos abzusichern. Wer die geforderten Sicherheitsstandards und Meldepflichten missachtet, riskiert nicht nur drakonische Bußgelder, sondern verliert im Ernstfall die Marktzulassung innerhalb der EU.

Wird Souveränität jetzt unbezahlbar?

Wed, 25 Feb 2026 09:39:16 +0000

Wird Souveränität jetzt unbezahlbar?

Docker Sandboxes stellen eine neue Möglichkeit dar, um KI-Agenten und andere Anwendungen in einer sicheren und isolierten Umgebung zu betreiben. Diese Funktion bietet Entwicklern eine starke Sicherheitsgrenze und eine benutzerfreundliche Erfahrung, indem sie die Ausführung von Anwendungen in Micro-VMs ermöglicht. Ein zentrales Merkmal ist der konfigurierbare Netzwerkproxy, der verhindert, dass Agenten auf beliebige Internetadressen zugreifen können. Gleichzeitig wird sichergestellt, dass API-Schlüssel, wie ANTHROPIC_API_KEY oder OPENAI_API_KEY, nicht zugänglich sind und somit nicht aus der Sandbox entweichen können.

Infrastructure-as-Code mit Polycrate: nie wieder SOPS

Mon, 23 Feb 2026 12:00:00 +0000

Wer Infrastructure-as-Code ernsthaft betreibt, kennt das Problem: Der Workspace im Git-Repository enthält Kubeconfigs, SSH-Keys, Passwörter und API-Tokens – alles Dateien, die niemals unkryptiert in einem Remote-Repository landen dürfen. Die übliche Antwort des cloud-nativen Ökosystems: ein weiteres Tool.

SOPS, git-crypt, sealed-secrets, Vault Agent – jedes Werkzeug löst das Problem, fügt aber gleichzeitig neue hinzu. Mehr Konfigurationsdateien, mehr Key-Backends, mehr mentale Last, mehr Dinge die kaputtgehen können. Polycrate macht das anders.

Das Tool-Sprawl-Problem im cloud-nativen IaC-Workflow

Ein typischer IaC-Workflow 2024 sieht ungefähr so aus:

Observability ohne Blindflug: Der Full-Stack-Einblick mit Grafana, Prometheus & Loki

Mon, 23 Feb 2026 11:04:05 +0000

Wer moderne Cloud-Native -Infrastrukturen betreibt, kennt das Problem: Daten sind überall, aber Erkenntnisse sind selten. Ein System gilt erst dann als „beobachtbar" (observable), wenn man seinen internen Zustand allein durch die Analyse seiner externen Ausgabedaten verstehen kann. Um dies zu erreichen, setzen wir auf das bewährte Trio des Cloud-Native-Standards.

1. Prometheus: Die Zeitreihen-Maschine für Metriken

Prometheus ist der Industriestandard für das Sammeln von numerischen Zeitreihendaten. Im Gegensatz zu alten Push-Systemen nutzt Prometheus ein Pull-Modell. Es fragt (schürft) Metriken von Endpunkten ab, die im Format /metricsbereitgestellt werden.

Polycrate CLI: Hilfreiche Tools für Developer und Platform Engineers

Mon, 23 Feb 2026 10:00:00 +0000

Wer täglich mit Polycrate arbeitet, stößt unweigerlich auf wiederkehrende Aufgaben: TLS-Zertifikate prüfen, DNS-Einträge verifizieren, Netzwerke berechnen, Tokens debuggen. Bisher bedeutete das: Tool nach Tool installieren und parallel öffnen. Mit polycrate tools gehört das der Vergangenheit an.

polycrate tools ist eine integrierte Werkzeugsammlung mit 11 spezialisierten Helfern – kein separates Install, keine Kontext-Wechsel, kein externes Dependency-Management. Einfach starten, Werkzeug wählen oder direkt per Subcommand aufrufen.

polycrate tools

Der interaktive Selektor öffnet eine TUI-Auswahl aller verfügbaren Tools. Alternativ ruft man jedes Tool direkt auf:

Statusbericht zur Agentic AI: Zentrale Erkenntnisse

Fri, 20 Feb 2026 17:18:29 +0000

TL;DR

Eine umfassende Umfrage unter über 800 Entwicklern und Technologieentscheidern zeigt, dass 60 % der Organisationen bereits KI-Agenten in Produktion haben. Sicherheitsbedenken und technische Komplexität stellen die größten Herausforderungen für die Skalierung von agentic AI dar. Während Containerisierung als zentrale Technologie betrachtet wird, ist der Weg zur unternehmensweiten Implementierung noch lang.

Hauptinhalt

Der Statusbericht zur agentic AI zeigt, dass die Akzeptanz von KI-Agenten in Unternehmen rasant zunimmt. 60 % der befragten Organisationen setzen bereits KI-Agenten in der Produktion ein, und 94 % betrachten den Aufbau solcher Agenten als strategische Priorität. Die meisten Implementierungen sind jedoch intern und konzentrieren sich auf Produktivitätssteigerung und operative Effizienz.

ayedo x STREAMLAB

Fri, 20 Feb 2026 15:46:25 +0000

Digitale Souveränität im Live-Streaming: Wie ayedo STREAMLAB strategisch beim Cloud-Betrieb stärkt

Live-Streaming ist längst geschäftskritische Infrastruktur. Die Übertragung von Vorstandsreden, Town Halls oder hybriden Events ist weit mehr als ein bloßes Kommunikations-Tool: Es handelt sich um geschäftskritische Abläufe, deren Infrastruktur höchsten Ansprüchen an Verfügbarkeit, Sicherheit und Compliance genügen muss. Genau hier setzt die Zusammenarbeit zwischen STREAMLAB und ayedo an.

STREAMLAB verfolgt einen klaren Anspruch:
„Unsere Kunden behalten jederzeit die Hoheit über ihre Kommunikationsdaten – von der Kamera bis zum Zuschauer."

Drei Mal NEIN für Microsofts „Recall“

Fri, 20 Feb 2026 11:19:58 +0000

Mit „Recall" integriert Microsoft in Windows 11 eine Funktion, die in kurzen Abständen Screenshots aller geöffneten Anwendungen erstellt, deren Inhalte per KI analysiert und dauerhaft durchsuchbar speichert. Dokumente, E-Mails, Chats, Gesundheits- oder Bankdaten können so Teil eines lückenlosen Nutzungsprotokolls werden. Was als Produktivitätsgewinn vermarktet wird, ist technisch eine neue Qualität der Systemüberwachung: Das Betriebssystem selbst wird zur permanenten Protokollinstanz.

Microsoft betont, Recall sei in der EU standardmäßig deaktiviert und nur für bestimmte Geräteklassen vorgesehen. Doch die Funktion ist Bestandteil des Systems. Solange der Code integriert ist, bleibt sie potenziell aktivierbar. Unabhängige, öffentlich einsehbare Auditberichte fehlen. Der Quellcode ist proprietär. Ob ein deaktiviertes Recall tatsächlich inaktiv ist, lässt sich von außen nicht überprüfen. Vertrauen ersetzt hier technische Nachweisbarkeit.

Wie Medplum ihre Gesundheitsplattform mit Docker Hardened Images (DHI) absicherte

Thu, 19 Feb 2026 14:00:00 +0000

TL;DR

Medplum hat erfolgreich seine Gesundheitsplattform auf Docker Hardened Images (DHI) migriert, um die Sicherheitslage zu verbessern und gleichzeitig den Codeaufwand minimal zu halten. Diese Migration erforderte nur 54 Zeilen Änderungen in fünf Dateien und demonstriert, wie DHI Unternehmen eine enterprise-grade Sicherheit bieten kann, ohne den Entwicklungsprozess zu belasten.

Hauptinhalt

Medplum ist eine Open-Source-Plattform für elektronische Gesundheitsakten (EHR), die über 20 Millionen Patienten bedient. Die Plattform ermöglicht Entwicklern, sich auf die Erstellung von Gesundheitsanwendungen zu konzentrieren, indem sie die Verwaltung von Patientendaten, klinischen Workflows und Compliance -Anforderungen übernimmt. Medplum bietet von Haus aus HIPAA- und SOC2-Compliance sowie eine FHIR R4 API für die Interoperabilität von Gesundheitsdaten. Die Plattform kann sowohl selbst gehostet als auch verwaltet bereitgestellt werden und hat sich als vertrauenswürdige Basis für Gesundheitsentwickler weltweit etabliert.

Video-Verarbeitung

Thu, 19 Feb 2026 11:05:47 +0000

Von Bare-Metal-Basteln zu elastischer Video-Infrastruktur: Wie ayedo Streambase für große Live-Events skalierbar gemacht hat

Video ist die Königsdisziplin der Infrastruktur.

Während viele SaaS-Anwendungen relativ gutmütig sind, reagiert Video gnadenlos: Ein kleiner Konfigurationsfehler wird sofort als Ruckeln sichtbar. Eine CPU-Spitze erzeugt Audio-Aussetzer. Eine unvorhersehbare Lastwelle führt nicht zu „etwas langsamer", sondern zu einem abgebrochenen Stream – live, vor Publikum.

Streambase Media betreibt eine Video-Plattform für Unternehmen: Live-Streaming von Firmenevents, hybride Meetings und eine On-Demand-Bibliothek in einer Lösung – als europäische Alternative zu Zoom Events und Vimeo Enterprise. Rund 120 Firmenkunden nutzen die Plattform, von Town-Halls mit 50 Teilnehmern bis zu Produkt-Launches mit mehreren tausend Zuschauern.

SaaS Apps

Thu, 19 Feb 2026 11:05:01 +0000

Von VM-Betrieb zu Plattform: Wie ayedo Planwerk zu skalierbarem, auditierbarem SaaS-Betrieb geführt hat

Viele SaaS-Plattformen wachsen so, wie sie gebaut werden: Schritt für Schritt, pragmatisch, „funktioniert erstmal". Das ist in der frühen Phase richtig. Doch irgendwann kippt es. Dann wird aus pragmatischer Infrastruktur ein Risiko – nicht, weil sie schlecht ist, sondern weil das Produkt ihr entwachsen ist.

Planwerk entwickelt eine Plattform für digitale Bauplanung und Projektsteuerung. Architekturbüros, Bauträger und öffentliche Auftraggeber planen damit kollaborativ, dokumentieren Entscheidungen, steuern Bauvorhaben. Rund 8.000 aktive Nutzer auf etwa 200 Kunden – von kleinen Büros bis zu kommunalen Bauämtern mit hunderten Nutzern. Zusätzlich gab es drei Enterprise-Kunden, die die Plattform aus regulatorischen Gründen in einer dedizierten On-Premise-Instanz betreiben.

Machine Learning

Thu, 19 Feb 2026 10:46:06 +0000

Von GPU-Engpässen zu Industrial-Scale MLOps: Wie ayedo Sensoriq zur Kubernetes-basierten ML-Plattform geführt hat

Predictive Maintenance klingt nach „ein Modell trainieren und fertig". In der Praxis scheitern viele Projekte nicht am Modell, sondern an dem, was danach kommt: Datenströme, Inferenz-SLAs, reproduzierbare Experimente und eine Infrastruktur, die skaliert, ohne dass jedes neue Kundenprojekt ein neues Betriebsprojekt auslöst.

Sensoriq entwickelt KI-basierte Lösungen für die Fertigungsindustrie. Die Software analysiert Sensordaten in Echtzeit und prognostiziert Ausfälle, bevor sie eintreten. Das Produkt besteht aus Edge-Komponenten an der Maschine, einer Streaming-Pipeline und einer Cloud-Plattform für Training, Inferenz und Visualisierung.

eCommerce

Thu, 19 Feb 2026 10:43:53 +0000

Von Einzelserver-Shops zur hochverfügbaren E-Commerce-Plattform: Wie ayedo Nordlicht Commerce neu aufgestellt hat

E-Commerce-Agenturen wachsen oft schneller als ihre Infrastruktur.

Nordlicht Commerce ist spezialisiert auf Shopware-Projekte für mittelständische Handelsunternehmen und D2C-Marken. Zwölf Kundenshops im Betrieb, sechs eigene Plugins im Shopware Store, ein wachsendes Projektgeschäft – fachlich stark, technisch engagiert.

Was lange funktionierte, wurde mit steigender Kundenanzahl und höheren SLA-Anforderungen zum Risiko.

Ausgangslage: Zwölf Shops, fünf Hoster, null Standardisierung

Über Jahre hatte sich ein typisches Agentur-Setup entwickelt.

Preview Environments

Thu, 19 Feb 2026 10:42:13 +0000

Von Staging-Stau zu Continuous Delivery: Wie ayedo für Vantara automatisierte Preview-Environments aufgebaut hat

Continuous Delivery ist kein Tool-Problem.
Es ist ein Feedback-Problem.

Vantara Digital entwickelt eine cloudbasierte Plattform für digitales Vertragsmanagement. Drei Feature-Teams arbeiten parallel an Frontend, Backend/API und Integrationen. Ziel der Geschäftsführung: wöchentliche Releases – perspektivisch Continuous Delivery.

Auf dem Papier war der Entwicklungsprozess sauber organisiert: Feature-Branches, Pull Requests, Code Reviews, Merge in den Hauptbranch, Deployment auf eine gemeinsame Staging-Umgebung. Ein klassisches Git-Flow-Modell.

Demo Environments

Thu, 19 Feb 2026 10:33:48 +0000

Von 3 Werktagen auf 90 Sekunden: Wie ayedo den Demo-Prozess eines ERP-Anbieters vollständig automatisiert hat

Produkt-Demos sind für viele SaaS-Unternehmen ein notwendiger Vertriebsbestandteil. Für Signalwerk waren sie der zentrale Wachstumstreiber – und gleichzeitig der größte operative Engpass.

Signalwerk entwickelt eine modulare ERP-Lösung für mittelständische Fertigungsunternehmen. Produktionsplanung, Lagerverwaltung, Qualitätsmanagement – komplexe Prozesse, die sich nicht in einer PowerPoint-Folie erklären lassen. Das Produkt muss erlebt werden.

Und genau hier begann das Problem.

Business Tools

Thu, 19 Feb 2026 10:33:01 +0000

Souveräne Business-IT statt US-SaaS-Abhängigkeit: Wie ayedo einen technischen Dienstleister strategisch entkoppelt hat

Standard-SaaS ist bequem. Bis sie strategisch zum Risiko wird.

Viele mittelständische Unternehmen setzen auf Microsoft 365, Zendesk oder DocuSign – nicht aus Überzeugung für US-Cloud-Infrastruktur, sondern weil es schnell verfügbar ist und ohne eigenes IT-Team funktioniert. Die Systeme laufen, Updates kommen automatisch, und der operative Aufwand scheint minimal.

Doch sobald Kunden aus regulierten Branchen ins Spiel kommen, verschiebt sich der Maßstab. Dann geht es nicht mehr um Funktionen, sondern um Kontrolle. Um Rechtsraum. Um Nachweisbarkeit. Und um die Frage, wer im Ernstfall Zugriff auf geschäftskritische Daten erzwingen kann.

Data Engineering

Thu, 19 Feb 2026 10:22:28 +0000

Von Ticket-Infrastruktur zu On-Demand-KI: Wie ayedo eine Kubernetes -basierte Data-Engineering-Plattform für einen Industriekonzern aufgebaut hat

Datengetriebene Innovation scheitert selten an Ideen. Sie scheitert an Infrastruktur.

Viele Industrieunternehmen investieren in Data Science, KI-Modelle und Advanced Analytics – und merken dann, dass ihre Plattform nicht mitwächst. GPU-Ressourcen sind knapp, Entwicklungsumgebungen starr, ETL-Prozesse schwer skalierbar. Jeder neue Anwendungsfall wird zum Infrastrukturprojekt.

In diesem Beitrag zeigen wir anhand eines anonymisierten Projekts, wie ayedo für einen global tätigen Industriekonzern eine Kubernetes-basierte Data-Engineering-Plattform aufgebaut hat – für ETL-Pipelines, Event-Streaming, analytische Datenbanken und GPU-gestützte KI-Workloads.

Monitoring

Thu, 19 Feb 2026 10:20:28 +0000

Von Log-Debugging zu echter Observability: Wie ayedo eine SaaS-Plattform mit APM auf Kubernetes stabilisiert hat

Viele SaaS-Unternehmen investieren früh in saubere Architektur: containerisierte Workloads, Kubernetes, Infrastructure as Code, GitOps. Technisch wirkt alles modern. Und doch fehlt häufig ein entscheidender Baustein: Transparenz über das tatsächliche Laufzeitverhalten der Anwendung.

In diesem Beitrag zeigen wir anhand eines anonymisierten Projekts, wie ayedo für einen SaaS-Anbieter mit mehreren Millionen aktiven Nutzern ein skalierbares Application Performance Monitoring (APM) auf Basis von VictoriaMetrics, VictoriaLogs, Grafana und OpenTelemetry aufgebaut hat – vollständig integriert in die bestehende Kubernetes-Infrastruktur.

Interne Developer Platform

Thu, 19 Feb 2026 10:17:05 +0000

Von GitHub-Deployments zu Continuous Confidence: Wie ayedo eine Internal Developer Platform für Enterprise-Delivery aufgebaut hat

Viele Teams liefern heute containerisierte Software, nutzen GitHub, automatisieren Builds – und fühlen sich trotzdem nicht „plattformreif". Das liegt selten am Code. Es liegt daran, dass CI/CD als Pipeline-Logik verstanden wird, nicht als System. Solange Deployments direkt aus Build-Pipelines auf Serverzustände wirken, bleibt Delivery fragil: schwer reproduzierbar, schwer auditierbar, schwer zu betreiben.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo ein Softwarehaus mit starkem Projektgeschäft und wachsenden Enterprise-Anforderungen von einem GitHub-zentrierten Deployment-Modell auf eine moderne Internal Developer Platform (IDP) auf Managed Kubernetes geführt hat. Der Kunde bleibt anonym. Der Ansatz ist übertragbar – insbesondere für Organisationen, die Best-of-Breed Tooling nutzen wollen, aber endlich eine konsistente, revisionssichere Delivery- und Betriebsbasis brauchen.

Edge-Compute

Thu, 19 Feb 2026 10:06:26 +0000

Kubernetes am Edge mit GitOps: Wie ayedo eine verteilte IoT-Flotte von SSH-Deployments zu kontrollierten Rollouts geführt hat

Edge Computing ist für IoT, Industrie 4.0 und Smart-Grid-Szenarien kein Hype, sondern Betriebsrealität. Daten entstehen nicht im Rechenzentrum, sondern draußen: an Messpunkten, in Trafostationen, an Gateways in kommunalen Netzen oder in Industrieanlagen. Wer diese Daten zuverlässig in ein zentrales Datahub bringen will, muss die Software an hunderten Standorten betreiben – oft mit instabiler Konnektivität, begrenzten Wartungsfenstern und hohen Anforderungen an Verfügbarkeit und Integrität.

Multi-Tenant App Hosting

Thu, 19 Feb 2026 10:02:43 +0000

Multi-Tenant Kubernetes für eCommerce: Wie ayedo ein Softwarehaus ohne DevOps-Team von VM-Skripting zur Developer Platform geführt hat

In vielen eCommerce-Teams ist der Engpass nicht Feature-Entwicklung, sondern Betrieb. Nicht weil die Entwickler schlechte Software schreiben, sondern weil das Betriebsmodell nicht mitwächst. Was am Anfang „ein paar Server und ein paar Skripte" ist, wird im Scale zu einem Business-Risiko: Jede Kundeninstanz entwickelt sich anders, Deployments sind nicht mehr reproduzierbar, Wartungsfenster häufen sich – und die Zeit der Entwickler fließt in Firefighting statt in Produktwert.

Compliant Software Hosting

Thu, 19 Feb 2026 09:55:25 +0000

Von Hyperscaler-Abhängigkeit zu DORA-nachweisbarer Souveränität: Wie ayedo eine Fintech-Plattform auditierbar migriert hat

In den letzten Jahren sind viele Fintechs auf US-Hyperscalern schnell groß geworden. Managed Kubernetes, Managed Databases, Identity-Dienste, Monitoring – das beschleunigt Produktentwicklung enorm. Technisch funktioniert das fast immer. Regulatorisch wird es zunehmend zur Sollbruchstelle.

Seit dem Inkrafttreten von DORA im Januar 2025 ist genau diese Sollbruchstelle für viele Finanzdienstleister und deren kritische IT-Dienstleister nicht mehr hypothetisch, sondern prüfungsrelevant. Konzentrationsrisiken, Exit-Strategien, Lieferkettensicherheit, Auditierbarkeit: Wer hier keine belastbaren Antworten liefert, verliert nicht nur Vertrauen, sondern Geschäftsgrundlagen.

Multi-Region Infrastruktur

Thu, 19 Feb 2026 09:54:50 +0000

Multi-Region Kubernetes für KRITIS: Wie ayedo eine Einzelstandort-Plattform in ein aktiv/aktiv Anycast-System transformiert hat

Wer kritische Infrastruktur betreibt, kann sich keine „gute Verfügbarkeit" leisten – sondern braucht nachweisbare Ausfallsicherheit. Und zwar nicht nur innerhalb eines Rechenzentrums, sondern standortübergreifend. Genau hier scheitern viele Plattformen, die technisch sauber gebaut sind, aber historisch in einer Einzelregion gewachsen sind: Sie sind redundant im Rack, redundant im Cluster, redundant in der Datenbank – und trotzdem ein Single Point of Failure auf Standortebene.

Global Endpoint Monitoring

Thu, 19 Feb 2026 09:45:40 +0000

Endpoint Monitoring, das man wieder ernst nimmt: Wie ayedo ein Hosting-Unternehmen von Fehlalarmen zu Multi-Region-Sicherheit geführt hat

Monitoring ist für Managed Hosting kein Werkzeug – es ist Teil des Produkts. Kunden kaufen nicht nur Infrastruktur, sondern die Zusage, dass Verfügbarkeit, Sicherheit und Reaktionsfähigkeit jederzeit gegeben sind. Genau daran scheitern viele Monitoring-Setups im Wachstum: Was anfangs „ausreichend" ist, wird später zur operativen Bremse. Und im schlimmsten Fall zur Ursache für Eskalationen.

DBaaS - Database as a Service

Thu, 19 Feb 2026 09:37:57 +0000

DBaaS für PostgreSQL: Wie ayedo einen europäischen Anbieter in Wochen zur skalierbaren Plattform geführt hat

Database as a Service klingt auf dem Papier einfach: Kund:innen klicken sich eine PostgreSQL-Instanz, bekommen Backups, Monitoring und Hochverfügbarkeit – und das war’s. In der Realität ist DBaaS eine der anspruchsvollsten Plattformdisziplinen überhaupt. Nicht wegen PostgreSQL, sondern wegen allem, was außen herum zuverlässig funktionieren muss: Isolation, Storage, Backup-Strategien, Observability, Automatisierung, Auditierbarkeit – und das bei hunderten bis tausenden Instanzen.

Hauseigene Betriebsplattform

Wed, 18 Feb 2026 13:48:54 +0000

Wie ayedo ein Systemhaus vom gewachsenen Betrieb zur auditierbaren Betriebsplattform geführt hat

Ein eigenes Rechenzentrum zu betreiben war lange ein Wettbewerbsvorteil – besonders für Systemhäuser, die Kundenanwendungen nicht nur entwickeln, sondern auch verantworten. Wer den Betrieb beherrscht, kann Verfügbarkeit garantieren, Updates kontrollieren, Datenhoheit sichern und Compliance-Fragen souverän beantworten.

In der Praxis kippt dieser Vorteil jedoch oft genau dann, wenn er am wichtigsten wird: wenn das Portfolio wächst, die Anforderungen steigen und Kunden nicht mehr nur „läuft" erwarten, sondern messbare SLAs, nachvollziehbare Betriebsprozesse und auditierbare Nachweise.

Weekly Backlog KW 09/2026

Wed, 18 Feb 2026 12:51:00 +0000

🧠 Editorial: Die Woche der Souveränitäts-Simulationen

Diese Woche hatte alles: Betriebssysteme, die Screenshots von allem machen wollen. Verwaltungsplattformen ohne klare Architektur. Kommunen mit eigenen Souveränitäts-Scores. Konzerne, die US-Cloud gegen US-Cloud tauschen – und das „Unabhängigkeit" nennen.

Und dazwischen eine europäische Telko-Allianz, die still und leise genau das baut, worüber andere seit Jahren nur Panels veranstalten.

Die digitale Souveränität ist eine Machtfrage. Und sie entscheidet sich nicht in PowerPoints, sondern in Architekturdiagrammen, Beschaffungsrichtlinien und Preismodellen.

Polycrate API 0.12.0 released: CatalogueApp, AI Maintenance Detection & Provider Model

Tue, 17 Feb 2026 16:00:00 +0000

Polycrate API 0.12.0 ist das groesste Feature-Release seit 0.11.0. Der App-Katalog wird zum First-Class ManagedObject, Provider-Maintenances werden automatisch via AI erkannt, und die Infrastruktur-Modellierung wird mit dem Provider Model und der Workspace-Pop-Pflicht gestaerkt.

CatalogueApp – App-Katalog als ManagedObject

Der plattformweite App-Katalog (bisher in Baserow) ist jetzt ein eigenstaendiges ManagedObject. Jede CatalogueApp ist mit einem ArtifactPackage verknuepft und erbt darueber Metadaten wie Icon, Beschreibung und Repository-URLs. Die Detail-Ansicht bietet einen Version Switcher mit Changelog und README Rendering pro Version. Ein Management Command importiert den bestehenden Katalog aus Baserow.

Die Multi-Model-Datenbank für KI-Agenten: SurrealDB mit Docker-Erweiterung bereitstellen

Tue, 17 Feb 2026 14:00:00 +0000

TL;DR

SurrealDB ist eine Multi-Model-Datenbank, die verschiedene Datentypen in einer einzigen Engine vereint und speziell für KI-Anwendungen optimiert ist. Sie ermöglicht eine einfache Bereitstellung über Docker und reduziert die Komplexität der Dateninfrastruktur, während sie gleichzeitig die Effizienz und Reaktionsgeschwindigkeit von AI-Systemen verbessert.

Hauptinhalt

Die zunehmende Komplexität moderner Anwendungen erfordert oft die Integration mehrerer Datenbanken, darunter relationale, dokumentenbasierte, graphenbasierte und zeitbasierte Systeme. Diese Fragmentierung führt zu höheren Kosten, operationalen Risiken und einer Verlangsamung der Innovationsgeschwindigkeit. Entwickler verbringen oft mehr Zeit mit der Verwaltung der Infrastruktur und dem Schreiben von Integrationscode als mit der eigentlichen Anwendungslogik. Dies ist besonders problematisch für KI-Anwendungen, bei denen fragmentierte Daten und Kontexte zu schlechten Ergebnissen führen können.

Make Cloud Yours Again

Tue, 17 Feb 2026 11:38:23 +0000

Warum digitale Souveränität weniger radikal ist, als viele glauben

Geopolitische Spannungen, extraterritoriale Gesetze, Sanktionsregime – all das ist längst Teil der Realität, in der IT-Strategien heute entwickelt werden. Unternehmen und öffentliche Einrichtungen stehen vor einer neuen Frage: Reicht funktionierende Cloud-Infrastruktur aus – oder braucht es zusätzlich strategische Kontrolle?

Dabei zeigt sich in vielen Gesprächen IT-Verantwortlichen ein wiederkehrendes Muster: Das Bewusstsein für Abhängigkeiten ist vorhanden. Die Argumente für mehr Souveränität sind nachvollziehbar.

Kubernetes als Fundament digitaler Souveränität

Tue, 17 Feb 2026 10:14:17 +0000

Warum die Open-Source-Technologie mehr ist als nur Container-Orchestrierung

Wenn heute über digitale Souveränität gesprochen wird, fällt ein Name fast immer: Kubernetes. Und das nicht ohne Grund. Die Open-Source-Technologie hat sich in den letzten Jahren zum De-facto-Standard für den Betrieb moderner Anwendungen entwickelt – vom SaaS-Start-up bis hin zu staatlichen Rechenzentren und kritischen Infrastrukturen.

Doch was macht Kubernetes technologisch so relevant? Und warum spielt es eine Schlüsselrolle in strategischen IT-Architekturen?

Kubernetes technisch betrachtet: Automatisierung auf Infrastruktur-Ebene

Kubernetes orchestriert Container – also isolierte, portable Anwendungspakete, die sämtliche Abhängigkeiten bereits mitbringen. Während früher einzelne Server manuell konfiguriert, skaliert und gewartet werden mussten, verfolgt Kubernetes einen deklarativen Ansatz:

Toxische Tech-Abhängigkeit:

Mon, 16 Feb 2026 12:04:31 +0000

Warum Deutschlands digitale Souveränität zur Sicherheitsfrage geworden ist

Digitale Souveränität ist kein industriepolitisches Schlagwort mehr. Sie ist eine Frage staatlicher Resilienz. Wer zentrale Verwaltungsprozesse, Polizeiarbeit, militärische Systeme und Kommunikationsinfrastrukturen auf Technologien weniger US-Konzerne stützt, begibt sich in eine strategische Abhängigkeit, die unter veränderten geopolitischen Bedingungen zum Risiko wird.

Genau das ist die Lage.

US-Clouds dominieren den europäischen Markt. Microsoft, Amazon, Google strukturieren die digitale Grundversorgung von Behörden und Unternehmen. Analyseplattformen wie Palantir sind in mehreren Bundesländern operative Realität. Gleichzeitig verschärft sich der politische Ton aus Washington. Die Trump-Administration greift europäische Regulierung offen an, attackiert den Digital Services Act und formuliert Einflussansprüche gegenüber der EU. Tech-CEOs suchen demonstrativ die Nähe zur Macht.

Trümpfe gegen Trump:

Mon, 16 Feb 2026 10:27:33 +0000

Europas ökonomische Macht

Der Handelskonflikt mit den USA wird in Europa reflexhaft als Machtasymmetrie erzählt. Washington verhängt Zölle, droht mit Sanktionen oder nutzt seine technologische Dominanz als Druckmittel – und Brüssel reagiert. Das Bild: ein abhängiger Kontinent, gefangen zwischen sicherheitspolitischer Bindung und wirtschaftlicher Verwundbarkeit.

Ein aktuelles Forschungspapier der Denkfabrik „Dezernat Zukunft" stellt diese Erzählung infrage. Die Analyse kommt zu einem klaren Befund: Die Europäische Union verfügt über deutlich größere wirtschaftliche Hebel gegenüber den USA, als gemeinhin angenommen wird. Das Problem ist nicht mangelnde Macht. Es ist mangelnde strategische Nutzung.

Warum klassische Public-Key-Kryptografie strukturell ausläuft

Mon, 16 Feb 2026 10:09:54 +0000

Das BSI zieht eine klare Linie: Ab Ende 2031 soll der alleinige Einsatz klassischer Schlüsseleinigungsverfahren wie RSA und ECC nicht mehr empfohlen werden. Für Anwendungen mit sehr hohem Schutzbedarf gilt die Frist bereits bis Ende 2030. Digitale Signaturen sollen spätestens ab 2036 hybrid umgesetzt werden. Die TR-02102 wird damit faktisch zum Migrationsfahrplan für Post-Quanten-Kryptografie (PQC).

Diese Entscheidung ist keine Vorsichtsübung. Sie ist eine technische Notwendigkeit.

Warum RSA und ECC strukturell verwundbar sind

Microsoft, Monokulturen und Macht:

Mon, 16 Feb 2026 10:01:50 +0000

Warum digitale Souveränität ohne Wettbewerb eine Illusion bleibt

Die Debatte um digitale Souveränität in Europa wird häufig verkürzt geführt. Im Zentrum steht dabei meist die Frage, ob sich europäische Staaten und Unternehmen stärker von US-amerikanischen Technologieanbietern lösen sollten. Der IT-Sicherheitsrechtler Dennis-Kenji Kipker warnt in einem Gespräch mit der Börsen-Zeitung vor pauschalen Forderungen nach einem Bann von Big-Tech-Unternehmen aus den USA. Seine Argumentation zielt auf eine differenzierte Betrachtung: Digitale Souveränität entsteht nicht durch Herkunftsverbote, sondern durch funktionierenden Wettbewerb, Interoperabilität und klare regulatorische Leitplanken.

Wero:

Mon, 16 Feb 2026 09:57:04 +0000

Europa arbeitet an einer eigenen digitalen Zahlungsinfrastruktur

Der europäische Zahlungsverkehr ist seit Jahren stark von internationalen Anbietern geprägt. Ein Großteil der Karten- und mobilen Zahlungen innerhalb der Europäischen Union wird über Netzwerke wie Visa, Mastercard, Paypal oder Alipay abgewickelt. Nach Angaben der Europäischen Zentralbank (EZB) entfallen 56 Prozent der bargeldlosen Zahlungen in den EU-Mitgliedstaaten auf Kartenzahlungen. Visa und Mastercard verarbeiten dabei Transaktionen im geschätzten Umfang von rund 24 Billionen US-Dollar pro Jahr.

Digitale Souveränität als Machtfrage:

Mon, 16 Feb 2026 09:36:52 +0000

Europas strukturelle Abhängigkeit von Big Tech

Die Debatte um digitale Souveränität ist keine technologische Detailfrage mehr. Sie ist eine Frage politischer Handlungsfähigkeit. Spätestens seit der sichtbaren Annäherung führender US-Technologieunternehmer an die Regierung von Donald Trump wird deutlich, wie eng wirtschaftliche Plattformmacht und politische Einflussnahme miteinander verflochten sind.

Die niederländische Digitalexpertin Marietje Schaake ordnet diese Entwicklung klar ein: Technologie ist nicht nur Wirtschaftsfaktor, sondern Machtinstrument. Europa hat diese Dimension lange unterschätzt.

Weekly Backlog KW 8/2026

Mon, 16 Feb 2026 09:20:33 +0000

🧠 Editorial

Falls es euch aufgefallen ist: Der Weekly Backlog sieht ein bisschen anders aus. Jetzt noch persönlicher, bunter, lauter und mit viel mehr Wiedererkennungswert. Inhaltlich bleibt aber alles beim Alten: Cloud, Macht, Security, Open Source, Politik. Nur eben frischer angerichtet.

Und das ist auch nötig.

Denn diese Woche hatte ein Leitthema, das sich durch fast alle Meldungen zieht: Digitale Infrastruktur ist Macht. Nicht metaphorisch. Nicht akademisch. Sondern sehr konkret – wirtschaftlich, sicherheitspolitisch, geopolitisch.

Human-Machine-Trust: Wie wir KI-Entscheidungen in der IT nachvollziehbar machen

Fri, 13 Feb 2026 08:48:20 +0000

In einer klassischen IT-Infrastruktur gab es eine klare Kausalkette: Ein Administrator änderte eine Zeile Code, und das System reagierte. In der Welt der Agentic AI trifft die KI autonome Entscheidungen (z. B. das Terminieren von Instanzen oder das Umrouten von Traffic), basierend auf Milliarden von Parametern. Ohne eine Strategie für Explainability(Erklärbarkeit) wird die Infrastruktur unberechenbar.

Human-Machine-Trust bedeutet, Systeme so zu bauen, dass sie nicht nur handeln, sondern ihr Handeln jederzeit gegenüber dem Menschen rechtfertigen können.

Data Mesh vs. Data Silo: Die föderierte Infrastruktur für das moderne Unternehmen

Fri, 13 Feb 2026 08:41:22 +0000

Das klassische Modell des „Data Lake" ist gescheitert. Unternehmen haben Millionen in Infrastruktur investiert, um Daten an einem Ort zu sammeln, nur um festzustellen, dass diese Daten dort „verrotten", weil der Kontext fehlt. Das Data Mesh bricht mit diesem Paradigma: Statt Daten in einen zentralen See zu schütten, verbleiben sie dort, wo sie entstehen – in der Verantwortung der jeweiligen Fachdomäne (z. B. Logistik, Sales, Produktion).

Technisch gesehen wandelt sich die Infrastruktur von einer monolithischen Speicherarchitektur hin zu einer dezentralen Microservice-Architektur für Daten.

Post-Quantum-Kryptographie: Die Infrastruktur gegen die Bedrohungen von morgen absichern

Fri, 13 Feb 2026 08:36:14 +0000

Die heutige Sicherheit des Internets beruht fast vollständig auf der Schwierigkeit, große Zahlen in Primfaktoren zu zerlegen (RSA) oder diskrete Logarithmen auf elliptischen Kurven zu berechnen (ECC). Ein ausreichend leistungsstarker Quantencomputer nutzt den Shor-Algorithmus, um diese Probleme trivial zu lösen.

Das Problem für Unternehmen heute heißt: “Harvest Now, Decrypt Later”. Angreifer speichern heute verschlüsselte Datenströme, um sie in 5 bis 10 Jahren mit Quantencomputern zu entschlüsseln. Wer heute sensible Daten (Patientenakten, Staatsgeheimnisse, IP) überträgt, muss jetzt auf quantensichere Verfahren umstellen.

500 Millionen Euro für Microsoft-Lizenzen

Thu, 12 Feb 2026 11:27:14 +0000

Und was diese Zahl für Europas digitale Handlungsfähigkeit bedeutet.

481,4 Millionen Euro hat die Bundesverwaltung im Jahr 2025 für Microsoft-Lizenzen ausgegeben. 2023 waren es 274,1 Millionen Euro, 2024 bereits 347,7 Millionen. Innerhalb von zwei Jahren sind die Ausgaben damit um mehr als 75 Prozent gestiegen.

Diese Dynamik ist mehr als eine haushaltspolitische Randnotiz. Sie ist ein Indikator für strukturelle Abhängigkeiten – und für eine digitale Beschaffungspraxis, die strategische Fragen zu lange ausgeklammert hat.

Agentic AI & Infrastructure: Wenn die KI Ressourcen selbst verwaltet

Thu, 12 Feb 2026 10:55:44 +0000

Bis vor kurzem war die Automatisierung von Infrastruktur reaktiv: Wenn die CPU-Auslastung über 80 % stieg, startete Kubernetes einen neuen Pod (Autoscaling). Das ist effizient, aber dumm. Es erkennt keine Zusammenhänge und kann keine komplexen Probleme lösen.

2026 übernehmen KI-Agenten das Ruder. Ein Agent „versteht" das Ziel (z. B. „Sichere die Verfügbarkeit bei minimalen Kosten") und führt autonom eine Kette von Aktionen aus: Er analysiert Traffic-Muster, erkennt einen drohenden DDoS-Angriff, unterscheidet ihn von einem echten Nutzeransturm, passt die Firewall-Regeln an und bucht gleichzeitig kostengünstige Spot-Instanzen in der Cloud dazu.

Compliance as Code: Warum Ihr nächstes Audit per Knopfdruck erfolgt

Thu, 12 Feb 2026 10:49:48 +0000

Bisher war Compliance in vielen Unternehmen der natürliche Feind der Agilität. Während die Softwareentwicklung dank Cloud-Native und DevOps in Millisekunden skaliert, brauchten Compliance-Prüfungen bisher Wochen: Manuelle Kontrollen, stichprobenartige Screenshots von Konfigurationen und dicke Ordner voller Dokumentationen, die bereits veraltet waren, bevor die Tinte trocken war.

Im Jahr 2026 bricht dieses manuelle System unter der Last neuer regulatorischer Anforderungen wie NIS-2, DORA oder dem EU AI Act endgültig zusammen. Wer heute noch auf Excel-Listen setzt, riskiert nicht nur Bußgelder, sondern verliert die Fähigkeit, schnell am Markt zu agieren. Die Lösung ist der radikale Wechsel zu Compliance as Code (CaC).

Software Supply Chain Security: Das Immunsystem Ihrer CI/CD-Pipeline

Thu, 12 Feb 2026 10:30:16 +0000

Früher reichte es aus, die Haustür (die Firewall) zu sichern. Doch heute kommen die Bedrohungen „frei Haus" – versteckt in den tausenden Abhängigkeiten, die wir täglich über npm, pip oder docker pull in unsere Systeme laden. Ein einziger kompromittierter Baustein in einer Open-Source-Bibliothek kann Ihre gesamte Infrastruktur von innen heraus lahmlegen.

Software Supply Chain Security (SSCS) bedeutet, den Weg des Codes vom ersten Tastendruck des Entwicklers bis zum laufenden Container im Cluster lückenlos zu überwachen und zu verifizieren.

FinOps 2.0: Cloud-Kostenkontrolle im Zeitalter teurer KI-Workloads

Thu, 12 Feb 2026 10:23:15 +0000

Der Hype um Künstliche Intelligenz hat eine neue Ära der IT-Ausgaben eingeläutet. Wer heute LLMs (Large Language Models) trainiert oder produktiv betreibt, merkt schnell: Die Kosten für Grafikprozessoren (GPUs) folgen ganz anderen Gesetzen als klassische CPU-Instanzen. Eine einzelne H100-Instanz in der Cloud kann pro Monat so viel kosten wie ein Kleinwagen.

FinOps 2.0 ist die Evolution des Cloud-Kostenmanagements. Es geht nicht mehr nur darum, ungenutzte Instanzen abzuschalten, sondern die teuersten Ressourcen des Unternehmens – die KI-Rechenpower – mit chirurgischer Präzision zu steuern.

Cyber-Resilienz durch Täuschung: Warum Ihr Cluster Honeypots braucht

Thu, 12 Feb 2026 10:15:33 +0000

In der IT-Sicherheit galt lange das Prinzip der „Festung": Hohe Mauern, tiefe Gräben (Firewalls). Doch die Realität 2026 zeigt: Wenn ein Angreifer erst einmal im Netzwerk ist (z. B. durch gestohlene Credentials), bewegt er sich oft wochenlang unbemerkt horizontal durch die Infrastruktur. Hier setzt Deception Technology an. Statt nur zu blockieren, verwandeln wir die Infrastruktur in ein digitales Minenfeld aus Täuschungen.

Das Ziel: Den Angreifer dazu bringen, sich zu offenbaren, indem er mit Ressourcen interagiert, die es eigentlich gar nicht geben dürfte.

Im Fokus: SIG Architektur - API Governance

Thu, 12 Feb 2026 00:00:00 +0000

TL;DR

Die API Governance innerhalb des SIG Architecture-Projekts von Kubernetes zielt darauf ab, die Stabilität und Innovationsfähigkeit der verschiedenen APIs zu gewährleisten. Die Initiative befasst sich nicht nur mit REST-APIs, sondern auch mit anderen API-Oberflächen, wie z.B. Kommandozeilenflags und Konfigurationsdateien. Durch strukturierte Richtlinien und aktive Beteiligung während des Design- und Implementierungsprozesses wird die Qualität und Konsistenz der APIs sichergestellt.

Hauptinhalt

Die API Governance ist ein Subprojekt des SIG Architecture von Kubernetes, das seit 2019 aktiv ist. Es wird von Jordan Liggitt geleitet, der seit 2014 an Kubernetes arbeitet und umfassende Erfahrungen in der Entwicklung von Authentifizierungs- und Autorisierungsmechanismen gesammelt hat. Die Hauptziele des Projekts sind die Gewährleistung der Stabilität der APIs, während gleichzeitig Raum für Innovationen geschaffen wird.

Ingress-NGINX läuft aus: So migrierst du bis März 2026 sauber

Wed, 11 Feb 2026 11:26:23 +0000

Der von der Kubernetes-Community gepflegte Ingress-NGINX Controller (Repository kubernetes/ingress-nginx) erreicht im März 2026 sein offizielles Lebensende. Ab dann gibt es keine Releases, keine Bugfixes und keine Security-Patchesmehr. Bestehende Installationen „brechen" zwar nicht sofort – aber sie laufen anschließend unkontrolliert weiter: neue CVEs, neue Kubernetes-Versionen, neue Inkompatibilitäten – ohne Upstream-Fixes.

Wichtig: Das betrifft nicht NGINX als Webserver. Es geht um den Kubernetes-Controller aus der Community (ingress-nginx), nicht um das NGINX-Projekt.

Die gute Nachricht: Du musst nicht in einem Schritt auf eine komplett neue Konfigurationswelt wechseln. Es gibt Migrationen, die sich wie ein „Soft Landing" anfühlen – inklusive Weiterverwendung vieler klassischer Ingress-NGINX-Annotationen.

Europäische Cloudplattformen vs. Hyperscaler

Wed, 11 Feb 2026 10:28:11 +0000

Europäische Cloudplattformen vs. Hyperscaler

Souveränität, Skalierung, Sicherheit und strategische Realität im Unternehmenskontext

Kaum ein IT-Thema wird derzeit so emotional diskutiert wie die Frage nach der „richtigen" Cloud: Europäische Cloudanbieter oder globale Hyperscaler wie AWS, Microsoft Azure und Google Cloud?

Die Debatte dreht sich um digitale Souveränität, Datenschutz, geopolitische Abhängigkeiten und Innovationsfähigkeit. Zwischen politischer Rhetorik und technischer Realität klafft jedoch häufig eine Lücke.

Für Unternehmen – insbesondere im Mittelstand und Enterprise-Segment – geht es nicht um Symbolik. Es geht um:

Edge-Computing im Enterprise-Kontext: Chancen und Grenzen

Wed, 11 Feb 2026 09:59:21 +0000

Edge-Computing im Enterprise-Kontext: Chancen und Grenzen

Architekturmodelle, Sicherheitsimplikationen und betriebliche Realität

Edge-Computing wird häufig als logische Weiterentwicklung der Cloud propagiert. Rechenleistung näher an der Datenquelle, geringere Latenzen, effizientere Verarbeitung großer Datenmengen – so die Theorie.

In der Praxis zeigt sich jedoch: Edge ist kein Ersatz für zentrale Cloud-Architekturen, sondern eine Ergänzung mit klar definierten Anwendungsfällen. Wer Edge-Computing im Enterprise-Kontext implementiert, muss Architektur, Sicherheit, Betrieb und Governance neu denken.

Dieser Beitrag beleuchtet Chancen, technische Architekturmodelle und die realen Grenzen von Edge-Computing in mittelständischen und großen Unternehmensstrukturen.

Multi-Cloud-Strategien für Mittelstand und Enterprise

Wed, 11 Feb 2026 09:38:48 +0000

Multi-Cloud-Strategien für Mittelstand und Enterprise

Architekturprinzipien, Governance, Sicherheit und betriebliche Realität

Multi-Cloud ist kein Trend mehr. Es ist längst operative Realität – oft gewollt, manchmal gewachsen, selten vollständig durchdacht.

Während Start-ups ihre Workloads noch vergleichsweise homogen auf einer Plattform aufbauen, sieht die Lage im Mittelstand und im Enterprise-Umfeld deutlich komplexer aus: Microsoft 365 hier, AWS-Workloads dort, SAP in einer Hyperscaler-Umgebung, Kubernetes-Cluster on-premises, Backup in einer dritten Cloud, dazu Speziallösungen für KI, Datenanalyse oder IoT.

Pharma statt Stillstand: Jahresauftakt von IHK und Wirtschaftsförderung

Wed, 11 Feb 2026 08:35:25 +0000

Die Wirtschaftsförderung Saarlouis und die IHK Saarland hatten zum wirtschaftspolitischen Jahresauftakt in die Repräsentanz der RAG nach Ensdorf eingeladen. Der Ort war bewusst gewählt – und er passte.

Außen: alte Bergwerksmauern. Innen: ein moderner, gläserner Raum.

Ein Gebäude-im-Gebäude-Konzept, das Transformation nicht nur beschreibt, sondern sichtbar macht. Die Architekten haben hier ein starkes Zeichen gesetzt. Der Kontrast aus Industriegeschichte und klarer, moderner Architektur war beeindruckend. Dazu ein aufmerksamer Service, sehr gutes Catering und eine Organisation, die vom Empfang bis zum Schlusswort reibungslos funktionierte. So muss ein Jahresauftakt aussehen.

Weekly Backlog KW 7/2026

Tue, 10 Feb 2026 11:32:56 +0000

Editorial:

Diese Woche hat vor allem eines gezeigt: Digitale Souveränität ist kein Strategiepapier, sondern Alltagsarbeit.

Politisch wird viel Einigkeit beschworen – im Saarland, im Bund, in Europa. Praktisch bleibt man oft bei dem, was „bewährt" ist. Gleichzeitig zeigen Beispiele wie Bayern mit Visavid oder die Opendesk-Piloten: Technisch ist der Umstieg längst möglich. Es fehlt selten an Software, fast immer an Konsequenz.

Besonders deutlich wird das dort, wo Mitarbeitende aus Zeitdruck zur Schatten-IT greifen. Das ist kein Fehlverhalten, sondern ein Signal: Wenn offizielle Systeme langsamer sind als Dropbox & Co., verlieren sie automatisch.

DSGVO-konforme Website Analytics mit nginx, VictoriaLogs und Grafana

Mon, 09 Feb 2026 12:00:00 +0000

TL;DR

Google Analytics, Matomo Cloud und andere SaaS-Tracking-Tools sind aus DSGVO-Sicht problematisch: Daten fließen an Dritte, Cookie-Banner nerven Besucher, und die rechtliche Grauzone bleibt.
nginx Access Logs enthalten bereits alle relevanten Daten für Website Analytics – Seitenaufrufe, Besucher-IPs, Referrer, User Agents, Response Times.
Mit strukturiertem JSON-Logging, VictoriaLogs als Log-Backend und Grafana als Dashboard entstehen vollwertige Website-Statistiken ohne ein einziges Tracking-Pixel.
Alle Daten bleiben auf Ihrer eigenen Infrastruktur. Kein Cookie-Banner nötig. Keine Drittanbieter-Abhängigkeit.
VictoriaLogs, Grafana und Kubernetes stehen als Managed Service von ayedo zur Verfügung – inklusive Bring-your-own-App für Ihre Web-Applikationen.

Das Problem mit klassischen Analytics-Tools

Die meisten Website-Betreiber greifen zu Google Analytics oder vergleichbaren SaaS-Lösungen. Das bringt drei fundamentale Probleme:

Polycrate API 0.11.31 released: SystemConfig Save Fix

Sun, 08 Feb 2026 18:00:00 +0000

Polycrate API 0.11.31 ist ein Bugfix-Release, das zwei zusammenhaengende Probleme beim Speichern der SystemConfig behebt.

JS API Client Fix

Der generierte JavaScript API Client exportiert Funktionen mit apiV1-Prefix (z.B. apiV1SystemConfigPartialUpdate). Ein Aufruf ohne diesen Prefix fuehrte in Produktion zum Fehler systemConfigPartialUpdate is not a function. In der Entwicklungsumgebung war das Problem durch gecachte aeltere JS-Dateien im Browser maskiert.

Save Bar Reactivity Fix

Nach erfolgreichem Speichern blieb die “Unsaved changes”-Leiste sichtbar. Ursache war ein Alpine.js Reactivity-Problem: die Referenzwerte fuer das Dirty-Tracking lagen in einer Closure-Variable, die Alpine nicht tracken konnte. Ein reaktiver Counter zwingt Alpine jetzt zur korrekten Re-Evaluation nach dem Save.

Polycrate API 0.11.30 released: Breach-Tracking, Operator Auto-Deployment & Backup Retention

Sun, 08 Feb 2026 16:00:00 +0000

Polycrate API 0.11.30 ist ein umfangreiches Feature-Release mit Fokus auf Performance, Automatisierung und Observability.

ServiceLevelBreach Model

SLO/SLA Breaches werden jetzt als materialisierte Records gespeichert statt bei jedem Dashboard-Aufruf live berechnet. Das bringt:

Dashboard-Ladezeiten von 3-8s auf unter 100ms
Historische Breach-Analyse (Beginn, Ende, Dauer)
Schneller API-Endpoint fuer aktuelle Breaches

Automatisches Operator-Deployment

Der Polycrate Operator wird automatisch auf alle registrierten K8sCluster ausgerollt:

Artifact-Version ueber SystemConfig konfigurierbar
Config-Hash-basierte Update-Erkennung
Bestehende manuelle Deployments werden nahtlos uebernommen

K8sCluster API Endpoint Monitoring

K8sCluster API Server werden jetzt ueber das allgemeine Endpoint-Monitoring-System ueberwacht – mit Multi-Agent-Checks, historischen Metriken und automatischer Condition-Ableitung.

Polycrate CLI 0.29.17 released: Label-basierte K8sApp Discovery & Stale-Sweep

Sun, 08 Feb 2026 12:00:00 +0000

Polycrate CLI Version 0.29.17 erweitert den Operator um label-basierte K8sApp Discovery, einen umfassenden Stale-Sweep fuer alle Discovery-Controller und behebt einen kritischen Bug beim CheckConfig Mapping.

Label-basierte K8sApp Discovery

Endkunden koennen ihre eigenen Applikationen jetzt in der Polycrate API registrieren lassen, ohne die Polycrate CLI zu nutzen. Pods mit dem Label k8sapps.polycrate.io/name werden automatisch als K8sApps erkannt und synchronisiert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    metadata:
      labels:
        k8sapps.polycrate.io/name: my-app
    spec:
      containers:
        - name: app
          image: my-registry/my-app:latest

Die Discovery ist standardmaessig aktiviert und bietet Cross-Namespace-Validierung, Deduplizierung mit Secret-basierten Apps und automatisches Cleanup bei fehlenden Pods.

Das Gehirn-Modell: Warum die Von-Neumann-Architektur am Edge bald ausgedient hat

Tue, 03 Feb 2026 11:50:07 +0000

Seit Jahrzehnten folgen fast alle Computer der Von-Neumann-Architektur: Eine strikte Trennung von Prozessor (CPU) und Speicher. Daten müssen ständig zwischen diesen beiden Einheiten hin- und hergeschoben werden. Im Zeitalter von Cloud-Computing und Desktop-PCs war das effizient genug. Doch für die Edge-Intelligence von morgen ist dieses Modell ein Flaschenhals – sowohl bei der Geschwindigkeit als auch beim massiven Energieverbrauch.

Das menschliche Gehirn hingegen arbeitet völlig anders: Speicher und Verarbeitung sind eins. Es ist “neuromorph”. Genau diesen Ansatz kopieren wir jetzt für die nächste Generation der IoT-Infrastruktur.

Infrastructure as an Asset: Wie IT-Architektur den Unternehmenswert steigert

Tue, 03 Feb 2026 11:41:22 +0000

In der traditionellen Betriebswirtschaft wird IT-Infrastruktur oft als notwendiges Übel betrachtet – eine Kostenstelle, die es zu minimieren gilt. Doch im Zeitalter der digitalen Disruption ist dieses Denken gefährlich. Eine moderne, skalierbare Infrastruktur ist kein Kostenfaktor, sondern ein strategischer Vermögenswert (Asset).

Unternehmen mit einer agilen Cloud-Native-Architektur sind am Markt deutlich mehr wert als Wettbewerber mit veralteten Legacy-Systemen. Der Grund ist simpel: Die Architektur bestimmt die Time-to-Market, die Skalierbarkeit und die Risikoprofile.

Edge-to-Core: Warum die Intelligenz Ihrer IT an den Rand wandert

Tue, 03 Feb 2026 11:34:03 +0000

In den letzten zehn Jahren war die Marschrichtung klar: Alle Daten und Prozesse wandern in die zentrale Cloud. Doch wir stoßen an physikalische und ökonomische Grenzen. Wenn ein autonomes System in einer Fabrik auf ein Hindernis reagiert oder eine KI-gestützte Qualitätskontrolle am Fließband Millimeter-Entscheidungen trifft, ist der Weg in ein entferntes Rechenzentrum zu weit. Die Latenz wird zum Sicherheitsrisiko, und die Kosten für den Datentransport explodieren.

Die Lösung ist eine Edge-to-Core-Architektur. Hierbei wird die Rechenpower hierarchisch verteilt: Die Intelligenz sitzt dort, wo die Daten entstehen (Edge), während die langfristige Analyse und das Training von Modellen im Zentrum (Core/Cloud) bleiben.

Schatten-IT im Rathaus: Wenn Mitarbeiter aus Verzweiflung zu Dropbox & Co. greifen

Tue, 03 Feb 2026 11:14:36 +0000

In deutschen Ämtern findet täglich ein stiller Akt der Rebellion statt. Wenn der offizielle Dienstweg für den Datenaustausch mit einem Architekturbüro über das „sichere Postfach" drei Tage dauert und fünf manuelle Freigaben erfordert, schickt der Sachbearbeiter den Plan stattdessen kurz über seinen privaten WeTransfer-Account. Wenn die Abstimmung im Krisenstab über das offizielle Telefonat zu träge ist, wird eine WhatsApp-Gruppe eröffnet.

Diese Schatten-IT ist das Fieber eines kranken IT-Systems. Sie entsteht immer dort, wo die offizielle Infrastruktur die Mitarbeiter nicht unterstützt, sondern behindert. Das Problem: In dem Moment, in dem die Daten den „sicheren Hafen" der Behörden-IT verlassen, verliert der Staat die Souveränität über die Informationen seiner Bürger.

Digitaler Burnout im Amt: Wie schlechte IT den Fachkräftemangel verschärft

Tue, 03 Feb 2026 10:56:20 +0000

Die Verwaltung hat ein massives Imageproblem bei IT-Talenten. Junge Cloud-Architekten und DevOps-Engineers assoziieren den öffentlichen Dienst oft mit „Legacy-Hölle", Faxgeräten und starren Hierarchien. In einem Markt, in dem Experten sich ihren Arbeitgeber aussuchen können, gewinnt die öffentliche Hand nicht über das höchste Gehalt, sondern über zwei Faktoren: Impact (Sinnhaftigkeit) und den Tech-Stack.

Ein „Weiter so" mit veralteter Infrastruktur führt in einen Teufelskreis: Die Belastung der bestehenden Teams steigt (Digitaler Burnout), Projekte verzögern sich, und die besten Köpfe wandern in die Privatwirtschaft ab.

Public Money, Public Code: Warum Steuergeld-Software allen gehören muss

Tue, 03 Feb 2026 10:43:01 +0000

Jedes Jahr fließen Milliarden an Steuergeldern in die Digitalisierung der Verwaltung. Doch oft landet dieses Geld in proprietären Lösungen: Software, deren Quellcode geheim ist, die nur von einem einzigen Anbieter gewartet werden kann und die bei jeder kleinsten Anpassung neue Lizenzgebühren kostet. Wenn die öffentliche Hand die Entwicklung von Software finanziert, stellt sich die moralische und wirtschaftliche Frage: Warum ist das Ergebnis nicht für alle zugänglich?

Die Initiative „Public Money, Public Code" fordert genau das: Öffentlich finanzierte Software muss als Open Source bereitgestellt werden. Das ist kein ideologischer Luxus, sondern eine technische Notwendigkeit für einen souveränen Staat.

Das Betriebssystem der Stadt: IoT-Architekturen für die Smart City

Tue, 03 Feb 2026 09:51:00 +0000

Eine Smart City ist ein riesiges, verteiltes Daten-Ökosystem. Sensoren messen Luftqualität, Bodenfeuchte in Parks, Parkplatzbelegungen oder Verkehrsflüsse. Die Herausforderung: Diese Daten entstehen an tausenden Endpunkten, nutzen unterschiedlichste Funkprotokolle (LoRaWAN, NB-IoT, 5G) und müssen in Echtzeit verarbeitet werden, um einen Mehrwert zu bieten.

Eine robuste Smart-City-Architektur muss das Problem der Daten-Heterogenität und der geografischen Verteilung lösen.

Die 3-Schichten-Architektur: Vom Sensor zum Dashboard

1. Connectivity Layer: LoRaWAN und LPWAN-Integration

In der Stadt sind viele Sensoren batteriebetrieben und an schwer zugänglichen Stellen verbaut.

OZG 2.0 & EfA: Die technische Architektur für den digitalen Staat

Tue, 03 Feb 2026 09:38:56 +0000

Das Ziel des Onlinezugangsgesetzes ist ehrgeizig: Alle Verwaltungsleistungen sollen digital verfügbar sein. Doch die Umsetzung scheiterte in der ersten Phase oft an der kleinteiligen föderalen Struktur. Die Lösung für die zweite Phase (OZG 2.0) ist das EfA-Prinzip. Ein Land entwickelt einen Dienst (z. B. das Elterngeld-Verfahren) und stellt diesen zentral als Cloud-Service für alle anderen Kommunen bereit.

Technisch gesehen ist dies ein massives Skalierungs- und Integrationsproblem. Es erfordert den Wechsel von lokalen “Insel-Servern” hin zu einer modernen, mandantenfähigen Cloud-Native-Plattform.

Nachhaltige Logistik-IT: Mit Cloud-Native-Technologie zum "Green Warehouse"

Tue, 03 Feb 2026 09:31:59 +0000

Die Logistikbranche hat ehrgeizige Ziele: CO2-neutrale Flotten und grüne Lagerhäuser. Doch während über alternative Antriebe und Photovoltaik auf Lagerdächern diskutiert wird, läuft im Hintergrund oft eine ineffiziente IT-Infrastruktur. Server, die 24/7 unter Volldampf laufen, obwohl nachts keine Pakete sortiert werden, verschwenden nicht nur Geld, sondern produzieren unnötige Emissionen.

Nachhaltige Logistik-IT bedeutet, dass die Infrastruktur so flexibel ist wie das Geschäft selbst. Cloud-Native-Technologien sind hier der Schlüssel, um den digitalen Fußabdruck drastisch zu reduzieren.

API-First in der Supply Chain: Partner-Integration in Rekordzeit

Tue, 03 Feb 2026 09:25:15 +0000

In einer global vernetzten Wirtschaft ist kein Logistikunternehmen eine Insel. Der Erfolg hängt davon ab, wie effizient Informationen zwischen Versendern, Speditionen, Lagern und Endkunden fließen. Doch in der Realität ist das „Onboarding" eines neuen Partners oft ein zäher Prozess: Manuelle Dateneingaben, inkompatible Dateiformate (EDI-Probleme) und langwierige IT-Abstimmungen verzögern den operativen Start um Wochen.

Die Antwort auf dieses Integrations-Dilemma ist eine API-First-Strategie. Wer seine Infrastruktur konsequent um Schnittstellen (Application Programming Interfaces) herum aufbaut, wandelt seine IT von einer geschlossenen Festung in eine offene, agile Plattform.

Digitale Souveränität in der Logistik

Tue, 03 Feb 2026 09:08:04 +0000

Daten sind das Gold der modernen Logistik. Wer weiß, wann welches Paket wo ist, wer die effizientesten Routen berechnet und wer die Schnittstellen zum Kunden kontrolliert, besitzt die Macht in der Lieferkette. Doch viele Logistikunternehmen begeben sich schleichend in eine gefährliche Abhängigkeit. Wenn Kernprozesse auf proprietären Plattformen großer US-Anbieter laufen, geben Unternehmen oft unbewusst die Kontrolle über ihr wichtigstes Gut ab: ihre strategische Unabhängigkeit.

Digitale Souveränität bedeutet in der Logistik, die volle Kontrolle über die eigene Software-Infrastruktur und die darin fließenden Daten zu behalten – ohne auf die Vorteile der Cloud zu verzichten.

Einführung des Node Readiness Controllers

Tue, 03 Feb 2026 02:00:00 +0000

TL;DR

Der Node Readiness Controller erweitert die Funktionalität der Kubernetes-Knotenbereitschaft durch die Einführung eines deklarativen Systems zur Verwaltung von Knoten-Taints. Dies ermöglicht eine präzisere Steuerung der Knotenverfügbarkeit, indem spezifische Infrastrukturabhängigkeiten berücksichtigt werden und unterschiedliche Anforderungen an die Betriebsbereitschaft in heterogenen Clustern durchgesetzt werden können.

Hauptinhalt

Im traditionellen Kubernetes-Modell wird die Eignung eines Knotens für Arbeitslasten durch einen einzigen binären “Bereit”-Zustand bestimmt. In modernen Kubernetes-Umgebungen sind jedoch komplexe Infrastrukturabhängigkeiten erforderlich, damit Knoten zuverlässig Pods hosten können. Der Node Readiness Controller wurde entwickelt, um diese Lücke zu schließen und eine dynamische Verwaltung von Taints basierend auf benutzerdefinierten Gesundheitsindikatoren zu ermöglichen.

Polycrate API 0.11.27 released: Pod Status, DataSource & SLO Dashboard

Mon, 02 Feb 2026 14:00:00 +0000

Polycrate API 0.11.27 ist ein großes Feature-Release mit Fokus auf K8sApp Pod-Status-Tracking, DataSource-Integration und UI-Modernisierungen.

K8sApp Pod Status Tracking

Der Operator sendet jetzt Echtzeit Pod-Health-Daten für K8sApps:

Aggregierte Metriken: Total, Ready, Available, Unavailable Pods
Container-Restarts: Summe aller Restarts
Pod Details: JSON mit detaillierten Pod-Informationen
Redeploy-Erkennung: Via Pod UID und Owner UID

Die Daten werden bei der Reconciliation zur automatischen Downtime-Erkennung genutzt.

Voraussetzung: Polycrate CLI 0.29.16+

DataSource für externe Feeds

Neues ManagedObject für externe Datenquellen:

Polycrate API 0.11.29 released: Support PIN in List API

Mon, 02 Feb 2026 13:00:00 +0000

Polycrate API 0.11.29 erweitert die Organization List API um das support_pin Feld.

Neues Feature: Support PIN in List API

Das support_pin Feld ist jetzt auch in der Organization List API verfuegbar, nicht nur in der Detail-Ansicht.

Anwendungsfall: Tabellen und Listen koennen jetzt direkt den Support PIN anzeigen, ohne einen zusaetzlichen API-Call fuer jede Organization.

GET /api/v1/organizations/

{
  "results": [
    {
      "name": "connext",
      "support_pin": "88796257",
      ...
    }
  ]
}

→ Vollstaendige Release Notes

3 Schritte zu mehr digitaler Souveränität

Mon, 02 Feb 2026 12:37:22 +0000

Digitale Souveränität ist keine Haltung und kein Strategiepapier. Sie ist das Ergebnis konkreter technischer Entscheidungen. Wer Software betreibt, entscheidet zwangsläufig darüber, in welchem Rechtsraum Daten liegen, wer faktisch Zugriff hat und wie leicht oder schwer sich Abhängigkeiten später wieder auflösen lassen. Diese Entscheidungen wirken oft jahrelang – unabhängig davon, ob sie bewusst getroffen wurden oder nicht.

Dieser Beitrag beschreibt drei Schritte, mit denen Unternehmen digitale Souveränität praktisch umsetzen können. Der Fokus liegt dabei nicht auf Versprechen, sondern auf überprüfbaren Eigenschaften von Architektur, Betrieb und Prozessen.

Polycrate API 0.11.28 released: Keycloak 26.4 Organization Sync Fix

Mon, 02 Feb 2026 12:00:00 +0000

Polycrate API 0.11.28 ist ein Bugfix-Release mit einem kritischen Fix fuer die Keycloak Organization-Synchronisation.

Kritischer Fix: Keycloak 26.4 Organization Sync

Die Synchronisation von Organizations nach Keycloak schlug in Production (Keycloak 26.4.0) fehl:

Keycloak org creation failed: 400 - Empty Space not allowed.

Ursache: Keycloak 26.4.0 hat strengere Validierung eingefuehrt, die Leerzeichen im alias-Feld von Organizations ablehnt. Der bisherige Code verwendete display_name (z.B. “Connext Communication GmbH”) als alias.

Loesung:

alias verwendet jetzt den slug (keine Leerzeichen)
display_name wird in description und als Keycloak-Attribut gespeichert

Referenz: GitHub Issue #1135

Polycrate CLI 0.29.16 released: Pod Status Discovery & MCP Knowledge Base

Mon, 02 Feb 2026 12:00:00 +0000

Polycrate CLI Version 0.29.16 bringt umfassende Verbesserungen für das Monitoring von Kubernetes-Workloads und eine neue Knowledge Base für KI-gestützte Entwicklung.

K8sApp Pod Status Discovery

Der Operator sammelt jetzt Echtzeit Pod-Health-Daten für jede K8sApp und sendet sie ans Backend für SLI-basierte Downtime-Erkennung.

Neue Metriken:

Anzahl Pods (Total, Ready, Available, Unavailable)
Container-Restarts aggregiert
Redeploy-Erkennung via Pod UID/Owner UID

Pod Watch für Echtzeit-Updates:

Der Controller watched jetzt auch Pods. Änderungen triggern sofort K8sApp-Reconciliation - keine Wartezeit mehr bei Rolling Updates.

Skalierung am Limit: Wie Track & Trace Millionen Events in Echtzeit verarbeitet

Mon, 02 Feb 2026 10:44:08 +0000

Skalierung am Limit: Wie Track & Trace Millionen Events in Echtzeit verarbeitet

Während der „Peak Season" – von Black Friday bis Weihnachten – vervielfacht sich das Datenaufkommen in der Logistik schlagartig. Tracking-Plattformen werden mit Millionen von Status-Updates (Events) pro Stunde geflutet: von Scannern in Verteilzentren, Telematik-Systemen der Flotten und Millionen von Kunden, die nervös auf den „Aktualisieren"-Button im Browser klicken.

Eine klassische Datenbank-Architektur würde unter dieser Last kollabieren (Deadlocks, hohe IO-Latenzen). Um diese Datenmassen verlustfrei und in Echtzeit zu verarbeiten, bedarf es einer Cloud-Native Streaming-Architektur.

Millisekunden entscheiden: Warum Edge Computing das Gehirn des modernen Lagers ist

Mon, 02 Feb 2026 10:40:04 +0000

In einem hochautomatisierten Logistikzentrum ist Zeit die härteste Währung. Wenn ein autonomes Transportsystem (AGV) an eine Kreuzung fährt oder ein High-Speed-Sorter ein Paket scannt, muss die Entscheidung über den weiteren Weg in Millisekunden fallen. Eine Verzögerung von nur einer halben Sekunde – verursacht durch die Signallaufzeit in eine entfernte Cloud (Latenz) – würde den gesamten Warenstrom ins Stocken bringen oder zu physischen Kollisionen führen.

Edge Computing ist die technologische Antwort auf diese Herausforderung. Es bringt die Rechenpower weg vom fernen Rechenzentrum und direkt an die „Kante" (Edge) des Geschehens: in das lokale Netzwerk des Warehouse.

Weekly Backlog KW 6/2026

Mon, 02 Feb 2026 10:34:58 +0000

Regulierung wird Code, Open Source wird Infrastruktur, Souveränität wird… Marketing?

🧠 Editorial

2026 wird gern als Übergangsjahr verkauft. Übergang wohin, bleibt meist offen. In der Praxis ist 2026 eher das Jahr, in dem Ausreden nicht mehr funktionieren. Regulierung kommt nicht mehr als PDF, sondern als Feature-Requirement. Sicherheit ist kein IT-Thema mehr, sondern Vorstandssache. Und digitale Souveränität? Wird weiter gepredigt – während parallel neue Abhängigkeiten betoniert werden.

Diese Woche zeigt ziemlich gut, wo Europa gerade steht: technisch klarer als früher, politisch aber immer noch erstaunlich inkonsequent.

Business Continuity in der Logistik: Wenn die IT steht, steht die Lieferkette

Mon, 02 Feb 2026 10:29:47 +0000

In der Logistik wird Erfolg in Taktraten gemessen. Ein modernes Logistikzentrum ist ein hochfrequentes Uhrwerk aus Warenwirtschaftssystemen (WMS), Transport-Management (TMS) und automatisierten Sortieranlagen. Wenn hier die IT-Infrastruktur für auch nur 15 Minuten ausfällt, entsteht ein Domino-Effekt: LKW stauen sich an den Rampen, Lieferzeitversprechen im E-Commerce platzen und im schlimmsten Fall stehen Produktionsbänder bei Industriekunden still.

„Resilienz" ist in der Logistik-IT kein Modewort, sondern eine Überlebensstrategie. Es geht darum, eine Infrastruktur zu schaffen, die Fehlertoleranz systemisch eingebaut hat.

IT-Gesetze 2026:

Mon, 02 Feb 2026 10:21:51 +0000

Das Jahr, in dem europäische Regulierung operativ wird

2026 ist kein Jahr neuer digitalpolitischer Großankündigungen. Es ist das Jahr, in dem europäische Digitalgesetze ihre Komfortzone verlassen und in den operativen Alltag von Unternehmen eindringen. Nicht als abstrakte Leitlinien, sondern als konkrete Anforderungen an Produkte, Prozesse, Entscheidungswege und Verantwortlichkeiten.

Der entscheidende Punkt: Europa reguliert nicht mehr „Technologie" im Allgemeinen. Es reguliert technische Eigenschaften. Wer das unterschätzt, wird 2026 viel Zeit mit Fristen und 2027 viel Geld mit Nachrüstungen verbringen.

Fachkräftemangel in der Klinik-IT: Managed Plattformen als strategischer Hebel

Mon, 02 Feb 2026 10:11:38 +0000

Fachkräftemangel in der Klinik-IT: Managed Plattformen als strategischer Hebel

Der Fachkräftemangel in der Klinik-IT stellt eine große Herausforderung dar. Um dieser Problematik zu begegnen, setzen viele Einrichtungen auf Managed Plattformen. Diese bieten nicht nur eine effiziente Lösung, sondern auch die Möglichkeit, moderne Technologien wie Container und Cloud-native Ansätze zu integrieren.

Durch den Einsatz von Managed Plattformen können Kliniken ihre IT-Ressourcen optimieren und gleichzeitig die Compliance-Anforderungen, wie die DSGVO, besser erfüllen. Dies ermöglicht eine schnellere Anpassung an sich verändernde Rahmenbedingungen und steigert die Effizienz der IT-Abteilungen.

Datenverarbeitung am Patientenbett: Warum Edge Computing die Klinik-IT revolutioniert

Mon, 02 Feb 2026 10:00:57 +0000

In der Theorie klingt das Versprechen der Cloud verlockend: Alle Daten werden zentral gespeichert und verarbeitet. Doch in der hochsensiblen Umgebung eines Krankenhauses stößt die reine Cloud-Lösung schnell an physikalische und regulatorische Grenzen. Wenn ein KI-gestütztes Assistenzsystem während einer Operation Videodaten analysiert oder ein Patientenmonitor Vitalwerte in Echtzeit auswertet, ist jede Millisekunde Latenz ein Risiko.

Hier kommt Edge Computing ins Spiel. Anstatt Datenpakete über das öffentliche Internet in ein fernes Rechenzentrum zu schicken, wird die Rechenleistung direkt dorthin verlagert, wo die Daten entstehen: in die Filiale, das Labor oder direkt in den OP-Saal.

MedTech-Innovationen beschleunigen: Compliance-ready von der ersten Codezeile

Mon, 02 Feb 2026 09:54:06 +0000

Für MedTech-Unternehmen und Entwickler von Digitalen Gesundheitsanwendungen (DiGAs) ist der Weg zum Markt kein Sprint, sondern ein Hürdenlauf durch regulatorische Anforderungen. Die Einhaltung der Medical Device Regulation (MDR) oder der Anforderungen des BfArM ist oft zeitaufwendiger als die eigentliche Programmierung des Produkts.

Das Problem: In vielen Unternehmen sind Software-Entwicklung und Compliance-Dokumentation zwei getrennte Welten. Dies führt zu langen Release-Zyklen und manuellen Audits, die das Innovationstempo massiv drosseln. Die Lösung liegt in der Automatisierung der Vertrauenswürdigkeit durch eine moderne DevSecOps-Pipeline.

Apache Kafka: Die Referenz-Architektur für Event-Driven Data Streaming

Mon, 02 Feb 2026 09:49:01 +0000

TL;DR

In der modernen IT ruhen Daten nicht, sie fließen. Apache Kafka ist das zentrale Nervensystem für diese Echtzeit-Datenströme. Während Cloud-Dienste wie AWS MSK zwar die Infrastruktur bereitstellen, entziehen sie dem Nutzer oft die Kontrolle über kritische Konfigurationen und Updates. Der Betrieb von Kafka auf Kubernetes (via Operator) demokratisiert diese Technologie: Er kombiniert die Einfachheit eines Managed Services mit der Flexibilität von Open Source, sodass Sie volle Hoheit über Durchsatz, Latenz und Kosten behalten.

Zero-Downtime in der Klinik-IT: Wenn Ausfallsicherheit Leben schützt

Mon, 02 Feb 2026 09:48:36 +0000

In der modernen Akutmedizin ist die IT kein unterstützender Prozess mehr – sie ist Teil der Behandlung. Wenn bildgebende Verfahren (PACS), Laborbefunde oder die digitale Medikation nicht verfügbar sind, verzögern sich lebenswichtige Entscheidungen. Ein “IT-Ausfall” in einem Krankenhaus der Maximalversorgung ist daher ein klinisches Risiko.

Um eine Verfügbarkeit von 99,99 % oder höher zu erreichen, reicht klassische Hardware-Redundanz nicht aus. Es bedarf einer intelligenten Orchestrierung, die Fehler erkennt, bevor sie den Anwender erreichen.

Keycloak: Die Referenz-Architektur für Enterprise Identity & Access Management (IAM)

Mon, 02 Feb 2026 09:48:06 +0000

TL;DR

Identität ist der neue Perimeter. Wer Login und Nutzerverwaltung an SaaS-Dienste wie Auth0 oder AWS Cognito auslagert, genießt anfangs Komfort, läuft aber in eine doppelte Falle: Exponentiell steigende Kosten bei wachsenden Nutzerzahlen (Pay-per-MAU) und eingeschränkte Anpassbarkeit. Keycloak ist der Industriestandard, um diese Hoheit zurückzugewinnen. Es bietet eine vollständige, Open-Source-basierte IAM-Lösung, die unbegrenzt skaliert, sich mit jedem bestehenden Verzeichnis (AD/LDAP) verbindet und keine “Steuer” pro aktivem Nutzer erhebt.

1. Das Architektur-Prinzip: Identity Brokering & Federation

SaaS-Lösungen wollen oft die einzige Datenbank für Ihre Nutzer sein. In der Realität liegen Identitäten aber überall: Im Active Directory der Firma, in Social-Media-Accounts (Google/GitHub) oder in Partner-Datenbanken.

KeyDB: Die Referenz-Architektur für Multithreaded High-Performance Caching

Mon, 02 Feb 2026 09:47:36 +0000

TL;DR

Redis ist der unangefochtene König der In-Memory-Datenbanken, hat aber eine architektonische Achillesferse: Es ist Single-Threaded. Selbst auf einem teuren Server mit 64 Kernen nutzt Redis nur einen einzigen Kern – der Rest liegt brach. KeyDB ist ein High-Performance-Fork von Redis, der diese Fessel sprengt. Durch echtes Multithreading nutzt KeyDB die gesamte Hardware-Power, bietet bis zu 5x mehr Durchsatz und bleibt dabei 100% kompatibel. Wer KeyDB nutzt, skaliert vertikal statt horizontal und spart sich komplexe Cluster-Architekturen.

Kyverno: Die Referenz-Architektur für Kubernetes-native Policy Management

Mon, 02 Feb 2026 09:47:02 +0000

TL;DR

Kubernetes ist standardmäßig permissiv: Es erlaubt Entwicklern fast alles, auch unsichere Konfigurationen (z.B. Container als “Root” laufen lassen). Um dies zu verhindern, brauchte man bisher Policy-Engines wie OPA Gatekeeper, die eine steile Lernkurve erfordern (Programmiersprache Rego). Kyverno demokratisiert Sicherheit. Es ist eine Policy-Engine, die für Kubernetes gebaut wurde. Policies sind einfaches YAML. Kyverno kann nicht nur blockieren (Validierung), sondern Ressourcen aktiv reparieren (Mutation) und Standard-Konfigurationen erzeugen (Generation) – ohne dass Entwickler ihren Workflow ändern müssen.

Loki: Die Referenz-Architektur für kosteneffiziente Log-Aggregation

Mon, 02 Feb 2026 09:46:17 +0000

TL;DR

Logs sind das unverzichtbare “Gedächtnis” jeder Applikation, aber ihre Speicherung explodiert oft zur größten Kostenposition in der Cloud. Traditionelle Lösungen wie Elasticsearch oder Splunk indexieren jedes einzelne Wort – das macht sie mächtig, aber extrem ressourcenhungrig. Loki verfolgt einen radikal anderen Ansatz: “Like Prometheus, but for Logs.” Es indexiert nur die Metadaten (Labels), nicht den Inhalt. Das Ergebnis ist ein Log-System, das Petabytes an Daten zu einem Bruchteil der Kosten in günstigem Object Storage (S3) speichert und nahtlos in Grafana integriert ist.

Digitale Souveränität in der Medizin: Warum Patientendaten nicht in die Public Cloud gehören

Mon, 02 Feb 2026 09:42:35 +0000

Die Digitalisierung im Gesundheitswesen verspricht enorme Fortschritte: von der telemedizinischen Betreuung über KI-gestützte Diagnostik bis hin zur elektronischen Patientenakte. Doch mit der Vernetzung wächst eine grundlegende Sorge: Wer hat im Zweifelsfall Zugriff auf die sensibelsten Informationen, die ein Mensch besitzt?

Für Krankenhäuser, Pharmaunternehmen und MedTech-Startups ist die Wahl der IT-Infrastruktur heute keine rein technische Entscheidung mehr. Es ist eine ethische und rechtliche Grundsatzentscheidung. Wer auf klassische US-amerikanische Public-Cloud-Anbieter setzt, begibt sich in ein Spannungsfeld zwischen technologischer Bequemlichkeit und dem Risiko des Datenabflusses.

Retail Excellence: Warum die Infrastruktur über den Erfolg im modernen Handel entscheidet

Mon, 02 Feb 2026 09:02:54 +0000

1. Executive Summary

Der Einzelhandel befindet sich in der größten Transformation seiner Geschichte. Die Trennung zwischen stationärem Geschäft und E-Commerce existiert nicht mehr. Kunden erwarten Echtzeit-Verfügbarkeit, personalisierte Erlebnisse und absolute Ausfallsicherheit. Dieses Dokument fasst zusammen, wie eine moderne Software-Infrastruktur diese Anforderungen vom Risiko zum Wettbewerbsvorteil wandelt.

2. Die fünf Säulen der digitalen Handels-Infrastruktur

I. Business Continuity & Hochverfügbarkeit

Der Kern: Ein Systemausfall am Point of Sale ist kein IT-Problem, sondern ein betriebswirtschaftlicher Notfall.
Die Lösung: Selbstheilende Systeme und geografische Redundanz sichern den Umsatz, auch wenn einzelne Komponenten versagen.

II. Elastizität und Skalierung

Der Kern: Starre Server-Kapazitäten sind entweder zu teuer oder bei Lastspitzen (Black Friday) zu schwach.
Die Lösung: Cloud-Native-Strukturen, die automatisch mit dem Kundenverkehr atmen, garantieren Performance bei optimierten Kosten.

III. Digitale Souveränität

Der Kern: Die Abhängigkeit von großen US-Hyperscalern (wie AWS) bedeutet oft die Finanzierung des eigenen größten Konkurrenten.
Die Lösung: Nutzung von Open-Source-Standards und europäischem Hosting, um die Hoheit über Geschäftsdaten und strategische Freiheit zurückzugewinnen.

IV. Die intelligente Filiale (Edge Computing)

Der Kern: Omnichannel scheitert oft an der schwachen Vernetzung der physischen Stores.
Die Lösung: Edge-Computing bringt Cloud-Technik in die Filiale – für Echtzeit-Inventur, Offline-Resilienz und zentrale Steuerbarkeit.

V. Agilität und Time-to-Market

Der Kern: Zu lange Release-Zyklen bremsen Innovationen aus.
Die Lösung: Automatisierte Software Delivery (CI/CD) ermöglicht es, neue Features in Stunden statt in Monaten live zu bringen.

3. Strategischer Fahrplan für Entscheider

Status Quo Audit: Identifikation von Legacy-Flaschenhälsen und Single-Points-of-Failure.
Souveränitäts-Check: Prüfung der Abhängigkeiten von Drittanbietern.
Schrittweise Modernisierung: Sanfte Transformation statt „Big Bang".

FAQ: Strategische IT-Investitionen im Handel

Warum ist eine Plattform-Strategie besser als Einzellösungen? Einzellösungen schaffen Datensilos und erhöhen den Wartungsaufwand. Eine einheitliche Plattform bietet einen standardisierten „Baukasten", der Synergien zwischen Online-Shop, Filiale und Logistik hebt.

Echtzeit statt Schätzung: Warum die Bestandsführung in der Cloud über den Verkaufserfolg entscheidet

Mon, 02 Feb 2026 08:50:30 +0000

Nichts ist für einen Kunden frustrierender als das „Click & Collect"-Erlebnis, das mit einer Stornierung endet. Man sieht online: „Verfügbar in Ihrer Filiale", fährt hin, und steht vor einem leeren Regal. Der Grund dafür ist meist eine veraltete IT-Architektur, die Bestände nur zeitversetzt oder in nächtlichen Stapelverarbeitungen (Batch-Processing) synchronisiert.

In einer Welt, in der Kunden absolute Transparenz erwarten, wird die Echtzeit-Inventur zum entscheidenden Wettbewerbsvorteil. Doch technisch gesehen ist es eine der größten Herausforderungen im Handel: Wie bringt man tausende Kassen, Webshops und Lagerstandorte dazu, in Millisekunden denselben Datenstand zu teilen?

Zukunftssicher ohne Risiko: Wie Sie Ihre gewachsene Warenwirtschaft sanft modernisieren

Mon, 02 Feb 2026 08:43:45 +0000

In vielen Handelsunternehmen bildet ein über Jahrzehnte gewachsenes Warenwirtschaftssystem (ERP) das Herzstück der IT. Diese Systeme sind stabil und bewährt, wurden jedoch für eine Welt vor dem E-Commerce konzipiert. In der heutigen Omnichannel-Realität werden sie oft zum Flaschenhals: Die API-Schnittstellen sind zu langsam für den Webshop, Echtzeit-Bestandsabfragen überlasten die Datenbank, und neue Features brauchen Monate für die Implementierung.

Die größte Sorge vieler Entscheider ist ein „Big Bang"-Szenario – der komplette Austausch des Systems. Doch es gibt einen sichereren Weg: Die schrittweise Modernisierung durch Umkapselung.

Neue Umstellung von cgroup v1 CPU-Anteilen auf v2 CPU-Gewichtung

Fri, 30 Jan 2026 16:00:00 +0000

TL;DR

Die Umstellung von cgroup v1 auf cgroup v2 bringt eine verbesserte Umrechnungsformel für CPU-Anteile mit sich, die die Priorität von Kubernetes-Workloads gegenüber Systemprozessen optimiert. Die neue quadratische Formel ermöglicht eine genauere Zuordnung von CPU-Gewichtungen und verbessert die Granularität der Ressourcenverteilung innerhalb von Containern.

Hauptinhalt

Die Migration von cgroup v1 zu cgroup v2 in Kubernetes hat wesentliche Änderungen in der Handhabung von CPU-Ressourcen zur Folge. Während cgroup v1 CPU-Anteile einfach durch die Zuweisung von CPU-Anforderungen in millicpu definiert, verwendet cgroup v2 ein neues Konzept von CPU-Gewichtungen. In cgroup v1 wurde ein Container, der 1 CPU anforderte, mit 1024 CPU-Anteilen (cpu.shares) bewertet. Im Gegensatz dazu wird in cgroup v2 ein Standardwert von 100 für CPU-Gewichtungen (cpu.weight) verwendet, was zu einer signifikanten Abweichung in der Priorität führt.

Sicher vernetzt: Strategien gegen Ransomware und Datenklau im modernen Handel

Fri, 30 Jan 2026 08:23:44 +0000

Die Digitalisierung des Point of Sale (PoS) bietet enorme Vorteile, bringt aber eine neue Gefahr mit sich: Jedes vernetzte Gerät in der Filiale – vom smarten Kühlschrank bis zum Handheld-Scanner – ist ein potenzieller Einstiegspunkt für Schadsoftware. Ein Ransomware-Angriff, der die Kassensysteme am Wochenende lahmlegt, führt nicht nur zu massiven Umsatzeinbußen, sondern beschädigt das Kundenvertrauen nachhaltig.

Um diese verteilten Infrastrukturen zu schützen, reicht eine einfache Firewall am Filialausgang nicht mehr aus. Es bedarf eines ganzheitlichen Ansatzes, der Sicherheit als integralen Bestandteil der Software-Auslieferung begreift.

Polycrate API 0.11.26 released: Downtime Recovery Fix

Thu, 29 Jan 2026 19:00:00 +0000

Polycrate API 0.11.26 ist ein Hotfix-Release mit einem kritischen Bugfix für das Downtime Recovery.

Kritischer Fix: Downtime Recovery Deadlock

Ein Deadlock verhinderte, dass Endpoints aus Downtimes recovered werden konnten:

Problem:

Endpoint ging DOWN → Downtime wurde erstellt
Endpoint recovered, hatte aber noch SLO_BREACH → Status DEGRADED
Downtime wartete auf “nicht mehr DOWN”, aber Endpoint war DEGRADED
→ Deadlock - Downtime konnte sich nie schließen

Lösung: Ein Endpoint gilt jetzt als “recovered” sobald er nicht mehr DOWN ist. DEGRADED (z.B. wegen SLO Breach) reicht aus.

Polycrate API 0.11.25 released: Bugfixes & Performance

Thu, 29 Jan 2026 18:00:00 +0000

Polycrate API 0.11.25 ist ein Patch-Release mit wichtigen Bugfixes und Performance-Optimierungen.

Kritischer Fix: SLO/SLA Breach State

Ein kritischer Bug wurde behoben, bei dem ein SLO/SLA Breach zu einem Teufelskreis führte:

Endpoint mit erschöpftem Error Budget → SLO_BREACH
SLO_BREACH führte zu DOWN State
DOWN triggerte automatisch neue Downtime
Downtime verbrauchte weiteres Error Budget → Infinite Loop

Fix: SLO_BREACH und SLA_BREACH führen jetzt zu DEGRADED, nicht DOWN.

Weitere Bugfixes

Artifact Naming: Bei Polycrate Discovery wurden Artifacts ohne korrekten Namen angelegt
Loadbalancer Chart: Bandwidth-Graph zeigte keine Balken trotz vorhandener Daten
Observability Auth: VictoriaLogs 401 und VictoriaMetrics 400 Fehler behoben

Neue Features

SLO/SLA Downtime History

Die SLO/SLA Status Box zeigt jetzt eine Tabelle der vergangenen Downtimes mit Error Budget Impact:

Polycrate API 0.11.24 released: SRE/SLO Framework & Observability Metrics

Thu, 29 Jan 2026 15:00:00 +0000

Polycrate API 0.11.24 ist ein großes Feature-Release mit Fokus auf Site Reliability Engineering (SRE) Standards und Observability Metrics.

SRE/SLA/SLO Framework

Vollständige Integration moderner SRE-Standards:

SLO/SLA Targets: Konfigurierbare Ziele pro Object (Default: 99.9% SLO, 99.0% SLA)
Error Budget: Automatische Berechnung und Tracking in Minuten
Criticality: Gewichtung für Aggregation (tier-1 bis tier-4)
Conditions: SLO_WARNING, SLO_BREACH, SLA_BREACH

Scope: Per AGB wird Availability auf Object-Level (Endpoint, K8sCluster, K8sApp) berechnet.

UI-Integration:

SLO/SLA Status Boxes in Detail Views
Organization Overview mit Tracked Objects, At Risk, Breached Counts
V2 Table Columns für Availability und Active Downtime

TL;DR

Mon, 26 Jan 2026 10:02:53 +0000

Die Zeit der US-Dominanz ist vorbei

Gestern hat das Europäische Parlament eine Entscheidung getroffen, die in ihrer Tragweite weit über die übliche Brüsseler Symbolpolitik hinausgeht. Mit breiter, fraktionsübergreifender Mehrheit haben EVP, Sozialdemokraten, Liberale und Grüne einen Bericht verabschiedet, der Europas digitale Realität unmissverständlich benennt: Die technologische Abhängigkeit von US-Konzernen ist kein Betriebsunfall, sondern ein strategisches Risiko. Und sie ist politisch nicht länger akzeptabel.

Der Bericht markiert einen Kurswechsel. Er formuliert erstmals geschlossen den Anspruch, die digitale Infrastruktur Europas als souveräne Aufgabe zu begreifen – vergleichbar mit Energieversorgung oder Verkehr. Cloud, Künstliche Intelligenz und Software werden nicht mehr als neutrale Marktprodukte behandelt, sondern als Machtfaktoren. Genau das sind sie längst.

Retail-Souveränität: Warum Sie Ihre Plattform nicht dem größten Konkurrenten überlassen dürfen

Mon, 26 Jan 2026 09:55:17 +0000

Im modernen Einzelhandel findet der härteste Konkurrenzkampf nicht mehr nur im Regal statt, sondern auf der Datenebene. Wer versteht, was der Kunde morgen kaufen will, gewinnt. Doch während Retailer Millionen in ihre digitale Transformation investieren, begehen viele einen folgenschweren strategischen Fehler: Sie bauen ihre gesamte digitale Existenz auf der Infrastruktur von Amazon Web Services (AWS) auf.

Das Paradoxon ist offensichtlich: Man zahlt monatlich hohe Gebühren an genau das Unternehmen, das mit aggressiver Preispolitik, Eigenmarken und unschlagbarer Logistik versucht, den stationären Handel und unabhängige E-Commerce-Brands zu verdrängen. Bei ayedo zeigen wir Ihnen, wie Sie technologische Exzellenz erreichen, ohne Ihre Unabhängigkeit an einen Wettbewerber zu verkaufen.

Keine Angst vor dem Black Friday: So skaliert Ihre Retail-Infrastruktur automatisch mit Ihren Kunden

Mon, 26 Jan 2026 09:48:41 +0000

Es ist der Albtraum jedes E-Commerce-Leiters und CTOs im Handel: Der Black Friday steht vor der Tür, die Marketing-Kampagnen laufen auf Hochtouren, und genau im Moment des größten Kundenansturms geht der Onlineshop in die Knie. Ladezeiten explodieren, der Checkout bricht ab, und die mühsam akquirierten Kunden landen frustriert beim Wettbewerb.

Das Problem ist oft eine starre Infrastruktur, die für den „Normalbetrieb" ausgelegt ist, aber bei extremen Lastspitzen wie ein Kartenhaus zusammenbricht. Mit der ayedo Software Delivery Platform gehört dieses Szenario der Vergangenheit an. Wir machen Ihre Infrastruktur elastisch.

Wenn die Kasse stillsteht: Warum Hochverfügbarkeit Einzelhandel über das Überleben entscheidet

Mon, 26 Jan 2026 09:42:06 +0000

Im Einzelhandel ist die Zeitrechnung gnadenlos. Ein Systemausfall am Samstagmittag, während der umsatzstärksten Stunden, ist für einen Retailer kein bloßes „IT-Problem" – es ist ein geschäftskritischer Notfall. Wenn das Kassensystem streikt, der Online-Bestand nicht synchronisiert oder die App für das Treueprogramm keine Daten liefert, wandert der Kunde ab. Und meistens kommt er an diesem Tag nicht zurück.

In einer Welt, in der Online und Offline nahtlos verschmelzen (Omnichannel), ist die IT das Nervensystem des Handels. Doch wie stellt man sicher, dass dieses System auch unter Höchstlast absolut ausfallsicher bleibt?

Weekly Backlog KW 5/2026

Mon, 26 Jan 2026 09:40:36 +0000

🧠 Editorial

Diese Woche markiert eine Verschiebung. Weg von der Frage, ob digitale Abhängigkeiten problematisch sind, hin zur Frage, wie lange Europa sie sich noch leisten will. Ob Straßburg, Bern oder Berlin: Überall wird sichtbar, dass Cloud, Software und digitale Infrastruktur keine neutralen Werkzeuge mehr sind, sondern Machtmittel. Wer sie kontrolliert, setzt Regeln. Wer sie nutzt, lebt mit den Konsequenzen.

Die gute Nachricht: Das Problem wird nicht mehr nur technisch diskutiert. Die schlechte: Die Konsequenzen sind größer, als viele bisher wahrhaben wollten.

Optimierung Ihrer Docker Hardened Images Enterprise-Testversion – Teil 3

Sun, 25 Jan 2026 17:51:40 +0000

TL;DR

Docker Hardened Images (DHI) bieten eine sichere Grundlage für Containeranwendungen, erfordern jedoch Anpassungen für spezifische Anwendungen. Es gibt zwei Hauptstrategien zur Anpassung: die Verwendung der Docker Hub UI zur Erstellung von “Golden Images” und das Multi-Stage-Build-Muster, das Flexibilität für Entwickler bietet.

Hauptinhalt

Docker Hardened Images sind so konzipiert, dass sie minimal und sicher sind, indem sie keine Paketmanager oder Shells enthalten. Dies schützt vor potenziellen Angriffen, da ein Angreifer auf ein leeres Werkzeugset stößt. Dennoch benötigen Entwickler oft zusätzliche Tools, um Anwendungen zu konfigurieren oder zu überwachen. In diesem Kontext werden zwei Strategien zur Anpassung von DHIs vorgestellt.

Optimierung Ihrer Docker Hardened Images Enterprise-Testversion – Teil 2

Sat, 24 Jan 2026 20:24:39 +0000

TL;DR

Docker Hardened Images (DHI) bieten eine verbesserte Sicherheit und Compliance für Container-Images. Die Verifizierung dieser Images erfolgt durch die Analyse von attestierten Metadaten, die kryptographisch signiert sind. Dieser Prozess ermöglicht es Unternehmen, die Sicherheitsstandards ihrer Container-Deployments unabhängig zu bestätigen.

Hauptinhalt

Docker Hardened Images haben sich als effektives Mittel zur Verbesserung der Sicherheit von Container-Anwendungen etabliert. In einer früheren Analyse wurde festgestellt, dass durch die Migration auf DHI eine vollständige Eliminierung von Sicherheitsanfälligkeiten, eine Reduzierung der verwendeten Pakete um 90 % und eine Verringerung der Bildgröße um 41,5 % erreicht werden konnte. Um jedoch die Sicherheit und Compliance dieser Images unabhängig zu verifizieren, ist ein strukturierter Verifizierungsprozess erforderlich.

Polycrate CLI 0.29.15 released: TLS Serialization Fix

Fri, 23 Jan 2026 15:30:00 +0000

Mit Polycrate CLI 0.29.15 haben wir den Root Cause eines hartnäckigen Bugs behoben, bei dem Endpoints mit tls: false in der API nicht korrekt in die Kubernetes CRD übernommen wurden.

Root Cause: omitempty + default=true

Das Problem lag in der CRD-Definition des Endpoint-Typs:

// Vorher (fehlerhaft)
// +kubebuilder:default=true
TLS bool `json:"tls,omitempty"`

Bei TLS=false (Go Zero-Value für bool) wurde das Feld wegen omitempty nicht ins JSON serialisiert. Kubernetes wendete dann den CRD-Default true an - das Update wurde effektiv ignoriert.

Polycrate CLI 0.29.13 released: Debug Logging & NetworkPolicy Fix

Fri, 23 Jan 2026 15:00:00 +0000

Polycrate CLI Version 0.29.13 bringt Debug-Logging für den Operator-Startup und einen wichtigen NetworkPolicy Fix.

Startup Debug Logging

Bei langsamem Operator-Startup war bisher unklar, welcher Controller gerade registriert wird. Mit loglevel: 2 werden jetzt detaillierte Logs angezeigt:

Registering SoftwareDeliveryPlatform controller...
Registering EndpointDiscovery controller...
Checking Velero CRDs...
BackupDiscovery controller skipped (Velero CRDs not installed)
...

NetworkPolicy Fix

Die NetworkPolicy wurde auf Egress ALLOW ALL gesetzt, um CNI-Kompatibilitätsprobleme zu beheben. Verschiedene CNI-Implementierungen (Cilium, Calico) behandeln API Server Traffic unterschiedlich, was zu Timeouts bei der CRD-Discovery führte.

Polycrate CLI 0.29.14 released: Backup & Endpoint Fixes

Fri, 23 Jan 2026 14:30:00 +0000

Mit Version 0.29.14 haben wir zwei wichtige Bugfixes im Polycrate Operator implementiert, die die Zuverlässigkeit der Backup-Schedule-Synchronisation und des Endpoint-Monitorings deutlich verbessern.

BackupSchedule K8sCluster UUID Fix

Der BackupSchedule Controller sendete bisher eine Null-UUID an die API, was zu folgendem Fehler führte:

Failed to create backup schedule in API
error: "Invalid pk \"00000000-0000-0000-0000-000000000000\""

Mit diesem Fix werden Backup-Schedules jetzt korrekt mit der registrierten Cluster-ID synchronisiert.

Endpoint TLS Default Fix

Ein subtiler Bug führte dazu, dass HTTP-only Endpoints fälschlicherweise als HTTPS behandelt wurden:

Automatisierung der Arm-Migration mit Docker MCP Toolkit, VS Code und GitHub Copilot

Fri, 23 Jan 2026 14:00:00 +0000

TL;DR

Die Automatisierung der Migration von Anwendungen von x86 zu Arm64 wird durch das Docker MCP Toolkit, VS Code und GitHub Copilot erheblich vereinfacht. Diese Tools ermöglichen es, den gesamten Migrationsprozess zu orchestrieren, indem sie Kompatibilitätsanalysen, Konvertierungen und Leistungsprognosen automatisieren, was den Zeitaufwand von mehreren Stunden auf etwa 30 Minuten reduziert.

Hauptinhalt

Die Migration von Workloads von x86 zu Arm64 gewinnt zunehmend an Bedeutung, da Organisationen versuchen, Cloud-Kosten zu senken und die Leistung zu verbessern. Plattformen wie AWS Graviton, Azure Cobalt und Google Cloud Axion haben Arm-basierte Computing-Lösungen populär gemacht, die Kosteneinsparungen von 20-40 % und verbesserte Leistung versprechen. Die Herausforderung besteht jedoch darin, Anwendungen zu migrieren, ohne dass es zu Funktionsstörungen kommt.

Polycrate API 0.11.23 released: API Key Fix & Contact Role

Fri, 23 Jan 2026 14:00:00 +0000

Polycrate API 0.11.23 bringt wichtige Fixes für die API Key Authentifizierung und erweitert das Contact-Management.

API Key Authentication Fix

User API Keys (Knox-basiert) konnten nicht für API-Zugriff verwendet werden. Die Fehlermeldung war:

{"detail":"Authentication error: Invalid agent token - credential not found"}

Ursache: Die Agent Token Authentifizierung blockierte fälschlicherweise die nachfolgenden Authenticators.

Lösung: Die Authentifizierungs-Kette funktioniert jetzt korrekt - User API Keys werden von Knox verarbeitet.

API Key Admin UI

User API Keys sind jetzt im Django Admin sichtbar:

Polycrate CLI 0.29.12 released: Operator Stability & Loglevel Fix

Fri, 23 Jan 2026 14:00:00 +0000

Polycrate CLI Version 0.29.12 behebt kritische Operator-Stabilitätsprobleme und korrigiert das Debug-Logging.

Operator Startup Fix

Der Operator wurde bei langsamem Startup von Kubernetes gekillt, weil die Health-Probes erst nach der Controller-Registrierung aktiviert wurden. Das führte zu CrashLoopBackOff bei Clustern mit vielen CRDs oder langsamer API.

Fix: Health-Checks werden jetzt direkt nach dem Manager-Setup registriert - vor der Controller-Registrierung.

Loglevel V-Level Fix

Das Loglevel 2 (Debug) und 3 (Trace) zeigten keine zusätzlichen Informationen. Die V-Levels in controller-runtime wurden jetzt korrekt gemappt:

Das autonome Unternehmen und die vier Säulen der Plattformkontrolle: Prognose 2026

Fri, 23 Jan 2026 12:03:00 +0000

TL;DR

Im Jahr 2026 wird die Rolle von KI-Agenten in Unternehmen entscheidend sein, um die Balance zwischen Entwicklergeschwindigkeit und Unternehmensgovernance zu automatisieren. Vier zentrale Kontrollmechanismen – goldene Pfade, Schutzvorrichtungen, Sicherheitsnetze und manuelle Überprüfungsworkflows – werden als Grundlage für ein autonomes Unternehmensmanagement fungieren.

Hauptinhalt

Die Integration von KI in DevOps und Plattformengineering wird zunehmend als Schlüssel zur Optimierung von Geschwindigkeit, Sicherheit und Kostenwahrnehmung identifiziert. Unternehmen erkennen, dass eine neue Governance-Struktur erforderlich ist, um die Automatisierung zu unterstützen. Die Rolle von KI wird sich von einem unterstützenden Werkzeug zu einem aktiven Agenten entwickeln, der Verantwortung für kritische Aufgaben wie Provisionierung, Sicherheit und Incident-Response übernimmt.

Polycrate CLI 0.29.11 released: TLS Debug-Logging

Fri, 23 Jan 2026 12:00:00 +0000

Polycrate CLI Version 0.29.11 verbessert die Diagnose von TLS-Problemen bei API-verwalteten Endpoints.

TLS Type-Cast Debug-Logging

Bei API-verwalteten Endpoints konnte es vorkommen, dass der TLS-Wert falsch übertragen wurde (tls: false → tls: true). Dies führte dazu, dass der Operator HTTPS-URLs auf Port 80 baute, was zu 404-Fehlern führte.

Mit dem neuen Debug-Logging werden Type-Cast-Fehler sofort sichtbar:

WARN: httpSpec[tls] type cast to bool failed
      endpoint: example.com
      tlsType: string
      tlsValue: "false"

Observability entscheidet darüber, wie gut Systeme verstanden, betrieben und weiterentwickelt werden können. Sie ist kein Add-on für den Betrieb, sondern eine zentrale Fähigkeit moderner Plattformen. Entsprechend relevant ist die Frage, wo Observability verankert wird: als konsumierter Cloud-Dienst oder als eigenständige, kontrollierbare Architektur.

AWS CloudWatch und Azure Monitor sind die nativen Observability-Dienste der großen Hyperscaler. Offene Stacks auf Basis von Grafana, VictoriaMetrics, VictoriaLogs und OpenTelemetry verfolgen einen anderen Ansatz. Beide liefern Metriken, Logs und Alerts – aber sie tun das mit grundlegend unterschiedlichen Konsequenzen für Kosten, Portabilität und Kontrolle.

AWS CodePipeline vs. Argo CD: CI/CD als Service oder als Architekturentscheidung

Wed, 21 Jan 2026 10:11:43 +0000

Service oder Architekturentscheidung?

CI/CD wird oft als Werkzeugfrage behandelt: Welcher Dienst, welche Pipeline, welcher Anbieter? In Wirklichkeit ist CI/CD eine architektonische Grundsatzentscheidung. Sie definiert, wie Deployments gedacht werden, wie stark Plattformen an Anbieter gebunden sind und wie kontrollierbar Systeme langfristig bleiben.

AWS CodePipeline und Argo CD stehen exemplarisch für zwei sehr unterschiedliche Ansätze. Das eine ist ein Cloud-Service zur Orchestrierung von Deployments. Das andere ist ein Betriebsmodell, das Deployments strukturell neu definiert.

AWS IAM & Azure Entra ID vs. authentik

Wed, 21 Jan 2026 10:09:32 +0000

Identitätsmanagement als Kontrollinstrument oder als offene Infrastruktur

Identitätsmanagement ist längst mehr als Login und Benutzerverwaltung. Es definiert, wer Zugriff auf Systeme erhält, unter welchen Bedingungen dieser Zugriff erfolgt und wie sich Sicherheit, Automatisierung und Compliance technisch durchsetzen lassen. Damit wird Identität zu einem der zentralen Machtfaktoren moderner IT-Architekturen.

AWS IAM, Azure Entra ID (ehemals Azure Active Directory) und authentik lösen alle dasselbe Grundproblem: Identitäten verwalten und Zugriffe steuern. Architektonisch stehen sie jedoch für zwei grundlegend unterschiedliche Ansätze. Das eine verankert Identität tief in einer Plattform. Das andere begreift sie als eigenständige, offene Infrastruktur.

Individueller Provider-Block-Storage vs. Ceph

Wed, 21 Jan 2026 10:06:36 +0000

Speicher als Cloud-Feature oder als kontrollierbare Plattform

Persistenter Storage gehört zu den unscheinbarsten, aber wirkungsmächtigsten Schichten moderner Plattformen. Er entscheidet darüber, ob Anwendungen skalierbar bleiben, ob Daten beweglich sind – und wie teuer ein späterer Richtungswechsel wird. Block Storage der Cloud-Provider wirkt dabei oft wie ein neutrales Infrastrukturfeature. In Wirklichkeit ist er tief in die jeweilige Plattformlogik eingebettet.

Provider-Block-Storage und Ceph lösen dasselbe Grundproblem: zustandsbehaftete Daten zuverlässig speichern. Architektonisch stehen sie jedoch für zwei gegensätzliche Modelle. Das eine bindet Storage an die Cloud. Das andere macht ihn zu einer eigenständigen, kontrollierbaren Plattformkomponente.

AWS Certificate Manager vs. cert-manager

Wed, 21 Jan 2026 10:03:35 +0000

Zertifikate als Cloud-Service oder als Teil der Plattformarchitektur

TLS-Zertifikate gelten oft als notwendiges Sicherheitsdetail. In modernen Plattformarchitekturen sind sie jedoch weit mehr als das. Zertifikate definieren, wo Vertrauen endet, wie Services miteinander sprechen und ob Sicherheitsmechanismen konsistent automatisiert sind – oder nur punktuell greifen.

AWS Certificate Manager (ACM) und cert-manager lösen dasselbe Grundproblem: Zertifikate ausstellen, erneuern und verwalten. Architektonisch verfolgen sie jedoch zwei grundverschiedene Ansätze. Das eine verlagert Zertifikatsmanagement in einen Cloud-Service. Das andere integriert es direkt in die Plattform.

AWS Redshift vs. ClickHouse

Wed, 21 Jan 2026 10:00:30 +0000

Data Warehouse als Cloud-Produkt oder als offene Analyseplattform

Analytische Daten sind längst kein Reporting-Anhängsel mehr. Sie sind Grundlage für Produktentscheidungen, Betriebsoptimierung und strategische Steuerung. Entsprechend relevant ist die Frage, wie Analyseplattformen aufgebaut werden – und wem sie gehören.

AWS Redshift und ClickHouse lösen dasselbe Grundproblem: große Datenmengen effizient analysieren. Architektonisch stehen sie jedoch für zwei sehr unterschiedliche Modelle. Das eine integriert Analytics tief in eine Cloud-Plattform. Das andere entkoppelt Analysefähigkeiten bewusst von einzelnen Anbietern.

AWS Secrets Manager vs. External Secrets Operator

Wed, 21 Jan 2026 09:57:07 +0000

Geheimnisse als Cloud-Service oder als Teil der Kubernetes-Plattform

Secrets gehören zu den sensibelsten Bausteinen moderner Anwendungen. Zugangsdaten, API-Keys, Tokens oder Zertifikate entscheiden darüber, ob Systeme sicher miteinander kommunizieren – oder ob Sicherheitsgrenzen faktisch nicht existieren. Entsprechend weitreichend ist die Frage, wo und wie Secrets verwaltet und konsumiert werden.

AWS Secrets Manager und der External Secrets Operator adressieren genau dieses Problem, allerdings aus grundlegend unterschiedlichen Perspektiven. Der eine verankert Secrets in der Cloud-Plattform. Der andere integriert sie bewusst in Kubernetes als zentrale Steuerungsebene. Der Unterschied ist nicht funktional – er ist architektonisch.

AWS CodePipeline vs. Flux

Wed, 21 Jan 2026 09:55:08 +0000

Pipeline-Orchestrierung oder GitOps als Betriebsmodell

CI/CD wird häufig als Toolfrage behandelt: Welche Pipeline, welcher Runner, welcher Dienst? In modernen Plattformarchitekturen greift diese Sicht zu kurz. Entscheidend ist nicht, wie Deployments ausgelöst werden, sondern welches Betriebsmodell dahintersteht.

AWS CodePipeline und Flux adressieren beide den Weg von Code in Produktion. Sie tun das jedoch aus grundlegend unterschiedlichen Richtungen. Das eine orchestriert Ausführungsschritte innerhalb einer Cloud. Das andere etabliert GitOps als dauerhaftes Betriebsmodell. Wer diesen Unterschied nicht sauber trennt, baut kurzfristig funktionierende Pipelines – und langfristig schwer wartbare Plattformen.

AWS CodeCommit vs. GitLab

Wed, 21 Jan 2026 09:48:23 +0000

Versionsverwaltung als Cloud-Baustein oder als Plattformkern

Versionsverwaltung wird oft auf ein technisches Minimum reduziert: Code ablegen, Änderungen nachverfolgen, fertig. In modernen Plattformarchitekturen ist Git jedoch weit mehr als ein Entwicklerwerkzeug. Es ist Steuerungsinstanz, Integrationspunkt und häufig der Ort, an dem technische Wahrheit definiert wird.

AWS CodeCommit und GitLab adressieren beide Git-basierte Versionsverwaltung. Architektonisch stehen sie jedoch für zwei grundverschiedene Ansätze. Das eine ordnet Git einer Cloud-Plattform unter. Das andere macht Git zum zentralen Kern der Plattform.

AWS CloudWatch & Azure Monitor vs. Grafana

Wed, 21 Jan 2026 09:43:46 +0000

Monitoring als Cloud-Funktion oder als offene Observability-Schicht

Monitoring und Observability sind längst mehr als Betriebswerkzeuge. Sie bestimmen, wie Systeme verstanden, bewertet und gesteuert werden. AWS CloudWatch und Azure Monitor sind die nativen Monitoring- und Observability-Dienste ihrer jeweiligen Hyperscaler. Grafana verfolgt einen grundlegend anderen Ansatz.

Der Unterschied liegt nicht darin, ob Metriken, Logs oder Events erfasst werden. Er liegt darin, wer definiert, wie diese Daten strukturiert, korreliert und genutzt werden dürfen. Monitoring ist damit keine rein technische Frage – es ist eine Frage von Architekturhoheit.

Provider-Loadbalancer vs. HAProxy

Wed, 21 Jan 2026 09:41:30 +0000

Verkehrssteuerung als Cloud-Service oder als kontrollierbare Plattformkomponente

Loadbalancer gehören zu den stillen Fundamenten moderner Infrastrukturen. Sie entscheiden darüber, wie Traffic verteilt, abgesichert und kontrolliert wird – oft, ohne dass man sie im Alltag bewusst wahrnimmt. Ob AWS Elastic Load Balancer, Azure Load Balancer oder vergleichbare Dienste: Provider-Loadbalancer sind heute Standardbestandteil nahezu jeder Cloud-Architektur.

Sie funktionieren zuverlässig, skalieren automatisch und lassen sich schnell anbinden. Genau deshalb werden sie häufig nicht als Architekturentscheidung betrachtet, sondern als Selbstverständlichkeit. Mit zunehmender Plattformisierung, insbesondere im Kubernetes-Umfeld, wird diese Haltung jedoch problematisch.

AWS ECR vs. Harbor

Wed, 21 Jan 2026 09:35:30 +0000

Container-Registry als Cloud-Service oder als kontrollierbarer Plattformbaustein

Container-Registries wirken auf den ersten Blick wie ein technisches Detail. Images werden gebaut, abgelegt, gezogen – fertig. In der Praxis sind Registries jedoch ein zentraler Bestandteil moderner Plattformarchitekturen. Sie entscheiden darüber, wie Images verteilt, abgesichert, versioniert und zwischen Umgebungen bewegt werden können.

AWS Elastic Container Registry (ECR) und Harbor lösen dasselbe Grundproblem: Container-Images speichern und bereitstellen. Architektonisch stehen sie jedoch für zwei grundverschiedene Modelle. Das eine ordnet die Registry der Cloud unter. Das andere macht sie zu einem kontrollierbaren Bestandteil der eigenen Plattform.

AWS Secrets Manager vs. HashiCorp Vault

Wed, 21 Jan 2026 09:33:28 +0000

Secret-Verwaltung als Cloud-Funktion oder als eigenständige Sicherheitsarchitektur

Secrets sind kein Randthema. Zugangsdaten, API-Keys, Tokens und Zertifikate definieren, wie Systeme miteinander sprechen dürfen – und wo Sicherheitsgrenzen tatsächlich verlaufen. AWS Secrets Manager und HashiCorp Vault adressieren dieses Problem aus zwei grundsätzlich unterschiedlichen Richtungen.

Der Unterschied liegt nicht in der Fähigkeit, Secrets verschlüsselt zu speichern. Er liegt in der Frage, ob Secret-Management Teil einer Cloud-Funktion ist oder eine eigenständige Sicherheitsarchitektur darstellt. Diese Entscheidung wirkt sich direkt auf Portabilität, Governance und langfristige Kontrolle aus.

AWS Secrets Manager vs. Infisical

Wed, 21 Jan 2026 09:28:05 +0000

Secrets als Hyperscaler-Service oder als offene Developer-Security-Plattform

Secrets gehören zu den unscheinbarsten, aber kritischsten Bausteinen moderner Plattformen. Zugangsdaten, API-Keys, Tokens oder Zertifikate entscheiden darüber, wer auf Systeme zugreifen darf – und wer nicht. AWS Secrets Manager und Infisical adressieren genau dieses Problem. Technisch betrachtet speichern beide Secrets sicher. Architektonisch verfolgen sie jedoch grundverschiedene Ansätze.

Der Unterschied liegt nicht in der Verschlüsselung, sondern in der Frage, wem Secret-Management untergeordnet ist: der Cloud-Infrastruktur oder der Anwendungs- und Plattformlogik. Das ist keine Detailfrage, sondern eine strategische Entscheidung.

AWS Timestream vs. InfluxDB

Wed, 21 Jan 2026 09:24:31 +0000

Managed Convenience gegen technische Kontrolle

AWS Timestream und InfluxDB lösen dasselbe Grundproblem: Zeitreihendaten effizient speichern, abfragen und analysieren. In Architekturdiagrammen wirken beide austauschbar. In der Praxis stehen sie für zwei grundverschiedene Haltungen zu Infrastruktur.

Der Unterschied liegt nicht in der Datenbankkategorie, sondern im Machtgefüge hinter der Technologie. Es geht nicht um einen technischen Schönheitswettbewerb, sondern um Architektur, Abhängigkeit und langfristige Steuerbarkeit.

AWS Timestream: Zeitreihen als konsumierter Service

AWS Timestream ist ein vollständig gemanagter Service. Keine Server, keine Versionen, kein Betrieb. Daten werden geschrieben, Abfragen gestellt, der Rest passiert automatisch. Skalierung, Retention, Storage-Tiering und Performance-Optimierung übernimmt AWS.

AWS MSK vs. Apache Kafka

Wed, 21 Jan 2026 09:20:49 +0000

Infrastruktur konsumieren oder selbst kontrollieren

AWS MSK und Apache Kafka stehen nicht in Konkurrenz auf Feature-Ebene. Sie stehen für zwei grundsätzlich unterschiedliche Haltungen zu Infrastruktur. Das eine Modell verspricht Entlastung durch Managed Services. Das andere setzt auf technische Kontrolle, Portabilität und Gestaltungsfreiheit. Wer diesen Unterschied unterschätzt, zahlt selten sofort – aber fast immer später.

Kafka ist längst mehr als ein Messaging-System. Es ist Datenrückgrat, Integrationsplattform und oft kritischer Bestandteil der Geschäftslogik. Entsprechend weitreichend ist die Entscheidung, ob man Kafka konsumiert oder betreibt.

Azure Entra ID vs. Keycloak

Wed, 21 Jan 2026 09:17:02 +0000

Identität als Service oder als Infrastruktur

Azure Entra ID und Keycloak lösen dasselbe Kernproblem: Identitäten verwalten, Zugriffe steuern und Authentifizierung absichern. In vielen Architekturen tauchen beide als „Identity Provider" auf und werden damit funktional gleichgesetzt. Diese Sicht greift zu kurz.

Der Unterschied liegt nicht in einzelnen Features, sondern in Kontrolle, Abhängigkeit und strategischer Tragweite. Identity ist keine Nebenfunktion. Sie entscheidet darüber, wer Zugriff erhält, wie Systeme miteinander interagieren und wo letztlich die Hoheit über digitale Identitäten liegt. Identity ist Macht über Systeme.

Azure Monitor vs. Loki

Wed, 21 Jan 2026 09:09:01 +0000

Observability als Service oder als eigene Infrastruktur

Azure Monitor und Loki verfolgen zwei grundverschiedene Ansätze für Monitoring und Logging. Beide liefern Einblicke in Systeme, Metriken und Logs. Der entscheidende Unterschied liegt jedoch nicht in der Sichtbarkeit, sondern in der Frage, wer die Kontrolle über Daten, Kosten und Architektur behält.

Observability ist kein Komfort-Feature. Sie entscheidet darüber, wie schnell Systeme verstanden, Fehler analysiert und Vorfälle aufgearbeitet werden können. Wer hier falsche Annahmen trifft, verliert nicht nur Transparenz, sondern langfristig auch Steuerungsfähigkeit.

Individueller Provider-Block-Storage vs. Longhorn

Wed, 21 Jan 2026 09:04:56 +0000

Abhängigkeit einkaufen oder Resilienz aufbauen

Block Storage gehört zu den unsichtbaren, aber kritischsten Schichten jeder Cloud- und Kubernetes Architektur. Ob AWS EBS, Azure Managed Disks oder vergleichbare provider-spezifische Angebote: Sie funktionieren zuverlässig – solange man im jeweiligen Ökosystem bleibt. Genau diese Selbstverständlichkeit wird selten hinterfragt.

Mit zunehmender Plattformisierung von Kubernetes wird Block Storage jedoch vom Detail zur strategischen Entscheidung. Longhorn setzt genau hier an und stellt die Grundannahme infrage, dass persistenter Storage zwangsläufig an einen einzelnen Anbieter gebunden sein muss.

AWS RDS vs. MariaDB

Wed, 21 Jan 2026 09:00:31 +0000

Datenbanken konsumieren oder selbst beherrschen

AWS RDS und MariaDB stehen nicht für konkurrierende Produkte, sondern für zwei grundverschiedene Modelle im Umgang mit Datenbanken. Das eine verspricht Entlastung durch Managed Services. Das andere verlangt Verantwortung – und erhält dafür Kontrolle. Wer diese Entscheidung zu kurz greift, zahlt selten sofort, aber fast immer später.

Datenbanken sind kein austauschbarer Infrastrukturbaustein. Sie speichern nicht nur Daten, sondern Geschäftslogik, Historie, Abhängigkeiten und implizite Annahmen über Skalierung, Verfügbarkeit und Konsistenz. Entsprechend weitreichend sind die Folgen der Frage, ob man eine Datenbank konsumiert oder beherrscht.

AWS S3 vs. MinIO

Wed, 21 Jan 2026 08:57:56 +0000

Objektspeicher konsumieren oder selbst kontrollieren

AWS S3 und MinIO erfüllen auf dem Papier dieselbe technische Aufgabe: hochverfügbaren, skalierbaren Objektspeicher bereitzustellen. In vielen Diskussionen endet der Vergleich deshalb früh – beim API. Beide sprechen S3. Damit scheint die Entscheidung trivial. In der Praxis ist sie es nicht.

Object Storage ist längst keine rein technische Komponente mehr. Er ist infrastrukturelles Fundament, Kostenfaktor, Compliance-Baustein und strategische Abhängigkeit zugleich. Die entscheidende Frage lautet daher nicht, ob Objektspeicher funktioniert, sondern wem Betrieb, Daten und Architektur gehören.

AWS DocumentDB vs. MongoDB

Wed, 21 Jan 2026 08:49:10 +0000

Warum API-Kompatibilität keine Datenbankstrategie ist

AWS DocumentDB und MongoDB werden regelmäßig gleichgesetzt. Der Grund ist schnell benannt: Beide sollen dieselbe API sprechen. Für viele Entscheidungsprozesse reicht diese Aussage bereits aus, um einen Haken zu setzen. „Kompatibel" klingt nach austauschbar, nach geringem Risiko, nach Flexibilität. Genau diese Annahme ist der Kern des Problems.

Eine Datenbank ist kein Protokoll und kein Interface. Sie ist ein komplexes Systemverhalten. Wer sich ausschließlich an einer API orientiert, blendet Architektur, Performance-Eigenschaften, Feature-Entwicklung und langfristige Abhängigkeiten aus. Im Fall von AWS DocumentDB und MongoDB führt das regelmäßig zu Fehlentscheidungen, die erst im Betrieb sichtbar werden.

Polycrate CLI 0.29.10 released: Security Hardening

Tue, 20 Jan 2026 23:30:00 +0000

Polycrate CLI Version 0.29.10 fokussiert auf Security und bringt umfassende Kubernetes-Härtung für den Operator nach NIST SP 800-190 und CIS Benchmark.

Kubernetes Security Hardening

Das Operator-Image wurde nach gängigen Sicherheitsstandards gehärtet und ist jetzt standardmäßig als Rootless-Image verfügbar:

Security Features:

Non-root User (UID 1000)
Read-only Root Filesystem
Dropped Capabilities (ALL)
Seccomp RuntimeDefault
NetworkPolicy für Namespace-Isolation

# Neue Security-Konfiguration
blocks:
  - name: polycrate-operator
    config:
      security:
        enabled: true
        run_as_non_root: true
        read_only_root_filesystem: true
        network_policy:
          enabled: true

Compliance:

NIST SP 800-190 (Container Security)
NSA/CISA Kubernetes Hardening Guidance
CIS Kubernetes Benchmark

DNS-Validierung für Endpoints

Der Operator validiert jetzt Hostnames per DNS-Lookup bevor sie als Endpoints an die API gemeldet werden:

Kubernetes als das De Facto 'Betriebssystem' für KI etabliert, während die Produktionsnutzung 2025 bei 82% liegt – CNCF-Jahresumfrage zu Cloud Native

Tue, 20 Jan 2026 17:00:00 +0000

TL;DR

Die jährliche Umfrage der Cloud Native Computing Foundation zeigt, dass Kubernetes sich als das bevorzugte „Betriebssystem“ für KI-Anwendungen etabliert hat, mit 82 % der Container Nutzer, die es in Produktionsumgebungen einsetzen. Cloud-native Technologien sind mittlerweile der Standard für moderne Anwendungen, während die Integration von KI und Kubernetes neue Möglichkeiten für Unternehmen eröffnet.

Hauptinhalt

Die Ergebnisse der CNCF-Jahresumfrage verdeutlichen, dass Kubernetes nicht mehr als aufkommende Technologie betrachtet wird, sondern als zuverlässige Grundlage für moderne Unternehmensinfrastrukturen. Diese Entwicklung ermöglicht es Unternehmen, kritische KI-Workloads sicher zu skalieren und zu operationalisieren. Die Umfrage zeigt, dass 98 % der befragten Organisationen cloud-native Techniken übernommen haben, was darauf hinweist, dass diese Technologien über die Phase der frühen Anwender hinausgewachsen sind und sich als Standard für die Bereitstellung und Verwaltung moderner Anwendungen etabliert haben.

Kubernetes fördert das Wachstum von KI; Unternehmenskultur bleibt der entscheidende Faktor

Tue, 20 Jan 2026 17:00:00 +0000

TL;DR

Kubernetes hat sich als zentrale Infrastruktur für moderne Anwendungen etabliert, insbesondere im Bereich der Künstlichen Intelligenz (KI). Mit 82 % Produktionsnutzung bei Containeranwendern und 66 % der KI-Anwender, die Kubernetes für das Skalieren von Inferenz-Workloads nutzen, wird deutlich, dass Kubernetes nicht mehr nur ein Nischenwerkzeug ist. Die kulturelle Anpassung innerhalb von Organisationen stellt jedoch die größte Herausforderung für die vollständige Nutzung cloud-nativer Technologien dar.

Hauptinhalt

Die Ergebnisse der jährlichen Umfrage zur Cloud-Native-Technologie zeigen, dass Kubernetes von einer reinen Container-Orchestrierung zu einem unverzichtbaren Bestandteil der modernen Infrastruktur gewachsen ist. Der Einsatz von Kubernetes in Produktionsumgebungen hat 82 % unter den Containeranwendern erreicht. Besonders bemerkenswert ist, dass 66 % der Unternehmen, die KI-Technologien einsetzen, Kubernetes verwenden, um ihre Inferenz-Workloads zu skalieren. Diese Entwicklung verdeutlicht die technische Evolution und die zunehmende betriebliche Reife des cloud-nativen Ökosystems.

Polycrate API 0.11.22 released: LoadBalancer Metrics Fix

Tue, 20 Jan 2026 17:00:00 +0000

Polycrate API 0.11.22 behebt die LoadBalancer Metrics-Abfrage. Die Detail-UI zeigt jetzt korrekte Bandwidth-Daten.

LoadBalancer Metrics Fix

Die LoadBalancer Instance Detail UI zeigte keine Bandwidth-Daten - “No bandwidth data available” für alle Zeiträume.

Ursache: Die VictoriaMetrics-Query verwendete falsche Label-Namen.

Lösung: Korrigierte Labels:

loadbalancerinstances_polycrate_io_id (UUID)
workspaces_polycrate_io_id (UUID)

→ Vollständige Release Notes

polycrate-api Block

Der polycrate-api Block wurde auf Version 0.5.26 (API 0.11.22) aktualisiert:

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-api
polycrate run polycrate-api install

Jetzt aktualisieren

polycrate run polycrate-api install

Oder laden Sie das Docker Image direkt:

Polycrate API 0.11.21 released: Ceph Metrics + Filter Fix

Tue, 20 Jan 2026 16:00:00 +0000

Polycrate API 0.11.21 behebt zwei wichtige Probleme: S3 Buckets mit Ceph-Backend zeigen jetzt korrekte Storage-Metriken in der Detail-UI, und die Filter für Organization und Workspace funktionieren wieder in der ActionRun- und Agent-Tabelle.

S3 Bucket Metrics für Ceph

S3 Buckets mit Ceph-Backend (RadosGW) zeigten in der Detail-UI keine Storage-Metriken – obwohl die Listen-Ansicht die Werte korrekt anzeigte. Das Problem: Die RadosGW Admin API liefert nur Momentaufnahmen, keine historischen Daten wie VictoriaMetrics bei MinIO.

Polycrate API 0.11.17 released: Timeline Chart Debugging

Tue, 20 Jan 2026 14:00:00 +0000

Mit Polycrate API 0.11.17 verbessern wir die Diagnose-Möglichkeiten für die Timeline-Charts in den Detail-UIs.

Das Problem

Nach dem 0.11.16 Release wurde beobachtet, dass die Timeline-Charts in S3 Bucket Detail und LoadBalancer Instance Detail keine Daten anzeigen - obwohl die aggregierten Werte (Durchschnitt, Maximum) korrekt berechnet werden.

Das Paradox: Beide Berechnungen nutzen dieselbe VictoriaMetrics-Response. _calculate_average_from_metrics() funktioniert, aber _extract_storage_timeline() liefert eine leere Liste.

Die Lösung

1. Konsistentes Parsing

Die Timeline-Extraktion nutzt jetzt exakt dieselbe Syntax wie die funktionierende Durchschnittsberechnung - bewährter Code statt Variation.

Polycrate API 0.11.20 released: LoadBalancer Fix + Debug

Tue, 20 Jan 2026 14:00:00 +0000

Polycrate API 0.11.20 behebt einen JavaScript-Fehler und fügt Debug-Logging hinzu, um die Ursache leerer Timeline-Daten zu identifizieren.

Fix: Chart resize TypeError

In der Browser-Console erschien beim Window-Resize folgender Fehler:

Uncaught TypeError: bandwidthChart?.resize is not a function

Der Event-Handler prüft jetzt explizit ob das Chart-Objekt existiert und die resize-Methode eine Funktion ist.

Debug: Leere Timeline-Daten

Die LoadBalancer Detail UI zeigte für 1h/24h Tabs keine Daten, obwohl für 30d Daten vorhanden waren. Diese Version fügt umfangreiche Debug-Ausgaben hinzu:

Polycrate API 0.11.19 released: Storage in der Bucket-Übersicht

Tue, 20 Jan 2026 13:00:00 +0000

Polycrate API 0.11.19 erweitert die S3 Bucket Table UI um Storage- und Objects-Spalten und bringt konsistente Bar-Charts für alle Timeline-Visualisierungen.

Storage & Objects direkt in der Übersicht

Die S3 Bucket Table zeigt jetzt den aktuellen Speicherverbrauch und die Objektanzahl direkt in der Übersicht:

Storage: Formatiert als KB, MB, GB oder TB
Objects: Mit Tausender-Trennzeichen für bessere Lesbarkeit

Diese Information war bisher nur im Detail-View verfügbar und ist jetzt direkt in der Liste sichtbar.

Polycrate API 0.11.16 released: Critical Bugfixes

Tue, 20 Jan 2026 12:00:00 +0000

Mit Polycrate API 0.11.16 beheben wir zwei kritische Bugs, die in Produktionsumgebungen auftreten konnten.

🔥 S3 Bucket Reconciliation Fix

Das Problem: S3 Buckets blieben permanent im Status DEGRADED und wurden beim Provider (MinIO) nie erstellt. Die Logs zeigten keinen Error - nur eine irreführende Info-Meldung über fehlende Metriken.

Die Ursache: Bei der Migration zu run_reconciliation() in 0.11.12 wurden Early Returns eingeführt, die den REPAIRS-Abschnitt übersprungen. Für neue Buckets ohne Metriken wurde create_bucket() nie aufgerufen.

Polycrate API 0.11.18 released: Hotfix & Bar-Charts

Tue, 20 Jan 2026 12:00:00 +0000

Polycrate API 0.11.18 behebt einen kritischen Fehler bei der Timeline-Datenextraktion und ändert den Chart-Stil auf Bar-Charts.

Hotfix: timezone.utc AttributeError

Nach dem Deploy von 0.11.17 erschien in Production folgender Fehler:

Error extracting storage timeline: module 'django.utils.timezone' has no attribute 'utc'

Django’s timezone Modul hat kein utc Attribut. 0.11.18 verwendet jetzt datetime.timezone.utc aus der Python Standard-Library.

UI: Bar-Chart-Stil

Die Timeline-Charts für S3 Buckets und LoadBalancer Instances wurden von Area-Charts auf Bar-Charts umgestellt, um Konsistenz mit dem Endpoint Detail UI herzustellen.

Wiederverwendung von unterausgelasteten GPUs in Kubernetes mit Scheduler-Plugins

Tue, 20 Jan 2026 12:00:00 +0000

TL;DR

Die Wiederverwendung von unterausgelasteten GPUs in Kubernetes wird durch einen neuen Scheduler-Plugin namens ReclaimIdleResource optimiert. Dieser Plugin ermöglicht eine nutzungsbasierte Preemption, die es ermöglicht, inaktive Pods zu verdrängen, um Ressourcen effizienter zu nutzen. Dies verbessert die Ressourcenauslastung in Kubernetes-Clustern, die GPU-intensive Workloads verarbeiten.

Hauptinhalt

In Kubernetes-Umgebungen, die GPU-intensive Anwendungen ausführen, bleiben viele leistungsstarke GPUs oft ungenutzt, obwohl sie zugewiesen sind. Dies führt zu einer ineffizienten Ressourcennutzung, da Pods, die GPUs anfordern, diese häufig nur teilweise verwenden. Das Standard-Scheduling-Modell von Kubernetes berücksichtigt derzeit keine Echtzeitnutzung von GPUs, was bedeutet, dass zugewiesene Ressourcen als nicht verfügbar betrachtet werden, selbst wenn sie nicht aktiv genutzt werden.

Einheitlicher API-Serverzugriff mit clientcmd

Mon, 19 Jan 2026 18:00:00 +0000

TL;DR

Die clientcmd-Bibliothek in Kubernetes ermöglicht eine einheitliche Handhabung von API-Server-Zugriffen über die Kommandozeile. Sie unterstützt die Auswahl von kubeconfig-Dateien, Kontexte und Namespaces sowie verschiedene Authentifizierungsmechanismen. Entwickler können damit ihre eigenen Kubernetes-Clients erstellen, die sich nahtlos in bestehende kubectl-Funktionen integrieren lassen.

Kubernetes stellt Entwicklern mit der clientcmd-Bibliothek eine leistungsstarke Ressource zur Verfügung, um die Interaktion mit dem Kubernetes API-Server zu vereinheitlichen. Diese Bibliothek ist Teil des client-go-Pakets und zielt darauf ab, eine Instanz von restclient.Config zu liefern, die Anfragen an den API-Server senden kann. Die Nutzung von clientcmd ermöglicht es, die Semantik von kubectl nachzubilden, indem Standardkonfigurationen aus dem Verzeichnis ~/.kube oder ähnlichen Pfaden geladen werden. Die Konfiguration kann über die Umgebungsvariable KUBECONFIG angepasst und durch Kommandozeilenargumente weiter spezifiziert werden.

Polycrate API 0.11.15 released: KaTeX Fix

Mon, 19 Jan 2026 15:00:00 +0000

Mit Polycrate API 0.11.15 beheben wir den letzten verbleibenden collectstatic-Fehler in Produktionsumgebungen.

KaTeX/LaTeX entfernt

Das Milkdown Editor CSS enthielt Styles für LaTeX Math-Rendering, die ~30 Font-Dateien referenzierten. Diese Fonts waren nicht im Static Files Verzeichnis vorhanden.

Warum funktionierte es lokal? Development nutzt das Standard Django Storage Backend ohne Post-Processing. Production nutzt Whitenoise’s CompressedManifestStaticFilesStorage, das alle CSS-Referenzen auflöst - und bei fehlenden Dateien crasht.

Die Lösung: Das Build-Script wurde angepasst, um KaTeX und LaTeX-Styles nicht mehr zu inkludieren. Wir nutzen kein Math-Rendering in Notes, daher ist dies kein Funktionsverlust.

Polycrate API 0.11.14 released: Certificate Sync Fix

Mon, 19 Jan 2026 14:30:00 +0000

Mit Polycrate API 0.11.14 beheben wir zwei kritische Bugs die in Produktionsumgebungen auftreten konnten.

Certificate API Upsert

Der Polycrate Operator synchronisiert cert-manager Zertifikate zur API. Bei bestimmten Konstellationen (Operator-Neustart, Status-Verlust) konnte es zu UniqueConstraint Violations kommen, wenn ein Zertifikat bereits in der API existierte.

Die Lösung: Die Certificate API implementiert jetzt Upsert-Logik. Existiert ein Zertifikat mit gleichem name, namespace und k8s_cluster bereits, wird es aktualisiert statt einen Fehler zu werfen.

Dieser Fix ist abwärtskompatibel zu allen Operator-Versionen.

Polycrate API 0.11.13 released: collectstatic Hotfix

Mon, 19 Jan 2026 13:00:00 +0000

Mit Polycrate API 0.11.13 beheben wir kritische Produktionsprobleme die nach dem 0.11.12 Release auftraten.

collectstatic-Fix

Das milkdown-theme/ Verzeichnis enthielt CSS-Dateien mit @import-Statements auf NPM-Pakete:

@import '@milkdown/kit/prose/gapcursor/style/gapcursor.css';
@import 'katex/dist/katex.min.css';

Diese Pfade existieren nur während der Entwicklung in node_modules/, nicht aber im Production-Build. Whitenoise’s collectstatic Post-Processing versuchte diese Imports aufzulösen und brach ab.

Die Lösung: Das gesamte milkdown-theme/ Verzeichnis wurde entfernt. Es war überflüssig, da das Template nur die gebündelte milkdown-crepe.css lädt.

→ Vollständige Release Notes

Jetzt aktualisieren

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-api
polycrate run polycrate-api install

Polycrate ist die Infrastructure-as-Code Plattform von ayedo für deklaratives Multi-Cluster-Management. Mehr erfahren →

AWS ElastiCache vs. KeyDB

Mon, 19 Jan 2026 12:50:54 +0000

Managed Cache oder kontrollierte Datenstruktur

AWS ElastiCache und KeyDB adressieren denselben Bedarf: extrem schnelle In-Memory-Datenhaltung für Caching, Queues, Sessions und Echtzeitzugriffe. In Architekturdiagrammen werden beide oft als austauschbarer Baustein eingezeichnet. Diese Annahme greift zu kurz.

Der Unterschied zwischen beiden liegt nicht primär in der Latenz, sondern in der Frage, wem Architektur, Kosten und Weiterentwicklung gehören. In-Memory-Stores sind kein nebensächlicher Performance-Trick. Sie entscheiden über Antwortzeiten, Systemstabilität und Skalierbarkeit ganzer Plattformen.

AWS ElastiCache: Redis als konsumierter Service

ElastiCache ist Redis oder Memcached als vollständig gemanagter AWS-Service. Provisionierung, Patching, Failover, Backups und Monitoring sind automatisiert. Für Teams im AWS-Ökosystem ist das bequem. ElastiCache integriert sich nahtlos in VPCs, Security Groups, IAM-Policies und CloudWatch.

Die 28 besten Kubernetes-Ressourcen für 2026: Lernen und informiert bleiben

Mon, 19 Jan 2026 12:00:00 +0000

TL;DR

Die Kubernetes-Community bietet eine Vielzahl von Ressourcen, um sowohl Einsteigern als auch erfahrenen Anwendern zu helfen, ihre Kenntnisse über Kubernetes und das Cloud-Native -Ökosystem zu erweitern. Diese Ressourcen umfassen grundlegende Tutorials, interaktive Labore, Podcasts und spezialisierte Inhalte, die auf verschiedene Lernbedürfnisse und Anwendungsfälle abgestimmt sind.

Hauptinhalt

Kubernetes hat sich als zentraler Bestandteil der Cloud-Native -Community etabliert und ist ein wesentlicher Faktor für deren Wachstum. Die Vielzahl an Ressourcen, die zur Verfügung stehen, ermöglicht es Praktikern, Wissen, Werkzeuge und Erfahrungen auszutauschen, um die Implementierung und Verwaltung von Kubernetes-Workloads zu verbessern. Diese Übersicht richtet sich an Ingenieure, die neu im Umgang mit Kubernetes sind, sowie an solche, die bereits produktive Umgebungen betreuen.

Polycrate API 0.11.12 released: Editor & UI Modernisierung

Mon, 19 Jan 2026 10:00:00 +0000

Polycrate API Version 0.11.12 bringt umfangreiche UI-Modernisierung mit dem neuen Milkdown Editor, S3 Media Storage und signifikante Performance-Verbesserungen für den System State Loop.

Highlights

Milkdown Editor - Moderner Markdown-Editor mit @Mention-Support für Notes
S3 Media Storage - Medien-Dateien werden jetzt in S3 gespeichert
V2 Table Filter - Neue Filter-UI mit URL-State Persistenz
Toast System - Modernisiertes Notification-System mit Polycrate.toast API
System State Loop - Von 5-15s auf 1-3s optimiert

Milkdown Editor

Der bisherige Plaintext-Editor für Notes wurde durch Milkdown ersetzt - einen modernen, Markdown-basierten WYSIWYG-Editor mit @Mention-Support für Benutzer-Referenzen.

Flux: Die Referenz-Architektur für Continuous Delivery & Infrastructure Automation

Mon, 19 Jan 2026 09:38:19 +0000

TL;DR

Kubernetes-Cluster sollten nicht manuell oder durch fragile Skripte verwaltet werden. Während AWS CodePipeline versucht, Deployments durch externe Befehle („Push") zu erzwingen, dreht Flux dieses Modell um. Als nativer Kubernetes-Controller zieht sich Flux den gewünschten Zustand direkt aus Git oder OCI-Repositories („Pull"). Das Ergebnis ist ein selbst-heilendes System, das Infrastruktur und Anwendungen synchron hält, ohne dass externe CI-Server Zugriff auf den Cluster benötigen.

1. Das Architektur-Prinzip: Der Cluster verwaltet sich selbst

Traditionelle CI/CD-Tools (wie AWS CodePipeline oder Jenkins) arbeiten imperativ: “Baue das Image, verbinde dich mit dem Cluster, führe kubectl apply aus”.

GitLab: Die Referenz-Architektur für die vollständige DevOps-Plattform

Mon, 19 Jan 2026 09:37:48 +0000

TL;DR

Moderne Softwareentwicklung erfordert mehr als nur Code-Hosting. Während Hyperscaler wie AWS versuchen, Entwickler durch eine fragmentierte Kette von Einzel-Services (CodeCommit, CodeBuild, CodePipeline) an ihre Plattform zu binden, verfolgt GitLab den Ansatz der „Single Application". Es vereint Source Code Management (SCM), CI/CD, Security Scanning und Package Registry in einer einzigen, kohärenten Oberfläche. Dies reduziert Komplexität, beschleunigt Feedback-Schleifen und garantiert, dass Ihr geistiges Eigentum (der Code) und Ihre Prozesse portabel bleiben.

Google Tag Manager (Server-Side): Die Referenz-Architektur für First-Party Data & Compliance

Mon, 19 Jan 2026 09:37:16 +0000

TL;DR

Das klassische Tracking über den Browser („Client-Side") stirbt. Browser-Restriktionen (ITP), AdBlocker und die DSGVO machen die Datenerhebung unzuverlässig und rechtlich riskant. Server-Side Tagging (SST) verlagert die Logik vom Endgerät des Nutzers auf einen eigenen Server. Dies gibt Unternehmen die volle Kontrolle zurück: Daten werden bereinigt, bevor sie an Drittanbieter (Google, Meta) gehen, und die Performance der Webseite steigt massiv. Wer GTM Server-Side im eigenen Cluster betreibt, verwandelt Tracking von einem Sicherheitsrisiko in einen kontrollierten Datenstrom.

Gotenberg: Die Referenz-Architektur für PDF-Generierung als Microservice

Mon, 19 Jan 2026 09:36:43 +0000

TL;DR

PDF-Generierung ist in der modernen Webentwicklung oft ein technischer Schuldenberg. Veraltete Tools wie wkhtmltopdf werden nicht mehr gewartet, und das Einbetten von Headless-Browsern in Applikations-Container bläht diese unnötig auf und schafft Sicherheitslücken. Gotenberg löst dieses Problem radikal: Es kapselt die Komplexität von Chromium und LibreOffice in einer zustandslosen API. Anstatt PDF-Logik mühsam in jeden Microservice zu bauen, delegieren Sie die Aufgabe an einen zentralen, skalierbaren Service, der HTML, Markdown und Office-Dokumente pixelgenau konvertiert.

Grafana: Die Referenz-Architektur für Unified Observability

Mon, 19 Jan 2026 09:34:21 +0000

TL;DR

In modernen verteilten Systemen reicht es nicht mehr, nur zu wissen, ob ein Server läuft (“Up/Down”). Man muss verstehen, warum er langsam ist. Während AWS CloudWatch einen soliden Blick auf die Infrastruktur bietet, endet die Sichtbarkeit oft an der Cloud-Grenze. Grafana durchbricht diese Silos. Es agiert als universelle Visualisierungs-Schicht, die Daten aus hunderten Quellen (Prometheus, SQL, Logs, Traces) in einer einzigen Oberfläche vereint. Wer Grafana nutzt, erhält echte End-to-End-Observability, unabhängig davon, wo die Daten liegen.

Kleine LLMs intelligenter machen

Fri, 16 Jan 2026 13:47:26 +0000

TL;DR

Die Verwendung kleiner Sprachmodelle (LLMs) kann durch kreative Ansätze und Techniken wie Retrieval Augmented Generation (RAG) optimiert werden. Der Einsatz eines 3-Milliarden-Parameter-Modells zur Unterstützung bei der Code-Generierung zeigt, dass auch lokale LLMs nützliche Ergebnisse liefern können, wenn sie mit spezifischen Informationen gefüttert werden.

Hauptinhalt

Die Entwicklung kleiner, lokal laufender Sprachmodelle bietet eine interessante Herausforderung, insbesondere im Kontext von Anwendungen wie der Code-Generierung. Obwohl große Modelle wie Claude AI oder Gemini leistungsstark sind, können sie in spezifischen Anwendungsfällen, wie der Arbeit an neuen Projekten, weniger hilfreich sein, da sie möglicherweise nicht mit den neuesten Informationen oder spezifischen Bibliotheken vertraut sind. Oftmals haben Entwickler nicht die Möglichkeit, diese Dienste zu nutzen, sei es aus Gründen der Vertraulichkeit oder aufgrund von Einschränkungen im Zugang zum Internet.

Polycrate API 0.11.11 released: Performance-Optimierung

Thu, 15 Jan 2026 19:00:00 +0000

Polycrate API Version 0.11.11 bringt massive Performance-Verbesserungen durch Entfernung der ungenutzten Discovery-Phase und Optimierung des Activity-Trackings.

Highlights

Discovery-Entfernung - 500+ DB-Queries pro control_loop-Zyklus eliminiert
Activity-Tracking Optimierung - SELECT-Query in save() durch Caching eliminiert
K8sAppInstance Cleanup - Obsoletes Model aus Reconciliation entfernt
API Endpoint Cleanup - discover_object Task und API Endpoint entfernt

Discovery-Phase entfernt

Der control_loop (alle 10 Sekunden) rief bisher discover_class() für 5 Model-Typen auf, was zu über 1000 DB-Queries pro Zyklus führte - obwohl die Discovery-Methoden meist nur pass enthielten. Diese Phase wurde komplett entfernt.

Polycrate API 0.11.10 released: Endpoint Monitoring Fixes

Thu, 15 Jan 2026 18:00:00 +0000

Polycrate API Version 0.11.10 behebt mehrere UI-Bugs und Performance-Probleme im Endpoint Monitoring System.

Highlights

Agent Detail Lazy Loading - Monitored Endpoints Table mit Pagination für bessere Performance
Agent Capacity Logic Fix - max_endpoints nutzt jetzt SystemConfig statt veraltetes effective_capacity
VictoriaMetrics Query Optimierung - Query Step von 30s auf 60s korrigiert
Agent Info Box Cleanup - Redundante und fehlerhafte Felder entfernt
Ingress Discovery deaktiviert - Operator ist Single Source of Truth

Agent Capacity Fix

Die max_endpoints Property nutzte das alte effective_capacity Feld, das nicht mehr aktualisiert wird. Das führte zu falschen Capacity-Berechnungen. Jetzt wird direkt der SystemConfig-Wert verwendet (Default: 300 Endpoints pro Agent).

Polycrate CLI 0.29.9 released: Agent Health Redesign

Thu, 15 Jan 2026 16:00:00 +0000

Polycrate CLI Version 0.29.9 bringt signifikante Verbesserungen für das Endpoint Monitoring mit einem kompletten Redesign der Agent Health-Daten.

Agent Health Data Redesign

Die Health-Daten des Operators werden jetzt direkt auf dem Agent Model gespeichert. Das eliminiert unnötige Datenbank-Joins und ermöglicht schnelleren Zugriff auf aktuelle Metriken im UI.

Neue Agent-Felder:

Health Status (healthy/degraded/unhealthy)
Monitored Endpoints Count
Checks per Minute
Total/Failed/Successful Checks

Check Result Submission

Der Operator sammelt alle Check Results und übermittelt sie zusammen mit dem Health Report an die API:

Berechtigungsbewusster RAG: End-to-End-Tests mit dem SpiceDB Testcontainer

Thu, 15 Jan 2026 14:00:00 +0000

TL;DR

Moderne Autorisierungssysteme sind entscheidend für die Sicherheit von Retrieval-Augmented Generation (RAG)-Anwendungen, insbesondere um unbefugten Zugriff auf sensible Daten zu verhindern. SpiceDB, eine skalierbare Open-Source-Implementierung des Google Zanzibar-Modells, bietet feingranulare Autorisierung und lässt sich effektiv mit Testcontainers kombinieren, um End-to-End-Tests der Berechtigungslogik in RAG-Pipelines durchzuführen.

Hauptinhalt

In der heutigen technologischen Landschaft ist der Einsatz von Generativen KI-Modellen weit verbreitet, insbesondere in Bereichen wie internen Wissensdatenbanken, Kundensupport und Code-Überprüfung. Ein zentrales Problem, das dabei häufig auftritt, ist die Sicherstellung, dass die KI-Modelle keine Informationen zurückgeben, auf die Benutzer keinen Zugriff haben sollten. Dies stellt ein erhebliches Risiko dar, da unbefugter Zugriff auf Daten rechtliche, finanzielle und reputationsbezogene Konsequenzen nach sich ziehen kann.

OpenCode mit Docker Model Runner für private KI-Programmierung

Thu, 15 Jan 2026 13:47:17 +0000

TL;DR

Die Kombination von OpenCode und Docker Model Runner ermöglicht eine datenschutzorientierte und kosteneffiziente KI-gestützte Programmierumgebung. Entwickler können lokale Modelle nutzen, um vollständige Kontrolle über ihre Daten und Infrastruktur zu behalten.

Hauptinhalt

OpenCode ist ein Open-Source-Coding-Assistent, der in moderne Entwicklungs-Workflows integriert werden kann. Er unterstützt verschiedene Modellanbieter und bietet eine flexible Konfigurationsmöglichkeit, um zwischen diesen Anbietern zu wechseln. Docker Model Runner (DMR) ermöglicht das einfache Ausführen und Verwalten großer Sprachmodelle und stellt eine OpenAI-kompatible API bereit, die eine nahtlose Integration mit bestehenden Tools ermöglicht.

Weekly Backlog KW 4/2026

Thu, 15 Jan 2026 11:22:06 +0000

🧠 Editorial

Diese Woche fühlt sich an wie ein Realitätsabgleich für alle, die digitale Souveränität bisher für ein Förderprogramm mit hübschem Deckblatt gehalten haben. Cloud ist Machtpolitik. Software ist Außenpolitik. Und Abhängigkeit ist kein Betriebsunfall, sondern eine strategische Entscheidung. Während Hyperscaler „Souveränität" neu labeln, Präsidenten mit Zöllen drohen und CEOs offen über Töten sprechen, wird eines klar: Europas Komfortzone ist vorbei. Willkommen im Jahr, in dem Tech endgültig geopolitisch wird.

SaaS Everywhere: Dedizierte SaaS-Instanzen auf Knopfdruck

Thu, 15 Jan 2026 11:17:59 +0000

Das klassische SaaS-Modell ist simpel: Eine Cloud, eine Architektur, alle Kunden teilen sich die Ressourcen. Doch je erfolgreicher ein SaaS-Anbieter im Enterprise-Segment wird, desto häufiger fällt ein Satz im Verkaufsgespräch: „Wir lieben Ihre Software, aber aus Compliance Gründen müssen die Daten in unserem eigenen Azure-Tenant (oder On-Premise) liegen."

Für viele SaaS-Teams ist das der Moment, in dem die Skalierung bricht. Plötzlich müssen „Speziallösungen" gepflegt werden, die manuell installiert und mühsam geupdatet werden. Polycrate löst dieses Dilemma, indem es die Applikations-Logik von der Infrastruktur entkoppelt.

Margen-Killer Cloud-Kosten? Wie SaaS-Anbieter ihre Infrastruktur-Effizienz maximieren

Thu, 15 Jan 2026 11:03:33 +0000

In der Wachstumsphase eines SaaS-Unternehmens gibt es eine gefährliche Kurve: Die Cost of Goods Sold (COGS). Während die Nutzerzahlen steigen, explodieren oft die Cloud-Kosten überproportional. Der Grund: Ineffiziente Ressourcenverteilung, ungenutzte „Zombie"-Instanzen und fehlende Kosten-Transparenz pro Kunde (Unit Economics).

Wenn die Infrastrukturkosten schneller wachsen als der Umsatz, sinkt die Marge. Im Jahr 2026 ist FinOps daher keine Option mehr, sondern Überlebensstrategie. Polycrate bietet SaaS-Anbietern die technischen Leitplanken, um Effizienz direkt in den Deployment-Prozess einzubauen.

AWS European Sovereign Cloud in Brandenburg:

Thu, 15 Jan 2026 10:29:24 +0000

Wie souverän sind Europas Daten wirklich?

Amazon Web Services nimmt in Brandenburg die „AWS European Sovereign Cloud" in Betrieb. In Baruth/Mark und Finsterwalde entstehen Cloud-Campusse, zunächst über angemietete Rechenzentren, perspektivisch mit eigener Infrastruktur. Der Betrieb erfolgt über eine deutsche GmbH, die Rechenzentren stehen ausschließlich in der EU, das eingesetzte Personal hat Wohnsitz in Europa. Der Anspruch ist klar formuliert: Betrieb, Kontrolle und Verantwortung sollen vollständig europäisch sein.

Der Zeitpunkt ist kein Zufall. Öffentliche Verwaltungen, Betreiber kritischer Infrastrukturen und regulierte Unternehmen stehen unter wachsendem Druck, ihre digitale Abhängigkeit von außereuropäischen Anbietern zu reduzieren. Politische Unsicherheiten, geopolitische Spannungen und die zunehmende Bedeutung digitaler Infrastrukturen als Machtfaktor verschärfen diese Debatte. Gleichzeitig bleibt die Realität globaler Konzernstrukturen bestehen – und mit ihr Einflussmöglichkeiten, die sich nicht allein durch regionale Betriebsmodelle neutralisieren lassen.

Polycrate API 0.11.7 released: Host String-Repräsentation

Wed, 14 Jan 2026 17:00:00 +0000

Polycrate API Version 0.11.7 korrigiert die Darstellung von Host-Objekten.

Host String-Repräsentation

Das Base-Model ManagedObject verwendet display_name als primäre String-Repräsentation. Für Hosts ist das ungeeignet, da der technische name aussagekräftiger ist.

Das Host-Model überschreibt jetzt __str__() und gibt immer name zurück. Hosts werden damit in Listen, Logs und API-Responses konsistent mit ihrem technischen Namen dargestellt.

→ Vollständige Release Notes

polycrate-api Block 0.5.8

Der polycrate-api Block wurde auf Version 0.5.8 aktualisiert:

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-api
polycrate run polycrate-api install

Jetzt aktualisieren

docker pull cargo.ayedo.cloud/polycrate/polycrate-api:0.11.7

Polycrate ist das Infrastructure-as-Code Tool von ayedo für deklaratives Multi-Cluster-Management. Mehr erfahren →

Polycrate API 0.11.6 released: UniqueValidator Fixes

Wed, 14 Jan 2026 16:30:00 +0000

Polycrate API Version 0.11.6 behebt kritische Validierungsfehler, die Updates über den Operator verhinderten.

UniqueValidator Fixes

K8sApp Block-Validierung

Beim Update einer K8sApp trat folgender Fehler auf:

{"block": ["Kubernetes App with this block already exists."]}

Das Problem: Django REST Framework fügt bei OneToOneField automatisch einen UniqueValidator hinzu, der bei Updates den eigenen Datensatz nicht ausschließt.

Host Unique-Constraints

Ähnliches Problem bei Hosts mit den Constraints unique_host_per_workspace und unique_hostname_per_workspace.

Lösung

Beide Serializer überschreiben jetzt die Validierung und schließen den aktuellen Datensatz bei Updates aus.

Polycrate CLI 0.29.7 released: API Schema Fix

Wed, 14 Jan 2026 16:00:00 +0000

Mit Version 0.29.7 erhält Polycrate wichtige Bugfixes für die API-Kommunikation des Operators.

API Schema Update

Der API-Client wurde mit dem korrigierten Schema regeneriert. Das k8s_cluster-Feld in Listen-Responses wird jetzt korrekt als Objekt behandelt, nicht als String.

Dies behebt den Fehler:

json: cannot unmarshal object into Go struct field K8sAppList.kubernetes_apps.k8s_cluster of type string

Verbesserte Fehlerdiagnose

API-Fehler zeigen jetzt den vollständigen Response-Body an. Das erleichtert die Diagnose von 400/500-Fehlern erheblich.

polycrate-operator Block 0.3.14

Der polycrate-operator Block wurde ebenfalls aktualisiert:

Polycrate CLI 0.29.8 released: Vollständige API-Fehlerdiagnose

Wed, 14 Jan 2026 16:00:00 +0000

Polycrate CLI Version 0.29.8 verbessert die Fehlerdiagnose für alle API-Operationen erheblich.

Verbesserte API-Fehlerdiagnose

Alle 42 API-Client-Funktionen wurden aktualisiert, um bei Fehlern den vollständigen Response-Body anzuzeigen:

// Vorher:
unexpected status code: 400

// Nachher:
unexpected status code: 400, body: {"field": ["Validation error details..."]}

Dies betrifft alle Ressourcentypen:

K8sCluster, K8sApp
Host, Certificate
Backup, BackupSchedule
Workspace, Block
und alle weiteren

Schnellere Problemlösung

Mit den detaillierten Fehlermeldungen können Validierungsprobleme jetzt sofort identifiziert werden, ohne in API-Logs suchen zu müssen. Besonders der Polycrate Operator profitiert davon mit klareren Log-Ausgaben.

Polycrate API 0.11.5 released: Bugfixes & UX Improvements

Wed, 14 Jan 2026 14:00:00 +0000

Mit Version 0.11.5 erhält die Polycrate API wichtige Bugfixes und UX-Verbesserungen. Die Tabellen aktualisieren sich jetzt schneller und Objekte können direkt via URL geöffnet werden.

Bugfixes

CLI-Kompatibilität

Der interne polycrate run Command wurde aktualisiert, um mit neueren CLI-Versionen kompatibel zu sein. Der Fehler Error: unknown shorthand flag: 'o' in -o=yaml ist damit behoben.

Ingress Controller Validierung

Cluster werden nicht mehr als “degraded” markiert, wenn kein nginx Ingress Controller vorhanden ist. Die Endpoint Discovery funktioniert jetzt unabhängig vom Ingress Controller Typ.

Polycrate CLI 0.29.6 released: API Client Type Fix

Wed, 14 Jan 2026 14:00:00 +0000

Mit Version 0.29.6 erhält Polycrate einen kritischen Bugfix: Der Operator konnte K8sApp-Objekte nicht mehr zur API synchronisieren.

Das Problem

Der Polycrate Operator konnte K8sApps nicht zur API synchronisieren und lieferte folgenden Fehler:

json: cannot unmarshal object into Go struct field K8sApp.workspace of type *uuid.UUID

Die Ursache

Der generierte API-Client erwartete für das workspace-Feld eine UUID als String, aber die API gibt ein vollständiges Objekt mit id, name, url etc. zurück.

Der Fix

Der API-Client wurde mit dem aktuellen OpenAPI-Schema aus polycrate-api 0.11.5 neu generiert. Das workspace-Feld verwendet jetzt den korrekten Typ:

Polycrate API 0.11.4 released: Dynamic Tables, Info Drawer & UI Improvements

Wed, 14 Jan 2026 10:00:00 +0000

Mit Version 0.11.4 erhält die Polycrate API umfangreiche UI-Verbesserungen für eine bessere Übersichtlichkeit und schnellere Navigation. Die neuen Dynamic Tables, der Info Drawer und die einklappbare Sidebar machen den Arbeitsalltag effizienter.

Dynamic Tables mit Auto-Refresh

Alle Listenansichten wurden grundlegend überarbeitet:

Echtzeit-Updates: Tabellen aktualisieren sich automatisch alle 30 Sekunden
Schnellere Navigation: Sortieren und Suchen ohne Seitenwechsel
Live-Status: Statusänderungen werden sofort sichtbar
Kompaktere Darstellung: Mehr Einträge auf einen Blick

Info Drawer

Ein neuer, einheitlicher Info-Bereich für alle Objekte:

Echte digitale Souveränität: Mit Polycrate die Cloud-Freiheit zurückgewinnen

Tue, 13 Jan 2026 13:05:15 +0000

Das Versprechen der Cloud war immer Flexibilität. Doch die Realität in vielen IT-Abteilungen sieht anders aus: Vendor Lock-in. Wer seine gesamte Automatisierung exklusiv auf AWS-APIs, Azure-spezifische Scripte oder Google-Cloud-Tools aufbaut, sitzt in der „goldenen Falle". Ein Wechsel des Providers oder auch nur die Verteilung von Workloads auf einen europäischen Anbieter wie STACKIT oder Hetzner wird zur unbezahlbaren Mammutaufgabe.

Echte digitale Souveränität bedeutet, die Kontrolle über die eigene Infrastruktur-Logik zu behalten. Polycrate ist das Werkzeug, das dieses Versprechen einlöst.

Wie Polycrate heterogene Toolstacks zähmt

Tue, 13 Jan 2026 12:45:23 +0000

Wer heute eine moderne IT-Infrastruktur betreibt, fühlt sich oft wie ein Mechaniker, der für jede Schraube eine andere Werkstatt aufsuchen muss. Wir nutzen Terraform für die Cloud-Ressourcen, Ansible für die Server-Konfiguration, Helm für die Kubernetes Apps und eine Handvoll Bash-Scripte, um alles irgendwie zusammenzuhalten.

Das Ergebnis? Die „kognitive Last" für Plattform-Teams steigt ins Unermessliche. Niemand im Team beherrscht alle Tools perfekt, das Wissen ist in Silos verteilt, und Fehler bei der Übergabe zwischen den Werkzeugen sind vorprogrammiert.

External Secrets Operator: Die Referenz-Architektur für hybrides Secrets Management

Im Jahr 2026 hat sich eBPF als der Standard etabliert, der dieses Problem löst. eBPF erlaubt es uns, Programme direkt im Linux-Kernel laufen zu lassen – sicher, effizient und völlig transparent für die Applikation. Es ist so, als hätten wir ein Röntgengerät für unseren gesamten Cluster.

Schluss mit dem Leerlauf: Rightsizing-Tools für effiziente Kubernetes-Cluster

Tue, 13 Jan 2026 10:46:15 +0000

In der klassischen Server-Welt galt: „Lieber zu viel RAM als zu wenig." In Kubernetes führt diese Einstellung direkt zu einer aufgeblähten Cloud-Rechnung. Da Kubernetes Pods basierend auf ihren Resource Requests (Reservierungen) plant, bezahlen Sie für den Platz, den Sie reservieren – völlig egal, ob Ihre Applikation ihn tatsächlich nutzt.

Wir nennen das Phänomen „Slack". Im Durchschnitt sind Kubernetes-Cluster in Unternehmen um 30 % bis 50 % überprovisioniert. Rightsizing ist der Prozess, diese Lücke zwischen Reservierung und realem Verbrauch zu schließen.

FinOps: Cloud-Börse - Spot-Instanzen in Kubernetes sicher nutzen

Tue, 13 Jan 2026 10:40:35 +0000

Stellen Sie sich vor, Sie könnten die gleiche Rechenleistung für 70 % bis 90 % weniger Kosten erhalten. Der Haken? Der Cloud-Provider darf Ihnen den Server jederzeit mit einer Vorwarnzeit von nur zwei Minuten (AWS) oder sogar nur 30 Sekunden (Azure) wieder wegnehmen.

Was für klassische Server ein Albtraum ist, ist für Kubernetes–Workloads eine riesige Chance. Da Kubernetes von Grund auf darauf ausgelegt ist, dass Pods sterben und an anderer Stelle neu entstehen können, sind Spot-Instanzen (oder “Preemptible VMs”) der perfekte Partner für eine kosteneffiziente Cloud-Strategie im Jahr 2026.

ArgoCD: Die Referenz-Architektur für deklaratives GitOps auf Kubernetes

Tue, 13 Jan 2026 10:29:24 +0000

TL;DR

ArgoCD hat sich als der Industriestandard für Continuous Delivery in Kubernetes etabliert. Durch die Implementierung des GitOps-Paradigmas transformiert es die Infrastrukturverwaltung von imperativen Pipelines hin zu einer deklarativen Zustandsverwaltung. Dies ermöglicht automatisierte Synchronisierung („Self-Healing"), lückenlose Auditierbarkeit und eine strikte Trennung von CI (Continuous Integration) und CD (Continuous Delivery).

1. Das Architektur-Prinzip: Pull statt Push

Traditionelle Deployment-Tools arbeiten „Push-basiert". Eine externe Pipeline (z.B. Jenkins oder GitLab CI) hat Zugriff auf den Cluster und führt Befehle aus, um Updates einzuspielen. Dies stellt ein Sicherheitsrisiko dar, da die CI-Server weitreichende Rechte im Cluster benötigen.

FinOps in Kubernetes - 20 Antworten

Tue, 13 Jan 2026 10:00:19 +0000

FinOps in Kubernetes - 20 Antworten

1. Warum ist die Standard-Cloud-Rechnung für Kubernetes-Kosten unbrauchbar? Cloud-Provider stellen Rechnungen für Instanzen (VMs) aus. Kubernetes teilt diese Instanzen jedoch unter vielen Teams und Apps auf. Ohne K8s-native Tools sieht man nur die Gesamtsumme, aber nicht, welcher Service die Kosten verursacht.

2. Was ist der Unterschied zwischen “Showback” und “Chargeback”? Showback macht Kosten für Teams sichtbar (Bewusstsein schaffen). Chargeback stellt diese Kosten den Teams oder Abteilungen tatsächlich in Rechnung (finanzielle Verantwortung).

Event-Driven Scaling mit KEDA: Wenn die Message Queue den Cluster steuert

Tue, 13 Jan 2026 09:10:32 +0000

Der klassische Horizontal Pod Autoscaler (HPA) von Kubernetes ist wie ein Thermostat: Wenn es im Zimmer zu warm wird (CPU > 80 %), geht die Klimaanlage an. Das funktioniert für Standard-Web-Apps gut, versagt aber in modernen, ereignisgesteuerten Architekturen.

Was ist, wenn Ihre CPU-Last niedrig ist, aber in Ihrer Kafka-Queue 10.000 unbearbeitete Aufträge liegen? Oder wenn Ihr System auf einen plötzlichen Spike von Webhooks reagieren muss? Hier stößt das Standard-Scaling an seine Grenzen. Die Lösung für 2026 heißt KEDA (Kubernetes Event-driven Autoscaling).

Vault, External Secrets & CSI: Der ultimative Guide zum Secret Management in K8s

Tue, 13 Jan 2026 08:58:21 +0000

„Base64 ist keine Verschlüsselung." Dieser Satz sollte über jedem Platform-Engineering-Team hängen. Standardmäßige Kubernetes-Secrets werden lediglich kodiert, nicht verschlüsselt. Wer Zugriff auf die API oder das etcd-Backend hat, kann Passwörter, API-Keys und Zertifikate im Klartext lesen.

Im Jahr 2026 ist ein professionelles Secret Management die Grundvoraussetzung, um Compliance -Vorgaben zu erfüllen und das Risiko von Datendiebstahl durch „Lateral Movement" im Cluster zu minimieren. Wir schauen uns an, wie Sie sensible Daten sicher verwalten, ohne den Workflow Ihrer Entwickler zu stören.

Policy-as-Code: Compliance automatisiert durchsetzen

Mon, 12 Jan 2026 14:29:44 +0000

Im Jahr 2026 ist Compliance kein “Papiertiger” mehr. Mit Regularien wie dem Cyber Resilience Act oder Zertifizierungen nach ISO 27001 und TISAX stehen IT-Verantwortliche vor einer gewaltigen Aufgabe: Sie müssen beweisen, dass Sicherheitsrichtlinien nicht nur existieren, sondern lückenlos und permanent in ihren Kubernetes Clustern erzwungen werden.

Wer hier auf manuelle Kontrollen setzt, verliert. Die Lösung ist Policy-as-Code (PaC). Dabei werden organisatorische Richtlinien in maschinenlesbaren Code gegossen und direkt durch den Cluster-Wächter (Admission Controller) geprüft. Das Prinzip: „Kein Deployment ohne Compliance-Check."

Alte Eisen, neue Hülle: Wie man Legacy-Monolithen mit Kubernetes-Sidecars modernisiert

Mon, 12 Jan 2026 10:40:52 +0000

„Das können wir nicht in die Cloud schieben, das ist ein Monolith." Diesen Satz hören wir oft. Doch Modernisierung bedeutet 2026 nicht mehr zwangsläufig, eine gewachsene Java- oder .NET-Applikation in kleinste Microservices zu zerlegen (Refactoring). Oft ist der schnellere und wirtschaftlichere Weg das Re-Platforming unter Nutzung des Sidecar-Patterns.

Anstatt den alten Code anzufassen, nutzen wir Kubernetes, um moderne Anforderungen wie Sicherheit, Observability und Konnektivität einfach „dranzuflanschen".

Der Sidecar-Ansatz: Hilfe von der Seite

In Kubernetes können mehrere Container innerhalb eines Pods laufen und sich Ressourcen wie das Netzwerk (localhost) teilen. Der Hauptcontainer (Ihr Monolith) bleibt unangetastet, während ein oder mehrere Sidecar-Container unterstützende Aufgaben übernehmen.

K8s am Point of Sale: Warum Produktion und Handel auf Edge-Cluster setzen

Mon, 12 Jan 2026 09:04:46 +0000

Lange Zeit galt Kubernetes als das Betriebssystem für das „große" Rechenzentrum. Doch 2026 findet die spannendste Entwicklung am Rand des Netzwerks statt – am Edge. Ob es die Bildverarbeitung in der Qualitätskontrolle einer Fabrik ist oder das Bestandsmanagement in hunderten Einzelhandelsfilialen: Zentrale Cloud-Lösungen stoßen hier an ihre Grenzen.

Latenzprobleme, Bandbreitenkosten und die Notwendigkeit von Autonomie (Offline-Fähigkeit) treiben Kubernetes aus der Cloud direkt auf die lokale Hardware.

Die Herausforderung: Tausend Cluster statt ein großer

Im Rechenzentrum managen wir meist wenige, sehr große Cluster. Am Edge kehrt sich das Prinzip um: Wir managen hunderte oder tausende Kleinst-Cluster (oft nur bestehend aus 1-3 Nodes). Das bringt völlig neue operative Anforderungen mit sich:

Developer Experience (DevEx): Warum Ihre Plattform scheitert, wenn sie nicht „liefert“

Mon, 12 Jan 2026 08:55:36 +0000

Wenn Unternehmen in Platform Engineering investieren, fließen 90 % der Ressourcen oft in die Technik: Kubernetes-Cluster, CI/CD-Pipelines und Security-Scanner. Doch der Erfolg einer Plattform entscheidet sich nicht an der Uptime, sondern an der Developer Experience (DevEx).

Im Jahr 2026 ist DevEx kein Luxus-Thema für Silicon-Valley-Giganten mehr. Für den deutschen Mittelstand ist es die einzige Antwort auf den Fachkräftemangel. Eine Plattform, die Entwickler mit komplexen YAML-Wüsten und Ticket-Wartezeiten ausbremst, wird ignoriert – oder schlimmer: sie führt zu Frust und Fluktuation.

Was kostet ein API-Call? Unit Economics für IT-Entscheider

Mon, 12 Jan 2026 08:48:23 +0000

In der klassischen IT-Welt war die Budgetplanung einfach: Man kaufte einen Server, schrieb ihn über fünf Jahre ab und verbuchte die Kosten als Fixum. In der Cloud-Native-Welt von 2026 ist diese Planbarkeit verschwunden. Cloud-Rechnungen sind dynamisch, komplex und oft entkoppelt vom tatsächlichen Geschäftserfolg.

Wer heute Kubernetes nutzt, darf nicht mehr nur fragen: „Wie hoch ist die monatliche Rechnung?" Die entscheidende Frage lautet: „Wie viel Infrastruktur-Kosten verursacht ein einzelner Verkauf, ein API-Call oder ein aktiver Nutzer?" Willkommen in der Welt der Cloud Unit Economics.

Supply Chain Security mit SBOM und Sigstore

Mon, 12 Jan 2026 08:42:03 +0000

Stellen Sie sich vor, Sie kaufen ein Fertiggericht im Supermarkt, auf dem keine Zutatenliste steht. In der Softwareentwicklung war das jahrelang der Standard: Wir laden Container–Images aus dem Netz und vertrauen darauf, dass nur das drin ist, was draufsteht. Doch Vorfälle wie Log4j haben gezeigt: Eine einzige kompromittierte Bibliothek in der Lieferkette kann globale Infrastrukturen lahmlegen.

Im Jahr 2026 ist Supply Chain Security kein “Nice-to-have” mehr. Mit Regularien wie dem EU Cyber Resilience Act (CRA) wird die Transparenz über die Software-Lieferkette zur Pflichtaufgabe für den Mittelstand.

Disaster Recovery Strategien für geschäftskritische K8s-Workloads

Mon, 12 Jan 2026 08:37:24 +0000

Viele IT-Verantwortliche im Mittelstand wiegen sich in Sicherheit, weil sie “Backups machen”. Doch im Ernstfall – etwa bei einem massiven Ausfall eines Cloud-Providers, einer Ransomware-Attacke oder einem menschlichen Fehler in der Root-Config – stellen sie fest: Ein Backup ist kein Recovery-Plan.

In der Cloud-Native Welt bedeutet Disaster Recovery (DR) nicht nur das Wiederherstellen von Daten. Es bedeutet das schnelle Wiederherstellen der gesamten Applikations-Topologie.

Backup vs. Disaster Recovery: Ein entscheidender Unterschied

Ein Backup ist eine Kopie von Daten. Disaster Recovery ist das Prozess-Framework, um den Geschäftsbetrieb innerhalb einer definierten Zeit wiederherzustellen. Dabei spielen zwei Kennzahlen die Hauptrolle:

Kubernetes v1.35: Einschränkung von ausführbaren Dateien in kubeconfigs durch exec-Plugin allowList hinzugefügt zu kuberc

Fri, 09 Jan 2026 18:30:00 +0000

TL;DR

Kubernetes v1.35 führt eine neue Funktion zur Einschränkung ausführbarer Dateien in kubeconfigs ein, um die Sicherheit zu erhöhen. Mit der Einführung einer allowlist für Credential-Plugins können Administratoren steuern, welche Plugins in ihrer Umgebung ausgeführt werden dürfen, was potenzielle Sicherheitsrisiken durch nicht vertrauenswürdige Codeausführungen minimiert.

Hauptinhalt

In Kubernetes v1.35 wurde eine bedeutende Sicherheitsfunktion implementiert, die es ermöglicht, die Ausführung von ausführbaren Dateien, die über kubeconfigs aufgerufen werden, zu steuern. Diese Funktion ist besonders relevant, da kubeconfigs die Möglichkeit bieten, beliebige ausführbare Dateien, einschließlich Shell-Skripte, mit den Rechten des aufrufenden Benutzers auszuführen. Dies kann ein Sicherheitsrisiko darstellen, insbesondere wenn die Pipeline zur Generierung des kubeconfigs kompromittiert ist oder ein Supply-Chain-Angriff erfolgt.

Polycrate CLI 0.29.5 released: Wildcard Endpoint API Sync Fix

Fri, 09 Jan 2026 15:00:00 +0000

Mit Version 0.29.5 erhält Polycrate einen kritischen Bugfix: Endpoints mit Wildcard-Hostnames wie *.example.com können jetzt korrekt zur API synchronisiert werden.

Das Problem

Endpoints von Ingress-Ressourcen mit Wildcard-Hostnames konnten nicht zur Polycrate API synchronisiert werden. Die API lehnte den Namen mit einem 400-Fehler ab:

unexpected status code: 400, response: {"name":["Name doesn't match RegEx..."]}

Die Ursache

Der Operator ersetzte bei der Endpunkt-Erstellung nur Punkte mit Dashes, aber nicht den Wildcard-Asterisk:

*.saar1.s3.loopbck.io → *-saar1-s3-loopbck-io ❌

Das * ist aber kein gültiges Zeichen für API-Namen.

Polycrate API 0.11.3 released: Workspace UUID Filter Fix

Fri, 09 Jan 2026 14:30:00 +0000

Mit Version 0.11.3 behebt die Polycrate API einen kritischen Bug im K8sCluster-Filter, der die Operator-Kommunikation beeinträchtigte.

Das Problem

Der K8sClusterFilter akzeptierte nur Workspace-Namen für den workspace Query-Parameter. Der Polycrate Operator sendet jedoch Workspace-UUIDs.

Folge: Der Operator versuchte bei jedem Reconcile ein neues Cluster zu erstellen, obwohl bereits eines existiert:

IntegrityError: duplicate key value violates unique constraint "unique_k8s_cluster_per_workspace"

Die Lösung

Neue filter_workspace() Methode erkennt automatisch ob der Wert eine UUID oder ein Name ist:

Polycrate CLI 0.29.4 released: Operator API Sync & TLS Port Fixes

Fri, 09 Jan 2026 14:00:00 +0000

Mit Version 0.29.4 erhält Polycrate kritische Bugfixes für den Operator: Korrekte Cluster-Erkennung bei Workspace-UUIDs, automatische TLS-Port-Synchronisation und verbesserte Node RBAC-Permissions.

Cluster API Filter Fix

Der Workspace-Filter bei der Cluster-Suche akzeptierte nur Namen, aber keine UUIDs. Da der Operator Workspace-UUIDs sendet, wurden existierende Cluster nicht gefunden und der Operator versuchte bei jedem Reconcile ein neues Cluster zu erstellen.

Fix: Der Filter erkennt jetzt automatisch ob der Wert eine UUID oder ein Name ist und filtert entsprechend.

GreenOps auf Kubernetes: CO2-Emissionen pro Microservice messen und optimieren

Fri, 09 Jan 2026 13:45:25 +0000

Nachhaltigkeit ist in der IT-Welt des Jahres 2026 kein bloßes Marketing-Schlagwort mehr. Mit der Ausweitung der EU-Berichtspflichten (CSRD) stehen IT-Entscheider vor einer neuen Herausforderung: Sie müssen den CO2-Fußabdruck ihrer digitalen Infrastruktur nicht nur schätzen, sondern präzise belegen.

Die Cloud galt lange als “sauber”, doch die Realität ist komplexer. Ein ineffizient skalierender Kubernetes-Cluster ist nicht nur teuer, sondern verschwendet auch wertvolle Energie. Hier setzt GreenOps an – die Disziplin, Energieeffizienz als primäre Kennzahl in den DevOps–Lifecycle zu integrieren.

Serving am Limit: LLM-Inferenz mit vLLM und Triton auf Kubernetes

Fri, 09 Jan 2026 12:39:00 +0000

Wenn ein KI-Modell die Trainingsphase verlässt, beginnt die eigentliche Herausforderung: Der produktive Inferenz-Betrieb. Ein Large Language Model (LLM) in einem Standard-Container zu „serven", ist ineffizient. Die Latenzen sind zu hoch und die GPU-Auslastung ist oft miserabel, da klassische Web-Server nicht für die sequenzielle Natur der Token-Generierung gebaut sind.

Um LLMs im Mittelstand wirtschaftlich und performant zu betreiben, müssen wir Kubernetes mit spezialisierten Inference Engines und intelligentem Batching kombinieren.

Die Ineffizienz des naiven Servings

Ein LLM generiert Token für Token. Wenn ein Nutzer eine Anfrage stellt, ist die GPU für die Dauer der gesamten Antwort belegt. In einem naiven Setup müsste der zweite Nutzer warten, bis die erste Antwort fertig ist – oder wir müssten für jeden Nutzer eine eigene GPU vorhalten. Beides ist im produktiven Umfeld inakzeptabel.

Polycrate CLI 0.29.3 released: SSH-Agent Auto-Mount, Git Branch-Aware & Operator-Fixes

Fri, 09 Jan 2026 12:00:00 +0000

Mit Version 0.29.3 erhält Polycrate Host SSH-Agent Auto-Mount für nahtlose Git-Operationen im Container, Branch-Aware Git-Commands und wichtige Operator-Fixes.

Action Run Output Capture

Container-Output wurde bei --docker-native (Standard seit 0.28.0) nicht an die Polycrate API übermittelt. Das stdout-Feld in ActionRun-Objekten war leer.

Fix: NativeDockerBackend.Run() verwendet jetzt io.MultiWriter um Output gleichzeitig anzuzeigen und zu erfassen.

Block Config Submission

Die block.poly Konfiguration wurde nicht korrekt zur API gesendet. Dies führte dazu, dass Block-Konfigurationen in der API fehlten.

Vector Databases on K8s: Performance-Tuning für RAG-Applikationen

Fri, 09 Jan 2026 11:16:53 +0000

In einer Retrieval Augmented Generation (RAG) Architektur ist die Vektor-Datenbank (Vector DB) das Herzstück. Sie liefert dem Large Language Model (LLM) den Kontext aus Ihren Unternehmensdaten. Doch während herkömmliche Datenbanken vor allem Disk-I/O-optimiert sind, stellen Vektor-Datenbanken wie Qdrant, Weaviate oder Milvus völlig neue Anforderungen an Ihre Kubernetes Infrastruktur.

Wenn die Suche nach relevanten Dokumenten zu lange dauert, nützt auch die schnellste GPU für die Inferenz nichts. Die User Experience (UX) Ihrer KI-App steht und fällt mit der Latenz Ihrer Vektor-Suche.

KI-Observability: Monitoring von LLMs und RAG-Pipelines in Kubernetes

Fri, 09 Jan 2026 11:03:20 +0000

Wer klassische Microservices betreibt, weiß: Metriken, Logs und Traces sind die Lebensversicherung. Doch bei KI-Workloads stoßen herkömmliche Monitoring-Ansätze an ihre Grenzen. Eine CPU-Auslastung von 10 % sagt uns nichts darüber aus, ob die Antwortqualität eines Sprachmodells gerade einbricht oder ob die Vektor-Suche ineffizient arbeitet.

Um eine KI-Plattform im Mittelstand produktiv zu betreiben, benötigen wir ein erweitertes Verständnis von Observability, das die Brücke zwischen Infrastruktur (GPU/K8s) und Modell-Performance (LLM) schlägt.

Europas Exportschlager: Personenbezogene Daten

Fri, 09 Jan 2026 10:05:45 +0000

Europas Exportschlager: Personenbezogene Daten

Europa versteht sich gern als globaler Hüter von Datenschutz und Grundrechten. DSGVO , NIS2, AI Act – der regulatorische Anspruch ist hoch, die Rhetorik selbstbewusst. In der operativen Realität entsteht jedoch ein anderes Bild: Personenbezogene Daten europäischer Bürgerinnen, Bürger und Unternehmen werden systematisch in Infrastrukturen ausgelagert, die außerhalb europäischer Rechts- und Kontrollräume liegen. Nicht illegal, aber politisch kurzsichtig. Nicht aus Zwang, sondern aus Bequemlichkeit.

Die aktuelle Debatte um Microsoft 365 in der Schweiz und in Bayern zeigt das Muster exemplarisch. Dreissig Schweizer Datenschutzbeauftragte warnen offen vor dem Einsatz mit sensiblen Daten. In Bayern prüft die Staatsregierung unter Markus Söder dennoch eine langfristige Bindung an Microsoft. Die Argumente sind überall gleich: bewährte Software, schnelle Einführung, Kompatibilität. Die Konsequenzen werden ausgeblendet.

Polycrate API 0.11.1 released: Alert Notification Loop deaktiviert

Fri, 09 Jan 2026 10:00:00 +0000

Mit Version 0.11.1 wird der automatische Alert Notification Loop in der Polycrate API temporär deaktiviert. Dies ist ein Patch-Release zur gezielten Steuerung des Benachrichtigungsverhaltens.

Änderungen

Alert Notification Loop deaktiviert

Der periodische Celery-Task alert_notification_loop, der alle 5 Minuten automatisch Benachrichtigungen über eingehende Alerts versendet hat, wurde temporär deaktiviert.

Vorher:

Task lief automatisch alle 5 Minuten
Versendete Benachrichtigungen über konfigurierte Notification Sinks (Mattermost, Slack, Email)

Nachher:

Task ist deaktiviert und läuft nicht mehr
Keine automatischen Benachrichtigungen bei neuen Alerts

Nicht betroffen

Die folgenden Funktionen bleiben vollständig aktiv:

Zero Trust für KI-Workloads: Datensouveränität in der Ära von LLM und GPU-Clustern

Fri, 09 Jan 2026 09:43:41 +0000

Die Einführung von Künstlicher Intelligenz im Mittelstand hat eine neue Sicherheitsfront eröffnet. Wenn wir LLMs trainieren oder RAG-Systeme (Retrieval Augmented Generation) aufbauen, bewegen wir massive Mengen sensibler Daten durch unseren Kubernetes–Cluster – oft direkt auf leistungsstarke GPU-Nodes.

Das Problem: Der klassische „Perimeter-Schutz" versagt hier völlig. Wenn ein Angreifer Zugriff auf einen weniger gesicherten Monitoring-Pod erhält, darf er nicht in der Lage sein, Trainingsdaten abzugreifen oder Modell-Gewichte zu exfiltrieren. Zero Trust für KI ist kein Luxus, sondern die Voraussetzung für den produktiven Einsatz.

Fortgeschrittene GPU-Strategien für effiziente KI-Cluster

Fri, 09 Jan 2026 09:30:14 +0000

Wer heute eine NVIDIA H100 oder A100 in seinen Cluster integriert, stellt schnell fest: Die klassische 1-zu-1-Zuweisung (ein Pod reserviert eine ganze GPU) ist im produktiven Alltag oft eine massive Kapitalverschwendung. Während das Training von LLMs die Hardware voll ausreizt, langweilen sich GPUs beim Inferenz-Betrieb oder in Entwicklungs-Umgebungen oft bei 10 % Auslastung.

Um die TCO (Total Cost of Ownership) Ihrer KI-Infrastruktur zu senken, müssen wir uns von der einfachen Zuweisung verabschieden und tief in das Resource-Management eintauchen.

Cloud-Native AI-Pipelines: MLOps mit Kubeflow vs. Ray

Fri, 09 Jan 2026 09:12:32 +0000

Die Begeisterung für Large Language Models (LLMs) und generative KI hat eine fundamentale Frage in die IT-Abteilungen zurückgebracht: Wie skalieren wir Machine Learning (ML) Workloads, ohne eine parallele Schatten-IT aufzubauen?

Kubernetes hat sich als Basis etabliert, doch die Wahl des Frameworks entscheidet darüber, ob Ihre Data Scientists effizient arbeiten oder in Infrastruktur-Details versinken. Mit Kubeflow und Ray stehen sich zwei Schwergewichte gegenüber, die grundlegend unterschiedliche Philosophien verfolgen.

Kubeflow: Das orchestrale Schwergewicht

Kubeflow verfolgt den Ansatz, eine vollständige End-to-End MLOps-Plattform auf Kubernetes-Basis bereitzustellen. Es ist weniger ein einzelnes Tool als vielmehr eine lose gekoppelte Sammlung von Komponenten (Pipelines, Training Operator, Katib für Hyperparameter-Tuning, KServe).

Internal Developer Platforms - Architekturen für echten Self-Service

Fri, 09 Jan 2026 08:55:58 +0000

In den letzten zwei Jahren ist “Internal Developer Platform” zum Buzzword avanciert. Doch während Gartner die IDP als Heilmittel gegen die kognitive Überlastung von Entwicklern preist, enden viele interne Projekte als starre Abstraktionsschichten, die mehr Probleme schaffen, als sie lösen.

Echter Self-Service entsteht nicht durch ein schickes GUI, sondern durch ein durchdachtes technisches Fundament, das Infrastruktur als Produkt begreift.

Das Kernproblem: Das “Abstraktions-Paradoxon”

Viele Plattform-Teams begehen den Fehler, Kubernetes komplett vor den Entwicklern zu verstecken. Sie bauen komplexe Wrapper um Helm-Charts oder nutzen proprietäre Portale, die nur 80 % der Use-Cases abdecken. Sobald ein Team die restlichen 20 % benötigt – etwa ein spezielles Ingress-Tuning oder ein Sidecar-Konfig – bricht das Modell zusammen und der manuelle Ticket-Prozess kehrt zurück.

Kubernetes v1.35: Änderbare PersistentVolume Node Affinität (alpha)

Thu, 08 Jan 2026 18:30:00 +0000

TL;DR

Kubernetes v1.35 führt eine alpha-Funktion ein, die es ermöglicht, die Node Affinität von PersistentVolumes (PVs) zu ändern. Diese Anpassung ermöglicht eine flexiblere Verwaltung von Speichervolumen, insbesondere in dynamischen Umgebungen, in denen sich die Anforderungen und die zugrunde liegende Speicherinfrastruktur ändern können.

Hauptinhalt

Die Node Affinität von PersistentVolumes ist ein wichtiges Merkmal von Kubernetes, das seit v1.10 existiert. Es ermöglicht die Angabe, dass nicht alle Knoten im Cluster gleichberechtigt auf bestimmte Volumes zugreifen können. Bis zur Version 1.35 war diese Affinität unveränderlich, was bedeutete, dass Änderungen an der zugrunde liegenden Infrastruktur nicht ohne Weiteres in Kubernetes reflektiert werden konnten. Mit der Einführung der mutierbaren Node Affinität in der alpha-Version von v1.35 wird diese Einschränkung aufgehoben, was eine flexiblere und dynamischere Verwaltung von Speichervolumen ermöglicht.

Vom Server-Hüter zum Plattform-Architekten: Die Evolution der IT-Abteilung

Thu, 08 Jan 2026 13:59:46 +0000

Wenn wir über den Wechsel zu Cloud-Native und Kubernetes sprechen, diskutieren wir meist über Architektur, Provider und Kosten. Doch die kritischste Variable in dieser Gleichung ist nicht der Tech-Stack – es ist Ihr Team.

Gerade im Mittelstand herrscht bei erfahrenen Administratoren oft eine unterschwellige Skepsis gegenüber der Cloud. Die Angst, durch Automatisierung ersetzt zu werden oder die Kontrolle über die “eigene” Hardware zu verlieren, ist real. Als IT-Entscheider ist es Ihre Aufgabe, diese Angst in Neugier zu verwandeln und den Weg vom klassischen Admin zum modernen Platform Engineer zu ebnen.

Hochverfügbarkeit im Mittelstand: Mit Kubernetes aus der Kostenfalle

Thu, 08 Jan 2026 13:12:48 +0000

Für kritische Anwendungen ist „Down-Time" im Mittelstand längst kein rein technisches Problem mehr, sondern ein direktes Geschäftsrisiko. Doch die traditionelle Antwort auf Hochverfügbarkeit (High Availability, HA) war jahrelang: Doppelte Infrastruktur = doppelte Kosten. Ein Modell, das viele Budgets sprengt.

Mit Kubernetes (K8s) verschiebt sich dieses Paradigma. HA ist hier kein teures Add-on mehr, sondern eine native Eigenschaft der Orchestrierung – vorausgesetzt, man versteht die Hebel für eine wirtschaftliche Redundanz.

HA ist kein binärer Zustand, sondern eine Design-Entscheidung

IT-Entscheider müssen heute definieren, welches Service Level (SLA) für welche Anwendung wirklich geschäftskritisch ist. Kubernetes erlaubt es uns, Hochverfügbarkeit modular und damit bezahlbar umzusetzen. Anstatt monolithische Cluster redundant vorzuhalten, nutzen wir die Mechanismen von K8s für ein intelligentes Failover-Management.

Effizienz statt Kostenschock: Warum Kubernetes das Herzstück Ihrer FinOps-Strategie ist

Thu, 08 Jan 2026 12:56:47 +0000

Dass FinOps die Antwort auf unkontrollierte Cloud-Ausgaben ist, müssen wir Ihnen nicht mehr erklären. Die Herausforderung für IT-Entscheider im Mittelstand liegt heute woanders: Wie lassen sich Kostenverantwortung und technische Skalierbarkeit so verzahnen, dass die Cloud nicht zum Fass ohne Boden wird?

Die Antwort liegt oft nicht in den Abrechnungs-Tools der Hyperscaler, sondern in der Art und Weise, wie Sie Ihre Kubernetes-Infrastruktur orchestrieren. Kubernetes ist mehr als ein Container–Tool – es ist, richtig konfiguriert, Ihre effizienteste FinOps-Maschine.

AWS EKS Alternative: Carefree Kubernetes mit ayedo

Thu, 08 Jan 2026 12:01:51 +0000

Kubernetes ist längst Standard, wenn es um skalierbare und hochverfügbare Software-Plattformen geht. Wer Kubernetes in der Cloud betreiben möchte, landet früher oder später bei AWS EKS (Elastic Kubernetes Service) – einem der bekanntesten Managed-Kubernetes-Angebote weltweit.

Doch gerade für Unternehmen mit Sitz in Deutschland oder der EU stellen sich zunehmend andere Fragen als nur Performance und Feature-Listen:

Wie souverän ist der Betrieb wirklich? Wie steht es um Datenschutz, Compliance und Auditierbarkeit? Wie transparent sind Kosten und Support?

Digitale Souveränität im Echtbetrieb: Warum Schleswig-Holstein mit Open Source Maßstäbe setzt

Thu, 08 Jan 2026 10:46:58 +0000

Die Entscheidung der Landesregierung Schleswig-Holstein, ihre Verwaltung konsequent auf Open-Source-Software umzustellen, ist mehr als ein politisches Signal. Sie ist ein realer, technisch anspruchsvoller Umbau einer komplexen IT-Landschaft – unter Volllast, mit rund 60.000 Beschäftigten, laufendem Justiz- und Verwaltungsbetrieb und klaren strategischen Zielen. Genau deshalb ist dieser Schritt vorbildlich.

Der vielzitierte Satz „Open Source ist schwierig" greift zu kurz. Die eigentliche Aussage dieses Projekts lautet: Digitale Souveränität ist erreichbar – wenn man bereit ist, Verantwortung für die eigene IT zu übernehmen.

Souveränitätsbarometer: Wie abhängig die öffentliche IT wirklich ist

Thu, 08 Jan 2026 10:20:27 +0000

Digitale Souveränität ist längst Teil jeder Digitalstrategie der öffentlichen Hand. Das Souveränitätsbarometer der öffentlichen IT von next:public zeigt jedoch, wie groß die Lücke zwischen Anspruch und Realität ist. Die Studie liefert belastbare Zahlen – und sie zeichnen ein klares Bild struktureller Abhängigkeit.

1. Der Kernbefund: Abhängigkeit ist der Normalzustand

Das Barometer basiert auf einer Befragung von IT-Verantwortlichen der öffentlichen Hand. Der zentrale Befund ist eindeutig:

Rund zwei Drittel der Verwaltungen stufen ihre Abhängigkeit von internationalen, außereuropäischen IT-Anbietern als stark ein.

Diese Abhängigkeit betrifft nicht Spezialanwendungen, sondern die Grundlagen des Verwaltungsbetriebs. Genau dort entsteht der größte Kontrollverlust.

Datenabfluss aus Owncloud & Nextcloud: Der Betrieb hat versagt, nicht die Software

Thu, 08 Jan 2026 09:23:54 +0000

Die aktuellen Berichte über massiven Datenabfluss aus selbst gehosteten Owncloud-, Nextcloud- und ShareFile-Instanzen sind technisch betrachtet unspektakulär – und genau das macht sie so problematisch. Es gab keinen Zero-Day, keine kompromittierte Verschlüsselung, keinen Architekturfehler in der Software. Der Zugriff erfolgte mit gültigen Benutzerkonten. Teilweise mit Zugangsdaten, die Jahre alt waren.

Wer daraus ein „Open-Source-Problem" ableitet, verkennt die Lage grundlegend.

Was ist passiert?

Angreifer haben Zugangsdaten genutzt, die zuvor über sogenannte Infostealer-Malware von Endgeräten abgegriffen wurden. Redline, Lumma, Vidar und ähnliche Varianten extrahieren gespeicherte Passwörter, Browserdaten und Session-Informationen. Diese Daten landen nicht sofort in Angriffen, sondern häufig monatelang oder jahrelang in Log-Sammlungen, die auf Untergrundmarktplätzen gehandelt werden.

Weekly Backlog KW 3/2026

Thu, 08 Jan 2026 08:57:54 +0000

🧠 Editorial

Digitale Souveränität wird gern beschworen, solange sie abstrakt bleibt. Als Zielbild. Als Vision. Als Strategiepapier. Sobald sie jedoch konkrete Entscheidungen verlangt – andere Anbieter, andere Verträge, andere Verantwortlichkeiten – wird sie unbequem. Genau an diesem Punkt trennt sich diese Woche sehr sauber, wer Souveränität meint und wer sie lediglich verwaltet.

Studien, Gutachten und reale Projekte zeichnen ein konsistentes Bild: Die Abhängigkeiten sind bekannt, die Alternativen existieren, das Wissen ist vorhanden. Was fehlt, ist Konsequenz. Und die Bereitschaft, kurzfristige Bequemlichkeit gegen langfristige Kontrolle einzutauschen.

Kubernetes v1.35: Ein besserer Weg, Service Account Tokens an CSI-Treiber zu übergeben

Wed, 07 Jan 2026 18:30:00 +0000

TL;DR

Kubernetes v1.35 führt eine verbesserte Methode zur Übergabe von Service-Account-Token an Container Storage Interface (CSI) Treiber ein. Die neue Beta-Funktion ermöglicht es Treibern, Tokens über das Secrets-Feld in NodePublishVolumeRequest zu empfangen, was die Sicherheit erhöht und das Risiko von versehentlichen Protokollierungen verringert.

Kubernetes v1.35 optimiert die Handhabung von Service-Account-Token für CSI-Treiber, indem ein neues opt-in Mechanismus eingeführt wird. Zuvor wurden Tokens über das volume_context-Feld übergeben, was sich als unsicher erwies, da sensible Informationen in Logs gelangen konnten. Dies geschah beispielsweise in den Vorfällen CVE-2023-2878 und CVE-2024-3744. Die neue Implementierung erlaubt es Treibern, Tokens über das secrets-Feld zu empfangen, was den Anforderungen der CSI-Spezifikation für sensible Daten besser entspricht.

HolmesGPT: Agentisches Troubleshooting für die Cloud-Native-Ära

Wed, 07 Jan 2026 12:00:00 +0000

TL;DR

HolmesGPT ist ein Open-Source-AI-Tool zur Fehlersuche in Kubernetes-Umgebungen, das Logs, Metriken und Traces integriert, um die Ursachenanalyse zu beschleunigen. Es nutzt eine agentische Architektur, um gezielte Abfragen durchzuführen und in natürlicher Sprache verständliche Diagnosen sowie Lösungsvorschläge zu bieten.

Hauptinhalt

Die Fehlersuche in Cloud-nativen Systemen stellt für viele Ingenieure eine erhebliche Herausforderung dar. Oftmals sind die Ursachen für Produktionsausfälle schwer zu identifizieren, da relevante Informationen verstreut und schwer zugänglich sind. HolmesGPT zielt darauf ab, diese Probleme zu adressieren, indem es eine integrierte Lösung bietet, die Daten aus verschiedenen Quellen zusammenführt und analysiert.

GPU-Orchestrierung: Das Fundament für skalierbare KI

Wed, 07 Jan 2026 10:29:14 +0000

Fast jedes moderne Unternehmen arbeitet heute an einer KI-Strategie. Ob Large Language Models (LLMs), Bilderkennung in der Qualitätskontrolle oder prädiktive Analysen – der Hunger nach Rechenleistung ist enorm. Doch während die Algorithmen immer präziser werden, stehen IT-Abteilungen vor einem neuen, physischen Problem: GPUs (Grafikprozessoren) sind teuer, schwer verfügbar und ihre Verwaltung unterscheidet sich grundlegend von klassischer IT-Infrastruktur.

Ohne eine intelligente GPU-Orchestrierung riskieren Unternehmen, dass ihre KI-Projekte entweder an explodierenden Kosten scheitern oder in starren Silos verharren, die keine Skalierung erlauben.

Polycrate API 0.11.0 released: Downtime Detection & Notification System

Wed, 07 Jan 2026 10:00:00 +0000

Mit Version 0.11.0 erhält die Polycrate API zwei zentrale neue Features: Downtime Detection & Logging für automatische Erfassung und SLA-Tracking von Service-Ausfällen, sowie ein Notification System für Multi-Provider-Benachrichtigungen.

Downtime Detection & Logging

Zentrale Erfassung und Tracking von Service-Downtimes mit vollständiger SLA-Integration.

Highlights:

Automatische Downtime-Erkennung: Downtimes werden automatisch erstellt wenn ManagedObjects in einen unhealthy State wechseln
SLA-Tracking: Berechnung der tatsächlichen Verfügbarkeit basierend auf Target-SLA
Multi-Object Support: Eine Downtime kann mehrere betroffene Objekte tracken
Activity-Aggregation: Alle Activities während einer Downtime werden automatisch verknüpft
Post-Mortem via Notes: Integration mit dem Notes-System für Dokumentation

Downtime-Kinds:

Skalieren ohne Kostenfalle: Infrastruktur-Optimierung für wachsende Unternehmen

Wed, 07 Jan 2026 09:40:29 +0000

„Die Cloud wächst mit Ihren Anforderungen." Dieses Versprechen ist Fluch und Segen zugleich. Für wachsende Unternehmen ist die Skalierbarkeit der Cloud essenziell, um mit steigenden Nutzerzahlen und Datenmengen Schritt zu halten. Doch in der Praxis folgt auf das schnelle Wachstum oft der Schock: Die monatlichen Rechnungen der Hyperscaler steigen schneller als der Umsatz.

Wer erfolgreich skalieren will, darf nicht einfach nur mehr Ressourcen buchen. Er muss seine Infrastruktur so optimieren, dass sie effizient und kostentransparent bleibt. Erfahren Sie, warum klassische Management-Ansätze beim Skalieren zur Kostenfalle werden und wie Sie durch intelligente Orchestrierung gesund wachsen.

Zero Trust in der Produktion: Warum die Firewall allein nicht mehr ausreicht

Wed, 07 Jan 2026 09:05:25 +0000

Zero Trust in der Produktion: Warum die Firewall allein nicht mehr ausreicht

Jahrzehntelang war die Sicherheitsstrategie in der Industrie klar definiert: Ein starker „Burggraben" (die Perimeter-Firewall) schützt das interne Maschinennetzwerk vor der Außenwelt. Doch in der vernetzten Industrie 4.0 bröckelt dieses Modell. Wenn Schadsoftware – etwa über ein infiziertes Techniker-Laptop oder eine kompromittierte Fernwartungsschnittstelle – erst einmal im internen Netz ist, hat sie oft freie Bahn. Hier setzt das Zero-Trust-Modell an. Das Prinzip: „Vertraue niemandem, verifiziere jeden." Erfahren Sie, wie Mikrosegmentierung innerhalb von Kubernetes verhindert, dass aus einem kleinen Vorfall ein fataler Produktionsstillstand wird. Das Problem: Das Risiko der lateralen Ausbreitung (Lateral Movement) In herkömmlichen, „flachen" Netzwerken können kompromittierte Systeme ungehindert mit anderen Geräten im selben Segment kommunizieren. Hacker nutzen dies für das sogenannte Lateral Movement: Sie springen von einem weniger kritischen System (z. B. einem Anzeige-Panel) auf die zentralen Steuerungen der Fertigungslinie über. Die Gefahren flacher Netzstrukturen:

Deterministisches AI-Testing mit Sitzungsaufzeichnung in cagent

Tue, 06 Jan 2026 19:16:04 +0000

TL;DR

Die neue Funktion zur Sitzungsaufzeichnung in cagent ermöglicht deterministisches AI-Testing, indem Interaktionen mit AI-Agenten aufgezeichnet und reproduziert werden können. Dies reduziert API-Kosten, verbessert die Entwicklerproduktivität und gewährleistet konsistente Testergebnisse.

Hauptinhalt

Die Implementierung von AI-Agenten bringt Herausforderungen mit sich, die bei herkömmlicher Software nicht auftreten, insbesondere das Problem der Nicht-Determinismus. Dies bedeutet, dass identische Eingaben unterschiedliche Ausgaben erzeugen können, was zuverlässiges Testen erschwert. cagent bietet eine Lösung durch die Funktion der Sitzungsaufzeichnung, die es ermöglicht, eine AI-Interaktion einmal aufzuzeichnen und diese dann beliebig oft mit identischen Ergebnissen abzuspielen. Dies geschieht ohne zusätzliche API-Kosten und mit Millisekunden-Latenz.

Polycrate CLI 0.29.2 released: Operator Bugfixes und Self-Reference Panic Fix

Tue, 06 Jan 2026 18:00:00 +0000

Mit Version 0.29.2 erhält Polycrate ein wichtiges Bugfix-Release mit Korrekturen für den Kubernetes Operator und kritische Panic-Fixes.

Operator: Loglevel wird respektiert

Der Operator verwendete bisher immer DEBUG-Logging, unabhängig von der Konfiguration. Jetzt wird der --loglevel Flag korrekt respektiert:

Loglevel	Ausgabe
1 (default)	INFO, WARN, ERROR
2	DEBUG-Meldungen sichtbar
3	Maximale Verbosität

Operator: Metriken verwenden API ID

Die Prometheus-Metriken des Operators (polycrate_io_endpoint_id) verwendeten bisher die Kubernetes UID statt der Polycrate API ID. Dies führte zu Mismatches bei der Korrelation von Metriken mit API-Daten.

NIS2 in der Fabrikhalle: Compliance durch Automatisierung

Tue, 06 Jan 2026 15:11:39 +0000

Die Schonfrist für die Cybersicherheit in der Industrie neigt sich dem Ende zu. Mit der neuen EU-Richtlinie NIS2(Network and Information Security Directive) werden deutlich mehr Unternehmen als bisher zu “wesentlichen” oder “wichtigen” Einrichtungen erklärt. Das bedeutet: Die Verantwortung für die Sicherheit der Operational Technology (OT)rückt direkt in den Fokus der Geschäftsführung – bei Androhung empfindlicher Bußgelder. Doch NIS2 sollte nicht nur als regulatorische Last gesehen werden. Sie ist die Chance, veraltete, unsichere Strukturen in der Produktion durch moderne, resiliente Standards zu ersetzen.

Vermeidung von Produktionsstillstand: Wie Self-Healing-Infrastrukturen die OT entlasten

Tue, 06 Jan 2026 14:55:28 +0000

Vermeidung von Produktionsstillstand: Wie Self-Healing-Infrastrukturen die OT entlasten

In der Welt der Operational Technology (OT) ist die Verfügbarkeit der Anlagen die wichtigste Kennzahl. Ein ungeplanter Stillstand in der Fertigungslinie kostet oft mehrere tausend Euro – pro Minute. Bisher bedeutete ein Softwarefehler oder der Absturz eines Edge-Gateways: Warten auf den Techniker, manuelle Fehlersuche und langwieriger Neustart. Moderne Cloud-Native-Technologien bringen ein Konzept in die Werkshalle, das dieses Risiko radikal minimiert: Self-Healing (Selbstheilung). Erfahren Sie, wie eine intelligente Infrastruktur Softwarefehler erkennt und behebt, noch bevor der Werker am Band etwas davon bemerkt. Das Problem: Der “stille” Ausfall in der Produktion

Air-Gapped Kubernetes: Cloud-Native Power für geschlossene Produktionsnetze

Tue, 06 Jan 2026 14:48:59 +0000

In der modernen Softwareentwicklung ist „immer online" das Standard-Paradigma. Doch in der industriellen Fertigung (OT), im Gesundheitswesen oder im Bereich kritischer Infrastrukturen sieht die Realität oft anders aus: Anlagen werden in Air-Gapped Umgebungen betrieben. Das bedeutet, dass diese Netzwerke physisch oder logisch komplett vom öffentlichen Internet isoliert sind – ein bewährtes Mittel zum Schutz vor Cyberangriffen und Industriespionage. Lange galt diese Isolation als Hindernis für moderne IT-Methoden. Doch heute zeigt sich: Cloud-Native-Technologien wie Kubernetes lassen sich erfolgreich in isolierten Netzen einsetzen, wenn man die Architektur grundlegend anpasst.

Digitale Sicherheit im fremden Rechtsraum: Warum das BSI-Portal auf AWS ein politischer Fehler ist

Tue, 06 Jan 2026 14:27:29 +0000

Ein Portal für mehr Sicherheit – auf unsicherem Fundament? Mit dem Start des zentralen BSI-Portals für NIS2-Meldungen verfolgt das Bundesamt für Sicherheit in der Informationstechnik (BSI) ein wichtiges Ziel: mehr Übersicht, schnellere Reaktionen und eine klare Anlaufstelle für Betreiber kritischer Infrastrukturen. Ein „One-Stop-Shop" für Cybersicherheit soll entstehen – und das ist grundsätzlich zu begrüßen.

Doch was auf den ersten Blick nach Fortschritt klingt, wirft bei genauerer Betrachtung ernsthafte Fragen auf. Denn: Das neue Portal läuft ausgerechnet auf der Cloud-Infrastruktur von Amazon Web Services (AWS) – einem US-Hyperscaler, der nicht dem europäischen Rechtsrahmen unterliegt. Was wie ein technisches Detail klingt, ist in Wahrheit eine strategische und politische Entscheidung mit weitreichenden Folgen.

Polycrate CLI 0.29.1 released: Ansible Upgrade und Secrets Registry Merge

Tue, 06 Jan 2026 14:00:00 +0000

Mit Version 0.29.1 erhält Polycrate ein wichtiges Maintenance-Release mit Ansible-Upgrade für kubernetes.core Kompatibilität.

Python & Ansible Upgrade

Upgrade von Python 3.11 auf 3.12 und Ansible 10.7.0 auf 13.2.0, um Zugriff auf moderne Ansible-Module zu erhalten.

Komponente	Alt	Neu
Python	3.11	3.12
Ansible	10.7.0	13.2.0
ansible-core	2.17.x	2.20.1
kubernetes.core	~3.x-5.x	>= 6.1.0

Hintergrund: Der take_ownership Parameter für kubernetes.core.helm wurde in Version 6.1.0 hinzugefügt. Dieser ermöglicht die Übernahme existierender Kubernetes-Ressourcen bei Helm Upgrades.

Weekly Backlog KW 2/2026

Tue, 06 Jan 2026 13:16:41 +0000

Editorial: Patchen ist kein Nice-to-have

KW 2 fühlt sich an wie ein Déjà-vu in Dauerschleife. Kritische Sicherheitslücken, politische Abhängigkeiten, Cloud-Lock-ins – alles bekannt, alles dokumentiert, alles trotzdem weiter betrieben wie bisher. Während über digitale Souveränität konferenziert wird, liegen produktive Systeme ungepatcht im Netz. Während man sich auf „bewährte Plattformen" verlässt, steigen Preise und Abhängigkeiten. Und während Behörden gern auf Verantwortung verweisen, endet diese erstaunlich oft exakt an der eigenen Zuständigkeit.

Europa liefert seine Verwaltung an Microsoft aus – und verliert dabei die Kontrolle

Tue, 06 Jan 2026 12:52:25 +0000

Eine kritische Analyse zur digitalen Souveränität in Deutschland und der Schweiz

Während europäische Regierungen in Sonntagsreden die Bedeutung digitaler Souveränität betonen, trifft die Realität der öffentlichen IT-Infrastruktur eine andere Sprache: Behörden auf allen Ebenen setzen weiterhin systematisch auf Microsoft – und damit auf einen US-Konzern, der faktisch der digitale Backbone ganzer Verwaltungseinheiten geworden ist. Nicht aus Zwang, sondern aus Bequemlichkeit. Nicht mangels Alternativen, sondern trotz besserer Optionen.

Was wie eine pragmatische Entscheidung für bekannte Software erscheint, ist in Wahrheit ein langfristiger politischer Kontrollverlust – mit klaren Risiken für Datenschutz, IT-Sicherheit und wirtschaftliche Unabhängigkeit.

Istio zur Verwaltung von stark frequentierten Services nutzen

Tue, 06 Jan 2026 12:46:40 +0000

TL;DR

Istio wird zur Verwaltung von hochfrequentierten SaaS-Plattformen eingesetzt, um Echtzeit-Verkehrskontrolle und Bot-Abwehr zu gewährleisten. Wichtige Funktionen wie Proxy-Protokoll, IP-basierte Zugriffskontrolle und Outlier Detection tragen zur Stabilität und Sicherheit der Infrastruktur bei.

Hauptinhalt

Die Nutzung von Istio als Kontroll-Plane ermöglicht die effektive Verwaltung von Envoy-Proxys, die neben Containern bereitgestellt werden. Diese Architektur bietet eine elegante Handhabung der meisten Anwendungsfälle durch Abstraktionen wie VirtualService, DestinationRule und AuthorizationPolicy. Bei Bedarf ermöglicht der EnvoyFilter den direkten Zugriff auf die Funktionen von Envoy, was eine flexible Anpassung der Infrastruktur erlaubt.

MongoBleed: Wenn Nachlässigkeit zur Sicherheitslücke wird

Tue, 06 Jan 2026 12:36:19 +0000

Deutschland auf Platz drei – aber nicht beim Patchen

Kurz vor Jahresende 2025 wurde bekannt, was längst Praxis war: Über 11.500 MongoDB-Instanzen in Deutschland sind über das Internet frei zugänglich und anfällig für eine kritische Sicherheitslücke, die unter dem Namen MongoBleed bekannt wurde. Weltweit liegt Deutschland damit auf einem traurigen dritten Platz – direkt hinter China und den USA. Besonders pikant: Kein Hoster weltweit zählt mehr verwundbare Instanzen als Hetzner, ein deutscher Anbieter.

Warum Ingress-NGINX eingestellt werden sollte – und warum es trotzdem weiterlebt

Tue, 06 Jan 2026 12:28:40 +0000

Warum Ingress-NGINX eingestellt werden sollte – und warum es trotzdem weiterlebt

Die Ankündigung von Kubernetes SIG Network, Ingress-NGINX einzustellen, war kein Betriebsunfall. Sie war das Ergebnis jahrelanger struktureller Überlastung – und sie war richtig. Nicht bequem, nicht populär, aber notwendig. Dass dieses Aus nun durch Chainguard abgefedert wird, ändert nichts an der Diagnose. Es verhindert aber, dass aus einer überfälligen Entscheidung ein operatives Desaster wird.

Ingress-NGINX war über lange Zeit das Rückgrat der Kubernetes-Ingress-Welt. Früh verfügbar, flexibel, überall einsetzbar. Genau diese Eigenschaften machten ihn zum Quasi-Standard. Und genau darin lag das Problem. Die enorme Verbreitung stand in keinem Verhältnis zur tatsächlichen Wartungsbasis. Kritische Infrastruktur, die Milliarden Requests verarbeitet, wurde faktisch von einer Handvoll Maintainer getragen – oft unbezahlt, oft nebenbei, oft unter permanenter Alarmbereitschaft.

GitOps in der Fabrik: Software-Rollouts für 100 Standorte gleichzeitig

Tue, 06 Jan 2026 12:01:21 +0000

In der Softwarewelt ist “Continuous Delivery” Standard. Doch in der Industrie sieht die Realität oft anders aus: Updates für Maschinensteuerungen oder Edge-Gateways werden häufig noch manuell per USB-Stick oder über unsichere VPN-Verbindungen eingespielt – Standort für Standort. Bei 100 Werken weltweit ist das nicht nur ineffizient, sondern ein massives Sicherheitsrisiko. Die Lösung für dieses Skalierungsproblem heißt GitOps. Erfahren Sie, wie wir bei ayedo Tools wie ArgoCD nutzen, um Software-Rollouts in der Fabrikhalle so sicher und einfach wie im Web zu machen.

Legacy-Maschinen cloud-ready machen: Retrofitting mit Container-Gateways

Tue, 06 Jan 2026 11:31:48 +0000

Legacy-Maschinen cloud-ready machen: Retrofitting mit Container-Gateways

In vielen deutschen Werkshallen steht das Rückgrat unserer Industrie: Bewährte Maschinen, die seit 10, 15 oder gar 20 Jahren zuverlässig ihren Dienst tun. Diese Anlagen sind mechanisch oft in Topform, technisch jedoch isoliert. Sie sprechen kein Cloud-Native, kennen kein JSON und sind für moderne Datenanalysen unsichtbar. Doch der Austausch einer Millioneninvestition ist oft unwirtschaftlich. Die Lösung heißt Industrial Retrofitting mittels Container-Gateways. Erfahren Sie, wie Sie Ihre SPS-Steuerungen (Speicherprogrammierbare Steuerungen) in eine moderne Kubernetes-Infrastruktur integrieren, ohne die Hardware anzutasten. Das Problem: Wenn die SPS nicht mit der Cloud spricht

Edge-Computing mit Kubernetes: Container-Orchestrierung in der Fabrikhalle

Tue, 06 Jan 2026 11:25:46 +0000

In der Theorie klingt die Cloud nach der perfekten Lösung für alles. In der Praxis der industriellen Fertigung stößt sie jedoch oft an ihre Grenzen – und zwar an die Grenzen der Physik. Wenn Millisekunden über die Qualität eines Bauteils entscheiden, ist der Weg in ein entferntes Rechenzentrum zu weit. Die Lösung: Edge-Computing. Und das Werkzeug der Wahl, um dies effizient zu verwalten? Kubernetes. Warum die Cloud allein in der Fabrik nicht ausreicht

Cloud-Native ohne Cloud-Lock-in: Warum Portabilität die neue Sicherheit ist

Tue, 06 Jan 2026 11:21:50 +0000

Cloud-Native ohne Cloud-Lock-in: Warum Portabilität die neue Sicherheit ist

Wer heute über moderne IT-Infrastruktur spricht, kommt an den großen Namen wie AWS, Google Cloud oder Azure nicht vorbei. Sie bieten Komfort, Geschwindigkeit und eine schier endlose Liste an Features. Doch dieser Komfort hat oft einen hohen Preis: den Vendor Lock-in.

In diesem Beitrag erfahren Sie, warum die Unabhängigkeit von einem spezifischen Anbieter (Portabilität) heute kein „Nice-to-have" mehr ist, sondern eine strategische Sicherheitskomponente für jedes digitale Unternehmen.

Vom Sensor in die Cloud: Skalierbare Infrastrukturen für die Industrie 4.0

Tue, 06 Jan 2026 11:14:51 +0000

In der modernen Fertigung ist die Frage längst nicht mehr, ob Daten erhoben werden, sondern wie sie effizient genutzt werden können. Während Maschinen (OT – Operational Technology) sekündlich Gigabytes an Telemetriedaten liefern, scheitern viele Unternehmen an der Brücke zur IT-Welt.

Der Weg vom Sensor in die Cloud ist die entscheidende Lebensader für die Industrie 4.0. Doch wie baut man eine Infrastruktur, die nicht nur heute funktioniert, sondern auch mit steigenden Datenmengen mitwächst?

Polycrate CLI 0.29.0 released: Operator Auto Workspace Resolution und Tools Overhaul

Tue, 06 Jan 2026 10:00:00 +0000

Mit Version 0.29.0 erhält Polycrate wesentliche Verbesserungen für den Kubernetes Operator und die integrierten CLI-Tools.

Operator Auto Workspace Resolution

Der Polycrate Operator erkennt jetzt automatisch den zugehörigen Workspace und die Organization anhand des Agent Tokens. Keine manuelle UUID-Konfiguration mehr erforderlich!

Vorher (< 0.29.0):

spec:
  api_sync:
    enabled: true
    credentials_ref:
      secret_name: polycrate-api-creds
      token_key: token
    workspace_id: "550e8400-e29b-41d4-a716-446655440000"  # Manuell!
    organization_id: "6ba7b810-9dad-11d1-80b4-00c04fd430c8"  # Manuell!

Nachher (0.29.0+):

spec:
  api_sync:
    enabled: true
    credentials_ref:
      secret_name: polycrate-api-creds
      token_key: token
    # workspace_id und organization_id werden automatisch abgeleitet!

Vorteile: Einfachere Installation, weniger Fehlerquellen und automatische Synchronisation mit der Polycrate API.

Kubernetes v1.35: Erweiterte Toleration Operators zur Unterstützung numerischer Vergleiche (Alpha)

Mon, 05 Jan 2026 18:30:00 +0000

TL;DR

Kubernetes v1.35 führt erweiterte Toleration Operators ein, die numerische Vergleiche ermöglichen. Mit den neuen Operatoren Gt (Greater Than) und Lt (Less Than) können Cluster-Administratoren spezifische Schwellenwerte für die Platzierung von Pods festlegen, was die Optimierung von Kosten und SLA-basierten Entscheidungen verbessert.

Hauptinhalt

In Kubernetes v1.35 wird die Funktionalität von Tolerationen durch die Einführung von erweiterten Toleration Operators erheblich erweitert. Diese neuen Operatoren ermöglichen es, numerische Vergleiche bei der Planung von Workloads in Kubernetes-Clustern durchzuführen. Bisher konnten Tolerationen nur exakte Werte oder das Vorhandensein eines Schlüssels überprüfen, was die Flexibilität bei der Platzierung von Pods einschränkte. Die neuen Operatoren Gt und Lt eröffnen nun die Möglichkeit, Schwellenwerte für die Platzierung von Pods festzulegen, was insbesondere für die Verwaltung von SLA-Anforderungen, Kostenoptimierung und leistungsbewusster Workload-Verteilung von Bedeutung ist.

Bereitstellung von Harbor auf Kubernetes mit Helm

Mon, 05 Jan 2026 13:14:00 +0000

TL;DR

Harbor ist ein leistungsstarkes, Open-Source-Container-Image-Registry, das sich nahtlos auf Kubernetes bereitstellen lässt. Die Nutzung von Helm zur Bereitstellung von Harbor ermöglicht eine skalierbare, hochverfügbare und ressourcenschonende Verwaltung von Container-Images, ergänzt durch Sicherheitsfeatures wie Schwachstellenscans und rollenbasierte Zugriffskontrollen.

Hauptinhalt

Harbor bietet eine umfassende Lösung für die Verwaltung von Container-Images und ist besonders für Unternehmen von Bedeutung, die ihre Containerisierungs-Workflows optimieren möchten. Die Bereitstellung von Harbor auf einer Kubernetes-Plattform bringt mehrere Vorteile mit sich. Kubernetes ermöglicht eine horizontale Skalierung der Harbor-Komponenten, sodass diese je nach Bedarf unabhängig voneinander skaliert werden können. Darüber hinaus sorgt die integrierte Hochverfügbarkeit von Kubernetes dafür, dass bei einem Ausfall eines Harbor-Komponenten diese automatisch neu gestartet wird, was die Ausfallzeiten minimiert.

Polycrate CLI 0.28.0 released: Workspace Encryption, Kubernetes Operator, Endpoint-Monitoring

Sun, 04 Jan 2026 12:00:00 +0000

Mit Version 0.28.0 erhält Polycrate das bisher umfangreichste Feature-Update. Drei Kernbereiche stehen im Fokus: sichere Workspace-Verschlüsselung, ein integrierter Kubernetes Operator für automatisierte Cluster-Verwaltung und Echtzeit-Endpoint-Monitoring.

Workspace-Verschlüsselung: Sensible Daten sicher verwalten

Infrastructure-as-Code bedeutet oft, dass sensible Informationen wie Zugangsdaten, API-Keys oder Zertifikate im Repository landen. Mit der neuen Workspace-Verschlüsselung können Sie diese Daten jetzt sicher in einer verschlüsselten secrets.poly speichern.

Die Verschlüsselung basiert auf age – einem modernen, auditierbaren Kryptographie-Standard. Ihre Secrets werden automatisch beim Ausführen von Actions entschlüsselt und stehen in Ansible-Playbooks und Jinja2-Templates zur Verfügung.

Kubernetes v1.35: Neues Effizienzlevel mit In-Place Pod-Neustart

Fri, 02 Jan 2026 18:30:00 +0000

TL;DR

Die Veröffentlichung von Kubernetes v1.35 führt eine neue Funktion ein, die einen effizienten In-Place-Neustart von Pods ermöglicht. Diese Funktion, bekannt als Restart All Containers, reduziert die Kosten und Komplexität beim Umgang mit Containerfehlern, insbesondere in anspruchsvollen AI/ML-Umgebungen.

Hauptinhalt

Kubernetes v1.35 bringt eine bedeutende Erweiterung in Form der Funktion Restart All Containers, die es ermöglicht, alle Container eines Pods in einem einzigen Schritt neu zu starten, ohne den Pod zu löschen und neu zu erstellen. Diese Funktion ist besonders vorteilhaft für Anwendungen mit komplexen Abhängigkeiten zwischen Containern, wie sie häufig in AI/ML-Workloads vorkommen. Anstatt die Ressourcen für das Löschen und die Neuerstellung von Pods aufzuwenden, können Entwickler nun die Pod-Zustände effizient zurücksetzen.

Kubernetes 1.35: Verbesserte Fehlersuche mit versionierten z-pages APIs

Wed, 31 Dec 2025 18:30:00 +0000

TL;DR

Kubernetes 1.35 führt strukturierte, versionierte Antworten für die z-pages Debugging-Endpunkte /statusz und /flagz ein. Diese Neuerung verbessert die Automatisierung von Troubleshooting-Prozessen und ermöglicht eine einfachere Integration in Monitoring-Tools.

Hauptinhalt

Die Fehlersuche in Kubernetes -Komponenten des Control Plane kann komplex sein, insbesondere wenn es darum geht, den aktuellen Zustand eines Moduls schnell zu verstehen oder dessen Konfiguration zu überprüfen. Mit der Version 1.35 von Kubernetes wird die Debugging-Funktionalität durch die Einführung strukturierter, maschinenlesbarer Antworten auf den z-pages Endpunkten erheblich verbessert. Diese Endpunkte, die ursprünglich in Kubernetes 1.32 als Alpha-Feature eingeführt wurden, bieten Diagnosedaten für wichtige Komponenten wie kube-apiserver, kube-controller-manager, kube-scheduler, kubelet und kube-proxy.

Weekly Backlog KW 53/2025

Wed, 31 Dec 2025 04:51:55 +0000

🧠 Editorial – Silvester mit Restlogfiles

🧠 Editorial

Es gibt Wochen, in denen Tech nicht nur Schlagzeilen produziert, sondern tektonische Verschiebungen. Open Source verliert wichtige Standbeine, Hyperscaler machen ihre Abhängigkeit erstmals richtig teuer, kritische Infrastruktur zeigt wiederholt Risse – und während Europa sicherheitspolitisch aufwacht, setzt Washington Technologie offen als geopolitisches Druckmittel ein. Kurz gesagt: Die nächsten Jahre werden weniger von Tools geprägt sein als von Machtfragen.

🚨 Die Tech-News der Woche

MinIO stellt Community Edition ein – ein weiterer Riss im Open-Source-Fundament

MinIO verabschiedet seine Community Edition in den Maintenance Mode: keine aktiven Features mehr, Security-Fixes nur noch im Ausnahmefall. Für ein Projekt, das seit Jahren als quasi-Standard im On-Prem-S3-Segment gilt, ist das ein harter Einschnitt.

Nextcloud souverän betreiben: Warum das „Wie“ entscheidend ist

Mon, 01 Dec 2025 11:22:20 +0000

Nextcloud souverän betreiben: Warum das „Wie“ entscheidend ist

Nextcloud steht für digitale Unabhängigkeit, europäische Datenschutzstandards und eine offene, vertrauenswürdige Alternative zu US-basierten Collaboration-Lösungen wie Microsoft 365 oder Google Workspace. Kein Wunder also, dass immer mehr Anbieter Managed Nextcloud-Services bewerben – oft kombiniert mit attraktiven Einstiegspreisen und dem Versprechen vollständiger Souveränität.

Doch ein genauer Blick auf die Angebote lohnt sich. Denn die Frage ist nicht nur ob Nextcloud genutzt wird, sondern wie es betrieben wird: Wer hat die Kontrolle über Infrastruktur und Daten? Wie transparent sind die Kosten? Wie flexibel ist die Lösung in der Praxis?

Sovereign Washing

Thu, 27 Nov 2025 10:06:37 +0000

Wie scheinbar „souveräne" Cloud-Angebote Abhängigkeiten verschleiern – und was das ZenDiS klarstellt

Digitale Souveränität hat in den vergangenen Jahren einen festen Platz in politischen Strategien, Verwaltungsmodernisierung und IT-Planung eingenommen. Angesichts geopolitischer Spannungen, wachsender Cyberrisiken und internationaler Rechtskonflikte ist die Frage nach Kontrolle über digitale Infrastrukturen längst nicht mehr abstrakt. Sie entscheidet über Handlungsfähigkeit, Sicherheit und wirtschaftliche Stabilität.

Mit dem neuen Whitepaper zeigt das Zentrum für Digitale Souveränität der öffentlichen Verwaltung (ZenDiS), wie groß die Lücke zwischen Marketingversprechen und tatsächlicher technischer Unabhängigkeit bei vielen Cloud-Angeboten ist. Der Begriff „Sovereign Washing" beschreibt dabei ein Problem, das im Markt zunehmend sichtbar wird: Dienstleistungen werden als souverän beworben, erfüllen aber nur sehr begrenzt die notwendigen Anforderungen.

Weekly Backlog KW 49/2025

Thu, 27 Nov 2025 09:22:54 +0000

Editorial

Europa spricht seit über zehn Jahren über digitale Souveränität. Man könnte also annehmen, dass die Debatte heute auf einer gewissen Flughöhe geführt wird: nüchtern, realistisch, strategisch. Doch statt einer Vision erleben wir eher einen schlechten Reboot alter Diskussionen.

Diese Woche zeigt exemplarisch, wo wir stehen:

ZenDiS wiederholt geduldig, was Souveränität eigentlich bedeutet.
Die Schweiz zieht sehr klare Konsequenzen.
GitLab erinnert Admins daran, dass Security-Teams nicht schlafen dürfen.
Und im EU-Parlament diskutieren manche lieber über Tastaturen als über Infrastruktur.

Thu, 13 Nov 2025 11:18:11 +0000

Container sind das Rückgrat der modernen Cloud-Infrastruktur. Sie bieten Entwicklern und Ops-Teams unschlagbare Agilität und Effizienz, basierend auf dem Versprechen robuster Isolation. Doch dieses Fundament wird regelmäßig auf die Probe gestellt. Die Entdeckung kritischer Laufzeitfehler (Runtime Bugs), die es Angreifern ermöglichen, aus einem Container auszubrechen und Root-Rechte auf dem Host-System zu erlangen, ist eine ernste Mahnung.

Der Riss in der Isolation

Das Kernprinzip von Container-Technologien ist die Trennung: Der Container soll keinen Zugriff auf das Host-Betriebssystem haben. Diese Isolation wird primär durch Linux-Funktionen wie Namespaces und Cgroups gewährleistet und durch die sogenannte Container-Runtime (runc ist ein bekanntes Beispiel) verwaltet.

Transatlantischer Zugriff auf biometrische Daten: Uneinigkeit unter EU-Mitgliedstaaten

Thu, 13 Nov 2025 10:57:25 +0000

Transatlantischer Zugriff auf biometrische Daten: Uneinigkeit unter EU-Mitgliedstaaten

Die US-Regierung fordert seit mehreren Jahren ein umfassendes Abkommen zum Zugriff auf biometrische Polizeidaten aus Europa. Grundlage ist die geplante „Enhanced Border Security Partnership" (EBSP), die für alle 43 Staaten des amerikanischen Visa-Waiver-Programms gelten soll. Wer bis Ende 2026 kein entsprechendes Abkommen unterzeichnet, riskiert den Verlust der visafreien Einreise in die USA.

Ein von der NGO Statewatch veröffentlichtes Ratsdokument zeigt nun, wie unterschiedlich die EU-Mitglieder die US-Forderungen bewerten. Die Mehrheit der Staaten signalisiert grundsätzliche Bereitschaft zu Verhandlungen, fordert aber klare Bedingungen und Begrenzungen. Die Spannbreite reicht von strikter Ablehnung eines US-Direktzugriffs bis hin zu weitreichender Offenheit für automatisierte Abfragen.

Weekly Backlog KW 47/2025

Thu, 13 Nov 2025 10:42:34 +0000

Weekly Backlog #47 — Digitale Souveränität? Ich hätte da ein paar Fragen…

Editorial

Willkommen zu einer Woche, in der Europa wieder einmal zeigt, wie man 1) Rechte verkauft, 2) Infrastruktur schleifen lässt, 3) Gesetze verwässert und 4) trotzdem glaubt, digital souverän zu sein. Dazwischen: Kubernetes gibt ein zentrales Bauteil seines Ökosystems auf, die Bundesregierung entdeckt plötzlich Milliarden im Sofa, und Cloudflare entscheidet sich, das Internet mal kurz auszuschalten.

Sam Altman, der Pinocchio des Silicon Valley

„A lie keeps growing and growing, until it’s as plain as the nose on your face." Was Disney einst Kindern beibrachte, ist heute eine treffende Beschreibung für Sam Altmans Kommunikationsstil.

LLMs als Waffe: Neue Ära der Cyberbedrohung

Mon, 10 Nov 2025 08:49:27 +0000

Die rasante Entwicklung von Künstlicher Intelligenz, insbesondere von Large Language Models (LLMs) wie Google Gemini oder OpenAI’s ChatGPT, hat das Potenzial, unsere Welt zu revolutionieren. Leider bleiben diese mächtigen Werkzeuge auch der Cyberkriminalität nicht verborgen. Bedrohungsakteure sind längst von der bloßen Produktivitätssteigerung (z. B. dem Verfassen besserer Phishing-E-Mails) zur aktiven Weaponisierung von KI in Malware und Angriffsmethoden übergegangen.

Thu, 06 Nov 2025 10:16:35 +0000

Kubernetes ist das Betriebssystem der souveränen Cloud

Kaum eine Technologie hat die moderne IT so grundlegend verändert wie Kubernetes. Ursprünglich als Container -Orchestrierungssystem gestartet, hat es sich in weniger als einem Jahrzehnt zu einer der zentralen Säulen der digitalen Infrastruktur entwickelt. Heute ist Kubernetes nicht mehr nur ein Werkzeug zum Verteilen von Workloads – es ist eine universelle Abstraktionsschicht über die Cloud selbst.

In einer Welt, in der Organisationen zunehmend über die Frage stolpern, wem ihre Daten, Systeme und Plattformen eigentlich gehören, wird diese Eigenschaft zur strategischen Schlüsselfunktion. Kubernetes ist damit weit mehr als ein weiteres Cloud-Tool: Es ist das Betriebssystem der souveränen Cloud – eine gemeinsame Sprache für den Betrieb von Software, unabhängig davon, wo sie läuft.

Delos Cloud vs. Stackit Workspace – Wölfe im Schafspelz

Thu, 06 Nov 2025 09:38:26 +0000

Delos Cloud vs. Stackit Workspace – Wölfe im Schafspelz

Die Diskussion um digitale Souveränität in Deutschland und Europa ist in vollem Gange. Kaum ein anderes Thema wird derzeit so stark von Politik, Verwaltung und Wirtschaft gleichermaßen getrieben. Die Forderung ist klar: Europa soll unabhängiger werden, insbesondere von den großen amerikanischen Hyperscalern – also AWS, Microsoft Azure und Google Cloud.

Doch während der Begriff „Souveränität" in der öffentlichen Kommunikation an Gewicht gewinnt, verliert er an Substanz. Die Schlagworte klingen nach Kontrolle, Eigenständigkeit und Datenschutz. Die Realität sieht oft anders aus.

Cloud Brokering für echte Souveränität

Thu, 06 Nov 2025 09:01:57 +0000

Cloud Brokering für echte Souveränität

Die Diskussion um digitale Souveränität in Europa ist alt – aber sie ist aktueller denn je. Spätestens seit der geopolitischen und regulatorischen Verschärfung der letzten Jahre ist klar geworden, dass die Frage, wo und wie Daten verarbeitet werden, nicht mehr nur eine technische, sondern eine strategische ist.

Staaten, Unternehmen und Behörden beginnen zu verstehen, dass digitale Unabhängigkeit mehr bedeutet als Datenschutz und mehr erfordert als ein EU-Rechenzentrum.

Docker Swarm ist kein Kubernetes für Einsteiger

Thu, 06 Nov 2025 08:54:39 +0000

Docker Swarm ist kein Kubernetes für Einsteiger

Wer heute über Container-Orchestrierung spricht, landet schnell bei zwei Begriffen: Docker Swarm und Kubernetes. Beide versprechen, Container auf mehreren Maschinen zu betreiben, Dienste zu skalieren und Deployments zu automatisieren. Und weil Kubernetes den Ruf hat, komplex zu sein, greifen viele Organisationen zunächst zu Docker Swarm – in der Hoffnung, sich mit weniger Aufwand in die Welt der Container-Orchestrierung einarbeiten zu können.

DevOps funktioniert immer noch nicht

Thu, 06 Nov 2025 08:45:18 +0000

DevOps funktioniert immer noch nicht

Warum Ego, Verantwortung und Realität den Traum von „gemeinsamer Ownership" immer noch scheitern lassen.

Vor über einem Jahrzehnt wurde DevOps als Befreiung gefeiert. Ein Kulturwandel, der die alten Mauern zwischen Entwicklung und Betrieb einreißen sollte. Ein gemeinsames Verständnis: Entwickler und Operations arbeiten in einem Team, teilen Verantwortung, Tools, Prozesse und Ziele. Heute, mehr als zehn Jahre später, ist das Versprechen in vielen Organisationen gebrochen. Die Trennung besteht weiterhin – nur subtiler. Und in vielen Fällen ist die Kluft sogar größer als zuvor.

Docker hier, Docker da – ich mach das wieder wie früher

Thu, 06 Nov 2025 08:21:04 +0000

Docker hier, Docker da – ich mach das wieder wie früher

Man hört es immer öfter, halb ernst, halb genervt: „Docker hier, Docker da – ich mach das wieder wie früher."

Und wer’s sagt, meint meistens: Ich bin müde von der nächsten großen „Vereinfachung", die am Ende alles komplizierter macht. Wieder ein neues Tool, neue Begriffe, neue YAML-Dateien. Früher hat man einfach Software installiert. Ein apt install, ein service start, fertig.

Docker Swarm oder Kubernetes - was bereitet weniger Schmerzen?

Thu, 06 Nov 2025 08:15:45 +0000

In vielen Gesprächen mit IT-Leitern, Sysadmins und Architekturverantwortlichen zeigt sich ein wiederkehrendes Muster: Die Frage nach „Swarm oder Kubernetes“ wird nicht nur technologisch geführt, sondern auch strategisch. Welche Plattform bringt weniger Schmerzen im Betrieb, mehr Skalierungspotenzial und langfristige Stabilität? Nach Jahren operativer Erfahrung kommt bei uns bei ayedo eine deutliche Präferenz heraus – Kubernetes. Aber: Das heißt nicht, dass Swarm keine Existenzberechtigung hat. Im Gegenteil – nur darf man nicht glauben, man könne Swarm heute als langfristige Lösung wählen und damit die Lernkurve von Kubernetes umgehen. Man landet früher oder später bei Kubernetes – mit den typischen „Und plötzlich-Problemen", die Swarm insbesondere im grösseren Umfeld mitbringt.

Docker vs. VM – Was ist eigentlich der Unterschied?

Thu, 06 Nov 2025 07:50:40 +0000

Viele Leute nicken wissend, wenn das Gespräch auf „Containerisierung" oder „virtuelle Maschinen" kommt – aber ganz ehrlich: Wer wirklich erklären kann, wo genau der Unterschied liegt, ist seltener, als man denkt.

Und das ist völlig in Ordnung. Denn die Unterschiede sind weniger „magisch", als oft behauptet wird – sie liegen tief in der Art, wie wir Systeme isolieren, betreiben und skalieren.

1. Virtuelle Maschinen: Schwergewichte mit viel Kontrolle

Virtuelle Maschinen (VMs) sind der Klassiker der Infrastrukturwelt. Eine VM ist im Prinzip ein kompletter Computer – nur eben virtuell. Sie hat ein eigenes Betriebssystem, eigene virtuelle Hardware und läuft auf einem sogenannten Hypervisor wie VMware, Hyper-V oder KVM.

Alerting & Incident Response: Von der Anomalie zum Abschlussbericht

Wed, 05 Nov 2025 12:00:00 +0000

TL;DR

Ein funktionierendes Alerting ist mehr als ein paar Mails bei 80 % CPU: Es braucht saubere Metriken, klare Schweregrade, durchdachtes Routing und Throttling, damit relevante Incidents zuverlässig erkannt werden – ohne das Team zu überlasten.
Incident Response funktioniert nur als definierter Prozess: Detection → Triage → Investigation → Mitigation → Resolution → Postmortem. Jede Phase hat andere Ziele, Akteure, Tools und Artefakte.
NIS‑2 und DORA verlangen nicht nur „irgendwie reagieren“, sondern nachvollziehbare, dokumentierte Abläufe – inklusive Frühwarnung innerhalb von 24 Stunden, Erstbericht nach 72 Stunden und Abschlussbericht innerhalb von 30 Tagen.
Mit VictoriaMetrics/Grafana für Alerting, VictoriaLogs für Forensics und GitLab (Issues & Wiki) für Tracking und Postmortem-Berichte lässt sich eine Incident Response-Chain aufbauen, die gleichzeitig technisch robust und auditierbar ist.
ayedo kombiniert eine Cloud‑Native Plattform mit integriertem Monitoring, Logging und Compliance-Bausteinen, sodass europäische Organisationen NIS‑2- und DORA‑konforme Incident-Prozesse pragmatisch umsetzen und mit einem praxisnahen Incident Response Playbook arbeiten können.

Warum strukturiertes Alerting und Incident Response heute Pflicht ist

Als europäische Technologiebranche stehen wir an einem Punkt, an dem professionelles Incident Management nicht mehr „nice to have“ ist, sondern regulatorischer Standard.

Weekly Backlog KW 45/2025

Tue, 04 Nov 2025 14:58:39 +0000

🗞 Weekly Backlog – KW 45/2025

Europa entdeckt, dass digitale Unabhängigkeit kein Ideal ist, sondern ein Wartungsfall.

Editorial

In dieser Woche hatte die digitale Souveränität gleich mehrere Bühnen. Von der Verwaltung über die Forschung bis zur Justiz. Während Microsofts DNS-Probleme die halbe Infrastrukturen ausknockt, feiert das Bundesministerium für Digitales seinen TYPO3-Erfolg als Symbol staatlicher Emanzipation. Die DFG zieht Daten aus US-Clouds, der Internationale Strafgerichtshof ersetzt Microsoft durch OpenDesk, und die Industrie ruft „Stop the clock", um beim AI Act Zeit zu gewinnen.

Observability im Detail: VictoriaMetrics, VictoriaLogs, Grafana

Tue, 04 Nov 2025 12:00:00 +0000

TL;DR

Observability basiert auf drei Säulen – Metriken, Logs und Traces – und wird durch die vier Golden Signals (Latency, Traffic, Errors, Saturation) in ein praxistaugliches Monitoring-Modell für moderne, oft verteilte Systeme übersetzt.
VictoriaMetrics liefert als Prometheus-kompatible, hochperformante Time-Series-Datenbank die Basis für Metriken mit Langzeit-Retention, skalierbarem Durchsatz und nativer Integration in Kubernetes über ServiceMonitors.
VictoriaLogs ergänzt diese Perspektive mit strukturierten, manipulationssicheren Logs auf Basis von LogQL und integriert sich nahtlos in Grafana, wodurch technische und regulatorische Anforderungen (z. B. Nachvollziehbarkeit, Unveränderbarkeit) effizient erfüllbar werden.
Grafana fungiert als zentrale Observability-Konsole: Dashboards, Alerting und Multi-Datasource-Fähigkeiten erlauben es, Golden Signals für Anwendungen wie Django-Services über Metriken und Logs hinweg konsistent zu visualisieren.
ayedo unterstützt Sie dabei, ein durchdachtes Observability-Setup auf Basis von VictoriaMetrics, VictoriaLogs und Grafana aufzubauen – von Architektur und Betrieb über Dashboards bis zur Einbettung in Ihre Plattform- und Compliance-Strategie.

Warum Observability heute unverzichtbar ist

Moderne Anwendungen bestehen selten aus einem Monolithen. Typischer sind Dutzende bis Hunderte Services, verteilt über Container, /kubernetes/-Cluster, Datenbanken und externe APIs. Fehlerfreiheit ist in solchen Umgebungen illusorisch – entscheidend ist, wie schnell und zuverlässig Sie Probleme erkennen, einordnen und beheben.

Digitale Unabhängigkeit: IStGH wechselt zu OpenDesk

Mon, 03 Nov 2025 13:32:45 +0000

Der Internationale Strafgerichtshof (IStGH) in Den Haag zieht eine weitreichende Konsequenz aus den jüngsten politischen Spannungen mit den USA: Er beendet die Zusammenarbeit mit US-amerikanischen Technologieanbietern wie Microsoft und setzt künftig auf die vom Bund entwickelte Open-Source-Plattform OpenDesk. Der Schritt markiert einen Wendepunkt im Umgang internationaler Institutionen mit digitaler Abhängigkeit und unterstreicht die strategische Bedeutung technologischer Souveränität.

Auslöser der Entscheidung ist laut einem Bericht des Handelsblatts die Sorge vor politischer Einflussnahme aus den USA. Unter der Regierung von Präsident Donald Trump hatte Washington Sanktionen gegen Mitarbeiter des IStGH verhängt – darunter auch gegen Chefankläger Karim Khan. In der Folge sperrte Microsoft Khan den E-Mail-Zugang, wodurch die Arbeitsfähigkeit des Gerichts unmittelbar beeinträchtigt wurde. Dieser Vorfall machte deutlich, wie verwundbar internationale Institutionen sind, wenn sie in zentralen Arbeitsbereichen auf ausländische Cloud- und Kommunikationsdienste angewiesen sind. Digitale Infrastruktur, die bislang als neutrale Dienstleistung galt, wurde zum geopolitischen Druckmittel.

Zwischen Anspruch und Realität: Verzögert sich der Start des AI Act?

Mon, 03 Nov 2025 12:06:40 +0000

Eigentlich sollte der europäische AI Act, die erste umfassende Regulierung für Künstliche Intelligenz weltweit, ab August 2026 vollständig in Kraft treten. Doch derzeit mehren sich Hinweise, dass sich dieser Zeitplan verschieben könnte. Industrieverbände und große Technologieunternehmen fordern eine Fristverlängerung, während zivilgesellschaftliche Organisationen vor einem Rückschritt in der europäischen Digitalpolitik warnen.

Hintergrund: Der Zeitplan der Verordnung

Die EU hatte den AI Act im August 2024 verabschiedet. Seitdem tritt die Verordnung schrittweise in Kraft:

DFG zieht die Notbremse: Deutsche Forschung holt ihre Daten aus der US-Cloud

Mon, 03 Nov 2025 12:03:17 +0000

Die Deutsche Forschungsgemeinschaft (DFG) hat ein klares Signal gesetzt: Sie startet ein Förderprogramm, um gefährdete Forschungsdaten aus ausländischen Cloud-Speichern zurückzuholen – vor allem aus den Rechenzentren von Amazon, Google und Microsoft. Was nach einer technischen Detailfrage klingt, ist in Wahrheit eine überfällige politische Entscheidung.

Seit Jahren lagern zentrale Datenbestände der deutschen und europäischen Wissenschaft auf Servern US-amerikanischer Konzerne. Der Grund ist einfach: Die Angebote dieser Anbieter sind bequem, skalierbar und weit verbreitet. Doch sie sind nicht souverän.

Guardrails in Action: Policy-basierte Deployment-Validierung mit Kyverno

Mon, 03 Nov 2025 12:00:00 +0000

TL;DR

Guardrails sind automatisierte Leitplanken rund um Ihre Deployments: Sie verhindern typische Fehlkonfigurationen, setzen Security by Default durch und erhöhen die Betriebssicherheit, ohne Ihre Teams zu entmündigen.
Mit Kyverno als Policy-Engine lassen sich Security-, Reliability- und Operational-Guardrails zentral definieren und im Enforce-Modus durchsetzen – direkt an der Admission-Schnittstelle Ihres Kubernetes-Clusters.
Security-Guardrails wie „keine privilegierten Container“, „nur vertrauenswürdige Registries“, verpflichtende Network Policies und konsistente Security Contexts unterstützen die Erfüllung von Anforderungen aus Art. 32 GDPR, NIS-2 und BSI IT-Grundschutz.
Reliability- und Operational-Guardrails (Resource Requests/Limits, Mindest-Replikazahl, PodDisruptionBudgets, Vermeidung von LoadBalancern, Local Storage und ungleichmäßiger Pod-Verteilung) stabilisieren Ihre Plattform und reduzieren manuelle Betriebsaufwände.
ayedo nutzt Kyverno-basierte Guardrails als integralen Bestandteil der Plattform-Architektur, um Organisationen dabei zu unterstützen, sichere, belastbare und auditierbare Deployments zu etablieren – von der Policy-Definition bis zum laufenden Compliance-Nachweis.

Guardrails als Leitplanken moderner Deployments

Moderne Softwarelandschaften sind hochgradig verteilt. In einem typischen Cluster laufen Hunderte bis Tausende von Pods, verwaltet über Dutzende von Namespaces und Teams. In dieser Komplexität ist es nicht mehr realistisch, jede Konfiguration manuell zu prüfen.

ArgoCD Deep Dive: GitOps-Deployments für Multi-Environment-Szenarien

Sun, 02 Nov 2025 12:00:00 +0000

TL;DR

GitOps beschreibt einen Ansatz, bei dem Git als zentrale, versionierte Quelle für den gewünschten Zustand Ihrer Infrastruktur und Anwendungen dient; ArgoCD setzt diesen Ansatz in Ihrer Kubernetes-Landschaft durch kontinuierlichen Abgleich mit den Clustern um.
ArgoCD arbeitet mit deklarativen Objekten wie Applications und ApplicationSets, ergänzt um Sync-Policies (Auto vs. Manual) und Health-Checks – so können Sie Multi-Environment-Deployments (dev/staging/prod) mit klaren Freigabeprozessen etablieren.
Für Compliance-Anforderungen aus NIS-2, DORA, GDPR und Cyber Resilience Act bietet GitOps mit ArgoCD einen vollständigen Audit-Trail, reproduzierbare Deployments und eine klare Trennung von Konfiguration und Secrets.
Rollbacks erfolgen primär über Git (Revert, Rollback-Commits); ArgoCD synchronisiert daraufhin den Clusterzustand, nutzt seine interne Historie für Inspection und unterstützt Disaster-Recovery-Szenarien durch Wiederaufbau ganzer Umgebungen nur aus Git.
ayedo verbindet ArgoCD, GitLab, Secrets-Management und Registry-Komponenten wie Harbor zu einer integrierten Delivery-Plattform und unterstützt Organisationen beim sicheren Aufbau von GitOps-Workflows – inklusive Multi-Environment-Strategie und Compliance-Architektur.

GitOps als Fundament: Was sich wirklich ändert

Git als Single Source of Truth

Im Kern bedeutet GitOps: Alles, was im Cluster laufen soll, ist als deklarativer Zustand in Git beschrieben – nicht nur Anwendungs-Manifeste, sondern idealerweise auch Plattformkomponenten, Policies und Konfiguration.

HashiCorp Vault + External Secrets Operator: Zero-Trust Secrets Management

Sat, 01 Nov 2025 12:00:00 +0000

TL;DR

Secrets in Git, klassische Kubernetes-Secrets und manuelle Verfahren reichen für Zero-Trust-Anforderungen und moderne Regulierungen nicht mehr aus.
HashiCorp Vault liefert mit Secrets Engines, Dynamic Secrets, Encryption as a Service und detaillierten Audit Logs die notwendige technische Grundlage für belastbares, revisionssicheres Secrets Management.
Der External Secrets Operator (ESO) verbindet Vault und Kubernetes: Er synchronisiert Secrets kontrolliert in Namespaces, sorgt für automatische Rotation und entkoppelt Applikationsteams von der Komplexität des Vault-Backends.
Ein durchgängiger Workflow Platform Admin → Vault → ESO → Kubernetes → App stellt sicher, dass Credentials für Systeme wie PostgreSQL nie in Git oder unverschlüsselt in Clustern landen.
ayedo unterstützt Organisationen dabei, Vault und ESO produktiv und compliant zu betreiben – von Architektur und Setup bis zur Integration in bestehende CI/CD- und Governance-Strukturen.

Warum modernes Secrets-Management ein Zero-Trust-Kernbaustein ist

Secrets Management ist nicht nur ein Security-Thema, sondern eine Grundvoraussetzung für jede ernstzunehmende Compliance-Strategie. Wer Zugangsdaten, Tokens oder Verschlüsselungs-Keys verliert, verliert im Zweifel auch die Kontrolle über Daten, Systeme und Reputation.

Harbor Deep Dive: Vulnerability-Scanning, SBOM, Image-Signing

Fri, 31 Oct 2025 12:00:00 +0000

TL;DR

Eine moderne Container Registry ist heute ein zentrales Compliance-Werkzeug – insbesondere im Kontext von Cyber Resilience Act, NIS-2 und DORA.
Harbor kombiniert Vulnerability-Scanning (Trivy), SBOM-Verwaltung (SPDX, CycloneDX) und Image-Signing (Notary, Cosign) mit Enterprise-Features wie Replication, Quotas, RBAC und Audit Logs – ideal, um Supply-Chain-Risiken strukturiert zu steuern.
Für den Cyber Resilience Act (in Kraft seit 20. Mai 2024, Anwendung der meisten Pflichten ab 2027) sind insbesondere SBOMs, koordinierte Vulnerability-Disclosure-Prozesse und signierte Artefakte relevant – alles Bereiche, in denen Harbor sehr konkret unterstützen kann.
NIS-2 (seit 16. Januar 2023 in Kraft, Umsetzung in nationales Recht bis 17. Oktober 2024) und DORA (anwendbar ab 17. Januar 2025) verlangen mehr Transparenz und Steuerung in der IKT-Lieferkette – Harbor liefert hier nachvollziehbare Artefakt-Historien, Richtlinien und Prüfbarkeit.
ayedo plant, baut und betreibt Harbor-Instanzen als Bestandteil einer integrierten Compliance-fähigen Plattform – inklusive Policy-Design, Vulnerability-Management-Workflows und sicherer Harbor Configuration.

Warum die Container Registry zur Compliance-Schlüsselkomponente wird

Container-Images sind heute das primäre Auslieferungsformat für Software. Damit wandert ein großer Teil der sicherheits- und compliance-relevanten Informationen in die Registry: Vulnerabilities, Abhängigkeiten, Lizenzen, Provenance.

Kaniko vs. Buildah: Rootless, Daemonless Container-Builds in Kubernetes

Thu, 30 Oct 2025 12:00:00 +0000

TL;DR

Klassische Container-Builds mit Docker Daemon, Root-Rechten und docker.sock im CI-System sind ein unnötiges Sicherheitsrisiko – insbesondere, wenn Builds direkt in einem Kubernetes-Cluster laufen.
Rootless, daemonless Tools wie Kaniko und Buildah erlauben sichere Image-Builds in Pods ohne privilegierte Rechte und ohne Docker Daemon – ein wichtiger Baustein für technische Guardrails und moderne Compliance-Anforderungen.
Kaniko ist der „Kubernetes-native“ Weg: deklarativ, stark auf Dockerfiles fokussiert, mit gutem Layer-Caching über die Registry; Buildah bietet mehr Flexibilität, tiefe OCI-Integration und Skriptbarkeit – eignet sich, wenn Sie komplexere Build-Workflows oder eigene Toolchains brauchen.
Für den europäischen Kontext – inklusive Cyber Resilience Act und signierten Builds – sind rootless Pipelines ein pragmatischer Weg, Security-by-Design in der Softwarelieferkette zu verankern.
ayedo setzt in der eigenen Plattform konsequent auf rootless Builds mit Kaniko und Buildah, integriert in GitLab, Harbor und GitOps-Deployment – und unterstützt Teams dabei, diese Architektur strukturiert zu übernehmen.

Warum traditionelle Container-Builds in Kubernetes zum Risiko werden

Viele Organisationen haben ihre ersten CI/CD-Pipelines mit einer simplen Annahme gebaut: „Wir installieren Docker auf dem Runner und rufen docker build auf.“ In klassischen VM-Setups war das pragmatisch. In einem Kubernetes-Cluster wird aus dieser Gewohnheit jedoch ein strukturelles Risiko.

Compliance

Thu, 30 Oct 2025 00:00:00 +0000

Einleitung

ayedo ist spezialisiert auf maßgeschneiderte Container-Lösungen und den Betrieb komplexer Anwendungen, damit geschäftskritische Software jederzeit zuverlässig läuft. Informationssicherheit und Qualität sind dabei fest in der Unternehmenskultur verankert. Wir haben ein integriertes Managementsystem (IMS) etabliert und erfolgreich zertifizieren lassen, das die Anforderungen der ISO/IEC 27001:2022 (Informationssicherheits-Management) und ISO 9001:2015 (Qualitätsmanagement) erfüllt. Sicherheit ist für uns keine Floskel, sondern ein Kernbestandteil unserer DNA. Dieses Dokument fasst die technische Infrastruktur, Sicherheitsmaßnahmen und Compliance-Aspekte unserer Plattform zusammen – mit dem Ziel, IT- und Compliance-Verantwortlichen einen umfassenden Überblick darüber zu geben, “was sie bei uns bekommen.”

Open Source in der Verwaltung: Der Government Site Builder 11 setzt Maßstäbe

Wed, 29 Oct 2025 12:23:41 +0000

Mit der Preisverleihung auf der Smart Country Convention (SCCON) am 2. Oktober 2025 hat die Open-Source-Bewegung in der öffentlichen Verwaltung einen sichtbaren Erfolg gefeiert. Beim ersten bundesweiten Open-Source-Wettbewerb für Behörden und öffentliche Institutionen, ausgerichtet von der Open Source Business Alliance (OSBA) und Partnern wie govdigital, SUSE, Capgemini und ZenDiS, wurden Projekte ausgezeichnet, die zeigen: Open Source ist längst kein Experiment mehr – sondern tragfähige Verwaltungsinfrastruktur.

Im Mittelpunkt stand der Government Site Builder 11 (GSB 11), eine gemeinsame Entwicklung des Bundesministeriums für Digitales und Staatsmodernisierung (BMDS) und des Informationstechnikzentrums Bund (ITZBund). Das Projekt gewann gleich zwei Auszeichnungen – den Preis in der Kategorie Interne Verwaltungsanwendungen und den Community-Sonderpreis.

GitLab CI/CD im Detail: Stages, Jobs, Pipelines für moderne Software

Wed, 29 Oct 2025 12:00:00 +0000

TL;DR

GitLab CI/CD ist weit mehr als ein Build-Tool: Richtig eingesetzt wird es zum zentralen Rückgrat Ihres Delivery-Prozesses – von Commit bis Produktion, inklusive Dokumentation und Audit-Trail.
Kernbausteine wie .gitlab-ci.yml, Stages, Jobs und Artifacts erlauben es, eine klare, reproduzierbare Lieferkette zu modellieren – inklusive Build (Kaniko, SBOM), Test (pytest, Integration, Trivy), Package (Push zu Harbor, Signatur), Deploy (GitOps mit ArgoCD).
Moderne Anforderungen aus Cyber Resilience Act, NIS‑2, DORA und GDPR lassen sich direkt in GitLab CI/CD verankern: SBOM-Erzeugung, CVE-Scanning, signierte Images, Audit-Trails und sauberes Secrets-Management.
Eine durchdachte Pipeline-Struktur macht Compliance zur integrierten Eigenschaft Ihrer Software-Lieferkette – statt zu einem nachgelagerten Kontrollmechanismus.
ayedo unterstützt Sie dabei, GitLab CI/CD, Harbor, ArgoCD und Ihr Kubernetes-Ökosystem so zu orchestrieren, dass Delivery-Geschwindigkeit, Sicherheit und Compliance gleichermaßen gewinnen.

GitLab CI/CD als Rückgrat Ihres Delivery-Prozesses

Wer heute Software verantwortet, verwaltet nicht nur Quellcode, sondern komplette Lieferketten: Quellcodeverwaltung, Build-Prozesse, Container-Images, Policy-Checks, Deployments, Audits. GitLab CI/CD bündelt diese Fäden an einem Ort.

Von KI-Browsern, Cybersecurity und Compliance

Tue, 28 Oct 2025 12:33:37 +0000

Die Einführung von KI-Browsern wie OpenAI’s ChatGPT Atlas und Perplexity Comet markiert den Beginn einer neuen Ära der Mensch-Computer-Interaktion. Diese Tools versprechen nicht nur das Surfen, sondern die gesamte Online-Aufgabenerfüllung neu zu definieren – durch die Fähigkeit, das Web zu verstehen und autonome Aktionen auszuführen. Doch gerade diese bahnbrechenden Fähigkeiten stellen unsere bestehenden Sicherheitsarchitekturen vor fundamentale Herausforderungen. Für uns in der IT-Branche sind diese neuen “Agenten im Browser” keine bloßen Features, sondern kritische, neuartige Angriffsvektoren.

Let's Deploy with ayedo, Teil 2: ArgoCD GitOps, Monitoring, Observability

Tue, 28 Oct 2025 12:00:00 +0000

TL;DR

GitOps mit ArgoCD verankert den gewünschten Zustand Ihrer Anwendungen und Infrastruktur in Git und macht Deployments damit reproduzierbar, auditierbar und automatisierbar.
Im gemeinsamen Workflow von GitLab, Harbor, ArgoCD und Kubernetes übernehmen Pipelines das Bauen, Testen und Signieren, während ArgoCD die kontrollierte Auslieferung in verschiedene Umgebungen steuert.
ArgoCD ApplicationSets erlauben skalierbares Multi-Environment-Deployment nach einheitlichen Standards – mit klaren Guardrails, wählbarem Automatisierungsgrad und sauberen Rollbacks.
Monitoring & Observability mit VictoriaMetrics (Metriken), VictoriaLogs (Logs) und Grafana liefern die technische Grundlage, um Compliance-Anforderungen an Verfügbarkeit, Nachvollziehbarkeit und Incident-Handling belastbar zu erfüllen.
ayedo integriert diesen gesamten GitOps- und Observability-Stack zu einer konsistenten Plattform, die Deployment-Automatisierung mit Compliance-Guardrails verbindet – inklusive einsatzfertiger ArgoCD-Templates und Dashboards.

GitOps mit ArgoCD: Steuerzentrale für den Plattform-Zustand

Was GitOps in der Praxis bedeutet

GitOps ist kein weiteres Modewort, sondern ein strukturierender Ansatz:
Der gewünschte Systemzustand – Deployments, Konfiguration, Policies – liegt versioniert in Git. Automatisierte Controller gleichen fortlaufend ab, ob der tatsächliche Zustand im Cluster diesem Zielbild entspricht, und korrigieren Abweichungen.

Let's Deploy with ayedo, Teil 1: GitLab CI/CD, Harbor Registry, Vault Secrets

Mon, 27 Oct 2025 12:00:00 +0000

TL;DR

GitLab CI/CD wird zum zentralen Orchestrator Ihres Delivery-Workflows: klar strukturierte Stages (build, test, package, deploy) machen Ihre Artefaktkette nachvollziehbar und prüfbar.
Rootless, daemonlose Container-Builds mit Kaniko oder Buildah ermöglichen sichere Pipelines ohne privilegierte Docker-Daemons – inklusive SBOM-Generierung als Grundlage für Auditierbarkeit und kommenden Vorgaben aus NIS2 und Cyber Resilience Act (in Kraft seit dem 09.01.2024).
Eine zentrale Registry wie Harbor wird vom simplen Image-Speicher zum Compliance-Drehkreuz: automatisches CVE-Scanning, Image-Signing und durchgesetzte Vulnerability-Policies erhöhen Ihre Supply-Chain-Sicherheit messbar.
Mit HashiCorp Vault und dem External Secrets Operator automatisieren Sie das Secrets-Management von der Pipeline bis zum /kubernetes/-Cluster – inklusive dynamischer Credentials und Rotation, ohne Secrets in GitLab-Variablen zu „verstecken“.
ayedo liefert eine integrierte Plattform mit GitLab, Harbor, HashiCorp Vault und ESO sowie praxiserprobte GitLab CI/CD-Templates, die genau diesen Workflow für Sie vorstrukturieren.

GitLab CI/CD als Rückgrat des Deployment-Workflows

Für moderne, regulierungskonforme Softwarelieferung ist eine saubere CI/CD-Pipeline nicht „nice to have“, sondern das technische Organigramm Ihrer Organisation. In vielen Unternehmen übernimmt GitLab diese Rolle – in der ayedo Plattform ist es der erste Schritt im End-to-End-Workflow.

Microsoft Teams: Wenn die Bürosoftware zur Anwesenheitskontrolle wird

Mon, 27 Oct 2025 10:48:02 +0000

Microsoft wird seine Kollaborationsplattform Teams ab Dezember 2025 um eine Funktion erweitern, die den tatsächlichen Arbeitsort von Mitarbeitenden automatisch erkennt. Die Software soll feststellen, ob ein Nutzer mit dem WLAN des Unternehmens verbunden ist – und daraus ableiten, ob er sich physisch im Büro befindet.

Offiziell soll das Feature die hybride Zusammenarbeit erleichtern. In großen Bürokomplexen oder bei verteilten Teams könne so sichtbar werden, wer vor Ort und wer im Homeoffice arbeitet. Doch die technische Grundlage – die Erfassung von Standortdaten über das Firmennetzwerk – weckt Bedenken.

ohMyHelm: Helm Charts für 15-Factor Apps ohne Kubernetes-Komplexität

Sun, 26 Oct 2025 12:00:00 +0000

TL;DR

ohMyHelm ist ein universeller Helm-Chart-Wrapper, der produktionsreife Workloads bereitstellt, ohne dass Teams eigene Templates pflegen müssen – die gesamte Definition erfolgt über eine zentrale values.yaml.
Standardkomponenten wie Deployments/StatefulSets, Ingress, RBAC, ConfigMaps, Secrets (inklusive External Secrets Operator) und Observability-Hooks sind integriert und nach Best Practices vorkonfiguriert.
Die 15-Factor-Prinzipien (Konfiguration, Backing Services, Logs, Telemetrie, Parity) lassen sich mit ohMyHelm konsistent in Helm-Modellen abbilden – ideal für standardisierte Cloud-Native-Architekturen auf /kubernetes/.
Guardrails wie Resource Limits, Network Policies, Security Contexts und standardisierte Service-Abhängigkeiten machen es leichter, regulatorische Anforderungen und interne /compliance/-Richtlinien durchzusetzen.
ayedo nutzt ohMyHelm selbst als Baustein einer souveränen, policy-konformen Plattform und unterstützt Teams dabei, ihre Anwendungen ohne Kubernetes-Overhead in eine sichere, auditierbare Betriebsumgebung zu überführen.

Warum Helm-Charts oft mehr Komplexität als Nutzen bringen

Helm hat sich als De-facto-Standard für das Packaging von Anwendungen auf /kubernetes/ etabliert. In der Praxis sehen viele Teams jedoch zwei gegensätzliche Realitäten:

Delivery Operations: Der Weg von Code zu Production

Sat, 25 Oct 2025 12:00:00 +0000

TL;DR

Delivery Operations beschreiben den Weg von Code in Ihrer Versionsverwaltung bis zu laufenden Workloads in Production – inklusive Build, Test, Packaging, Security-Scans, Deployment und Monitoring.
Im Gegensatz zu Platform Operations (Cluster, Netzwerk, Basisdienste) kümmern sich Delivery Operations um reproduzierbare, nachvollziehbare und automatisierte Abläufe, die technische Qualität und regulatorische Anforderungen gleichermaßen adressieren.
Ein sauber gestalteter End-to-End-Workflow – Code → CI → Package → Scan → Deploy → Monitor – ist der effektivste Hebel, um Vorgaben aus Cyber Resilience Act, NIS‑2, DORA und Data Act pragmatisch umzusetzen.
Zentrale Compliance-Bausteine sind SBOMs, CVE-Scanning, signierte Artefakte, ein belastbarer Audit-Trail und Exit-Fähigkeit Ihrer Plattform – alles eingebettet in schlanke Developer-Experience.
ayedo stellt mit der Software Delivery Plattform eine integrierte Umgebung bereit, in der Delivery Operations, Compliance und moderne Cloud-Native-Technik zusammengeführt werden – inklusive vorkonfigurierter Workflows, Guardrails und einer konsistenten Delivery Workflow Demo.

Delivery Operations als Gegenstück zu Platform Operations

Wenn wir über moderne Cloud-Native-Umgebungen sprechen, fallen häufig Begriffe wie Kubernetes, Observability oder Infrastructure as Code. Das sind klassische Themen der Platform Operations: Aufbau und Betrieb der technischen Basis – also Cluster, Netzwerk, Storage, Logging, Identity und die zugrunde liegende Plattform.

Velero: Backup & Disaster Recovery für DORA und NIS-2

Fri, 24 Oct 2025 12:00:00 +0000

TL;DR

Velero ist ein ausgereiftes Open-Source-Werkzeug für Backups, Migrationsszenarien und Disaster Recovery in Kubernetes-Umgebungen – und damit ein zentraler Baustein für jede belastbare Compliance-Architektur.
Regulatorische Vorgaben wie GDPR (seit dem 25.05.2018 anwendbar), NIS‑2 (Umsetzung bis zum 17.10.2024) und DORA (gilt ab dem 17.01.2025) verlangen explizit robuste Business-Continuity- und Wiederherstellungskonzepte – nicht nur Backups „irgendwo im S3-Bucket“.
Eine stimmige Backup-Strategie umfasst automatisierte, richtlinienbasierte Backups, geografisch getrenkte und verschlüsselte Speicherung, klare RPO/RTO-Ziele sowie regelmäßig geübte Restore- und Disaster-Recovery-Prozesse.
Velero wird in kritischen Szenarien – vom Verlust eines Namespaces bis hin zum kompletten Cluster-Ausfall – zum operativen Herzstück des DR-Prozesses und verbindet technische Wiederherstellung mit regulatorisch sauberer Dokumentation.
ayedo liefert eine integrierte Lösung: Die ayedo Kubernetes Distribution bringt Velero, Offsite-Storage, Monitoring und standardisierte DR-Prozesse als Bausteine mit – inklusive Beratung zur Ausrichtung an GDPR, NIS‑2 und DORA.

Velero im Überblick: Backup- und Migrations-Engine für Kubernetes

In produktiven Kubernetes-Landschaften ist ein robustes Backup- und Disaster-Recovery-Konzept keine Kür mehr, sondern eine regulatorische Pflicht. Velero hat sich hier als De-facto-Standard etabliert.

Kyverno: Policy as Code für automatisierte Compliance-Prüfung

Thu, 23 Oct 2025 12:00:00 +0000

TL;DR

Kyverno ist eine Kubernetes-native Policy Engine, mit der Sie Sicherheits- und Betriebsrichtlinien direkt als YAML definieren und automatisiert als Admission-Controller im Cluster durchsetzen können.
Mit klar strukturierten Guardrails für Security (z. B. Container-Isolation, vertrauenswürdige Registries), Reliability (z. B. Ressourcen-Management) und Operation (z. B. Storage-, LoadBalancer- und Backup-Regeln) wird Compliance zu einem wiederholbaren, überprüfbaren Prozess.
Regulatorische Anforderungen aus GDPR Art. 32 (seit dem 25.05.2018 anwendbar), der NIS‑2-Richtlinie (mit Umsetzungsfrist der EU-Mitgliedstaaten bis zum 17.10.2024) und dem BSI IT-Grundschutz lassen sich mit Policy as Code systematisch in Ihrem Kubernetes-Cluster abbilden.
Praxisnah umgesetzt bedeutet das: Deployments werden schon beim Einspielen gegen Policies geprüft; fehlerhafte Konfigurationen werden mit klaren, technischen Hinweisen abgewiesen – bevor sie zum Risiko in Produktion werden.
ayedo nutzt Kyverno als zentrales Policy-as-Code-Werkzeug, liefert vordefinierte Guardrails und Reporting-Funktionen und unterstützt Sie dabei, Kyverno Policies als festen Bestandteil Ihrer Delivery- und Compliance-Strategie zu etablieren.

Kyverno im Überblick: Policy as Code, wo es hingehört

Kyverno ist eine Policy Engine, die speziell für Kubernetes entwickelt wurde. Anders als generische Policy-Frameworks setzt Kyverno vollständig auf Kubernetes-Objekte und YAML. Das passt gut in eine Welt, in der Infrastruktur, Applikationen und Security-Konfigurationen bereits als Code beschrieben werden.

Weekly Backlog KW 44/2025

Thu, 23 Oct 2025 11:03:00 +0000

Editorial

Deutschland, deine Server. In derselben Woche, in der eine kleine Gemeinde in Baden-Württemberg digital kollabiert und das Bundes-Login-System offline geht, diskutiert Europa über „digitale Souveränität" – während Microsoft gleichzeitig lernt, wer im Büro ist und wer nur vorgibt, dort zu sein.

Man könnte sagen: Willkommen in der paradoxen Republik. Zwischen Sicherheitslücke und Surveillance-Feature, zwischen Faxgerät und Cloud-Monopol. Diese Woche zeigt einmal mehr: Digitalisierung ist kein IT-Projekt. Es ist eine Machtfrage.

Keycloak: Identity & Access Management für GDPR und NIS-2

Wed, 22 Oct 2025 12:00:00 +0000

TL;DR

Keycloak ist ein ausgereiftes Open-Source-Identity-&-Access-Management (IAM), das moderne Protokolle wie OAuth2, OpenID Connect (OIDC) und SAML 2.0 unterstützt und sich gut in Cloud-native Architekturen integrieren lässt.
Für GDPR/DSGVO (insbesondere Art. 32), NIS-2 und DORA bietet Keycloak zentrale Bausteine: starke Authentifizierung (MFA), granulare Rollen- und Rechteverwaltung (RBAC) sowie detaillierte Audit-Logs.
In der Praxis eignet sich Keycloak als zentraler Identity Provider für die Kubernetes-API, für einheitliche MFA-Richtlinien und für durchgängige Rollenkonzepte über Infrastruktur- und Anwendungsebene hinweg.
Durch die Integration in eine zentrale Plattform wie die ayedo SDP wird Keycloak zur strategischen IAM-Komponente Ihrer Compliance-Architektur – mit standardisierten Betriebsprozessen, hoher Verfügbarkeit und sauber dokumentierten Zugriffswegen.
ayedo unterstützt bei Architektur, Einführung und Betrieb von Keycloak, integriert das IAM in Ihre Plattform- und Security-Landschaft und hilft, regulatorische Vorgaben pragmatisch umzusetzen – von der ersten Bestandsaufnahme bis zur produktiven Keycloak Integration.

Warum Identity & Access Management der Kern moderner Compliance ist

Wer heute Verantwortung für eine digitale Organisation trägt, weiß: Die großen europäischen Regulierungswerke – GDPR/DSGVO, NIS-2, DORA – zielen nicht auf einzelne Tools, sondern auf strukturiertes Sicherheits- und Risikomanagement. Zugang zu Systemen und Daten steht dabei im Zentrum.

VictoriaMetrics & VictoriaLogs: Observability für NIS-2 und DORA

Tue, 21 Oct 2025 12:00:00 +0000

TL;DR

Moderne Compliance-Anforderungen wie NIS-2, DORA und GDPR verlangen eine belastbare, nachweisbare Observability: Metriken, Logs und Traces müssen systematisch erfasst, ausgewertet und langfristig aufbewahrt werden.
VictoriaMetrics bietet eine hochperformante, Prometheus-kompatible Metrik-Plattform mit effizienter Langzeit-Retention – ideal, um SLOs, Kapazitäten und Incidents regulatorisch sauber abzubilden.
VictoriaLogs ergänzt dies um strukturierte, performante und manipulationsresistente Log-Verwaltung und ermöglicht so Audit-Trails, forensische Analysen und revisionssichere Nachweise.
In Kombination mit Grafana und einem Tracing-Backend entsteht ein vollständiger Observability-Stack, der proaktives Monitoring, schnelles Incident Handling und belastbare Berichte für NIS-2, DORA und GDPR unterstützt.
ayedo konzipiert, implementiert und betreibt solche Observability-Stacks auf Basis von VictoriaMetrics, VictoriaLogs und Grafana – technisch tief, regulierungsbewusst und mit klarem Fokus auf Ihre Compliance-Anforderungen.

Cloud-native Architekturen bringen enorme Flexibilität – und eine drastisch gestiegene Komplexität. Container, Microservices, Infrastructure as Code und dynamische Orchestrierung mit Kubernetes machen klassische, manuelle Sicherheitsprüfungen faktisch unmöglich.

Weekly Backlog 43/2025

Thu, 16 Oct 2025 08:15:45 +0000

„Wenn Ausschreibungen ein Timeout haben und AWS Schluckauf bekommt"

Editorial

Diese Woche zeigte, wie eng die moderne Welt vernetzt ist. Technisch, wirtschaftlich und politisch. Ein DDoS auf das Vergabeportal des Bundes stoppt öffentliche Ausschreibungen, ein Angriff auf F5 öffnet das Fenster in den Maschinenraum globaler Netzsicherheit und AWS demonstriert erneut, dass „Multi-AZ" kein Backup-Plan ist.

Außerdem: Das Saarland verliert sein digitales Aushängeschild an München.

Die Tech-News der Woche

DDoS legt Vergabeportal des Bundes lahm

Mehrere Tage lang war das zentrale Vergabeportal des Bundes - das Herzstück für öffentliche Ausschreibungen - nicht erreichbar. Ursache: ein großangelegter DDoS-Angriff der prorussischen Hackergruppe Noname057(16), die seit Jahren koordinierte Überlastungsangriffe auf europäische Behörden, Banken und Medien fährt.

Software-Logistik standardisiert: OCI, Helm, Kubernetes API

Wed, 15 Oct 2025 12:00:00 +0000

TL;DR

Die Cloud-Native-Community hat mit OCI, Helm und der Kubernetes-API eine durchgängige „Software-Logistik“ geschaffen: standardisiert, interoperabel und von einzelnen Anbietern weitgehend entkoppelt.
Für Software-Anbieter bedeutet das: Einmal sauber paketieren, dann auf jeder CNCF-kompatiblen Plattform ausliefern – von Hyperscaler-Kubernetes bis zur souveränen Private Cloud.
Für Software-Einkäufer entstehen handfeste Vorteile: bessere Verhandlungsposition gegenüber Providern, echte Portabilität, sowie standardisierte Prüfpfade für Security, SBOM und regulatorische Compliance.
Regulierung wie Data Act, Cyber Resilience Act und das europäische Cloud Sovereignty Framework werden durch diese Standards nicht nur erfüllbar, sondern strategisch nutzbar – als Hebel für Governance und Qualität.
ayedo baut auf genau diesen Standards auf: standardisierte Container-Registries, Helm-basierte Plattform-Bausteine und Kubernetes-native Compliance-Automatisierung – von der Chart-Qualität bis zur dokumentierten, revisionssicheren Auslieferung.

Die Evolution der Software-Logistik: Von Installern zu Standards

Software-Distribution war lange ein Flickenteppich: individuelle Installer, proprietäre Update-Mechanismen, manuelle Konfigurationen. Jede Umgebung war anders, jeder Wechsel des Betriebsmodells ein Mini-Migrationsprojekt.

Das Trojanische Pferd der „sovereign cloud“

Tue, 14 Oct 2025 19:13:15 +0000

Das trojanische Pferd der „Sovereign Cloud"

Warum Europas neue Souveränität oft nur amerikanisch lackiert ist

Das Meme ist genial in seiner Schlichtheit:

Ein trojanisches Pferd rollt vor die Tore Europas.

Darauf steht: „Sovereign Cloud".

Im Bauch sitzen: AWS, Microsoft, Google – fröhlich lächelnd.

Und an den Toren der Stadt stehen zwei europäische Männer, die das Seil ziehen und sagen: „Lasst uns das mal reinholen – sieht ja sicher aus."

Open Source ≠ Souveränität. Über Abhängigkeit und Verantwortung in einer cloud-nativen Welt

Tue, 14 Oct 2025 19:01:55 +0000

Viele verwechseln Open Source mit Souveränität. Beides gehört zusammen – aber das eine garantiert nicht automatisch das andere.

Das bekannte XKCD-Meme, das eine riesige, wackelige digitale Infrastruktur zeigt, die auf einem winzigen Software-Baustein ruht, den „irgendeine Person in Nebraska seit 2003 still pflegt", ist mehr als eine humorvolle Karikatur. Es ist eine präzise Zustandsbeschreibung unserer digitalen Gegenwart – und eine Mahnung an alle, die glauben, dass Open Source automatisch Sicherheit, Kontrolle oder gar Unabhängigkeit bedeutet.

Weekly Backlog KW 42/2025

Tue, 14 Oct 2025 14:31:04 +0000

Editorial

Diese Woche war ein einziger Fiebertraum. Von Localmind bis Aleph Alpha, von SonicWall bis GitHub – überall das gleiche Muster: große Versprechen, dünne Architektur, und ein tiefes Missverständnis davon, was Kontrolle wirklich bedeutet. Wenn wir weiter glauben, Sicherheit entstehe durch Marketing, und wenn US-Firmen weiter glauben, Vertrauen sei ein Abo-Modell - dann wird 2025 ein Jahr der Entzauberung.

Die Tech-News der Woche

Localmind – Wie man Vertrauen in europäische KI verspielt

Heise berichtet über einen Vorfall, der so absurd ist, dass man ihn fast für Satire halten könnte: Die österreichische Firma Localmind, die sich als „sichere KI-Plattform" verkauft, hat ihre komplette Infrastruktur offengelegt - nicht durch einen Angriff, sondern durch Unfähigkeit.

Cloud Sovereignty + 15 Factor App: Die architektonische Brücke zwischen Recht und Technik

Tue, 14 Oct 2025 12:00:00 +0000

TL;DR

Das Cloud Sovereignty Framework der EU definiert, was digitale Souveränität erreichen soll – die 15-Factor-App-Prinzipien definieren, wie eine konkrete Anwendungsarchitektur diese Ziele technisch umsetzt.
SOV‑3 (Data & AI) wird operativ greifbar, wenn Konfiguration (inklusive Verschlüsselungskeys) komplett aus dem Code herausgelöst und als BYOK-Setup in standardisierten Umgebungen verwaltet wird – ganz im Sinne von Factor 3 „Config“.
SOV‑4 (Operational), SOV‑6 (Technology) und SOV‑7 (Security) lassen sich direkt auf moderne Architekturprinzipien mappen: Backing Services, API-First, Open Source, Telemetry und durchgängige Authentifizierung machen Portabilität, Exit-Fähigkeit und Auditierbarkeit zur eingebauten Eigenschaft.
Eine 15-Factor-konforme Anwendung kann zwischen Cloud-Providern migriert werden, ohne dass der Anwendungscode verändert werden muss – Konfiguration, APIs und Infrastruktur-Abstraktionen tragen die Last der Migration. Das entspricht exakt der Exit-Fähigkeit, die das Cloud Sovereignty Framework fordert.
ayedo kombiniert eine souveräne Infrastruktur nach Cloud Sovereignty Framework mit 15-Factor-basierter Anwendungs-Paketierung. Mit unserem Portability Assessment machen wir sichtbar, wie portabel Ihre Anwendungen heute sind – und wie Sie regulatorische Anforderungen architektonisch sauber erfüllen können.

Warum Cloud Souveränität eine Architekturfrage ist

Regulatorische Anforderungen sind längst kein reines Legal-Thema mehr. Spätestens seit die EU-Kommission mit Version 1.2.1 des Cloud Sovereignty Frameworks im Oktober 2025 einen konkreten Bewertungsrahmen veröffentlicht hat, ist klar: Wer souveräne Cloud-Dienste beschaffen oder anbieten will, braucht nachvollziehbare technische Antworten.

Der Deutschland-Stack

Tue, 14 Oct 2025 07:13:04 +0000

Der Deutschland-Stack und die Realität moderner Cloud-Native Entwicklung:

Digitalisierung ist kein Schlagwort mehr – sie ist Fundament, Wettbewerbsvorteil und geopolitischer Faktor zugleich. Europa hat das verstanden. Und mit dem Deutschland-Stack, einer vom Bundesministerium für Digitales und Staatsmodernisierung initiierten Referenzarchitektur, entsteht erstmals ein offener, validierter und interoperabler Technologie-Stack für Softwareentwicklung in Verwaltung und Wirtschaft.

Das Ziel: Eine einheitliche, sichere und souveräne IT-Grundlage für moderne Anwendungen – frei von proprietären Abhängigkeiten, auf offenen Standards basierend und durchgehend cloud-kompatibel.

Der moderne Software Development Lifecycle: Von Cloud-Native zu Compliance

Mon, 13 Oct 2025 12:00:00 +0000

TL;DR

Der moderne Software Development Lifecycle (SDLC) basiert auf Cloud-native Architekturen, automatisierten Pipelines und einer klaren Trennung von Zuständigkeiten zwischen Plattform- und Produktteams.
Mehrere Releases pro Tag sind nur dann tragfähig, wenn Portabilität, Ausfallsicherheit und standardisierte Logistik von Anfang an in der Architektur angelegt sind – idealerweise nach Prinzipien wie der 15-Factor App.
Ein gut gestalteter SDLC schafft nicht nur Geschwindigkeit, sondern vor allem Planbarkeit, messbare Qualität und eine deterministische Grundlage für Sicherheits- und Compliance-Prüfungen.
Platform Operations und Delivery Operations bilden zwei Seiten derselben Medaille: Die eine Seite stellt eine robuste, compliant-fähige Plattform bereit, die andere Seite nutzt diese Plattform für wiederholbare, auditierbare Softwarelieferung.
ayedo bietet mit der Plattform und darauf abgestimmten Lösungen für GitOps, CI/CD und Compliance einen Rahmen, in dem Organisationen moderne SDLC-Praktiken sicher, strukturiert und regulatorisch belastbar etablieren können.

Vom klassischen Projekt zur kontinuierlichen Produktentwicklung

Viele Organisationen sind inzwischen weit von der klassischen „Projekt-IT“ entfernt. Statt großer, seltener Releases bewegen wir uns hin zu kontinuierlicher Produktentwicklung: Features werden in kleinen Inkrementen entwickelt, getestet und ausgeliefert – oft mehrmals täglich.

15 Factor App Deep Dive: Faktoren 13–15 (API First, Telemetry, Auth)

Sun, 12 Oct 2025 12:00:00 +0000

TL;DR

Die Erweiterung der klassischen 12-Factor-App um die Faktoren 13–15 (API First, Telemetry, Auth) ist kein „Nice-to-have“, sondern Voraussetzung für belastbare, skalierbare und regulierungskonforme Cloud-Native-Anwendungen.
API First mit OpenAPI/Swagger und Contract-First-Entwicklung ermöglicht parallele Teamarbeit, bessere Interoperabilität und schafft eine solide Basis für Anforderungen aus dem Data Act.
Telemetry mit Metriken, Traces und Events hebt Sie von reaktiver Fehlerbehebung auf ein proaktives Observability-Niveau – und adressiert direkt die Monitoring- und Reporting-Erwartungen aus NIS-2 und DORA.
Moderne Authentifizierung und Autorisierung (OAuth2, OIDC, Zero-Trust-Modelle) sind Kernbausteine, um Sicherheitsanforderungen aus der GDPR (insbesondere Art. 32) und NIS-2 technisch sauber zu erfüllen.
ayedo verankert die 15-Factor-Prinzipien – inklusive API First, Telemetry und Auth – in einer souveränen, europäischen Delivery-Plattform, sodass Engineering-Teams Cloud-Native-Architekturen und Compliance-Anforderungen gemeinsam denken und umsetzen können.

Von 12 zu 15 Faktoren: Warum die Erweiterung entscheidend ist

Die klassische 12-Factor-Lehre hat einen Standard für moderne Webanwendungen gesetzt. Doch viele dieser Prinzipien entstanden zu einer Zeit, in der APIs, Observability und Zero-Trust noch nicht den heutigen Stellenwert hatten.

15 Factor App Deep Dive: Faktoren 7–12 (Networking, Skalierung, Operations)

Sat, 11 Oct 2025 12:00:00 +0000

TL;DR

Die Faktoren 7–12 der 15-Factor-App adressieren vor allem Betrieb, Skalierung und Wartbarkeit – genau dort, wo moderne Container-Plattformen wie Kubernetes ihre Stärken ausspielen.
Port Binding, Concurrency und Disposability sorgen dafür, dass Anwendungen sauber gekapselt, horizontal skalierbar und jederzeit ersetzbar sind – die Grundlage für stabile Deployments und belastbare Business-Continuity-Konzepte.
Dev/Prod Parity, Logs als Event-Streams und Admin Processes als One-Off-Prozesse machen den Betrieb vorhersehbar, auditierbar und automatisierbar – ein wichtiger Beitrag zu strukturierten Compliance-Programmen.
Kubernetes-Mechanismen wie Deployments, Horizontal Pod Autoscaling, Liveness/Readiness Probes und zentrale Logpipelines (z. B. mit Loki) sind direkte technische Hebel zur Umsetzung dieser Faktoren.
ayedo übersetzt die 15-Factor-Prinzipien mit ohMyHelm, Polycrate und der ayedo Platform in anwendbare Best Practices für Ihr Team – von standardisierten Deployments bis zu Kubernetes-Governance und Compliance-by-Design.

Warum Faktoren 7–12 für Betriebsteams entscheidend sind

Faktoren 1–6 der 15-Factor-App legen das Fundament: Codebasis, Konfiguration, Abhängigkeiten und Statelessness. Ab Faktor 7 verschiebt sich der Fokus klar in Richtung Operations: Wie wird eine Anwendung im Cluster exponiert, skaliert, überwacht und betrieben?

15 Factor App Deep Dive: Faktoren 1–6 (Grundlagen & Lifecycle)

Fri, 10 Oct 2025 12:00:00 +0000

TL;DR

Die Faktoren 1–6 der 15-Factor App definieren den inneren Lebenszyklus einer Anwendung: von der Codebasis über Dependencies und Konfiguration bis hin zu Prozessen und Laufzeitverhalten.
Eine einzige Codebasis mit klar deklarierten Dependencies und externer Konfiguration reduziert Betriebsrisiken, erleichtert Audits und schafft die Grundlage für belastbare, portable Deployments.
Backing Services als austauschbare Ressourcen und strikt getrennte Build-/Release-/Run-Phasen sind zentrale Hebel für Resilienz, Portabilität und regulatorisch nachvollziehbare Änderungen.
Stateless Prozesse unterstützen Hochverfügbarkeit und Disaster-Recovery – ein wichtiger Baustein für organisationsweite Compliance und Anforderungen an Resilience.
Mit ohMyHelm als Paketierungswerkzeug der ayedo-Plattform lassen sich diese Faktoren systematisch in Helm-Charts und values.yaml-Dateien übersetzen – inklusive sauberer Trennung von Code, Konfiguration und Umgebung (ohne proprietäre Abhängigkeiten).

Warum die ersten sechs Faktoren den Unterschied machen

Die 15-Factor App erweitert die bekannten 12-Factor-Prinzipien um moderne Anforderungen wie Telemetrie und Security. In der Praxis entscheiden aber vor allem die Faktoren 1–6 darüber, ob eine Anwendung sich zuverlässig auf einer modernen Plattform betreiben lässt – und ob sie mittel- und langfristig mit Ihren Compliance- und Souveränitätszielen Schritt hält.

GitHub zieht vollständig in die Azure Cloud – Infrastruktur geht vor Innovation

Fri, 10 Oct 2025 09:45:37 +0000

GitHub wird innerhalb der nächsten 24 Monate seine gesamte Infrastruktur auf Microsoft Azure migrieren. Das geht aus internen Dokumenten hervor, über die The New Stack berichtet. Mit dieser Entscheidung beendet GitHub den Betrieb eigener Rechenzentren zugunsten der Microsoft-Cloud – trotz technischer Risiken und auf Kosten neuer Produktfunktionen.

Migration statt Weiterentwicklung

Laut GitHub-CTO Vladimir Fedorov ist der Schritt notwendig, um der steigenden Nachfrage durch KI-Funktionen wie Copilot gerecht zu werden. Die bestehende Infrastruktur, insbesondere das zentrale Rechenzentrum in Virginia, sei an der Kapazitätsgrenze. Die vollständige Migration soll in 12 Monaten abgeschlossen sein, mit sechs Monaten Puffer für parallelen Betrieb.

SonicWall-Datenleck: Ein Systemfehler in der Sicherheitsarchitektur

Fri, 10 Oct 2025 08:45:08 +0000

Was zunächst wie ein überschaubarer Zwischenfall wirkte, ist nun offiziell ein vollständiger Kontrollverlust: Der Firewall-Hersteller SonicWall hat bestätigt, dass alle Cloud-Backups sämtlicher Firewalls kompromittiert wurden – entgegen der ursprünglichen Aussage, es seien nur rund fünf Prozent betroffen. Damit betrifft der Vorfall sämtliche Kunden, die die optionale Cloud-Sicherungsfunktion für ihre Firewall-Konfigurationen aktiviert hatten.

Die Brisanz liegt nicht nur im Umfang des Leaks, sondern in der Art der betroffenen Daten: Bei den entwendeten Backups handelt es sich um vollständige Konfigurationsdateien produktiver Netzwerksicherheitslösungen – darunter Routing-Informationen, VPN-Tunnel, Portfreigaben, Authentifizierungsmechanismen, Regeln und gegebenenfalls gespeicherte Zugangsinformationen.

15 Factor App: Die Evolution der Cloud-Native Best Practices

Thu, 09 Oct 2025 12:00:00 +0000

TL;DR

Die 12-Factor App von Heroku hat 2011 einen klaren Standard für Cloud-taugliche Anwendungen gesetzt – die 15-Factor App erweitert dieses Fundament um drei Faktoren, die in einer Welt von Microservices, Zero-Trust und Observability unverzichtbar geworden sind.
API First, Telemetry sowie Authentication & Authorization ergänzen die bestehenden zwölf Faktoren nahtlos: Sie adressieren nicht neue „Moden“, sondern konsequent weitergedachte Anforderungen an Schnittstellen-Design, Betriebsbeobachtbarkeit und Sicherheit.
Für verteilte Systeme und Microservice-Architekturen bilden alle 15 Faktoren gemeinsam einen praxisnahen Referenzrahmen: von sauberem Config-Handling über horizontale Skalierung bis zu durchgängigen Sicherheits- und Observability-Konzepten.
Mit ohMyHelm lassen sich Anwendungen so paketieren, dass diese 15 Prinzipien im Alltag tatsächlich gelebt werden: ein Chart, mehrere Umgebungen, integrierte Telemetrie und Security-by-Design – eingebettet in die ayedo Plattform auf Kubernetes.
ayedo versteht die 15-Factor App als Blaupause für souveräne, compliant betriebene Cloud-Native-Anwendungen in Europa und unterstützt Sie dabei, diese Prinzipien mit realistischen Prozessen und Werkzeugen in Ihrer Organisation zu verankern.

Von 12 zu 15 Faktoren: Evolution statt Bruch

Die 12-Factor App, 2011 von Heroku formuliert, hat eine ganze Generation von Cloud- und SaaS-Anwendungen geprägt. Sie hat viele Praktiken, die heute selbstverständlich wirken – etwa die Trennung von Konfiguration und Code oder den Verzicht auf lokalen State – früh und klar formuliert.

Der Fall Localmind: Was passiert, wenn Sicherheitsversprechen nicht eingelöst werden

Thu, 09 Oct 2025 08:43:04 +0000

Der Fall Localmind: Was passiert, wenn Sicherheitsversprechen nicht eingelöst werden

Die Selbstbeschreibung war vielversprechend: „Lokale & sichere KI-Plattform für Unternehmen", „volle Kontrolle", „Unabhängigkeit von der Cloud". Die Realität: Admin-Zugriff mit trivialem Passwort, ungesicherte Testsysteme, Klartext-Zugangsdaten in der internen Wissensdatenbank und potenzieller Zugriff auf Systeme von über 150 Unternehmen – darunter Banken, Behörden, Energieversorger und Organisationen der öffentlichen Hand in Deutschland und Österreich.

Was der österreichische Anbieter Localmind als „Beta-Testinstanz" bezeichnet, entpuppte sich in der Praxis als Einfallstor mit nahezu unbeschränktem Zugriff auf Infrastruktur und Kundendaten. Laut Heise gelang es einem anonymen Sicherheitsforscher, über ein offen zugängliches Testsystem mit sofortigen Admin-Rechten in interne Strukturen vorzudringen – ohne Exploit, ohne Angriff, sondern mit banalen Mitteln. Der Zugang zur internen Wissensdatenbank öffnete die Tür zu weiteren Systemen, inklusive Root-Zugangsdaten im Klartext. Manche Passwörter lauteten angeblich schlicht „whatTheHell123$$$".

Wie die EU-Regulierungen zusammenhängen: Ein integrierter Compliance-Ansatz

Wed, 08 Oct 2025 12:00:00 +0000

TL;DR

Die europäische Regulierungslandschaft ist bewusst verzahnt: Die GDPR bildet das Fundament, darauf bauen NIS‑2, DORA, Cyber Resilience Act und Data Act auf – ergänzt durch das Cloud Sovereignty Framework als Beschaffungsleitlinie.
Ein integrierter Ansatz reduziert den Aufwand erheblich: Ein solides ISMS nach ISO 27001, gelebte GDPR-Konformität und cloud-native Prinzipien decken große Teile der Anforderungen aller genannten Regulierungen gleichzeitig ab.
NIS‑2 (ab Oktober 2024) und DORA (ab Januar 2025) fokussieren Cyber-Resilienz und operatives Risikomanagement; CRA (ab 2027) und Data Act (ab September 2025) verschieben den Fokus auf sichere Produkte, Interoperabilität und Vendor-Neutralität.
Das Cloud Sovereignty Framework macht diese Anforderungen für Einkauf und Architektur messbar und verbindet Datenschutz, Security, Exit-Fähigkeit und Souveränität zu konkreten Auswahlkriterien für Cloud- und SaaS-Services.
ayedo verfolgt einen integrierten Compliance-Ansatz: Wir kombinieren ISO‑27001-orientierte Prozesse, cloud-native Architektur-Patterns und EU-Regulierungswissen, um Organisationen strukturiert zu einer tragfähigen, auditierbaren Compliance-Strategie zu führen.

Die GDPR ist seit dem 25. Mai 2018 unmittelbar anwendbares Recht in der EU – und sie ist mehr als „nur“ Datenschutz. Sie definiert Prinzipien, die sich quer durch die gesamte Regulierungslandschaft ziehen:

Wir erweitern unser Multi-Cloud-Angebot: IONOS Cloud ab sofort verfügbar

Wed, 08 Oct 2025 10:03:54 +0000

Neue Standards für Compliance und europäische Cloud-Souveränität

Ab sofort steht ayedo-Kunden ein weiterer leistungsfähiger Cloud-Provider zur Auswahl: die IONOS Cloud. Damit ergänzen wir unser bestehendes Infrastrukturportfolio – bestehend aus unserer eigenen Infrastruktur sowie Anbindungen an u. a. Hetzner – um eine weitere europäische Alternative mit höchsten Sicherheitsstandards.

Ob Managed Kubernetes oder der Betrieb unserer Managed Apps: Kunden können ihre Software nun auch auf IONOS Infrastruktur über ayedo betreiben – inklusive aller Vorteile unserer zertifizierten Plattformservices.

Das Ende von num=100 - kleine Änderung, große Folgen

Wed, 08 Oct 2025 09:40:39 +0000

Als Google still und leise den Parameter „num=100" aus seiner Suchmaschinenlogik entfernte, bemerkte es zunächst kaum jemand außerhalb der SEO-Bubble. Dabei war diese unscheinbare Variable über Jahre hinweg ein zentrales Werkzeug für all jene, die tiefere Einblicke in die Google-Suchergebnisse gewinnen wollten. Mit „num=100" ließ sich Google anweisen, bis zu hundert Resultate pro Anfrage auszuliefern – eine bequeme Hintertür, die es Entwicklern von SEO-Tools, Datendienstleistern und auch KI-Systemen erlaubte, große Mengen an Suchdaten in einem einzigen Abruf zu erfassen. Nun ist diese Tür geschlossen, und die Folgen reichen weit über ein paar zusätzliche Zeilen Code hinaus.

OpenAI, AMD und die stille Machtverschiebung in der globalen KI-Infrastruktur

Tue, 07 Oct 2025 13:25:51 +0000

Die Meldung klang zunächst wie eine weitere technische Partnerschaft in der Ära generativer KI: OpenAI und AMD schließen eine Vereinbarung über sechs Gigawatt GPU-Kapazität zur Unterstützung künftiger KI-Infrastrukturen. Doch wer genauer hinschaut, erkennt: Diese Partnerschaft ist mehr als nur ein Deal zwischen Anbieter und Abnehmer. Sie markiert eine nächste Eskalationsstufe in einem sich rasant entwickelnden Machtgefüge – nicht nur im Bereich Hochleistungsrechnen, sondern in der Architektur einer digitalen Weltwirtschaft, die zunehmend um proprietäre Modelle, geschlossene Lieferketten und strategische Beteiligungen gebaut wird.

Cloud Sovereignty Framework: Digitale Souveränität messbar gemacht

Tue, 07 Oct 2025 12:00:00 +0000

TL;DR

Das Cloud Sovereignty Framework der EU macht digitale Souveränität erstmals präzise messbar – über acht Souveränitätsziele (SOV‑1 bis SOV‑8) und fünf Assurance-Level (SEAL‑1 bis SEAL‑5).
Die SEAL-Levels erlauben es Beschaffungsstellen, klare Mindestanforderungen an Cloud-Dienste zu formulieren und Angebote objektiv zu vergleichen – insbesondere im regulierten und öffentlichen Sektor.
SEAL‑4 steht für praktisch vollständige digitale Souveränität: EU-Jurisdiktion, technische und operative Kontrolle durch europäische Akteure, Exit-Fähigkeit und verifizierbare Evidenzen über alle acht Souveränitätsziele hinweg.
Für Organisationen bietet das Framework einen pragmatischen Fahrplan: Ziel-Level pro SOV-Ziel definieren, GAPs identifizieren, Maßnahmen priorisieren und Beschaffungsprozesse sowie Verträge entlang des Modells ausrichten.
ayedo unterstützt Sie dabei, SEAL‑4-fähige Plattformen aufzubauen – mit EU-only Infrastruktur, BYOK, offenen Standards, Exit-Szenarien, ISO-zertifizierten Prozessen und einem strukturierten Cloud Sovereignty Assessment.

Was das Cloud Sovereignty Framework leistet

Digitale Souveränität war lange ein abstrakter Begriff. Das ändert sich mit dem Cloud Sovereignty Framework der Europäischen Kommission. Es übersetzt den politischen Anspruch nach europäischer Kontrolle über digitale Infrastrukturen in ein operatives Modell, das sich messen, auditieren und in Ausschreibungen verankern lässt.

Backup-Versagen in Südkorea

Tue, 07 Oct 2025 10:04:18 +0000

Kein Backup, kein Mitleid – aber vor allem: kein Schweigen mehr. Wer 2025 immer noch glaubt, kritische Infrastrukturen ohne externe Datensicherung betreiben zu können, sollte nicht nur zur Rechenschaft gezogen werden, sondern vor allem nicht mit sensiblen Daten betraut sein.

Was in Südkorea passiert ist, liest sich wie eine Parabel auf systemisches IT-Versagen: Ein Feuer im Rechenzentrum des National Information Resources Service (NIRS) zerstörte nicht nur Hardware – es löschte 858 Terabyte Verwaltungsdaten aus dem zentralen G-Drive-System der Regierung. Daten von 750.000 Beschäftigten – einfach weg.

Weekly Backlog 41/2025

Mon, 06 Oct 2025 13:59:28 +0000

Weekly Backlog KW 41/2025

Digitale Identität, souveräne Verwaltungen und die unkaputtbare Trägheit der deutschen Digitalisierung

Editorial

Diese Woche ist wie ein Brennglas auf alles, was in der deutschen Digitalpolitik schiefläuft – und an wenigen Stellen doch Hoffnung macht.

Während Bonify (Schufa-Tochter!) mit einem Datenschutzleck beweist, dass selbst Identitätsdienste kaum ihre eigenen Daten schützen, wollen andere gleich eine digitale Brieftasche für ganz Deutschland starten. Gleichzeitig kämpft Discord mit einem Leck über externe Dienstleister – und das Saarland zeigt, dass Verwaltung mit Open-Source-KI und europäischer Datenhaltung eben doch funktioniert.

Data Act: Portabilität und Exit-Fähigkeit werden Pflicht ab September 2025

Mon, 06 Oct 2025 12:00:00 +0000

TL;DR

Der Data Act tritt am 12. September 2025 in Kraft und macht Datenportabilität, Cloud-Switching und Interoperabilität zu verbindlichen Anforderungen – mit klaren Rechten für Nutzer und Pflichten für Provider.
Die sechs Kernziele reichen von IoT-Datenzugangsrechten über B2B/B2G-Datenzugang bis hin zu Cloud-Switching, Interoperabilität und Schutz vor Drittlandszugriffen – und zielen auf fairen Wettbewerb statt Vendor-Lock-in.
Für Cloud-Switching werden offene APIs, transparente Egress-Regeln und funktionale Äquivalenz Pflicht. Organisationen brauchen Exit-Strategien mit klaren Runbooks, Verantwortlichkeiten und getesteten Prozessen.
Interoperabilitätsstandards wie ISO/IEC 19941 und das EU Cloud Rulebook bieten einen technischen Kompass für Multi-Cloud-Architekturen und verhindern Insellösungen.
ayedo unterstützt Sie mit API-first-Plattformdesign, standardisierten Exit-Runbooks und Multi-Cloud-Architekturen dabei, Data-Act-Anforderungen pragmatisch umzusetzen und Portabilität als Wettbewerbsvorteil zu nutzen.

Data Act: Portabilität und Exit-Fähigkeit werden planbar

Der Data Act (Verordnung (EU) 2023/2854) ist mehr als ein weiteres Compliance-Projekt. Er ist ein Infrastrukturgesetz für den europäischen Daten- und Cloud-Markt.

Datenleck bei Discord: Angriff auf Supportdienstleister kompromittiert Nutzerdaten

Mon, 06 Oct 2025 10:12:09 +0000

Am 5. Oktober 2025 wurde bekannt, dass ein externer Support-Dienstleister der Plattform Discord Ziel eines Cyberangriffs geworden ist. Dabei wurden persönliche Daten von Nutzerinnen und Nutzern entwendet, die in den vergangenen Wochen mit dem Discord-Support in Kontakt standen. Laut Discord selbst sei die Kernplattform nicht betroffen gewesen. Die Attacke konzentrierte sich demnach ausschließlich auf die Systeme des beauftragten Dienstleisters.

Art der erbeuteten Daten

Nach Angaben des Unternehmens konnten die Angreifer unter anderem auf folgende Datensätze zugreifen:

F13 im Saarland: Open-Source-KI für eine moderne, souveräne Verwaltung

Mon, 06 Oct 2025 09:54:01 +0000

NIS-2 erweitert den Geltungsbereich der EU-Cybersicherheitsregulierung auf 18 Sektoren und bindet vor allem mittlere und große Unternehmen in kritischen und wichtigen Bereichen ein. Die Richtlinie ist seit dem 16. Januar 2023 in Kraft und muss bis zum 17. Oktober 2024 in nationales Recht überführt sein.
Kernelement von NIS-2 sind zehn Mindestanforderungen an das Cyber-Risikomanagement, darunter Incident Handling, Business Continuity/Disaster Recovery, Supply-Chain-Sicherheit, Zugriffskontrolle und Multi-Faktor-Authentifizierung.
Das Management trägt explizite Verantwortung: Führungsteams müssen Cybersicherheits-Risiken verstehen, strategische Entscheidungen treffen und sind bei grober Pflichtverletzung persönlich haftbar.
Meldepflichten sind streng geregelt: Frühwarnung innerhalb von 24 Stunden, detaillierter Bericht nach 72 Stunden und ein Abschlussbericht innerhalb eines Monats – das erfordert klare Prozesse, Rollen und geeignete technische Telemetrie.
ayedo unterstützt Sie mit einer integrierten, auf NIS-2 ausgerichteten Plattform: von Intrusion Detection mit Falco, über Netzwerk-Sichtbarkeit mit Cilium, Backups mit Velero bis zu Supply-Chain-Security mit Harbor sowie einer strukturierten Compliance-Architektur und einem NIS-2-Readiness-Assessment.

NIS-2 als neuer Standard für Cyber-Resilienz in Europa

Mit der NIS-2-Richtlinie (EU) 2022/2555 etabliert die EU einen einheitlichen, anspruchsvollen Standard für Cybersicherheit. Die Richtlinie ist am 16. Januar 2023 in Kraft getreten; die Mitgliedstaaten müssen sie bis zum 17. Oktober 2024 in nationales Recht überführen. Ab diesem Zeitpunkt greifen nationale NIS-2-Gesetze – und damit konkrete Pflichten und Sanktionsmechanismen.

GDPR: Privacy by Design als Fundament moderner Software

Thu, 02 Oct 2025 12:00:00 +0000

TL;DR

Die GDPR verlangt seit dem 25.05.2018, dass personenbezogene Daten nach dem Prinzip “Privacy by Design” geschützt werden – technisch heißt das: risikobasierte Sicherheitsarchitektur, durchgängige Verschlüsselung und sauber implementierte Prozesse für Betroffenenrechte.
Art. 32 fordert “Stand der Technik” bei Sicherheit und Verfügbarkeit: Pseudonymisierung, Verschlüsselung, Zugriffskontrolle, Auditierbarkeit und belastbare Backup-/Recovery-Prozesse sind heute Mindeststandard in Cloud-nativen Umgebungen.
Art. 28 verschiebt Verantwortung in die Lieferkette: Cloud-Provider müssen als Auftragsverarbeiter klare Garantien geben – von Weisungsgebundenheit über Subprozessor-Transparenz bis hin zu technischer Unterstützung bei Löschersuchen (Art. 17).
EU-Datenlokalisierung ist kein politischer Luxus, sondern ein technischer und rechtlicher Stabilitätsanker: Datenresidenz in EU-Rechenzentren reduziert regulatorische Risiken und vereinfacht Architekturentscheidungen.
ayedo setzt Privacy by Design praktisch um: EU-basierte Rechenzentren, BYOK-Schlüsselverwaltung, durchgängige Verschlüsselung, detaillierte Audit Logs auf Basis von Systemen wie Loki sowie dokumentierte Compliance-Bausteine in der ayedo Kubernetes-Distribution.

Privacy by Design als Architekturprinzip – nicht als Zusatzoption

“Privacy by Design” in der GDPR ist kein Marketing-Slogan, sondern ein Architekturprinzip. Die Verordnung ist bewusst technologieoffen gehalten. Sie schreibt nicht vor, welche Software Sie einsetzen müssen, sondern definiert Schutzziele und lässt Ihnen den Gestaltungsspielraum, diese technisch sinnvoll umzusetzen.

Wenn der Scoreanbieter selbst zum Risiko wird

Thu, 02 Oct 2025 10:17:45 +0000

Bonify und der Verlust digitaler Identität

Am 1. Oktober 2025 wurde ein Datenschutzvorfall bekannt, der das Vertrauen in die digitale Bonitätswirtschaft weiter erschüttert: Die Schufa-Tochter Forteil, Betreiber des Dienstes Bonify, hat bestätigt, dass Unbefugte Zugriff auf Identifikationsdaten von Nutzer:innen hatten. Es handelt sich nicht um abstrakte Metadaten oder technische Logs – sondern um reale, personenbezogene Daten: Ausweisdokumente, Adressen, Fotos und Videoaufnahmen, aufgenommen im Rahmen des Videoident-Verfahrens.

Was genau ist passiert?

Wie zuerst heise online berichtete, wurde bei einem Angriff auf Bonify sensible Nutzerdaten erbeutet, die beim Onboarding-Prozess für neue Kunden erfasst werden – konkret:

Compliance Compass: EU-Regulierungen für Software, SaaS und Cloud-Hosting

Wed, 01 Oct 2025 12:00:00 +0000

TL;DR

Die EU hat mit GDPR, NIS‑2, DORA, CRA, Data Act und dem Cloud Sovereignty Framework ein kohärentes Regelwerk geschaffen, das Datenschutz, Cyber-Resilienz, digitale Souveränität und Interoperabilität systematisch stärkt.
Für Betreiber von Software, SaaS und Cloud-Hosting bedeutet das: klare Anforderungen an Security-by-Design, Datenverarbeitung, Exit-Fähigkeit, Drittparteirisiken und Governance – aber auch wiederverwendbare Bausteine, die viele Pflichten gleichzeitig adressieren.
Die gemeinsamen Ziele der Regelungen sind: Schutz personenbezogener und geschäftskritischer Daten, Widerstandsfähigkeit gegenüber Cybervorfällen, Reduktion von Vendor Lock-in und ein souveräner europäischer Technologiestandort.
Strategisch sinnvoll ist ein integrierter Ansatz: Ein sauberes ISMS, cloud-native Architektur, dokumentierte Prozesse sowie transparente Lieferketten können große Teile der Anforderungen aller sechs Regulierungen parallel abdecken.
ayedo unterstützt Organisationen dabei, diese Regulierungen in tragfähige Architektur-, Plattform- und Prozessentscheidungen zu übersetzen und so Compliance als strukturierten Wettbewerbsvorteil zu nutzen – von der Analyse bis zur betriebenen Plattform.

Warum ein Compliance-Compass nötig ist

Die europäische Regulierungslandschaft ist in den letzten Jahren deutlich dichter geworden. Das ist kein Zufall, sondern Ausdruck eines klaren politischen Ziels: Europa will im digitalen Raum nicht nur Konsument, sondern eigenständiger Gestalter sein. Dazu gehören verlässlicher Datenschutz, robuste Infrastrukturen, faire Wettbewerbsbedingungen und ein Mindestmaß an technologischer Unabhängigkeit.

Smartes Load Balancing mit Cloudflare Healthchecks: Effizient, robust und kostengünstig

Tue, 30 Sep 2025 09:03:28 +0000

Cloudflare ist längst mehr als nur ein CDN-Anbieter. Neben Performance-Optimierung und Sicherheitsfeatures bietet die Plattform zahlreiche Tools, die sich kreativ einsetzen lassen, um individuelle Anforderungen in modernen Infrastruktur-Setups zu lösen – ohne zwangsläufig auf die kostenpflichtigen Enterprise-Features zurückgreifen zu müssen.

Bei ayedo haben wir genau das getan: Wir nutzen Cloudflare nicht nur für DNS-Management und Traffic-Proxys, sondern auch für ein eigenes Load-Balancing-Konzept – ohne die offiziellen Load-Balancer-Features von Cloudflare zu verwenden, und das mit beeindruckender Kosteneffizienz.

Der Digital Networks Act (DNA): Europas Konnektivitätsreform mit Sprengkraft

Mon, 29 Sep 2025 08:32:34 +0000

Warum der DNA das digitale Fundament Europas neu definiert

Mit dem Digital Networks Act (DNA) bereitet die EU eine der tiefgreifendsten Reformen ihres Telekommunikationssektors vor. Ziel ist es, die regulatorische Fragmentierung zu überwinden, Investitionen in zukunftsfähige Netzinfrastrukturen zu beschleunigen und Europas digitale Wettbewerbsfähigkeit auf globaler Ebene zu stärken.

Doch der DNA ist mehr als ein technokratisches Gesetzeswerk: Er steht für einen Paradigmenwechsel hin zu einer einheitlichen, resilienten und souveränen digitalen Infrastruktur – und zugleich im Zentrum einer hochemotionalen Kontroverse um die Einführung eines sogenannten Fair-Share-Modells. Dieses soll große Content-Anbieter zur Mitfinanzierung der Netze verpflichten – mit potenziellen Folgen für Netzneutralität und Offenheit des Internets.

Ankündigung der Unterstützung für Changed Block Tracking API (Alpha)

Thu, 25 Sep 2025 13:00:00 +0000

TL;DR

Die Unterstützung für die Changed Block Tracking API in Kubernetes (Alpha) ermöglicht es, geänderte Datenblöcke zwischen Snapshots effizient zu identifizieren, was die Backup-Prozesse optimiert. Diese Funktion reduziert Backup-Zeiten und Ressourcenverbrauch erheblich und ist besonders vorteilhaft für große Datenmengen.

Hauptinhalt

Die neue Changed Block Tracking API in Kubernetes bietet eine verbesserte Methode zur Identifizierung und Verfolgung von Änderungen auf Blockebene zwischen Snapshots. Diese Funktion ist für Container Storage Interface (CSI) Treiber implementiert und ermöglicht es Backup-Anwendungen, sich nur auf die geänderten Datenblöcke zu konzentrieren, anstatt gesamte Volumes zu scannen. Dies führt zu schnelleren und ressourcenschonenderen Backup-Operationen.

OpenAI for Germany – Digitale Souveränität mit Azure im Fundament?

Thu, 25 Sep 2025 07:28:07 +0000

Titel: OpenAI for Germany – Digitale Souveränität mit Azure im Fundament?

Markdown-Content:

Am 24. September 2025 verkündeten SAP und OpenAI eine neue Partnerschaft: OpenAI for Germany. Ziel sei es, Künstliche Intelligenz „made for Germany" in den öffentlichen Sektor zu bringen – verantwortungsvoll, rechtskonform und souverän. Getragen wird das Projekt von SAP, betrieben über deren Tochterfirma Delos Cloud – auf technischer Basis von Microsoft Azure.

Auf den ersten Blick: ein Fortschritt. Auf den zweiten: ein Widerspruch.

Weekly Backlog KW 40/2025

Thu, 25 Sep 2025 07:16:31 +0000

Souveränität vs. Marktlogik

🧠 Editorial

Diese Woche lässt sich ein roter Faden kaum übersehen: „Souveränität" wird überall beschworen. In der Cloud, bei KI, in den Netzen. Doch sobald man genauer hinschaut, zerbröselt einfach alles. Mal hängt die deutsche „Staats-KI" am Tropf von Azure. Mal pumpt Nvidia 100 Milliarden in OpenAI, um die Monopolstellung zu sichern. Und mal schreibt Brüssel an einem Digital Networks Act, der die Grundregeln des Netzes neu ordnen will. Unsicherheiten zwischen Fair-Share-Forderungen und Netzneutralitäts-Gefahren.

OpenAI und Nvidia: 100 Milliarden Dollar für das KI-Wettrüsten

Wed, 24 Sep 2025 11:41:40 +0000

Titel: OpenAI und Nvidia: 100 Milliarden Dollar für das KI-Wettrüsten

Markdown-Content:

Die Meldung von Reuters schlägt Wellen: Nvidia plant, bis zu 100 Milliarden US-Dollar in OpenAI zu investieren. Ein Schritt, der nicht nur durch seine schiere Dimension beeindruckt, sondern auch durch die Struktur des Deals. Nvidia will nicht nur Kapital einbringen, sondern zugleich die notwendige Hardware liefern – und damit die Grundlage für OpenAIs künftige Rechenzentren sichern.

Die Dimension des Deals

Konkret sieht die Vereinbarung vor, dass OpenAI mindestens 10 Gigawatt an Nvidia-Systemen einsetzen wird. Das entspricht dem Energiebedarf von über acht Millionen US-Haushalten. Bereits jetzt ist klar: Der Bau und Betrieb dieser Rechenzentren wird neue Maßstäbe setzen – technisch wie ökonomisch.

Weekly Backlog KW 39/2025

Wed, 24 Sep 2025 10:41:40 +0000

Linux Vs Windows

🧠 Editorial

Astronauten nutzen Linux, weil man im All keine Windows öffnen kann – und ganz ehrlich: manchmal wünschte ich mir, unsere Innenministerien würden sich die gleiche Logik zu Herzen nehmen. Aber wir kommen gleich dazu.

🚨 Die Tech-News der Woche

Niedersachsen stoppt Palantir – endlich jemand mit Rückgrat

Niedersachsens Innenministerin Daniela Behrens hat das einzig Richtige getan: Palantir eine klare Absage erteilt. Ihr Satz „Das System ist natürlich ein gutes System, aber es ist nicht beherrschbar" bringt es auf den Punkt.

Kubernetes v1.34: Pod-Level-Ressourcen in Beta überführt

Mon, 22 Sep 2025 18:30:00 +0000

TL;DR

Die Kubernetes-Version 1.34 hat die Pod-Level-Ressourcen in den Beta-Status überführt, was eine vereinfachte Verwaltung der Ressourcenallokation für Pods ermöglicht. Diese Neuerung erlaubt es, CPU- und Speicherkapazitäten auf Pod-Ebene zu definieren, wodurch eine effizientere Ressourcennutzung und eine verbesserte Leistung von Anwendungen erreicht werden können.

Hauptinhalt

Die Einführung der Pod-Level-Ressourcen in Kubernetes v1.34 stellt einen bedeutenden Fortschritt in der Verwaltung von Ressourcen dar. Bisher mussten Ressourcen hauptsächlich auf der Ebene einzelner Container definiert werden, was oft zu redundanten Berechnungen und einer komplexen Verwaltung führte. Mit der neuen Funktion können nun CPU und Speicher für den gesamten Pod festgelegt werden, was die Verwaltung erheblich vereinfacht.

Der große Unterschied: Warum MSPs Zukunft haben

Sun, 21 Sep 2025 20:09:56 +0000

Warum Hyperscaler nur Hardware verkaufen – und MSPs die Zukunft sind

Hyperscaler haben die digitale Welt geprägt wie kaum ein anderes Modell. Mit dem Versprechen unbegrenzter Skalierung, globaler Verfügbarkeit und scheinbar unendlicher Innovation haben sie eine ganze Generation von IT-Strategien dominiert. Doch schaut man genauer hin, bleibt von dieser Erzählung wenig übrig: Das Geschäftsmodell der Hyperscaler basiert bis heute fast ausschließlich auf dem Verkauf von Hardware – Compute, Storage, Netzwerktraffic. Schick verpackt, global distribuiert, in APIs gegossen, aber im Kern immer noch dieselbe Logik: Du mietest Maschinen.

Kubernetes als Betriebssystem der Cloud

Sun, 21 Sep 2025 20:07:30 +0000

Wenn wir heute über digitale Souveränität und moderne IT-Infrastrukturen sprechen, führt kein Weg mehr an Kubernetes vorbei. Innerhalb weniger Jahre hat sich das Open-Source-Projekt vom Orchestrator für Container zu einem De-facto-Standard entwickelt, der in seiner Bedeutung durchaus mit dem Linux-Kernel vergleichbar ist. Wer verstehen will, warum, muss sich die Architektur ansehen – und die Parallelen ernst nehmen.

Von Linux zum Cluster

Linux abstrahiert die Hardware eines Servers. Es verwaltet CPU-Kerne, Arbeitsspeicher und Speichermedien, sorgt für Prozessisolation und stellt Schnittstellen bereit, auf denen Anwendungen aufsetzen können.

Cloud-native Softwareentwicklung

Sun, 21 Sep 2025 20:04:43 +0000

Souveränität durch Architektur\n

Cloud-native Softwareentwicklung ist mehr als ein Methodenbaukasten. Sie beschreibt ein Paradigma, das Anwendungen so gestaltet, dass sie in hochdynamischen Infrastrukturen zuverlässig funktionieren – Umgebungen, in denen Server, Datenbanken und Netzwerke nicht mehr statisch existieren, sondern per API bereitgestellt und wieder entfernt werden können.

Damit verschiebt sich die Perspektive: Es geht nicht länger nur um das Schreiben von Code oder den Betrieb von Infrastruktur, sondern um das Ineinandergreifen beider Disziplinen in einem durchgängigen, überprüfbaren Prozess.

Kubernetes v1.34: Wiederherstellung nach Volume-Erweiterungsfehler (GA)

Fri, 19 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 führt eine verbesserte Wiederherstellung nach Fehlern bei der Erweiterung von Persistent Volumes ein, die nun allgemein verfügbar ist. Diese neue Funktion ermöglicht es Nutzern, fehlerhafte Erweiterungsanfragen einfach zu korrigieren, ohne administrative Eingriffe vornehmen zu müssen. Zudem wurden die Fehlerbehandlung und die Überwachungsmöglichkeiten während des Erweiterungsprozesses erheblich verbessert.

Hauptinhalt

Mit der Veröffentlichung von Kubernetes v1.34 wird die automatisierte Wiederherstellung von fehlgeschlagenen Volumen-Erweiterungen, die zuvor in der Beta-Phase war, nun allgemein verfügbar. Diese Funktion adressiert ein häufiges Problem, das bei der Erweiterung von Persistent Volumes auftritt, insbesondere wenn Nutzer versehentlich falsche Größenangaben machen. Vor dieser Version war die manuelle Wiederherstellung oft zeitaufwendig und erforderte Administratorzugriff.

Microsoft Entra ID - Die gefährlichste Sicherheitslücke

Fri, 19 Sep 2025 11:21:58 +0000

Ein kritischer Blick auf CVE-2025-55241

Am 18. September berichtete golem.de über eine Sicherheitslücke in Microsoft Entra ID, die von dem Sicherheitsforscher Dirk-Jan Mollema entdeckt und als „wohl bedeutendste Entra-ID-Sicherheitslücke" seiner Laufbahn bezeichnet wurde. Registriert als CVE-2025-55241 und mit einem CVSS-Score von 9,0 als kritisch eingestuft, zeigt der Fall exemplarisch, wie verwundbar zentrale Identitäts- und Zugriffsplattformen sein können.

Was war das Problem?

Im Kern basiert die Lücke auf dem Missbrauch sogenannter Actor-Tokens – interne Tokens, die Microsoft für die Service-to-Service-Kommunikation einsetzt. In Verbindung mit einem Bug in der Graph-API für Azure Active Directory konnte Mollema zeigen, dass sich diese Tokens zweckentfremden lassen, um Zugriff auf fremde Tenants zu erlangen.

Switching‑Register – Verfahren, Formate & Schnittstellen

Fri, 19 Sep 2025 00:00:00 +0000

Version: 2025-09-19

Kontakt: security@ayedo.de · billing@ayedo.de
Rechtsnatur: Dieses Register konkretisiert Art. 26 EU Data Act. Maßgeblich bleiben Vertrag inkl. der AGB. Für jeden Vertrag ist die zum Vertragsschluss übergebene Fassung maßgeblich (Export/PDF als Anlage). Spätere Aktualisierungen wirken nicht zu Lasten laufender Verträge.

1) Zweck und Anwendungsbereich

Dieses Register beschreibt Verfahren, Datenstrukturen/-formate, Standards und Schnittstellen für den Anbieterwechsel. Es gilt für folgende ayedo‑Leistungsbereiche:

Managed Kubernetes (Public-Cloud, Private-Cloud, Enterprise-Cloud)
Managed Apps
Bring-Your-Own-Apps

Hinweis zu On‑Premises‑Zielumgebungen: Der Wechsel in kundeneigene Rechenzentren wird unterstützt (siehe Abschnitt 9).

Kubernetes v1.34: DRA nutzbare Kapazität

Thu, 18 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 führt die Funktion der konsumierbaren Kapazität im Rahmen der dynamischen Ressourcenzuteilung (DRA) ein, die eine flexiblere Verwaltung von Geräten und deren Nutzung durch Pods ermöglicht. Diese Neuerung erlaubt das Teilen von Ressourcen über mehrere ResourceClaims und verbessert die Effizienz der Ressourcennutzung in Kubernetes–Clustern.

Hauptinhalt

Die dynamische Ressourcenzuteilung (DRA) in Kubernetes zielt darauf ab, knappe Ressourcen effizienter zwischen Pods und Containern zu verwalten. Mit der Einführung der konsumierbaren Kapazität in Kubernetes v1.34 wird die DRA um die Möglichkeit erweitert, spezifische Geräteteile flexibel zuzuweisen. Dies geht über die einfache Zuteilung von Geräten hinaus und ermöglicht es Nutzern, maßgeschneiderte Konfigurationen für ihre Workloads zu definieren und Geräte zwischen mehreren Containern oder Pods zu teilen.

EU Data Act – Switching & Interoperability Center

Thu, 18 Sep 2025 00:00:00 +0000

Stand: 18.09.2025

Diese Seite bündelt ayedo-weit die Informationen zu Switching, Interoperabilität und Transparenz gemäß VO (EU) 2023/2854 (EU Data Act). Sie konkretisiert unsere Verträge/AGB, ist jedoch nicht selbst Vertragsbestandteil. Maßgeblich bleiben der jeweils gültige Vertrag inkl. Anhänge (abschließende Listen). Versionen dieser Seite sind für den Zeitpunkt des Vertragsschlusses maßgeblich.

Geltung & Stichtage

12.09.2025: Anwendbarkeit der Switching‑Pflichten (Kapitel VI; insb. Art. 23–27, 30).
12.01.2027: Verbot von Switching‑Charges; bis dahin nur kostenbasierte, reduzierte Entgelte zulässig (direkt zurechenbare Kosten).
Kapitel IV (unfaire Vertragsklauseln in B2B ggü. KMU) gilt für neu geschlossene Verträge ab 12.09.2025; für bestimmte Altverträge greifen Übergangsfristen.
Hinweis: Standard‑Servicegebühren laufen während Notice/Transit regulär weiter. Egress/Parallelbetrieb: at cost.

Weiterführende Information findet Sie in unseren Allgemeinen Geschäftsbedingungen (Kapitel 7).

Kubernetes v1.34: Pods melden DRA-Ressourcenzustand

Wed, 17 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 führt eine neue Alpha-Funktion ein, die es Pods ermöglicht, den Gesundheitszustand von Geräten über den Dynamic Resource Allocation (DRA) Mechanismus zu melden. Diese Verbesserung erleichtert die Diagnose von Hardwarefehlern in Kubernetes-Clustern und verbessert die Sichtbarkeit für Betreiber und Entwickler.

Hauptinhalt

Die zunehmende Nutzung von KI/ML und anderen leistungsintensiven Workloads hat die Notwendigkeit für spezialisierte Hardware wie GPUs, TPUs und FPGAs in Kubernetes-Clustern verstärkt. Mit der neuen Version von Kubernetes wird eine Funktion bereitgestellt, die es ermöglicht, den Gesundheitszustand dieser Geräte direkt im Status eines Pods anzuzeigen. Dies geschieht über die Erweiterung der Funktionalität des KEP-4680, das ursprünglich ein Mechanismus für die Berichterstattung über den Gesundheitszustand von Geräten eingeführt hat, die von Device Plugins verwaltet werden.

Kubernetes v1.34: Verschieben von Volume Group Snapshots zu v1beta2

Tue, 16 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 hat die Unterstützung für Volume Group Snapshots auf die Beta-Version v1beta2 aktualisiert. Diese Funktion ermöglicht es, konsistente Snapshots von mehreren Volumes zu erstellen und sie bei Bedarf wiederherzustellen. Die neue Beta-Version bringt Anpassungen in der API-Struktur und zielt darauf ab, die Funktionalität weiter zu verbessern.

Hauptinhalt

Die Unterstützung für Volume Group Snapshots wurde erstmals in der Kubernetes Version 1.27 als Alpha-Funktion eingeführt und in der Version 1.32 in den Beta-Status überführt. Mit der aktuellen Version v1.34 wird diese Funktion nun in die zweite Beta-Phase überführt. Diese Funktionalität nutzt eine Reihe von Erweiterungs-APIs, die es Benutzern ermöglichen, konsistente Snapshots für eine Gruppe von Volumes zu erstellen. Kubernetes verwendet dazu einen Label-Selector, um mehrere PersistentVolumeClaims für das Snapshotting zu gruppieren. Dies ermöglicht eine Wiederherstellung der Snapshots auf neue Volumes, was eine zuverlässige Wiederherstellung des Workloads nach einem Ausfall ermöglicht.

CrowdStrike unter Beschuss: Supply-Chain-Angriff auf npm-Pakete entlarvt neue Dimension der Gefahr

Tue, 16 Sep 2025 13:15:26 +0000

Die Nachricht schlägt hohe Wellen: Mehrere npm-Pakete von CrowdStrike – einem Unternehmen, das eigentlich für Sicherheit und Schutz bekannt ist – wurden kompromittiert. Was nach einer Randnotiz klingt, ist in Wahrheit ein massiver Weckruf für die gesamte Softwareindustrie. Es handelt sich um eine Fortsetzung der „Shai-Halud"-Kampagne, die bereits im Rahmen des Tinycolor-Angriffs aufgefallen war.

Was ist passiert?

Unbekannte Angreifer haben Zugriff auf das npm-Konto crowdstrike-publisher erlangt und dort manipulierte Versionen populärer CrowdStrike-Bibliotheken veröffentlicht. Darunter:

Kubernetes v1.34: Entkoppelter Taint-Manager ist jetzt stabil

Mon, 15 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 hat den entkoppelten Taint-Manager stabilisiert, wodurch die Verwaltung des Lebenszyklus von Knoten und die Evakuierung von Pods in separate Komponenten aufgeteilt werden. Diese Änderung verbessert die Code-Organisation und ermöglicht benutzerdefinierte Implementierungen des Taint-basierten Evakuierungsprozesses.

Hauptinhalt

Die neue Version von Kubernetes v1.34, bringt eine signifikante Verbesserung in der Art und Weise, wie Taints und Pod-Evakuierungen verwaltet werden. Zuvor war der Node Lifecycle Controller für sowohl die Kennzeichnung von Knoten als ungesund als auch für die Evakuierung von Pods verantwortlich. Mit der Einführung eines dedizierten Taint Eviction Controllers wird diese Verantwortung nun klar getrennt. Der Node Lifecycle Controller konzentriert sich ausschließlich auf das Anwenden von Taints, während der Taint Eviction Controller für die Evakuierung von Pods zuständig ist.

Hosting reloaded: Warum die Zukunft nicht den Hyperscalern gehört

Mon, 15 Sep 2025 07:09:24 +0000

In den vergangenen Jahren galt Cloud First als nahezu unumstößliche Maxime. Unternehmen aller Größenordnungen sollten ihre Infrastruktur so schnell wie möglich in die Public Cloud verlagern, um Skalierbarkeit, Innovation und Wettbewerbsfähigkeit sicherzustellen. Für viele klang das nach einer einfachen Formel: je mehr Cloud, desto besser. Doch inzwischen zeigt sich, dass dieser Ansatz nicht in allen Fällen die versprochene Lösung bringt – im Gegenteil, er wirft neue Fragen auf, die zunehmend kritisch diskutiert werden.

Kubernetes v1.34: Autokonfiguration für Node Cgroup Driver wird GA

Fri, 12 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 führt die Autokonfiguration des Node Cgroup Drivers als allgemeine Funktion ein, wodurch die manuelle Konfiguration des Cgroup Drivers für kubelet und CRI-Implementierungen entfällt. Diese Funktion verbessert die Benutzerfreundlichkeit und verringert die Fehleranfälligkeit bei der Bereitstellung neuer Kubernetes-Cluster.

Hauptinhalt

Die Konfiguration des Cgroup Drivers war für viele Nutzer von Kubernetes ein wiederkehrendes Problem, insbesondere bei der Einrichtung neuer Cluster auf Linux-Systemen. Traditionell mussten sowohl der kubelet als auch die Container Runtime (wie CRI-O oder containerd) so konfiguriert werden, dass sie denselben Cgroup Driver verwenden, um Fehlfunktionen zu vermeiden. Dies führte häufig zu Verwirrung und unerwarteten Fehlern, da keine klaren Fehlermeldungen bereitgestellt wurden.

Chat Control: Von der DSGVO zur Massenüberwachung – Europas gefährlicher Kurswechsel

Hauptinhalt

Kubernetes hat sich kontinuierlich darum bemüht, die Stabilität und Vorhersagbarkeit der Performance des API-Servers zu verbessern. Ein zentrales Anliegen war die Optimierung von LIST-Anfragen, die historisch gesehen zu hohem Speicherverbrauch und einer starken Belastung des etcd-Datenspeichers führten. Mit der Einführung des snapshottable API-Server-Caches in Kubernetes v1.34 wird ein bedeutender Fortschritt in dieser Hinsicht erzielt.

NPM unter Beschuss: Supply-Chain-Angriff auf das Fundament der Softwareentwicklung

Mon, 08 Sep 2025 19:26:12 +0000

Seit dem 8. September liegen konkrete Hinweise vor, dass eine Reihe extrem weit verbreiteter NPM-Pakete – darunter debug, chalk, ansi-styles, supports-color und weitere zentrale Bausteine des Node.js-Ökosystems – kompromittiert wurden; der Maintainer wurde laut öffentlicher Darstellung per Phishing auf eine gefälschte NPM-Support-Domain hereingelegt, woraufhin neue, präparierte Versionen veröffentlicht wurden, die in Summe über das gesamte Set betrachtet wöchentlich Milliardenfach gezogen werden und damit in praktisch jede moderne Frontend-, Backend- und CI/CD-Pipeline diffundieren können.

Kubernetes v1.34: VolumeAttributesClass für die GA zur Volumenänderung

Mon, 08 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 hat die VolumeAttributesClass API in den Status der allgemeinen Verfügbarkeit (GA) überführt. Diese Funktion ermöglicht es Nutzern, die Attribute von Volumes dynamisch zu modifizieren, was eine flexible Anpassung der Speicherressourcen in Kubernetes ermöglicht.

Hauptinhalt

Den Begriff SBOM erläutern und ihn anhand von Konzepten aus der realen Welt greifbar machen.
Das Konzept der CVEs erklären und die wichtigsten Quellen von Schwachstelleninformationen vorstellen.
Aufzeigen, wie Tools wie GitLab und Harbor helfen, SBOMs zu generieren und CVE-Scans durchzuführen.
Den besonderen Nutzen dieser Prozesse für compliance-lastige Branchen wie Pharma, Industrie und GovTech darstellen.

Was ist eine Software Bill of Materials (SBOM)?

Eine Software Bill of Materials ist im Kern eine Stückliste der Software. Sie beschreibt, aus welchen Komponenten eine Software besteht – vergleichbar mit den Stücklisten in der industriellen Fertigung.

Storage in Kubernetes

Tue, 02 Sep 2025 15:45:25 +0000

Speicher in Kubernetes ist keinesfalls trivial. Stateful Workloads stellen höchste Anforderungen an Stabilität, Performance und Verfügbarkeit – der Umgang mit persistenten Daten ist daher eine der komplexesten Aufgaben im Cloud‑Native‑Umfeld. Dieser Artikel beleuchtet das Thema umfassend: von CSI, über Cloud vs. On‑Premise CSI, Longhorn, Ceph und einer weiteren Lösung, bis hin zu Cloud‑Controller‑Manager, Kosten, Skalierung, Redundanz, Sicherheit und den Herausforderungen lokaler Speicherlandschaften.

Was ist CSI (Container Storage Interface)?

CSI, die Container Storage Interface, ist ein Standardschnittstelle (API-Spezifikation), die Kubernetes oder anderen Container-Orchestrierungen ermöglicht, mit beliebigen Speicherlösungen (Block oder File) zu arbeiten – ohne Änderungen am Kubernetes-Kerncode. So können externe Speicheranbieter CSI-Treiber entwickeln und unabhängig vom Kubernetes-Releasezyklus bereitstellen. Die Architektur umfasst in der Regel zwei Komponenten: einen Controller Plugin (für Provisionierung, Attachment etc.) und einen Node Plugin (für Mounting) .

Immutable Releases bei GitHub – ein wichtiger Meilenstein für eine sichere Software Supply-Chain

Tue, 02 Sep 2025 15:37:32 +0000

Die Sicherheit der Software Supply-Chain ist eines der zentralen Themen moderner Softwareentwicklung. Mit jeder neuen Abhängigkeit, jedem externen Artefakt und jeder genutzten Bibliothek wächst die Angriffsfläche – und damit auch die Verantwortung der Entwicklerinnen und Entwickler, diese Kette gegen Manipulationen und versehentliche Fehler abzusichern. GitHub hat nun mit den sogenannten Immutable Releases ein Feature eingeführt, das einen großen Schritt in diese Richtung bedeutet: einmal veröffentlichte Releases können nicht mehr nachträglich verändert werden.

Kubernetes v1.34: DRA hat den Status GA erreicht

Mon, 01 Sep 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 hat die Unterstützung für die dynamische Ressourcenallokation (DRA) auf den Status “General Availability” (GA) angehoben. Dies ermöglicht eine verbesserte Verwaltung spezialisierter Hardware wie GPUs und FPGAs, während neue Beta- und Alpha-Funktionen zusätzliche Flexibilität und Kontrolle bieten.

Hauptinhalt

Die neueste Version von Kubernetes, v1.34, bringt bedeutende Verbesserungen für die dynamische Ressourcenallokation (DRA). Diese Funktionalität ermöglicht es, spezialisierte Hardware und Infrastrukturressourcen effizient zu verwalten. Mit der Graduierung der DRA zum GA-Status wird eine stabile und langfristige Integration in Kubernetes gewährleistet. Die DRA-APIs sind nun standardmäßig aktiviert, was bedeutet, dass Benutzer und Entwickler von DRA-Treibern diese Funktion ohne vorherige Aktivierung nutzen können.

Kyverno vs. OPA – Richtlinienkontrolle für Kubernetes in regulierten Umgebungen

Sun, 31 Aug 2025 21:39:41 +0000

Kubernetes hat sich zum De-facto-Standard für den Betrieb cloud-nativer Anwendungen entwickelt. Doch mit seiner Flexibilität kommt auch eine enorme Komplexität. In hochregulierten Umgebungen – wie Finanzwesen, Gesundheitssektor oder öffentlicher Verwaltung – ist die sichere Nutzung von Kubernetes nur dann möglich, wenn Policies das Verhalten von Clustern, Workloads und Nutzern streng kontrollieren. Ohne solche Mechanismen drohen Compliance-Verstöße, Sicherheitslücken und unkontrollierte Abweichungen von internen Standards.

Zwei der bekanntesten Policy-Engines sind Kyverno und Open Policy Agent (OPA). Beide bieten Mechanismen, um Richtlinien in Kubernetes-Umgebungen durchzusetzen, unterscheiden sich jedoch erheblich in Philosophie, Usability und Integration. Dieser Beitrag beleuchtet die Unterschiede, zeigt Vor- und Nachteile in regulierten Umgebungen auf, und vergleicht die Eignung für kleine Teams sowie große Organisationen.

Spotify Backstage – Potenziale und Herausforderungen interner Developer-Plattformen

Sun, 31 Aug 2025 21:16:46 +0000

Interne Developer-Portale (Internal Developer Platforms, IDPs) sind seit einigen Jahren ein heißes Thema in der Softwareentwicklung. Unternehmen stehen vor der Herausforderung, komplexe Cloud-Native-Landschaften mit Microservices, APIs, Kubernetes-Clustern und einer Vielzahl von Tools zu managen. Entwicklerteams verlieren Zeit durch Kontextwechsel, unvollständige Dokumentationen und fragmentierte Toolchains. Genau hier setzt Spotify Backstage an – eine Open-Source-Plattform für Developer-Portale, die 2020 von Spotify veröffentlicht und inzwischen in die Cloud Native Computing Foundation (CNCF) eingebracht wurde.

Backstage verspricht: Zentralisierung, Transparenz und Self-Service für Entwicklerteams. Doch wie so oft steckt der Teufel im Detail. Backstage ist kein Plug-and-Play-Produkt, sondern eine Entwicklungsplattform, die erhebliche Investitionen in Anpassung und Wartung erfordert. Dieser Beitrag beleuchtet die Chancen und Risiken von Backstage umfassend, analysiert Vor- und Nachteile, stellt zentrale Features vor und bewertet den tatsächlichen ROI für Organisationen. Ziel ist eine realistische Einschätzung: Wann ist Backstage der richtige Weg – und wann sind andere Ansätze sinnvoller?

Souveräne Alternativen zu Hyperscalern – muss es immer eine andere "Cloud" sein?

Sun, 31 Aug 2025 17:30:34 +0000

Die Diskussion um Souveränität in der Cloud wird in Europa oft entlang der Frage geführt: Brauchen wir unsere eigenen Hyperscaler, um unabhängig zu sein? Viele sehen die Lösung in einer „europäischen Cloud", die AWS, Azure oder Google Cloud ersetzen soll. Aber die Realität ist deutlich komplexer – und in vielerlei Hinsicht pragmatischer. Denn die meisten Dienste, die Hyperscaler anbieten, basieren ohnehin auf bekannten Open-Source-Projekten. Der Unterschied liegt im Branding, in der Integration und im Pricing. Wer wirklich Souveränität anstrebt, muss nicht unbedingt einen neuen Hyperscaler bauen. Die eigentliche Alternative liegt näher: Kubernetes als Basis und offene Werkzeuge statt proprietärer „Cloud-Services".

Souveräne KI für Europa – das Problem mit der Lieferkette

Sun, 31 Aug 2025 17:24:07 +0000

Die europäische Debatte um „souveräne KI" wird oft auf die Ebene von Regulierung, Datenschutz und gesellschaftlicher Akzeptanz reduziert. Was dabei gerne übersehen wird: Souveränität in Künstlicher Intelligenz entscheidet sich nicht nur an Algorithmen oder Modellen, sondern ganz wesentlich an der Lieferkette der zugrundeliegenden Hardware. Ohne Chips, ohne GPUs, ohne die notwendige Infrastruktur ist jede Vision einer europäischen KI-Souveränität nicht mehr als eine akademische Übung. In diesem Beitrag möchte ich die realen Engpässe aufzeigen, die Europa auf diesem Weg blockieren, und gleichzeitig die Handlungsräume benennen, die bleiben. Es wird kein romantisches Plädoyer für Autarkie, sondern eine nüchterne Analyse von Abhängigkeiten, Marktmechanismen und industriepolitischen Optionen.

Kubernetes v1.34: Feinere Kontrolle über Container-Neustarts

Fri, 29 Aug 2025 18:30:00 +0000

TL;DR

Mit der Veröffentlichung von Kubernetes v1.34 wird eine neue alpha-Funktion eingeführt, die eine differenziertere Steuerung über Container -Neustarts innerhalb eines Pods ermöglicht. Die Funktion „Container Restart Policy and Rules“ erlaubt es, individuelle Neustartrichtlinien für jeden Container festzulegen und diese basierend auf den Exit-Codes der Container zu steuern.

Kubernetes v1.34 bringt eine bedeutende Verbesserung in der Handhabung von Container-Neustarts. Vor dieser Version war die Neustartpolitik auf Pod-Ebene festgelegt, was bedeutete, dass alle Container innerhalb eines Pods dieselbe Neustartpolitik (Always, OnFailure oder Never) teilten. Diese Einschränkung war in vielen Szenarien unpraktisch, insbesondere wenn unterschiedliche Anforderungen an die Container bestanden.

Kubernetes v1.34: Präzision, Sicherheit und Reife

Fri, 29 Aug 2025 08:22:17 +0000

Kubernetes v1.34: Präzision, Sicherheit und Reife

Kubernetes wächst weiter – mit Version 1.34 liegt jetzt das nächste große Release vor. 58 neue Features umfasst der Zyklus: 23 sind stabil, 22 Beta, 13 frisch als Alpha. Zahlen allein sagen wenig. Interessant ist, wie sich Kubernetes technisch entwickelt – und wohin die Reise geht.

Dynamic Resource Allocation wird stabil

Ein zentraler Fortschritt ist die jetzt stabile Dynamic Resource Allocation (DRA). Sie erlaubt es, GPUs, TPUs, Netzwerkkarten und andere Spezialressourcen flexibel im Cluster zu claimen. Damit werden parallele Workloads, KI-Training und HPC-Szenarien erheblich einfacher zu managen.

Kubernetes v1.34: Benutzerpräferenzen (kuberc) sind in kubectl 1.34 zum Testen verfügbar

Thu, 28 Aug 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 führt die Funktionalität der Benutzerpräferenzen in kubectl ein, die es ermöglicht, Standardoptionen und Aliase für Befehle zu definieren. Diese Funktion befindet sich in der Beta-Phase und bietet eine flexible Anpassung der Benutzererfahrung.

Hauptinhalt

Mit der Einführung von Kubernetes v1.34 wird die neue Funktion der Benutzerpräferenzen in kubectl vorgestellt, die es Nutzern ermöglicht, ihre Arbeitsumgebung individuell zu gestalten. Die Benutzerpräferenzen werden in einer Datei namens kuberc gespeichert, die standardmäßig im Verzeichnis $HOME/.kube zu finden ist. Alternativ kann der Speicherort über die Option --kuberc oder die Umgebungsvariable KUBERC definiert werden.

Datenbanken in Kubernetes – Alternativen zur Cloud-Hosted DB

Thu, 28 Aug 2025 12:25:21 +0000

Der Betrieb von Datenbanken in Kubernetes galt lange Zeit als riskant: Stateful Workloads, persistente Daten und Container-Orchestrierung schienen nicht zusammenzupassen. Heute ist die Lage eine andere. Durch spezialisierte Operatoren, optimierte Storage-Lösungen und bewährte Praktiken sind relationale und dokumentenbasierte Datenbanken inzwischen stabile Bausteine für Cloud-native Architekturen.

Während Hyperscaler wie AWS, Google oder Azure mit Cloud-hosted DBaaS-Angeboten (z. B. RDS, CloudSQL, CosmosDB) den Betrieb stark vereinfachen, bleiben Fragen offen: Vendor Lock-in, Souveränität, Compliance. Unternehmen, die volle Kontrolle und Flexibilität wünschen, setzen daher auf Self-Hosted Datenbanken in Kubernetes.

Kubernetes v1.34: Von Wind und Wille (O' WaW)

Wed, 27 Aug 2025 18:30:00 +0000

TL;DR

Kubernetes v1.34 bringt 58 Verbesserungen, darunter 23 stabile, 22 Beta- und 13 Alpha-Funktionen. Wichtige Neuerungen sind die dynamische Ressourcenallokation, verbesserte Sicherheitsmechanismen für ServiceAccount-Token und die Einführung von KYAML, einer neuen YAML-Dialekt für Kubernetes.

Hauptinhalt

Die Veröffentlichung von Kubernetes v1.34 stellt einen weiteren Schritt in der kontinuierlichen Weiterentwicklung der Plattform dar. Mit insgesamt 58 Verbesserungen, von denen 23 den Status “Stabil” erreicht haben, 22 in die Beta-Phase übergegangen sind und 13 als Alpha eingeführt wurden, zeigt sich die Stärke des Entwicklungszyklus und die Unterstützung durch die Community.

Observability in Kubernetes – Ein umfassender Vergleich

Wed, 27 Aug 2025 08:37:19 +0000

Kubernetes hat sich in den letzten Jahren zum Standard für den Betrieb containerisierter Anwendungen entwickelt. Mit der zunehmenden Verbreitung wächst auch die Notwendigkeit, Cluster und Applikationen transparent, nachvollziehbar und effizient zu überwachen. Observability – die Fähigkeit, den Zustand eines Systems aus externen Signalen wie Logs, Metriken und Traces zu rekonstruieren – ist dafür ein zentrales Konzept.

Dieser Artikel bietet eine fundierte Übersicht über Open-Source-Lösungen im Bereich Metrics- und Log-Monitoring, vergleicht ihre Stärken und Schwächen in Bezug auf Skalierbarkeit, Performance und Wartbarkeit und beleuchtet verschiedene Methoden zur Datenaufnahme. Ziel ist eine klare Orientierung für Architekten und Betriebsteams, die eine zukunftsfähige Observability-Strategie in Kubernetes aufbauen wollen.

Egress-Traffic Management in Kubernetes

Wed, 27 Aug 2025 08:16:48 +0000

Kubernetes bietet seit Jahren bewährte Mechanismen, um eingehenden Traffic in ein Cluster zu steuern. Ingress-Controller stellen ein definiertes „Nadelöhr" dar, über das Anfragen von außen eintreten und mit klaren Regeln – beispielsweise für Routing, TLS oder Authentifizierung – behandelt werden können. Für den ausgehenden Traffic, den sogenannten Egress-Traffic, ist die Lage jedoch weniger übersichtlich. Standardmäßig verlässt Egress-Traffic das Cluster über die Node, auf der der Pod läuft, der die Verbindung initiiert. Eine zentrale Kontrollinstanz, vergleichbar zum Ingress-Controller, gibt es nicht.

.NET in Kubernetes – geht das?

Wed, 27 Aug 2025 07:00:43 +0000

Spoiler-Alert: Ja, das geht – und es ist nicht nur möglich, sondern in vielen Enterprise-Umgebungen bereits Standard.

NET und Kubernetes – passt das zusammen?

Auf den ersten Blick wirkt es ungewöhnlich, eine ursprünglich stark Windows-geprägte Technologie im Linux-dominierten Kubernetes-Umfeld zu betreiben. In der Praxis hat Microsoft jedoch in den letzten Jahren gezielt darauf hingearbeitet, .NET plattformübergreifend einsetzbar zu machen. Seit der Einführung von .NET Core ist die Laufzeitumgebung vollständig auf Linux und macOS verfügbar und wird kontinuierlich für den Betrieb in Containern optimiert. Mit .NET 7 und .NET 8 legt Microsoft besonderen Fokus auf Performance, Ressourceneffizienz und Cloud-native Einsatzszenarien.

Von OTRS zu Zammad – 50.000 Tickets finden ein neues Zuhause

Tue, 26 Aug 2025 11:41:51 +0000

Der Wechsel von OTRS zu Zammad ist für viele Organisationen mehr als nur ein technisches Upgrade – es ist ein Schritt hin zu einer souveränen, modernen und hochverfügbaren Ticketing-Infrastruktur. In diesem Blogpost beschreiben wir detailliert, wie wir eine Migration von 50.000 Tickets von einer nicht-hochverfügbaren OTRS 6 Instanz auf eine in Kubernetes betriebene self-hosted Zammad-Instanz erfolgreich umgesetzt haben.

Wir gehen dabei sowohl auf die technischen Vorbereitungen ein, als auch auf Herausforderungen, Best Practices und konkrete Handlungsempfehlungen für alle, die eine ähnliche Reise planen.

Digitale Ohnmacht – Deutschland im Bann von Big Tech - Ein Film der ARD

Thu, 21 Aug 2025 08:14:12 +0000

Dass die Bundeswehr ihre Daten künftig in der Google Cloud speichert, ist kein IT-Projekt. Es ist ein sicherheitspolitischer Offenbarungseid. Genauso wie die Entscheidung, Peter Thiels Palantir direkten Zugriff auf deutsche Polizeidaten zu geben. Diese beiden Beispiele sind keine singulären Fehltritte – sie sind Ausdruck eines systemischen Versagens. Deutschland hat seine digitale Souveränität aufgegeben.

Strategielosigkeit als Prinzip

Statt eine kohärente digitale Strategie zu entwickeln, hat sich die Bundesregierung darauf beschränkt, amerikanische Hyperscaler zum Standard zu erheben. Cloud-Infrastruktur, Identitätsmanagement, Kommunikationsnetze, Cybersicherheit – fast alle kritischen Systeme werden strukturell von US-Konzernen getragen. Die Illusion, man habe damit „die besten Technologien" eingekauft, ersetzt jede geopolitische Analyse. Wer Daten in die Google Cloud legt, wer Palantir in polizeiliche Systeme integriert, entscheidet sich nicht für Effizienz, sondern für Abhängigkeit.

Microsoft schafft die klassischen Volumenlizenzen ab

Wed, 20 Aug 2025 07:50:27 +0000

Ab dem 1. November 2025 schafft Microsoft die klassischen Volumenlizenzen ab. Konkret betroffen sind die großen Lizenzmodelle Enterprise Agreement (EA) und Microsoft Products and Services Agreement (MPSA). Bisher konnten Unternehmen – je nach Abnahmemenge – Rabatte zwischen 6 und 12 Prozent auf den Listenpreis erhalten. Damit ist bald Schluss. Ab November fallen alle Kunden in die Preisstufe A – und zahlen damit den vollen Listenpreis, so wie er auf der Microsoft-Website steht.

Optimierung von Linux Swap für Kubernetes: Eine tiefgehende Analyse

Tue, 19 Aug 2025 18:30:00 +0000

TL;DR

Die bevorstehende Kubernetes Version v1.34 wird die NodeSwap-Funktion stabilisieren, die die Nutzung von Swap-Speicher auf Linux-Knoten ermöglicht. Diese Funktion zielt darauf ab, die Ressourcennutzung zu verbessern und Out-of-Memory (OOM)-Killer zu reduzieren. Eine korrekte Konfiguration der Linux-Kernel-Parameter ist entscheidend für die Leistung und Stabilität von Kubernetes-Clustern unter Speicherdruck.

Hauptinhalt

Die NodeSwap-Funktion in Kubernetes stellt einen bedeutenden Wandel in der Handhabung von Swap-Speicher dar, indem sie die herkömmliche Praxis, Swap zu deaktivieren, um die Leistung vorhersehbar zu halten, in Frage stellt. Durch die Aktivierung von Swap können Linux-Knoten zusätzlichen virtuellen Speicher nutzen, wenn der physische RAM erschöpft ist. Dies zielt darauf ab, die Ressourcenauslastung zu optimieren und die Häufigkeit von OOM-Kills zu verringern.

K3s on Flatcar via Ansible & vSphere: automatisiertes K8s für regulierte Umgebungen

Sun, 17 Aug 2025 19:17:38 +0000

In Branchen wie Industrie, Finanzwesen oder kritischen Infrastrukturen ist Automatisierung kein „Nice-to-have", sondern zwingende Notwendigkeit. Kubernetes ist längst etabliert – doch die Bereitstellung von Controlplanes in regulierten On-Premises-Umgebungen bleibt komplex.

Virtuelle Maschinen müssen auditierbar, reproduzierbar und sicher erzeugt werden. Standard-Templates mit Ubuntu oder CentOS sind oft schwer aktuell zu halten. Gleichzeitig erfordert Compliance die volle Kontrolle über Supply-Chain, Secrets und Netzwerkzugänge.

Ein Ansatz, der sich gerade für Edge, Test, Dev und auch Prod-Cluster in sensiblen Umgebungen anbietet: Flatcar Linux + k3s, vollautomatisch provisioniert über Ansible auf vSphere.

k3k: agent-less k3s in Kubernetes

Sun, 17 Aug 2025 18:44:33 +0000

Zusammenfassung in drei Punkten

Controlplane on demand: Mit k3k lässt sich eine vollwertige k3s-Controlplane als Kubernetes-Workload betreiben – ohne Agent-Knoten. Das ermöglicht blitzschnelles Spin-up/Down kompletter, valider k3s-Cluster für Tests, Mandanten oder Edge-Szenarien. (Hintergrund: agent-less servers sind ein Feature von k3s bei dem die Controlplane keine normale Node im Cluster ist, wie sonst üblich)
On-Prem turbo: Wo das Bereitstellen vollständiger VMs für jede Controlplane Stunden/Tage dauern kann, erzeugt k3k in Minuten reproduzierbare Umgebungen – ideal für End-to-End-Tests in CI, Multi-Tenant-K3s-Setups, Dev-Cluster und ressourcenlimitiertes Edge.
Kompatibel & offen: k3s ist ein leichtgewichtiges, CNCF-konformes Kubernetes mit ARM-Support; Helm bleibt der gewohnte Paketmanager. k3k nutzt das – mit Helm-Install, deklarativ, GitOps-freundlich.

k3k auf GitHub

Zero Trust Network Access (ZTNA) mit NetBird – Die Open-Source-Alternative

Sun, 17 Aug 2025 18:28:18 +0000

In einer Welt, in der Cloud-native Architekturen, remote Development und komplexe Multi-Cluster-Infrastrukturen zur Norm geworden sind, ist der klassische VPN-basierte Zugriff schlicht nicht mehr zeitgemäß. Zero Trust Network Access (ZTNA) ist nicht nur ein Trend, sondern eine Notwendigkeit: ein modernes Paradigma, bei dem niemals blind vertraut wird und jeder Zugriff explizit geprüft wird – unabhängig von Standort, Gerät oder Netzwerk.

In diesem Artikel erläutern wir:

Was ZTNA ist und wie es sich von traditionellen VPN-/Netzwerkzugriffen unterscheidet
Warum ZTNA unverzichtbar für sichere, cloud-native Software Delivery Pipelines ist
Vergleich zwischen etablierten branchenüblichen ZTNA-Anbietern und der Open-Source-Lösung NetBird
Warum wir bei ayedo auf NetBird setzen – Vorteile der OSS-Strategie
Technische Integration von ZTNA mit OIDC, Kubernetes & übergreifenden Netzwerkszenarien

Was ist ZTNA – und was macht es anders?

ZTNA basiert auf dem Grundprinzip „Never trust, always verify". Anders als VPNs, die klassischen Netzwerkzonen vertrauen, überprüft ZTNA jede Verbindung individuell – auch innerhalb des internen Netzwerks. Authentifizierung (oft OIDC-basiert), Gerätestatus, Kontext und Identität entscheiden, ob Zugriff gewährt wird – und nur auf genau die zulässigen Zielressourcen, nach dem Prinzip des Least Privilege. Dies wird häufig mit Termini wie „Software-Defined Perimeter (SDP)" oder „Secure Access Service Edge (SASE)" kombiniert. Hier einige Kernvorteile:

Artefakt-Management – Warum blindes Vertrauen in Public Artefakte gefährlich ist

Sun, 17 Aug 2025 17:52:25 +0000

Die unsichtbare Grundlage moderner Software

Cloud-native Software-Entwicklung baut auf einem Fundament auf, das in der Regel unsichtbar bleibt: Artefakte. Gemeint sind Docker Images, Helm Charts, Operator Packages und andere Bausteine, die in modernen Kubernetes-Workflows unverzichtbar sind. Fast jedes Projekt – von der kleinen API bis zur komplexen KI-Plattform – stützt sich auf diese Pakete. Doch wie stabil ist dieses Fundament wirklich, wenn man es aus der Community oder von Drittanbietern bezieht, ohne Absicherung, Spiegelung oder Governance?

Developer Platforms von ayedo: Maßgeschneidert, flexibel und zukunftsgerichtet

Sun, 17 Aug 2025 17:07:27 +0000

Developer Platforms von ayedo: Maßgeschneidert, flexibel und zukunftsgerichtet

Im Kern ermöglichen Developer Platforms Teams, Software sicher, effizient und automatisiert durch den gesamten Software Development & Delivery Lifecycle zu führen. Als Managed Service Provider für cloud‑native Plattformen gestaltet ayedo diese Plattformen nicht als starres Produkt, sondern als lebendige Infrastruktur, die auf die Bedürfnisse des Kunden genauso reagiert wie ein ausgefuchster GitOps-Pipeline.

Warum eine eigene Developer Platform?

Das Problem: Zersplitterte Tool-Landschaften und unklare Abläufe

In vielen Unternehmen arbeiten Entwicklungs- und Betriebsteams mit einer Vielzahl von Einzellösungen:

Governance & Security für KI-Entwicklungs-Teams: Cluster-Access & Secret Management in Kubernetes

Sun, 17 Aug 2025 16:59:23 +0000

Wie Unternehmen mit Tools wie Kyverno, Vault und Infisical ihre GPU-Kubernetes-Umgebungen sicher, compliant und effizient für KI-Entwicklung gestalten können.

Einleitung

KI-Workloads sind nicht nur rechenintensiv, sondern auch sicherheits- und compliance-sensibel. Während GPUs, MIG und Time-Slicing dafür sorgen, dass Ressourcen effizient genutzt werden, entstehen auf Governance-Ebene neue Fragen:

Wer darf wo deployen?
Wie werden Zugriffsrechte für Cluster und GPU-Ressourcen vergeben?
Wie werden Secrets (API-Keys, Tokens, Datenbank-Passwörter, Model-Registry-Credentials) verwaltet?
Wie wird verhindert, dass sensible Daten in Dev- oder Staging-Umgebungen unkontrolliert genutzt werden?

In unserem letzten Beitrag haben wir gezeigt, wie MIG und Time-Slicing GPU-Ressourcen für KI-Teams in Kubernetes verfügbar machen. Jetzt geht es um die Governance-Schicht darüber: Cluster-Access und Secret Management – die beiden zentralen Stellschrauben für Sicherheit und Compliance.

GPUs in Kubernetes: Praxisleitfaden für H100, MIG & Time‑Slicing

Sun, 17 Aug 2025 14:34:08 +0000

GPUs in Kubernetes: Praxisleitfaden für H100, MIG & Time‑Slicing

Wie du GPU‑Ressourcen sicher, effizient und cloud‑native für Entwicklung, Inferenz und Training bereitstellst – inklusive H100‑MIG und Time‑Slicing, YAML‑Beispielen und Betriebsrichtlinien.

TL;DR

Ja, eine einzelne GPU kann von mehreren Pods genutzt werden – entweder hardware‑isoliert via MIG (Multi‑Instance GPU) oder kooperativ via Time‑Slicing.
Entwickler fordern genau die GPU‑Größe an, die sie brauchen (z. B. nvidia.com/mig-3g.40gb: 1), erhalten planbare Performance und zahlen/verbrauch en nur, was sie nutzen.
Cloud‑native Patterns (GitOps, CI/CD, IaC, Rolling/Blue‑Green, Canary, Autoscaling, Multi‑Tenancy) funktionieren auch für GPU‑Workloads – wenn die Infrastruktur sauber modelliert ist.

Dieser Beitrag zeigt End‑to‑End, wie man Bare‑Metal‑Kubernetes (z.B. mit NVIDIA H100) produktionsreif betreibt, wie man MIG und Time‑Slicing sinnvoll kombiniert und welche Betriebs‑ und Governance‑Aspekte (Quotas, Labeling, Monitoring, Kostenkontrolle) entscheidend sind.

324 Millionen MagentaTV-Logs offen im Netz – was der Fall über Datensicherheit sagt

Wed, 13 Aug 2025 08:29:04 +0000

Die Zahlen sind beeindruckend – und beunruhigend: Über eine ungesicherte Elasticsearch-Datenbank waren 324 Millionen Logeinträge der Streaming-Plattform MagentaTV öffentlich zugänglich. Betroffen: Daten von geschätzt 4,4 Millionen Kunden.

Entdeckt wurde die Sicherheitslücke nicht intern, sondern von den Sicherheitsexperten von Cybernews. Die Datenbank gehörte nicht direkt der Deutschen Telekom, sondern dem französischen AdTech-Unternehmen Equativ und dessen Tochter Serverside.ai, das für MagentaTV die serverseitige Werbeausspielung übernimmt (Server-Side Ad Insertion, SSAI).

Welche Daten lagen offen?

Laut den Forschern enthielten die Logdateien:

Kira: Warum wir als Erste einen AI-Influencer einsetzen – und was das für ayedo bedeutet

Mon, 11 Aug 2025 09:40:48 +0000

Ein AI-Influencer ist kein Mensch, der spontan entscheidet, ob heute ein Video oder ein Post dran ist. Ein AI-Influencer ist eine digitale Persona, komplett konstruiert, immer verfügbar, niemals urlaubsreif, und in der Lage, in Sekunden hochwertigen Content zu produzieren. Genau das ist Kira. Sie wird für uns sprechen – über Cloud-Native-Technologien, AI- und Hosting-News, in Videos, Podcasts und auf LinkedIn.

Wir gehen mit Kira bewusst einen Schritt, den bisher kein Unternehmen in unserer Branche gewagt hat. Wir wollen nicht nur mitreden, wir wollen bestimmen, wie über dieses Thema gesprochen wird.

Einführung des Headlamp AI Assistenten

Thu, 07 Aug 2025 19:00:00 +0000

TL;DR

Der Headlamp AI Assistant ist ein neues Plugin für Headlamp, das die Verwaltung und Fehlersuche von Kubernetes Clustern erleichtert. Durch die Nutzung von großen Sprachmodellen ermöglicht es Benutzern, in natürlicher Sprache Fragen zu stellen und Aktionen durchzuführen, ohne tiefgehende Kubernetes-Kenntnisse zu benötigen.

Hauptinhalt

Der Headlamp AI Assistant wurde entwickelt, um die Interaktion mit Kubernetes zu vereinfachen und die Effizienz bei der Verwaltung von Clustern zu steigern. Benutzer können Fragen wie “Ist meine Anwendung gesund?” oder “Wie kann ich das beheben?” stellen, ohne sich mit komplexen technischen Details auseinandersetzen zu müssen. Das Plugin bietet eine kontextuelle Benutzeroberfläche, die es ermöglicht, relevante Informationen direkt aus der aktuellen Ansicht in Headlamp abzurufen.

Warum Helm der Standard für Kubernetes Apps ist

Wed, 06 Aug 2025 10:25:18 +0000

Kubernetes hat sich in den letzten Jahren vom Experimentierfeld zum De-facto-Standard für Cloud-native Anwendungen entwickelt. Die Flexibilität und Skalierbarkeit, die es bietet, sind beeindruckend – doch sie haben ihren Preis: eine deutlich gesteigerte Komplexität beim Management von Deployments, Konfigurationen und Releases. Wer ernsthaft Software auf Kubernetes betreibt oder ausliefert, steht früher oder später vor der Frage: Wie verpacke ich meine Anwendung so, dass sie reproduzierbar, wartbar und leicht integrierbar ist?

Zoll-Deal mit Trump: Das Saarland zahlt den Preis

Mon, 04 Aug 2025 06:46:22 +0000

Manchmal genügt ein einziger Satz, um die politische Realität in ihrer ganzen Bitterkeit offenzulegen. In diesem Fall lautet er: “Der Zoll-Deal mit den USA ist Schadensbegrenzung – zu einem sehr hohen Preis.” So kommentierte es jüngst Frank Thomé, Hauptgeschäftsführer der IHK Saarland. Und dieser Preis? Könnte im Saarland bis zu 17.000 Arbeitsplätze kosten.

Was wurde eigentlich beschlossen?

US-Präsident Donald Trump und EU-Kommissionspräsidentin Ursula von der Leyen haben Ende Juli ein Abkommen geschlossen, das auf den ersten Blick wie ein Befreiungsschlag wirken soll. Statt 30 % Einfuhrzölle auf europäische Produkte gibt es „nur" noch 15 % pauschal. Das klingt nach Erleichterung – bis man ins Kleingedruckte schaut.

Transatlantische Illusion – Wie Europa sich zum Daten- und Investitionslieferanten macht

Wed, 30 Jul 2025 08:15:04 +0000

Der Jubel über den jüngsten „Deal" zwischen der EU und Donald Trump wirkt wie eine makabre Inszenierung. Während Brüssel sich öffentlich für „Planungssicherheit in unsicheren Zeiten" feiert, verlagern sich die realen Machtverhältnisse weiter gen Westen – wirtschaftlich, technologisch, politisch. Man spricht von Partnerschaft, aber gemeint ist Unterwerfung.

1. Wirtschaftlich: Der Stahl wird verzollt, die Milliarden fließen

Ein kurzer Blick auf die Zahlen reicht, um die Schlagseite zu erkennen: 750 Milliarden Euro verpflichten die Europäer sich, in US-Energie zu investieren – also LNG, Öl und Uran. Dazu kommen weitere 600 Milliarden Euro, die ausgerechnet in die US-Wirtschaft fließen sollen, statt in unsere marode Infrastruktur oder digitale Souveränität. Gleichzeitig müssen europäische Exporte in die USA künftig mit 15 Prozent Zoll belegt werden – mit wenigen Ausnahmen. Für deutschen Stahl bleiben die 50 Prozent Strafzölle bestehen. Der „Erfolg" dieses Deals besteht also darin, dass Trump seine ursprüngliche Drohung von 30 Prozent pauschalem Zoll auf alles auf 15 Prozent reduziert hat. Ein fauler Deal, der Arbeitsplätze kostet und Produktionsstandorte gefährdet.

Palantir und die Polizei: Wie eine Überwachungssoftware zur Gefahr für Grundrechte wird

Mon, 28 Jul 2025 11:37:41 +0000

Palantir in Deutschland ist mehr als nur ein Softwareanbieter. Es ist das Symbol für einen stillen Wandel im Staat: Weg von demokratischer Kontrolle, hin zu datengetriebener Überwachung durch externe Tech-Konzerne. Und mittendrin – deutsche Innenministerien, die Millionen ausgeben für ein System, das sie weder verstehen noch kontrollieren.

400.000 Euro monatlich für ein nicht genutztes System

In Hessen wurde ein Vertrag mit Palantir Technologies abgeschlossen, der die Landesregierung rund 400.000 Euro pro Monat kostet – über fünf Jahre hinweg. Ohne öffentliche Ausschreibung. Ohne parlamentarische Kontrolle. Und ohne produktiven Einsatz. Denn die Einführung der Überwachungssoftware Gotham wurde gestoppt, nachdem das Bundesverfassungsgericht 2023 zentrale Regelungen für verfassungswidrig erklärt hatte.

Zölle, Stahlkriese, US-Abhänigkeit: Was der Trump-EU-Deal für Deutschland bedeutet

Mon, 28 Jul 2025 11:16:25 +0000

Es war ein langes Tauziehen – nun gibt es einen Deal. Die EU und die USA haben sich in letzter Minute auf einen Kompromiss im Zollkonflikt geeinigt. Was auf den ersten Blick wie ein geopolitischer Befreiungsschlag daherkommt, offenbart bei genauerem Hinsehen vor allem eines: Europa zahlt. Viel. Und nicht nur mit Geld.

Eine „Einigung", die teuer erkauft ist

Der neue Deal sieht vor, dass die ursprünglich angedrohten 30 % US-Zölle auf europäische Produkte abgewendet werden. Doch das ist kein Sieg – sondern der Preis für etwas anderes. Die EU akzeptiert nun einen pauschalen Einfuhrzoll von 15 % auf den Großteil ihrer Exporte in die USA. Für viele Güter – insbesondere Autos – bedeutet das eine Versechsfachung der bisherigen Zollsätze. Gleichzeitig bleibt der Zugang für US-Produkte in den europäischen Markt größtenteils zollfrei.

Kubernetes v1.34 Vorschau

Mon, 28 Jul 2025 00:00:00 +0000

TL;DR

Kubernetes v1.34 wird Ende August 2025 veröffentlicht und bringt zahlreiche Verbesserungen mit sich, darunter die stabile Version der dynamischen Ressourcenallokation, verbesserte Authentifizierung für Image-Pulls und eine neue Pod-Ersetzungsrichtlinie für Deployments. Diese Funktionen zielen darauf ab, die Effizienz und Sicherheit in Kubernetes–Umgebungen zu erhöhen.

Hauptinhalt

Die kommende Version von Kubernetes, v1.34, wird eine Vielzahl von neuen Funktionen und Verbesserungen enthalten, die darauf abzielen, die Benutzererfahrung und die Effizienz in Kubernetes-Clustern zu optimieren. Eine der bedeutendsten Neuerungen ist die dynamische Ressourcenallokation (Dynamic Resource Allocation, DRA), die eine flexible Handhabung von Geräten wie GPUs und benutzerdefinierter Hardware ermöglicht. DRA wird in dieser Version voraussichtlich den Status “stabil” erreichen. Die Implementierung basiert auf strukturierten Parametern, die eine Feinsteuerung der Geräteanfragen ermöglichen, und unterstützt eine Reihe von API-Typen, die eine zentrale Kategorisierung und vereinfachte Pod-Anfragen fördern.

Cloud First war gestern – Warum Europa endlich souverän digitalisieren muss

Wed, 23 Jul 2025 11:43:48 +0000

Die digitale Transformation galt lange als technisches Projekt: schneller, skalierbarer, effizienter. Wer sich früh in die Cloud wagte, galt als mutig, modern, progressiv. Heute, ein gutes Jahrzehnt später, müssen wir feststellen: Die Cloud ist längst kein reines Technologie-Thema mehr – sie ist auch eine politische Frage.

Vom Fortschritt zum Risiko

Was einst als Innovationsmotor gefeiert wurde, ist heute zur kritischen Infrastruktur geworden. Und kritische Infrastruktur verlangt nach Kontrolle. Nach dem Wissen, wo unsere Daten liegen. Nach der Sicherheit, wer darüber verfügt. Nach der Gewissheit, dass sie im Ernstfall nicht gegen uns verwendet werden kann.

ToolShell, SharePoint – und die Bequemlichkeit des Kontrollverlusts

Mon, 21 Jul 2025 11:50:46 +0000

Warum Sicherheitslücken nicht nur technische Risiken sind, sondern politische Entscheidungen provozieren sollten

Die neu entdeckte Sicherheitslücke CVE-2025-53770, in Fachkreisen unter dem Namen „ToolShell" bekannt, offenbart einmal mehr ein fundamentales Dilemma moderner IT: die wachsende Diskrepanz zwischen technischer Machbarkeit und strategischer Abhängigkeit. Betroffen ist diesmal Microsofts SharePoint – genauer gesagt die On-Premise-Versionen Enterprise Server 2016 und Server 2019. Die Cloud-Varianten? Natürlich nicht.

Und hier beginnt das eigentliche Problem.

Eine Lücke mit System – technisch, wirtschaftlich, strategisch

Die Lücke ermöglicht die Remote Code Execution via manipulierten HTTP-Requests. Ein Angreifer muss keinen Benutzer kompromittieren, keine Authentifizierung umgehen – ein gezielter Request reicht. Die Folge: Vollständiger Zugriff auf den Server, Diebstahl der ASP.Net Machine Keys, Persistenz durch gefälschte Tokens. Kritischer geht es kaum.

Sovereign Washing, jetzt auch unter Eid bestätigt.

Mon, 21 Jul 2025 08:54:45 +0000

Ein Offenbarungseid – und das im wahrsten Sinne des Wortes

Lange haben wir es vermutet, lange wurde es beschwichtigt, relativiert, in Whitepapers zerredet und in PR-Sprache verpackt. Jetzt liegt die Wahrheit auf dem Tisch – juristisch unangreifbar, glasklar, unumstößlich.

In einer Anhörung vor dem französischen Senat im Juni 2025 wurde Anton Carniaux, Head of Corporate, External & Legal Affairs bei Microsoft France, unter Eid befragt. Die zentrale Frage:

Kann Microsoft garantieren, dass keine Daten europäischer Nutzer ohne die Zustimmung nationaler Behörden an die US-Regierung weitergegeben werden?

Ein Jahr OZG 2.0: Die digitale Verwaltung wartet immer noch auf ihren Durchbruch

Fri, 18 Jul 2025 07:59:04 +0000

Ein Jahr nach Inkrafttreten des Onlinezugangsgesetzes 2.0 ist die Bilanz ernüchternd. Die großen Versprechen sind geblieben – spürbare Fortschritte für Bürger*innen und Verwaltungen hingegen kaum. Dabei liegt eine zentrale Lösung längst auf dem Tisch: Cloudnative Technologien. Das BSI selbst empfiehlt Containerisierung, Kubernetes und modulare Architekturen – nicht als Modeerscheinung, sondern als solide Grundlage für eine sichere, skalierbare und moderne Verwaltungsinfrastruktur.

Wir arbeiten seit Jahren mit diesen Technologien, in komplexen IT-Umgebungen, unter höchsten Sicherheitsanforderungen. Und wir sehen: Es funktioniert – wenn man den politischen Rahmen schafft, um es auch wirklich umzusetzen.

Post-Quanten-Kryptographie in Kubernetes

Fri, 18 Jul 2025 00:00:00 +0000

TL;DR

Die Einführung von Post-Quantum-Kryptographie (PQC) in Kubernetes markiert einen wichtigen Schritt in der Sicherstellung der Kommunikation in einer Ära, in der Quantencomputer zunehmend an Bedeutung gewinnen. Kubernetes v1.33 unterstützt standardmäßig hybride PQC-Mechanismen für TLS-Verbindungen, was eine proaktive Maßnahme gegen zukünftige Bedrohungen darstellt.

Hauptinhalt

Die Welt der Kryptographie steht vor einem Paradigmenwechsel durch die Entwicklung von Quantencomputern, die potenziell bestehende kryptographische Standards gefährden können. Post-Quantum-Kryptographie (PQC) umfasst Algorithmen, die als sicher gegen Angriffe sowohl von klassischen als auch von Quantencomputern gelten. Insbesondere könnte der Einsatz von Shor’s Algorithmus durch Quantencomputer weit verbreitete Public-Key-Kryptosysteme wie RSA und Elliptische Kurvenkryptographie (ECC) brechen, die die Grundlage für viele sichere Kommunikationsprotokolle, einschließlich TLS, bilden.

Der digitale Ausverkauf Europas – Und wir zahlen auch noch dafür!

Fri, 11 Jul 2025 08:44:16 +0000

70 % der europäischen Unternehmen halten ihre Abhängigkeit von nicht-europäischer Technik für zu hoch. Das ist kein Bauchgefühl, sondern das Ergebnis des aktuellen „State of Cybersecurity Report 2025" von HarfangLab. Ein Weckruf. Und doch läuft der Großteil unseres Datenverkehrs weiterhin dorthin, wo unsere Gesetze enden: in US-amerikanische Rechenzentren, betrieben von Plattformen, die mehr mit Börsenkursen und geopolitischen Interessen gemein haben als mit europäischer IT-Realität.

Wenn Abhängigkeit zur Gefahr wird

Hyperscaler wie Microsoft, Amazon oder Google versprechen Sicherheit, Innovation und Skalierbarkeit. Was sie nicht versprechen: Rechtssicherheit im Sinne europäischer Datenschutzgesetze. Der CLOUD Act erlaubt US-Behörden Zugriff auf sämtliche Daten, die von US-Anbietern gespeichert werden – auch dann, wenn sich die Server physisch in der EU befinden. Diese extraterritoriale Reichweite steht in eklatantem Widerspruch zur DSGVO und zur Idee der digitalen Selbstbestimmung.

Support-Ende für Windows 10: Warum jetzt der richtige Zeitpunkt ist, sich von Hyperscalern zu lösen

Thu, 10 Jul 2025 11:49:59 +0000

Am 14. Oktober 2025 endet der reguläre Support für Windows 10. Was für viele IT-Abteilungen zunächst wie ein kalkulierbares Wartungsdatum klingt, entpuppt sich bei genauerem Hinsehen als strategische Zäsur. Microsoft bietet zwar eine einjährige „Extended Security Updates"-Phase (ESU) an, doch die Bedingungen dafür lassen tief blicken – und eröffnen Unternehmen eine grundsätzliche Frage: Wie abhängig wollen wir eigentlich noch sein?

Die Gnadenfrist – mehr Symbolik als Service

Mit dem ESU-Modell verspricht Microsoft, auch nach Support-Ende noch sicherheitskritische Updates für Windows 10 bereitzustellen. Privatnutzer haben drei Möglichkeiten zur Teilnahme:

Hyperscaler-Wahn in Deutschland: teuer, bindend und rechtlich fahrlässig

Wed, 09 Jul 2025 11:28:06 +0000

Wer sich nüchtern anschaut, wie die durchschnittliche IT-Infrastruktur in deutschen Unternehmen aussieht, wird feststellen: Der technologische Bedarf ist in den meisten Fällen überschaubar. Active Directory, SQL-Datenbanken, ein ERP-System, ein paar virtuelle Maschinen und eine E-Mail-Infrastruktur, die seit über einem Jahrzehnt zuverlässig ihren Dienst tut – das ist die Realität im industriellen Mittelstand, im Gesundheitswesen, bei Energieversorgern und in Behörden.

Was diese Landschaften jedoch nicht benötigen, sind hyperskalierende Plattformen mit globalem CDN, Dutzenden Regionen, Serverless-Funktionen, BigQuery-Engines und GPU-Farmen auf Zuruf. Und dennoch laufen genau diese Szenarien: Unternehmen buchen Infrastruktur bei AWS, Microsoft Azure oder Google Cloud – und zahlen, als würden sie die nächste Streamingplattform mit 100 Mio. Nutzern skalieren.

US-Druck auf die EU: Verwässert Brüssel den Digital Markets Act?

Tue, 08 Jul 2025 10:49:52 +0000

Die Europäische Union feierte sich selbst als Pionierin in der Regulierung digitaler Plattformen. Mit dem Digital Markets Act (DMA) wollte sie ein Zeichen setzen: Gegen marktbeherrschende Tech-Konzerne, für mehr Wettbewerb, Datenkontrolle und Transparenz. Der DMA trat im März 2024 in Kraft – doch kaum ein Jahr später steht genau diese europäische Regulierung offenbar zur Disposition. Und zwar nicht etwa aus Brüssel selbst, sondern aus Washington.

Was ist passiert?

Wie die Süddeutsche Zeitung und das Handelsblatt berichten, verhandelt die EU-Kommission im Rahmen eines neuen transatlantischen Handelsabkommens mit den USA nicht nur über Zölle, sondern auch über die Umsetzung des DMA. Laut übereinstimmenden Quellen soll es Überlegungen geben, die Regeln „flexibler" anzuwenden – sogar ein gemeinsamer Ausschuss wird diskutiert, in dem die USA Einfluss auf die Anwendung europäischer Gesetze nehmen könnten.

Catch Me If You Can: Was der Fall Soham Parekh über moderne Tech-Startups verrät

Mon, 07 Jul 2025 11:26:43 +0000

Ein Softwareentwickler, 22 parallele Arbeitsverhältnisse, ein Skandal: Der Fall Soham Parekh liest sich wie ein Drehbuch für die Fortsetzung von “Catch Me If You Can”. Nur diesmal nicht mit gefälschten Schecks und Pilotenuniformen, sondern mit GitHub-Profilen, Remote-Jobs und einem erstaunlichen Mangel an Kontrolle.

Parekh, ein talentierter Entwickler aus Indien, hat über Monate hinweg bei mehr als zwanzig KI-Startups gleichzeitig angeheuert. Die meisten davon: junge Y-Combinator-Startups mit großem Funding und noch größerem Druck, schnell zu liefern. Seine Strategie: Vorstellungsgespräche meistern, Überzeugung durch Oberflächenkönnen, dann untertauchen. Kaum Commits, viele Ausreden, noch mehr Auszahlungen.

Herausforderungen und Lösungen: So meistern Sie Geräteausfälle in Kubernetes-Pods

Sun, 06 Jul 2025 02:00:00 +0000

Kubernetes ist der De-facto-Standard für die Container-Orchestrierung, aber wenn es um den Umgang mit spezialisierter Hardware wie GPUs und anderen Beschleunigern geht, wird es kompliziert. In diesem Blogbeitrag werfen wir einen Blick auf die Herausforderungen bei der Verwaltung von Ausfällen, wenn Pods mit Geräten in Kubernetes betrieben werden. Diese Erkenntnisse basieren auf dem Vortrag von Sergey Kanzhelev und Mrunal Patel auf der KubeCon NA 2024. Sie können die Präsentation und die Aufzeichnung einsehen.

Produkt-Update bei Loopback:

Thu, 03 Jul 2025 11:13:40 +0000

Neue Features für mehr Kontrolle, Sicherheit und Flexibilität

Am 1. Juli hat unsere Schwesterfirma Loopback ein umfangreiches Update ihrer Cloud-Plattform veröffentlicht – ein bedeutender Schritt in Richtung noch leistungsfähigerer, sicherer und nutzerfreundlicher Kubernetes-Infrastrukturen. Ob neue Speicheroptionen, verbesserte Verwaltungsfunktionen oder gezielte UI-Optimierungen: Das Release adressiert zentrale Anforderungen moderner IT-Teams.

Object Storage: Datenhaltung neu gedacht

Mit der Einführung von Object Storage erweitert Loopback seine Plattform um ein essenzielles Feature für cloudnative Anwendungen:

Fortschritt durch Klarheit:

Thu, 03 Jul 2025 10:04:37 +0000

Wie der KI-Service Desk der Bundesnetzagentur Unternehmen in die Zukunft begleitet

Die europäische KI-Verordnung (AI Act) ist ein Meilenstein: Sie schafft erstmals einen einheitlichen Rechtsrahmen für die Entwicklung und Nutzung Künstlicher Intelligenz in der EU. Ziel ist es, Innovationen zu ermöglichen und gleichzeitig Risiken für Gesellschaft, Wirtschaft und Grundrechte zu minimieren. Doch die Umsetzung dieser komplexen Regelung stellt Unternehmen vor erhebliche Herausforderungen. Genau hier setzt der neue KI-Service Desk der Bundesnetzagentur an.

Kubernetes als Schlüsseltechnologie für die OZG-Umsetzung im Saarland

Thu, 03 Jul 2025 07:37:24 +0000

Die digitale Verwaltung im Saarland steckt fest. Nur 29 % der Verwaltungsleistungen wurden laut Bitkom Länderindex im Rahmen des Onlinezugangsgesetzes (OZG) digital umgesetzt – letzter Platz im Bundesvergleich. Dabei mangelt es nicht an Fachkräften: Der Anteil von Informatik-Auszubildenden und -Studierenden ist überdurchschnittlich. Woran scheitert es also?

Ein Grund ist technischer Natur: Die Verwaltungs-IT im Saarland basiert vielerorts auf veralteten monolithischen Architekturen. Neue Dienste lassen sich kaum integrieren, Skalierung ist komplex, und die Wiederverwendbarkeit bestehender Komponenten bleibt aus. Genau hier kommt Kubernetes ins Spiel – als Basis für moderne, containerisierte Verwaltungsplattformen.

Fehlerbehandlung in Pods mit Devices

Thu, 03 Jul 2025 00:00:00 +0000

TL;DR

Kubernetes steht vor Herausforderungen bei der Verwaltung von Pods, die spezialisierte Hardware wie GPUs nutzen, insbesondere im Kontext von AI/ML-Workloads. Die statische Sichtweise von Kubernetes auf Ressourcen und unzureichende Unterstützung für Hardwarefehler führen zu komplexen Fehlermodi, die die Leistung und Zuverlässigkeit beeinträchtigen können. Trotz dieser Herausforderungen bleibt Kubernetes aufgrund seiner Reife und des umfangreichen Ökosystems die bevorzugte Plattform für AI/ML-Anwendungen.

Hauptinhalt

Kubernetes hat sich als der Standard für die Container-Orchestrierung etabliert, doch die Handhabung spezialisierter Hardware wie GPUs und anderer Beschleuniger bringt neue Herausforderungen mit sich. Insbesondere die Zunahme von AI/ML-Workloads hat die Komplexität im Umgang mit Hardwarefehlern erhöht. Diese Workloads sind stark von spezialisierter Hardware abhängig, und ein Ausfall eines Geräts kann erhebliche Leistungseinbußen und Unterbrechungen verursachen. Studien zeigen, dass Hardwareprobleme, insbesondere GPU-Ausfälle, eine häufige Ursache für Störungen im Training von AI/ML-Modellen sind.

Nur 29 % OZG-Umsetzung im Saarland: Wie konnte es so weit kommen?

Wed, 02 Jul 2025 08:53:43 +0000

Das Saarland belegt im aktuellen Bitkom Länderindex 2024 den letzten Platz in der Kategorie “digitale Verwaltung”. Nur 29 % der im Onlinezugangsgesetz (OZG) geforderten digitalen Verwaltungsleistungen wurden umgesetzt. Zum Vergleich: Spitzenreiter Hamburg kommt auf 63 %, der Länderdurchschnitt liegt bei etwa 50 %. Die Bilanz für das Saarland ist ernüchternd – und wirft grundsätzliche Fragen zur digitalen Strategie des Landes auf.

Was sagen die Zahlen?

Hier die Platzierungen des Saarlands im Vergleich zu anderen Bundesländern laut Bitkom Index 2024:

Kompatibilität von Container-Images: Ein Schlüssel zur Zuverlässigkeit in Cloud-Umgebungen

Sat, 28 Jun 2025 02:00:00 +0000

In Branchen, in denen Systeme äußerst zuverlässig laufen müssen und strenge Leistungsanforderungen bestehen, wie beispielsweise in der Telekommunikation, Hochleistungs- oder KI-Computing, benötigen containerisierte Anwendungen oft spezifische Betriebssystemkonfigurationen oder Hardware. Es ist gängige Praxis, bestimmte Versionen des Kernels, dessen Konfiguration, Gerätetreiber oder Systemkomponenten zu verlangen.

Trotz der Existenz der Open Container Initiative (OCI), einer Gemeinschaft, die Standards und Spezifikationen für Container-Images definiert, gab es eine Lücke in der Ausdrucksweise solcher Kompatibilitätsanforderungen. Die Notwendigkeit, dieses Problem anzugehen, führte zu unterschiedlichen Vorschlägen und letztlich zu einer Implementierung im Kubernetes-Projekt Node Feature Discovery (NFD).

Nextcloud & IONOS fordern Microsoft heraus

Wed, 25 Jun 2025 11:43:10 +0000

Warum diese Allianz ein Wendepunkt für Europas digitale Selbstbestimmung ist

Die Schlagzeile liest sich unspektakulär, ihr Inhalt ist es nicht: Zwei deutsche Tech-Unternehmen schließen sich zusammen, um eine europäische Alternative zu Microsoft 365 zu entwickeln. Was nüchtern klingt, ist in Wahrheit ein klares politisches, wirtschaftliches und technologisches Signal.

Nextcloud und IONOS gehen gemeinsam den nächsten Schritt – und setzen damit ein deutliches Zeichen für digitale Souveränität in Europa. Keine Worthülse, kein Marketinglabel, keine Pseudo-Garantien, sondern: Kontrolle. Verbindlichkeit. Verantwortung.

Sovereign Washing 2.0

Wed, 25 Jun 2025 11:36:58 +0000

Was Microsofts neue Sovereign Cloud wirklich bedeutet – und was nicht

Microsoft hat geliefert. Zumindest auf den ersten Blick.

Mit der aktualisierten Sovereign-Cloud-Roadmap vom Juni 2025 antwortet der Konzern auf geopolitische Spannungen, europäische Datenschutzanforderungen und wachsenden regulatorischen Druck. Neue Produkte wie „Data Guardian", „EU Data Boundary" oder „Microsoft 365 Local" sollen Kontrolle und Transparenz für europäische Kunden schaffen.

Die Botschaft ist klar: Ihr könnt uns wieder vertrauen.

Die Realität: Ihr müsst es weiterhin.

Drei Wochen ayedo – mein Schülerpraktikum im Brand-Team

Wed, 25 Jun 2025 09:32:04 +0000

von Leon, 8. Klasse

Ich war drei Wochen bei ayedo – und ganz ehrlich: Das Praktikum war viel besser, als ich es mir vorgestellt hatte. Ich habe nicht einfach nur zugeschaut, sondern richtig mitgemacht. Vom ersten Tag an war ich Teil des Brand-Teams, also dem Bereich, der sich bei ayedo um alles Kreative kümmert – von Social-Media-Posts bis zu Videoproduktionen.

Was mich überrascht hat: Ich wurde ernst genommen. Ich durfte meine eigenen Ideen einbringen, Inhalte mitgestalten und war direkt im Geschehen dabei.

Gigafabrik ohne Gigavisionskraft?

Wed, 25 Jun 2025 09:20:19 +0000

Wie SAP sich aus der Verantwortung stiehlt – und was das über den Zustand der deutschen Tech-Industrie verrät

Am 21. Juni 2025 veröffentlichte der Tagesspiegel einen Artikel mit dem Titel „Deutsche Konzerne uneins – kein gemeinsames Angebot für KI-Gigafabrik". Er beschreibt ein Vorhaben der EU-Kommission, das eigentlich Grund zur Aufbruchsstimmung sein könnte: Bis zu sechs sogenannte „KI-Gigafactories" sollen entstehen – also leistungsstarke Rechenzentren, auf denen künftig europäische Modelle für Künstliche Intelligenz trainiert werden können. Eine dieser Fabriken soll nach Deutschland kommen. Und die EU zeigt sich großzügig: Mit bis zu 35 Prozent sollen die Milliardenkosten öffentlich gefördert werden.

Bildkompatibilität in Cloud Native Umgebungen

Wed, 25 Jun 2025 00:00:00 +0000

TL;DR

In Cloud-Native-Umgebungen ist die Bildkompatibilität von entscheidender Bedeutung, insbesondere für containerisierte Anwendungen mit spezifischen Hardware- und Betriebssystemanforderungen. Die Initiative zur Bildkompatibilität im Open Container Initiative (OCI) Rahmenwerk zielt darauf ab, Standardisierungen für die Kompatibilität von Container-Images zu schaffen, um die Bereitstellung und Verwaltung von Workloads in heterogenen Umgebungen zu optimieren.

Hauptinhalt

In Bereichen wie Telekommunikation, Hochleistungs- oder KI-Computing müssen containerisierte Anwendungen oft spezifische Anforderungen an das Betriebssystem oder die Hardware erfüllen. Die Verwendung bestimmter Kernel-Versionen, Konfigurationen, Gerätetreiber oder Systemkomponenten ist gängig. Trotz der Existenz der Open Container Initiative (OCI), die Standards für Container-Images definiert, besteht eine Lücke in der Darstellung dieser Kompatibilitätsanforderungen.

Public Relations

Mon, 23 Jun 2025 21:57:06 +0000

Systemfehler Identität: Warum 16 Milliarden geleakte Logins ein Weckruf sind

Fri, 20 Jun 2025 09:06:51 +0000

Ein Sicherheitsvorfall ist dann systemisch, wenn er sich wiederholt, skaliert und normalisiert.

Das aktuelle Datenleck mit über 16 Milliarden kompromittierten Zugangsdaten erfüllt alle drei Kriterien – und zeigt unmissverständlich: Wir haben ein strukturelles Problem im Umgang mit digitaler Identität. Und es betrifft uns alle.

Was passiert ist – und was nicht

Die Sicherheitsforscher von Cybernews haben offengelegt, was wohl der größte Credential-Leak aller Zeiten ist. Nicht recycelte Altdaten, sondern neue, mit Malware abgefangene Login-Informationen: Nutzernamen, Passwörter, Ziel-URLs – gebrauchsfertig und automatisiert auswertbar.

Kubernetes kann Freiheit - wenn man es richtig macht.

Tue, 17 Jun 2025 09:09:46 +0000

Warum Managed Kubernetes bei Hyperscalern nicht zur digitalen Souveränität führt

Kubernetes hat sich als De-facto-Standard für die Orchestrierung containerisierter Anwendungen etabliert. Es verspricht Portabilität, Skalierbarkeit und eine einheitliche Steuerung komplexer IT-Umgebungen. Doch viele Unternehmen nutzen Kubernetes auf eine Weise, die genau das untergräbt, was es eigentlich leisten soll: Unabhängigkeit.

Managed-Kubernetes-Angebote wie Amazon EKS oder Azure AKS wirken auf den ersten Blick bequem. Sie nehmen den Betrieb ab, liefern Integrationen in die jeweilige Plattform und versprechen ein Rundum-sorglos-Paket. Tatsächlich aber verschieben sie zentrale Kontrollfunktionen aus dem Einflussbereich des Unternehmens heraus. Der vermeintliche Komfort wird mit massiver Abhängigkeit erkauft.

Sovereign Washing - Ein Microsoft-Marketing-Märchen aus Redmond

Mon, 16 Jun 2025 17:28:16 +0000

Satya Nadella stellte in Amsterdam ein neues „Souveränitätsprogramm" für europäische Microsoft-Kunden vor. Drei Cloudmodelle, Hardware-Sicherheitsmodule (HSMs), europäischer Support und Partner wie Utimaco sollen Vertrauen schaffen. Was wie eine europäische Sicherheits-Offensive klingt, ist bei näherem Hinsehen eine ausgefeilte PR-Strategie zur Beruhigung eines zunehmend misstrauischen Marktes – und ein Ablenkungsmanöver von der eigentlichen Bedrohung: dem US-amerikanischen CLOUD Act.

CLOUD Act: Der Elefant im Serverraum

Seit 2018 verpflichtet der CLOUD Act alle US-Unternehmen – also auch Microsoft –, Daten an US-Behörden herauszugeben, selbst wenn diese in Rechenzentren außerhalb der USA gespeichert sind. Die juristische Logik: Der Sitz der Firma zählt, nicht der Speicherort. Und: Diese Herausgabe kann auch ohne richterliche Anordnung erfolgen. Noch problematischer: Unternehmen ist es verboten, ihre Kunden über diese Zugriffe zu informieren – eine sogenannte „Gag Order".

Änderungen an Kubernetes Slack

Mon, 16 Jun 2025 00:00:00 +0000

TL;DR

Die Kubernetes-Community wird am 20. Juni 2025 von einem spezialisierten Slack-Arbeitsbereich auf einen Standard-Gratis-Slack umgestellt. Diese Änderung bringt Einschränkungen bei der Speicherdauer von Nachrichten und der Nutzung von Apps mit sich. Eine Migration zu Discord wird als mögliche neue Plattform in Betracht gezogen.

Hauptinhalt

Die Kubernetes-Community steht vor einer bedeutenden Veränderung in der Kommunikationsinfrastruktur. Ab dem 20. Juni 2025 wird der derzeitige Slack-Arbeitsbereich, der über ein kostenloses, angepasstes Unternehmenskonto verfügt, auf einen Standard-Gratis-Slack umgestellt. Diese Entscheidung wurde von Salesforce getroffen, da das Unternehmen die Unterstützung für den speziellen Status der Kubernetes-Community nicht länger aufrechterhalten kann. Die Kubernetes-Slack-Instanz gehört zu den größten und aktivsten auf der Plattform, was zu einer Überlastung der verfügbaren Ressourcen geführt hat.

Vibecoding kills Software. KI verstärkt, was du kannst - oder nicht kannst.

Fri, 13 Jun 2025 08:25:01 +0000

Alle schreiben jetzt Software mit KI. Prompt rein, Code raus. Ein paar Zeilen Typescript hier, ein Dockerfile da, und am Ende fliegt alles irgendwie. Die Leute fühlen sich produktiv. Weil sie Output haben.

Was keiner fragt: Verstehst du eigentlich, was da passiert?

Denn das ist der Unterschied:

Erfahrene Entwickler:innen nutzen KI wie ein Präzisionswerkzeug.

Alle anderen bauen damit Software, die nur auf Stacktrace und Hoffnung basiert.

Prompt != Architektur

Die KI kann Code generieren. Aber sie kennt dein System nicht.

Struktur statt Chaos - Unser Weg zum IMS

Fri, 13 Jun 2025 08:17:35 +0000

Cyber-Risiken nehmen zu. Anforderungen steigen. Und wer als IT-Dienstleister ernst genommen werden will, braucht mehr als gute Technik. Wir bei ayedo haben früh gemerkt: Wachsen ohne Struktur funktioniert nicht. Sicherheit, Qualität und Effizienz entstehen nicht von selbst – sie brauchen ein belastbares Fundament.

Für uns heißt das: ein integriertes Managementsystem (IMS), das nicht nur der ISO genügt, sondern dem Alltag standhält.

ISO 27001 war unser Wendepunkt

Angefangen hat alles nicht mit einem Plan – sondern mit offenen Fragen:

Container nativ auf dem Mac: Apple macht ernst

Fri, 13 Jun 2025 07:26:43 +0000

Mit der Ankündigung von macOS 26 („Tahoe") stellt Apple die Karten im DevOps-Umfeld leise, aber grundlegend neu. Erstmals bringt das Betriebssystem einen nativen Support für Linux-Container mit – ohne Docker, ohne Orbstack, ohne zusätzliche Abhängigkeiten. Ein Schritt, der nicht nur technische Reibung reduziert, sondern das Potenzial hat, den Mac neu zu positionieren: Als vollwertige, systemnahe Entwicklungsumgebung für Cloud-native Workflows.

Was ist neu?

Apple integriert mit macOS 26 ein eigenes Containerization-Framework direkt ins Betriebssystem. Es basiert auf einer Open-Source-Basis, wurde speziell für Apple Silicon optimiert und erlaubt die Ausführung von OCI-konformen Linux-Containern – direkt über das Terminal. Die Lösung nutzt eine leichtgewichtige VM im Hintergrund, ist sicher isoliert und kommt ohne Docker Engine oder vergleichbare Layer aus.

Vendor Lock-in – Wenn Architektur zur Abhängigkeit wird

Wed, 11 Jun 2025 10:17:40 +0000

Vendor Lock-in bezeichnet die technisch, wirtschaftlich oder rechtlich eingeschränkte Fähigkeit, einen IT-Dienstleister oder Plattformanbieter ohne erheblichen Aufwand zu wechseln.

Anders gesagt: Du könntest in der Theorie gehen – aber praktisch ist es keine Option mehr.

Diese Abhängigkeit entsteht nicht über Nacht. Sie wächst schleichend.

Ein Managed Service hier, ein Auth-System dort, etwas Monitoring, ein wenig IAM. Alles greift ineinander, alles funktioniert reibungslos. Bis du irgendwann feststellst: Dein gesamter Stack ist untrennbar mit genau einem Anbieter verbunden.

Netzneutralität – das unsichtbare Rückgrat digitaler Fairness

Wed, 11 Jun 2025 09:59:50 +0000

Netzneutralität bedeutet: Alle Daten im Internet werden gleich behandelt. Punkt.

Es spielt keine Rolle, ob sie von einem Konzern, einem Forschungslabor, einem gemeinnützigen Projekt oder einem Startup stammen. Der Transportweg muss blind sein. Keine Paketpriorisierung, keine künstliche Verlangsamung, keine selektive Durchleitung.

Dieses Prinzip klingt selbstverständlich, ist es aber längst nicht mehr.

Infrastrukturanbieter erkennen, wie viel Macht in der Datenleitung selbst liegt. Wer die Leitung kontrolliert, kann bestimmen, welcher Dienst wann und wie „funktioniert". Technisch lässt sich diese Macht sehr fein dosieren – durch Bandbreitenzuweisung, Routingpräferenzen, Paketfilterung, Protokollpriorisierung.

Was bedeutet eigentlich „Digitale Souveränität" – ganz konkret?

Wed, 11 Jun 2025 09:47:17 +0000

Digitale Souveränität bezeichnet die Fähigkeit einer Organisation, ihre digitalen Systeme, Datenflüsse und technischen Abhängigkeiten so zu steuern, dass sie unabhängig, handlungsfähig und sicher bleibt – gegenüber Marktkräften, Infrastrukturbetreibern und fremden Rechtsräumen.

Dabei geht es nicht nur um Datenschutz oder Hostingstandorte. Digitale Souveränität ist ein Zusammenspiel aus technischer Architektur, rechtlicher Kontrolle und betrieblicher Selbstbestimmung.

Sie beantwortet Fragen wie:

Wer kontrolliert meine Systemzugänge?
Wer betreibt die Control Plane meiner Cloud-Umgebung?
Wer kann auf meine Logs, Traces und Konfigurationsdaten zugreifen?
Wer entscheidet, welche APIs wann veralten?
Wer ist im Ernstfall handlungsfähig – ich, oder mein Provider?

Digitale Souveränität heißt nicht, alles selbst zu bauen. Es heißt, jederzeit bewusst entscheiden zu können, was man selbst kontrolliert – und wo man Verantwortung abgibt.

Verbesserung des Kubernetes Event Managements durch benutzerdefinierte Aggregation

Tue, 10 Jun 2025 00:00:00 +0000

TL;DR

Kubernetes-Events sind entscheidend für das Management von Clustern, aber ihre hohe Anzahl und begrenzte Aufbewahrungszeit erschweren die Analyse. Ein benutzerdefiniertes Aggregationssystem kann helfen, Ereignisse zu kategorisieren, zu korrelieren und zu speichern, was die Fehlersuche und Systemzuverlässigkeit erheblich verbessert.

Hauptinhalt

In Kubernetes-Clustern werden Ereignisse für verschiedene Operationen generiert, darunter Pod-Scheduling, Containerstarts und Netzwerkkonfigurationen. Diese Ereignisse sind essenziell für das Debugging und Monitoring, jedoch treten in Produktionsumgebungen mehrere Herausforderungen auf. Große Cluster erzeugen oft Tausende von Ereignissen pro Minute, während die standardmäßige Aufbewahrungszeit auf eine Stunde begrenzt ist. Zudem werden verwandte Ereignisse nicht automatisch verknüpft, und es fehlen standardisierte Klassifizierungen bezüglich Schweregrad oder Kategorie. Ähnliche Ereignisse werden ebenfalls nicht automatisch gruppiert.

Hyperscaler oder Hylascaler? Wie aus simplen Services teure Plattform-Abhängigkeiten werden.

Sun, 08 Jun 2025 10:10:34 +0000

Cloud-Infrastruktur hat ihre Berechtigung. Skalierbarkeit, Automatisierung, Globalisierung von IT-Ressourcen sind längst Standard. Technisch liefern die großen Plattformanbieter — AWS, Google Cloud, Azure — ohne Zweifel stabile Basistechnologie.

Aber das Problem fängt dort an, wo Kunden glauben, sie würden sich nur Infrastruktur einkaufen. In Wahrheit kaufen sie Geschäftsmodelle. Mit unserer Enterprise Cloud und Private Cloud bieten wir Alternativen, die Ihnen die volle Kontrolle über Ihre Infrastruktur zurückgeben.

Der Vergleich: Cloud verkauft wie ein Hyla-Staubsauger

Der Hyperscaler verkauft nicht das, was der Kunde eigentlich braucht. Der Kunde will einen Staubsauger. Der Hyperscaler verkauft das gesamte Ökosystem drumherum: Wasserfiltersystem, Luftbefeuchter, Allergiker-Zertifikate, Lifetime-Servicevertrag, Schulungsprogramme, Service-Inspektionen.

Neue Wege im KI-Management: Die Gateway API Inference Extension

Sun, 08 Jun 2025 02:00:00 +0000

Moderne generative KI- und große Sprachmodelle (LLMs) stellen Kubernetes vor einzigartige Herausforderungen im Datenverkehrsmanagement. Im Gegensatz zu typischen kurzlebigen, zustandslosen Webanfragen sind LLM-Inferenzsitzungen oft langwierig, ressourcenintensiv und teilweise zustandsbehaftet. Beispielsweise kann ein einzelner GPU-unterstützter Modellserver mehrere Inferenzsitzungen aktiv halten und gespeicherte Token im Arbeitsspeicher verwalten.

Traditionelle Lastverteiler, die sich auf HTTP-Pfade oder Round-Robin konzentrieren, fehlen die spezialisierten Fähigkeiten, die für diese Arbeitslasten erforderlich sind. Sie berücksichtigen auch nicht die Modellidentität oder die Kritikalität der Anfragen (z. B. interaktiver Chat vs. Batch-Jobs). Organisationen fügen häufig ad-hoc Lösungen zusammen, doch ein standardisierter Ansatz fehlt.

Wie Sie sicherstellen, dass Ihr Sidecar-Container zuerst startet

Fri, 06 Jun 2025 02:00:00 +0000

Einführung in die Verwaltung von Sidecar-Containern in Kubernetes

In der Welt von Kubernetes sind Sidecar-Container nützliche Helfer, die Funktionen erweitern oder zusätzliche Aufgaben für die Hauptanwendung übernehmen. In diesem Artikel werfen wir einen Blick darauf, wie Sie sicherstellen können, dass Ihre Sidecar-Container vor der Hauptanwendung starten. Dies kann entscheidend sein, um Probleme während des Starts zu vermeiden und die Stabilität Ihrer Anwendungen zu gewährleisten.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Mit der Einführung von Kubernetes v1.29.0 wurde die native Unterstützung für Sidecar-Container verbessert. Diese können jetzt im .spec.initContainers-Feld definiert werden, was bedeutet, dass sie immer vor der Hauptanwendung gestartet werden. Das klingt einfach, birgt jedoch einige Herausforderungen.

KI im Klassenzimmer: Chancen und Herausforderungen für die Zukunft der Bildung

Thu, 05 Jun 2025 18:59:14 +0000

KI im Klassenzimmer: Chancen und Herausforderungen für die Zukunft der Bildung

Die Diskussion um den Einsatz von Künstlicher Intelligenz (KI) in der Bildung polarisiert. Während die einen große Chancen für personalisiertes Lernen sehen, befürchten andere eine Entmenschlichung des Unterrichts und neue Abhängigkeiten. Doch wenn wir einen sachlichen Blick darauf werfen, zeigt sich: KI kann ein wertvolles Werkzeug sein — vorausgesetzt, wir gehen verantwortungsvoll damit um.

Die großen Chancen: Wie KI den Unterricht verbessern kann

1. Individuelles Lernen auf neuem Niveau\nJeder Mensch lernt unterschiedlich schnell, auf eigene Weise und mit eigenen Stärken und Schwächen. KI-gestützte Lernsysteme können genau hier ansetzen: Sie analysieren den Lernstand der Schülerinnen und Schüler in Echtzeit, erkennen Verständnisprobleme frühzeitig und passen die Lerninhalte automatisch an. So wird der Unterricht individueller und effektiver gestaltet.

Moderne Ticketsysteme: Warum Zammad die bessere Wahl für IT-Support und Kundenservice ist

Thu, 05 Jun 2025 18:55:10 +0000

Heute entscheidet jede Supportanfrage über Kundenzufriedenheit, Bindung und langfristigen Unternehmenserfolge. Unstrukturierte Prozesse, verlorene Tickets und lange Antwortzeiten kosten Vertrauen und Effizienz. Viele Unternehmen kämpfen mit komplexen, unflexiblen Helpdesk-Lösungen oder geraten in teure Abhängigkeiten von SaaS-Anbietern. Genau hier schafft Zammad einen klaren Unterschied.

Zammad: Das leistungsstarke Open-Source-Ticketsystem

Zammad ist mehr als nur ein weiteres Ticketsystem. Als moderne, Open-Source-basierte Lösung kombiniert es Effizienz, Transparenz und volle Kontrolle über Ihre Supportprozesse. Unternehmen jeder Größe erhalten damit eine skalierbare Plattform, die ohne Lizenzkosten auskommt und sich flexibel an individuelle Anforderungen anpasst.

Gateway API v1.3.0: Neue Funktionen für flexibles Request Mirroring und mehr!

Thu, 05 Jun 2025 02:00:00 +0000

Wir freuen uns, die allgemeine Verfügbarkeit der Gateway API v1.3.0 bekanntzugeben! Diese Version wurde am 24. April 2025 veröffentlicht und bringt spannende neue Funktionen mit sich.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die Version 1.3.0 der Gateway API führt das prozentuale Request Mirroring als neue Funktion im Standard Kanal ein. Außerdem gibt es drei experimentelle Features: CORS-Filter, einen standardisierten Mechanismus zur Zusammenführung von Listenern und Gateways sowie Retry Budgets.

Einführung in die Gateway API Inference Extension

Thu, 05 Jun 2025 00:00:00 +0000

TL;DR

Die Gateway API Inference Extension wurde entwickelt, um die spezifischen Anforderungen an das Routing von Inferenz-Workloads in Kubernetes zu adressieren. Sie ermöglicht eine verbesserte, modellbewusste Lastverteilung und optimiert die Ressourcennutzung für generative KI- und große Sprachmodell-Dienste.

Hauptinhalt

Die Einführung von generativen KI-Diensten und großen Sprachmodellen (LLMs) bringt neue Herausforderungen für das Traffic-Routing in Kubernetes mit sich. Im Gegensatz zu typischen, kurzlebigen, zustandslosen Webanfragen sind Inferenzsitzungen oft langlaufend, ressourcenintensiv und teilweise zustandsbehaftet. Ein einzelner GPU-unterstützter Modellserver kann mehrere Inferenzsitzungen gleichzeitig aktiv halten und In-Memory-Token-Caches verwalten. Herkömmliche Lastverteiler, die sich auf HTTP-Pfade oder Round-Robin-Methoden stützen, sind nicht ausreichend, um diese speziellen Anforderungen zu erfüllen.

Die vergessene Schwachstelle in euren CI/CD-Pipelines: Die Registry

Tue, 03 Jun 2025 10:26:37 +0000

Die vergessene Schwachstelle in euren CI/CD-Pipelines: Die Registry

Jeder redet über Build-Pipelines, Deployment-Automatisierung, GitOps, Blue/Green-Rollouts, Canary Releases. Alles sauber durchorchestriert, automatisiert, versioniert. Klingt stabil. Aber der ganze Stack hängt an einem simplen Punkt, den viele Teams viel zu lange ignorieren: der Container- und Artifact-Registry.

Hier wird alles gespeichert, was eure Software überhaupt erst lauffähig macht: Container-Images, Helm-Charts, Pakete, Libraries, Abhängigkeiten. Ohne diese Artefakte ist jeder Build wertlos. Ohne sie kann keine einzige Pipeline mehr ausrollen.

Application Performance sollte messbar sein — jederzeit, in Echtzeit

Tue, 03 Jun 2025 10:24:49 +0000

Wer Anwendungen produktiv betreibt, braucht keine schönen Dashboards, sondern harte Daten. Performance-Probleme entstehen nie dann, wenn Zeit für Debugging ist. Sie kommen genau dann, wenn Systeme unter Last laufen, Services peak-load fahren, externe Abhängigkeiten anfangen zu kippen oder Netzwerklatenzen sich schleichend aufbauen.

Die Frage ist nicht, ob man irgendwann rausfindet, warum der Stack unterperformt. Die Frage ist, ob man es früh genug sieht, um eingreifen zu können, bevor es der Kunde merkt.

Warum betreibt ihr eure App eigentlich noch selbst?

Tue, 03 Jun 2025 10:24:14 +0000

Die Frage stellt sich immer wieder. Entwicklerteams liefern Features, optimieren Releases, bauen saubere Architekturen — und dann hängen sie trotzdem noch in der Infrastruktur. Kubernetes-Cluster betreuen, Zertifikate erneuern, Storage erweitern, Loadbalancer konfigurieren, Backups prüfen, Monitoring überwachen, Security-Patches einspielen.

All das ist Betriebsalltag. Aber keiner dieser Punkte bringt dem Kunden ein neues Feature. Kein einziger dieser Tasks steigert den Mehrwert eurer Anwendung. Betrieb sichert lediglich den Zustand ab, den der Kunde sowieso voraussetzt: dass es funktioniert.

KI ohne Kontrollverlust: Maschinen laufen besser auf eigenen Infrastruktur

Tue, 03 Jun 2025 10:21:56 +0000

Gerade redet jeder über KI, Large Language Models, Inference-Pipelines, Custom-LLMs und Co-Piloten für alle denkbaren Business-Prozesse. Was dabei gern vergessen wird: Die eigentliche Wertschöpfung entsteht nicht beim Prompt, sondern in der Infrastruktur, auf der die Modelle laufen.

Und genau hier wird es schnell unbequem.

Wer ernsthaft KI-Modelle für Enterprise-Prozesse betreiben will, landet ziemlich schnell bei zwei Fragen: Wo läuft das Modell? Und wer kontrolliert, wer darauf zugreift?

Viele fahren aktuell blind Richtung Public-Cloud-KI-Plattformen. Dort gibt es fertige APIs, hübsche Dashboards, automatisierte Training-Pipelines. Klingt bequem, skaliert schnell, wird aber teuer. Viel wichtiger: Die volle Kontrolle über das Modell, die Trainingsdaten, die Hyperparameter und die Inference-Pipelines bleibt beim Plattformanbieter.

IIoT-Daten nützen nichts, wenn sie in der Maschine vergammeln

Tue, 03 Jun 2025 10:18:57 +0000

Die meisten IIoT-Projekte scheitern nicht an den Maschinen. Die Sensorik läuft. Die Steuerungen liefern Daten. Die Netzwerke übertragen Pakete. Das Problem beginnt eine Ebene höher: Die Daten landen irgendwo im Produktionsnetz, werden kurz geloggt, vielleicht aggregiert, und dann? Nichts.

Weil niemand sauber gelöst hat, wie aus hochfrequenten Echtzeitdaten aus der OT tatsächlich verwertbare Informationen für Analytics, Planung, Supply Chain und Management werden. Und das ist absurd. Die Produktionslinie weiß längst, wie es ihr geht — nur die Organisation erfährt es oft erst Tage später, wenn Reports konsolidiert sind.

App-Hosting auf Kubernetes — komplett gemanaged

Tue, 03 Jun 2025 10:10:24 +0000

Softwareentwicklung endet nicht beim Code

Wer heute Applikationen für Kunden entwickelt, steht schnell vor dem nächsten Thema: Wie wird die Software produktiv betrieben? Wo laufen Staging und Produktivsysteme? Wer übernimmt den 24/7-Betrieb? Wie sieht die Absicherung aus? Wer kümmert sich um Verfügbarkeit, Patching, Backup, Skalierung, Überwachung?

Die meisten Kunden erwarten heute nicht mehr nur Softwareentwicklung, sondern ein Komplettangebot: Entwicklung, Deployment, Betrieb, Support.

Genau hier entsteht die operative Lücke.

Betrieb ist kein Nebenjob. Infrastruktur ist kein Feature. Wer es ernst meint, braucht ein Betriebskonzept, das skalierbar, automatisierbar und auditfähig funktioniert. Und zwar stabil — unabhängig davon, wie viele Projekte parallel laufen.

Sichere Infrastruktur für Gesundheitsdaten — ISO27001-konform

Tue, 03 Jun 2025 10:02:56 +0000

Gesundheitsdaten sind ein Sonderfall — technisch wie regulatorisch

Die Verarbeitung von Gesundheitsdaten unterscheidet sich grundlegend von klassischer Unternehmens-IT. Hier geht es nicht nur um personenbezogene Daten, sondern um besonders schützenswerte Informationen nach Art. 9 DSGVO. Diagnosen, Laborwerte, Therapieverläufe, Medikationspläne, Bilddaten und Behandlungsdokumentationen sind hochsensibel. Ein technischer Fehler, ein Sicherheitsvorfall oder ein unzureichend abgesicherter Betriebsprozess gefährden hier nicht nur Geschäftsprozesse, sondern die Integrität von Menschen.

Die Anforderungen an Infrastruktur, die solche Systeme betreibt, liegen entsprechend weit über dem Niveau klassischer Web- oder SaaS-Plattformen. Und genau hier trennt sich operative Souveränität von bloßen Softwareprojekten.

Mit ayedo hosten Sie Ihre Banking-APIs DORA-compliant auf europäischer Infrastruktur

Tue, 03 Jun 2025 09:57:07 +0000

DORA kommt. Und diesmal bleibt es nicht bei ein paar hübschen Compliance-PDFs.

Was viele Banken, Zahlungsdienstleister und FinTechs gerade erst realisieren:

DORA (Digital Operational Resilience Act) ist kein weiteres Dokumentations- und Prüfverfahren, das man durch ein paar Policies und Zertifikate elegant beilegt. DORA greift deutlich tiefer in den operativen Betrieb ein.

Es geht um technische Resilienz. Nicht auf PowerPoint-Ebene, sondern direkt in der Infrastruktur.

DORA ist kein Datenschutz, DORA ist Betriebsverantwortung

Der eigentliche Kern von DORA: Die vollständige Kontrolle über Betriebsfähigkeit und Störungsresilienz kritischer IT-Systeme. Also genau das, was klassische SaaS- oder Public-Cloud-Modelle ungern im Detail offenlegen.

OZG-Software bauen ist das eine. OZG-Software bauen ist das eine.

Tue, 03 Jun 2025 09:50:41 +0000

OZG-Umsetzung: Software allein reicht nicht

Das Onlinezugangsgesetz (OZG) verpflichtet Bund, Länder und Kommunen, Verwaltungsleistungen digital verfügbar zu machen. Auf dem Papier klingt das nach Softwareprojekten. In der Praxis geht es längst nicht mehr nur um die Applikation.

Entscheidend für die Umsetzbarkeit wird, wie die darunterliegende Infrastruktur betrieben wird. Behörden erwarten längst keine reinen Entwicklungspartner mehr, sondern Betriebskonzepte, die die vollständige Servicekette absichern: Verarbeitung personenbezogener Daten, Verarbeitung von Meldedaten, Registerzugriff, Identitäten, Schnittstellen, Compliance und Auditierbarkeit.

Cloud Act: Das eigentliche Problem ist nicht der Speicherort, sondern das Control Plane

Tue, 03 Jun 2025 07:11:02 +0000

In den meisten Diskussionen um den Cloud Act geht es ausschließlich um den Speicherort von Daten. Rechenzentrum in Frankfurt? ISO-zertifiziert? Verschlüsselt? Klingt gut.

Technisch betrachtet greift diese Diskussion aber viel zu kurz.

Der eigentliche Angriffspunkt sitzt an ganz anderer Stelle: dem Control Plane.

Wer das Control Plane kontrolliert, kontrolliert alles

In jeder Cloud-Infrastruktur gibt es zwei Ebenen:

Data Plane: Hier liegen und bewegen sich die eigentlichen Nutzdaten.
Control Plane: Hier wird gesteuert, wer was wie wo verarbeitet. Scheduling, Orchestrierung, APIs, IAM, Zugriffsrechte, Verschlüsselungsmanagement, Netzwerksteuerung, Policy Engines.

Die Kontrolle über das Control Plane entscheidet faktisch darüber, wer Zugriff auf welche Datenströme, Metadaten, Schlüssel und Steuerbefehle hat.

Starte Sidecar zuerst: So vermeidest du Probleme

Tue, 03 Jun 2025 00:00:00 +0000

TL;DR

Die korrekte Reihenfolge beim Start von Sidecar-Containern in Kubernetes ist entscheidend für die Stabilität von Anwendungen. Mit der Einführung von native Sidecar-Unterstützung in Kubernetes v1.29.0 können Entwickler sicherstellen, dass Sidecar-Container vor der Hauptanwendung gestartet werden. Strategien wie die Verwendung von Readiness-Proben helfen dabei, sicherzustellen, dass die Hauptanwendung erst startet, wenn die Sidecar-Container bereit sind.

Die Einführung von Sidecar-Containern in Kubernetes v1.29.0 ermöglicht eine verbesserte Handhabung von Multi-Container-Pods. Sidecar-Container können nun im .spec.initContainers-Feld definiert werden, wodurch sichergestellt wird, dass sie vor der Hauptanwendung gestartet werden. Dies ist besonders wichtig, da Sidecar-Container oft Dienste bereitstellen, die für das ordnungsgemäße Funktionieren der Hauptanwendung erforderlich sind. Ein Beispiel für die Definition eines Sidecar-Containers zeigt, dass diese Container nicht nur vor der Hauptanwendung, sondern auch nach deren Start weiterhin aktiv bleiben können.

Gateway API v1.3.0: Fortschritte bei Request Mirroring, CORS, Gateway Merging und Retry Budgets

Mon, 02 Jun 2025 17:00:00 +0000

TL;DR

Die Gateway API v1.3.0 wurde veröffentlicht und bietet neue Funktionen wie prozentuales Request Mirroring, CORS-Filter, Gateway-Merging sowie Retry Budgets. Diese Version hat den Standard-Kanal erreicht, was auf eine hohe Zuverlässigkeit hinweist und die Rückwärtskompatibilität garantiert.

Hauptinhalt

Die Veröffentlichung der Gateway API v1.3.0 markiert einen wichtigen Fortschritt in der Entwicklung der API, die nun im Standard-Kanal verfügbar ist. Diese Einstufung unterstreicht das Vertrauen in die API-Oberfläche und bietet Nutzern die Sicherheit, dass diese Version mit zukünftigen Ergänzungen rückwärtskompatibel bleibt. Zu den neuen Funktionen gehören das prozentuale Request Mirroring, das es ermöglicht, einen bestimmten Anteil von HTTP-Anfragen an einen anderen Backend-Dienst zu spiegeln, sowie die Einführung von CORS-Filter, einem standardisierten Mechanismus für das Merging von Listenern und Gateways, und Retry Budgets.

IT/OT-Integration mit Kubernetes: Architektur für industrielle Echtzeitdatenverarbeitung

Sun, 01 Jun 2025 13:30:25 +0000

Warum IT und OT zusammenwachsen müssen

In modernen Industrieumgebungen entstehen an der Schnittstelle zwischen Produktion und Unternehmens-IT zunehmend komplexe Datenströme. Produktionsanlagen, Sensoren und Maschinensteuerungen liefern permanent Echtzeitdaten, die für die Prozessoptimierung, Predictive Maintenance, Qualitätssicherung und Geschäftsentscheidungen immer wichtiger werden.

Das Problem: OT-Systeme (Operational Technology) und klassische IT sprechen unterschiedliche Sprachen. Während OT auf Stabilität, niedrige Latenzen und deterministisches Verhalten optimiert ist, arbeitet IT serviceorientiert, dynamisch skalierend und mit ganz anderen Anforderungen an Netzwerke, Security und Steuerbarkeit.

Kubernetes als Brücke zwischen IT und OT: Echtzeitdaten aus Maschinen intelligent verarbeiten

Sun, 01 Jun 2025 13:25:22 +0000

Die Lücke zwischen Shopfloor und Enterprise IT

In immer mehr Unternehmen wachsen IT und OT (Operational Technology) zusammen. Produktionsanlagen, Maschinen, Steuerungssysteme und Sensoren liefern in Echtzeit riesige Datenmengen. Diese Informationen sind wertvoll – aber nur, wenn sie schnell, stabil und sicher in die IT-Infrastruktur integriert und weiterverarbeitet werden können. Genau hier entstehen seit Jahren die typischen Herausforderungen:

Hohe Latenz und inkonsistente Protokolle
Zerklüftete Netzwerke zwischen Shopfloor und Enterprise-IT
Sicherheitsanforderungen und Segmentierung
Proprietäre Schnittstellen und Altsysteme

Die klassische Trennung zwischen OT und IT wird zunehmend unpraktisch. Was fehlt, ist eine saubere, standardisierte Integrationsschicht, die beide Welten miteinander verbindet — und genau hier bietet Kubernetes entscheidende Vorteile.

Redundanz, Automatisierung, Unabhängigkeit – drei Dimensionen einer Infrastrukturentscheidung

Thu, 29 May 2025 10:06:09 +0000

Technologische Eigenständigkeit beginnt im Rechenzentrum: Warum wir auf Europäische Netzwerktechnologie setzen

Digitale Souveränität beginnt nicht in Gesetzestexten oder Strategiepapieren – sie beginnt dort, wo Infrastruktur geplant, implementiert und betrieben wird. Bei ayedo bedeutet das: jede Komponente, jeder Layer, jede Schnittstelle wird hinterfragt. Nicht aus Misstrauen, sondern aus Verantwortung.

In unserem aktuellen Ausbauprojekt im Rechenzentrum haben wir gezielt in mehr Redundanz und Performance investiert – und gleichzeitig einen weiteren Schritt hin zu technologischer Eigenständigkeit vollzogen. Im Fokus stand die Netzwerkinfrastruktur. Genauer: der Einsatz Europäischer Routing-Technologie, die uns nicht nur technische Vorteile bringt, sondern auch in Fragen der Kontrolle, Wartbarkeit und rechtlichen Klarheit neue Maßstäbe setzt.

Bundeswehr & Google Cloud: Warum das ein sicherheitspolitisches Risiko ist

Wed, 28 May 2025 08:29:29 +0000

Ein technisches Projekt, das politische Fragen aufwirft

Die Meldung klang zunächst nüchtern: Die Bundeswehr wird ihre private Cloud-Infrastruktur künftig mit Unterstützung von Google aufbauen. Genauer gesagt: Die BWI GmbH – IT-Dienstleister der Bundeswehr – hat mit der „Google Cloud Public Sector – Deutschland GmbH" einen Rahmenvertrag unterzeichnet, um zwei isolierte Cloud-Instanzen aufzubauen. Der Begriff, den Google selbst verwendet: Air-Gapped Cloud.

Auf den ersten Blick wirkt das nach einer pragmatischen Lösung: Rechenzentren im Eigenbetrieb, physikalische Trennung vom öffentlichen Internet, angeblich vollständige Datenkontrolle durch die Bundeswehr.

Warum Deutschland mehr Rechenzentren braucht

Tue, 20 May 2025 19:12:51 +0000

Digitale Souveränität beginnt bei der Infrastruktur

Die Digitalisierung in Deutschland schreitet voran – aber sie braucht ein solides Fundament. Und dieses Fundament ist die IT-Infrastruktur. Rechenzentren bilden dabei das Rückgrat unserer digitalen Wirtschaft. Doch trotz wachsender digitaler Abhängigkeiten hinkt Deutschland beim Ausbau seiner Rechenzentrumsinfrastruktur hinterher. Das ist nicht nur ein wirtschaftliches Risiko, sondern auch ein Souveränitätsproblem.

Der steigende Bedarf: Daten explodieren, Infrastruktur stagniert

Cloud-Anwendungen, KI-Modelle, vernetzte Produktionsanlagen und datengetriebene Geschäftsprozesse erzeugen täglich immense Datenmengen. Laut Bitkom wächst das Datenvolumen in Deutschland jährlich um mehr als 30 %. Gleichzeitig steigen die Anforderungen an Verfügbarkeit, Sicherheit und Latenz.

Adieu Kaltakquise

Tue, 20 May 2025 18:38:23 +0000

Wie moderner IT-Vertrieb Vertrauen aufbaut statt zu stören!

In der IT-Branche war der klassische Vertrieb lange geprägt von hartnäckigen Anrufen, generischen E-Mails und uninspirierten PowerPoint-Folien. Doch die Spielregeln haben sich geändert: Entscheider, Entwickler und Tech-Startups erwarten heute keine Produkte, sondern Lösungen – keine Versprechen, sondern Partnerschaften. Willkommen im Zeitalter des digitalen Vertrauensaufbaus.

Warum Kaltakquise ausgedient hat

Kaltakquise wirkt – wie der Name schon sagt – kalt. Sie unterbricht, statt zu inspirieren. Besonders in technologiegetriebenen Märkten, in denen informierte Kunden auf Augenhöhe agieren, wird aufdringlicher Vertrieb zunehmend als Reibungsverlust wahrgenommen.

Cloud-Exit wird Realität: Warum Unternehmen die Re-Patriierung ernsthaft prüfen

Tue, 20 May 2025 18:16:59 +0000

Die Wolke verliert ihre Unschuld

Die Cloud war einmal der Inbegriff für Effizienz, Skalierbarkeit und digitale Transformation. Doch die Realität hat viele Unternehmen eingeholt: Vendor-Lock-ins, unkontrollierte Kostensteigerungen, Compliance-Risiken und ein wachsender Kontrollverlust über sensible Daten haben dazu geführt, dass immer mehr Organisationen die Option eines Cloud-Exits prüfen – und in einigen Fällen auch konsequent umsetzen.

Cloud-Exit meint nicht das Ende der Cloud-Nutzung per se, sondern den gezielten Rückzug aus bestimmten Public-Cloud-Szenarien hin zu souveräneren, kostentransparenten und kontrollierbaren IT-Infrastrukturen – ob on-premises, in der Private Cloud oder auf europäischen Open-Source-Plattformen.

Europa und die Cloud

Mon, 19 May 2025 17:11:55 +0000

Hey,

ich bin Fabian – Ingenieur, Unternehmer und europäischer Staatsbürger mit Wohnsitz in Deutschland.

Seit über 10 Jahren bewege ich mich in der internationalen Tech-Szene – mit einem klaren Fokus: global denken, lokal handeln. Ich habe einen formalen Abschluss in Informatik und Technologie, bin aber seit jeher autodidaktisch unterwegs, neugierig, offen für Neues und pragmatisch im Umgang mit der realen Welt.

2017 habe ich meinen Job gekündigt und ein Beratungsunternehmen für Cloud-native Technologien gegründet – hauptsächlich DevOps, aber auch individuelle Softwareentwicklung, Teamaufbau, Venture-Building und Produktentwicklung.

Microsoft sperrt das E-Mail-Konto eines Chefanklägers. Europa schaut zu.

Mon, 19 May 2025 14:57:22 +0000

Ein leitender Ermittler des Internationalen Strafgerichtshofs verliert den Zugriff auf seine E-Mails – weil ein US-Präsident Sanktionen verhängt. Microsoft zieht mit. Ohne Verfahren, ohne Rechtfertigung, ohne Konsequenzen.

Ein Fall, der alles offenlegt, was viele in Europa weiterhin ignorieren: Unsere digitale Infrastruktur liegt außerhalb unserer Kontrolle. Wer heute Dienste wie Microsoft 365 oder Azure nutzt, handelt nicht neutral. Er gibt Kontrolle ab.

Was passiert ist, ist keine Ausnahme – es ist systemisch

Ein UN-Ermittler wird technisch entmündigt.
NGOs beenden aus Angst vor Sanktionen die Zusammenarbeit mit dem IStGH.
Ermittlungen zu Kriegsverbrechen kommen zum Stillstand – nicht aus Mangel an Beweisen, sondern weil Zugänge blockiert wurden.

In Kubernetes-Umgebungen ist die Handhabung von Pod-Fehlern entscheidend für die erfolgreiche Ausführung von Arbeitslasten. Die Standardfunktionalität von Kubernetes ermöglicht es, mit dem Feld spec.backoffLimit eine maximale Anzahl an tolerierten Fehlern für einen Job festzulegen. Diese Methode erweist sich jedoch als unzureichend, wenn es um Arbeitslasten geht, bei denen jeder Index unabhängig ist, wie beispielsweise bei parallelen Testausführungen.

Datensouveränität vs. Digitales Zaudern: Warum Deutschland beim Cloud-Thema aufholen muss

Tue, 13 May 2025 10:31:36 +0000

Deutschland diskutiert über Datensouveränität – und bleibt dabei technologisch abhängig. Warum das mit unserer Kultur zu tun hat und was sich ändern muss, um digitale Eigenständigkeit zu erreichen.

Zwischen Angst, Anspruch und Ambivalenz

Deutschland – das Land der Dichter und Denker. Der Ort, an dem einst Grundlagen für moderne Technologie, Informatik und Automatisierung gelegt wurden. Und dennoch: Wenn es um digitale Infrastrukturen, insbesondere Cloud-Services, geht, blicken wir fast ausnahmslos in Richtung USA. Amazon, Microsoft, Google – die Schwergewichte heißen alle anderswo. Und was bleibt uns? Ein paar lokale Rechenzentren, IT-Dienstleister in Nischen und eine gewaltige Portion technologischer Abhängigkeit.

Kubernetes v1.33: Image Pull Policy so, wie du es dir immer vorgestellt hast!

Mon, 12 May 2025 18:30:00 +0000

TL;DR

Kubernetes v1.33 bringt eine überarbeitete Handhabung der Image Pull Policies, insbesondere für private Container -Images. Die neue Implementierung stellt sicher, dass Pods nur dann auf bereits lokal vorhandene private Images zugreifen können, wenn sie über die entsprechenden Authentifizierungsdaten verfügen, was die Sicherheit erhöht und potenzielle Risiken minimiert.

Hauptinhalt

Die Image Pull Policy in Kubernetes, insbesondere die Option IfNotPresent, hat in der Vergangenheit für Verwirrung gesorgt. Diese Policy erlaubt es Pods, ein Container-Image zu verwenden, wenn es bereits auf dem Node vorhanden ist, ohne dass eine erneute Authentifizierung erforderlich ist. Dies führte zu einem Sicherheitsrisiko, da Pods, die nicht über die richtigen Anmeldeinformationen verfügten, auf private Images zugreifen konnten, die von anderen Pods bereits heruntergeladen wurden.

Souveräne Cloud: Anspruch, Realität und technische Auswege

Mon, 12 May 2025 09:13:41 +0000

Souveräne Cloud braucht mehr als ein Rechenzentrum in Europa. Was der CLOUD Act mit der DSGVO kollidieren lässt – und welche Technologien echte Datensouveränität ermöglichen.

Zwischen juristischer Sackgasse und technologischer Machbarkeit

Die Idee einer Souveränen Cloud ist in der europäischen IT-Landschaft zum Leitmotiv geworden – besonders im Kontext von Datenschutz, digitaler Unabhängigkeit und regulatorischer Compliance. Doch zwischen Wunsch und Wirklichkeit klafft eine erhebliche Lücke: Während technologische Konzepte für Souveränität zunehmend verfügbar sind, bleibt die rechtliche Seite komplex und widersprüchlich.

US Cloud Act vs. DSGVO: Wer kontrolliert Ihre Daten wirklich?

Mon, 12 May 2025 09:03:32 +0000

Der CLOUD Act erlaubt US-Behörden den Zugriff auf europäische Daten – im Konflikt mit der DSGVO. Erfahren Sie, wie sich Unternehmen technisch und rechtlich absichern können.

Ein Gesetz mit Sprengkraft für europäische Unternehmen

Im März 2018 verabschiedete die US-Regierung den CLOUD Act (Clarifying Lawful Overseas Use of Data Act). Was auf den ersten Blick nach technokratischer Gesetzgebung klingt, ist in Wahrheit ein geopolitischer Zugriff auf Ihre Unternehmensdaten – selbst wenn diese auf europäischen Servern gespeichert sind. Entscheidend ist nicht der Standort der Server, sondern wer sie kontrolliert.

US Cloud Act vs. DSGVO: Wenn Datenschutz auf geopolitische Realität trifft

Mon, 12 May 2025 08:57:39 +0000

Der US Cloud Act erlaubt US-Behörden den Zugriff auf europäische Server – ein klarer Konflikt mit der DSGVO. Erfahren Sie, wie Unternehmen sich absichern und digitale Souveränität zurückgewinnen.

Was US-Behörden auf europäische Server treibt – und was das für Ihr Unternehmen bedeutet

Transatlantische Datenbeziehungen waren selten einfach – doch mit dem US Cloud Act ist endgültig klar: Wer mit US-basierten Cloud-Dienstleistern arbeitet, muss sich bewusst sein, dass nicht europäisches Recht, sondern amerikanische Interessen das letzte Wort haben könnten. Und das betrifft nicht nur US-Server, sondern auch Rechenzentren mitten in Deutschland, wenn sie unter der Kontrolle eines US-Konzerns stehen.

Kubernetes v1.33: Effiziente Datenübertragung durch Streaming-Listenantworten

Mon, 12 May 2025 02:00:00 +0000

Managing Kubernetes-Cluster-Stabilität wird zunehmend kritisch, je größer Ihre Infrastruktur wird. Eine der herausforderndsten Aspekte beim Betrieb von großen Clustern war bisher die Handhabung von List-Anfragen, die umfangreiche Datensätze abrufen - eine häufige Operation, die unerwartete Auswirkungen auf die Stabilität Ihres Clusters haben kann.

Heute freut sich die Kubernetes-Community, eine bedeutende architektonische Verbesserung anzukündigen: Streaming-Codierung für List-Antworten.

Das Problem: Unnötiger Speicherverbrauch bei großen Ressourcen

Aktuelle API-Antwortencoder serialisieren eine gesamte Antwort in einen einzigen zusammenhängenden Speicherbereich und führen einen einzigen ResponseWriter.Write-Aufruf aus, um die Daten an den Client zu übertragen. Trotz der Fähigkeit von HTTP/2, Antworten in kleinere Frames für die Übertragung zu splitten, hält der zugrunde liegende HTTP-Server die vollständigen Antwortdaten weiterhin als einen einzigen Puffer. Selbst wenn einzelne Frames an den Client übertragen werden, kann der Speicher, der mit diesen Frames verbunden ist, nicht inkrementell freigegeben werden.

Kubernetes 1.33: Volumen-Populator jetzt allgemein verfügbar – Das ändert sich für dich!

Sun, 11 May 2025 02:00:00 +0000

Kubernetes Volume Populators sind jetzt allgemein verfügbar (GA)! Mit der AnyVolumeDataSource-Funktion können Nutzer nun jede geeignete benutzerdefinierte Ressource als Datenquelle für ein PersistentVolumeClaim (PVC) angeben.

Ein Beispiel, wie du dataSourceRef in PVC verwenden kannst: yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc1 spec: … dataSourceRef: apiGroup: provider.example.com kind: Provider name: provider1

Was ist neu

In dieser Version gibt es vier wesentliche Verbesserungen im Vergleich zur Beta.

Populator-Pod ist optional

Während der Beta-Phase haben die Mitwirkenden von Kubernetes potenzielle Ressourcenlecks beim Löschen von PersistentVolumeClaims (PVC) identifiziert, während die Volumenbefüllung noch im Gange war. Diese Lecks traten aufgrund von Einschränkungen bei der Handhabung von Finalizern auf. Vor der Graduierung zur allgemeinen Verfügbarkeit hat das Kubernetes-Projekt die Unterstützung für das Löschen temporärer Ressourcen (PVC prime usw.) hinzugefügt, wenn das ursprüngliche PVC gelöscht wird.

Kubernetes v1.33: Streaming List-Antworten

Fri, 09 May 2025 18:30:00 +0000

TL;DR

Kubernetes v1.33 führt einen neuen Streaming-Encoder für List-Antworten ein, der die Effizienz und Stabilität des API-Servers bei großen Datenmengen verbessert. Dieser Mechanismus ermöglicht eine schrittweise Verarbeitung und Übertragung von Listenelementen, wodurch der Speicherverbrauch signifikant gesenkt wird und die Leistung des Clusters optimiert wird.

Hauptinhalt

Die Verwaltung der Stabilität von Kubernetes -Clustern wird mit wachsender Infrastruktur immer wichtiger. Eine der größten Herausforderungen bei der Arbeit mit großen Clustern ist die Handhabung von List-Anfragen, die umfangreiche Datensätze abrufen. Bisherige API-Antwortencoder serialisieren die gesamte Antwort in einem einzigen zusammenhängenden Speicherblock, was zu unnötigem Speicherverbrauch führt. Insbesondere bei großen Clustern kann dies zu einer erheblichen Belastung des kube-apiserver führen, da der gesamte Antwortkörper im Speicher gehalten wird, selbst wenn Teile der Antwort bereits an den Client gesendet werden.

Warum wir uns jetzt von AWS, Azure & Google Cloud verabschieden müssen

Fri, 09 May 2025 09:33:09 +0000

Die digitale Transformation ist keine Zukunftsmusik mehr – sie ist längst Realität. Sie betrifft nicht nur E-Commerce oder digitale Tools im Büro, sondern ist tief in das Fundament unserer Gesellschaft eingedrungen: vernetzte Produktionsprozesse, automatisierte Lieferketten, digitale Gesundheitsversorgung, smarte Energienetze und die Steuerung kritischer Infrastrukturen. Kurz: das Rückgrat unserer Wirtschaft und Verwaltung.

Mit der Einführung von Kubernetes v1.33 wird ein bedeutendes Problem angegangen, das in früheren Versionen auftrat, als das Löschen von PVs und PVCs in der falschen Reihenfolge zu PersistentVolume-Leaks führte. In Versionen vor v1.33 gab es keine Einschränkungen beim Löschen eines PVs, bevor der zugehörige PVC entfernt wurde. Dies führte dazu, dass die Reclaim-Policy des PVs nicht respektiert wurde, was zur Folge hatte, dass die entsprechenden Speicherressourcen in der externen Infrastruktur nicht gelöscht wurden.

Kubernetes v1.33: Änderbarer CSI Node Allocatable Count

Fri, 02 May 2025 18:30:00 +0000

TL;DR

Kubernetes v1.33 führt eine alpha-Funktion namens “mutable CSI node allocatable count” ein, die es Container Storage Interface (CSI) Treibern ermöglicht, die maximale Anzahl von Volumen, die ein Knoten verarbeiten kann, dynamisch zu aktualisieren. Diese Funktion verbessert die Genauigkeit von Pod-Scheduling-Entscheidungen und verringert Fehler, die durch veraltete Kapazitätsinformationen verursacht werden.

Hauptinhalt

Die Zuverlässigkeit bei der Planung zustandsbehafteter Anwendungen in Kubernetes hängt stark von präzisen Informationen über die Verfügbarkeit von Ressourcen auf den Knoten ab. In der bisherigen Implementierung berichteten CSI-Treiber eine statische maximale Anzahl an Volumen, die einem Knoten zugewiesen werden konnten. Diese statischen Werte konnten jedoch während des Lebenszyklus eines Knotens aus verschiedenen Gründen variieren. Dazu gehören manuelle oder externe Vorgänge, die Volumen außerhalb der Kontrolle von Kubernetes an- oder abklemmen, dynamisch angefügte Netzwerkschnittstellen oder spezialisierte Hardware, die verfügbare Slots in Anspruch nimmt, sowie Szenarien mit mehreren Treibern, bei denen die Operationen eines Treibers die Kapazitätsberichte eines anderen beeinflussen.

Mit Kubernetes v1.33: Image Volumes jetzt im Beta-Stadium!

Fri, 02 May 2025 02:00:00 +0000

Image Volumes wurden mit der Kubernetes-Version v1.31 als Alpha-Feature eingeführt und sind nun in der Version v1.33 auf Beta-Status hochgestuft worden. Dies ist Teil von KEP-4639.

Es ist wichtig zu beachten, dass das Feature standardmäßig deaktiviert ist, da noch nicht alle Container-Runtimes vollständige Unterstützung bieten. CRI-O unterstützt das ursprüngliche Feature seit Version v1.31 und wird in v1.33 die Unterstützung für Image Volumes als Beta hinzufügen. containerd hat die Unterstützung für das Alpha-Feature integriert, das Teil der Version v2.1.0 sein wird, und arbeitet an der Beta-Unterstützung im Rahmen von PR #11578.

Kubernetes v1.33: Neue Funktionen in DRA

Thu, 01 May 2025 18:30:00 +0000

TL;DR

Kubernetes v1.33 bringt bedeutende Fortschritte in der dynamischen Ressourcenallokation (DRA), die ursprünglich in v1.26 eingeführt wurde. Wichtige Neuerungen umfassen die Beförderung des Driver-owned Resource Claim Status in die Beta-Phase sowie mehrere neue Alpha-Funktionen, die die Flexibilität und Effizienz bei der Geräteverwaltung erhöhen. Die DRA-Funktionalitäten sollen in v1.34 allgemein verfügbar gemacht werden.

Hauptinhalt

Die dynamische Ressourcenallokation (DRA) in Kubernetes hat sich seit ihrer Einführung in v1.26 erheblich weiterentwickelt. Nach einem umfassenden Redesign in v1.31 und der Beta-Einführung in v1.32 hat das DRA-Team in v1.33 mehrere neue Funktionen und Benutzererfahrungsverbesserungen implementiert. Eine der bedeutendsten Änderungen ist die Beförderung des Driver-owned Resource Claim Status in die Beta-Phase. Diese Funktion ermöglicht es Treibern, spezifische Statusdaten für jedes zugewiesene Gerät in einem Ressourcenanspruch zu melden, was besonders nützlich für die Unterstützung von Netzwerkgeräten ist.

Kubernetes v1.33: Benutzer-Namensräume jetzt standardmäßig aktiviert!

Mon, 28 Apr 2025 02:00:00 +0000

In Kubernetes v1.33 ist die Unterstützung für Benutzer-Namensräume standardmäßig aktiviert. Das bedeutet, dass Pods, wenn die Systemanforderungen erfüllt sind, die Möglichkeit haben, Benutzer-Namensräume zu verwenden. Es ist nicht mehr erforderlich, ein Kubernetes-Feature-Flag zu aktivieren!

Was sind Benutzer-Namensräume?

Hinweis: Linux-Benutzer-Namensräume sind ein anderes Konzept als Kubernetes-Namensräume. Erstere sind eine Funktion des Linux-Kernels; letztere sind eine Funktion von Kubernetes.

Linux bietet verschiedene Namensräume, um Prozesse voneinander zu isolieren. Ein typischer Kubernetes-Pod läuft beispielsweise innerhalb eines Netzwerk-Namensraums, um die Netzwerkidentität zu isolieren, und eines PID-Namensraums, um die Prozesse zu isolieren.

Kubernetes v1.33: Magische Neuerungen für Entwickler und DevOps-Teams

Sat, 26 Apr 2025 02:00:00 +0000

Kubernetes v1.33 bringt spannende Neuerungen, die sowohl für Entwickler als auch für DevOps-Teams von großem Nutzen sind. In dieser Version wurden 64 Verbesserungen eingeführt, darunter 18 stabilisierte Features, 20 in die Beta-Version übergehende Funktionen und 24 neue Alpha-Features.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Ein besonders hervorzuhebendes Feature in dieser Version sind die Sidecar-Container, die nun den Status “stabil” erreicht haben. Dieses Muster ermöglicht es, zusätzliche Containerservices zu implementieren, die beispielsweise für Networking, Logging und das Sammeln von Metriken zuständig sind.

Herausforderungen und Lösungen bei der Datenbank-Skalierung: Nextdoor's Optimierungsweg

Fri, 25 Apr 2025 07:00:46 +0000

In einer detaillierten Blogserie gibt das Core-Services-Team von Nextdoor wertvolle Einblicke in ihre Strategien zur Optimierung der Datenbank- und Cache-Infrastruktur. Diese Serie richtet sich an Entwicklerteams, die sich mit den Skalierungsherausforderungen von PostgreSQL und Redis auseinandersetzen.

Die Ausgangssituation und die zentralen Herausforderungen Nextdoor sah sich mit zwei wesentlichen Problemen konfrontiert:

Übermäßige Belastung der Hauptdatenbank, ungeachtet der Nutzung von Lesereplikas. Probleme mit Inkonsistenzen im Cache-System. Das Architekturdesign des Backends, das stark auf das Django-ORM zurückgreift, führte dazu, dass Anfragen häufig aus Sicherheitsgründen an die Primärdatenbank gingen. Dies löste weitere Probleme aus, wie Dateninkonsistenzen durch konkurrierende Schreibzugriffe und nicht erfolgreiche Cache-Aktualisierungen.

Die Burnout-Maschine: Die dunkle Seite der Techindustrie

Fri, 25 Apr 2025 06:59:56 +0000

In der glitzernden Fassade der Technologiebranche, wo Sitzsäcke, kostenloser Kombucha und flexible Arbeitszeiten als Annehmlichkeiten gepriesen werden, verbirgt sich eine tiefere, düstere Realität. Der im “2600 Hacker Quarterly” veröffentlichte Artikel “The Burnout Machine” wirft einen schonungslosen Blick auf die beunruhigenden Arbeitspraktiken einer Industrie, die einst als Eldorado moderner Arbeitnehmer galt.

Die dunklen Untiefen der Technikindustrie

Vermeintliche Traumjobs entpuppen sich oft als Mühlen, die unermüdlich an den Energiereserven ihrer Talente zehren. Agile Methoden, ursprünglich entwickelt, um Flexibilität und Effizienz zu steigern, haben sich zu unaufhörlichen Sprints entwickelt, die eine ständige Erreichbarkeit erfordern. In dieser Kultur ist Burnout nicht nur normalisiert, sondern wird sogar als Maßstab für Engagement angesehen. Nachtschichten sind zu Ruhmeszeiten der Hingabe avanciert.

Remote Work: Sicherstellen von Flexibilität ohne Überforderung

Fri, 25 Apr 2025 06:51:56 +0000

In der heutigen Arbeitslandschaft hat das Konzept der Remote-Arbeit eine bemerkenswerte Veränderung herbeigeführt, indem es Flexibilität offeriert und gleichzeitig neue Herausforderungen in Bezug auf die Work-Life-Balance mit sich bringt. Marissa Goldberg zeigt in ihrem jüngsten Artikel auf, wie man Flexibilität im Arbeitsleben erreichen kann, ohne dabei die Gesundheit zu gefährden.

Flexibilität in der Realität

Goldberg beschreibt ein häufiges Missverständnis: Während sie die flexible Arbeitsweise befürwortet, wurde sie dafür kritisiert, E-Mails zu ungewöhnlichen Zeiten zu bearbeiten. Dabei wird oft vernachlässigt, dass Goldberg als Mutter während des Tages auch Familienverpflichtungen wahrnehmen muss. Sie argumentiert, dass Flexibilität nicht durch feste Arbeitszeiten, sondern durch individuell angepasste Strukturen erreicht wird.

Sidecars in Kubernetes: Der Schlüssel zur Erweiterung Ihrer Anwendungen

Fri, 25 Apr 2025 02:00:00 +0000

Kubernetes hat sich als die bevorzugte Plattform für die Bereitstellung komplexer, verteilter Systeme etabliert. Eine der mächtigsten, aber auch subtilsten Entwurfsmuster in diesem Ökosystem ist das Sidecar-Muster. Es ermöglicht Entwicklern, die Funktionalität von Anwendungen zu erweitern, ohne tief in den Quellcode eintauchen zu müssen.

Die Ursprünge des Sidecar-Musters

Stellen Sie sich ein Sidecar wie einen treuen Begleiter an einem Motorrad vor. Historisch gesehen haben IT-Infrastrukturen immer Hilfsdienste genutzt, um kritische Aufgaben zu erledigen. Vor Containern arbeiteten wir mit Hintergrundprozessen und Hilfsdiensten, um Logging, Monitoring und Netzwerkverwaltung zu steuern. Die Revolution der Microservices hat diesen Ansatz transformiert und das Sidecar-Muster zu einer strukturierten und zielgerichteten architektonischen Wahl gemacht. Mit dem Aufstieg der Microservices wurde das Sidecar-Muster klarer definiert. Entwickler können spezifische Verantwortlichkeiten vom Hauptdienst abladen, ohne dessen Code zu ändern. Service-Meshes wie Istio und Linkerd haben Sidecar-Proxys populär gemacht und gezeigt, wie diese Begleitcontainer elegant Observierbarkeit, Sicherheit und Verkehrsmanagement in verteilten Systemen handhaben können.

EU stärkt digitale Souveränität: Neue Schwachstellendatenbank als Antwort auf CVE-Unsicherheiten

Thu, 17 Apr 2025 12:44:14 +0000

CVE-Aus abgewendet – doch Europa geht eigene Wege. Mit der neuen Schwachstellendatenbank der ENISA stärkt die EU ihre digitale Souveränität. ayedo zeigt, wie modernes Schwachstellenmanagement funktioniert.

In letzter Minute: CVE bleibt – vorerst

In der globalen IT-Security-Welt hat sich am 16. April 2025 etwas Entscheidendes bewegt: Die drohende Abschaltung des CVE-Systems (Common Vulnerabilities and Exposures) konnte offenbar abgewendet werden. Laut Berichten wurde der Vertrag zwischen der US-amerikanischen Cybersecurity-Behörde CISA und dem Betreiber MITRE kurzfristig verlängert – eine Maßnahme in buchstäblich letzter Minute.

ZenDiS in der Krise: Warum die Abberufung von Jutta Horstmann ein Warnsignal für Open Source ist

Thu, 17 Apr 2025 09:41:10 +0000

Die plötzliche Abberufung von Jutta Horstmann als Geschäftsführerin des Zentrums für Digitale Souveränität (ZenDiS) wirft fundamentale Fragen zur strategischen Ausrichtung der öffentlichen IT in Deutschland auf. Wo bleibt die digitale Souveränität, wenn die Visionäre gehen?

Ein Rückschritt zur Unzeit

Mitten in einer Phase, in der Open-Source-Initiativen in der öffentlichen Verwaltung endlich Fahrt aufnehmen, überrascht das Bundesinnenministerium (BMI) mit einer Entscheidung, die nicht nur irritiert, sondern ernsthafte Zweifel an der digitalen Agenda der Bundesregierung weckt. Jutta Horstmann, eine anerkannte OSS-Expertin und langjährige Fürsprecherin freier Software, wurde ohne konkrete Begründung von ihrer Rolle im ZenDiS abberufen.

US-Kürzungen bei CVE: Wenn digitale Sicherheit zur Verhandlungsmasse wird

Wed, 16 Apr 2025 11:04:16 +0000

Die US-Finanzierung für die CVE-Liste wird per sofort gestoppt – mit potenziell dramatischen Folgen für globale IT-Sicherheit. Warum Europa jetzt digitale Souveränität beweisen muss.

Ein Weckruf für IT-Sicherheitsverantwortliche in Europa

Die Common Vulnerabilities and Exposures (CVE)-Liste bildet das Rückgrat koordinierter IT-Sicherheitsmaßnahmen weltweit. Sie ist nicht nur ein technischer Standard, sondern ein strategisches Instrument zur kollektiven Cyberabwehr. Nun steht sie vor dem Aus – zumindest in der heutigen Form. Die US-Regierung hat die Finanzierung für das Projekt gestoppt. Und das mit sofortiger Wirkung.

Polycrate: Automatisierte Infrastruktur in modularen Paketen

Wed, 16 Apr 2025 09:25:22 +0000

Automatisierung muss wieder beherrschbar werden. Mit Polycrate bauen wir bei ayedo ein Framework, das Ordnung ins Chaos komplexer IT-Infrastrukturen bringt – modular, wiederverwendbar und vollständig automatisierbar.

In diesem Beitrag zeigen wir, wie Polycrate funktioniert, wie man es produktiv einsetzt und warum wir glauben: “Modular Infrastructure as Code” ist das nächste Level von GitOps.

Was ist Polycrate?

Polycrate ist ein leichtgewichtiges Framework zur Paketierung, Integration und Automatisierung von IT- und Cloud-Infrastruktur. Es verbindet:

Infrastruktur, die mitdenkt: Wie wir Betrieb und Automatisierung neu gedacht haben

Tue, 15 Apr 2025 15:36:09 +0000

Digitale Souveränität endet nicht bei der Tool-Auswahl oder Architektur. Sie entfaltet ihre volle Wirkung erst dann, wenn der Betrieb effizient, sicher und skalierbar erfolgt. In diesem letzten Teil unserer Blogserie zeigen wir, wie wir bei ayedo unsere Infrastruktur automatisiert und selbstbedienbar gemacht haben – ganz ohne Vendor-Overhead.

Warum Automatisierung essenziell ist

Viele IT-Teams arbeiten heute noch wie vor zehn Jahren:

Konfiguration per Hand,
Wartung über Tickets,
Änderungen ohne Versionierung.

In komplexen, dynamischen Infrastrukturen ist das nicht nur ineffizient, sondern riskant. Unser Ansatz: Automatisierung als Default – nicht als nachgelagerter Bonus.

Architektur statt Abhängigkeit: So sieht unsere Infrastruktur heute aus

Tue, 15 Apr 2025 15:22:48 +0000

Digitale Souveränität ist kein Feature – sie ist ein Architekturprinzip. Nachdem wir unsere Toolchain auf Open Source umgestellt haben, stand der nächste Schritt an: Die Infrastruktur hinter den Tools strategisch neu denken.

In diesem Beitrag zeigen wir, wie unsere moderne IT-Architektur aussieht – container-basiert, automatisiert, skalierbar und vollständig unter unserer Kontrolle.

Warum Infrastruktur der Schlüssel zur Freiheit ist

Viele Unternehmen ersetzen zwar einzelne Tools, bleiben aber strukturell abhängig:

von hyperskalierenden Cloud-Anbietern,
von undurchsichtigen Blackbox-Diensten,
von starren Hosting-Modellen.

Unser Ziel war klar: Ein Fundament schaffen, das uns maximale Kontrolle, Flexibilität und Zukunftssicherheit bietet.

Raus aus dem SaaS-Labyrinth: Unsere Open-Source-Alternativen im Alltag

Tue, 15 Apr 2025 15:07:17 +0000

Digitale Souveränität beginnt mit konkreten Entscheidungen. In diesem Beitrag zeigen wir, wie wir bei ayedo zentrale SaaS-Tools durch leistungsfähige Open-Source-Lösungen ersetzt haben – und was wir dabei gelernt haben.

Warum der Werkzeugkasten zählt

In der Diskussion um digitale Eigenständigkeit geht es oft um große Strategien – doch der Wandel beginnt bei den täglichen Werkzeugen:

Wo planen wir unsere Projekte?
Wie organisieren wir interne Kommunikation?
Wo liegen unsere Dokumente – und wer hat Zugriff?

Wir zeigen: Es geht auch anders. Und es funktioniert.

Schluss mit SaaS-Knechtschaft: Warum wir auf digitale Eigenständigkeit setzen

Tue, 15 Apr 2025 10:19:14 +0000

Die Abhängigkeit von US-SaaS-Anbietern kostet deutsche Unternehmen zunehmend Kontrolle, Geld und Innovationskraft. ayedo zeigt, wie Open Source zur strategischen Alternative wird – für mehr digitale Souveränität, Flexibilität und Effizienz.

Einleitung: Die wachsende Abhängigkeit wird zum Risiko

In vielen Unternehmen hat sich über Jahre eine starke Abhängigkeit von US-amerikanischen SaaS-Anbietern entwickelt. Was als praktisches Lizenzmodell begann, entpuppt sich zunehmend als digitale Sackgasse:

Kosten steigen durch Preisanpassungen, Nutzerstaffelungen und eingeschränkte Exportmöglichkeiten.
Funktionen werden künstlich beschnitten, um Premium-Pläne zu verkaufen.
Datenkontrolle und Datenschutz liegen oft jenseits europäischer Standards.
Digitale Zusatzsteuern stehen bereits in politischen Diskussionen.

Diese Entwicklung betrifft längst nicht nur Konzerne – auch mittelständische Unternehmen stehen vor einem Wendepunkt.

Microsoft verabschiedet sich von klassischen Servermodellen – Was nun?

Fri, 11 Apr 2025 07:17:21 +0000

Microsoft verabschiedet sich von klassischen Servermodellen – Was nun?

Ab Juli 2025 verändert sich das Lizenzmodell für Microsofts On-Premise-Produkte grundlegend: Preise für lokale Serverlösungen wie Exchange, SharePoint oder Skype for Business steigen um bis zu 20 %, dauerhafte Kauflizenzen werden eingestellt. Die Stoßrichtung ist eindeutig: Der Weg führt in die Cloud.

Eine strategische Weichenstellung – mit Konsequenzen

Microsofts Argument: On-Premise-Produkte verursachen hohe Entwicklungs- und Wartungskosten. Die Folge ist ein klarer Fokus auf Cloud-Dienste. Für Unternehmen mit sensiblen oder geschäftskritischen Systemen stellt sich jedoch die Frage: Ist die Public Cloud wirklich der richtige Ort für meine Daten und Workloads?

Kube-Scheduler-Simulator: Der Schlüssel zu besserem Scheduling in Kubernetes

Thu, 10 Apr 2025 02:00:00 +0000

Der Kubernetes Scheduler ist ein entscheidendes Element im Control Plane, das bestimmt, auf welchem Node ein Pod ausgeführt wird. Jede Person, die Kubernetes nutzt, verlässt sich auf einen Scheduler.

Der kube-scheduler-simulator ist ein Simulator für den Kubernetes Scheduler, der als Projekt im Google Summer of Code 2021 gestartet wurde und von mir (Kensei Nakada) entwickelt wurde. Diese Anwendung ermöglicht es Nutzern, das Verhalten und die Entscheidungen des Schedulers genau zu untersuchen.

Er ist nützlich für Gelegenheitsnutzer, die Scheduling-Bedingungen verwenden (zum Beispiel Inter-Pod-Affinitäten) sowie für Experten, die den Scheduler mit benutzerdefinierten Plugins erweitern.

Docker vs Kubernetes

Fri, 28 Mar 2025 11:44:36 +0000

Kubernetes vs. Docker – Warum du beides brauchst und nicht gegeneinander ausspielst

Die Frage, ob man Kubernetes oder Docker verwenden sollte, ist vollkommen falsch gestellt. Die beiden Technologien konkurrieren nicht miteinander, sondern ergänzen sich perfekt. Beide haben ihren Platz und ihre spezifische Rolle in modernen Infrastruktur- und DevOps-Umgebungen. Wer sie als Alternativen betrachtet, hat entweder noch nicht viel mit Containern gearbeitet oder ist auf der Suche nach einer schnellen Antwort ohne den notwendigen Kontext.

IngressNightmare: Kritische RCE-Sicherheitslücken in Ingress NGINX bedrohen Kubernetes-Cluster

Wed, 26 Mar 2025 17:07:13 +0000

Einleitung

In der Welt der Kubernetes-Orchestrierung spielt der Ingress NGINX Controller eine zentrale Rolle, da er als Gateway für den Datenverkehr zu den Applikationen innerhalb des Clusters dient. Jüngste Entdeckungen von Sicherheitsforschern zeigen jedoch, dass dieser essenzielle Bestandteil von Kubernetes erhebliche Sicherheitsrisiken birgt.

Forscher von Wiz Research haben eine Reihe von Remote Code Execution (RCE)-Schwachstellen aufgedeckt , die unter dem Namen IngressNightmare bekannt geworden sind. Die betroffenen CVEs (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 und CVE-2025-1974) erreichen einen CVSS-Score von 9.8, was sie zu kritischen Bedrohungen macht.

JobSet: Die neue Lösung für verteilte ML- und HPC-Workloads in Kubernetes

Wed, 26 Mar 2025 01:00:00 +0000

In der Welt der Kubernetes-Entwicklung gibt es spannende Neuigkeiten: JobSet wurde eingeführt, eine Open-Source-API, die speziell für die Verwaltung verteilter Jobs entwickelt wurde. Ziel von JobSet ist es, eine einheitliche API für das verteilte Training von Machine Learning (ML) und High-Performance-Computing (HPC) Workloads auf Kubernetes bereitzustellen.

Warum JobSet?

Die jüngsten Verbesserungen im Batch-Ökosystem von Kubernetes haben das Interesse von ML-Ingenieuren geweckt, die festgestellt haben, dass Kubernetes hervorragend für die Anforderungen an verteilte Trainings-Workloads geeignet ist.

Die Geheimnisse des SIG etcd: Einblicke in die Kubernetes-Welt

Fri, 07 Mar 2025 01:00:00 +0000

Ein Blick auf SIG etcd

In diesem Artikel werfen wir einen Blick auf die Kubernetes Special Interest Group (SIG) etcd. Wir haben mit einigen der Hauptakteure gesprochen, um mehr über ihre Rollen und ihre Motivation für die Arbeit an etcd zu erfahren.

Wer sind die Mitglieder von SIG etcd?

Benjamin: Hallo, ich bin Benjamin. Ich bin der technische Leiter von SIG etcd und einer der Maintainer von etcd. Ich arbeite bei VMware, das zur Broadcom-Gruppe gehört. Mein Interesse an Kubernetes, etcd und CSI (Container Storage Interface) begann 2020, sowohl aus beruflichem Interesse als auch aus meiner Leidenschaft für Open Source.

Mit nftables zu besserer Performance: kube-proxy neu gedacht

Mon, 03 Mar 2025 01:00:00 +0000

Einleitung

In der Welt von Kubernetes gibt es stetige Entwicklungen, die die Performance und Effizienz von Anwendungen verbessern. Eine der spannendsten Neuerungen ist die Einführung des nftables-Modus für kube-proxy in Kubernetes 1.29, der nun in der Beta-Phase ist und voraussichtlich in Version 1.33 als stabiler Bestandteil verfügbar sein wird. Diese neue Funktion zielt darauf ab, die langjährigen Performanceprobleme des bisherigen iptables-Modus zu beheben.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die Verwendung von nftables bringt signifikante Verbesserungen mit sich, insbesondere in Bezug auf die Latenz beim Datenverkehr. Der iptables-Modus war ursprünglich für einfache Firewall-Anwendungen konzipiert und hat Schwierigkeiten, mit der Vielzahl an Services in großen Kubernetes-Clustern umzugehen. Je mehr Services vorhanden sind, desto mehr Regeln müssen im iptables-Modus verarbeitet werden, was die Latenz bei der ersten Anfrage negativ beeinflusst.

Das Henne-Ei-Problem des Cloud Controller Managers in Kubernetes

Mon, 17 Feb 2025 01:00:00 +0000

Kubernetes 1.31 hat die größte Migration in der Geschichte von Kubernetes abgeschlossen und dabei den In-Tree-Cloud-Anbieter entfernt. Obwohl die Migration der Komponenten nun abgeschlossen ist, bringt dies zusätzliche Komplexität für Benutzer und Installationsprojekte wie kOps oder Cluster API mit sich. In diesem Artikel gehen wir auf die zusätzlichen Schritte und mögliche Fehlerquellen ein und geben Empfehlungen für Cluster-Besitzer. Diese Migration war komplex und erforderte die Extraktion einiger Logik aus den Kernkomponenten, was zur Bildung von vier neuen Subsystemen führte.

Transatlantischer Datentransfer in der Krise: Was bedeutet das für Unternehmen?

Sun, 09 Feb 2025 17:07:13 +0000

Die unsichere Zukunft des EU-US-Datentransfers

Die regulatorische Unsicherheit rund um den Datenaustausch zwischen der EU und den USA nimmt erneut zu. Nachdem US-Präsident Donald Trump drei Mitglieder der Datenschutzaufsichtsbehörde PCLOB entlassen hat, steht das Transatlantic Data Privacy Framework (TADPF) auf wackligen Beinen. Sollte der Angemessenheitsbeschluss der EU für Datenübermittlungen in die USA gekippt werden, drohen europäischen Unternehmen erhebliche rechtliche und organisatorische Herausforderungen.

Pod-Ausfälle in Kubernetes: So meistern Sie die Herausforderungen mit spezialisierten Geräten

Fri, 17 Jan 2025 01:00:00 +0000

Kubernetes ist der De-facto-Standard für die Orchestrierung von Containern, doch wenn es um den Umgang mit spezialisierter Hardware wie GPUs und anderen Beschleunigern geht, wird es kompliziert. In diesem Artikel gehen wir auf die Herausforderungen ein, die beim Management von Ausfallmodi auftreten, wenn Pods mit Geräten in Kubernetes betrieben werden.

Auswirkungen auf Entwickler und DevOps-Teams

Der Boom von AI/ML-Anwendungen bringt neue Herausforderungen für Kubernetes mit sich. Diese Workloads sind oft stark von spezialisierter Hardware abhängig, und ein Ausfall von Geräten kann die Leistung erheblich beeinträchtigen und zu frustrierenden Unterbrechungen führen. Laut dem 2024 veröffentlichten Llama-Paper sind Hardwareprobleme, insbesondere GPU-Ausfälle, eine der Hauptursachen für Störungen im AI/ML-Training.

Kubernetes optimieren: Wie API-Streaming die Effizienz steigert

Fri, 20 Dec 2024 01:00:00 +0000

Effizientes Management von Kubernetes-Clustern wird zunehmend wichtiger, insbesondere bei wachsender Clustergröße. Eine der größten Herausforderungen bei großen Clustern ist der Speicheraufwand, der durch list-Anfragen verursacht wird.

In der aktuellen Implementierung verarbeitet der kube-apiserver list-Anfragen, indem er die gesamte Antwort im Speicher zusammenstellt, bevor er Daten an den Client überträgt. Aber was passiert, wenn der Antwortinhalt umfangreich ist, sagen wir mehrere hundert Megabyte? Und stellen Sie sich vor, mehrere list-Anfragen treffen gleichzeitig ein, vielleicht nach einem kurzen Netzwerk-Ausfall. Während API Priority and Fairness sich als wirksam erwiesen hat, um den kube-apiserver vor CPU-Überlastung zu schützen, ist der Einfluss auf den Spe Schutz sichtbar geringer. Dies kann durch die unterschiedliche Natur des Ressourcenverbrauchs einer einzelnen API-Anfrage erklärt werden - die CPU-Nutzung zu einem bestimmten Zeitpunkt ist durch einen konstanten Wert begrenzt, während der Speicher, der nicht komprimierbar ist, proportional mit der Anzahl der verarbeiteten Objekte wachsen kann und unbegrenzt ist.

Kubernetes 1.32: Verbesserte Speichermanagement-Funktionen für Containeranwendungen

Mon, 16 Dec 2024 01:00:00 +0000

Mit Kubernetes 1.32 hat der Speichermanager offiziell den Status der allgemeinen Verfügbarkeit (GA) erreicht. Dies stellt einen bedeutenden Fortschritt in Richtung effizienter und vorhersehbarer Speicherzuweisung für containerisierte Anwendungen dar. Seit der Version 1.22, in der er in den Beta-Status überging, hat sich der Speichermanager als zuverlässig und stabil erwiesen und sich als nützliches Ergänzungsfeature zum CPU Manager etabliert.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Der Speichermanager trägt im Zuge des Zulassungsprozesses von Workloads durch den Kubelet dazu bei, die Speicherzuweisung und -ausrichtung zu optimieren. Dies ermöglicht es den Nutzern, exklusiven Speicher für Pods in der Guaranteed QoS-Klasse zuzuweisen. Die während der Beta-Phase eingeführten Änderungen konzentrieren sich hauptsächlich auf Fehlerbehebungen, interne Umstrukturierungen und Verbesserungen der Beobachtbarkeit, etwa durch neue Metriken und verbesserte Protokollierung.

Optimierung der Pod-Zuweisung: QueueingHint in Kubernetes v1.32

Sun, 15 Dec 2024 01:00:00 +0000

Der Kubernetes Scheduler ist das Herzstück, das bestimmt, auf welchen Knoten neue Pods laufen. Er verarbeitet diese neuen Pods einen nach dem anderen. Daher wird die Effizienz des Schedulers mit der Größe Ihrer Cluster immer wichtiger.

Im Laufe der Jahre hat das Kubernetes SIG Scheduling die Durchsatzrate des Schedulers durch verschiedene Verbesserungen optimiert. In diesem Artikel stellen wir eine wesentliche Neuerung des Schedulers in Kubernetes v1.32 vor: ein Scheduling-Kontextelement namens QueueingHint. Hier erfahren Sie, wie QueueingHint die Effizienz der Pod-Zuweisung verbessert.

Kubernetes v1.32: So wird die Wolke noch smarter!

Sat, 14 Dec 2024 01:00:00 +0000

Die neueste Version von Kubernetes, v1.32, bringt spannende Neuerungen und Verbesserungen mit sich! Diese Version, die auf den Namen “Penelope” hört, feiert gleichzeitig das zehnjährige Bestehen von Kubernetes und zeigt, wie weit die Community gekommen ist. Mit insgesamt 44 Verbesserungen, darunter 13 neue stabile, 12 in Beta und 19 in Alpha, ist diese Veröffentlichung ein echter Meilenstein.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die neuen Funktionen in Kubernetes v1.32 zielen darauf ab, den Alltag von Entwicklern und DevOps-Teams zu erleichtern. Besonders hervorzuheben sind die Verbesserungen in der dynamischen Ressourcenallokation (DRA), die speziell für Workloads konzipiert sind, die auf spezialisierte Hardware wie GPUs und FPGAs angewiesen sind. Diese Anpassungen bieten eine effizientere Verwaltung der Ressourcen und sind besonders wertvoll für Anwendungen im Bereich maschinelles Lernen und Hochleistungsrechnen.

Changelog: Kubernetes v1.32

Wed, 11 Dec 2024 18:00:00 +0000

Kubernetes v1.32: Optimierung Ihrer Container-Infrastruktur mit ayedo

In der dynamischen Welt der Container-Orchestrierung spielt Kubernetes eine zentrale Rolle. Bei ayedo, den Experten für Docker und Kubernetes, sind wir stets darauf bedacht, die neuesten Technologien zu integrieren, um unseren Kunden einen erstklassigen Service zu bieten. Kubernetes v1.32 bringt bedeutende Neuerungen mit sich, die unsere Fähigkeit verbessern, Ihre Container-basierte Workloads effizient und sicher zu verwalten.

API-Deprecation: Zukünftig sicher und zukunftssicher

Kubernetes v1.32 setzt stringentere Maßnahmen zur API-Deprecation um, die sicherstellen, dass Ihre Infrastruktur stets auf dem neuesten Stand bleibt. Diese Richtlinie gewährleistet eine kontinuierliche Funktionalität mit fortschrittlicheren und stabileren API-Versionen. Mit ayedo an Ihrer Seite sind Sie auf API-Änderungen vorbereitet, die durch klare Übergangsstrategien und Migrationen Ihren Betrieb ungestört fortsetzen.

Die Zukunft von Kubernetes unter NIS2 ayedos Weg zu mehr Cybersicherheit

Thu, 28 Nov 2024 09:38:36 +0000

NIS2-Richtlinie: Warum jetzt der perfekte Zeitpunkt für mehr Sicherheit ist – Ayedo zeigt den Weg

Die Einführung der NIS2-Richtlinie hat einige Wellen in der Welt der Container-Technologien geschlagen. Für Unternehmen, die auf Kubernetes setzen, bringt diese Richtlinie neue Herausforderungen mit sich. Doch bei Ayedo sehen wir weniger einen Sturm als vielmehr eine Gelegenheit, Sicherheitsstandards zu heben und die digitale Resilienz zu stärken.

Was bedeutet NIS2 für Kubernetes-Anwender?

Die neue Richtlinie fordert mehr Cybersicherheit und präzisere Incident Reporting-Prozesse. Kubernetes-Nutzer stehen vor der Aufgabe, ihre Systeme entsprechend zu erweitern und zu sichern. Hier springt Ayedo ein: Bei uns erhalten Sie nicht nur Unterstützung bei der Implementierung, sondern auch bei der laufenden Betreuung Ihrer Container-Infrastrukturen. Sei es On-Premise oder in der Cloud, wir sind zertifiziert nach ISO/IEC 27001:2022 und bieten Lösungen, die diesen neuen Anforderungen gerecht werden.

Gateway API v1.2: Neue Funktionen für Entwickler und DevOps-Teams

Sun, 24 Nov 2024 01:00:00 +0000

Kubernetes SIG Network freut sich, die allgemeine Verfügbarkeit von Gateway API v1.2 bekannt zu geben! Diese Version der API wurde am 3. Oktober veröffentlicht und wir sind begeistert, dass es mittlerweile mehrere konforme Implementierungen gibt, die Sie ausprobieren können.

Gateway API v1.2 bringt zahlreiche neue Funktionen in den Standard-Kanal (dem GA-Release-Kanal der Gateway API), führt einige neue experimentelle Features ein und feiert unseren neuen Release-Prozess – allerdings gibt es auch zwei Breaking Changes, auf die Sie achten sollten.

Kubernetes Training in Japan: So wirst du zum Contributor!

Thu, 31 Oct 2024 01:00:00 +0000

Wir sind die Organisatoren des Kubernetes Upstream Trainings in Japan. Unser Team besteht aus Mitgliedern, die aktiv zu Kubernetes beitragen, darunter Rollen wie Mitglied, Reviewer, Approver und Chair.

Unser Ziel ist es, die Anzahl der Kubernetes-Beitragenden zu erhöhen und das Wachstum der Community zu fördern. Obwohl die Kubernetes-Community freundlich und kooperativ ist, können Neulinge den ersten Schritt zur Mitwirkung als etwas herausfordernd empfinden. Unser Trainingsprogramm soll diese Hürde senken und eine Umgebung schaffen, in der selbst Anfänger reibungslos teilnehmen können.

Ollama auf eigenen Servern im Rechenzentrum mit Continue in VSCode als Copilot-Alternative

Wed, 09 Oct 2024 13:07:13 +0000

Einleitung

In der heutigen Softwareentwicklung, in der KI-gestützte Tools wie GitHub Copilot und ähnliche Assistenten unterstützen, suchen viele Entwickler nach flexibleren und datenschutzfreundlicheren Alternativen. Eine spannende Möglichkeit bietet die Kombination aus Ollama und Continue. Diese Lösung erlaubt es Entwicklern, ihre KI-gestützten Coder-Assistenten vollständig unabhängig von externen Cloud-Diensten zu betreiben.

Visual Studio Code (VSCode)

VSCode ist ein freier, quelloffener Texteditor von Microsoft, der aufgrund seiner Erweiterbarkeit und der großen Auswahl an Plugins (Extensions) besonders beliebt bei Entwicklern ist. Es bietet Unterstützung für verschiedene Programmiersprachen und Funktionen wie Debugging, Git-Integration und intelligente Codevervollständigung. Mit seiner Erweiterungsfähigkeit können KI-basierte Tools wie Continue nahtlos integriert werden, um den Codierprozess zu beschleunigen.

Maximale Datensouveränität mit unserer internen RAG-Lösung und der ayedo Cloud

Mon, 07 Oct 2024 10:35:36 +0000

Maximale Datensouveränität mit unserer internen RAG-Lösung und der ayedo Cloud

Einleitung

In der heutigen digitalen Ära ist der effiziente Umgang mit großen Datenmengen entscheidend für den Geschäftserfolg. Retrieval-Augmented Generation (RAG) hat sich als revolutionäre Methode etabliert, um KI-gesteuerte Systeme mit aktuellen und spezifischen Informationen zu versorgen. Doch was genau ist RAG und welche Vorteile bietet es für Ihr Unternehmen?

Was ist RAG?

RAG kombiniert die Stärken von Informationsabrufsystemen mit generativen KI-Modellen. Dabei werden relevante Informationen aus einer Wissensdatenbank abgerufen und in die Erstellung von Antworten integriert. Das Ergebnis sind präzise und kontextbezogene Antworten, die stets auf den neuesten Daten basieren.

Inklusion im Tech-Bereich: Die DHHWG und ihre Bedeutung für Kubernetes

Tue, 24 Sep 2024 02:00:00 +0000

Einleitung

Im Rahmen des Deaf Awareness Month rückt die CNCF Deaf and Hard-of-Hearing Working Group (DHHWG) ins Rampenlicht. Wir werfen einen Blick auf die inspirierende Arbeit von Catherine Paganini, einer der Gründerinnen dieser Gruppe, und Sandeep Kanabar, einem gehörlosen Mitglied, das die Bedeutung von Inklusion in der Tech-Community verdeutlicht.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die DHHWG setzt sich dafür ein, die Cloud-Native-Projekte wie Kubernetes für alle zugänglicher zu machen. Dies geschieht durch die Schaffung von Wegen, die es unterrepräsentierten Gruppen, einschließlich Menschen mit Behinderungen, ermöglichen, ihre einzigartigen Perspektiven und Fähigkeiten einzubringen. Die Initiative fördert nicht nur das Bewusstsein für Barrierefreiheit, sondern schafft auch eine Umgebung, in der Empathie und Unterstützung im Vordergrund stehen.

Kubernetes 1.31: Präzise Kontrolle über Gruppenmitgliedschaften in Pods

Sun, 25 Aug 2024 02:00:00 +0000

Kubernetes 1.31 bringt eine spannende neue Funktion mit sich, die die Handhabung von Gruppenmitgliedschaften in Containern innerhalb von Pods verbessert. Diese Änderung zielt darauf ab, die Kontrolle über Gruppenmitgliedschaften zu verfeinern und potenzielle Sicherheitsrisiken zu minimieren.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Mit der Einführung des neuen Feldes supplementalGroupsPolicy im .spec.securityContext eines Pods wird die Art und Weise, wie Gruppenmitgliedschaften für Containerprozesse berechnet werden, optimiert. Entwickler und DevOps-Teams haben nun die Möglichkeit, zwischen zwei Politiken zu wählen:

Kubernetes v1.31: Optimierte CPU-Verteilung für mehr Leistung auf Multi-Core-Prozessoren

Sun, 25 Aug 2024 02:00:00 +0000

In Kubernetes v1.31 freuen wir uns, eine bedeutende Verbesserung im CPU-Management vorzustellen: die Option distribute-cpus-across-cores für die CPUManager statische Richtlinie. Diese Funktion befindet sich derzeit in der Alpha-Phase und ist standardmäßig verborgen. Sie markiert einen strategischen Wandel, der darauf abzielt, die CPU-Auslastung zu optimieren und die Systemleistung auf Multi-Core-Prozessoren zu verbessern.

Verständnis der Funktion

Traditionell tendiert der CPUManager von Kubernetes dazu, CPUs so kompakt wie möglich zuzuweisen, indem er sie in der Regel auf die geringste Anzahl physischer Kerne packt. Diese Zuweisungsstrategie ist entscheidend, da CPUs auf demselben physischen Host weiterhin einige Ressourcen des physischen Kerns teilen, wie z.B. den Cache und die Ausführungseinheiten.

ESCRA und ayedo revolutionieren ZTNA mit Kubernetes und Cloud-Hosting

Thu, 04 Jul 2024 11:45:36 +0000

Erfolgreiche Partnerschaft: ESCRA und ayedo revolutionieren ZTNA mit Kubernetes und Cloud-Hosting

Strategische Partnerschaften sind entscheidend, um Stärken zu bündeln und gemeinsam zu wachsen. Ein herausragendes Beispiel hierfür ist die Zusammenarbeit zwischen ESCRA, einem aufstrebenden Startup, das ZTNA (Zero Trust Network Access) Fernzugriffslösungen anbietet, und uns, ayedo, einem innovativen Anbieter von Cloud-Hosting- und Kubernetes-Management-Dienstleistungen. Diese Partnerschaft hat nicht nur die individuellen Angebote beider Unternehmen gestärkt, sondern auch neue Maßstäbe in der Branche gesetzt.

Wie bewältigt man 160 Millionen User im Monat? Mit K8s und Docker!

Mon, 01 Jul 2024 17:07:13 +0000

Hochverfügbare SaaS-Infrastruktur für mehr als 2 Milliarden Requests pro Monat

In der heutigen digitalisierten Welt sind Ausfallsicherheit und Skalierbarkeit unverzichtbare Merkmale jeder erfolgreichen Software-as-a-Service (SaaS)-Plattform. Prime Insights, ein führender Anbieter von Datenanalyselösungen, erkannte diesen Bedarf frühzeitig und suchte nach einer fortschrittlichen Infrastruktur, um seine rasant wachsende Anzahl von Nutzeranfragen effizient zu bewältigen. Hier kommt ayedo ins Spiel – unsere Experten entwickelten und betreiben eine hochverfügbare, geo-redundante SaaS-Infrastruktur, die den Anforderungen von Prime Insights gerecht wird.

Schutz vor Cyber-Bedrohungen: Ein umfassender Leitfaden zum Cyber Risiko Check

Thu, 13 Jun 2024 11:45:36 +0000

![Schutz vor Cyber-Bedrohungen: Ein umfassender Leitfaden zum Cyber Risiko Check] (ein-umfassender-leitfaden-zum-cyber-risiko-check.png)

Ein effektiver Weg, um diese Risiken zu minimieren, ist der Cyber Risiko Check. In diesem Blogpost erfahren Sie, was ein Cyber Risiko Check ist, warum er wichtig ist und wie ayedo Ihnen dabei helfen kann, Ihre Sicherheitsmaßnahmen zu optimieren.

Was ist ein Cyber Risiko Check?

Ein Cyber Risiko Check ist ein systematischer Prozess zur Bewertung der Sicherheitslage eines Unternehmens. Dabei werden potenzielle Sicherheitslücken identifiziert und Maßnahmen zur Risikominderung vorgeschlagen. Der Check umfasst die Analyse von Technologien, Prozessen und Mitarbeiterverhalten, um eine umfassende Sicherheitsstrategie zu entwickeln.

Compliance leicht gemacht: Die ISO27001 als Schlüssel zur Einhaltung gesetzlicher Vorschriften

Mon, 10 Jun 2024 11:45:36 +0000

Compliance leicht gemacht: Die ISO27001 als Schlüssel zur Einhaltung gesetzlicher Vorschriften

Die Einhaltung gesetzlicher Anforderungen und Datenschutzrichtlinien ist für Unternehmen eine ständige Herausforderung. ISO 27001, der internationale Standard für Informationssicherheits-Managementsysteme (ISMS), bietet eine umfassende Lösung für diese Herausforderung. Doch wie genau kann ISO 27001 Ihrem Unternehmen helfen, gesetzliche Vorschriften leichter einzuhalten?

Was ist die ISO27001?

ISO 27001 ist ein international anerkannter Standard, der die Anforderungen an die Einrichtung, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines ISMS festlegt. Ziel ist es, die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen durch einen risikobasierten Ansatz zu gewährleisten.

Baserow mit Traefik-Labels bereitstellen und unter DNS-Eintrag nutzen

Sun, 09 Jun 2024 17:07:13 +0000

Einleitung

In diesem Beitrag zeigen wir dir, wie du Baserow mithilfe von Docker Compose und Traefik bereitstellen und es über einen DNS-Eintrag wie https://data.deine-domain.org zugänglich machen kannst. Diese Konfiguration ermöglicht eine einfache und sichere Bereitstellung deiner Low-Code-Datenbankplattform.

Vorstellung von Traefik

Traefik ist ein leistungsstarker Reverse-Proxy und Load-Balancer, der die Verwaltung und Bereitstellung von Microservices erleichtert. Er ermöglicht die automatische Erkennung von Diensten und die Verwaltung von SSL/TLS-Zertifikaten. Mehr Details und ein umfassendes Tutorial findest du in unserem Traefik-Tutorial.

getHomepage mit Traefik-Labels bereitstellen und unter DNS-Eintrag nutzen

Sun, 09 Jun 2024 17:07:13 +0000

In diesem Beitrag zeigen wir dir, wie du die Dashboard-App getHomepage mit Docker Compose und Traefik bereitstellst und sie über einen DNS-Eintrag wie https://my.deine-domain.org erreichst. Diese Konfiguration ermöglicht eine einfache und zentrale Verwaltung deiner SaaS-Tools.

Vorstellung von Traefik

Traefik ist ein dynamischer Reverse-Proxy und Load-Balancer, der speziell für moderne Anwendungen entwickelt wurde. Er ermöglicht die automatische Erkennung von Diensten und das einfache Verwalten von SSL/TLS-Zertifikaten. Mehr Details findest du in unserem Traefik-Tutorial.

Mattermost mit Traefik-Labels bereitstellen und unter DNS-Eintrag nutzen

Sun, 09 Jun 2024 17:07:13 +0000

Einleitung

In diesem Beitrag zeigen wir dir, wie du Mattermost mit Docker Compose und Traefik bereitstellst und es über einen DNS-Eintrag wie https://chat.deine-domain.org erreichst. Diese Konfiguration ermöglicht eine einfache und sichere Bereitstellung deiner Kommunikationsplattform.

Vorstellung von Traefik

Traefik ist ein dynamischer Reverse-Proxy und Load-Balancer, der speziell für Microservices und moderne Cloud-native Anwendungen entwickelt wurde. Er ermöglicht die automatische Service-Erkennung und Verwaltung von SSL/TLS-Zertifikaten. Für weitere Details und ein umfassendes Tutorial besuche unser Traefik-Tutorial.

Paperless-ngx mit Traefik-Labels bereitstellen und unter DNS-Eintrag nutzen

Sun, 09 Jun 2024 17:07:13 +0000

Einleitung

In diesem Beitrag zeigen wir dir, wie du Paperless-ngx mit Docker Compose und Traefik bereitstellst und es über einen DNS-Eintrag wie https://docs.deine-domain.org erreichst. Diese Konfiguration ermöglicht eine einfache und sichere Bereitstellung deiner digitalen Dokumentenmanagement-Plattform.

Vorstellung von Traefik

Vor zehn Jahren, am 6. Juni 2014, wurde der erste Commit von Kubernetes auf GitHub veröffentlicht. Dieser erste Commit, der 250 Dateien und 47.501 Zeilen Go, Bash und Markdown umfasste, läutete das Projekt ein, das wir heute kennen. Wer hätte damals gedacht, dass Kubernetes zehn Jahre später zu einem der größten Open-Source-Projekte mit über 88.000 Mitwirkenden aus mehr als 8.000 Unternehmen in 44 Ländern heranwachsen würde?

Dieser Meilenstein ist nicht nur für Kubernetes bedeutend, sondern auch für das Cloud-Native-Ökosystem, das daraus entstanden ist. Innerhalb der CNCF existieren nahezu 200 Projekte, mit Beiträgen von über 240.000 individuellen Mitwirkenden und noch vielen weiteren in der erweiterten Community. Kubernetes wäre nicht dort, wo es heute steht, ohne diese Gemeinschaft, die über 7 Millionen Entwickler und die noch größere Benutzerbasis umfasst, die alle geholfen haben, das Ökosystem zu gestalten, das wir heute kennen.

Sichere Daten durch den Cyber Risiko Check: So schützen Sie Ihr Unternehmen effektiv

Mon, 03 Jun 2024 11:45:36 +0000

![Sichere Daten durch den Cyber Risiko Check: So schützen Sie Ihr Unternehmen effektiv] (cyber-risiko-check-so-schuetzen-sie-ihr-unternehmen-effektiv.png)

Der Schutz sensibler Daten ist daher von größter Bedeutung. Ein Cyber Risiko Check ist ein effektives Mittel, um die Sicherheitslage Ihres Unternehmens zu bewerten und zu verbessern. In diesem Blogpost erfahren Sie, wie der Cyber Risiko Check von ayedo Ihnen dabei helfen kann, Ihre Daten sicher zu halten.

Was ist ein Cyber Risiko Check?

Ein Cyber Risiko Check ist ein systematischer Prozess zur Bewertung der Cybersicherheit eines Unternehmens. Dabei werden potenzielle Schwachstellen identifiziert, Risiken bewertet und Maßnahmen zur Risikominderung vorgeschlagen. Ziel ist es, eine robuste Sicherheitsstrategie zu entwickeln, die Ihre sensiblen Daten schützt.

ayedo Cloud: Performance-Optimierung für cloud-native Anwendungen

Tue, 28 May 2024 11:45:36 +0000

ayedo Cloud: Performance-Optimierung für cloud-native Anwendungen

Die Leistung cloud-nativer Anwendungen ist ein entscheidender Faktor für den Geschäftserfolg. ayedo Cloud bietet spezialisierte Lösungen zur Performance-Optimierung, die sicherstellen, dass Ihre Anwendungen stets effizient und zuverlässig laufen. In diesem Artikel beleuchten wir die verschiedenen Features und Strategien von ayedo Cloud, die zur Leistungssteigerung beitragen.

1. Hochleistungsinfrastruktur

Moderne Hardware und Netzwerktechnologien

State-of-the-Art Hardware: ayedo Cloud setzt auf moderne Hardwarekomponenten, um maximale Leistung und Zuverlässigkeit zu gewährleisten. Dies umfasst leistungsstarke Prozessoren, schnelle SSDs und hochverfügbare Netzwerktechnologien.
Optimierte Netzwerkkonnektivität: Durch den Einsatz fortschrittlicher Netzwerktechnologien und redundanter Verbindungen bietet ayedo Cloud niedrige Latenzzeiten und hohe Bandbreiten, was die Datenübertragung beschleunigt.

2. Automatische Skalierung

Dynamische Ressourcenanpassung

Die treibende Kraft hinter Kubernetes: Ein Blick auf SIG Node

Fri, 24 May 2024 02:00:00 +0000

In der Welt der Container-Orchestrierung ist Kubernetes die unangefochtene Nummer eins und treibt einige der komplexesten und dynamischsten Anwendungen weltweit an. Hinter den Kulissen sorgt ein Netzwerk aus Special Interest Groups (SIGs) für die Innovation und Stabilität von Kubernetes.

Heute haben wir das Vergnügen, mit Matthias Bertschy, Gunju Kim und Sergey Kanzhelev zu sprechen, Mitgliedern von SIG Node, die uns Einblicke in ihre Rollen, Herausforderungen und spannende Entwicklungen innerhalb von SIG Node geben werden.

Einführungen

Arpit: Vielen Dank, dass Sie heute bei uns sind. Können Sie sich bitte kurz vorstellen und einen Überblick über Ihre Rollen innerhalb von SIG Node geben?

Cyber Risiko Check: Die wichtigsten Schritte zur Verbesserung Ihrer Cybersicherheit

Mon, 20 May 2024 10:38:36 +0000

Die Bedrohungen im Bereich der Cybersicherheit nehmen ständig zu, und Unternehmen stehen vor der Herausforderung, ihre sensiblen Daten zu schützen. Ein Cyber Risiko Check ist ein wesentlicher Prozess, um die Sicherheitslage Ihres Unternehmens zu bewerten und zu verbessern. In diesem Blogpost stellen wir die wichtigsten Schritte eines Cyber Risiko Checks vor und zeigen, wie ayedo Ihnen dabei helfen kann, Ihre Cybersicherheit zu optimieren.

Gateway API v1.1: Neue Features für Entwickler und DevOps-Teams!

Sun, 12 May 2024 02:00:00 +0000

Nach der allgemeinen Freigabe der Gateway API im vergangenen Oktober freut sich das Kubernetes SIG Network, die Veröffentlichung von v1.1 der Gateway API anzukündigen. In dieser Version sind mehrere Funktionen nun im Standard Channel (GA) verfügbar, darunter die Unterstützung für Service Mesh und GRPCRoute. Zudem führen wir einige neue experimentelle Funktionen ein, wie Sitzungs-Persistenz und die Überprüfung von Client-Zertifikaten.

Was ist neu?

Graduierung zum Standard

In dieser Version sind vier sehnsüchtig erwartete Funktionen zum Standard aufgestiegen. Das bedeutet, dass sie nicht länger experimentelle Konzepte sind; die Aufnahme in den Standardrelease-Kanal zeigt ein hohes Maß an Vertrauen in die API-Oberfläche und bietet Garantien für die Abwärtskompatibilität. Natürlich können Funktionen im Standard Channel weiterhin weiterentwickelt werden, wobei wir im Laufe der Zeit mit abwärtskompatiblen Ergänzungen rechnen. Weitere Informationen dazu finden Sie in der Gateway API Versioning Policy.

Der Einfluss der ISO 27001 Zertifizierung auf den Datenschutz und die Datenintegrität

Fri, 10 May 2024 11:45:36 +0000

Der Einfluss der ISO 27001 Zertifizierung auf den Datenschutz und die Datenintegrität

Datenlecks und Cyber-Angriffe sind heutzutage allgegenwärtige Bedrohungen, die Unternehmen jeder Größe betreffen können. In diesem Kontext gewinnt die ISO 27001, der internationale Standard für Informationssicherheits-Managementsysteme (ISMS), an enormer Bedeutung. Diese Zertifizierung ist nicht nur ein Qualitätssiegel für Informationssicherheit, sondern spielt auch eine wesentliche Rolle beim Schutz von Datenschutz und Datenintegrität. Doch was bedeutet das konkret für Ihr Unternehmen?

Die Geheimnisse des Container Runtime Interface: Streaming leicht gemacht!

Sat, 04 May 2024 02:00:00 +0000

Das Kubernetes Container Runtime Interface (CRI) ist die zentrale Verbindung zwischen dem kubelet und der Container Runtime. Diese Runtimes müssen einen gRPC-Server bereitstellen, der eine von Kubernetes definierte Protocol Buffer-Schnittstelle erfüllt. Diese API-Definition entwickelt sich im Laufe der Zeit weiter, wenn beispielsweise neue Funktionen hinzugefügt oder Felder veraltet werden.

In diesem Blogbeitrag möchte ich die Funktionalität und die Geschichte von drei außergewöhnlichen Remote Procedure Calls (RPCs) beleuchten, die in ihrer Funktionsweise wirklich herausragend sind: Exec, Attach und PortForward.

Kubernetes 1.30: Mehr Sicherheit durch User-Namespace für Pods

Thu, 25 Apr 2024 02:00:00 +0000

Linux bietet verschiedene Namespaces, um Prozesse voneinander zu isolieren. Ein typischer Kubernetes-Pod läuft in einem Netzwerk-Namespace, um die Netzwerkidentität zu isolieren, und in einem PID-Namespace, um die Prozesse zu isolieren.

Ein Linux-Namespace, der bisher vernachlässigt wurde, ist der User Namespace. Dieser Namespace ermöglicht es uns, die Benutzer- und Gruppen-IDs (UIDs und GIDs), die wir innerhalb des Containers verwenden, von denen des Hosts zu isolieren.

Diese leistungsstarke Abstraktion erlaubt es uns, Container als “root” auszuführen: Wir sind root innerhalb des Containers und können alles tun, was ein root innerhalb des Pods tun kann. Unsere Interaktionen mit dem Host sind jedoch auf das beschränkt, was ein nicht privilegierter Benutzer tun kann. Dies ist großartig, um die Auswirkungen eines Container-Breakouts zu begrenzen.

Baue deine eigene Cloud: Mit Kubernetes zum Erfolg

Mon, 08 Apr 2024 02:00:00 +0000

Einführung

Hast du jemals darüber nachgedacht, deine eigene Cloud zu erstellen? Vielleicht hast du es sogar schon ausprobiert! Mit Kubernetes ist das durchaus möglich, und in dieser Artikelreihe zeige ich dir, wie du das anpacken kannst. Wir bei Ænix haben viel Erfahrung in der Entwicklung von Cozystack gesammelt und möchten unsere Erkenntnisse mit dir teilen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Oft wird argumentiert, dass Kubernetes nicht für die Erstellung einer eigenen Cloud gedacht ist und dass man stattdessen OpenStack nutzen sollte. Doch das Hinzufügen eines komplexen Systems wie OpenStack ist nicht nötig. Kubernetes hat bereits alles, was du benötigst, um tenant Kubernetes-Cluster zu betreiben. In dieser Artikelreihe werde ich dir zeigen, wie du Kubernetes auf Bare Metal für deine Cloud nutzen kannst.

Baue deine eigene Cloud: Virtualisierung mit Kubernetes leicht gemacht

Mon, 08 Apr 2024 02:00:00 +0000

In unserer Reihe über den Aufbau einer eigenen Cloud mit dem Kubernetes-Ökosystem setzen wir heute unsere Reise fort. Im vorherigen Artikel haben wir erklärt, wie wir eine grundlegende Kubernetes-Distribution auf der Basis von Talos Linux und Flux CD vorbereiten. In diesem Artikel zeigen wir dir verschiedene Virtualisierungstechnologien in Kubernetes und bereiten alles vor, was du benötigst, um virtuelle Maschinen in Kubernetes zu betreiben – insbesondere in den Bereichen Speicher und Netzwerk.

Kubernetes im Kubernetes: So baust du deine eigene Cloud!

Mon, 08 Apr 2024 02:00:00 +0000

In dieser spannenden Fortsetzung unserer Serie über Kubernetes geht es darum, wie du Kubernetes in Kubernetes (K8s in K8s) betreiben kannst. Technologien wie Kamaji und Cluster API stehen dabei im Mittelpunkt, ebenso wie ihre Integration mit KubeVirt. Nachdem wir in den vorherigen Artikeln bereits behandelt haben, wie man Kubernetes auf Bare Metal vorbereitet und wie man es in ein Management-System für virtuelle Maschinen verwandelt, kommt hier der letzte Schliff: Mit diesen Technologien kannst du eine vollwertige verwaltete Kubernetes-Umgebung aufbauen und virtuelle Kubernetes-Cluster mit nur einem Klick betreiben.

Kubernetes für IoT und IIoT

Wed, 27 Mar 2024 11:52:36 +0000

Kubernetes hat sich als eine Schlüsseltechnologie für die Verwaltung und den Betrieb von containerisierten Anwendungen etabliert, einschließlich solcher, die in den Bereichen Internet der Dinge (IoT) und Industrie 4.0 (IIoT) eingesetzt werden. Durch die Bereitstellung einer flexiblen, skalierbaren und hochverfügbaren Infrastruktur erleichtert Kubernetes den Einsatz und die Verwaltung von IoT- und IIoT-Anwendungen und -Diensten erheblich. Besonders bei der Echtzeit-Kommunikation zwischen Geräten und deren Controlplane spielen Message Queues und Broker wie Apache Kafka und NATS eine entscheidende Rolle. Hier wird ausführlich beschrieben, wie Kubernetes diese Prozesse unterstützt:

Kubernetes für App Entwickler

Wed, 27 Mar 2024 11:51:36 +0000

Kubernetes kann einer Software- oder Digitalisierungs-Agentur auf verschiedene Weise helfen, zusätzliche Umsätze mit dem hochverfügbaren Betrieb von Software zu erwirtschaften:

Hochverfügbarkeit: Durch die Gewährleistung einer fast 100%igen Verfügbarkeit der Anwendungen können Agenturen höhere Service-Level-Agreements (SLAs) mit ihren Kunden aushandeln und somit höhere Preise rechtfertigen.
Skalierbarkeit: Kubernetes ermöglicht es, Anwendungen dynamisch zu skalieren, um Spitzenlasten zu bewältigen, ohne dass dafür ständig Ressourcen vorgehalten werden müssen. Das kann Agenturen helfen, effizientere und kosteneffektivere Lösungen anzubieten, die sie an ihre Kunden weitergeben können.
Automatisierte Rollouts und Rollbacks: Die Fähigkeit, Updates und Änderungen schnell und zuverlässig auszuführen, ohne Downtime zu riskieren, bedeutet, dass Agenturen neue Features schneller auf den Markt bringen und auf Kundenwünsche reagieren können, was wiederum die Kundenzufriedenheit und -bindung erhöht.
Selbstheilung: Kubernetes kann fehlerhafte Instanzen automatisch ersetzen und sorgt somit für eine kontinuierliche Verfügbarkeit der Dienste. Dies reduziert den Bedarf an manuellen Eingriffen und ermöglicht es der Agentur, sich auf die Entwicklung und Verbesserung der Anwendungen zu konzentrieren statt auf deren Wartung.
Portabilität und Flexibilität: Die Unabhängigkeit von Cloud-Anbietern und Infrastrukturen ermöglicht es Agenturen, ihre Anwendungen in jeder Umgebung zu betreiben. Dies eröffnet die Möglichkeit, Hosting-Kosten zu optimieren und die Software verschiedenen Kunden auf deren bevorzugter Plattform anzubieten.
Sicherheit: Kubernetes bietet robuste Sicherheitsfeatures, die helfen können, die Anwendungen der Kunden zu schützen. Agenturen können dies als Verkaufsargument nutzen, insbesondere in Branchen, in denen Datenschutz und Sicherheit von großer Bedeutung sind.
Managed Services: Viele Cloud-Anbieter bieten Kubernetes als Managed Service an. Agenturen können ihre Expertise im Umgang mit diesen Services nutzen, um Kunden bei der Migration, Verwaltung und Optimierung ihrer Kubernetes-Cluster zu unterstützen, was eine zusätzliche Einnahmequelle darstellt.

Software Development mit eingebautem Distributionskanal

Sieben Gründe dafür, Software so zu entwickeln, dass sie in Kubernetes laufen kann:

Kubernetes für KI

Wed, 27 Mar 2024 11:50:36 +0000

Kubernetes spielt eine entscheidende Rolle bei der Unterstützung von Open Source KI-Anwendungen, indem es eine robuste, skalierbare und flexible Plattform für das Deployment, die Verwaltung und die Skalierung solcher Anwendungen bietet. Dieses Container-Orchestrierungstool erleichtert das Management von containerisierten Anwendungen über mehrere Hosts hinweg, was es ideal für KI-Projekte macht, die oft große Mengen an Rechenressourcen und eine zuverlässige Infrastruktur erfordern.

Automatisierung und Skalierbarkeit

Mit Kubernetes können Entwickler KI-Anwendungen automatisch skalieren, um den wechselnden Anforderungen gerecht zu werden. Dies ist besonders wichtig für KI-Modelle, die während des Trainingsprozesses oder bei der Verarbeitung großer Datenmengen erhebliche Ressourcen benötigen. Kubernetes ermöglicht es, Ressourcen effizient zuzuweisen und bei Bedarf automatisch zu skalieren, was sowohl die Leistung als auch die Kosteneffizienz verbessert.

Laravel für SaaS Apps

Wed, 27 Mar 2024 11:49:36 +0000

Laravel ist eines der beliebtesten PHP-Frameworks und bietet eine Reihe von Funktionen, die es zu einer ausgezeichneten Wahl für die Entwicklung von Software-as-a-Service (SaaS) Produkten machen. Hier sind sieben Gründe, die für die Nutzung von Laravel sprechen:

Einfachheit und Eleganz: Laravel bietet eine elegante Syntax, die die Entwicklung beschleunigt und den Code übersichtlicher macht. Es ermöglicht Entwicklern, mit weniger Aufwand mehr zu erreichen.
Modularität: Durch die eingebaute Modularität können Entwickler wiederverwendbare Komponenten leicht in ihre Anwendungen integrieren. Dies fördert die Wiederverwendbarkeit von Code und erleichtert die Wartung.

PHP in Kubernetes

Wed, 27 Mar 2024 11:48:36 +0000

Durch die Nutzung von Kubernetes können Entwickler und Betriebsteams die Herausforderungen traditioneller Hosting-Umgebungen überwinden und ihre PHP-Anwendungen effizienter, zuverlässiger und skalierbarer machen. Hier sind einige Schlüsselaspekte, wie Kubernetes den Betrieb von PHP-Anwendungen vereinfachen und verbessern kann:

Automatisierte Bereitstellung und Skalierung

Schnelle und konsistente Deployments: Kubernetes ermöglicht es, PHP-Anwendungen in Containern zu verpacken, was eine schnelle, konsistente und reproduzierbare Bereitstellung über verschiedene Umgebungen hinweg erleichtert. Dies vereinfacht den Prozess der Softwareauslieferung erheblich.
Automatische Skalierung: Kubernetes kann die Anzahl der Pods (Container) basierend auf der Last automatisch anpassen. Für PHP-Anwendungen bedeutet das, dass sie bei steigendem Traffic automatisch skaliert werden können, um die Leistung aufrechtzuerhalten, und bei geringerem Traffic Ressourcen freigeben können, um Kosten zu sparen.

Verbesserte Ausfallsicherheit und Verfügbarkeit

Selbstheilung: Kubernetes überwacht ständig den Zustand der Pods und kann automatisch fehlerhafte Instanzen ersetzen. Dies erhöht die Zuverlässigkeit von PHP-Anwendungen, da Ausfallzeiten minimiert und potenzielle Störungen schnell behoben werden.
Load Balancing: Kubernetes verteilt den eingehenden Netzwerkverkehr auf mehrere Instanzen der Anwendung, was nicht nur die Lastverteilung verbessert, sondern auch die Gesamtverfügbarkeit der PHP-Anwendung erhöht.

Effizientes Ressourcenmanagement

Ressourcenkontingentierung: Kubernetes ermöglicht es, Ressourcenlimits und -anforderungen (wie CPU und Speicher) für jeden Container festzulegen. Dies hilft, die Nutzung von Systemressourcen zu optimieren und sicherzustellen, dass eine PHP-Anwendung nicht mehr Ressourcen verbraucht, als ihr zugewiesen sind.
Persistent Storage: Kubernetes unterstützt persistente Volumes, die unabhängig vom Lebenszyklus der Container bestehen bleiben. Dies ist entscheidend für PHP-Anwendungen, die auf Datenbanken oder Dateispeicher angewiesen sind, um eine konsistente Datenhaltung zu gewährleisten.

Verbesserte Entwicklung und Zusammenarbeit

Declarative Konfiguration: Kubernetes verwendet YAML- oder JSON-Konfigurationsdateien, um den gewünschten Zustand einer Anwendung zu beschreiben. Dies fördert Best Practices wie Infrastruktur als Code und erleichtert die Zusammenarbeit in Entwicklungsteams.
Umfassendes Ökosystem: Dank des breiten Ökosystems von Kubernetes können Teams aus einer Vielzahl von Tools und Diensten wählen, die speziell für Monitoring, Logging und CI/CD entwickelt wurden, was den Betrieb und die Wartung von PHP-Anwendungen weiter vereinfacht.

Insgesamt kann Kubernetes den Betrieb von PHP-basierten Anwendungen durch Automatisierung, verbesserte Ausfallsicherheit, effizientes Ressourcenmanagement und Unterstützung für moderne Entwicklungspraktiken erheblich vereinfachen und verbessern. Diese Vorteile machen Kubernetes zu einer attraktiven Plattform für Unternehmen, die ihre PHP-Anwendungen in einer dynamischen, skalierbaren und zuverlässigen Umgebung betreiben möchten.

Was ist die ayedo Cloud?

Wed, 27 Mar 2024 11:47:36 +0000

Willkommen in der ayedo Cloud – Ihrer ultimativen Plattform für Zero-Downtime SaaS-App-Hosting. Entwickelt für die kreativen Köpfe, die die Welt mit ihrer Software bereichern wollen. Ob Sie ein Software-as-a-Service-Anbieter sind, ein Docker-Enthusiast oder einfach jemand, der die Ruhe der Nacht genießen möchte, ohne sich Gedanken über den Betrieb Ihrer Anwendungen machen zu müssen – die ayedo Cloud ist für Sie.

Cloud Services für App-Entwickler: Das ultimative Toolkit

Kubernetes - Managed oder Manuell?

Wed, 27 Mar 2024 11:46:36 +0000

Kubernetes - Managed oder Manuell?

Sollten Sie Kubernetes selbst verwalten oder die Verantwortung in die Hände von Managed Service Providern legen? Mit dem Aufstieg von Kubernetes als De-facto-Standard für die Container-Orchestrierung stehen viele vor dieser Entscheidung.

Managed Kubernetes Cluster aus der ayedo Cloud

Bei ayedo verstehen wir die Herausforderungen und Chancen, die Kubernetes bietet. Unsere Managed Kubernetes-Dienste in der ayedo Cloud sind darauf ausgelegt, Ihnen nicht nur eine robuste und skalierbare Orchestrierungslösung anzubieten, sondern auch erhebliche Preisvorteile, Zeitersparnisse, Zugang zu Fachwissen und eine hochverfügbare Infrastruktur.

Docker Swarm vs Kubernetes

Wed, 27 Mar 2024 11:45:36 +0000

In der Welt der Container-Orchestrierung stehen zwei Technologien im Mittelpunkt der Diskussion: Docker Swarm und Kubernetes. Beide bieten leistungsfähige Plattformen zur Verwaltung von Containern, doch sie unterscheiden sich grundlegend in ihrem Ansatz, ihrer Komplexität und ihrer Funktionalität.

Merkmal	Docker Swarm	Kubernetes
Einrichtung und Benutzerfreundlichkeit	Einfach und schnell, intuitive Befehle für Docker-Nutzer	Komplexer, bietet umfassendere Konfigurationsmöglichkeiten
Skalierbarkeit	Optimal für kleinere bis mittelgroße Cluster	Entworfen für hohe Skalierbarkeit, auch in sehr großen Umgebungen
Orchestrierungsfunktionen	Grundlegende Funktionen für Container-Management	Umfangreiche Orchestrierungsfunktionen und -möglichkeiten
Zukunftssicherheit	Begrenzt durch einfacheren Funktionsumfang	Hoch, durch aktive Weiterentwicklung und breite Akzeptanz
Stand der Technologie	Gut für einfache Anwendungen und Deployments	Fortschrittlich, unterstützt neueste Technologien und Standards
Entwickler-Community	Teil der Docker-Community, kleiner im Vergleich zu Kubernetes	Große, aktive Community; breite Unterstützung und Engagement
Mitgliedschaft in der CNCF	Nicht direkt als CNCF-Projekt gelistet	Kernprojekt der CNCF, zentral für das Cloud-native Ökosystem
Bekanntheit bei Softwareentwicklern	Hoch, besonders bei Entwicklern, die mit Docker arbeiten	Sehr hoch, als De-facto-Standard für Container-Orchestrierung anerkannt
Flexibilität und Anpassungsfähigkeit	Weniger anpassbar, fokussiert auf Einfachheit	Hochgradig anpassbar, unterstützt eine Vielzahl von Workloads

Docker Swarm: Einfachheit und Schnelligkeit

Docker vs Docker Swarm

Wed, 27 Mar 2024 11:44:36 +0000

Docker und Docker Swarm sind eng miteinander verbundene Technologien im Bereich der Containerisierung und Orchestrierung, die jeweils unterschiedliche Aspekte des Managements von Containern abdecken. Hier sind die grundlegenden Unterschiede zwischen beiden:

Eigenschaft	Docker	Docker Swarm
Fokus	Containerisierung von Anwendungen	Orchestrierung von Containern auf Clusterebene
Einsatzgebiet	Entwicklung, Versand und Betrieb von Containern	Verwaltung von hochverfügbaren und skalierbaren Anwendungen
Architektur	Einzelhost	Cluster von Hosts
Skalierung	Manuell auf einem einzelnen Host	Automatische Skalierung über mehrere Hosts
Verfügbarkeit	Begrenzt auf die Verfügbarkeit eines einzelnen Hosts	Hochverfügbar durch Multi-Host-Deployment
Netzwerk	Einfaches Netzwerkmanagement für Container	Fortgeschrittenes Netzwerkmanagement für Cluster
Datenpersistenz	Volumes und Bind Mounts für Persistenz	Volumes in Kombination mit externen Speicherlösungen für Cluster-weite Persistenz
Discovery & Orchestrierung	Nicht nativ unterstützt	Native Unterstützung für Service Discovery und Orchestrierung
Tools/Plattform	Docker CLI, Docker Compose	Docker CLI, Docker Compose (erweitert für Swarm)
Sicherheit	Basis Sicherheitsfeatures	Zusätzliche Sicherheitsfeatures für Cluster-Kommunikation

Docker

Docker ist eine Plattform für die Entwicklung, den Versand und den Betrieb von Anwendungen in Containern. Es ermöglicht Entwicklern, Anwendungen und ihre Abhängigkeiten in leichtgewichtigen, portablen Containern zu verpacken, die auf nahezu jeder Linux- oder Windows-Basis laufen können. Docker vereinfacht den Entwicklungsworkflow und erleichtert die Continuous Integration und Continuous Deployment (CI/CD) Prozesse.

Was ist Netbird?

Wed, 27 Mar 2024 11:43:36 +0000

Netbird ist eine moderne, peer-to-peer (P2P) Netzwerklösung, die den Aufbau eines sicheren, skalierbaren und leicht zu verwaltenden Netzwerks ermöglicht. Es handelt sich um eine fortschrittliche Alternative zu traditionellen VPN-Lösungen, die speziell für die Bedürfnisse von Unternehmen entwickelt wurde. Mit Netbird können Teams sicher und effizient auf Systemressourcen zugreifen, unabhängig von ihrem Standort.

Vorteile von Netbird

Einfache Einrichtung und Verwaltung: Netbird eliminiert die Komplexität, die oft mit der Einrichtung und Verwaltung von VPNs verbunden ist, und ermöglicht eine schnelle und unkomplizierte Netzwerkkonfiguration.
Sicherer, verschlüsselter Zugang: Es bietet End-to-End-Verschlüsselung, die einen sicheren Zugriff auf Netzwerkressourcen und den Schutz sensibler Daten gewährleistet.
Skalierbarkeit: Netbird passt sich nahtlos dem Wachstum Ihres Unternehmens an, indem es die einfache Skalierung des Netzwerks ohne zusätzliche Hardware oder komplexe Konfigurationen ermöglicht.
Hohe Verfügbarkeit: Durch die P2P-Architektur und die automatische Wiederherstellung von Verbindungen sorgt Netbird für eine konstante Verfügbarkeit und Zuverlässigkeit des Netzwerks.

Warum Netbird anderen VPN-Lösungen überlegen ist

Anders als traditionelle VPN-Technologien, die zentralisierte Server nutzen und oft zu Engpässen führen können, basiert Netbird auf einer dezentralen P2P-Architektur. Diese Konfiguration verbessert die Performance, reduziert Latenzen und erhöht die Ausfallsicherheit. Darüber hinaus vereinfacht Netbird den Netzwerkbetrieb durch Automatisierung und bietet eine intuitive Benutzeroberfläche, die es auch Nicht-Experten ermöglicht, komplexe Netzwerkeinstellungen vorzunehmen.

Postgresql vs MongoDB

Wed, 27 Mar 2024 11:42:36 +0000

PostgreSQL und MongoDB sind zwei der beliebtesten Datenbankmanagementsysteme (DBMS), die sich grundlegend in ihrem Ansatz und ihren Einsatzgebieten unterscheiden. PostgreSQL ist ein relationales DBMS, das auf der Structured Query Language (SQL) basiert, während MongoDB ein NoSQL-DBMS ist, das für die Speicherung von dokumentenorientierten oder semi-strukturierten Daten konzipiert wurde. Beide Systeme können in Kubernetes für hochverfügbaren und automatisierten Betrieb konfiguriert werden, jedoch mit unterschiedlichen Herangehensweisen und Überlegungen.

Eigenschaft	PostgreSQL	MongoDB
Datenmodell	Relational, tabellenbasiert, mit strengen Datenschemata	Dokumentenorientiert, Schema-frei, JSON-ähnliche Dokumente
Abfragesprache	SQL (Structured Query Language), unterstützt komplexe Abfragen und Joins	MQL (MongoDB Query Language), flexibel für dokumentenorientierte Abfragen
Hochverfügbarkeit in Kubernetes	Erfordert Tools wie Patroni für HA und Skalierung; komplexere Einrichtung	Native Unterstützung durch MongoDB Atlas und MongoDB Kubernetes Operator; einfacher in der Einrichtung
Skalierbarkeit	Vertikal und horizontal (mit zusätzlichen Tools für die Cluster-Verwaltung)	Native Unterstützung für horizontale Skalierung durch Sharding
Performance	Hohe Performance bei komplexen Transaktionen und Abfragen	Optimiert für schnelle Lese- und Schreiboperationen großer Mengen variabler Daten
Automatisierter Betrieb in Kubernetes	Management über Operatoren möglich, aber tendenziell komplexer	Einfacher und automatisierter durch MongoDB Kubernetes Operator
Einsatzgebiete	Geeignet für Anwendungen, die relationale Datenintegrität und komplexe Transaktionen erfordern	Geeignet für Anwendungen mit großem Datenvolumen und flexiblen Schemata

Datenmodell und Abfragesprache

PostgreSQL: Nutzt ein tabellenbasiertes Modell mit strengen Datenschemata. Es unterstützt komplexe Abfragen und Transaktionen, die ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) gewährleisten. PostgreSQL ist ideal für Anwendungen, die komplexe Joins, Transaktionen und analytische Operationen erfordern.
MongoDB: Verwendet ein flexibles, dokumentenorientiertes Modell, das es Entwicklern ermöglicht, halbstrukturierte Daten in einem JSON-ähnlichen Format zu speichern. MongoDB ist besonders gut für Anwendungen geeignet, die schnelle Iterationen, den Umgang mit großen Mengen von variablen Datenstrukturen und einfache Skalierbarkeit erfordern.

Hochverfügbarkeit und Skalierbarkeit in Kubernetes

PostgreSQL: Die Implementierung von Hochverfügbarkeit (HA) und Skalierbarkeit in Kubernetes erfordert zusätzliche Tools und Operatoren, wie z.B. Patroni, um ein PostgreSQL-Cluster zu verwalten. Diese Tools ermöglichen die Automatisierung von Failover-Prozessen, Backups und die Skalierung. PostgreSQL kann vertikal (durch Hinzufügen von Ressourcen zu bestehenden Nodes) und horizontal (durch Hinzufügen mehrerer Nodes) skaliert werden, wobei letzteres komplexer in der Verwaltung ist.
MongoDB: MongoDB bietet mit MongoDB Atlas eine native Unterstützung für den Betrieb in der Cloud, einschließlich Kubernetes, mit Funktionen für die automatische Skalierung, Backups und HA. Der MongoDB Kubernetes Operator automatisiert die Bereitstellung, das Failover und die Skalierung von MongoDB-Instanzen. MongoDB unterstützt auch die horizontale Skalierung durch Sharding direkt und ist damit potenziell einfacher skalierbar in Kubernetes-Umgebungen.

Performance

PostgreSQL: Bietet eine hohe Performance für komplexe Abfragen und ist optimal für Szenarien, in denen relationale Datenintegrität und komplexe Transaktionen erforderlich sind. Die Performance kann jedoch unter extrem hohen Schreib- und Leseanforderungen leiden, besonders wenn horizontale Skalierung verwendet wird.
MongoDB: Entwickelt für schnellen Datenzugriff und hohe Performance, insbesondere bei Lese- und Schreiboperationen von großen Mengen nicht-relationaler Daten. Durch Sharding und Replikation kann MongoDB hohe Durchsatzraten und niedrige Latenzzeiten auch bei sehr großen Datensätzen erreichen.

Automatisierter Betrieb in Kubernetes

PostgreSQL und MongoDB: Beide Datenbanksysteme können von der Orchestrierung und den Selbstheilungsfähigkeiten von Kubernetes profitieren. Die Nutzung von Operatoren in Kubernetes erleichtert die Automatisierung von Bereitstellung, Skalierung und Verwaltung, einschließlich der Überwachung des Zustands der Datenbanken und der automatischen Handhabung von Failover-Szenarien.

Fazit

Die Entscheidung zwischen PostgreSQL und MongoDB hängt von den spezifischen Anforderungen der Anwendung, dem bevorzugten Datenmodell und den Skalierbarkeitsanforderungen ab. Während PostgreSQL sich durch sein robustes, relationales Modell für komplexe Datenverarbeitungsanforderungen auszeichnet, bietet MongoDB Flexibilität und Leistung für den Umgang mit großen Mengen variabler Daten. In Kubernetes-Umgebungen können beide Systeme für hochverfügbaren und automatisierten Betrieb konfiguriert werden, wobei die jeweiligen Operatoren und Management-Tools entscheidend für die Effizienz und Einfachheit der Verwaltung sind.

Was ist Cilium?

Wed, 27 Mar 2024 11:41:36 +0000

Cilium ist ein Open-Source-Projekt, das Netzwerksicherheit und -überwachung für Container-Orchestrierungssysteme wie Kubernetes bietet. Es verwendet eine moderne Technologie namens eBPF (extended Berkeley Packet Filter), die es ermöglicht, Netzwerkverkehr auf einer sehr niedrigen Ebene effizient zu steuern und zu überwachen.

Für jemanden ohne umfangreiche Erfahrung mit Kubernetes ist es hilfreich zu verstehen, dass Kubernetes Container in einer isolierten und automatisierten Umgebung verwaltet. Netzwerksicherheit und -kommunikation zwischen diesen Containern und der Außenwelt sind entscheidend für den Betrieb jeder Anwendung. Hier kommt Cilium ins Spiel:

Kafka vs NATS

Wed, 27 Mar 2024 11:40:36 +0000

Apache Kafka und NATS sind hochleistungsfähige Messaging-Systeme, die in modernen, verteilten Architekturen eingesetzt werden, um Komponenten durch Nachrichtenaustausch zu verbinden. Trotz einiger Überschneidungen in ihrer Funktionalität unterscheiden sich beide Systeme grundlegend in Design, Einsatzgebieten und technischen Spezifikationen.

Eigenschaft	Apache Kafka	NATS
Skalierbarkeit	Hoch, unterstützt Petabytes von Daten über Cluster von Servern.	Gut, optimiert für Leichtigkeit und Skalierbarkeit in großen Systemen.
Runtime-Anforderungen	Höher, benötigt JVM-Umgebung.	Geringer, in Go geschrieben und für Container- und Mikroservicelandschaften optimiert.
Performance	Hoher Durchsatz und niedrige Latenz, optimiert für Millionen Nachrichten pro Sekunde.	Extrem niedrige Latenzen und hohe Durchsatzraten, optimiert für schnelle Nachrichtenübermittlung.
Komplexität	Höher, komplexe Architektur erfordert spezialisiertes Wissen für Einrichtung und Management.	Niedriger, einfacher in der Einrichtung und Verwaltung. Vereinfachte API und Client-Bibliotheken.
Persistenz	Bietet dauerhafte Speicherung von Nachrichten.	Fokussiert sich auf Zustellbarkeit von Nachrichten ohne persistente Datenspeicherung.
Verwendungsszenarien	Ideal für zuverlässige, dauerhafte und skalierbare Verarbeitung von Nachrichtenströmen.	Geeignet für Projekte, die eine schnelle, effiziente und leichtgewichtige Messaging-Lösung suchen.
Cluster-Fähigkeit	Unterstützt Partitionierung und Replikation für Skalierung und Verfügbarkeit.	Unterstützt Clustering zur Skalierung und erhöhten Durchsatz, allerdings mit anderem Fokus als Kafka.
Sprache/Plattform	Geschrieben in Scala und Java.	Geschrieben in Go.

Apache Kafka

Apache Kafka ist ein verteiltes Streaming-Plattform, die zum Veröffentlichen, Abonnieren, Speichern und Verarbeiten von Streams von Ereignissen (Nachrichten) in Echtzeit verwendet wird. Es wurde ursprünglich von LinkedIn entwickelt und ist jetzt ein Open-Source-Projekt der Apache Software Foundation.

Postgresql vs MariaDB

Wed, 27 Mar 2024 11:39:36 +0000

PostgreSQL und MariaDB sind beide beliebte Open-Source-Relationale Datenbankmanagementsysteme (RDBMS), die für die Speicherung und Verwaltung von Daten verwendet werden. Obwohl beide Systeme viele ähnliche Funktionen bieten, gibt es zwischen ihnen signifikante Unterschiede hinsichtlich ihrer Funktionalitäten, Leistungsmerkmale und Unterstützung.

Aspekt	PostgreSQL	MariaDB
Grundlage	Fortgeschrittene Funktionen und Datenstrukturen	Abkömmling von MySQL
Lizenzierung	PostgreSQL-Lizenz (ähnlich der MIT-Lizenz)	GPL v2-Lizenz
Erweiterbarkeit	Hoch, mit Unterstützung für benutzerdefinierte Datentypen und Funktionen	Bietet auch Erweiterungen, aber fokussiert auf MySQL-Kompatibilität
Cluster-Fähigkeit	Unterstützt durch native Funktionen und Drittanbieter-Erweiterungen	Eingebaute Cluster-Lösung mit MariaDB Galera Cluster
PITR Backups	Umfangreiche Unterstützung für PITR	Unterstützt PITR, Implementierung variiert nach Speicher-Engine
Hochverfügbarkeit	Erreichbar durch Streaming Replication und logische Replikation	Hochverfügbar durch MariaDB Galera Cluster ohne zusätzliche Software
Skalierbarkeit	Vertikales und horizontales Skalieren möglich	Horizontales Skalieren durch Galera Cluster, verschiedene Speicher-Engines unterstützen verschiedene Lasten
Performance	Hoch bei komplexen Abfragen und großen Datenmengen	Optimiert für hohe Leistung und Skalierbarkeit
Datentypen und Funktionen	Unterstützt erweiterte Datentypen wie Arrays, JSON/JSONB und Geometrische Typen	Fokussiert auf Kompatibilität mit MySQL, erweitert dessen Funktionen
Speicher-Engines	Einheitlicher Ansatz mit MVCC	Unterstützt mehrere Speicher-Engines, darunter Aria und InnoDB
Leistungsmerkmale	Robuste Indexierungsoptionen und MVCC	Pool-of-Threads für verbesserte Skalierbarkeit

PostgreSQL

Erweiterte Funktionen: PostgreSQL ist bekannt für seine fortschrittlichen Funktionen wie die Unterstützung für komplexe Abfragen, Fremdschlüssel, Trigger, Views, Transaktionen mit ACID-Eigenschaften und mehr. Es unterstützt auch erweiterte Datentypen wie Arrays, hstore (ein Schlüssel-Wert-Store), JSON/JSONB und Geometrische Datentypen.
Leistung: PostgreSQL wird oft für seine Leistung bei komplexen Abfragen und die Fähigkeit zur Verarbeitung großer Datenmengen gelobt. Es bietet robuste Indexierungsmechanismen wie B-Bäume, Multiversion Concurrency Control (MVCC) und GIN-Indizes für komplexe Suchanfragen.
Erweiterbarkeit: Ein Schlüsselmerkmal von PostgreSQL ist seine Erweiterbarkeit. Entwickler können neue Funktionen hinzufügen, wie Datentypen, Funktionen, Operatoren und Indexmethoden, ohne den Kerncode zu ändern.
Lizenzierung: PostgreSQL wird unter der PostgreSQL-Lizenz veröffentlicht, einer liberalen Open-Source-Lizenz, die der MIT-Lizenz ähnelt.
Cluster-Fähigkeit: PostgreSQL unterstützt durch seine Architektur native Partitionierung und Sharding, was es ermöglicht, Daten effizient über mehrere Server zu verteilen. Zusätzlich gibt es Drittanbieter-Erweiterungen wie Postgres-XL für horizontales Skalieren und Citus, das verteilte Datenbankfunktionalitäten hinzufügt, um die Cluster-Fähigkeit zu erweitern.
Point-in-Time Recovery (PITR) Backups: PostgreSQL bietet umfangreiche Möglichkeiten für Backups und Wiederherstellungen, einschließlich PITR. PITR ermöglicht es, Datenbanken zu einem bestimmten Zeitpunkt in der Vergangenheit wiederherzustellen, was sehr nützlich ist, um Datenverluste nach einem Fehler zu minimieren.
Hochverfügbarkeit und Skalierbarkeit: PostgreSQL kann durch Replikationslösungen wie Streaming Replication und logische Replikation hochverfügbar gemacht werden. Für die Skalierbarkeit bietet PostgreSQL neben der nativen Partitionierung und den bereits genannten Drittanbieter-Erweiterungen auch Load Balancing und Failover-Mechanismen.

MariaDB

Abkömmling von MySQL: MariaDB wurde als Fork von MySQL erstellt, nachdem MySQL von Oracle übernommen wurde. Es strebt vollständige binäre Kompatibilität mit MySQL an, was bedeutet, dass es als Drop-in-Ersatz fungieren kann.

GitHub vs GitLab

Wed, 27 Mar 2024 11:38:36 +0000

GitLab und GitHub sind beides sehr populäre Plattformen zur Versionsverwaltung und Kollaboration für Software-Entwicklungsprojekte, die auf Git basieren. Obwohl sie ähnliche Funktionen bieten, wie Issue Tracking, Pull Requests, und CI/CD-Pipelines, gibt es einige wesentliche Unterschiede zwischen den beiden.

Feature	GitHub	GitLab
Grundlage	Cloud Service	Open Source
Hosting	Primär Cloud-basiert; Enterprise-Version für Selbst-Hosting	Sowohl Cloud-basiert als auch Open Source für Selbst-Hosting
Open Source	Nein (GitHub selbst ist nicht Open Source)	Ja (Community Edition verfügbar)
Selbst-Hosting	Nur in der Enterprise-Version	Möglich in allen Versionen, einschließlich der kostenlosen Community-Edition
CI/CD Integration	Verfügbar, mit GitHub Actions	Integrierte CI/CD in allen Versionen
Kosten	Kostenlose und bezahlte Pläne; Selbst-Hosting in Enterprise-Version	Kostenlose Community Edition; bezahlte Enterprise-Edition
Zielgruppe	Einzelpersonen und Unternehmen	Einzelpersonen, Open-Source-Projekte und Unternehmen

GitHub:

Cloud Service: GitHub wird hauptsächlich als Cloud-basierter Service genutzt. Das bedeutet, dass Benutzer ihre Projekte auf den Servern von GitHub hosten. Diese Lösung bietet eine schnelle Einrichtung und leichte Zugänglichkeit von überall her, solange eine Internetverbindung besteht.
Enterprise Hosting: GitHub bietet zwar eine Enterprise-Version an, die es Unternehmen ermöglicht, GitHub auf ihren eigenen Servern zu hosten, aber diese Option ist kostenpflichtig. Diese Version richtet sich an Organisationen, die eine größere Kontrolle über ihre Daten und eine tiefe Integration in ihre internen Systeme benötigen.
Open Source: Während viele Open-Source-Projekte auf GitHub gehostet werden, ist die Plattform selbst nicht Open Source. GitHub hat jedoch zahlreiche Tools und APIs, die Entwicklern zur Verfügung stehen, um Integrationen und Automatisierungen zu erleichtern.

GitLab:

Open Source: Ein entscheidender Unterschied zu GitHub ist, dass GitLab als Open-Source-Plattform zur Verfügung steht. Dies bedeutet, dass jeder den Quellcode von GitLab einsehen, ändern und selbst hosten kann. GitLab bietet eine Community-Edition, die kostenlos ist und von der Community unterstützt wird, sowie eine Enterprise-Edition mit erweiterten Funktionen für größere Organisationen.
Selbst-Hosting: GitLab ermöglicht es Benutzern von Anfang an, ihre eigene Instanz der Plattform auf privaten Servern zu betreiben. Dies bietet Unternehmen und Organisationen die Flexibilität, ihre eigene Versionskontroll- und CI/CD-Infrastruktur nach ihren Sicherheits- und Compliance-Anforderungen zu gestalten.
Integrierte CI/CD: Sowohl GitLab als auch GitHub bieten integrierte Lösungen für Continuous Integration und Continuous Deployment. Jedoch ist GitLab besonders dafür bekannt, dass es eine umfassende, out-of-the-box CI/CD-Lösung innerhalb seiner Plattform bietet, die eng mit anderen Features integriert ist.

Fazit:

Während GitHub als führende Plattform für Open-Source-Projekte und die Kollaboration von Entwicklern weltweit gilt, bietet GitLab eine flexible und vollständig Open-Source-Alternative, die es Benutzern ermöglicht, die Plattform auf ihren eigenen Servern zu hosten. Die Entscheidung zwischen GitLab und GitHub hängt letztendlich von den spezifischen Anforderungen eines Projekts oder Unternehmens ab, einschließlich Faktoren wie Kosten, Hosting-Präferenzen, Datenschutz- und Sicherheitsanforderungen sowie der Notwendigkeit für integrierte CI/CD-Pipelines.

Prometheus vs VictoriaMetrics

Wed, 27 Mar 2024 11:37:36 +0000

Prometheus und VictoriaMetrics sind beide leistungsfähige Zeitreihendatenbanken, die sich für Überwachungs- und Alarmierungsaufgaben in komplexen IT-Umgebungen eignen. Obwohl sie ähnliche Ziele verfolgen, gibt es einige wesentliche Unterschiede in ihrer Architektur, Funktionsweise und den angebotenen Features.

Merkmal	Prometheus	VictoriaMetrics
Architektur	Pull-basiertes Modell für das Abrufen von Metriken	Unterstützt sowohl Pull- als auch Push-Modelle für die Datenerfassung
Skalierbarkeit	Vertikal durch Erhöhung der Ressourcen oder durch Föderation	Sowohl vertikal als auch horizontal skalierbar
Abfragesprache	PromQL (Prometheus Query Language)	Rückwärtskompatibel mit PromQL und führt MetricsQL ein, eine Erweiterung von PromQL
Hochverfügbarkeit	Kein eingebautes Clustering, manuelle Koordination für Hochverfügbarkeit notwendig	Entworfen mit Hochverfügbarkeit im Hinterkopf, nutzt Replikation und Clustering
Leistung und Effizienz	Optimiert für Echtzeitüberwachung, nicht speziell für Langzeitspeicherung	Höhere Ressourceneffizienz und bessere Unterstützung für Langzeitspeicherung mit effizienterer Datenerfassung
Integration mit Grafana	Einfach, dank flexibler Datenquellenunterstützung von Grafana	Ebenfalls einfach, unterstützt zusätzlich die Verbesserungen durch MetricsQL
API	HTTP-basiert, PromQL für Abfragen und Verwaltung	Umfassende HTTP-API, kompatibel mit Prometheus, unterstützt zusätzlich InfluxDB und Graphite API

Architektur und Datenerfassung

Prometheus nutzt ein Pull-basiertes Modell, bei dem es Metriken in festgelegten Intervallen von konfigurierten Zielen abruft. Es speichert Zeitreihendaten in einem eigenen effizienten, lokalen Speicherformat und unterstützt multidimensionale Datenerfassung, Abfragen und Alarmierung. Prometheus kann als einzelnes Binär auf einem Server oder auf einer Containerplattform wie Kubernetes eingesetzt werden.

Redis vs Keydb

Wed, 27 Mar 2024 11:35:36 +0000

Redis und KeyDB sind beides leistungsstarke In-Memory-Datenbanksysteme, die sich durch ihre Geschwindigkeit und Effizienz bei der Datenverarbeitung auszeichnen. Trotz ihrer Ähnlichkeiten gibt es jedoch wesentliche Unterschiede zwischen beiden Technologien.

Feature	Redis	KeyDB
Ursprung	Ursprünglich von Salvatore Sanfilippo entwickelt	Ein Fork von Redis
Lizenzierung	BSD-Lizenz; duales Lizenzmodell für erweiterte Module und Enterprise-Funktionen	Open-Source-Lizenz, Details variieren je nach Version und Komponenten
Architektur	Single-Threaded	Multithreading-fähig
Leistung	Hoch, durch Single-Threaded-Architektur begrenzt bei Nutzung von Mehrkern-CPUs	Verbesserte Leistung durch Multithreading, effiziente Nutzung von Mehrkern-CPUs
Erweiterbarkeit	Modulsystem für Erweiterungen	Kompatibel mit Redis-Protokollen und -Datenstrukturen, eigene Erweiterungen
Community und Unterstützung	Große und aktive Community; umfangreiche Dokumentation und Tutorials	Bemüht sich um Kompatibilität mit Redis, eigene Community für spezifische KeyDB-Erweiterungen
Kompatibilität mit Redis	-	Ja, unterstützt Redis-Protokolle und -Datenstrukturen
Zusätzliche Funktionen	-	Verbesserte Replikation, zusätzliche Befehle
Active-Active Cluster	Nur in der Enterprise-Version verfügbar	Enthalten in der Standardversion

Redis

Ursprung und Verbreitung: Redis (Remote Dictionary Server) wurde ursprünglich von Salvatore Sanfilippo entwickelt und ist weit verbreitet in der Industrie als leistungsstarke und flexible In-Memory-Datenbank, die für Caching, Session Management, Pub/Sub und weitere Szenarien verwendet wird.
Lizenzierung: Redis ist unter der BSD-Lizenz veröffentlicht, was bedeutet, dass es sehr permissiv ist und wenig Einschränkungen für die Nutzung und Verteilung bietet. Mit der Zeit hat Redis allerdings ein duales Lizenzmodell eingeführt, besonders für seine erweiterten Module und Enterprise-Funktionen.
Architektur und Leistung: Redis nutzt eine Single-Threaded-Architektur, die für ihre Einfachheit und hohe Leistung bekannt ist. Es unterstützt verschiedene Datenstrukturen wie Strings, Hashes, Lists, Sets, Sorted Sets mit Range Queries, Bitmaps, Hyperloglogs und Geospatial Indexes mit Radius Queries.
Erweiterbarkeit und Module: Redis bietet eine Modulsystem an, das es ermöglicht, die Funktionalität der Datenbank durch Drittanbieter oder benutzerdefinierte Module zu erweitern.
Community und Unterstützung: Als eines der populärsten Open-Source-Projekte hat Redis eine große und aktive Community. Es gibt umfangreiche Dokumentationen, Tutorials und Drittanbieter-Tools.

KeyDB

Ursprung und Verbreitung: KeyDB ist ein Fork von Redis, der sich durch seine Multithreading-Fähigkeit auszeichnet. Das Hauptziel von KeyDB ist es, die Leistung von Redis durch Multithreading zu verbessern, um höhere Durchsätze und eine bessere Nutzung moderner Mehrkern-CPUs zu ermöglichen.
Lizenzierung: KeyDB wird ebenfalls unter einer Open-Source-Lizenz veröffentlicht, wobei das genaue Lizenzmodell von der Version und den spezifischen Komponenten abhängen kann.
Architektur und Leistung: Im Gegensatz zu Redis verwendet KeyDB eine Multithreading-Architektur, die es ermöglicht, mehrere Kerne eines Prozessors effizient zu nutzen, um höhere Durchsatzraten und bessere Skalierbarkeit zu erreichen, insbesondere bei Workloads, die viele Verbindungen und Befehle umfassen.
Kompatibilität mit Redis: KeyDB bemüht sich, mit Redis kompatibel zu bleiben, was bedeutet, dass Anwendungen, die für Redis geschrieben wurden, oft ohne Änderungen mit KeyDB funktionieren können. KeyDB unterstützt die gleichen Protokolle und Datenstrukturen wie Redis.
Erweiterungen und Unterschiede: Neben der Multithreading-Fähigkeit fügt KeyDB auch eigene Erweiterungen und Verbesserungen hinzu, die über die Kernfunktionen von Redis hinausgehen, wie verbesserte Replikation und zusätzliche Befehle.

Fazit

Obwohl Redis und KeyDB in vielen Aspekten ähnlich sind, unterscheiden sie sich hauptsächlich in ihrer internen Architektur und Leistungsoptimierung. Redis ist bekannt für seine Stabilität und eine große Benutzergemeinschaft, während KeyDB als eine leistungsfähigere Alternative durch die Nutzung von Multithreading und zusätzlichen Optimierungen positioniert ist. Die Wahl zwischen Redis und KeyDB hängt letztendlich von den spezifischen Anforderungen des Projekts, der bevorzugten Architektur und den Leistungserwartungen ab.

Authentik vs Keycloak

Wed, 27 Mar 2024 11:30:36 +0000

In der heutigen digitalisierten Welt ist das Management von Benutzeridentitäten und Zugriffsberechtigungen eine zentrale Herausforderung für Unternehmen aller Größen. Single-Sign-On (SSO) Lösungen bieten eine effiziente Möglichkeit, die Nutzererfahrung zu verbessern, während gleichzeitig die Sicherheit erhöht wird. Sie ermöglichen es Benutzern, sich einmal anzumelden und Zugang zu mehreren Anwendungen zu erhalten, ohne sich für jede Anwendung erneut authentifizieren zu müssen. In diesem Zusammenhang haben sich zwei führende Tools herauskristallisiert: Authentik und Keycloak. Beide bieten robuste Lösungen für das Identity Management und damit offene Alternativen zu Diensten wie Auth0 oder Okta. In diesem Artikel werfen wir einen detaillierten Blick auf Authentik und Keycloak, vergleichen ihre Kernfeatures, Einsatzmöglichkeiten und wie sie sich in realen Anwendungsszenarien bewähren. Ziel ist es, Ihnen eine klare Vorstellung davon zu geben, welches Tool für die spezifischen Bedürfnisse Ihres Unternehmens am besten geeignet ist.

Cyber Risiko Check: Wie Sie Sicherheitslücken in Ihrem Unternehmen erkennen und beheben

Wed, 27 Mar 2024 10:38:36 +0000

Ein effektiver Weg, um diese Risiken zu minimieren, ist der Cyber Risiko Check. In diesem Blogpost erfahren Sie, wie Sie mit Hilfe von ayedo Sicherheitslücken in Ihrem Unternehmen erkennen und beheben können.

Was ist ein Cyber Risiko Check?

Ein Cyber Risiko Check ist ein umfassender Ansatz zur Bewertung und Verbesserung der Cybersicherheit eines Unternehmens. Er umfasst die Identifizierung potenzieller Schwachstellen in der IT-Infrastruktur, die Bewertung der damit verbundenen Risiken und die Implementierung von Maßnahmen zur Risikominderung.

Warum ISO 27001 für Unternehmen jeder Größe wichtig ist

Sun, 24 Mar 2024 11:45:36 +0000

Warum ISO 27001 für Unternehmen jeder Größe wichtig ist

Sicherheit von Informationen ist für Unternehmen ein zentrales Anliegen. Von kleinen Start-ups bis hin zu großen multinationalen Konzernen – jedes Unternehmen muss sensible Daten vor Cyber-Bedrohungen schützen und gleichzeitig gesetzliche Anforderungen erfüllen. Hier kommt ISO 27001 ins Spiel, der international anerkannte Standard für Informationssicherheits-Managementsysteme (ISMS). Aber warum ist diese Zertifizierung für Unternehmen jeder Größe so wichtig?

ArgoCD vs Flux

Sat, 23 Mar 2024 11:30:36 +0000

ArgoCD und Flux sind beides Werkzeuge, die für Continuous Deployment (CD) und GitOps-Workflows in Kubernetes-Clustern verwendet werden. Sie automatisieren die Bereitstellung von Anwendungen und Konfigurationen in Kubernetes-Clustern, indem sie die Deklarative Konfiguration in Git-Repositories überwachen und Änderungen in Echtzeit auf die Cluster anwenden. Hier sind die Hauptunterschiede zwischen ArgoCD und Flux:

Kriterium	ArgoCD	Flux
Entwicklung	Von Intuit entwickelt und in CNCF beheimatet	Von Weaveworks entwickelt, jetzt in CNCF unterstützt
Architektur	Zentraler Steuerungs- und Überwachungsmodul	Modulare Architektur mit verschiedenen Controllern
Unterstützte Funktionen	Automatische Synchronisierung, Rollback, Überwachung, Integration mit CI/CD	Synchronisierung, automatische Updates, Rollback, Integration mit CI/CD
Benutzeroberfläche	Eingebaute webbasierte Benutzeroberfläche	Keine eingebaute Benutzeroberfläche, CLI-basiert
Bedienungsfreundlichkeit	Einfachere Bedienung mit eingebauter Benutzeroberfläche	CLI-basiert, kann aber mit externen Tools integriert werden
Community und Ökosystem	Aktive Community und wachsendes Ökosystem	Aktive Community und wachsendes Ökosystem

Ursprung und Entwicklung:

Kubernetes vs VMWare

Fri, 22 Mar 2024 11:30:36 +0000

Kriterium	Kubernetes	VMware
Technologie	Container-Orchestrierungsplattform	Virtualisierungsplattform
Abstraktionsebene	Virtualisiert Anwendungen auf Container-Ebene	Virtualisiert Hardware auf Server-Ebene
Anwendungsbereich	Bereitstellung und Verwaltung von Containeranwendungen in Cloud-Umgebungen	Serverkonsolidierung, Desktop-Virtualisierung, Cloud-Infrastrukturen
Architektur	Master-Slave-Architektur mit Kubernetes-Knoten	Hypervisor (z. B. VMware ESXi) und Management-Software (z. B. vSphere)
Einsatzort	Cloud- und Hybrid-Cloud-Umgebungen	Rechenzentren und Cloud-Infrastrukturen
Funktionen	Automatisierte Bereitstellung, Skalierung und Verwaltung von Containern	Serverkonsolidierung, Lastenausgleich, Ressourcenoptimierung
Portabilität	Portabilität von Containeranwendungen über verschiedene Cloud-Plattformen hinweg	Portabilität von VMs über verschiedene VMware-Produkte hinweg
Beispielprodukte	Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS)	VMware vSphere, VMware ESXi, VMware vCenter Server

Diese Tabelle bietet eine übersichtliche Darstellung der Unterschiede zwischen Kubernetes und VMware in Bezug auf Technologie, Abstraktionsebene, Anwendungsbereich, Architektur, Einsatzort, Funktionen, Portabilität und Beispielprodukte.

Managed Kubernetes im Vergleich

Wed, 20 Mar 2024 11:30:36 +0000

TL;DR

Kriterium	AWS EKS	Azure AKS	Google GKE
Preisgestaltung	Komplex, basierend auf Instanzen, Diensten und Datenübertragung	Variiert je nach gewähltem Knotentyp und Anzahl der Knoten	Abhängig von Knotenkonfiguration, Speicher und Diensten
Verwaltungsfeatures	Automatische Skalierung, Überwachung, Logging, Integration mit anderen AWS-Diensten	Automatische Skalierung, Überwachung, Integration mit Azure-Diensten	Automatische Skalierung, Überwachung, Integration mit Google Cloud-Diensten
Leistung und Skalierbarkeit	Hohe Leistung, unterstützt durch AWS-Infrastruktur	Hohe Verfügbarkeit und Leistung, unterstützt durch Azure-Infrastruktur	Hochskalierbare Kubernetes-Cluster, unterstützt durch Google Cloud-Infrastruktur
Sicherheit	VPC-Isolation, IAM-Rollen, Integration mit AWS-Sicherheitsdiensten	Azure Active Directory-Integration, Netzwerksicherheitsgruppen, Sicherheitscenter-Integration	Automatische Patches, Netzwerksicherheit, IAM-Integration
Support und Community	Große AWS-Community, umfangreicher Amazon-Support	Azure-Community, Azure-Supportteam	Große Kubernetes-Community, Google Cloud-Unterstützung

Was ist Kubernetes?

Kubernetes ist eine Open-Source-Plattform zur Automatisierung, Bereitstellung und Skalierung von Containeranwendungen. Container sind eine Möglichkeit, Anwendungen und ihre Abhängigkeiten zu verpacken, um eine schnelle Bereitstellung und konsistente Ausführung zu ermöglichen. Kubernetes verwaltet diese Container über Cluster von Hosts und bietet Tools zur Skalierung, Verwaltung und Überwachung der Containeranwendungen. In diesem Beitrag vergleichen wir die beliebtesten Europäischen Managed Kubernetes Anbieter.

Erhöhte Sicherheit für Ihr Unternehmen: Die Vorteile des Cyber Risiko Checks

Wed, 13 Mar 2024 10:38:36 +0000

Die digitale Transformation bringt nicht nur Vorteile, sondern auch neue Herausforderungen im Bereich der Cybersicherheit mit sich. Um diesen Herausforderungen zu begegnen und die Sicherheit Ihres Unternehmens zu gewährleisten, ist ein Cyber Risiko Check unerlässlich. In diesem Blogpost erklären wir Ihnen die zahlreichen Vorteile des Cyber Risiko Checks und wie ayedo Ihnen helfen kann, Ihre Sicherheitsstandards zu erhöhen.

Was ist ein Cyber Risiko Check?

Ein Cyber Risiko Check ist ein umfassender Prozess zur Bewertung der IT-Sicherheitslage eines Unternehmens. Er identifiziert Schwachstellen, bewertet Risiken und schlägt Maßnahmen zur Risikominderung vor. Ziel ist es, die IT-Infrastruktur sicherer und widerstandsfähiger gegen Cyber-Bedrohungen zu machen.

ISO 27001: Der Goldstandard für Informationssicherheit – Was bedeutet das für Ihr Unternehmen?

Sun, 10 Mar 2024 11:45:36 +0000

ISO 27001: Der Goldstandard für Informationssicherheit – Was bedeutet das für Ihr Unternehmen?

Unternehmen müssen heute mehr denn je ihre sensiblen Daten vor Cyber-Bedrohungen schützen und gleichzeitig gesetzlichen Anforderungen gerecht werden. Dabei spielt die Informationssicherheit eine zentrale Rolle. Hier setzt ISO 27001 an, der international anerkannte Standard für Informationssicherheits-Managementsysteme (ISMS). Doch welche Bedeutung hat diese Zertifizierung für Ihr Unternehmen?

Software Defined Networking

Tue, 05 Mar 2024 11:30:36 +0000

“Software Defined Networking” (SDN) ist ein Ansatz zur Netzwerkverwaltung, der die Steuerung des Netzwerkverkehrs von den physischen Geräten (wie Switches und Router) entkoppelt und in eine Softwareebene verlagert. Dies ermöglicht eine zentralisierte Verwaltung des Netzwerks durch abstrahierte Kontrollebenen, was zu einer höheren Flexibilität, einfacherer Skalierbarkeit und besserer Anpassungsfähigkeit an sich ändernde Anforderungen führt. SDN vereinfacht die Netzwerkkonfiguration und -optimierung, indem es Programmierschnittstellen (APIs) für die Entwicklung von Anwendungen bereitstellt, die Netzwerkressourcen intelligent verwalten können.

Add-ons

Sun, 03 Mar 2024 11:30:36 +0000

Add-ons (Erweiterungen) sind Ressourcen, die die Funktionalität von Kubernetes erweitern. Das Manual Installation von Erweiterungen erklärt ausführlicher, wie Sie Erweiterungen in Ihrem Cluster verwenden können, und listet einige beliebte Erweiterungen auf.

Kubernetes ist eine leistungsstarke Plattform für die Verwaltung von Containeranwendungen und bietet eine Vielzahl von Funktionen und Möglichkeiten. Mit Hilfe von Add-ons können Sie diese Funktionalitäten weiter anpassen und erweitern, um den Anforderungen Ihrer spezifischen Anwendung gerecht zu werden. Von Überwachungswerkzeugen bis hin zu Lastausgleichslösungen bieten Add-ons eine breite Palette von Erweiterungen, die Ihre Kubernetes-Umgebung noch leistungsfähiger machen können.

Admission Controller

Sun, 03 Mar 2024 11:30:36 +0000

Ein Admission Controller oder auch Zulassungscontroller ist ein Code-Abschnitt, der Anfragen an den Kubernetes-API-Server abfängt, bevor das Objekt dauerhaft gespeichert wird. Zulassungscontroller sind für den Kubernetes-API-Server konfigurierbar und können “validierend”, “verändernd” oder beides sein. Jeder Zulassungscontroller kann die Anfrage ablehnen. Verändernde Controller können die Objekte, die sie zulassen, ändern; validierende Controller dürfen dies nicht.

Der Admission Controller spielt eine wichtige Rolle im Kubernetes-Ökosystem, indem er sicherstellt, dass nur gültige und autorisierte Anfragen verarbeitet und akzeptiert werden. Durch die Interzeption von Anfragen vor ihrer dauerhaften Speicherung ermöglicht der Admission Controller die Implementierung von Sicherheitsrichtlinien, Validierungen und anderen Kontrollmechanismen auf Cluster-Ebene.

Affinity

Sun, 03 Mar 2024 11:30:36 +0000

Affinity oder auch Affinität ist in Kubernetes eine Reihe von Regeln, die dem Scheduler Hinweise darauf geben, wo Pods platziert werden sollen.

Es gibt zwei Arten von Affinität:

Knotenaffinität

Pod-zu-Pod-Affinität Die Regeln werden mithilfe der Kubernetes-Labels definiert und in den Pods angegeben. Sie können entweder erforderlich oder bevorzugt sein, je nachdem, wie streng Sie möchten, dass der Scheduler sie durchsetzt.

Die Knotenaffinität ermöglicht es Ihnen, die Pods auf bestimmten Nodeaim Cluster zu platzieren, basierend auf den von Ihnen festgelegten Regeln. Dies kann nützlich sein, um Ressourcenanforderungen zu erfüllen oder um sicherzustellen, dass bestimmte Pods in der Nähe bestimmter Datenquellen oder Dienste platziert werden.

Aggregation Layer

Sun, 03 Mar 2024 11:30:36 +0000

Die Aggregations-Schicht ermöglicht es Ihnen, zusätzliche APIs im Kubernetes-Cluster zu installieren.

Wenn Sie den Kubernetes-API-Server so konfiguriert haben, dass er zusätzliche APIs unterstützt, können Sie APIService-Objekte hinzufügen, um einen URL-Pfad im Kubernetes-API “anzufragen”.

Die Aggregations-Schicht ist ein leistungsstarkes Werkzeug, das es Ihnen ermöglicht, benutzerdefinierte APIs oder APIs von Drittanbietern nahtlos in Ihren Kubernetes-Cluster zu integrieren. Indem Sie APIService-Objekte erstellen, können Sie die APIs registrieren und bereitstellen, und der Kubernetes-API-Server behandelt sie wie jede andere native API.

Annotation

Sun, 03 Mar 2024 11:30:36 +0000

Eine Annotation ist ein Schlüssel-Wert-Paar, das verwendet wird, um beliebige nicht-identifizierende Metadaten an Objekte anzuhängen.

Die Metadaten in einer Annotation können klein oder groß, strukturiert oder unstrukturiert sein und Zeichen enthalten, die von Labels nicht erlaubt sind. Clients wie Tools und Bibliotheken können diese Metadaten abrufen.

Annotationen sind nützlich, um zusätzliche Informationen oder Kontext zu Objekten in einem Kubernetes-Cluster hinzuzufügen. Sie bieten eine flexible Möglichkeit, relevante Details zu speichern, die nicht in Labels passen oder spezielle Formatierungsanforderungen haben.

API Group

Sun, 03 Mar 2024 11:30:36 +0000

Die API-Gruppe in Kubernetes ist ein grundlegendes Konzept, das die Struktur und Organisation der Kubernetes-API maßgeblich beeinflusst. Sie ermöglicht eine logische Gruppierung von verwandten Ressourcen und Funktionen, was die Verwaltung und Erweiterung der Plattform erheblich erleichtert. Eine API-Gruppe definiert eine Sammlung von zusammenhängenden Endpunkten oder Pfaden innerhalb der API, die eine bestimmte Domäne oder eine bestimmte Funktion repräsentieren.

Durch die Möglichkeit, einzelne API-Gruppen sowie spezifische Pfade zu aktivieren oder zu deaktivieren, bietet Kubernetes eine hohe Flexibilität und Anpassungsfähigkeit. Dies ermöglicht es Administratoren, die API-Umgebung ihres Clusters genau auf ihre Anforderungen und Sicherheitsrichtlinien zuzuschneiden. Sie können unerwünschte Pfade deaktivieren oder nur bestimmten Benutzergruppen Zugriff auf bestimmte API-Gruppen gewähren, um die Sicherheit und Kontrolle zu erhöhen.

API Initiated Eviction

Sun, 03 Mar 2024 11:30:36 +0000

API-initiated eviction ist der Prozess, bei dem Sie die Eviction-API verwenden, um ein Eviction-Objekt zu erstellen, das eine kontrollierte Beendigung von Pods auslöst.

Sie können die Beendigung entweder direkt über die Eviction-API anfordern, indem Sie einen Client des kube-apiservers wie den Befehl “kubectl drain” verwenden. Wenn ein Eviction-Objekt erstellt wird, beendet der API-Server den Pod auf eine sanfte Weise.

API-initiierte Beendigungen respektieren Ihre konfigurierten PodDisruptionBudgets und terminationGracePeriodSeconds.

API-initiierte Beendigungen unterscheiden sich von Node-Pressure-Eviction. Bei Node-Pressure-Eviction wird ein Pod beendet, weil der Knoten Ressourcenknappheit hat oder aus anderen Gründen nicht mehr in der Lage ist, den Pod auszuführen. Im Gegensatz dazu wird bei API-initiierten Beendigungen die Beendigung explizit durch eine API-Anfrage ausgelöst, die die Beendigung von Pods auf eine kontrollierte und geplante Weise ermöglicht.

API Server

Sun, 03 Mar 2024 11:30:36 +0000

Der API-Server, auch bekannt als kube-apiserver, ist ein wesentlicher Bestandteil der Kubernetes-Steuerungsebene, der die Kubernetes-API freigibt. Der API-Server fungiert als Front-End für die Kubernetes-Steuerungsebene.

Die Hauptimplementierung eines Kubernetes-API-Servers ist der kube-apiserver. Der kube-apiserver ist so konzipiert, dass er horizontal skalierbar ist, das heißt, er skaliert durch Bereitstellung weiterer Instanzen. Sie können mehrere Instanzen des kube-apiserver ausführen und den Datenverkehr zwischen diesen Instanzen ausbalancieren.

Durch die Skalierbarkeit des kube-apiserver können Kubernetes-Cluster problemlos wachsen und die steigenden Anforderungen an die Verarbeitung von API-Anfragen bewältigen. Die horizontale Skalierung ermöglicht eine bessere Lastenverteilung und Ausfallsicherheit, da die Belastung auf mehrere Instanzen verteilt werden kann und Ausfälle einzelner Instanzen den Gesamtbetrieb des Clusters nicht beeinträchtigen.

App Container

Sun, 03 Mar 2024 11:30:36 +0000

App-Container sind die Container in einem Pod, die gestartet werden, nachdem alle Init-Container abgeschlossen wurden.

Ein Init-Container ermöglicht es Ihnen, Initialisierungsdetails zu trennen, die für die Gesamtarbeitslast wichtig sind, und die nicht weiter ausgeführt werden müssen, sobald der Anwendungscontainer gestartet wurde. Wenn ein Pod keine Init-Container konfiguriert hat, sind alle Container in diesem Pod App-Container.

App-Container enthalten die Hauptanwendungen oder Prozesse, die im Pod ausgeführt werden sollen. Sie werden gestartet, nachdem die Initialisierungsaufgaben der Init-Container abgeschlossen sind. App-Container sind in der Regel für die eigentliche Ausführung der Anwendungslogik oder -services zuständig und bleiben während der Lebensdauer des Pods aktiv.

Application Architect

Sun, 03 Mar 2024 11:30:36 +0000

Ein Application Architect oder auch Anwendungsarchitekt ist eine Person, die für das hochrangige Design einer Anwendung verantwortlich ist.

Ein Architekt stellt sicher, dass die Implementierung einer Anwendung es ihr ermöglicht, auf skalierbare und wartbare Weise mit ihren umgebenden Komponenten zu interagieren. Zu den umgebenden Komponenten gehören Datenbanken, Logging-Infrastrukturen und andere Mikroservices.

Die Rolle eines Anwendungsarchitekten umfasst die Gestaltung der Struktur und des Zusammenspiels verschiedener Module und Komponenten innerhalb einer Anwendung. Sie müssen sicherstellen, dass die Architektur der Anwendung die Leistungsanforderungen erfüllt, zukunftssicher ist und sich den sich ändernden Anforderungen und Bedingungen anpassen kann.

Application Developer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Application Developer oder auch Anwendungsentwickler ist eine Person, die Anwendungen schreibt, die in einem Kubernetes-Cluster ausgeführt werden.

Ein Anwendungsentwickler konzentriert sich auf einen Teil einer Anwendung. Das Ausmaß ihrer Aufmerksamkeit kann erheblich variieren, je nachdem, ob sie sich auf eine kleine, spezifische Funktion oder auf die Entwicklung und Wartung eines umfangreicheren Teils der Anwendung konzentrieren.

Die Aufgaben eines Anwendungsentwicklers umfassen typischerweise das Schreiben von Code, das Testen und Debuggen von Software, das Implementieren neuer Funktionen und das Warten und Aktualisieren bestehender Anwendungen. Sie arbeiten oft eng mit anderen Entwicklern, Testern und Projektmanagern zusammen, um die Anwendungsentwicklung effizient zu gestalten und sicherzustellen, dass die erstellten Lösungen den Anforderungen und Standards entsprechen.

Applications

Sun, 03 Mar 2024 11:30:36 +0000

Die Anwendungsebene ist die Schicht, in der verschiedene containerisierte Anwendungen ausgeführt werden. In Kubernetes werden Anwendungen typischerweise als Pods repräsentiert, die Container enthalten, die spezifische Anwendungsfunktionen ausführen. Diese Container können Teil derselben oder verschiedener Workloads sein, die von Kubernetes-Objekten wie Deployments, StatefulSets oder Jobs verwaltet werden. Die Anwendungsebene bildet die oberste Schicht der Kubernetes-Architektur und ist der Bereich, in dem Endbenutzerinteraktionen stattfinden und Geschäftsanforderungen erfüllt werden.

Link zum offiziellen Glossar

Approver

Sun, 03 Mar 2024 11:30:36 +0000

Ein Approver ist eine wichtige Rolle im Entwicklungsprozess von Kubernetes, da sie die Verantwortung für die Überprüfung und Genehmigung von Codebeiträgen tragen. Während die Codeprüfung dazu dient, die Qualität und Korrektheit des Codes zu gewährleisten, geht es bei der Genehmigung um die umfassende Akzeptanz eines Beitrags. Dies bedeutet, dass ein Approver nicht nur den Code selbst überprüft, sondern auch sicherstellen muss, dass der Beitrag rückwärts- und vorwärtskompatibel ist, API- und Flaggenkonventionen einhält und keine subtilen Leistungs- oder Korrektheitsprobleme verursacht. Darüber hinaus müssen Approver die Wechselwirkungen des neuen Codes mit anderen Teilen des Systems berücksichtigen und sicherstellen, dass der Beitrag reibungslos in das Gesamtsystem integriert werden kann.

cAdvisor

Sun, 03 Mar 2024 11:30:36 +0000

cAdvisor (Container Advisor) ist ein unverzichtbares Werkzeug für die Verwaltung von Containern in Kubernetes-Clustern und anderen Containerumgebungen. Es bietet den Benutzern ein detailliertes Verständnis für die Ressourcennutzung und Leistungsmerkmale ihrer laufenden Container.

Als laufender Daemon spielt cAdvisor eine entscheidende Rolle, indem es kontinuierlich Informationen über laufende Container sammelt, aggregiert, verarbeitet und exportiert. Für jeden Container werden verschiedene Daten gespeichert, darunter Ressourcenisolationsparameter, historische Ressourcennutzung, Histogramme der vollständigen historischen Ressourcennutzung und Netzwerkstatistiken. Diese umfassenden Informationen ermöglichen es den Benutzern, die Ressourcennutzung ihrer Container zu überwachen, Engpässe zu identifizieren und Engpässe zu beheben.

Certificate

Sun, 03 Mar 2024 11:30:36 +0000

Ein Certificate oder auf deutsch Zertifikat ist eine kryptografisch sichere Datei, die verwendet wird, um den Zugriff auf den Kubernetes-Cluster zu validieren.

Zertifikate ermöglichen es Anwendungen innerhalb eines Kubernetes-Clusters, sicher auf die Kubernetes-API zuzugreifen. Sie dienen dazu, zu überprüfen, ob Clients berechtigt sind, auf die API zuzugreifen.

Die Verwendung von Zertifikaten ist eine bewährte Methode, um die Sicherheit und Integrität von Kommunikationen innerhalb des Kubernetes-Clusters zu gewährleisten. Durch die Verwendung von kryptografisch signierten Zertifikaten können Anwendungen und Benutzer ihre Identität gegenüber dem Kubernetes-API-Server nachweisen und sicherstellen, dass nur autorisierte Parteien auf sensible Cluster-Ressourcen zugreifen können.

cgroup (control group)

Sun, 03 Mar 2024 11:30:36 +0000

cgroup (Control Group) ist eine Gruppe von Linux-Prozessen mit optionaler Ressourcenisolierung, Buchführung und Grenzen. Es handelt sich um ein Merkmal des Linux-Kernels, das die Ressourcennutzung (CPU, Speicher, Festplatten-E/A, Netzwerk) für eine Sammlung von Prozessen begrenzt, Buch führt und isoliert.

cgroup ermöglicht es Administratoren, die Ressourcennutzung von Prozessen auf einem Linux-System effektiv zu kontrollieren und zu verwalten. Indem Ressourcen wie CPU-Zeit, Speicher und E/A-Bandbreite auf Gruppenebene begrenzt werden können, können Administratoren sicherstellen, dass kritische Systemressourcen fair und effizient zwischen verschiedenen Prozessen oder Gruppen von Prozessen aufgeteilt werden.

CIDR

Sun, 03 Mar 2024 11:30:36 +0000

CIDR (Classless Inter-Domain Routing) ist eine Notation zur Beschreibung von IP-Adressblöcken und wird in verschiedenen Netzwerkkonfigurationen stark verwendet.

Im Kontext von Kubernetes wird jedem Node ein Bereich von IP-Adressen über die Startadresse und eine Subnetzmaske mit CIDR zugewiesen. Dadurch können Nodes jedem Pod eine eindeutige IP-Adresse zuweisen. Obwohl CIDR ursprünglich ein Konzept für IPv4 war, wurde es auch auf IPv6 erweitert.

CIDR ermöglicht eine effiziente Verwaltung von IP-Adressbereichen, indem es eine flexible Möglichkeit bietet, Adressblöcke zu definieren und zuzuweisen. Durch die Verwendung von CIDR können Administratoren IP-Adressen logisch gruppieren und die Netzwerkressourcen effizienter nutzen.

Cloud Controller Manager

Sun, 03 Mar 2024 11:30:36 +0000

Der Cloud Controller Manager ist eine essenzielle Komponente der Kubernetes-Steuerungsebene, die spezifische Steuerlogik für cloudbasierte Infrastrukturen enthält. Seine Hauptaufgabe besteht darin, eine Schnittstelle zwischen Kubernetes-Clustern und den APIs der Cloud-Anbieter zu schaffen. Durch diese Verbindung ermöglicht der Cloud Controller Manager die nahtlose Integration von Kubernetes mit den verschiedenen Diensten und Funktionen, die von Cloud-Plattformen bereitgestellt werden.

Eine der wichtigsten Funktionen des Cloud Controller Managers besteht darin, die Komponenten zu trennen, die mit der Cloud-Plattform interagieren, von den Komponenten, die ausschließlich mit dem Kubernetes-Cluster interagieren. Dies ermöglicht eine klare Trennung der Verantwortlichkeiten und erhöht die Flexibilität bei der Verwaltung von Kubernetes-Clustern in cloudbasierten Umgebungen.

Cloud Native Computing Foundation (CNCF)

Sun, 03 Mar 2024 11:30:36 +0000

Die Cloud Native Computing Foundation (CNCF) ist eine Organisation, die nachhaltige Ökosysteme aufbaut und eine Community um Projekte fördert, die Container als Teil einer Microservices-Architektur orchestrieren. Kubernetes ist eines der prominentesten Projekte der CNCF und spielt eine zentrale Rolle in der Verwaltung und Bereitstellung von Containern in cloudbasierten Umgebungen.

Als Teil der Linux Foundation ist die CNCF bestrebt, cloudbasiertes Computing allgegenwärtig zu machen. Ihr Ziel ist es, die Entwicklung und Nutzung von Cloud-nativen Technologien zu fördern und Innovationen in diesem Bereich voranzutreiben. Die CNCF unterstützt eine Vielzahl von Projekten und Initiativen, die dazu beitragen, Cloud-natives Computing zu etablieren und zu verbessern.

Cloud Provider

Sun, 03 Mar 2024 11:30:36 +0000

Cloud-Anbieter, auch bekannt als Cloud Service Provider (CSP), sind Unternehmen oder Organisationen, die Cloud-Computing-Plattformen und -Dienste bereitstellen. Diese Dienstleister spielen eine entscheidende Rolle bei der Bereitstellung von Infrastruktur, Plattformen und Diensten, die es Unternehmen ermöglichen, ihre IT-Ressourcen flexibel zu skalieren, effizienter zu nutzen und kostengünstiger zu betreiben.

Cloud-Anbieter bieten eine Vielzahl von Diensten an, darunter verwaltete Infrastruktur (Infrastructure as a Service, IaaS). Bei verwalteter Infrastruktur übernimmt der Cloud-Anbieter die Verantwortung für die Bereitstellung und Wartung von Servern, Speicher und Netzwerkinfrastruktur, während Kunden sich auf das Betreiben von Anwendungen und Diensten konzentrieren können, ohne sich um die zugrunde liegende Hardware kümmern zu müssen. Dies ermöglicht es Unternehmen, schnell skalierbare und hochverfügbare Lösungen bereitzustellen, ohne umfangreiche Investitionen in Hardware tätigen zu müssen.

Cluster

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster ist eine Gruppe von Arbeitsmaschinen, die als Node bezeichnet werden und containerisierte Anwendungen ausführen. Jeder Cluster hat mindestens einen Arbeitsknoten.

Die Arbeitsknoten(Worker Nodes) hosten die Pods, die die Komponenten der Anwendungs-Workload sind. Der Steuerungsebene (Control Plane) verwaltet die Arbeitsknoten und die Pods im Cluster. In Produktionsumgebungen läuft die Steuerungsebene in der Regel über mehrere Computer, und ein Cluster läuft normalerweise auf mehreren Nodes, was eine Fehlerverträglichkeit und hohe Verfügbarkeit gewährleistet.

Cluster sind eine grundlegende Infrastrukturkomponente für die Bereitstellung und Verwaltung von containerisierten Anwendungen. Sie ermöglichen es Organisationen, Ressourcen effizient zu nutzen, die Skalierbarkeit zu verbessern und die Ausfallsicherheit ihrer Anwendungen zu erhöhen.

Cluster Architect

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster-Architekt ist eine Person, die Infrastrukturen entwirft, die ein oder mehrere Kubernetes-Cluster umfassen.

Cluster-Architekten spielen eine entscheidende Rolle bei der Gestaltung von Infrastrukturen, die Kubernetes-Cluster umfassen. Sie sind dafür verantwortlich, die Architektur der Cluster zu entwerfen, um sicherzustellen, dass sie den Anforderungen der Anwendungen und Geschäftsprozesse gerecht werden. Dies umfasst die Planung und Gestaltung von Ressourcen wie Arbeitsknoten, Speicher, Netzwerke und Sicherheitsrichtlinien.

Ein wesentlicher Aspekt der Rolle eines Cluster-Architekten besteht darin, bewährte Verfahren für verteilte Systeme anzuwenden. Dazu gehören die Gewährleistung hoher Verfügbarkeit, Skalierbarkeit, Zuverlässigkeit und Sicherheit der Cluster. Cluster-Architekten müssen sich mit Technologien und Praktiken vertraut machen, die für die Verwaltung von Kubernetes-Clustern in Produktionsumgebungen relevant sind, einschließlich der Implementierung von Failover-Mechanismen, Lastenausgleich und Sicherheitsmaßnahmen.

Cluster Infrastructure

Sun, 03 Mar 2024 11:30:36 +0000

Die Infrastrukturebene stellt und pflegt virtuelle Maschinen (VMs), Netzwerke, Sicherheitsgruppen und andere Ressourcen bereit.

Die Infrastrukturebene bildet das Fundament für die Bereitstellung von Kubernetes-Clustern und bietet die grundlegenden Ressourcen, die für den Betrieb der Cluster erforderlich sind. Dazu gehören VMs, auf denen die Arbeitsknoten und Steuerungsebenen des Clusters ausgeführt werden, sowie das Netzwerk, das die Kommunikation zwischen den verschiedenen Komponenten im Cluster ermöglicht.

Die Bereitstellung und Wartung von VMs ist ein wichtiger Aspekt der Infrastrukturebene. VMs dienen als zugrunde liegende Rechenressource für die Ausführung von Containern und Pods im Kubernetes-Cluster. Die Infrastrukturebene ist dafür verantwortlich, sicherzustellen, dass ausreichend VM-Ressourcen vorhanden sind, um die Anwendungs-Workloads zu unterstützen, und dass diese Ressourcen effizient verwaltet und skaliert werden können, um den sich ändernden Anforderungen gerecht zu werden.

Cluster Operator

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster Operator ist eine Person, die Cluster konfiguriert, steuert und überwacht.

Die Hauptverantwortung eines Cluster Operators besteht darin, einen Cluster betriebsbereit zu halten. Dies beinhaltet regelmäßige Wartungsarbeiten oder Upgrades, um sicherzustellen, dass der Cluster ordnungsgemäß funktioniert und die Anwendungen und Dienste darauf reibungslos ausgeführt werden können.

Cluster Operators spielen eine entscheidende Rolle bei der Gewährleistung der Verfügbarkeit und Leistungsfähigkeit von Kubernetes-Clustern. Sie überwachen den Zustand des Clusters, erkennen potenzielle Probleme frühzeitig und ergreifen entsprechende Maßnahmen, um Probleme zu beheben und die Stabilität des Clusters sicherzustellen.

Cluster Operatorions

Sun, 03 Mar 2024 11:30:36 +0000

Cluster Operations umfassen die Arbeit, die zur Verwaltung eines Kubernetes-Clusters erforderlich ist: die Verwaltung der täglichen Betriebsabläufe und die Koordination von Upgrades.

Beispiele für Cluster Operations umfassen:

Bereitstellung neuer Nodes zur Skalierung des Clusters: Dies umfasst die Hinzufügung neuer Arbeitsknoten (Worker Nodes) zum Cluster, um die Ressourcenkapazität zu erhöhen und die Arbeitslasten zu verteilen.

Durchführung von Software-Upgrades: Dies beinhaltet das Aktualisieren der Kubernetes-Software sowie anderer beteiligter Komponenten, um Fehlerkorrekturen, neue Funktionen und Sicherheitsverbesserungen zu implementieren.

Code Contributor

Sun, 03 Mar 2024 11:30:36 +0000

Ein Code-Contributor ist eine Person, die Code entwickelt und zur Kubernetes-Open-Source-Codebasis beiträgt. Diese Personen sind aktive Mitglieder der Community, die an einem oder mehreren Special Interest Groups (SIGs) teilnehmen.

Die Rolle eines Code-Contributors ist entscheidend für die kontinuierliche Weiterentwicklung und Verbesserung der Kubernetes-Plattform. Sie arbeiten an der Implementierung neuer Funktionen, der Behebung von Fehlern und der Optimierung der Leistung. Dies kann die Entwicklung von neuen Features, die Überarbeitung bestehender Codes oder die Implementierung von Bugfixes umfassen.

ConfigMap

Sun, 03 Mar 2024 11:30:36 +0000

Eine ConfigMap ist ein äußerst nützliches API-Objekt in Kubernetes, das dazu dient, nicht vertrauliche Konfigurationsdaten in Form von Schlüssel-Wert-Paaren zu speichern. Diese Konfigurationsdaten können dann von Pods verwendet werden, entweder als Umgebungsvariablen, Befehlszeilenargumente oder als Konfigurationsdateien, die in einem Volume gemountet werden.

Die Verwendung einer ConfigMap bietet eine Reihe von Vorteilen. Zunächst ermöglicht sie es, die Konfiguration von Anwendungen von den Container-Images zu entkoppeln. Dies bedeutet, dass Umgebungs-spezifische Konfigurationsdaten wie z.B. URLs von externen Diensten oder benutzerdefinierte Einstellungen nicht hart in den Container-Images kodiert werden müssen. Stattdessen können sie separat in einer ConfigMap gespeichert werden, was die Portabilität und Wiederverwendbarkeit der Container-Images erhöht.

Container

Sun, 03 Mar 2024 11:30:36 +0000

Ein Container ist eine leichtgewichtige und portable Ausführungsumgebung, die eine Anwendung und all ihre Abhängigkeiten in einem isolierten Paket zusammenfasst. Durch die Containerisierung werden Anwendungen von der zugrunde liegenden Infrastruktur entkoppelt, was die Bereitstellung in verschiedenen Umgebungen, wie Clouds oder Betriebssystemen, vereinfacht und das Skalieren erleichtert.

Containerisierte Anwendungen, die in Containern ausgeführt werden, bieten eine Reihe von Vorteilen. Sie sind portabel und konsistent, da sie in einer standardisierten Umgebung laufen, unabhängig von der zugrunde liegenden Infrastruktur. Dies ermöglicht eine konsistente Entwicklung, Bereitstellung und Ausführung von Anwendungen in verschiedenen Umgebungen.

Container Environment Variable

Sun, 03 Mar 2024 11:30:36 +0000

Container Environment Variables oder auch Container Umgebungsvariablen sind Name=Wert-Paare, die wertvolle Informationen über Container bereitstellen, die in einem Pod ausgeführt werden. Sie sind entscheidend für die Kommunikation und Konfiguration von Anwendungen innerhalb des Kubernetes-Clusters.

Diese Variablen dienen dazu, wichtige Informationen bereitzustellen, die von den laufenden containerisierten Anwendungen benötigt werden. Dazu gehören Details zum Dateisystem, Informationen über den Container selbst sowie andere Cluster-Ressourcen wie Dienstendpunkte. Ein typisches Beispiel ist die Konfiguration von Anwendungen, die auf Datenbanken oder anderen externen Diensten zugreifen müssen. Durch das Setzen von Umgebungsvariablen können die Anwendungen die Verbindungsinformationen zu diesen Diensten erhalten, ohne dass sie hartcodiert sein müssen.

Container Lifecycle Hooks

Sun, 03 Mar 2024 11:30:36 +0000

Container-Lifecycle-Hooks sind Mechanismen, die Ereignisse im Lebenszyklus der Container-Verwaltung offenlegen und es dem Benutzer ermöglichen, Code auszuführen, wenn diese Ereignisse eintreten.

Es gibt zwei Hooks, die den Containern zur Verfügung gestellt werden:

PostStart: Dieser Hook wird unmittelbar nach der Erstellung eines Containers ausgeführt. Er bietet eine Möglichkeit, spezifische Aktionen auszuführen, sobald der Container initialisiert und einsatzbereit ist. Beispielsweise können hier Initialisierungsaufgaben wie das Herstellen einer Verbindung zu externen Diensten oder das Laden von Konfigurationsdaten durchgeführt werden.

Container Network Interface (CNI)

Sun, 03 Mar 2024 11:30:36 +0000

Container Network Interface (CNI)-Plugins sind eine Art von Netzwerkplugin, das der appc/CNI-Spezifikation entspricht.

Die Container Network Interface (CNI) definiert eine standardisierte Schnittstelle für die Konfiguration von Container-Netzwerken in Container-Runtime-Umgebungen. CNI-Plugins sind Erweiterungen, die diese Schnittstelle implementieren und es Kubernetes ermöglichen, Netzwerkkonfigurationen für Container bereitzustellen und zu verwalten.

CNI-Plugins sind so konzipiert, dass sie in einer Vielzahl von Umgebungen und Szenarien eingesetzt werden können. Sie können verschiedene Netzwerktechnologien unterstützen, darunter Bridge, VLAN, VXLAN, Host-Gateway und viele andere. Die Wahl des geeigneten CNI-Plugins hängt von den Anforderungen und Präferenzen des Clusters ab, einschließlich der Leistung, Skalierbarkeit und Kompatibilität mit vorhandener Infrastruktur.

Container Runtime

Sun, 03 Mar 2024 11:30:36 +0000

Ein Container-Laufzeit (Container Runtime) ist eine grundlegende Komponente, die Kubernetes ermöglicht, Container effektiv auszuführen. Sie ist verantwortlich für das Verwalten der Ausführung und des Lebenszyklus von Containern innerhalb der Kubernetes-Umgebung.

Kubernetes unterstützt verschiedene Container-Laufzeiten, darunter containerd, CRI-O und jede andere Implementierung des Kubernetes CRI (Container Runtime Interface). Diese Container-Laufzeiten stellen die grundlegenden Funktionen zur Ausführung von Containern bereit und ermöglichen es Kubernetes, Container zu starten, zu stoppen, zu überwachen und zu verwalten.

Container-Laufzeiten implementieren das Kubernetes CRI-Protokoll, das eine standardisierte Schnittstelle zwischen Kubernetes und den verschiedenen Container-Laufzeiten definiert. Dadurch wird die Interoperabilität zwischen Kubernetes und den Container-Laufzeiten gewährleistet, und Kubernetes kann nahtlos mit verschiedenen Container-Laufzeiten arbeiten, ohne auf spezifische Implementierungsdetails eingehen zu müssen.

Container Runtime Interface (CRI)

Sun, 03 Mar 2024 11:30:36 +0000

Die Container Runtime Interface (CRI) ist eine API, die es Container-Laufzeiten ermöglicht, sich mit dem kubelet auf einem Node zu integrieren. Das kubelet ist ein zentraler Node-Agent in einem Kubernetes-Cluster, der für die Verwaltung von Containern auf dem Node verantwortlich ist.

Die CRI definiert eine standardisierte Schnittstelle zwischen dem kubelet und verschiedenen Container-Laufzeiten. Durch die Implementierung der CRI können Container-Laufzeiten nahtlos in Kubernetes-Cluster integriert werden, unabhängig von ihrer spezifischen Implementierung oder Technologie.

Die CRI-API spezifiziert die Methoden und Funktionen, die von einer Container-Laufzeit bereitgestellt werden müssen, um mit dem kubelet zu kommunizieren. Dazu gehören unter anderem Funktionen zum Starten, Stoppen, Überwachen und Verwalten von Containern sowie zum Abrufen von Container-Logs und Metadaten.

Container Storage Interface(CSI)

Sun, 03 Mar 2024 11:30:36 +0000

Das Container Storage Interface (CSI) definiert eine standardisierte Schnittstelle zum Bereitstellen von Speichersystemen für Container.

Mit CSI können Anbieter benutzerdefinierte Speicherplugins für Kubernetes erstellen, ohne sie zum Kubernetes-Repository hinzufügen zu müssen (out-of-tree-Plugins). Um einen CSI-Treiber eines Speicheranbieters zu verwenden, muss dieser zunächst in Ihrem Cluster bereitgestellt werden. Anschließend können Sie eine Storage Class erstellen, die diesen CSI-Treiber verwendet.

Die Verwendung von CSI bietet eine Vielzahl von Vorteilen. Sie ermöglicht die Interoperabilität zwischen verschiedenen Speicherlösungen und Kubernetes, da Anbieter ihre eigenen CSI-Treiber implementieren können, die nahtlos in Kubernetes-Cluster integriert werden können. Dies erweitert die Flexibilität und Auswahlmöglichkeiten für Speicherlösungen in Kubernetes.

Containerd

Sun, 03 Mar 2024 11:30:36 +0000

containerd ist eine Container-Laufzeit mit einem Schwerpunkt auf Einfachheit, Robustheit und Portabilität. Als Container-Laufzeit läuft containerd als Daemon auf Linux- oder Windows-Systemen und übernimmt verschiedene Aufgaben im Zusammenhang mit Containern.

Eine der Hauptfunktionen von containerd besteht darin, Container-Images zu verwalten. Das bedeutet, dass containerd für das Herunterladen, Speichern und Verwalten von Container-Images verantwortlich ist. Es ermöglicht die effiziente Speicherung von Images und stellt sicher, dass diese schnell und zuverlässig von Containern verwendet werden können.

Contributor

Sun, 03 Mar 2024 11:30:36 +0000

Ein Contributor ist eine Person, die Code, Dokumentation oder ihre Zeit dem Kubernetes-Projekt oder der Community zur Verfügung stellt.

Beiträge können verschiedene Formen annehmen, darunter Pull Requests (PRs), bei denen Änderungen am Code vorgeschlagen werden, Issues, in denen Probleme oder Verbesserungsvorschläge gemeldet werden, Feedback zu bestehenden Funktionen oder Dokumentation, sowie die aktive Teilnahme an Special Interest Groups (SIGs) oder die Organisation und Teilnahme an Community-Veranstaltungen.

Contributoren sind unverzichtbare Mitglieder der Kubernetes-Community und tragen wesentlich zum Erfolg des Projekts bei. Ihre Arbeit hilft dabei, Fehler zu beheben, neue Funktionen hinzuzufügen, die Dokumentation zu verbessern und die Community durch Wissensaustausch und Unterstützung zu stärken. Sie repräsentieren eine vielfältige Gruppe von Menschen aus verschiedenen Hintergründen und Organisationen, die gemeinsam daran arbeiten, Kubernetes zu einer robusten und leistungsstarken Plattform für Container-Orchestrierung und Cloud-native Anwendungen zu machen.

Contributor License Agreement (CLA)

Sun, 03 Mar 2024 11:30:36 +0000

Ein Contributor License Agreement (CLA) definiert die Bedingungen, unter denen ein Beitragende einer Open-Source-Projektgemeinschaft eine Lizenz für seine Beiträge gewährt.

CLAs sind rechtliche Vereinbarungen, die dazu dienen, rechtliche Streitigkeiten im Zusammenhang mit beigesteuertem Material und geistigem Eigentum (IP) zu lösen. Durch die Unterzeichnung eines CLA erklärt der Beitragende, dass er das Recht hat, den Code oder andere Materialien beizutragen, und gewährt dem Open-Source-Projekt die erforderlichen Rechte zur Nutzung, Verteilung und Lizenzierung seiner Beiträge.

Control Plane

Sun, 03 Mar 2024 11:30:36 +0000

Die Control Plane ist die Container-Orchestrierungsebene, die die API und Schnittstellen zur Definition, Bereitstellung und Verwaltung des Lebenszyklus von Containern bereitstellt.

Diese Ebene besteht aus verschiedenen Komponenten, darunter (aber nicht beschränkt auf):

etcd
API-Server
Scheduler
Controller-Manager
Cloud-Controller-Manager

Diese Komponenten können als traditionelle Betriebssystemdienste (Daemons) oder als Container ausgeführt werden. Die Hosts, auf denen diese Komponenten ausgeführt werden, wurden historisch als “Masters” bezeichnet. Sie bilden das Herzstück eines Kubernetes-Clusters und sind für die Koordination und Steuerung der Cluster-Ressourcen verantwortlich.

Controller

Sun, 03 Mar 2024 11:30:36 +0000

In Kubernetes sind Controller Kontrollschleifen, die den Zustand Ihres Clusters überwachen und bei Bedarf Änderungen vornehmen oder anfordern. Jeder Controller versucht, den aktuellen Zustand des Clusters dem gewünschten Zustand näher zu bringen.

Die Controller überwachen den gemeinsamen Zustand Ihres Clusters über den API-Server (Teil der Control Plane). Einige Controller laufen auch innerhalb der Control Plane und stellen Kontrollschleifen bereit, die für den Betrieb von Kubernetes unerlässlich sind. Zum Beispiel laufen der Deployment-Controller, der DaemonSet-Controller, der Namespace-Controller und der PersistentVolume-Controller (und andere) alle innerhalb des kube-controller-managers.

CRI-O

Sun, 03 Mar 2024 11:30:36 +0000

CRI-O ist ein Tool, das es ermöglicht, OCI-Container-Runtimes mit dem Kubernetes CRI zu verwenden. Es handelt sich dabei um eine Implementierung der Container Runtime Interface (CRI), die die Verwendung von Container-Runtimes ermöglicht, die mit dem Spezifikation der Open Container Initiative (OCI) kompatibel sind.

Durch die Bereitstellung von CRI-O kann Kubernetes jede OCI-konforme Laufzeit als Container-Laufzeit für die Ausführung von Pods verwenden und OCI-Container-Images aus entfernten Registern abrufen.

Indem CRI-O als Bindeglied zwischen Kubernetes und OCI-kompatiblen Runtimes fungiert, ermöglicht es die Nutzung einer breiten Palette von Runtimes, die den OCI-Spezifikationen entsprechen. Dies bietet Flexibilität und Auswahlmöglichkeiten für die Konfiguration und Verwaltung von Containern in Kubernetes-Clustern.

Cronjob

Sun, 03 Mar 2024 11:30:36 +0000

Ein CronJob verwaltet einen Job, der in regelmäßigen Abständen gemäß einem Zeitplan ausgeführt wird. Ähnlich wie eine Zeile in einer crontab-Datei spezifiziert ein CronJob-Objekt einen Zeitplan unter Verwendung des cron-Formats.

Ein CronJob in Kubernetes ermöglicht es Entwicklern, Aufgaben zu definieren, die automatisch und periodisch ausgeführt werden sollen, ohne dass manuelle Eingriffe erforderlich sind. Dies kann nützlich sein für wiederkehrende Aufgaben wie Datensicherungen, periodische Bereinigungen oder die Ausführung von Batch-Jobs zu bestimmten Zeitpunkten.

CustomResourceDefinition

Sun, 03 Mar 2024 11:30:36 +0000

Eine CustomResourceDefinition (CRD) ist benutzerdefinierter Code, der eine Ressource definiert, die Ihrem Kubernetes-API-Server hinzugefügt wird, ohne dass ein vollständiger benutzerdefinierter Server erstellt werden muss.

CRDs ermöglichen es Ihnen, das Kubernetes-API für Ihre Umgebung zu erweitern, wenn die öffentlich unterstützten API-Ressourcen Ihre Anforderungen nicht erfüllen können. Dies gibt Ihnen die Möglichkeit, spezifische Ressourcentypen zu definieren, die speziell auf die Anforderungen Ihrer Anwendung oder Infrastruktur zugeschnitten sind.

Durch die Verwendung von CRDs können Sie benutzerdefinierte Ressourcentypen erstellen, die dieselben Funktionalitäten wie native Kubernetes-Ressourcen haben. Dies umfasst Funktionen wie CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen), Validierung, Statusaktualisierungen und Reaktionsmechanismen auf Ereignisse.

DaemonSet

Sun, 03 Mar 2024 11:30:36 +0000

Ein DaemonSet stellt sicher, dass eine Kopie eines Pods über eine Gruppe von Nodes in einem Cluster ausgeführt wird.

DaemonSets werden verwendet, um System-Daemons wie Protokollsammler und Überwachungsagenten bereitzustellen, die normalerweise auf jedem Node im Cluster ausgeführt werden müssen.

Das Konzept eines DaemonSets ist besonders nützlich für Anwendungen oder Dienste, die auf jedem Node im Cluster vorhanden sein müssen, um bestimmte Aufgaben auszuführen, wie z.B. das Sammeln von Protokollen, das Überwachen von Ressourcen oder das Bereitstellen von Netzwerkdiensten.

Data Plane

Sun, 03 Mar 2024 11:30:36 +0000

Die Data Plane ist die Ebene, die Kapazitäten wie CPU, Speicher, Netzwerk und Speicher bereitstellt, damit die Container ausgeführt und mit einem Netzwerk verbunden werden können.

In einem Kubernetes-Cluster bildet die Data Plane die grundlegende Infrastruktur, die für die Ausführung und den Betrieb von Containern erforderlich ist. Diese Ebene stellt sicher, dass die erforderlichen Ressourcen für die Container bereitgestellt werden, damit sie reibungslos ausgeführt werden können.

CPU und Speicher werden den Containern zugewiesen, um die Rechenleistung und den Speicherbedarf ihrer Anwendungen zu unterstützen. Das Netzwerk ermöglicht die Kommunikation zwischen den Containern sowie den Zugriff auf externe Dienste und Ressourcen. Die Speicherkapazität bietet die Möglichkeit, Daten persistent zu speichern und zu nutzen, auch über den Lebenszyklus der Container hinweg.

Deployment

Sun, 03 Mar 2024 11:30:36 +0000

Ein Deployment ist ein API-Objekt, das eine replizierte Anwendung verwaltet, typischerweise durch das Ausführen von Pods ohne lokalen Zustand.

Ein Deployment definiert die gewünschte Konfiguration für die Anwendung, einschließlich der Anzahl der replizierten Pods, der verwendeten Container-Images und der Bereitstellungsstrategie. Anschließend überwacht das Deployment ständig den Zustand der Pods und stellt sicher, dass die tatsächlichen Pods im Cluster mit der gewünschten Konfiguration übereinstimmen.

Jede Replik wird durch einen Pod repräsentiert, und die Pods werden auf die Node eines Clusters verteilt. Dadurch wird sichergestellt, dass die Anwendung über die gesamte Clusterumgebung hinweg verfügbar ist und gleichmäßig auf die verfügbaren Ressourcen verteilt wird. Wenn ein Pod ausfällt oder gelöscht wird, startet das Deployment automatisch einen neuen Pod, um sicherzustellen, dass die gewünschte Anzahl von Repliken stets vorhanden ist.

Developer

Sun, 03 Mar 2024 11:30:36 +0000

Developer oder auf deutsch “Entwickler” ist ein überladener Begriff, der je nach Kontext auf verschiedene Rollen verweisen kann. Im Bereich von Kubernetes und der Softwareentwicklung kann er verschiedene Aufgaben umfassen, darunter:

Anwendungsentwickler: Eine Person, die für das Schreiben und Entwickeln von Anwendungen verantwortlich ist, die auf Kubernetes-Clustern ausgeführt werden. Sie konzentrieren sich auf das Entwerfen, Codieren, Testen und Bereitstellen von Anwendungen unter Verwendung von Kubernetes-spezifischen Tools und Methoden.

Code-Beitragender: Jemand, der Code, Dokumentation oder seine Zeit zur Verbesserung von Kubernetes oder anderen Open-Source-Projekten beiträgt. Code-Beitragende beteiligen sich am Entwicklungsprozess, indem sie Pull-Requests einreichen, Probleme ansprechen, Feedback geben und aktiv an Diskussionen innerhalb der Community teilnehmen.

Device Plugin

Sun, 03 Mar 2024 11:30:36 +0000

Device Plugins sind Programme, die auf Worker-Nodes ausgeführt werden und Pods Zugriff auf Ressourcen ermöglichen, die eine anbieterspezifische Initialisierung oder Einrichtung erfordern.

Diese Plugins werben Ressourcen beim Kubelet, damit Pods auf Hardwarefunktionen zugreifen können, die mit dem Node zusammenhängen, auf dem der jeweilige Pod ausgeführt wird. Sie können ein Device Plugin entweder als DaemonSet bereitstellen oder die entsprechende Software direkt auf jedem Zielknoten installieren.

Device Plugins sind besonders nützlich, wenn Pods spezielle Hardwarefunktionen oder Geräte benötigen, die auf dem betreffenden Node verfügbar sind. Dies könnte beispielsweise GPUs, FPGAs oder spezielle Netzwerkgeräte umfassen.

Disruption

Sun, 03 Mar 2024 11:30:36 +0000

Disruption oder auf deutsch Störung sind unvermeidliche Ereignisse in einem Kubernetes-Cluster, die dazu führen können, dass Pods außer Betrieb gehen und Auswirkungen auf die betroffenen Arbeitslasten haben. Diese Ereignisse können sowohl freiwillig als auch unfreiwillig auftreten und erfordern eine sorgfältige Planung und Handhabung seitens des Cluster-Betreibers, um die Auswirkungen auf die laufenden Arbeitslasten zu minimieren.

Freiwillige Störungen treten auf, wenn der Cluster-Betreiber gezielt einen Pod zerstört, der zu einer bestimmten Anwendung gehört. Dies kann Teil eines geplanten Wartungsvorgangs sein, bei dem ein Pod vorübergehend außer Betrieb genommen wird, um Updates durchzuführen oder Konfigurationsänderungen vorzunehmen. Obwohl diese Störungen geplant sind, können sie dennoch Auswirkungen auf die Verfügbarkeit der Anwendung haben, insbesondere wenn die Arbeitslast nicht korrekt auf andere Pods im Cluster umgeleitet wird.

Docker

Sun, 03 Mar 2024 11:30:36 +0000

Docker (speziell Docker Engine) ist eine Softwaretechnologie, die Virtualisierung auf Betriebssystemebene bietet, auch bekannt als Container.

Docker nutzt die Ressourcenisolationsfunktionen des Linux-Kernels wie cgroups und Kernel-Namespaces sowie ein unionsfähiges Dateisystem wie OverlayFS und andere, um unabhängige Container innerhalb einer einzigen Linux-Instanz auszuführen. Dadurch wird der Overhead beim Starten und Verwalten von virtuellen Maschinen (VMs) vermieden.

Die Verwendung von Containern ermöglicht es Entwicklern, Anwendungen und ihre Abhängigkeiten in isolierten Umgebungen zu verpacken, die leichtgewichtig, portabel und konsistent sind. Dadurch können Anwendungen problemlos zwischen verschiedenen Umgebungen verschoben und bereitgestellt werden, ohne sich um Kompatibilitätsprobleme oder Abhängigkeiten auf dem Zielsystem sorgen zu müssen.

Dockershim

Sun, 03 Mar 2024 11:30:36 +0000

Der Dockershim war ein Bestandteil von Kubernetes Version 1.23 und früher. Er ermöglichte es dem kubelet, mit dem Docker Engine zu kommunizieren.

Ab Version 1.24 wurde der Dockershim aus Kubernetes entfernt. Diese Änderung wurde vorgenommen, um die Abhängigkeit von Docker als Container-Runtime zu reduzieren und die Interoperabilität mit anderen Container-Runtimes zu verbessern.

Mit dem Wegfall des Dockershims müssen Benutzer, die Docker als Container-Runtime verwenden, auf eine alternative Lösung umsteigen, wie z. B. containerd oder CRI-O. Diese Container-Runtimes bieten ähnliche Funktionen wie Docker und können nahtlos in Kubernetes integriert werden.

Downstream

Sun, 03 Mar 2024 11:30:36 +0000

“Downstream” ist ein Begriff, der je nach Kontext unterschiedliche Bedeutungen haben kann:

Im Kubernetes-Ökosystem bezieht sich “Downstream” auf den Teil der Community, der von der Kern-Kubernetes-Codebasis abhängt. Das können Anwendungen, Tools oder andere Codeprojekte sein, die auf Kubernetes aufbauen oder von dessen Funktionalitäten profitieren. Zum Beispiel können Anwendungen “downstream” von neuen Kubernetes-Funktionen profitieren, um ihre eigene Funktionalität zu verbessern.

In GitHub oder Git bezeichnet “Downstream” normalerweise eine verzweigte Repository-Version, die von der ursprünglichen (Upstream-)Codebasis abgeleitet ist. Das Downstream-Repository enthält möglicherweise spezifische Anpassungen, Erweiterungen oder Experimente im Vergleich zum Upstream-Repository.

Downward API

Sun, 03 Mar 2024 11:30:36 +0000

Die Downward-API ist ein entscheidender Mechanismus von Kubernetes, der es Containern ermöglicht, auf Informationen über sich selbst oder ihren Kontext im Kubernetes-Cluster zuzugreifen, ohne dass die Container selbst direkt mit der Kubernetes-API interagieren müssen. Dies ist besonders nützlich, wenn Container Informationen über ihre Umgebung benötigen, ohne dass diese Informationen fest in den Containercode eingebettet werden müssen, was die Flexibilität und Portabilität der Anwendungen erhöht.

Es gibt zwei Hauptmethoden, um die Downward-API zu nutzen: die Verwendung von Umgebungsvariablen und die Verwendung eines Downward-API-Volumes. Über Umgebungsvariablen können Container direkt auf bestimmte Feldwerte des Pods oder Containers zugreifen, indem sie einfach auf die entsprechenden Umgebungsvariablen zugreifen. Auf der anderen Seite ermöglicht die Verwendung eines Downward-API-Volumes eine flexiblere Möglichkeit, Daten von Feldern des Pods oder Containers abzurufen, indem eine spezielle Datei im Dateisystem des Containers erstellt wird, die die gewünschten Informationen enthält.

Dynamic Volume Provisioning

Sun, 03 Mar 2024 11:30:36 +0000

Die Dynamic Volume Provisioning (dynamische Volumenbereitstellung) ermöglicht es Benutzern, die automatische Erstellung von Speichervolumen anzufordern.

Durch die dynamische Bereitstellung entfällt die Notwendigkeit für Cluster-Administratoren, Speicher im Voraus zu planen und zu reservieren. Stattdessen erfolgt die Speicherbereitstellung automatisch auf Benutzeranforderung hin. Die dynamische Volumenbereitstellung basiert auf einem API-Objekt, der sogenannten “StorageClass” die auf einen Volumen-Plugin verweist, welches ein Volumen bereitstellt, sowie auf einer Reihe von Parametern, die an das Volumen-Plugin übergeben werden.

Benutzer können einfach eine PersistentVolumeClaim (PVC) erstellen und dabei die gewünschte Speicherklasse (StorageClass) angeben. Die StorageClass definiert, wie das Volumen bereitgestellt werden soll, einschließlich des verwendeten Speichertyps, der Zugriffsmodi und anderer Konfigurationsoptionen. Wenn eine PVC erstellt wird, die auf eine bestimmte StorageClass verweist und keine passenden Volumes verfügbar sind, wird automatisch ein neues Volumen entsprechend den Spezifikationen der StorageClass erstellt.

Endpoints

Sun, 03 Mar 2024 11:30:36 +0000

Endpoints verfolgen die IP-Adressen von Pods mit übereinstimmenden Selektoren.

Normalerweise werden Endpoints automatisch für Kubernetes-Services generiert, basierend auf den Selektoren, die in den Service-Spezifikationen definiert sind. Diese Endpoints zeigen auf die Pods, die den Dienst bereitstellen.

In einigen Fällen kann es jedoch erforderlich sein, Endpoints manuell zu konfigurieren, insbesondere wenn der Service keine Selektoren spezifiziert hat oder wenn die Pods außerhalb des Kubernetes-Clusters laufen. In solchen Fällen können Administratoren die Endpoints manuell konfigurieren, um die IP-Adressen der Ziel-Pods anzugeben.

EndpointSlice

Sun, 03 Mar 2024 11:30:36 +0000

EndpointSlice ist eine Möglichkeit, Netzwerkendpunkte zusammen mit Kubernetes-Ressourcen zu gruppieren.

Im Wesentlichen handelt es sich bei EndpointSlice um eine skalierbare und erweiterbare Methode, um Netzwerkendpunkte zu gruppieren. Diese können von kube-proxy verwendet werden, um Netzwerkrouten auf jedem Node im Kubernetes-Cluster einzurichten.

Im Vergleich zu herkömmlichen Endpoints bietet EndpointSlice eine verbesserte Skalierbarkeit und Flexibilität. Insbesondere in Umgebungen mit einer großen Anzahl von Netzwerkendpunkten oder in komplexen Netzwerktopologien kann EndpointSlice eine effiziente Möglichkeit bieten, Endpunkte zu verwalten und die Leistung zu optimieren.

Ephemeral Container

Sun, 03 Mar 2024 11:30:36 +0000

Ephemeral Container sind eine äußerst nützliche Funktion in Kubernetes, die es Administratoren und Entwicklern ermöglicht, temporäre Container innerhalb eines laufenden Pods zu starten, um spezifische Diagnosen oder Anpassungen durchzuführen.

Ephemeral Container bieten eine schnelle und flexible Möglichkeit, Probleme in einem laufenden Pod zu untersuchen, ohne die laufende Anwendung zu beeinträchtigen. Wenn ein Pod beispielsweise unerwartetes Verhalten zeigt oder Schwierigkeiten bei der Ausführung einer bestimmten Aufgabe hat, kann ein Ephemeral Container hinzugefügt werden, um spezifische Diagnosen durchzuführen. Dies könnte das Ausführen von Befehlen zum Überprüfen von Protokollen, das Installieren von Debugging-Tools oder das Ausführen von Diagnosetests umfassen.

etcd

Sun, 03 Mar 2024 11:30:36 +0000

etcd ist ein konsistenter und hochverfügbarer Schlüssel-Wert-Speicher, der als Kubernetes-Back-End-Speicher für alle Clusterdaten verwendet wird. Als zentrales Element in der Kubernetes-Architektur dient etcd zur Speicherung von Konfigurationsinformationen, Zustandsinformationen und Metadaten, die für den Betrieb des Clusters erforderlich sind. Zu diesen Daten gehören beispielsweise Informationen über laufende Pods, Services, Bereitstellungen und Konfigurationseinstellungen.

Die Konsistenz und Hochverfügbarkeit von etcd gewährleistet, dass die Clusterdaten zuverlässig gespeichert und aktualisiert werden können, selbst unter Bedingungen wie Netzwerkpartitionen oder Ausfällen von Rechenzentren. Dies ist entscheidend für die Stabilität und Zuverlässigkeit eines Kubernetes-Clusters.

Event

Sun, 03 Mar 2024 11:30:36 +0000

Events sind Kubernetes-Objekte, die Zustandsänderungen oder bemerkenswerte Ereignisse im System beschreiben.

Sie dienen dazu, wichtige Ereignisse im Kubernetes-Cluster zu protokollieren, wie zum Beispiel das Starten oder Stoppen von Pods, Änderungen an Ressourcen oder Fehlerbedingungen. Jedes Event besteht aus einem Zeitstempel, einer Quelle, einem Grund und einer Meldung, die das Ereignis näher beschreiben.

Es ist wichtig zu beachten, dass Events eine begrenzte Aufbewahrungszeit haben und sich Auslöser und Meldungen im Laufe der Zeit ändern können. Daher sollten Verbraucher von Ereignissen nicht davon ausgehen, dass die Timing-Details eines Ereignisses mit einem bestimmten Grund eine konsistente zugrunde liegende Ursache widerspiegeln oder dass die Ereignisse mit diesem Grund fortbestehen.

Eviction

Sun, 03 Mar 2024 11:30:36 +0000

Die Eviction (deutsch: Vertreibung) ist der Prozess der Beendigung eines oder mehrerer Pods auf Nodes im Kubernetes-Cluster.

Es gibt zwei Arten von Evictions:

Node Pressure Eviction: Diese Art der Vertreibung tritt auf, wenn ein Node aufgrund von Ressourcenknappheit, wie beispielsweise unzureichendem Speicher oder CPU-Auslastung, unter Druck gerät. In solchen Fällen kann Kubernetes entscheiden, bestimmte Pods von diesem Node zu vertreiben, um die Verfügbarkeit und Leistung des Clusters sicherzustellen.

API Initated Eviction: Dies ist der Prozess, bei dem Sie die Eviction-API verwenden, um ein Eviction-Objekt zu erstellen, das die Graceful Pod-Terminierung auslöst. Dies kann durch direkten Aufruf der Eviction-API mithilfe eines Clients des kube-apiservers wie dem kubectl drain-Befehl erfolgen. Wenn ein Eviction-Objekt erstellt wird, beendet der API-Server den Pod.

Extensions

Sun, 03 Mar 2024 11:30:36 +0000

Erweiterungen sind Softwarekomponenten, die Kubernetes erweitern und eng mit ihm integriert sind, um neue Arten von Hardware zu unterstützen.

Viele Cluster-Administratoren verwenden eine gehostete oder verteilte Instanz von Kubernetes. Diese Cluster werden mit vorinstallierten Erweiterungen geliefert. Als Ergebnis werden die meisten Kubernetes-Benutzer keine Erweiterungen installieren müssen, und noch weniger Benutzer werden neue Erweiterungen erstellen müssen.

Diese Erweiterungen können verschiedene Funktionen bereitstellen, darunter zusätzliche Ressourcentypen, benutzerdefinierte Controller, Netzwerkfunktionen oder Speicherlösungen. Sie ermöglichen es Kubernetes, sich nahtlos in verschiedene Hardwareumgebungen zu integrieren und spezifische Anforderungen von Anwendungen oder Workloads zu erfüllen.

Feature Gate

Sun, 03 Mar 2024 11:30:36 +0000

Feature Gates sind eine Reihe von Schlüsseln (undurchsichtige Zeichenfolgen), die Sie verwenden können, um zu steuern, welche Kubernetes-Funktionen in Ihrem Cluster aktiviert sind.

Sie können diese Funktionen mit dem Befehlszeilenflag –feature-gates auf jedem Kubernetes-Komponenten ein- oder ausschalten. Jede Kubernetes-Komponente ermöglicht es Ihnen, eine Reihe von Feature-Gates zu aktivieren oder zu deaktivieren, die für diese Komponente relevant sind. Die Kubernetes-Dokumentation listet alle aktuellen Feature-Gates und ihre Steuerungen auf.

Feature-Gates dienen dazu, experimentelle oder sich in Entwicklung befindende Funktionen in Kubernetes zu aktivieren oder zu deaktivieren. Sie ermöglichen es Administratoren, die Einführung neuer Funktionen zu steuern und sicherzustellen, dass nur stabile Funktionen in Produktionsumgebungen aktiviert sind.

Finalizier

Sun, 03 Mar 2024 11:30:36 +0000

Finalizer oder auch Finalisierer sind namensraumbezogene Schlüssel, die Kubernetes mitteilen, dass es warten soll, bis bestimmte Bedingungen erfüllt sind, bevor es Ressourcen, die zur Löschung markiert wurden, vollständig löscht. Finalisierer benachrichtigen Controller darüber, Ressourcen aufzuräumen, die dem gelöschten Objekt gehören.

Wenn Sie Kubernetes anweisen, ein Objekt zu löschen, für das Finalisierer angegeben sind, markiert die Kubernetes-API das Objekt für die Löschung, indem sie .metadata.deletionTimestamp bevölkert, und gibt einen HTTP-Statuscode 202 (“Akzeptiert”) zurück. Das Zielobjekt bleibt in einem terminierenden Zustand, während das Kontrollflugzeug oder andere Komponenten die Aktionen ausführen, die durch die Finalisierer definiert sind. Nachdem diese Aktionen abgeschlossen sind, entfernt der Controller die entsprechenden Finalisierer aus dem Zielobjekt. Wenn das Feld metadata.finalizers leer ist, betrachtet Kubernetes die Löschung als abgeschlossen und löscht das Objekt.

FlexVolume

Sun, 03 Mar 2024 11:30:36 +0000

FlexVolume ist eine veraltete Schnittstelle zum Erstellen von externen Volume-Plugins. Das Container Storage Interface (CSI) ist eine neuere Schnittstelle, die mehrere Probleme mit FlexVolume angeht.

FlexVolumes ermöglichen es Benutzern, ihre eigenen Treiber zu schreiben und Unterstützung für ihre Volumes in Kubernetes hinzuzufügen. Die Binärdateien und Abhängigkeiten des FlexVolume-Treibers müssen auf den Hostmaschinen installiert sein. Dies erfordert Root-Zugriff. Die Storage SIG empfiehlt die Implementierung eines CSI-Treibers, sofern möglich, da dies die Einschränkungen von FlexVolumes adressiert.

Garbage Collection

Sun, 03 Mar 2024 11:30:36 +0000

Die Garbage Collection - oder auch Müllsammlung- ist ein integraler Bestandteil der Clusterwartung in Kubernetes und bezeichnet die verschiedenen Mechanismen, die verwendet werden, um ungenutzte oder nicht mehr benötigte Ressourcen zu entfernen. Dabei handelt es sich um einen proaktiven Ansatz, um die Effizienz des Clusters zu verbessern und Ressourcen freizugeben.

Kubernetes nutzt die Müllsammlung, um verschiedene Arten von Ressourcen aufzuräumen, darunter:

Ungenutzte Container und Images: Container und zugehörige Images, die nicht mehr verwendet werden oder keine aktiven Pods haben, werden entfernt, um Speicherplatz freizugeben.

Gateway API

Sun, 03 Mar 2024 11:30:36 +0000

Die Gateway-API ist eine Familie von API-Typen zur Modellierung des Service-Netzwerks in Kubernetes. Sie bietet eine Reihe von erweiterbaren, rollenorientierten und protokollbewussten API-Typen für die Modellierung des Service-Netzwerks in Kubernetes.

Die Gateway-API ermöglicht es Benutzern, komplexe Netzwerktopologien in Kubernetes zu definieren und zu verwalten, indem sie verschiedene Rollen und Protokolle berücksichtigt. Sie bietet eine flexible und skalierbare Möglichkeit, Services und deren Kommunikation innerhalb des Clusters sowie mit externen Ressourcen zu konfigurieren.

Durch die Verwendung der Gateway-API können Developer und Administratoren die Netzwerkkonfiguration in Kubernetes effektiv steuern und anpassen, um den Anforderungen ihrer Anwendungen gerecht zu werden. Dies ermöglicht eine präzise Steuerung des Datenverkehrs, die Implementierung von Sicherheitsrichtlinien und die Optimierung der Netzwerkperformance.

Group Version Resource

Sun, 03 Mar 2024 11:30:36 +0000

Group Version Resource, auch als GVR bekannt, ist eine Möglichkeit, eine eindeutige Kubernetes-API-Ressource darzustellen.

Group Version Resources (GVRs) spezifizieren die API-Gruppe, die API-Version und die Ressource (Name für die Objektart, wie sie in der URI erscheint), die mit dem Zugriff auf ein bestimmtes Objekt in Kubernetes verbunden sind. GVRs ermöglichen es Ihnen, verschiedene Kubernetes-Objekte zu definieren und zu unterscheiden, und einen stabilen Zugriff auf Objekte festzulegen, auch wenn sich die APIs ändern.

Helm Chart

Sun, 03 Mar 2024 11:30:36 +0000

Ein Helm-Chart ist ein Paket vorab konfigurierter Kubernetes-Ressourcen, das mit dem Helm-Tool verwaltet werden kann.

Charts bieten eine reproduzierbare Möglichkeit zur Erstellung und Weitergabe von Kubernetes-Anwendungen. Ein einzelnes Chart kann verwendet werden, um etwas Einfaches bereitzustellen, wie zum Beispiel einen Memcached-Pod, oder etwas Komplexes, wie einen vollständigen Webanwendungs-Stack mit HTTP-Servern, Datenbanken, Caches und so weiter.

Link zum offiziellen Glossar

Horizontal Pod Autoscaler

Sun, 03 Mar 2024 11:30:36 +0000

Der Horizontal Pod Autoscaler (HPA) ist ein leistungsstarkes Werkzeug in Kubernetes, das automatisch die Anzahl der Pod-Replikationen basierend auf der CPU-Auslastung oder benutzerdefinierten Metrikzielen skaliert. Dies ermöglicht es Kubernetes-Benutzern, ihre Anwendungen dynamisch an sich ändernde Arbeitslasten anzupassen, indem sie Ressourcen effizient nutzen.

Der HPA ist eine API-Ressource, die in der Regel mit anderen Kubernetes-Ressourcen wie ReplicationControllers, Deployments oder ReplicaSets verwendet wird. Es überwacht kontinuierlich die Ressourcenauslastung der Pods und passt die Anzahl der Replikationen automatisch an, um die gewünschte Ziel-CPU-Auslastung oder benutzerdefinierte Metriken zu erreichen.

HostAliases

Sun, 03 Mar 2024 11:30:36 +0000

Die HostAliases sind eine Zuordnung zwischen der IP-Adresse und dem Hostnamen, die in die Hostdatei eines Pods eingefügt werden.

HostAliases ist eine optionale Liste von Hostnamen und IP-Adressen, die in die Hostdatei des Pods eingefügt werden, wenn sie angegeben sind. Dies ist nur für nicht-HostNetzwerk-Pods gültig.

Die Verwendung von HostAliases ermöglicht es Benutzern, benutzerdefinierte Zuordnungen zwischen IP-Adressen und Hostnamen festzulegen, die in einem Pod verwendet werden sollen. Dies kann nützlich sein, um benutzerdefinierte Namensauflösungen für Dienste oder Ressourcen in einem Kubernetes-Cluster bereitzustellen.

Image

Sun, 03 Mar 2024 11:30:36 +0000

Ein Image ist eine gespeicherte Instanz eines Containers, die eine Reihe von Software enthält, die benötigt wird, um eine Anwendung auszuführen.

Ein Image ist eine Möglichkeit, Software zu verpacken, die es ermöglicht, sie in einem Container-Repository zu speichern, auf ein lokales System herunterzuladen und als Anwendung auszuführen. Metadaten sind in dem Image enthalten, die angeben können, welches ausführbare Programm ausgeführt werden soll, wer es erstellt hat, und andere Informationen.

Images sind das Grundelement in der Containerisierungstechnologie und bilden die Basis für die Bereitstellung und Ausführung von Anwendungen in Containerumgebungen wie Docker oder Kubernetes. Sie sind portabel, da sie alle notwendigen Abhängigkeiten und Konfigurationen enthalten, um eine Anwendung über verschiedene Umgebungen hinweg konsistent auszuführen.

Ingress

Sun, 03 Mar 2024 11:30:36 +0000

Ein Ingress ist ein API-Objekt, das den externen Zugriff auf die Dienste in einem Cluster verwaltet, typischerweise über HTTP.

Ingress ermöglicht es, den externen Zugriff auf Dienste in einem Kubernetes-Cluster zu verwalten und zu steuern. Dabei können verschiedene Funktionen wie Lastenausgleich, SSL-Terminierung und namensbasiertes virtuelles Hosting bereitgestellt werden.

Durch die Verwendung von Ingress können Kubernetes-Benutzer den eingehenden HTTP-Traffic auf verschiedene Dienste in ihrem Cluster verteilen und steuern, wodurch sie eine flexiblere und skalierbare Infrastruktur für ihre Anwendungen schaffen können.

Init Container

Sun, 03 Mar 2024 11:30:36 +0000

Ein Init-Container ist ein wichtiger Bestandteil von Kubernetes-Pods, der dazu dient, bestimmte Vorbedingungen zu erfüllen, bevor die Hauptanwendungscontainer gestartet werden. Init-Container sind spezielle Container, die vor dem Start der eigentlichen Anwendungscontainer ausgeführt werden müssen. Sie dienen dazu, verschiedene Aufgaben auszuführen, wie beispielsweise das Laden von Konfigurationsdateien, das Einrichten von Umgebungsvariablen oder das Warten auf das Vorhandensein bestimmter Ressourcen.

Init-Container werden in einer streng sequenziellen Reihenfolge ausgeführt, was bedeutet, dass jeder Init-Container vollständig abgeschlossen sein muss, bevor der nächste gestartet wird. Dies gewährleistet, dass alle notwendigen Vorbereitungen abgeschlossen sind, bevor die eigentliche Anwendung gestartet wird.

Istio

Sun, 03 Mar 2024 11:30:36 +0000

Istio ist eine offene Plattform (nicht spezifisch für Kubernetes), die einen einheitlichen Ansatz für die Integration von Microservices, die Verwaltung des Datenverkehrsflusses, die Durchsetzung von Richtlinien und die Aggregation von Telemetriedaten bietet.

Die Integration von Istio erfordert keine Änderung des Anwendungs-Codes. Es handelt sich um eine Infrastrukturschicht zwischen einem Dienst und dem Netzwerk, die in Kombination mit Dienstbereitstellungen häufig als Service-Mesh bezeichnet wird. Die Steuerungsebene von Istio abstrahiert die zugrunde liegende Cluster-Management-Plattform, die Kubernetes, Mesosphere usw. sein kann.

Job

Sun, 03 Mar 2024 11:30:36 +0000

Ein Job in Kubernetes ist eine endliche oder Batch-Aufgabe, die bis zur Fertigstellung ausgeführt wird. Es erstellt ein oder mehrere Pod-Objekte und stellt sicher, dass eine bestimmte Anzahl von ihnen erfolgreich beendet wird. Während die Pods erfolgreich abgeschlossen werden, verfolgt der Job die erfolgreichen Abschlüsse.

Jobs sind nützlich für Aufgaben, die nur einmalig ausgeführt werden müssen oder für Batch-Verarbeitungsaufgaben, die eine bestimmte Anzahl von Instanzen benötigen, um erfolgreich abgeschlossen zu werden. Sie stellen sicher, dass die Aufgabe ordnungsgemäß ausgeführt wird, indem sie die Anzahl der Pods im Auge behalten und den Fortschritt überwachen.

JSON Web Token (JWT)

Sun, 03 Mar 2024 11:30:36 +0000

JSON Web Token (JWT) ist ein Mittel zur Darstellung von Ansprüchen, die zwischen zwei Parteien übertragen werden sollen. JWTs können digital signiert und verschlüsselt werden. Kubernetes verwendet JWTs als Authentifizierungstoken, um die Identität von Entitäten zu überprüfen, die Aktionen in einem Cluster durchführen möchten.

Ein JWT besteht aus drei Teilen: dem Header, den Payload und der Signatur. Der Header enthält Metadaten über den Token wie den Typ und das verwendete Signaturalgorithmus. Der Payload enthält die Ansprüche oder Informationen, die übertragen werden sollen. Die Signatur wird verwendet, um die Integrität des Tokens zu gewährleisten und sicherzustellen, dass er nicht manipuliert wurde.

kOps

Sun, 03 Mar 2024 11:30:36 +0000

kOps (Kubernetes Operations) ist ein automatisiertes Bereitstellungssystem, das nicht nur dabei hilft, produktionsreife, hochverfügbare Kubernetes-Cluster zu erstellen, zu zerstören, zu aktualisieren und zu warten, sondern auch die erforderliche Cloud-Infrastruktur bereitstellt. Aktuell wird AWS (Amazon Web Services) offiziell unterstützt, während DigitalOcean, GCE und OpenStack in der Beta-Unterstützung sind und Azure sich noch im Alpha-Status befindet.

Die wichtigsten Merkmale von kOps sind:

Vollautomatische Installation: kOps automatisiert den gesamten Bereitstellungsprozess von Kubernetes-Clustern, was die Einrichtung und Wartung erleichtert.

kube proxy

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-proxy ist ein Netzwerkproxy, der auf jedem Node in Ihrem Cluster läuft und einen Teil des Kubernetes-Servicekonzepts implementiert. Er verwaltet Netzwerkregeln auf den Nodes, die die Netzwerkkommunikation zu Ihren Pods aus Netzwerksitzungen innerhalb oder außerhalb Ihres Clusters ermöglichen.

Der kube-proxy nutzt die Paketfilterungsebene des Betriebssystems, wenn diese verfügbar ist. Andernfalls leitet der kube-proxy den Datenverkehr selbst weiter. Dies ermöglicht es, dass Netzwerkanforderungen an Services und Pods innerhalb des Clusters richtig geroutet werden, unabhängig davon, auf welchem Node sie sich befinden. Der kube-proxy spielt somit eine wichtige Rolle bei der Gewährleistung der Konnektivität innerhalb des Kubernetes-Clusters.

kube scheduler

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-scheduler ist eine wichtige Steuerungsebene innerhalb eines Kubernetes-Clusters, die für die effiziente Zuweisung von Pods auf die verfügbaren Node verantwortlich ist. Diese Komponente überwacht kontinuierlich die neu erstellten Pods, die noch keinen zugewiesenen Node haben, und entscheidet anhand verschiedener Faktoren, auf welchem Node sie ausgeführt werden sollen.

Bei der Entscheidung über die Platzierung von Pods berücksichtigt der kube-scheduler eine Vielzahl von Aspekten, um eine optimale Verteilung im Cluster zu gewährleisten. Dazu gehören die individuellen und kollektiven Ressourcenanforderungen der Pods, etwaiger Hardware- oder Softwarebeschränkungen, Richtlinienkonformität, Affinitäts- und Anti-Affinitätsregeln sowie Datenlokalität. Darüber hinaus berücksichtigt der Scheduler auch Faktoren wie Interferenzen zwischen Arbeitslasten und Deadlines, um sicherzustellen, dass Pods effizient und zuverlässig ausgeführt werden.

kube-controller-manager

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-controller-manager ist eine Komponente der Steuerebene, die Controller-Prozesse ausführt. Logisch gesehen ist jeder Controller ein separater Prozess, aber um die Komplexität zu reduzieren, werden sie alle in eine einzige Binärdatei kompiliert und in einem einzigen Prozess ausgeführt.

Die Controller sind für die Überwachung des Zustands des Kubernetes-Clusters verantwortlich und nehmen entsprechende Maßnahmen, um sicherzustellen, dass der aktuelle Zustand mit dem gewünschten Zustand übereinstimmt. Es gibt verschiedene Controller, die unterschiedliche Aufgaben erfüllen, wie z. B. den Replication Controller, den Node Controller und den Endpoints Controller.

Kubeadm

Sun, 03 Mar 2024 11:30:36 +0000

Kubeadm ist ein leistungsstarkes Tool zur schnellen Installation von Kubernetes und zur Einrichtung eines sicheren Clusters. Es wurde entwickelt, um den Prozess der Kubernetes-Bereitstellung zu vereinfachen und sicherzustellen, dass die Clusterkonfiguration gemäß bewährten Methoden erfolgt.

Mit kubeadm können Sie sowohl die Steuerungsebene (control plane) als auch die Worker-Node-Komponenten installieren und konfigurieren. Dabei übernimmt kubeadm die Aufgabe, alle notwendigen Schritte zur Initialisierung des Clusters durchzuführen, darunter:

Einrichten der Kubernetes-Steuerungsebene: Kubeadm erstellt die erforderlichen Kubernetes-Steuerungsebene-Komponenten wie den API-Server, den Scheduler und den Controller-Manager. Diese Komponenten sind für die Verwaltung und Steuerung des Clusters verantwortlich.

Kubectl

Sun, 03 Mar 2024 11:30:36 +0000

kubectl, auch bekannt als Kubernetes Control, ist ein leistungsstarkes Befehlszeilenwerkzeug, das für die Interaktion mit der Steuerungsebene eines Kubernetes-Clusters über die Kubernetes-API entwickelt wurde. Mit kubectl können Entwickler und Administratoren verschiedene Aufgaben zur Verwaltung von Kubernetes-Ressourcen durchführen.

Hier sind einige der Hauptfunktionen von kubectl:

Kubernetes-Ressourcen verwalten: Mit kubectl können Sie Kubernetes-Ressourcen wie Pods, Services, Deployments, ReplicaSets, ConfigMaps und mehr erstellen, anzeigen, aktualisieren und löschen. Dies ermöglicht die Verwaltung der gesamten Clusterkonfiguration über die Befehlszeile.
Clusterstatus überprüfen: kubectl bietet verschiedene Befehle zum Überprüfen des Status und der Gesundheit des Kubernetes-Clusters. Sie können beispielsweise den Status von Pods, Services, Nodes und anderen Ressourcen abrufen, um sicherzustellen, dass der Cluster ordnungsgemäß funktioniert.

Kubelet

Sun, 03 Mar 2024 11:30:36 +0000

Der Kubelet ist ein Agent, der auf jedem Node im Kubernetes-Cluster läuft. Seine Hauptaufgabe besteht darin, sicherzustellen, dass die in einem Pod definierten Container auf dem jeweiligen Node ordnungsgemäß ausgeführt werden.

Hier sind einige der wichtigsten Funktionen des Kubelets:

Pod-Verwaltung: Der Kubelet erhält Pod-Spezifikationen von der Kubernetes-API und stellt sicher, dass die darin definierten Container gemäß den Spezifikationen gestartet, aktualisiert und beendet werden.

Ressourcenüberwachung: Das Kubelet überwacht die Ressourcennutzung der Container und greift bei Bedarf ein, um sicherzustellen, dass die Container innerhalb der definierten Grenzen für CPU, Arbeitsspeicher und andere Ressourcen arbeiten.

Kubernetes API

Sun, 03 Mar 2024 11:30:36 +0000

Die Kubernetes-API ist die Anwendung, die Kubernetes-Funktionalitäten über eine RESTful-Schnittstelle bereitstellt und den Zustand des Clusters speichert.

Hier sind einige wichtige Merkmale der Kubernetes-API:

RESTful-Schnittstelle: Die Kubernetes-API stellt eine RESTful-Schnittstelle bereit, über die Benutzer mit dem Cluster interagieren können. Diese Schnittstelle ermöglicht das Lesen, Erstellen, Aktualisieren und Löschen von Ressourcen im Cluster.
Zustandsverwaltung: Die Kubernetes-API speichert den Zustand des Clusters und verwaltet die Lebenszyklen der verschiedenen Ressourcen, die im Cluster ausgeführt werden. Dies umfasst Pod-Spezifikationen, Service, Replicaset, Deployment und vieles mehr.

Label

Sun, 03 Mar 2024 11:30:36 +0000

Labels sind Schlüssel/Wert-Paare, die Objekten wie Pods zugeordnet werden, um sie mit identifizierenden Attributen zu versehen, die für Benutzer bedeutsam und relevant sind. Sie werden verwendet, um Objekte zu organisieren und Teilmengen von Objekten auszuwählen. Labels sind eine wichtige Funktion von Kubernetes und bieten mehrere Vorteile:

Identifikation und Organisation: Durch das Anbringen von Labels können Benutzer Kubernetes-Objekte identifizieren und organisieren. Sie können Objekte mit ähnlichen Funktionen, Umgebungen oder anderen Kriterien markieren, um sie später leichter zu finden oder zu gruppieren.

LimitRange

Sun, 03 Mar 2024 11:30:36 +0000

LimitRange ist ein Kubernetes-Objekt, das Einschränkungen bereitstellt, um den Ressourcenverbrauch pro Container oder Pod in einem Namespace zu begrenzen.

Hier sind einige wichtige Punkte zu LimitRange:

Begrenzung der Objektmenge: LimitRange ermöglicht es Administratoren, die Anzahl der erstellbaren Objekte pro Typ zu begrenzen. Dies kann nützlich sein, um Ressourcenverbrauch und Clusterressourcen zu kontrollieren.

Begrenzung der Ressourcen: Neben der Begrenzung der Anzahl von Objekten kann LimitRange auch den Ressourcenverbrauch pro Container oder Pod einschränken. Dies umfasst CPU, Speicher und andere Ressourcen, die von Containern oder Pods angefordert oder verbraucht werden können.

Logging

Sun, 03 Mar 2024 11:30:36 +0000

Logs sind eine Liste von Ereignissen, die von einem Cluster oder einer Anwendung protokolliert werden.

Hier sind einige wichtige Punkte zu Logging in Kubernetes:

Protokollierung von Ereignissen: Logs erfassen Ereignisse, die in einem Cluster oder einer Anwendung auftreten. Dies kann Fehlermeldungen, Warnungen, Informationsmeldungen und andere relevante Ereignisse umfassen.
Debugging und Fehlerbehebung: Logs sind besonders nützlich für das Debugging und die Fehlerbehebung von Problemen in einer Anwendung oder im Cluster. Sie ermöglichen es Entwicklern und Administratoren, den Ablauf von Ereignissen zu verfolgen und potenzielle Probleme zu identifizieren.

Managed Service

Sun, 03 Mar 2024 11:30:36 +0000

Ein Managed Service ist ein Softwareangebot, das von einem Drittanbieter verwaltet wird. Im Gegensatz zu selbstverwalteten Lösungen übernimmt der Anbieter die Verantwortung für die Bereitstellung, Wartung und Skalierung des Dienstes, während der Benutzer sich auf die Verwendung und Integration konzentrieren kann.

Hier sind einige wichtige Merkmale von Managed Services:

Bereitstellung und Wartung: Der Anbieter übernimmt die Bereitstellung und Wartung des Dienstes, einschließlich der Einrichtung von Servern, der Installation von Software, der Konfiguration von Netzwerken und der Durchführung von Softwareupdates und Patches.

Manifest

Sun, 03 Mar 2024 11:30:36 +0000

Ein Manifest ist eine Spezifikation eines Kubernetes-API-Objekts im JSON- oder YAML-Format. Es beschreibt den gewünschten Zustand eines Objekts, den Kubernetes beibehalten soll, wenn das Manifest angewendet wird. Jede Konfigurationsdatei kann mehrere Manifeste enthalten.

Manifeste werden verwendet, um Kubernetes mitzuteilen, welche Ressourcen erstellt, aktualisiert oder gelöscht werden sollen. Sie enthalten Details wie den Objekttyp, Metadaten wie den Namen und die Labels des Objekts, sowie spezifische Konfigurationsparameter, die den gewünschten Zustand des Objekts definieren.

Master

Sun, 03 Mar 2024 11:30:36 +0000

“Master” ist ein veralteter Begriff, der früher als Synonym für Nodes verwendet wurde, auf denen die Steuerungsebene (Control Plane) von Kubernetes ausgeführt wird. Die Steuerungsebene umfasst Komponenten wie den API-Server, den Scheduler und den Controller-Manager, die für die Verwaltung und Steuerung des Kubernetes-Clusters verantwortlich sind.

Obwohl der Begriff “Master” immer noch gelegentlich verwendet wird, um die Nodes zu bezeichnen, die die Steuerungsebene hosten, ist er in der Kubernetes-Community aufgrund seiner impliziten Konnotationen als nicht mehr zeitgemäß angesehen. Stattdessen wird empfohlen, Begriffe wie “Control Plane” oder “Controller Nodes” zu verwenden, um die Rolle dieser Nodes im Cluster genauer zu beschreiben.

Member

Sun, 03 Mar 2024 11:30:36 +0000

Ein Mitglied in der Kubernetes-Community ist eine Person, die aktiv an der Weiterentwicklung und Verbesserung des Kubernetes-Projekts beteiligt ist. Diese Beteiligung kann sich in verschiedenen Formen manifestieren, darunter das Einreichen von Fehlerberichten (Issues), das Beheben von Fehlern, das Einreichen von Pull Requests (PRs), das Teilnehmen an Diskussionen in Foren oder in speziellen Interessengruppen (SIGs) sowie das Organisieren oder Unterstützen von Community-Veranstaltungen.

Mitglieder genießen gewisse Privilegien und Verantwortlichkeiten innerhalb der Community. Sie haben die Möglichkeit, Issues und PRs zugewiesen zu bekommen, was bedeutet, dass sie bestimmte Probleme lösen oder Änderungen am Quellcode vornehmen können. Mitglieder können auch aktive Teilnehmer in den SIGs sein, wo sie an Diskussionen teilnehmen und zur Entwicklung von Kubernetes beitragen können.

Minikube

Sun, 03 Mar 2024 11:30:36 +0000

Minikube ist ein nützliches Tool, das es Entwicklern ermöglicht, Kubernetes lokal auszuführen. Es ermöglicht das Einrichten und Betreiben einer einfachen Kubernetes-Clusterumgebung auf einem einzelnen Rechner, was ideal ist, um Kubernetes zu lernen, Anwendungen lokal zu entwickeln und zu testen sowie verschiedene Kubernetes-Funktionen zu erkunden, ohne auf eine vollständige Cloud-basierte Bereitstellung angewiesen zu sein.

Durch die Verwendung von Minikube kann ein Entwickler schnell und einfach einen Kubernetes-Cluster auf seinem eigenen Computer erstellen, ohne dass ein umfangreiches Setup oder spezielle Hardware erforderlich ist. Minikube verwendet dabei eine virtuelle Maschine (VM), um den Kubernetes-Cluster innerhalb einer isolierten Umgebung auszuführen. Dadurch wird sichergestellt, dass die lokale Entwicklungsumgebung nicht durch die Kubernetes-Ressourcen beeinträchtigt wird.

Mirror Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Mirror Pod ist ein Objekt, das vom Kubelet verwendet wird, um einen statischen Pod zu repräsentieren. Wenn das Kubelet einen statischen Pod in seiner Konfiguration findet, versucht es automatisch, ein Pod-Objekt auf dem Kubernetes-API-Server dafür zu erstellen. Dies bedeutet, dass der Pod auf dem API-Server sichtbar ist, aber nicht von dort aus gesteuert werden kann.

Mit anderen Worten, ein Mirror Pod ist eine Spiegelung des statischen Pods auf dem Kubernetes-API-Server, die vom Kubelet verwaltet wird. Obwohl der Mirror Pod auf dem API-Server existiert, kann er nicht von dort aus gesteuert oder verwaltet werden. Beispielsweise hat das Löschen eines Mirror Pods keine Auswirkungen auf das Verhalten des kubelet-Dienstes, der den Pod ausführt. Der Mirror Pod wird weiterhin ausgeführt, solange er in der Konfiguration des kubelets vorhanden ist.

Mixed Version Proxy (MVP)

Sun, 03 Mar 2024 11:30:36 +0000

Der Mixed Version Proxy, auch als MVP bekannt, ist eine Funktion in Kubernetes, die es einem kube-apiserver ermöglicht, eine Ressourcenanfrage an einen anderen Peer-API-Server weiterzuleiten. Dies ist besonders nützlich in Clustern, in denen mehrere API-Server mit unterschiedlichen Kubernetes-Versionen ausgeführt werden.

Die Notwendigkeit für den MVP entsteht, wenn ein Kubernetes-Cluster aufgrund von Upgrades oder verteilten Bereitstellungen API-Server unterschiedlicher Versionen enthält. In solchen Fällen können bestimmte Ressourcen möglicherweise nicht von allen API-Servern ordnungsgemäß bedient werden. Der MVP ermöglicht es einem API-Server, Ressourcenanfragen an den richtigen API-Server mit der passenden Version weiterzuleiten, um sicherzustellen, dass die Anfragen ordnungsgemäß verarbeitet werden.

Name

Sun, 03 Mar 2024 11:30:36 +0000

Ein “Name” ist eine clientbereitgestellte Zeichenfolge, die sich auf ein Objekt in einer Ressourcen-URL bezieht, wie z.B. “/api/v1/pods/some-name”. In Kubernetes kann jedes Objekt einen eindeutigen Namen haben, der es identifiziert. Ein bestimmter Name kann jedoch nur für ein Objekt einer bestimmten Art zur gleichen Zeit existieren. Wenn ein Objekt gelöscht wird, kann ein neues Objekt mit demselben Namen erstellt werden.

Der Name eines Objekts ist ein wichtiger Identifikator in Kubernetes, da er verwendet wird, um auf das Objekt zuzugreifen, es zu identifizieren und mit ihm zu interagieren. Beispielsweise können Ressourcen wie Pods, Services, Deployments usw. einen Namen haben, der es den Benutzern ermöglicht, sie eindeutig zu identifizieren und auf sie zuzugreifen. Die Einzigartigkeit des Namens gewährleistet, dass keine Konflikte zwischen verschiedenen Objekten entstehen, und erleichtert die Verwaltung und den Betrieb des Kubernetes-Clusters.

Namespace

Sun, 03 Mar 2024 11:30:36 +0000

Ein Namespace ist eine Abstraktion, die von Kubernetes verwendet wird, um die Isolierung von Gruppen von Ressourcen innerhalb eines einzelnen Clusters zu unterstützen. Mit Namespaces können Objekte in einem Cluster organisiert werden, und sie bieten eine Möglichkeit, die Ressourcen des Clusters zu unterteilen. Die Namen von Ressourcen müssen innerhalb eines Namespaces eindeutig sein, aber nicht über Namespaces hinweg. Die auf Namespaces basierende Abgrenzung gilt nur für Namespaced-Objekte (z. B. Deployments, Services usw.) und nicht für Cluster-weite Objekte (z. B. StorageClass, Nodes, PersistentVolumes usw.). Durch die Verwendung von Namespaces können verschiedene Teams oder Anwendungen ihre Ressourcen in einem gemeinsamen Kubernetes-Cluster verwalten, ohne dass sie sich gegenseitig beeinträchtigen. Dies fördert die Organisation, das Management und die Skalierbarkeit von Kubernetes-Clustern, da es eine logische Trennung der Ressourcen ermöglicht. Jeder Namespace fungiert als isolierte Umgebung, in der Ressourcen definiert und verwaltet werden können, und ermöglicht es Administratoren, Berechtigungen und Zugriffssteuerungen auf Namespace-Ebene festzulegen.

Network Policy

Sun, 03 Mar 2024 11:30:36 +0000

Network Policy sind Spezifikationen darüber, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren dürfen. Sie ermöglichen es Ihnen, deklarativ zu konfigurieren, welche Pods miteinander kommunizieren dürfen, welche Namespaces miteinander kommunizieren dürfen, und spezifisch welche Portnummern durch jede Richtlinie erzwungen werden sollen. Network Policies verwenden Labels, um Pods auszuwählen, und definieren Regeln, die festlegen, welcher Datenverkehr zu den ausgewählten Pods zugelassen ist.

Network Policies werden durch einen unterstützten Netzwerk-Plugin bereitgestellt, das von einem Netzwerkanbieter bereitgestellt wird. Es ist wichtig zu beachten, dass das Erstellen einer Netzwerkressource ohne einen Controller, der sie implementiert, keine Auswirkungen hat. Die Netzwerkrichtlinie wird vom Netzwerkplugin umgesetzt und kann dazu beitragen, die Sicherheit in einem Kubernetes-Cluster zu verbessern, indem sie den Datenverkehr zwischen verschiedenen Pods und Namespaces steuert und einschränkt. Sie ermöglichen eine granulare Kontrolle darüber, welche Pods miteinander kommunizieren dürfen, basierend auf definierten Regeln und Richtlinien.

Node

Sun, 03 Mar 2024 11:30:36 +0000

Ein Node ist eine Arbeitsmaschine in Kubernetes, die für die Ausführung von Pods zuständig ist. Ein Node kann entweder eine virtuelle Maschine (VM) oder eine physische Maschine sein, abhängig von der Art des Clusters. Er verfügt über lokale Dienste oder Daemons, die erforderlich sind, um Pods auszuführen, und wird von der Control Plane verwaltet. Zu den Daemons auf einem Node gehören kubelet, kube-proxy und ein Containerlaufzeitdienst, der das Container Runtime Interface (CRI) implementiert, wie z. B. Docker.

Node-pressure-eviction

Sun, 03 Mar 2024 11:30:36 +0000

Node-pressure-eviction, auch als Kubelet-Eviction bekannt, ist ein entscheidender Prozess im Kubernetes-Clustermanagement. Wenn die Ressourcen wie CPU, Speicher, Festplattenspeicherplatz oder Dateisysteminodes auf einem Nodeknapp werden, greift das Kubelet ein und entscheidet proaktiv, welche Pods auf diesem Node beendet werden sollen, um Ressourcen freizugeben.

Der Node-pressure-eviction-Prozess wird durch das Kubelet überwacht, das ständig die Ressourcenauslastung auf jedem Node im Cluster überprüft. Sobald das Kubelet feststellt, dass ein Node überlastet ist und dringend Ressourcen benötigt werden, startet es den Eviction-Prozess. Dabei werden bestimmte Pods auf dem Node ausgewählt und beendet, um Platz für neue Pods und die Freigabe von Ressourcen zu schaffen.

Object

Sun, 03 Mar 2024 11:30:36 +0000

Ein Objekt im Kontext von Kubernetes ist eine Entität, die verwendet wird, um den Zustand und das Verhalten eines Clusters zu definieren und zu repräsentieren. Die Kubernetes-API nutzt diese Objekte, um die gewünschten Zustände der verschiedenen Ressourcen im Cluster zu beschreiben. Im Wesentlichen ist ein Kubernetes-Objekt eine Art “Intentionserklärung”, die angibt, wie ein Teil der Cluster-Workload aussehen soll.

Diese Objekte können verschiedene Arten von Ressourcen darstellen, darunter Pods, Services, Deployment, Konfigurationskarten, Secrets und vieles mehr. Jedes Objekt hat eine eindeutige Identität und spezifische Eigenschaften, die seinen Zweck und seine Funktionalität im Cluster definieren.

Operation Pattern

Sun, 03 Mar 2024 11:30:36 +0000

Das Operator-Pattern ist ein Systemdesign, das einen Controller mit einer oder mehreren benutzerdefinierten Ressourcen verknüpft. Es ermöglicht die Erweiterung von Kubernetes, indem zusätzliche Controller zum Cluster hinzugefügt werden, die über die eingebauten Controller von Kubernetes hinausgehen.

Im Rahmen des Operator-Pattern fungiert eine laufende Anwendung als Controller und hat API-Zugriff, um Aufgaben gegen eine benutzerdefinierte Ressource im Steuerungsebene auszuführen. Diese benutzerdefinierte Ressource ist speziell für die Bedürfnisse der Anwendung definiert und kann beispielsweise Zustände und Konfigurationen repräsentieren.

Persistent Volume

Sun, 03 Mar 2024 11:30:36 +0000

Ein Persistent Volume (PV) ist ein API-Objekt, das einen Speicherbereich im Cluster repräsentiert. Es steht als allgemeine, anpassbare Ressource zur Verfügung, die über den Lebenszyklus eines einzelnen Pods hinaus bestehen bleibt.

PersistentVolumes (PVs) bieten eine API, die Details darüber abstrahiert, wie Speicher bereitgestellt wird, im Gegensatz dazu, wie er verwendet wird. PVs werden direkt in Szenarien eingesetzt, in denen Speicher im Voraus erstellt werden kann (statische Bereitstellung). Für Szenarien, die eine bedarfsgesteuerte Speicherbereitstellung erfordern (dynamische Bereitstellung), werden stattdessen Persistent Volume Claims (PVCs) verwendet.

Persistent Volume Claim

Sun, 03 Mar 2024 11:30:36 +0000

Ein Persistent Volume Claim (PVC) beansprucht Speicherressourcen, die in einem Persisten Volume definiert sind, damit sie als Volume in einem Container bereitgestellt werden können.

Ein PVC gibt an, wie viel Speicherplatz benötigt wird, wie auf den Speicher zugegriffen wird (nur lesen, lesen und schreiben und/oder exklusiv) und wie er zurückgefordert wird (behalten, wiederverwenden oder löschen). Einzelheiten zum Speicher selbst werden im Persisten tVolume-Objekt beschrieben.

Durch die Verwendung von PVCs können Entwickler oder Benutzer innerhalb des Kubernetes-Clusters auf Speicher zugreifen, ohne sich um die zugrunde liegende Speicherinfrastruktur kümmern zu müssen. PVCs erleichtern die Bereitstellung von Speicher für Anwendungen und ermöglichen eine flexible und bedarfsgerechte Nutzung von Speicherressourcen in Kubernetes.

Platform Developer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Plattformentwickler ist eine Person, die die Kubernetes-Plattform an die Anforderungen ihres Projekts anpasst.

Ein Plattformentwickler kann beispielsweise benutzerdefinierte Ressourcen verwenden oder die Kubernetes-API mit der Aggregationsfunktion erweitern, um die Funktionalität ihrer Instanz von Kubernetes speziell für ihre Anwendung zu erweitern. Einige Plattformentwickler sind auch Beitragende und entwickeln Erweiterungen, die der Kubernetes-Community zur Verfügung gestellt werden. Andere entwickeln proprietäre kommerzielle oder standortspezifische Erweiterungen.

Link zum offiziellen Glossar

Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Pod ist die kleinste und grundlegendste Einheit in Kubernetes, die eine Gruppe von miteinander verbundenen Containern umfasst und als eine atomare Einheit behandelt wird. Diese Container teilen sich denselben Netzwerk- und Speicherbereich und werden gemeinsam auf einem Node ausgeführt. Ein Pod kann einen oder mehrere Container enthalten, die eng miteinander zusammenarbeiten, um eine bestimmte Anwendung oder eine Gruppe von Aufgaben zu erfüllen.

Die Verwendung von Pods bietet mehrere Vorteile. Zum einen ermöglichen sie die einfache Gruppierung von Containern, die zusammenarbeiten müssen, um eine Anwendung bereitzustellen. Dies fördert eine modulare und skalierbare Architektur, da neue Funktionen oder Dienste durch das Hinzufügen zusätzlicher Container zu einem Pod implementiert werden können. Darüber hinaus ermöglicht Kubernetes die horizontale Skalierung von Pods, indem mehrere Instanzen desselben Pods erstellt werden, um die Last auf dem Cluster zu verteilen.

Pod Disruption

Sun, 03 Mar 2024 11:30:36 +0000

Pod-Unterbrechung ist der Prozess, bei dem Pods auf Nodes entweder freiwillig oder unfreiwillig beendet werden.

Freiwillige Unterbrechungen werden absichtlich von Anwendungsbesitzern oder Cluster-Administratoren gestartet. Unfreiwillige Unterbrechungen sind unbeabsichtigt und können durch unvermeidbare Probleme wie Nodes, die keine Ressourcen mehr haben, oder durch versehentliche Löschungen ausgelöst werden.

Link zum offiziellen Glossar

Pod Disruption Budget (PDB)

Sun, 03 Mar 2024 11:30:36 +0000

Ein Pod Disruption Budget, auch bekannt als PDB, ermöglicht es einem Anwendungsbesitzer, ein Objekt für eine replizierte Anwendung zu erstellen. Dieses Objekt stellt sicher, dass eine bestimmte Anzahl oder Prozentsatz von Pods mit einem bestimmten Label zu keinem Zeitpunkt freiwillig beendet werden.

Der Zweck eines PDB besteht darin, sicherzustellen, dass eine Anwendung während Wartungsarbeiten oder anderen geplanten Unterbrechungen weiterhin eine Mindestanzahl von Pods aufrechterhalten kann, um die Verfügbarkeit zu gewährleisten. Dies ist besonders wichtig für replizierte Anwendungen, bei denen das Ausfallen eines Pods durch eine geplante Unterbrechung zu einer Beeinträchtigung der Dienstleistung führen kann.

Pod Lifecycle

Sun, 03 Mar 2024 11:30:36 +0000

Der Pod-Lifecycle beschreibt die Abfolge der Zustände, durch die ein Pod während seiner Lebensdauer durchläuft. Es gibt fünf mögliche Phasen eines Pods: Pending (Ausstehend), Running (Aktiv), Succeeded (Erfolgreich abgeschlossen), Failed (Fehlgeschlagen) und Unknown (Unbekannt). Eine allgemeine Beschreibung des Pod-Zustands wird im PodStatus-Phasenfeld zusammengefasst.

Pending (Ausstehend): Der Pod wurde erstellt, aber noch nicht an einen Node zugewiesen und gestartet.
Running (Aktiv): Der Pod wurde auf einem Node zugewiesen und mindestens ein Container innerhalb des Pods wurde gestartet und läuft.
Succeeded (Erfolgreich abgeschlossen): Alle Container im Pod wurden erfolgreich ausgeführt und beendet.
Failed (Fehlgeschlagen): Mindestens einer der Container im Pod hat einen Fehler gemeldet oder ist unerwartet beendet worden.
Unknown (Unbekannt): Der Zustand des Pods kann nicht abgerufen werden.

Diese Phasen des Pod-Lifecycle ermöglichen es Administratoren und Entwicklern, den Zustand von Pods zu überwachen und auf Ereignisse zu reagieren, die während des Betriebs auftreten können.

Pod Priority

Sun, 03 Mar 2024 11:30:36 +0000

Pod-Priorität gibt die Bedeutung eines Pods im Vergleich zu anderen Pods an. Sie ermöglicht es, die Planungspriorität eines Pods höher oder niedriger als die anderer Pods festzulegen. Dies ist eine wichtige Funktion für Produktionsworkloads in Clustern.

Die Priorität eines Pods kann helfen, die Reihenfolge festzulegen, in der Pods gestartet und verteilt werden, insbesondere wenn Ressourcen knapp sind. Ein Pod mit höherer Priorität wird bevorzugt behandelt und hat eine höhere Chance, auf einem Knoten gestartet zu werden, selbst wenn die Ressourcen knapp sind. Dies kann helfen, sicherzustellen, dass kritische Workloads priorisiert werden, während weniger wichtige Workloads zurückgestellt werden können, um die Gesamtstabilität des Clusters zu gewährleisten.

Pod Security Police

Sun, 03 Mar 2024 11:30:36 +0000

Pod Security Policy ermöglicht eine feinkörnige Autorisierung für die Erstellung und Aktualisierung von Pods.

Es handelt sich um eine clusterweite Ressource, die sicherheitsrelevante Aspekte der Pod-Spezifikation kontrolliert. Die Pod Security Policy-Objekte definieren eine Reihe von Bedingungen, die ein Pod erfüllen muss, um vom System akzeptiert zu werden, sowie Standards für die entsprechenden Felder. Die Steuerung der Pod-Sicherheitsrichtlinie wird als optionaler Zulassungscontroller implementiert.

Pod Security Policy wurde ab Kubernetes v1.21 als veraltet markiert und in v1.25 entfernt. Als Alternative verwenden Sie Pod Security Admission oder ein Drittanbieter-Zulassungs-Plugin.

Preemption

Sun, 03 Mar 2024 11:30:36 +0000

In Kubernetes ist die Vorbelegung (Preemption) ein Mechanismus, der entwickelt wurde, um bei der Planung von Pods niedriger Priorität vorhandene Pods von Nodes zu entfernen, um Platz für Pods mit höherer Priorität zu schaffen, die aufgrund von Ressourcenbeschränkungen nicht geplant werden können. Wenn der Scheduler versucht, einen ausstehenden Pod auf einem Node zu platzieren, aber feststellt, dass nicht genügend Ressourcen verfügbar sind, wird der Vorbelegungsprozess ausgelöst.

Während der Vorbelegung identifiziert der Scheduler vorhandene Pods auf dem Node, die eine niedrigere Priorität als der ausstehende Pod haben. Diese Pods niedrigerer Priorität werden dann zur Räumung markiert, um Ressourcen auf dem Node für den Pod mit höherer Priorität freizugeben. Der Scheduler stellt sicher, dass die Gesamtauslastung der Ressourcen auf dem Node auch nach der Vorbelegung innerhalb akzeptabler Grenzen bleibt.

Probe

Sun, 03 Mar 2024 11:30:36 +0000

Eine Probe ist eine Überprüfung, die der Kubelet regelmäßig gegen einen Container durchführt, der in einem Pod läuft. Diese Überprüfungen dienen dazu, den Zustand und die Gesundheit des Containers zu definieren und Informationen für den Lebenszyklus des Containers bereitzustellen. Es gibt drei Arten von Proben, die von Kubernetes unterstützt werden:

Liveness Probe: Überprüft, ob der Container am Leben ist. Wenn die Liveness-Probe fehlschlägt, wird der Container als nicht gesund markiert und möglicherweise neu gestartet.

Proxy

Sun, 03 Mar 2024 11:30:36 +0000

Ein Proxy ist ein Server, der als Vermittler für einen entfernten Dienst fungiert. Wenn ein Client mit einem Proxy interagiert, übermittelt der Proxy die Daten des Clients an den tatsächlichen Server und leitet die Antwort des Servers zurück an den Client.

Im Kontext von Kubernetes ist kube-proxy ein Netzwerkproxy, der auf jedem Knoten im Cluster läuft und einen Teil des Kubernetes-Servicekonzepts implementiert. Seine Hauptaufgabe besteht darin, den Netzwerkverkehr zu den Pods zu leiten, die die Dienste des Clusters bereitstellen.

QoS class

Sun, 03 Mar 2024 11:30:36 +0000

Die QoS-Class (Quality of Service Class) bietet Kubernetes eine Möglichkeit, Pods innerhalb des Clusters in verschiedene Klassen einzuteilen und Entscheidungen über die Planung und Räumung zu treffen. Die QoS-Class eines Pods wird zum Zeitpunkt der Erstellung basierend auf seinen Anforderungen und Grenzen für Rechenressourcen festgelegt. QoS-Class werden verwendet, um Entscheidungen über die Planung und Räumung von Pods zu treffen. Kubernetes kann einem Pod eine der folgenden QoS-Class zuweisen: Garantiert, Erweiterbar oder BestEffort.

Quantity

Sun, 03 Mar 2024 11:30:36 +0000

Eine “Quantity” ist eine Darstellung von kleinen oder großen Zahlen unter Verwendung von SI-Suffixen. Quantitäten werden verwendet, um Zahlen auf kompakte Weise darzustellen, wobei ganze Zahlen und SI-Suffixe verwendet werden. Bruchzahlen werden mit Milli-Einheiten dargestellt, während große Zahlen mit Kilo-, Mega- oder Giga-Einheiten dargestellt werden können.

Zum Beispiel wird die Zahl 1,5 als 1500m dargestellt, während die Zahl 1000 als 1k und 1000000 als 1M dargestellt werden kann. Sie können auch binäre Suffixe verwenden; die Zahl 2048 kann als 2Ki geschrieben werden.

RBAC (Role-Based Access Control)

Sun, 03 Mar 2024 11:30:36 +0000

RBAC (Role-Based Access Control) ist ein Mechanismus zur Verwaltung von Autorisierungsentscheidungen in Kubernetes. Es ermöglicht Administratoren, Zugriffsrichtlinien dynamisch über die Kubernetes-API zu konfigurieren. Dies geschieht mithilfe von Rollen und Rollenbindungen.

Eine Rolle definiert die Berechtigungen, die einem Benutzer oder einer Gruppe von Benutzern für bestimmte Ressourcen im Cluster zugewiesen werden. Diese Berechtigungen umfassen Aktionen wie Lesen, Schreiben, Löschen usw. Rollen können auf Namespace-Ebene oder clusterweit definiert werden und können spezifische oder allgemeine Berechtigungen enthalten.

Replica

Sun, 03 Mar 2024 11:30:36 +0000

Eine Replica ist eine Kopie oder Duplikat eines Pods oder einer Gruppe von Pods. Replikas gewährleisten hohe Verfügbarkeit, Skalierbarkeit und Ausfallsicherheit, indem sie mehrere identische Instanzen eines Pods aufrechterhalten.

Replikas werden häufig in Kubernetes eingesetzt, um den gewünschten Anwendungsstatus und die Zuverlässigkeit zu erreichen. Sie ermöglichen das Skalieren der Workloads und die Verteilung über mehrere Nodes in einem Cluster.

Durch die Definition der Anzahl von Replikas in einem Deployment oder ReplicaSet stellt Kubernetes sicher, dass die angegebene Anzahl von Instanzen ausgeführt wird, und passt die Anzahl bei Bedarf automatisch an.

Replicaset

Sun, 03 Mar 2024 11:30:36 +0000

Ein ReplicaSet ist ein Objekt in Kubernetes, das darauf abzielt, eine bestimmte Anzahl von replizierten Pods aufrechtzuerhalten, die eine Anwendung oder einen Service darstellen. Es ist eine Möglichkeit, die Skalierung und Verfügbarkeit von Pods in einem Kubernetes-Cluster zu steuern.

Im Wesentlichen definiert ein ReplicaSet, wie viele identische Kopien eines Pods gleichzeitig ausgeführt werden sollen. Es überwacht ständig den aktuellen Zustand der Pods und startet automatisch neue Pods oder beendet vorhandene Pods, um sicherzustellen, dass die gewünschte Anzahl von Kopien immer aktiv ist.

ReplicationController

Sun, 03 Mar 2024 11:30:36 +0000

Ein ReplicationController ist ein Ressourcenobjekt in Kubernetes, das die Replica einer Anwendung verwaltet, indem es sicherstellt, dass eine bestimmte Anzahl von Instanzen eines Pods gleichzeitig ausgeführt wird. Es ist eine Möglichkeit, die Skalierung und Verfügbarkeit von Pods in einem Kubernetes-Cluster zu steuern.

Der ReplicationController überwacht kontinuierlich die Anzahl der laufenden Pods und startet automatisch neue Pods oder beendet vorhandene Pods, um sicherzustellen, dass die gewünschte Anzahl von Kopien der Anwendung immer aktiv ist. Wenn beispielsweise aufgrund von Ausfällen oder Skalierungsanforderungen die Anzahl der Pods sinkt oder steigt, passt der ReplicationController die Anzahl der Pods entsprechend an.

Resource Quotas

Sun, 03 Mar 2024 11:30:36 +0000

Resource Quotas in Kubernetes bieten einen Mechanismus zur Einschränkung des Gesamtverbrauchs von Ressourcen innerhalb eines Namespaces. Diese Quotas ermöglichen es Cluster-Administratoren, Beschränkungen für verschiedene Aspekte festzulegen, wie z. B. die Anzahl der Objekte, die erstellt werden können, und die Gesamtmenge an Rechenressourcen, die von Ressourcen innerhalb eines bestimmten Namespace verbraucht werden können.

Durch die Konfiguration von Ressourcenquoten können Administratoren verhindern, dass einzelne Projekte oder Teams die Clusterressourcen monopolisieren, und eine gerechte Ressourcenzuweisung für verschiedeneNamespace sicherstellen. Dies hilft, zu verhindern, dass ein Namespace die Leistung oder Verfügbarkeit von Ressourcen für andere, die denselben Cluster teilen, negativ beeinflusst.

Reviewer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Reviewer ist eine Person, die Code auf Qualität und Richtigkeit in einem bestimmten Bereich des Projekts überprüft. Diese Person sollte über fundierte Kenntnisse des Code-Bereichs sowie der Software-Engineering-Prinzipien verfügen. Die Rolle des Reviewers besteht darin, sicherzustellen, dass der Code den Standards entspricht, Fehler minimiert und die bestmögliche Qualität aufweist. Reviewer spielen eine wichtige Rolle im Entwicklungsprozess, indem sie Feedback geben, Probleme identifizieren und Verbesserungsvorschläge machen, um sicherzustellen, dass der Code den Anforderungen und Erwartungen entspricht.

Secret

Sun, 03 Mar 2024 11:30:36 +0000

Secrets sind eine wichtige Ressource in Kubernetes, die es ermöglicht, sensible Informationen sicher in einem Cluster zu verwalten.

Arten von Secrets: Kubernetes unterstützt verschiedene Arten von Secrets, darunter generische Secrets, Docker-Registry-Secrets, TLS-Secrets und SSH-Secrets. Jeder Typ ist darauf ausgelegt, bestimmte Arten von sensiblen Informationen zu speichern.

Verwendung von Secrets: Secrets können von Pods auf verschiedene Arten verwendet werden. Zum Beispiel können sie als Umgebungsvariablen in Containern bereitgestellt werden, um sensible Konfigurationsinformationen zu übergeben. Sie können auch als Volumen in Pods gemountet werden, um sensible Daten sicher zu speichern und zwischen verschiedenen Containern oder Pods zu teilen.

Security Context

Sun, 03 Mar 2024 11:30:36 +0000

Der Security Context (Sicherheitskontext) ist ein wichtiges Konzept in Kubernetes, das es ermöglicht, Privilegien und Zugriffskontrolle für Pods und Container zu definieren. Hier sind einige wichtige Punkte zum Sicherheitskontext:

Benutzer und Gruppen: Mit dem Sicherheitskontext können Sie festlegen, unter welchem Benutzer und welcher Gruppe die Prozesse innerhalb eines Pods oder Containers ausgeführt werden sollen. Dies ermöglicht eine granulare Steuerung über die Identität, unter der Anwendungen innerhalb des Pods arbeiten.
Privilegien: Sie können auch Privilegien für Pods oder Container festlegen, um bestimmte Aktionen oder Systemressourcen einzuschränken oder zu gewähren. Dies kann helfen, potenzielle Sicherheitslücken zu minimieren, indem unnötige Berechtigungen entfernt werden.

Selector

Sun, 03 Mar 2024 11:30:36 +0000

Ein Selector ist ein Mechanismus in Kubernetes, der es Benutzern ermöglicht, eine Liste von Ressourcen basierend auf Labels zu filtern. Labels sind Schlüssel/Wert-Paare, die Ressourcen in Kubernetes markieren und organisieren.

Mit einem Selector können Benutzer spezifizieren, welche Ressourcen sie aus einer Liste abrufen möchten, indem sie Kriterien basierend auf den Labels der Ressourcen angeben. Dies ermöglicht eine präzise Auswahl von Ressourcen, die bestimmte Anforderungen erfüllen.

Beispielweise können Sie mit einem Selector alle Pods abrufen, die mit einem bestimmten Label versehen sind, oder nur diejenigen Services auswählen, die einer bestimmten Kategorie zugeordnet sind.

Service

Sun, 03 Mar 2024 11:30:36 +0000

Ein Service ist eine Methode zum Bereitstellen einer Netzwerkanwendung, die in Ihrem Cluster als ein oder mehrere Pods ausgeführt wird.

Der Service identifiziert eine Gruppe von Pods, die eine bestimmte Netzwerkanwendung implementieren, und bietet einen einheitlichen, stabilen Endpunkt für den Zugriff auf diese Anwendung. Dies wird normalerweise durch einen Selector bestimmt, der die Pods auswählt, die durch den Service abgebildet werden sollen. Wenn Pods hinzugefügt oder entfernt werden, passt der Service automatisch die Menge der zugehörigen Pods an, um sicherzustellen, dass der Datenverkehr ordnungsgemäß geroutet wird.

Service Catalog

Sun, 03 Mar 2024 11:30:36 +0000

Der Servicekatalog war eine ehemalige Erweiterungs-API, die es Anwendungen ermöglichte, die in Kubernetes-Clustern ausgeführt werden, externe gemanagte Softwareangebote wie einen Datenspeicherdienst, der von einem Cloud-Anbieter angeboten wird, einfach zu nutzen.

Er bot eine Möglichkeit, externe Managed Services ohne detaillierte Kenntnisse darüber, wie diese Dienste erstellt oder verwaltet werden, aufzulisten, bereitzustellen und zu binden.

Der Servicekatalog erleichterte die Integration von Anwendungen in Kubernetes-Cluster mit externen Diensten, indem er einen standardisierten Ansatz für die Interaktion mit diesen Diensten bereitstellte. Dies ermöglichte es Entwicklern, Dienste aus einer Vielzahl von Quellen nahtlos in ihre Anwendungen zu integrieren, ohne sich um die spezifischen Implementierungsdetails kümmern zu müssen.

ServiceAccount

Sun, 03 Mar 2024 11:30:36 +0000

Ein ServiceAccount stellt eine Identität für Prozesse bereit, die in einem Pod ausgeführt werden.

Wenn Prozesse innerhalb von Pods auf den Cluster zugreifen, werden sie vom API-Server als ein bestimmter Serviceaccount authentifiziert, zum Beispiel “default”. Wenn Sie einen Pod erstellen und keinen Serviceaccount angeben, wird automatisch der Standard-Serviceaccount im gleichen Namespace zugewiesen. Dies ermöglicht es den Prozessen, mit dem Kubernetes-API-Server zu interagieren und auf Ressourcen im Cluster zuzugreifen, während gleichzeitig ihre Identität überwacht und kontrolliert wird.

Shuffle-sharding

Sun, 03 Mar 2024 11:30:36 +0000

Shuffle-sharding ist eine Technik zur Zuweisung von Anfragen an Warteschlangen, die eine bessere Isolierung als die Hashfunktion modulo die Anzahl der Warteschlangen bietet.

Oft geht es darum, verschiedene Anfrageströme voneinander zu isolieren, damit ein Strom mit hoher Intensität nicht die Ströme mit geringer Intensität überlagert. Eine einfache Möglichkeit, Anfragen in Warteschlangen zu platzieren, besteht darin, einige Merkmale der Anfrage zu hashen, modulo die Anzahl der Warteschlangen, um den Index der zu verwendenden Warteschlange zu erhalten. Die Hashfunktion verwendet als Eingabe Merkmale der Anfrage, die sich mit den Strömen decken. Zum Beispiel ist dies im Internet oft das 5-Tupel aus Quell- und Zieladresse, Protokoll sowie Quell- und Zielport.

Sidecar Container

Sun, 03 Mar 2024 11:30:36 +0000

Sidecar-Container sind eine oder mehrere Container, die in der Regel gestartet werden, bevor andere App-Container gestartet werden. Sidecar-Container ähneln regulären App-Containern, haben jedoch einen anderen Zweck: Der Sidecar stellt einen Pod-lokalen Dienst für den Haupt-App-Container bereit. Im Gegensatz zu Init-Containern bleiben Sidecar-Container nach dem Start des Pods weiterhin aktiv. Lesen Sie auch Sidecar-Container für weitere Informationen.

Link zum offiziellen Glossar

SIGS (Special interest group)

Sun, 03 Mar 2024 11:30:36 +0000

SIGs (Special Interest Groups) sind eine essentielle Struktur innerhalb der Kubernetes-Community, die dazu beiträgt, das komplexe Ökosystem des Projekts zu verwalten und zu erweitern. Jedes SIG konzentriert sich auf ein spezifisches Thema oder einen bestimmten Aspekt von Kubernetes und wird von Community-Mitgliedern geleitet, die ein gemeinsames Interesse an diesem Bereich haben. Die SIGs müssen sich an die SIG Rollen und organisatorischen Regeln halten Diese Gruppen spielen eine entscheidende Rolle bei der Entwicklung, Dokumentation und Verbesserung verschiedener Aspekte des Kubernetes-Ökosystems.

Spec

Sun, 03 Mar 2024 11:30:36 +0000

Die Spec (Spezifikation) in Kubernetes ist ein entscheidender Bestandteil jedes Objekts, sei es ein Pod, ein Service oder eine andere Ressource. Sie definiert den gewünschten Zustand und die Konfiguration des jeweiligen Objekts, und Kubernetes arbeitet kontinuierlich daran, sicherzustellen, dass das Objekt diesem Zustand entspricht. Die Spec ist in der Regel in der YAML- oder JSON-Syntax verfasst und enthält verschiedene Einstellungen und Parameter, die spezifisch für jedes Objekt sind.

Für Pods umfasst die Spec beispielsweise Angaben zu den Containern, den Volumes, den Netzwerkeinstellungen und anderen relevanten Konfigurationen. Für Services definiert die Spec die Portweiterleitungen, die Art der Dienstbereitstellung und andere Netzwerkeinstellungen. StatefulSets haben spezifische Einstellungen für die Replikation, Persistenz und Reihenfolge der Bereitstellung von Pods.

Statefulset

Sun, 03 Mar 2024 11:30:36 +0000

Ein StatefulSet in Kubernetes verwaltet die Bereitstellung und Skalierung einer Gruppe von Pods und bietet Garantien für die Reihenfolge und Eindeutigkeit dieser Pods. Ähnlich wie bei einer Bereitstellung (Deployment) verwaltet ein StatefulSet Pods, die auf einer identischen Container-Spezifikation basieren. Im Gegensatz zu einer Bereitstellung behält ein StatefulSet jedoch eine eindeutige Identität für jeden seiner Pods bei. Diese Pods werden aus derselben Spezifikation erstellt, sind aber nicht austauschbar: Jeder hat einen persistenten Bezeichner, den er über jede Neuverplanung hinweg beibehält.

Static Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Static Pod ist ein Pod, der direkt vom kubelet-Daemon auf einem bestimmten Node verwaltet wird, ohne dass der API-Server ihn beobachtet. Im Gegensatz zu regulären Pods, die über die Kubernetes-API verwaltet werden, werden Static Pods lokal auf dem Node definiert und gestartet.

Static Pods bieten eine Möglichkeit, Pods auf einem Kubernetes-Node zu starten, ohne dass der API-Server beteiligt ist. Sie sind nützlich für systemnahe Dienste oder Infrastrukturkomponenten, die unabhängig von der API-Serververfügbarkeit ausgeführt werden müssen. Da sie nicht von der Kubernetes-API verwaltet werden, unterstützen Static Pods keine ephemeren Container, die während der Laufzeit dynamisch hinzugefügt werden können. Alle Konfigurationen und Änderungen müssen direkt auf dem Node vorgenommen werden, auf dem der Static Pod ausgeführt wird.

Storage Class

Sun, 03 Mar 2024 11:30:36 +0000

Eine StorageClass ist ein wichtiger Bestandteil von Kubernetes, der es Administratoren ermöglicht, die verschiedenen verfügbaren Speichertypen im Cluster zu beschreiben und zu konfigurieren. Diese Funktion bietet Flexibilität und Automatisierung bei der Bereitstellung von persistentem Speicher für Anwendungen.

Die StorageClass definiert die Eigenschaften und Konfigurationen eines Speichertyps, einschließlich Aspekte wie die Art des Speichers (z. B. blockbasiert oder dateibasiert), die Speichergröße, Zugriffskontrollen, Replikation, Backup-Richtlinien und vieles mehr. Dies ermöglicht es Administratoren, Speichertypen basierend auf den Anforderungen ihrer Anwendungen zu erstellen und zu verwalten.

Sysctl

Sun, 03 Mar 2024 11:30:36 +0000

Sysctl ist eine halbstandardisierte Schnittstelle zum Lesen oder Ändern der Attribute des laufenden Unix-Kernels. Auf Unix-ähnlichen Systemen ist sysctl sowohl der Name des Tools, das Administratoren zum Anzeigen und Ändern dieser Einstellungen verwenden, als auch der Systemaufruf, den das Tool verwendet.

Durch sysctl können Administratoren verschiedene Einstellungen des Betriebssystems anpassen, um die Leistung, Sicherheit und Funktionalität des Kernels anzupassen. Diese Einstellungen umfassen Parameter wie Netzwerkeinstellungen, Dateisysteme, Speicher- und Prozessverwaltung, Netzwerkschnittstellen und vieles mehr.

Taint

Sun, 03 Mar 2024 11:30:36 +0000

Ein “Taint” ist ein Kernobjekt in Kubernetes, das aus drei erforderlichen Eigenschaften besteht: Schlüssel, Wert und Effekt. Taints verhindern die Planung von Pods auf Nodes oder Node-Gruppen.

Taints und Tolerations arbeiten zusammen, um sicherzustellen, dass Pods nicht auf ungeeigneten Nodes geplant werden. Ein oder mehrere Taints werden einem Node zugewiesen. Ein Node sollte nur einen Pod planen, der die entsprechenden Tolerations für die konfigurierten Taints aufweist.

Taints werden normalerweise verwendet, um Nodes zu markieren, die möglicherweise bestimmte Einschränkungen haben oder für spezielle Aufgaben vorgesehen sind. Zum Beispiel könnten Sie einen Node mit einem Taint markieren, der angibt, dass er nur für speicherintensive Pods geeignet ist. In diesem Fall würden nur Pods mit der entsprechenden Tolerierung für den Speicher-Taint auf diesem Node geplant werden.

Toleration

Sun, 03 Mar 2024 11:30:36 +0000

Eine “Toleration” ist ein Kernobjekt in Kubernetes, das aus drei erforderlichen Eigenschaften besteht: Schlüssel, Wert und Effekt. Tolerations ermöglichen die Planung von Pods auf Nodes oder Node-Gruppen, die entsprechende Taints aufweisen.

Tolerations und Taints arbeiten zusammen, um sicherzustellen, dass Pods nicht auf ungeeigneten Nodes geplant werden. Eine oder mehrere Tolerations werden einem Pod zugewiesen. Eine Toleration gibt an, dass der Pod auf Nodes oder Node-Gruppen mit passenden Taints geplant werden darf (aber nicht muss).

UID

Sun, 03 Mar 2024 11:30:36 +0000

Eine UID (User Identifier) ist eine von Kubernetes generierte Zeichenfolge, um Objekte eindeutig zu identifizieren. Jedes Objekt, das im Laufe des gesamten Lebenszyklus eines Kubernetes-Clusters erstellt wird, verfügt über eine eindeutige UID. Diese dient dazu, zwischen historischen Vorkommnissen ähnlicher Entitäten zu unterscheiden.

Die UID ist eine wichtige Komponente, um sicherzustellen, dass Objekte eindeutig identifiziert werden können, unabhängig davon, ob sie momentan vorhanden sind oder in der Vergangenheit erstellt wurden. Sie wird verwendet, um auf bestimmte Objekte zuzugreifen, sie zu referenzieren und sie von anderen Objekten zu unterscheiden. Die UID wird vom Kubernetes-System automatisch generiert und kann nicht vom Benutzer geändert werden.

Upstream

Sun, 03 Mar 2024 11:30:36 +0000

“Upstream” kann je nach Kontext verschiedene Bedeutungen haben:

Im Kubernetes-Community-Kontext bezieht sich “upstream” oft auf den Kern des Kubernetes-Codebasis, auf den das allgemeine Ökosystem, andere Codes oder Tools von Drittanbietern angewiesen sind. Zum Beispiel können Community-Mitglieder vorschlagen, dass ein Feature “upstream” verschoben wird, damit es im Kerncode statt in einem Plugin oder einem Tool von Drittanbietern liegt.
In GitHub oder Git bezieht sich “upstream” auf das ursprüngliche Repository, von dem ein Repository abgezweigt wurde. Das ursprüngliche Repository wird als “upstream” bezeichnet, während das abgezweigte Repository als “downstream” betrachtet wird.

User-Namespace

Sun, 03 Mar 2024 11:30:36 +0000

Das User-Namespaces-Feature im Linux-Kernel ermöglicht es einem nicht-root Benutzer, Superuser- (“root”) Berechtigungen zu emulieren. Dies ist besonders nützlich für “rootless containers”, bei denen Container ohne Superuser-Rechte außerhalb des Containers ausgeführt werden können.

Durch die Verwendung von User-Namespaces können nicht-root Benutzer privilegierte Aktionen innerhalb eines Containers ausführen, ohne dass sie über root-Berechtigungen auf dem Host-System verfügen müssen. Dies trägt dazu bei, die Sicherheit zu verbessern, indem potenzielle Schadensmöglichkeiten bei Container-Angriffen eingeschränkt werden.

Volume

Sun, 03 Mar 2024 11:30:36 +0000

Ein Volume in Kubernetes ist ein Verzeichnis, das Daten enthält und den Containern in einem Pod zugänglich ist. Anders als bei herkömmlichen Containern, die auf dem Dateisystem des Host-Betriebssystems basieren, wird ein Kubernetes-Volume innerhalb des Pod-Ökosystems verwaltet.

Ein Kubernetes-Volume besteht so lange wie der Pod, der es umgibt. Dadurch überlebt ein Volume alle Container, die innerhalb des Pods ausgeführt werden, und die Daten im Volume bleiben auch nach dem Neustart der Container erhalten.

Volume-Plugin

Sun, 03 Mar 2024 11:30:36 +0000

Ein Volume-Plugin ermöglicht die Integration von Speicher innerhalb eines Pods in Kubernetes. Es ermöglicht das Anhängen und Einbinden von Speichervolumes, die von einem Pod verwendet werden können. Volume-Plugins können in Baumstruktur (in-tree) oder außerhalb des Baumes (out-of-tree) implementiert sein.

In-Tree-Plugins sind Teil des Kubernetes-Quellcodes und folgen seinem Veröffentlichungszyklus. Sie werden gemeinsam mit Kubernetes entwickelt, gepflegt und veröffentlicht. Out-of-Tree-Plugins hingegen werden unabhängig von Kubernetes entwickelt. Sie können von Drittanbietern entwickelt und bereitgestellt werden, um spezielle Anforderungen an Speicherintegration zu erfüllen, die nicht von den standardmäßigen in-tree-Plugins abgedeckt werden.

Working Group

Sun, 03 Mar 2024 11:30:36 +0000

Eine working group - auf deutsch Arbeitsgruppe oder kurz : WG - erleichtert die Diskussion und/oder Umsetzung eines kurzlebigen, spezifischen oder entkoppelten Projekts für einen Ausschuss, eine SIG oder eine SIG-übergreifende Bemühung.

Arbeitsgruppen sind eine Möglichkeit, Personen zu organisieren, um eine spezifische Aufgabe zu erfüllen. Sie werden oft gebildet, um bestimmte Probleme anzugehen oder Projekte durchzuführen, die nicht innerhalb der üblichen Strukturen wie einer SIG oder einem Ausschuss behandelt werden können. Arbeitsgruppen können zeitlich begrenzt sein und sich auf eng umrissene Aufgaben konzentrieren, bevor sie ihre Ziele erreichen oder aufgelöst werden.

Workload

Sun, 03 Mar 2024 11:30:36 +0000

Eine Workload ist eine Anwendung, die auf Kubernetes läuft. Sie kann aus einer oder mehreren Komponenten bestehen, die verschiedene Teile der Anwendung repräsentieren, wie beispielsweise Frontend, Backend oder Datenbank. Um die verschiedenen Teile einer Anwendung auf Kubernetes zu verwalten, können verschiedene Kernobjekte verwendet werden, die als Workload-Objekte bezeichnet werden. Dazu gehören unter anderem:

DaemonSet: Stellt sicher, dass eine Kopie einer bestimmten Pod-Vorlage auf jedem Node im Cluster ausgeführt wird.
Deployment: Definiert einen Satz von identischen Pods, die eine Anwendung repräsentieren, und ermöglicht die Skalierung und Aktualisierung dieser Pods.
Job: Führt eine bestimmte Aufgabe oder einen Batch-Job aus, bis ein erfolgreicher Abschluss erreicht ist.
ReplicaSet): Sichert eine spezifizierte Anzahl von replizierten Pods und gewährleistet ihre Verfügbarkeit und Skalierbarkeit.
StatefulSet: Bietet eine Möglichkeit, Pods mit einer eindeutigen Identität und persistenten Speicher zu verwalten, wodurch die Reihenfolge und Einzigartigkeit der Pods gewährleistet wird.

Zusammen repräsentieren diese Workload-Objekte die verschiedenen Arten von Anwendungen und Aufgaben, die auf einem Kubernetes-Cluster ausgeführt werden können. Sie bieten Mechanismen zur Verwaltung, Skalierung und Wartung von Anwendungen und Diensten in einer Container-Umgebung.

Gemeinsam Lernen: Der Kubernetes Book Club und seine Vorteile

Sun, 25 Feb 2024 01:00:00 +0000

Lernen über Kubernetes und das gesamte Ökosystem der Technologien rund um es ist nicht ohne Herausforderungen. In diesem Artikel werfen wir einen Blick auf den Kubernetes Book Club, der von Carlos Santana ins Leben gerufen wurde. Hier erfahren wir, wie er funktioniert und wie jeder teilnehmen kann, um von einer gemeinschaftsorientierten Lernerfahrung zu profitieren.

Der Weg zum Kubernetes Book Club

Carlos Santana ist ein erfahrener Senior Specialist Solutions Architect bei AWS und hat seit sechs Jahren Erfahrung in der Produktion mit Kubernetes. Seine Reise führte ihn über Knative zu den Kubernetes Release Team-Beiträgen. Der Kubernetes Book Club entstand aus einer lockeren Idee während eines TGIK-Livestreams. Es ging ihm nicht nur ums Lesen eines Buches, sondern darum, eine Lerncommunity zu schaffen. Diese Plattform hat sich nicht nur als Wissensquelle, sondern auch als Unterstützungssystem, insbesondere während der herausfordernden Zeiten der Pandemie, etabliert.

Kubernetes vs OpenShift

Thu, 22 Feb 2024 11:30:36 +0000

Kriterium	Kubernetes	OpenShift
Entwickler	Open-Source-Projekt von Google, das von der CNCF verwaltet wird	Von Red Hat entwickelte Container-Plattform, die auf Kubernetes basiert
Funktionalität	Grundlegende Container-Orchestrierungsfunktionen wie automatisches Skalieren, Lastenausgleich und Service Discovery	Erweiterte Funktionen und Dienste wie Build- und Image-Management, Anwendungsskalierung und Sicherheit
Erweiterbarkeit	Modular und erweiterbar, unterstützt eine Vielzahl von Add-ons und Plugins	Erweitert Kubernetes um zusätzliche Funktionen und Dienste, bietet zusätzliche Integrationen und Support
Community-Unterstützung	Große und aktive Community von Entwicklern und Unternehmen	Unterstützt von Red Hat und der Open-Source-Community, bietet zusätzlichen Enterprise-Support und Integrationen
Entwicklungs- und Betriebsumgebung	Konzentriert sich hauptsächlich auf die Container-Orchestrierung und -Verwaltung	Integrierte Entwicklungs- und Betriebsumgebung, unterstützt CI/CD-Pipelines und DevOps-Praktiken
Unternehmen und Organisationen	Häufig von Unternehmen und Organisationen aller Größen und Branchen verwendet	Häufig von Unternehmen und Organisationen mit komplexen Anwendungsumgebungen und spezifischen Anforderungen eingesetzt
Support und SLAs	Angebot von Support und Services durch verschiedene Anbieter, keine spezifischen SLAs	Bietet Enterprise-Support und Service-Level-Vereinbarungen (SLAs) durch Red Hat und Partnerunternehmen

Kubernetes und OpenShift sind zwei verwandte, aber unterschiedliche Technologien im Bereich der Container-Orchestrierung und des Managements von Containeranwendungen. Hier sind die Hauptunterschiede zwischen Kubernetes und OpenShift:

Warum Kubernetes?

Sat, 10 Feb 2024 11:30:36 +0000

Willkommen bei ayedo: Ihre Lösung für kosteneffizienten Betrieb von SaaS-Produkten mit Kubernetes

Als Software-Unternehmen wissen Sie, dass der Betrieb von Software-as-a-Service (SaaS) Produkten eine komplexe und anspruchsvolle Aufgabe sein kann. Die Bereitstellung, Skalierung und Verwaltung von Anwendungen erfordert eine professionelle Infrastruktur und ein erfahrenes Team. Hier kommt Kubernetes ins Spiel – die führende Plattform für die Containerorchestrierung, die Ihnen dabei hilft, Ihre SaaS-Produkte effizient und kostengünstig zu betreiben.

Kubernetes On-Premise

Sat, 27 Jan 2024 11:30:36 +0000

Der Einsatz von Kubernetes on premise, also in einer privaten, selbstverwalteten Infrastruktur, kann einige Herausforderungen mit sich bringen, die es zu bewältigen gilt. Hier sind einige der wichtigsten Herausforderungen und potenziellen Schwierigkeiten:

Infrastrukturkomplexität: Die Einrichtung und Verwaltung einer Kubernetes-Infrastruktur on premise erfordert ein gewisses Maß an technischer Expertise und ein Verständnis für Netzwerke, Speicher und Compute-Ressourcen. Dies kann besonders für kleinere Unternehmen oder Organisationen eine Herausforderung darstellen, die möglicherweise nicht über das erforderliche Fachwissen oder die Ressourcen verfügen.

Kubernetes vs Docker

Fri, 26 Jan 2024 11:30:36 +0000

Kriterium	Kubernetes	Docker
Funktionalität und Zweck	Container-Orchestrierungsplattform für Bereitstellung, Skalierung und Verwaltung von Containeranwendungen	Containerisierungsplattform für das Verpacken, Bereitstellen und Ausführen von Anwendungen in Containern
Abstraktionsebene	Höhere Ebene der Abstraktion, konzentriert sich auf die Verwaltung von Containern und Anwendungen in einer verteilten Umgebung	Niedrigere Ebene der Abstraktion, konzentriert sich auf die Verpackung von Anwendungen in Containern und deren Ausführung
Management von Containern und Anwendungen	Umfassende Plattform für das Cluster-Management, Service-Discovery, Lastenausgleich, automatische Skalierung und Rolling Updates von Anwendungen	Werkzeuge für das Erstellen, Verwalten und Ausführen von Containern, fehlen jedoch fortgeschrittene Funktionen für das Cluster-Management und die Verwaltung verteilter Anwendungen
Einsatzbereich	Häufig in Produktionsumgebungen für das Betreiben von Containeranwendungen in Cloud- und Hybrid-Cloud-Umgebungen verwendet	Häufig von Entwicklern und DevOps-Teams für die lokale Entwicklung und das Verpacken von Anwendungen in Containern verwendet, wird auch in Produktionsumgebungen eingesetzt
Beispielprodukte	Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS)	Docker Engine, Docker Desktop, Docker Hub

Kubernetes und Docker sind zwei verschiedene Technologien, die jedoch oft in Verbindung miteinander verwendet werden, da sie sich beide mit der Verwaltung von Containern befassen. Hier sind die Hauptunterschiede zwischen Kubernetes und Docker:

Was ist Docker

Sat, 20 Jan 2024 11:30:36 +0000

Docker ist eine Open-Source-Plattform für die Containerisierung von Anwendungen. Es ermöglicht Entwicklern, Anwendungen und ihre Abhängigkeiten in Containern zu verpacken, um eine konsistente Bereitstellung und Ausführung auf verschiedenen Umgebungen zu gewährleisten. Docker hat die Art und Weise, wie Anwendungen entwickelt, bereitgestellt und betrieben werden, grundlegend verändert.

Hier sind die Hauptkomponenten und Konzepte von Docker:

Container: Ein Container ist eine standardisierte, isolierte und portable Umgebung, die eine Anwendung und ihre Abhängigkeiten enthält. Docker verwendet Container, um Anwendungen in einer konsistenten Umgebung auszuführen, unabhängig von der zugrunde liegenden Infrastruktur.

Was ist Kubernetes?

Fri, 19 Jan 2024 11:30:36 +0000

Kubernetes ist eine leistungsstarke Open-Source-Plattform, die entwickelt wurde, um die Verwaltung von Containeranwendungen zu erleichtern. Um zu verstehen, was Kubernetes ist und wofür es verwendet wird, ist es hilfreich, zuerst zu erklären, was Container sind.

Container sind eine Art von Softwareverpackung, die es Entwicklern ermöglicht, Anwendungen und alle ihre Abhängigkeiten in einem einzigen, isolierten Paket zu bündeln. Diese Container sind leichtgewichtig, tragbar und konsistent, was bedeutet, dass sie über verschiedene Umgebungen hinweg konsistent ausgeführt werden können, unabhängig von den darunter liegenden Betriebssystemen oder Infrastrukturen.

Die Kunst der Kubernetes-Versionen: Ein Blick hinter die Kulissen der Release-Gruppe

Thu, 18 Jan 2024 01:00:00 +0000

Einleitung

Die Release Special Interest Group (SIG Release) ist das Herzstück von Kubernetes, wenn es darum geht, alle vier Monate neue Funktionen und Bugfixes zu veröffentlichen. Haben Sie sich schon mal gefragt, wie ein so großes Projekt wie Kubernetes seinen Zeitplan so effizient managt? In diesem Artikel werfen wir einen Blick auf die Abläufe innerhalb des Release-Teams und wie Sie daran teilnehmen können.

Was ändert sich konkret für Entwickler/DevOps-Teams?

SIG Release spielt eine entscheidende Rolle in der Entwicklung und Evolution von Kubernetes. Das Hauptziel dieser Gruppe ist es, den Release-Prozess neuer Kubernetes-Versionen zu steuern. Dies geschieht in einem regelmäßigen Zyklus, der in der Regel alle drei bis vier Monate stattfindet. Während dieses Zyklus arbeitet das Kubernetes Release-Team eng mit anderen SIGs und Mitwirkenden zusammen, um einen reibungslosen und gut koordinierten Release zu gewährleisten. Dazu gehört die Planung des Release-Zeitplans, das Setzen von Fristen für Code-Freezes und Testphasen sowie die Erstellung von Release-Artefakten wie Binaries, Dokumentationen und Release-Notizen.

Cal.com mit Docker in der Hetzner Cloud

Fri, 12 Jan 2024 11:30:36 +0000

In diesem Artikel zeigen wir den schnellsten und bequemsten Weg, Cal.com mit Docker in der Hetzner Cloud zu self-hosten. Mit Hilfe von Polycrate haben Sie in weniger als 5 Minuten Zugang zu Ihrer eigenen Cal.com Instanz auf Hetzner.

Ihre Cal.com Instanz ermöglicht Ihnen zahlreiche Integrationen mit Kalender- und Meeting-Tools, wie zum Beispiel:

In diesem Artikel wird Ihre Cal.com Instanz mit Microsoft 365 integriert sodass Sie gleich Zugriff auf Ihre MS365 Kalender und Meetings haben.

Container Network Interface (CNI) in Kubernetes: Ciliums Rolle und die Übernahme von Isovalent durch Cisco

Mon, 01 Jan 2024 09:30:36 +0000

Willkommen zu einem Thema, das für jeden Kubernetes-Nutzer von entscheidender Bedeutung ist: das Container Network Interface (CNI). In dieser Diskussion beleuchten wir nicht nur die Grundlagen des CNIs, sondern auch die spezifische Rolle von Cilium, einem führenden CNI, das für seine fortschrittlichen Funktionen und seine Bedeutung in modernen Kubernetes-Implementierungen bekannt ist. Besonders interessant ist dabei die jüngste Entwicklung in der CNI-Landschaft – die Übernahme von Isovalent, dem schweizerischen Unternehmen hinter Cilium, durch den US-amerikanischen Netzwerkriesen Cisco.

Kontakt

Mon, 01 Jan 2024 00:00:00 +0000

Was macht eigentlich OPNsense?

Thu, 28 Dec 2023 11:30:36 +0000

Das Thema Netzwerksicherheit wird häufig stiefmütterlich behandelt und das, obwohl die Netzwerksicherheit ein hohes Gut ist! Sowohl im privaten als auch im wirtschaftlichen Sektor kommt häufig nur ein Tool zum Einsatz und dieses auch eher unwissentlich:

Die Firewall

Eine Firewall ist eine grundlegende Sicherheitsfunktion, um sein Netzwerk vor unerwünschten Zugriffen zu schützen. Sie stellt eine Sicherheitsbarriere zwischen einem lokalen und einem externen Netzwerk wie beispielsweise dem Internet dar. Dabei wird eingehender wie ausgehender Datenverkehr überwacht und auf Grundlage von vordefinierten Regeln entscheidet die Firewall, welche Datenpakete geblockt werden müssen. Diese Paketinspektion geschieht in Echtzeit und überprüft Parameter wie die Quell- und Ziel-IP-Adressen, Ports und Protokolle sowie weitere Header Informationen. Wenn sich darunter Parameter befinden, welche sich auf einer Verbotsliste befinden (so genanntes Black-Listing), also beispielsweise ein Zugriff auf einen unerwünschten Port, greift die regelbasierte Filterung und blockiert das Paket. Zusätzlich loggt die Firewall Zugriffe und bietet dem Administrator so eine Kontrolle über potentielle Sicherheitsvorfälle. Eine Firewall ist in den meisten modernen Routern integriert, standardmäßig konfiguriert und schützt auf diese Weise das Netzwerk des Anwenders.

What's the matter with matter?

Thu, 28 Dec 2023 11:30:36 +0000

In der heutigen Welt, in der Technologie eine zentrale Rolle in unserem Alltag spielt, hat die Idee eines vernetzten Zuhauses - ein Smart Home - an Bedeutung gewonnen. Smart-Home-Geräte, oder auch IoT-Devices, ermöglichen es uns, Beleuchtung, Heizung, Sicherheitssysteme und vieles mehr über das Internet zu steuern und zu automatisieren. Dabei handelt es sich bei weitem nicht mehr nur um kleine quality of life changes – die Waschmaschine die sich jetzt per Smartphone starten lässt – sondern das Smart-Home kann viel mehr. Es hilft beispielsweise, Energie zu sparen in dem es automatisch die Rollläden runterlässt, wenn eine bestimme Außentemperatur unterschritten wird oder es regelt die Heizung viel genauer als wir dazu im Stande wären. Immer wenn man auf der Fahrt in den Urlaub die Autobahn erreicht hat kommen die gleichen Fragen: Haben wir die Haustür abgeschlossen? Ist das kleine Fenster im Badezimmer noch offen? Muss ich jetzt dem Nachbarn bescheid sagen, dass er mal schnell gucken soll? Solche Fragen können dank smarter Türschlösser oder Fenstersensoren der Vergangenheit angehören.

Allgemeine Geschäftsbedingungen

Tue, 26 Dec 2023 00:00:00 +0000

1. Geltungsbereich

1.1. Anwendungsbereich

Diese Allgemeinen Geschäftsbedingungen gelten für alle Vertragsverhältnisse zwischen der Ayedo Cloud Solutions GmbH („ayedo") und dem Kunden (ayedo und Kunde auch „Vertragsparteien" oder „Parteien") über die Erbringung sämtlicher von ayedo angebotenen Leistungen und/oder Produkte (insgesamt die „Services")

1.2. Zielgruppe und Geltung

Die Leistungen und/oder Produkte von ayedo richten sich ausschließlich an Unternehmen im Sinne des § 14 Abs. 1 BGB , juristische Personen des öffentlichen Rechts oder öffentlich-rechtliche Sondervermögen. Abweichende Geschäftsbedingungen werden nicht anerkannt, es sei denn, diesen wurde ausdrücklich schriftlich zugestimmt. Diese Allgemeinen Geschäftsbedingungen gelten auch dann, wenn in Kenntnis entgegenstehender oder abweichender Bedingungen des Kunden Leistungen vorbehaltlos erbracht werden. Diese Allgemeinen Geschäftsbedingungen gelten nicht für die Geschäftsbeziehung von ayedo mit Kunden, die Verbraucher im Sinne des § 13 BGB sind. Für diese Kunden gelten gesonderte Geschäftsbedingungen, auf die bei Bedarf explizit verwiesen wird.

Kubernetes 1.29: Volumenattribute einfach ändern – So profitieren Entwickler!

Mon, 18 Dec 2023 01:00:00 +0000

Die Veröffentlichung von Kubernetes 1.29 bringt eine spannende Neuerung mit sich: eine alpha-Funktion, die es ermöglicht, Volumen durch Ändern des volumeAttributesClassName, der für einen PersistentVolumeClaim (PVC) festgelegt wurde, zu modifizieren. Diese Funktion vereinfacht die Verwaltung von Volumenattributen erheblich, da Änderungen nun direkt über Kubernetes erfolgen können, anstatt über verschiedene APIs der Anbieter verwaltet werden zu müssen.

VolumeAttributesClass

Die neue API-Gruppe storage.k8s.io/v1alpha1 bietet zwei neue Typen:

VolumeAttributesClass
Repräsentiert eine Spezifikation von veränderbaren Volumenattributen, die vom CSI-Treiber definiert werden. Diese Klasse kann während der dynamischen Bereitstellung von PersistentVolumeClaims angegeben und nach der Bereitstellung in der PVC-Spezifikation geändert werden.

Das ABC von OpenTelemetry: Von den Grundlagen bis zur Integration

Sat, 25 Nov 2023 11:30:36 +0000

In einer komplexen IT-Landschaft kann das Überwachen und Verstehen von Anwendungsleistungen zu einer wahren Herausforderung werden. Das Open-Source Framework OpenTelemetry bietet hier eine vereinheitlichte Lösung für Monitoring und Observability, die es Entwicklern und DevOps ermöglicht, umfassende Einblicke in ihre Anwendungen zu erhalten. Dieser Artikel führt Sie durch die Grundlagen, zeigt Ihnen, warum OpenTelemetry wichtig ist, und hilft Ihnen, die ersten Schritte in Richtung Implementierung dieses vielseitigen Frameworks in Ihren Technologiestack zu gehen.

Kubernetes-Ressourcengrenzen: Der Balanceakt zwischen Vorhersehbarkeit und Effizienz

Sun, 19 Nov 2023 01:00:00 +0000

Es gibt eine Menge Diskussionen darüber, ob das Nichtverwenden von Kubernetes-Ressourcengrenzen tatsächlich von Vorteil sein könnte (zum Beispiel in Artikeln wie For the Love of God, Stop Using CPU Limits on Kubernetes oder Kubernetes: Make your services faster by removing CPU limits). Die Argumente sind durchaus gültig – es macht wenig Sinn, für Rechenleistung zu bezahlen, die aufgrund von Beschränkungen nicht genutzt wird, oder künstlich die Latenz zu erhöhen. Dieser Artikel möchte jedoch darlegen, dass Limits auch ihre legitimen Vorteile haben.

Zero-Downtime Deployments mit Docker Swarm und Portainer - Teil 2/2

Sun, 05 Nov 2023 10:37:00 +0000

Was haben wir bisher erreicht?

In Teil 1 haben wir uns angeschaut, was nochmal die Unterschiede zwischen Rolling Updates und Zero-downtime deployments sind. Anschließend haben wir unseren Stack vorbereitet, sodas wir ein Zero-downtime deployment durchführen können.

In diesem Teil werden wir uns nun anschauen, wie wir unsere Anwendung über Portainer aktualisieren können. Dabei werden wir über GitHub automatisch ein Update anstoßen lassen, sodass wir in Portainer nichts mehr machen müssen.

Behind the Scenes: Ein Blick auf den Kubernetes Contributor Summit 2023

Sun, 05 Nov 2023 01:00:00 +0000

Jedes Jahr, kurz vor der offiziellen Eröffnung von KubeCon+CloudNativeCon, findet eine ganz besondere Veranstaltung statt, die einen besonderen Platz im Herzen der Organisatoren und Teilnehmer hat: der Kubernetes Contributor Summit. Um herauszufinden, warum das so ist, und um einen Blick hinter die Kulissen zu werfen, haben wir Noah Abrahams interviewt, der unter anderem als Co-Leiter des Kubernetes Contributor Summit 2023 tätig war.

Frederico Muñoz (FSM): Hallo Noah und herzlich willkommen. Könntest du dich bitte vorstellen und uns erzählen, wie du zu Kubernetes gekommen bist?

Gateway API v1.0: Ein Meilenstein für Kubernetes-Routing

Fri, 03 Nov 2023 01:00:00 +0000

Wir freuen uns, im Namen des Kubernetes SIG Network die Veröffentlichung von Gateway API v1.0 anzukündigen! Dieses Release stellt einen wichtigen Meilenstein für das Projekt dar. Mehrere zentrale APIs haben den Status “generally available” (GA) erreicht, während andere bedeutende Funktionen in den Experimental-Kanal aufgenommen wurden.

Was ist neu?

Graduation zu v1

Diese Veröffentlichung umfasst die Graduierung von Gateway, GatewayClass und HTTPRoute zu v1. Das bedeutet, dass sie jetzt allgemein verfügbar sind (GA). Diese API-Version zeigt ein hohes Maß an Vertrauen in die API-Oberfläche und bietet Garantien für die Abwärtskompatibilität. Beachten Sie, dass die Version dieser APIs, die im Standard-Kanal enthalten sind, nun als stabil gilt, dies jedoch nicht bedeutet, dass sie vollständig sind. Diese APIs werden weiterhin neue Funktionen über den Experimental-Kanal erhalten, während sie die Kriterien für die Graduierung erfüllen. Weitere Informationen dazu finden Sie in der Gateway API Versioning Policy.

So gelingt der Wechsel: ingress2gateway für eine einfache Migration zur Gateway API

Sat, 28 Oct 2023 02:00:00 +0000

Heute stellen wir ingress2gateway vor, ein Tool, das Ihnen dabei hilft, von Ingress zur Gateway API zu migrieren. Die Gateway API steht kurz vor der Veröffentlichung in der GA-Version – wenn Sie also noch nicht umgestiegen sind, ist jetzt der richtige Zeitpunkt!

Hintergrund

In der sich ständig weiterentwickelnden Welt von Kubernetes spielt die Netzwerktechnologie eine entscheidende Rolle. Mit der zunehmenden Anzahl an Anwendungen in Kubernetes-Clustern wird die effektive Bereitstellung dieser Dienste für Clients zu einer kritischen Herausforderung. Wenn Sie bereits mit Kubernetes arbeiten, sind Sie wahrscheinlich mit der Ingress API vertraut, die als Standardlösung für den externen Zugang zu Diensten dient.

Was ist eigentlich eine Interne Developer Plattform?

Wed, 25 Oct 2023 11:30:36 +0000

Effizienz und Skalierbarkeit sind in der rasanten Welt der Softwareentwicklung oft entscheidende Faktoren für den Erfolg eines Projekts. Eine Technologie, die in diesem Kontext immer mehr an Bedeutung gewinnt, ist die Interne Developer Plattform (IDP). Aber was ist das eigentlich genau und warum sollten Sie und Ihr Unternehmen sich damit beschäftigen? In diesem Beitrag gehen wir auf die Grundlagen und Vorteile von Internen Developer Plattformen ein und geben Ihnen Orientierungshilfen für die Auswahl der richtigen Lösung.

Kubernetes Contributor Summit 2023: Ein Wiedersehen in Shanghai

Mon, 23 Oct 2023 02:00:00 +0000

Am 26. September 2023 trafen sich fast 50 Mitwirkende zum Kubernetes Contributor Summit in Shanghai, im Rahmen der KubeCon + CloudNativeCon + Open Source Summit China 2023.

Dies war das erste persönliche Treffen in China nach drei Jahren Pandemie.

Ein freudiges Treffen

Die Veranstaltung begann mit Begrüßungsansprachen von Kevin Wang von Huawei Cloud, einem der Co-Vorsitzenden von KubeCon, und Puja von Giant Swarm.

Kubernetes im Luftspiegel: So starten Sie einen Cluster ohne Internet

Sun, 15 Oct 2023 02:00:00 +0000

Ever wonder how software gets deployed onto a system that is deliberately disconnected from the Internet and other networks? Diese Systeme sind oft aufgrund ihrer sensiblen Natur vom Internet getrennt. Dazu zählen beispielsweise Versorgungsunternehmen (Strom/Wasser), Banken, das Gesundheitswesen, Waffensysteme und andere staatliche Anwendungen. Manchmal handelt es sich sogar um einen Wassergraben, wenn Sie Kubernetes auf einem Unterwasserfahrzeug betreiben. Dennoch müssen diese Umgebungen mit Software betrieben werden. Dieses Konzept der Bereitstellung in einem abgeschotteten Zustand beschreibt, was es bedeutet, auf die andere Seite eines Luftspiegels zu deployen.

Single-Sign-On (SSO): Was sind eigentlich OAuth, OpenID, SAML und SCIM?

Tue, 10 Oct 2023 11:30:36 +0000

In der digital vernetzten Welt ist das ständige Anmelden bei verschiedenen Diensten mehr als nur ein lästiges Übel – es ist eine Herausforderung für die Datensicherheit und das Benutzererlebnis. Eine fortschrittliche Lösung für dieses Dilemma bietet die Single Sign-On Technologie (SSO). Sie ermöglicht es Benutzern, sich einmal anzumelden und Zugang zu mehreren Diensten zu erhalten, ohne für jeden einzelnen Service separate Anmeldedaten eingeben zu müssen.

Container Orchestration: Was ist eigentlich der Unterschied zwischen Docker Swarm und Kubernetes?

Mon, 09 Oct 2023 09:30:36 +0000

In der modernen Softwareentwicklung ist Container-Orchestrierung längst kein Fremdwort mehr, sondern ein unverzichtbares Werkzeug für DevOps-Teams. Sie ermöglicht es, Container-Instanzen effizient zu verwalten, zu verteilen und zu skalieren. Doch wenn es um die Wahl der richtigen Orchestrierungsplattform geht, stehen viele vor einer Entscheidung: Docker Swarm oder Kubernetes?

Beide Technologien haben ihre eigenen Vorteile, Schwächen und Anwendungsgebiete. Doch welche ist die richtige für Ihr Projekt? In diesem Beitrag beleuchten wir beide Orchestrierungstools in Detail, vergleichen ihre Features und geben Ihnen handfeste Kriterien an die Hand, damit Sie die beste Entscheidung für Ihre Anforderungen treffen können.

Benutzer-Namensräume: Stateful Pods jetzt in Kubernetes 1.28 verfügbar!

Sat, 16 Sep 2023 02:00:00 +0000

Kubernetes v1.25 führte die Unterstützung von Benutzer-Namensräumen nur für stateless Pods ein. Mit Kubernetes 1.28 wurde diese Einschränkung aufgehoben, nachdem in der Version 1.27 einige Designänderungen vorgenommen wurden.

Die Schönheit dieser Funktion liegt darin, dass:

sie mühelos übernommen werden kann (man muss nur ein boolesches Feld in der Pod-Spezifikation setzen)
keine Änderungen für die meisten Anwendungen erforderlich sind
die Sicherheit drastisch verbessert wird, indem die Isolation von Containern erhöht und CVEs mit den Bewertungen HOCH und KRITISCH gemindert werden.

Dieser Beitrag erklärt die Grundlagen der Benutzer-Namensräume und zeigt:

Zero-Downtime Deployments mit Docker Swarm und Portainer - Teil 1/2

Sun, 10 Sep 2023 13:37:00 +0000

Zero-downtime deployments mit Docker Swarm und Portainer Teil 1/2

Was sind Zero-downtime deployments?

Bevor wir ans Eingemachte gehen, klären wir einmal die Frage, was denn Zero-downtime deployments sind. Zero-downtime deployments sind Deployments, die keine Ausfallzeit haben. Das bedeutet, dass die Anwendung die gerade deployed wird während des Deyploments nicht offline ist. Das ist besonders wichtig bei Anwendungen, die 24/7 laufen müssen. Die hohe Verfügbarkeit von Anwendungen rückt immer mehr in den Fokus. Mal ehrlich, wer will schon warten müssen, wenn Netflix und Co. ihre Anwendungen updaten?

Achtung: Veraltete Kubernetes-Paket-Repositories werden eingefroren!

Sun, 03 Sep 2023 02:00:00 +0000

Am 15. August 2023 hat das Kubernetes-Projekt die allgemeine Verfügbarkeit der gemeinschaftlich verwalteten Paket-Repositories für Debian- und RPM-Pakete unter pkgs.k8s.io bekannt gegeben. Diese neuen Repositorys ersetzen die veralteten, von Google gehosteten Paket-Repositories: apt.kubernetes.io und yum.kubernetes.io. Der Ankündigungsbeitrag zu pkgs.k8s.io hat hervorgehoben, dass wir in Zukunft keine Pakete mehr in die alten Repositories veröffentlichen werden.

Heute kündigen wir offiziell die Abkündigung der alten Paket-Repositories (apt.kubernetes.io und yum.kubernetes.io) an und informieren über unsere Pläne, den Inhalt dieser Repositories am 13. September 2023 einzufrieren.

Kubernetes Garbage Collection: Mit Terminating Pods aufräumen

Thu, 17 Aug 2023 10:38:36 +0000

Mit ayedo ist der Betrieb Ihrer Apps in Kubernetes ein Kinderspiel. Hin und wieder reichen die Boardmittel allerdings nicht aus, um den reibungslosen Betrieb Ihrer Anwendungen sicherzustellen. Einen nützlichen kleinen Life-Hack im Zusammenhang mit Terminating Pods möchten wir Ihnen in diesem Artikel vorstellen. Noch kein Kubernetes Cluster?

Mit ayedo Fleet können Sie Kubernetes 30 Tage kostenlos testen, ohne die operativen Kopfschmerzen. Probieren Sie’s aus.

Der CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: garbage-collector-cronjob
  namespace: kube-system
spec:
  schedule: '*/1 * * * *'
  concurrencyPolicy: Forbid
  suspend: false
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      parallelism: 1
      completions: 1
      backoffLimit: 0
      template:
        metadata:
          creationTimestamp: null
        spec:
          volumes:
            - name: scripts
              configMap:
                name: garbage-collector-cm
                defaultMode: 320
          containers:
            - name: garbage-collector
              image: alpine/k8s:1.25.12
              command:
                - /scripts/remove-evicted-pods-all-ns.sh
              resources: {}
              volumeMounts:
                - name: scripts
                  mountPath: /scripts
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
              imagePullPolicy: IfNotPresent
          restartPolicy: Never
          terminationGracePeriodSeconds: 30
          dnsPolicy: ClusterFirst
          securityContext: {}
          schedulerName: default-scheduler

Und die dazugehörige ConfigMap:

Docker Swarm auf Hetzner Cloud in 3 Schritten

Tue, 11 Jul 2023 10:38:36 +0000

Mit ayedo ist der Betrieb Ihrer Apps in Kubernetes ein Kinderspiel. Mit Docker Swarm bieten wir eine produktionsreife Alternative zu Kubernetes für alle, die sich mit den Abstraktionen von Docker wohl fühlen, aber mehr Verfügbarkeit und Skalierbarkeit benötigen. Mit der ayedo Fleet Custom Edition kommen Sie in den Genuss von Docker Swarm, ohne die operativen Kopfschmerzen. Probieren Sie’s aus.

Wir lieben Kubernetes. Ist einfach unser Ding. Nichts desto trotz setzen viele Unternehmen nach wie vor auf Docker Swarm zur Orchestrierung Ihrer Container-Workloads und das zu Recht. Docker Swarm ist in vielerlei Hinsicht weniger flexibel wie Kubernetes, aber auf jeden Fall weniger komplex - was es zum idealen Kandidaten für Einsteiger in die Welt verteiler Container-Workloads macht. Docker Swarm erweitert die Syntax und Semantik der bereits bekannten Docker-Befehle um ein Konzept von Services und Stacks um replizierte Workloads gemeinsam verwaltbar zu machen.

Mattermost Self-Hosted: SSO mit Authentik als IDP in der Free-Version

Tue, 04 Jul 2023 12:40:00 +0000

Mattermost wird in vielen Unternehmen als zentrale Kommunikationsplattform verwendet. Es ist vergleichbar mit Microsoft Teams oder auch Slack. Was ist nun der Unterschied zwischen Mattermost und anderen Kommunikationsplattformen? Mattermost ist grundsätzlich kostenlos. Zudem kann man die Open-Source-Software auf eigenen Servern betreiben, was für einige Unternehmen ein wichtiges Kriterium sein wird, Stichwort: Compliance.

Ein großer Nachteil an der Free-Version von Mattermost ist die Limitierung sich nur via GitLab SSO authentifizieren zu können, sollte man mehr wollen als User in der Mattermost-internen DB. Sofern man GitLab als zentrale Nutzerverwaltung im Unternehmen verwendet stellt dies kein Problem dar. Meist verwenden Unternehmen jedoch dedizierte IDPs (Identity Provider) wie Keycloak, Authentik oder Auth0.

Sichere Container-Bilder: So überprüfen Sie digitale Signaturen in Kubernetes

Sun, 02 Jul 2023 02:00:00 +0000

Einleitung

Die Kubernetes-Community hat mit der Version v1.24 den Schritt gewagt, ihre Container-Image-basierten Artefakte digital zu signieren. Mit der Umstellung des entsprechenden Enhancements von alpha auf beta in v1.26 wurden auch die Signaturen für binäre Artefakte eingeführt. Dies hat andere Projekte inspiriert, ebenfalls Bildsignaturen für ihre Releases zu implementieren. Aber wie verifiziert man diese Signaturen effektiv?

Änderungen für Entwickler und DevOps-Teams

Für Entwickler und DevOps-Teams bedeutet dies, dass sie nun die Möglichkeit haben, Container-Images automatisiert zu signieren und diese Signaturen zu überprüfen. Dies kann entweder innerhalb der eigenen CI/CD-Pipelines geschehen, beispielsweise durch GitHub Actions, oder durch den Kubernetes-Image-Promotion-Prozess, der die Signierung automatisch vornimmt. Voraussetzung dafür ist, dass das Projekt Teil der kubernetes oder kubernetes-sigs GitHub-Organisation ist.

Kubernetes: Liveness und Readiness Probes erklärt

Sat, 01 Jul 2023 10:38:36 +0000

Probes sind Checks, die das Kubelet einer Node in oder gegen einen Pod ausführt um dessen Status zu überprüfen.

Mit Hilfe der Probes kann zum Beispiel überprüft werden, ob der Container auf einen bestimmten Port lauscht oder ob Programme, die im Container ausgeführt werden, einen bestimmten Exit-Code zurückgeben.

Das Ergebnis einer Probe wird vom Kubelet interpretiert und triggert bestimmte Lifecycle-Events eines Pods. Schlägt eine Probe zum Beispiel fehl kann das ein Signal für das Kubelet sein den Pod neuzustarten.

Apps

Tue, 27 Jun 2023 00:00:00 +0000

Kubernetes 1.27: Ressourcen dynamisch anpassen – ohne Neustart der Pods!

Mon, 15 May 2023 02:00:00 +0000

In der neuesten Version von Kubernetes, v1.27, gibt es eine aufregende Neuerung: Die Möglichkeit, CPU- und Speicherressourcen für laufende Pods anzupassen, ohne diese neu starten zu müssen. Dies bedeutet eine erhebliche Entlastung für Entwickler und DevOps-Teams, die oft mit der Herausforderung konfrontiert sind, die Ressourcen ihrer Anwendungen dynamisch zu verwalten.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Bisher war das Anpassen von Ressourcen für Pods eine disruptive Maßnahme, die einen Neustart erforderte. Mit der Einführung der neuen Alpha-Funktion in Kubernetes v1.27 können Sie die resources-Felder in den Containern eines Pods jetzt einfach ändern, indem Sie die Spezifikation des laufenden Pods patchen. Dies reduziert Ausfallzeiten und steigert die Effizienz Ihrer Anwendungen.

Kubernetes 1.27: Bessere Speichermanagement-Funktionen für Ihre Container

Mon, 08 May 2023 02:00:00 +0000

Kubernetes v1.27, veröffentlicht im April 2023, bringt Verbesserungen im Bereich Memory QoS (alpha), die eine effizientere Speicherverwaltung auf Linux-Knoten ermöglichen.

Support für Memory QoS wurde ursprünglich in Kubernetes v1.22 eingeführt, wobei später einige Einschränkungen in Bezug auf die Berechnung von memory.high festgestellt wurden. Diese Einschränkungen wurden nun in Kubernetes v1.27 behoben.

Hintergrund

Kubernetes ermöglicht es Ihnen, optional anzugeben, wie viel von jeder Ressource ein Container in der Pod-Spezifikation benötigt. Die häufigsten Ressourcen sind CPU und Speicher.

Fünf wichtige Features von Portainer

Sun, 07 May 2023 11:30:36 +0000

Fünf wichtige Features von Portainer

Wie bereits im vorherigen Blogpost erwähnt, ist Portainer ein mächtiges Tool, das alle Funktionen von Docker grafisch darstellt und vereinfacht. Dabei bietet Portainer über die von Docker bekannten Funktionen hinaus, noch einige weitere Features, welche die Verwaltung von Docker Containern noch einfacher machen.

In diesem Blogpost möchte ich fünf dieser Features vorstellen.

Bei den Features handelt es sich nicht unbedingt um die wichtigsten Features, sondern um die Features, welche ich am interessantesten finde.

Kubernetes verbessert den offiziellen CVE-Feed: Was Entwickler wissen sollten

Fri, 28 Apr 2023 02:00:00 +0000

Seit der Einführung des automatisch aktualisierenden offiziellen CVE-Feeds als Alpha-Funktion in der Version 1.25 haben wir bedeutende Verbesserungen und Updates vorgenommen. Wir freuen uns, die Veröffentlichung der Beta-Version des Feeds bekannt zu geben. In diesem Blogbeitrag werden wir das erhaltene Feedback, die vorgenommenen Änderungen und die Möglichkeiten zur Unterstützung besprechen, während wir uns darauf vorbereiten, dies in einer zukünftigen Kubernetes-Version zu einer stabilen Funktion zu machen.

Feedback von Endbenutzern

Das SIG Security-Team erhielt einige Rückmeldungen von Endbenutzern:

Warum man Portainer anstelle der Konsole nutzen sollte: Einführung und schneller Einstieg

Mon, 10 Apr 2023 11:30:36 +0000

Für diejenigen die direkt loslegen wollen hier der Link zum praktischen Teil

Warum dieser Post?

Immer wieder fällt mir auf, dass sich viele Menschen vor der Kommandozeile scheuen. Das ist auch nicht besonders verwunderlich, denn die Kommandozeile erfordert ein gewisses technisches Verständnis und kann insbesondere für Neulinge und unerfahrene Anwender abschreckend wirken. Immerhin gibt es bei vielen Technologien neben der Kommandozeile auch eine grafische Benutzeroberfläche (GUI), die oft als intuitiver empfunden wird.

Die Kunst der forensischen Analyse von Kubernetes-Containern

Mon, 13 Mar 2023 01:00:00 +0000

In meinem vorherigen Artikel habe ich das Thema Checkpointing in Kubernetes vorgestellt und erläutert, wie es eingerichtet werden kann. Diesmal möchte ich Ihnen zeigen, wie Sie die erstellten Checkpoints analysieren können. Das Checkpointing ist derzeit noch eine Alpha-Funktion in Kubernetes, und dieser Artikel gibt einen Ausblick darauf, wie diese Funktion in Zukunft aussehen könnte.

Vorbereitung

Details zur Konfiguration von Kubernetes und der zugrunde liegenden CRI-Implementierung, um die Unterstützung für Checkpointing zu aktivieren, finden Sie in meinem vorherigen Artikel.

KWOK: Revolutioniere Deine Kubernetes-Tests in Sekundenschnelle!

Sat, 04 Mar 2023 01:00:00 +0000

Hast du dich jemals gefragt, wie man in Sekundenschnelle ein Cluster aus Tausenden von Knoten aufsetzt, reale Knoten mit niedrigem Ressourcenbedarf simuliert und deine Kubernetes-Controller in großem Maßstab testet, ohne viel für die Infrastruktur auszugeben?

Wenn du auf eine dieser Fragen mit “Ja” geantwortet hast, könnte KWOK genau das Richtige für dich sein. Es handelt sich um ein Toolkit, das es dir ermöglicht, in Sekundenschnelle ein Cluster aus Tausenden von Knoten zu erstellen.

Die Sicherheit von Microservices: Vulnerabilitäten erkennen und schützen

Mon, 23 Jan 2023 01:00:00 +0000

In der heutigen digitalen Welt sind Cyber-Angriffe komplexer denn je. Unternehmen, die Cloud-Dienste bereitstellen, investieren zwar kontinuierlich in Sicherheitsmaßnahmen, doch die Zahl der Cybervorfälle steigt weiterhin. Es wird zunehmend klar, dass die Vorstellung, völlig sichere und schwachstellenfreie Microservices zu entwickeln, naiv ist. Der erste Schritt zur Verbesserung Ihrer Sicherheitsstrategie besteht darin, zu akzeptieren: Ihre Dienste sind anfällig!

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die Erkenntnis, dass alle Microservices anfällig sind, ist entscheidend. Es ist wichtig, dass Entwickler und DevOps-Teams nicht nur Sicherheitsbest Practices befolgen, sondern auch verstehen, dass Schwachstellen immer vorhanden sein können. Dies bedeutet, dass ein reaktiver Ansatz zur Sicherheitsüberwachung und -analyse unerlässlich ist.

Schütze Deine wichtigsten Pods vor der Eviction mit PriorityClass!

Sun, 15 Jan 2023 01:00:00 +0000

Kubernetes hat sich als führende Orchestrierungsengine etabliert, die von vielen Organisationen genutzt wird, um Workloads effizient zu verwalten. Die richtige Planung der Pods ist entscheidend, um sicherzustellen, dass Anwendungs-Pods innerhalb des Kubernetes-Clusters reibungslos laufen. In diesem Artikel betrachten wir, wie das Objekt PriorityClass verwendet wird, um mission-critical oder hochpriorisierte Pods vor der Eviction zu schützen und sicherzustellen, dass sie verfügbar sind und den Datenverkehr bedienen.

Ressourcenmanagement in Kubernetes

Der Control Plane von Kubernetes besteht aus mehreren Komponenten, wobei der Scheduler (in der Regel der integrierte kube-scheduler) eine der wichtigsten ist. Er ist dafür verantwortlich, einen Knoten einem Pod zuzuweisen.

Kubernetes v1.26: Revolutionäre Verbesserungen im Traffic-Management

Mon, 02 Jan 2023 01:00:00 +0000

Kubernetes v1.26 bringt bedeutende Fortschritte im Netzwerk-Traffic-Management mit sich. Zwei Funktionen, die Unterstützung der internen Traffic-Policy für Services und die Endpunkt-Slice-Abbruchbedingungen, wurden in den allgemeinen Zugriff (GA) überführt. Eine dritte Funktion, das Proxy für abgebrochene Endpunkte, hat den Beta-Status erreicht. Diese Verbesserungen zielen darauf ab, Herausforderungen im Traffic-Management zu adressieren und neue Möglichkeiten für die Zukunft zu eröffnen.

Verlust von Traffic durch Load Balancer während Rolling Updates

Vor Kubernetes v1.26 konnten Cluster während Rolling Updates Traffic-Verluste durch Service-Load-Balancer erleiden, wenn das Feld externalTrafficPolicy auf Local gesetzt war. Um das zu verstehen, hilft ein kurzer Überblick darüber, wie Kubernetes Load Balancer verwaltet!

Kubernetes 1.26: Effizientes Job-Tracking für massive Batch-Workloads!

Sun, 01 Jan 2023 01:00:00 +0000

Die Veröffentlichung von Kubernetes 1.26 bringt eine stabile Implementierung des Job Controllers mit sich, der zuverlässig eine große Anzahl an Jobs mit hohem Parallelitätsgrad nachverfolgen kann. Die Teams von SIG Apps und WG Batch haben seit Kubernetes 1.22 an dieser grundlegenden Verbesserung gearbeitet. Nach mehreren Iterationen und Skalierungsüberprüfungen ist dies jetzt die Standardimplementierung des Job Controllers.

In Kombination mit dem indizierten Abschlussmodus kann der Job Controller massiv parallele Batch-Jobs verwalten und unterstützt bis zu 100.000 gleichzeitige Pods.

Kubernetes v1.26: Flexibelere Authentifizierung für Container-Registries

Sun, 25 Dec 2022 01:00:00 +0000

Kubernetes v1.26 bringt eine spannende Neuerung mit sich: den allgemeinen Unterstützungsstatus (GA) für Kubelet Credential Provider Plugins. Dieses erweiterbare Plugin-Framework ermöglicht es Entwicklern, dynamisch Anmeldeinformationen für jede Container-Image-Registry abzurufen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Vor Kubernetes v1.20 waren Entwickler darauf angewiesen, dass die Kubelet-Authentifizierung nur für einige spezifische Container-Registries wie Amazon Elastic Container Registry (ECR), Azure Container Registry (ACR) und Google Cloud Container Registry (GCR) verfügbar war. Ab v1.20 wurde eine alpha-Unterstützung für Kubelet Credential Provider Plugins eingeführt, die es ermöglicht, Anmeldeinformationen für beliebige Container-Registries dynamisch abzurufen.

Kubernetes 1.26: Revolutionäre Validierungsrichtlinien für Admissions

Fri, 23 Dec 2022 01:00:00 +0000

In Kubernetes 1.26 steht die erste Alpha-Version der Validating Admission Policies zur Verfügung! Diese neuen Richtlinien nutzen die Common Expression Language (CEL) und bieten eine deklarative, in-process Alternative zu den bestehenden validating admission webhooks.

CEL wurde ursprünglich für Validierungsregeln für CustomResourceDefinitions in Kubernetes eingeführt. Diese Erweiterung weitet die Nutzung von CEL erheblich aus und unterstützt eine viel breitere Palette von Anwendungsfällen für Admission.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Admission Webhooks können für Entwickler und DevOps-Teams eine große Herausforderung darstellen. Sie müssen nicht nur einen Webhook-Binary implementieren und warten, sondern auch sicherstellen, dass dieser immer verfügbar ist. Wenn ein Webhook zeitlich ausfällt oder nicht erreichbar ist, kann dies zu einem Ausfall des Kubernetes-Controlplanes führen. Mit den neuen Validating Admission Policies wird dieser komplexe Prozess erheblich vereinfacht, indem CEL-Ausdrücke direkt in Kubernetes-Ressourcen eingebettet werden.

Kubernetes 1.26: Der Device Manager ist jetzt für alle bereit!

Thu, 22 Dec 2022 01:00:00 +0000

Einleitung

Mit der Veröffentlichung von Kubernetes 1.26 ist der Device Manager nun allgemein verfügbar! Diese Funktion, die ursprünglich in Kubernetes v1.8 vorgestellt wurde, ermöglicht es Entwicklern, externe Geräte effizient zu entdecken, anzubieten und zuzuweisen, ohne das Kernsystem von Kubernetes zu verändern. Dies ist ein bedeutender Schritt, der sowohl für Entwickler als auch für DevOps-Teams neue Möglichkeiten eröffnet.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Der Device Manager ermöglicht eine nahtlose Kommunikation mit sogenannten Device Plugins über gRPC. Diese Plugins fungieren als Server und ermöglichen es dem kubelet, sich mit ihnen zu verbinden, um Geräte zu entdecken und sie als erweiterte Ressourcen anzubieten. Durch die Registrierung beim kubelet wird der Device Manager Teil des Kubernetes-Ökosystems und ermöglicht die Verwaltung von externen Geräten wie GPUs, FPGAs und mehr.

Dynamische Ressourcenallokation in Kubernetes 1.26: Flexibilität für Entwickler

Sun, 18 Dec 2022 01:00:00 +0000

Einführung

In der neuesten Version von Kubernetes 1.26 gibt es eine spannende Neuerung: die Alpha API für dynamische Ressourcenallokation. Diese Funktion ermöglicht es Entwicklern, Ressourcen flexibler und gezielter anzufordern. Die Erweiterung ist eine Verallgemeinerung der API für persistenten Speicher und eröffnet neue Möglichkeiten in der Handhabung von Ressourcen in Containern.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die dynamische Ressourcenallokation erlaubt es, dieselbe Ressourcinstanz in verschiedenen Pods und Containern zu nutzen. Zudem können spezifische Einschränkungen für Ressourcennachfragen angehängt werden, um genau die Ressourcen zu erhalten, die benötigt werden. Dies verbessert die Effizienz und Nutzung der Ressourcen erheblich.

Endlich verfügbar: HostProcess-Container für Windows in Kubernetes 1.26

Fri, 16 Dec 2022 01:00:00 +0000

Der lang erwartete Tag ist gekommen: HostProcess-Container, das Windows-Pendant zu Linux-privilegierten Containern, sind endlich in Kubernetes 1.26 allgemein verfügbar!

Was sind HostProcess-Container und warum sind sie nützlich?

Cluster-Betreiber sehen sich oft der Herausforderung gegenüber, ihre Knoten bei der Bereitstellung zu konfigurieren, z. B. durch die Installation von Windows-Diensten, die Konfiguration von Registrierungsschlüsseln, das Verwalten von TLS-Zertifikaten, Änderungen an der Netzwerkkonfiguration oder sogar durch die Bereitstellung von Überwachungstools wie dem Prometheus Node-Exporter. Bisher wurden diese Aufgaben auf Windows-Knoten normalerweise durch das Ausführen von PowerShell-Skripten über SSH oder WinRM-Sitzungen und/oder durch die Verwendung der Verwaltungstools des Cloud-Anbieters durchgeführt.

Sichere Container-Analyse: Forensisches Checkpointing in Kubernetes

Thu, 08 Dec 2022 01:00:00 +0000

Forensisches Container-Checkpointing basiert auf Checkpoint/Restore In Userspace (CRIU) und ermöglicht das Erstellen von zustandsbehafteten Kopien eines laufenden Containers, ohne dass der Container davon Kenntnis hat. Diese Kopie kann analysiert und mehrfach in einer Sandbox-Umgebung wiederhergestellt werden, ohne dass der ursprüngliche Container davon weiß. Forensisches Container-Checkpointing wurde als Alpha-Feature in Kubernetes v1.25 eingeführt.

Wie funktioniert es?

Mit Hilfe von CRIU ist es möglich, Container zu checkpointen und wiederherzustellen. CRIU ist in runc, crun, CRI-O und containerd integriert, und das forensische Container-Checkpointing, wie es in Kubernetes implementiert ist, nutzt diese bestehenden CRIU-Integrationen.

Kubernetes und OpenTelemetry: Die Geheimwaffe für bessere Container-Überwachung

Sun, 04 Dec 2022 01:00:00 +0000

Einleitung

In der Welt der Cloud-nativen Technologien wird OpenTelemetry (OTEL) oft als Schlüssel zur Verbesserung der Überwachung von Anwendungen genannt. Diese innovative Lösung ermöglicht es, Logs, Metriken und Traces zu einem umfassenden Bild zu kombinieren. Doch wie kann Kubernetes diese Technologie nutzen, um die Sichtbarkeit in Container-Runtime-Umgebungen zu verbessern?

Was ändert sich konkret für Entwickler/DevOps-Teams?

Kubernetes ist ein komplexes System, das aus verschiedenen Komponenten besteht, die entweder unabhängig oder miteinander verbunden sind. Um die Überwachung zu erleichtern, wird OpenTelemetry nun auch in Kubernetes integriert. Diese Integration bedeutet, dass Entwickler und DevOps-Teams eine bessere Sicht auf den Zustand ihrer Cluster erhalten. Anstatt sich auf das Durchforsten von Logs und Metriken zu verlassen, können sie jetzt konsolidierte Informationen nutzen, um Probleme schneller zu identifizieren und zu beheben.

Infrastructure as Code: der Devops Standard

Mon, 28 Nov 2022 16:38:36 +0000

Infrastructure as Code (IaC) unterstützt DevOps-Best-Practices, indem es die Erstellung wiederholbarer Infrastrukturumgebungen durch die Verwendung einer deklarativen Sprache erleichtert. In diesem Artikel wird untersucht, was IaC ist, welche Vorteile es aus der DevOps-Perspektive bietet und welche der beliebtesten IaC-Tools heute verfügbar sind.

Wenn Sie als DevOps-Ingenieur Ihre Karriere vorantreiben möchten, haben Sie wahrscheinlich schon von Infrastructure as Code (IaC) gehört. Infrastructure as Code hat sich als Schlüsselkomponente der DevOps-Bewegung herauskristallisiert, deren Ziel es ist, die Kommunikation und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams zu verbessern.

Deutsche Verwaltungscloud-Strategie: Kubernetes, Container und DevOps im Fokus

Thu, 17 Nov 2022 10:38:36 +0000

Der IT-Planungsrat beschließt das Dokument „Deutsche Verwaltungscloud-Strategie: Rahmenwerk zur Zielarchitektur 2.0“.

PDF downloaden

TL;DR

die Deutsche Verwaltungscloud soll primär aus Open Source Komponenten bestehen
alle Teilnehmer müssen die definierten Standards implementieren und befolgen
Anbieter von Lösungen für die Deutsche Verwaltungscloud müssen
- ihre Services in deutschem Hoheitsgebiet bereitstellen
- Container-as-a-Service Plattformen auf Basis von Kubernetes bereitstellen
- DevOps-Ansätze wie Continuous Integration und Continuous Deployment implementieren
- die Migrierbarkeit von Services zwischen unterschiedlichen Anbietern gewährleisten
Zentrale Service-Komponenten die von Teilnehmern der Deutschen Verwaltungscloud entwickelt werden, sollen über OpenCoDE allen Teilnehmern zur Verfügung gestellt werden

Übersicht

Der IT-Planungsrat fungiert als zentrales politisches Steuerungsgremium zwischen Bund und Ländern in Fragen der Informationstechnik und der Digitalisierung von Verwaltungsleistungen. Er fördert und entwickelt gemeinsame nutzer:innenorientierte IT-Lösungen und ebnet so den Weg für eine effiziente, sichere und gut vernetzte digitale Verwaltung in Deutschland.

Kubernetes v1.25: Sicherheit durch Benutzer-Namensräume für Pods

Thu, 06 Oct 2022 02:00:00 +0000

Kubernetes v1.25 bringt eine bedeutende Neuerung mit sich: die Unterstützung für Benutzer-Namensräume. Diese Funktion ermöglicht es, sichere Workloads in Kubernetes zu betreiben, indem jeder Pod nur auf einen eingeschränkten Satz von verfügbaren UIDs und GIDs auf dem System zugreifen kann. Dies fügt eine zusätzliche Sicherheitsebene hinzu, um Pods, die auf demselben System laufen, zu schützen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Mit der neuen Unterstützung für Benutzer-Namensräume können Entwickler und DevOps-Teams sicherere Anwendungen bereitstellen. Jeder Pod läuft in einer eigenen Umgebung mit einzigartigen IDs, was das Risiko von Sicherheitsvorfällen verringert. Insbesondere wird es möglich, Workloads als Root auszuführen, ohne den Host zu gefährden. Diese Isolation ist besonders wertvoll in multi-tenant Umgebungen, wo verschiedene Teams oder Anwendungen auf demselben Cluster betrieben werden.

Kubernetes 1.25: Stabilität für StatefulSets und DaemonSets im Rollout

Sun, 18 Sep 2022 02:00:00 +0000

Einleitung

Mit der Veröffentlichung von Kubernetes 1.25 gibt es spannende Neuigkeiten für Entwickler und DevOps-Teams: Zwei wichtige Features, minReadySeconds für StatefulSets und maxSurge für DaemonSets, haben den Status “stabil” erreicht. Diese Änderungen verbessern die Handhabung von Rollouts und erhöhen die Verfügbarkeit von Anwendungen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die neuen stabilen Features bieten Entwicklern eine verbesserte Steuerung über den Rollout-Prozess von StatefulSets und DaemonSets. minReadySeconds gibt Teams die Möglichkeit, sicherzustellen, dass ein Pod für eine bestimmte Zeit bereit ist, bevor er als verfügbar gilt. Gleichzeitig ermöglicht maxSurge, dass während eines Rollouts mehrere Instanzen eines Pods auf einem Knoten laufen können, was die Ausfallzeiten minimiert.

Bleib sicher: Der neue automatische CVE-Feed für Kubernetes im Blick

Thu, 15 Sep 2022 02:00:00 +0000

Ein lang gehegter Wunsch der Kubernetes-Community war es, eine programmatische Möglichkeit zu schaffen, Sicherheitsprobleme in Kubernetes (auch bekannt als “CVEs”) zu verfolgen. Mit der Veröffentlichung von Kubernetes v1.25 freuen wir uns, die Verfügbarkeit eines solchen Feeds als alpha-Feature bekannt zu geben. In diesem Blogbeitrag werden wir die Hintergründe und den Umfang dieses neuen Dienstes beleuchten.

Motivation

Mit der zunehmenden Aufmerksamkeit auf Kubernetes ist auch die Zahl der CVEs, die mit Kubernetes in Verbindung stehen, gestiegen. Obwohl die meisten CVEs, die Kubernetes direkt, indirekt oder transitiv betreffen, regelmäßig behoben werden, gibt es keinen einzigen Ort, an dem die Endbenutzer von Kubernetes programmatisch abonnieren oder die Daten von behobenen CVEs abrufen können. Die aktuellen Optionen sind entweder fehlerhaft oder unvollständig.

Build your own developer platform on Kubernetes with Otomi

Sun, 28 Aug 2022 10:38:36 +0000

Building cloud native software and running it in production is quite a challenge these days. Besides getting the architecture of your software right, you have to deal with things like cloud infrastructure, CI/CD and a whole lot of security concerns – especially if you build your software in teams. Our work at ayedo is focused on helping you getting the latter part right with our managed Kubernetes and Applications offerings. On of these applications is Otomi – a self-hosted PaaS the enables organizations to build their own developer platform on top of Kubernetes.

Kubernetes v1.25: Sicherheit für Pods wird zur neuen Norm

Sun, 28 Aug 2022 02:00:00 +0000

Die Veröffentlichung von Kubernetes v1.25 markiert einen bedeutenden Meilenstein für die Sicherheitskontrollen von Pods: Der Pod Security Admission Controller (PSA) hat den Status “stabil” erreicht, während die Pod Security Policy (PSP) entfernt wurde. PSP wurde in Kubernetes v1.21 als veraltet gekennzeichnet und funktioniert in Kubernetes v1.25 und später nicht mehr.

Der Pod Security Admission Controller ersetzt die Pod Security Policy und erleichtert die Durchsetzung vordefinierter Pod Security Standards, indem einfach ein Label zu einem Namespace hinzugefügt wird. Die Pod Security Standards werden von der K8s-Community gepflegt, was bedeutet, dass Sie automatisch aktualisierte Sicherheitsrichtlinien erhalten, wenn neue sicherheitsrelevante Funktionen in Kubernetes eingeführt werden.

PodSecurityPolicy: Von der Idee zur Abschaffung – Ein Blick zurück

Fri, 19 Aug 2022 02:00:00 +0000

Die PodSecurityPolicy (PSP) wurde mit Kubernetes v1.25 entfernt. Diese Entscheidung wurde bereits zuvor in dem Blogbeitrag PodSecurityPolicy Deprecation: Past, Present, and Future angekündigt. In diesem Artikel werfen wir einen Blick auf die Entstehung und Entwicklung der PSP, erklären, warum sie nie stabil wurde und zeigen, weshalb sie durch die Pod Security Admission Control ersetzt wurde.

Die Entstehung der PodSecurityPolicy

Die PodSecurityPolicy hat ihre Wurzeln in den SecurityContextConstraints (SCC) von OpenShift, die bereits in der ersten Version der Red Hat OpenShift Container Platform implementiert waren, noch vor der Veröffentlichung von Kubernetes 1.0. Die PSP war eine vereinfachte Version der SCC.

Kubernetes-Updates: So gestaltet das Enhancement-Team die Zukunft

Sun, 14 Aug 2022 02:00:00 +0000

Wussten Sie, dass Kubernetes v1.24 ganze 46 Verbesserungen enthält? In nur vier Monaten hat das Team eine beeindruckende Anzahl neuer Funktionen in das System integriert. Das Kubernetes-Release-Team übernimmt die logistischen Aufgaben einer solchen Veröffentlichung, von der Behebung von Testproblemen bis hin zur Veröffentlichung aktualisierter Dokumentationen. Eine Menge Arbeit, die aber immer erfolgreich gemeistert wird.

Das Release-Team besteht aus etwa 30 Personen, die sich auf sechs Unterteams verteilen: Bug Triage, CI Signal, Enhancements, Release Notes, Communications und Docs. Jedes dieser Teams verwaltet einen Teil des Releases. In diesem Artikel möchten wir uns besonders auf die Rolle des Enhancements-Teams konzentrieren und aufzeigen, wie Sie sich beteiligen können.

Dokumentation im Rampenlicht: Wie SIG Docs Kubernetes vorantreibt

Fri, 05 Aug 2022 02:00:00 +0000

Einleitung

Die offizielle Dokumentation ist die zentrale Anlaufstelle für jedes Open-Source-Projekt. Für Kubernetes ist dies eine ständig wachsende Special Interest Group (SIG), in der engagierte Mitglieder daran arbeiten, Informationen für neue Mitwirkende und Benutzer leicht zugänglich zu machen. SIG Docs veröffentlicht die offizielle Dokumentation auf kubernetes.io, die unter anderem die Dokumentation der Kern-APIs, architektonische Details und CLI-Tools umfasst, die mit den Kubernetes-Versionen ausgeliefert werden.

Um mehr über die Arbeit von SIG Docs und ihre zukünftigen Pläne zur Gestaltung der Community zu erfahren, habe ich meine Gespräche mit den Co-Vorsitzenden Divya Mohan (DM), Rey Lejano (RL) und Natali Vlatko (NV) zusammengefasst. Sie erläuterten die Ziele der SIG und wie andere Mitwirkende helfen können.

Kubernetes 1.24: Strukturierte Protokolle für mehr Klarheit

Sat, 28 May 2022 02:00:00 +0000

Die Working Group für strukturiertes Logging hat in Kubernetes 1.24 neue Funktionen zur Protokollierungsinfrastruktur hinzugefügt. In diesem Artikel erfahren Sie, wie Entwickler diese nutzen können, um die Protokollausgaben nützlicher zu gestalten, und wie sie sich aktiv an der Verbesserung von Kubernetes beteiligen können.

Strukturiertes Logging

Das Ziel des strukturierten Loggings besteht darin, die C-artige Formatierung und die daraus resultierenden undurchsichtigen Log-Strings durch Protokolleinträge zu ersetzen, die eine klar definierte Syntax für die separate Speicherung von Nachrichten und Parametern haben, zum Beispiel als JSON-Struktur.

Kubernetes 1.24: Die Revolution im Speichermanagement ist da!

Mon, 09 May 2022 02:00:00 +0000

Die Veröffentlichung von Kubernetes 1.24 bringt das Storage Capacity Tracking als allgemein verfügbare Funktion mit sich. Diese Neuerung ermöglicht es Entwicklern und DevOps-Teams, die Kapazität ihrer Speicherressourcen besser zu verwalten und zu überwachen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Mit dem neuen Storage Capacity Tracking können CSI-Treiber (Container Storage Interface) Informationen über die verbleibende Speicherkapazität bereitstellen. Der kube-scheduler nutzt diese Informationen, um geeignete Knoten für Pods auszuwählen, die noch Volumes benötigen.

Sicherheitsboost für Ingress-NGINX: So schützt die neue Version Ihre Kubernetes-Anwendungen

Sun, 01 May 2022 02:00:00 +0000

Die Ingress ist eines der am häufigsten angegriffenen Komponenten in Kubernetes. Ein Ingress definiert in der Regel einen HTTP-Reverse-Proxy, der ins Internet exponiert wird und mehrere Websites enthält. Zudem hat er privilegierten Zugang zur Kubernetes-API, beispielsweise um Secrets für TLS-Zertifikate und deren private Schlüssel zu lesen.

Obwohl es sich hierbei um eine riskante Komponente in Ihrer Architektur handelt, ist sie immer noch der beliebteste Weg, um Ihre Dienste ordnungsgemäß bereitzustellen.

Ingress-NGINX war Teil von Sicherheitsbewertungen, die auf ein großes Problem hinwiesen: Wir führen nicht alle notwendigen Sanitärmaßnahmen durch, bevor wir die Konfiguration in eine nginx.conf-Datei umwandeln, was zu Informationslecks führen kann.

Zwei Jahre SIG Node CI: Auf dem Weg zu stabileren Kubernetes-Tests

Sat, 19 Feb 2022 01:00:00 +0000

Ensuring the reliability of SIG Node upstream code is a continuous effort that takes a lot of behind-the-scenes effort from many contributors. Es gibt häufige Releases von Kubernetes, Basisbetriebssystemen, Container-Runtimes und Testinfrastrukturen, die zu einer komplexen Matrix führen, die Aufmerksamkeit und kontinuierliche Investitionen erfordert, um “die Lichter am Laufen zu halten”.

Im Mai 2020 organisierte die Kubernetes Node Special Interest Group (“SIG Node”) ein neues Subprojekt für kontinuierliche Integration (CI) für node-bezogene Codes und Tests. Seit seiner Gründung führt das SIG Node CI Subprojekt wöchentliche Meetings durch, und selbst eine volle Stunde reicht oft nicht aus, um alle Fehler, testbezogenen PRs und Probleme zu bearbeiten und alle laufenden Arbeiten innerhalb der Gruppe zu besprechen.

Multicluster: Die Zukunft von Kubernetes jenseits der Clustergrenzen

Thu, 10 Feb 2022 01:00:00 +0000

Einleitung

Die SIG Multicluster ist die Special Interest Group, die sich mit der Anwendung von Kubernetes-Konzepten über die Grenzen eines Clusters hinaus beschäftigt. Traditionell interagieren Kubernetes-Ressourcen nur innerhalb dieser Grenzen. Mit der zunehmenden Verbreitung von Multicloud- und Multicluster-Deployments gewinnt die Arbeit von SIG Multicluster zunehmend an Bedeutung. In diesem Blog diskutieren Jeremy Olmsted-Thompson von Google und Chris Short von AWS die spannenden Herausforderungen, die SIG Multicluster löst, und wie Sie sich beteiligen können.

Sichere Container im Blick: Mit Admission Controllers Container Drift erkennen

Fri, 24 Dec 2021 01:00:00 +0000

Bei Box nutzen wir Kubernetes (K8s), um Hunderte von Mikrodiensten zu verwalten, die es uns ermöglichen, Daten im Petabyte-Maßstab zu streamen. Im Rahmen unseres Deployment-Prozesses setzen wir kube-applier als Teil der GitOps-Workflows mit deklarativer Konfiguration und automatisierten Deployments ein. Entwickler deklarieren ihre K8s-Anwendungen in einem Git-Repository, welches eine Code-Überprüfung und automatische Checks erfordert, bevor Änderungen in unseren K8s-Clustern zusammengeführt und angewendet werden können. Mit kubectl exec und ähnlichen Befehlen können Entwickler jedoch direkt mit laufenden Containern interagieren und diese aus ihrem deployten Zustand verändern. Diese Interaktion könnte die Änderungs- und Code-Überprüfungsprozesse, die in unseren CI/CD-Pipelines durchgesetzt werden, untergraben. Zudem erlaubt es, dass solche betroffenen Container langfristig im Produktionsumfeld weiterhin Traffic erhalten.

Sicherheit neu gedacht: Die neuesten Funktionen des Security Profiles Operators v0.4.0

Mon, 20 Dec 2021 01:00:00 +0000

Die Security Profiles Operator (SPO) ist eine maßgebliche Erweiterung für Kubernetes, die die Verwaltung von seccomp, SELinux und AppArmor Profilen erheblich vereinfacht. Wir freuen uns, die Veröffentlichung von v0.4.0 anzukündigen, die viele neue Funktionen, Verbesserungen und Fehlerbehebungen mit sich bringt.

Was ist neu?

Es ist einige Zeit vergangen, seit der letzten Veröffentlichung v0.3.0. In den letzten sechs Monaten haben wir über 290 Commits vorgenommen, um neue Funktionen hinzuzufügen, bestehende zu optimieren und unsere Dokumentation zu überarbeiten.

Speicher-Qualität im Kubernetes: So optimieren Sie Ihre Ressourcen

Mon, 29 Nov 2021 01:00:00 +0000

Kubernetes v1.22, veröffentlicht im August 2021, bringt eine neue Alpha-Funktion mit sich, die die Art und Weise verbessert, wie Linux-Knoten Speicherressourcen verwalten. Diese Neuerung bedeutet insbesondere für Entwickler und DevOps-Teams einen großen Schritt nach vorn in der Verwaltung von Ressourcen.

Was ändert sich konkret für Entwickler/DevOps-Teams?

In früheren Versionen unterstützte Kubernetes keine Qualitätsgarantien für Speicher. Das bedeutete, dass es bei der Vergabe von Speicherressourcen zu Problemen kommen konnte, insbesondere wenn Container ihre Grenzen überschritten. Mit der Einführung von Memory QoS (Quality of Service) können Sie nun sicherstellen, dass wichtige Prozesse immer ausreichend Speicher zugewiesen bekommen.

Docker-Integration in Kubernetes: Was bedeutet die Abschaffung von Dockershim für dich?

Mon, 15 Nov 2021 01:00:00 +0000

Einleitung

Die Kubernetes-Community steht vor einer bedeutenden Veränderung: Die Abschaffung des Dockershim-Components steht bevor. Dieser Teil von Kubernetes, der eine integrierte Nutzung der Docker Engine ermöglicht, wird bald nicht mehr unterstützt. Aber keine Sorge, wir klären, was das für dich und dein Team bedeutet!

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die Deprecation von Dockershim bedeutet, dass Kubernetes-Nutzer, die bisher Docker als Container-Runtime verwendet haben, sich auf alternative Runtimes umstellen sollten. Kubernetes hat bereits die Container Runtime Interface (CRI) entwickelt, die eine nahtlose Integration mit anderen Container-Runtimes ermöglicht. Viele Entwickler und Unternehmen haben diesen Wechsel bereits vollzogen, ohne auf größere Probleme zu stoßen. Dennoch bleibt Dockershim bei vielen Nutzern beliebt, was die Notwendigkeit einer sorgfältigen Planung und Vorbereitung unterstreicht.

Die Rolle von SIG Node: Wie Kubernetes die Interaktion zwischen Pods und Ressourcen optimiert

Thu, 30 Sep 2021 02:00:00 +0000

Einleitung

In Kubernetes ist ein Node die Darstellung einer einzelnen Maschine in Ihrem Cluster. SIG Node ist für diesen wichtigen Node-Komponenten verantwortlich und unterstützt verschiedene Teilprojekte wie Kubelet und Container Runtime Interface (CRI). In diesem Blog haben wir unsere Gespräche mit Elana Hashman (EH) und Sergey Kanzhelev (SK) zusammengefasst, die uns durch die verschiedenen Aspekte der SIG-Mitgliedschaft führen und Einblicke geben, wie andere sich engagieren können.

Zusammenfassung unseres Gesprächs

Könnten Sie uns ein wenig darüber erzählen, was SIG Node macht?

SK: SIG Node ist ein vertikaler SIG, der für die Komponenten verantwortlich ist, die die kontrollierten Interaktionen zwischen Pods und Host-Ressourcen unterstützen. Wir verwalten den Lebenszyklus der Pods, die auf einem Node geplant sind. Der Fokus dieses SIGs liegt darauf, eine breite Palette von Workload-Typen zu ermöglichen, einschließlich solcher mit hardware-spezifischen oder leistungsabhängigen Anforderungen. Dabei halten wir die Isolationsgrenzen zwischen Pods auf einem Node sowie zwischen Pod und Host ein. Dieses SIG verwaltet eine Vielzahl von Komponenten und hat viele externe Abhängigkeiten (wie Container-Runtimes oder Betriebssystemfunktionen), was die Komplexität, mit der wir umgehen, erheblich erhöht. Wir zähmen diese Komplexität und streben kontinuierlich danach, die Zuverlässigkeit der Nodes zu verbessern.

Windows HostProcess Container: Eine neue Ära für Kubernetes-Management

Thu, 19 Aug 2021 02:00:00 +0000

Kubernetes v1.22 hat eine spannende neue Alpha-Funktion für Cluster mit Windows-Knoten eingeführt: HostProcess Container.

HostProcess Container erweitern das Windows-Container-Modell und ermöglichen eine Vielzahl von Szenarien für das Management von Kubernetes-Clustern. Diese Container laufen direkt auf dem Host und verhalten sich ähnlich wie reguläre Prozesse. Mit HostProcess Containern können Nutzer Management-Operationen und -Funktionen, die Hostzugriff erfordern, verpacken und verteilen, während sie die Versionskontrolle und Bereitstellungsmethoden von Containern beibehalten. Dadurch können Windows-Container für verschiedene Szenarien in Bezug auf Geräte-Plugins, Speicher- und Netzwerkmanagement in Kubernetes verwendet werden.

Kubernetes-Release-Zyklus: Was die neue Dreimonatsregel für Dich bedeutet

Fri, 23 Jul 2021 02:00:00 +0000

Am 23. April 2021 hat das Release-Team einen Kubernetes Enhancement Proposal (KEP) verabschiedet, der den Release-Zyklus von vier Releases pro Jahr auf drei Releases pro Jahr umstellt. Diese Entscheidung bringt einige wesentliche Änderungen für die Kubernetes-Community mit sich.

Was ändert sich konkret?

Ab der Kubernetes 1.22-Version wird ein leichtgewichtiges Regelwerk zur Erstellung des Release-Zeitplans genutzt. Die wichtigsten Punkte sind:

Die erste Kubernetes-Version eines Kalenderjahres sollte in der zweiten oder dritten Januarwoche beginnen, um den Beitragenden nach den Feiertagen mehr Zeit zu geben.
Die letzte Kubernetes-Version eines Kalenderjahres sollte bis zur Mitte Dezember abgeschlossen sein.
Ein Kubernetes-Release-Zyklus dauert etwa 15 Wochen.
Die Woche der KubeCon + CloudNativeCon wird nicht als “Arbeitswoche” für SIG Release betrachtet. Das Release-Team hält in dieser Zeit keine Meetings ab und trifft keine Entscheidungen.
Zwischen jedem Release-Zyklus wird eine explizite SIG Release-Pause von mindestens zwei Wochen eingehalten.

Infolgedessen wird Kubernetes künftig drei Releases pro Jahr herausbringen. Die Version 1.23 wird die letzte Veröffentlichung des Kalenderjahres 2021 sein. Diese neue Regelung sorgt für einen sehr vorhersehbaren Release-Zeitplan, was es einfacher macht, kommende Veröffentlichungstermine zu planen:

Wichtige API-Änderungen in Kubernetes 1.22: Das solltest du wissen!

Sat, 17 Jul 2021 02:00:00 +0000

Die Kubernetes-API entwickelt sich ständig weiter, was bedeutet, dass alte APIs regelmäßig reorganisiert oder aktualisiert werden. Mit der Veröffentlichung von Kubernetes 1.22, die für August 2021 geplant ist, stehen einige wichtige Änderungen an. In dieser Version werden mehrere veraltete Beta-APIs entfernt, die durch stabilere Versionen ersetzt wurden. Hier erfährst du, was das konkret für Entwickler und DevOps-Teams bedeutet.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die bevorstehenden API-Entfernungen betreffen alle Beta-APIs, die bereits als veraltet markiert wurden. Diese Änderungen könnten den Workflow und die Kompatibilität in deinen Projekten beeinflussen. Es ist wichtig, dass du die neuen stabilen API-Versionen überprüfst und deine Implementierungen entsprechend anpasst, um eine reibungslose Migration zu gewährleisten.

Jährliche Berichte der Kubernetes-Community: Ein Blick hinter die Kulissen

Thu, 01 Jul 2021 02:00:00 +0000

Die Kubernetes-Community hat einen entscheidenden Schritt zur Verbesserung der Transparenz und Nachverfolgbarkeit ihrer Aktivitäten gemacht. Mit der Einführung der Jährlichen Berichte der Kubernetes-Community für Spezialinteressengruppen (SIGs) und Arbeitsgruppen (WGs) wird es einfacher, die Vitalität und Fortschritte der verschiedenen Gruppen innerhalb des Projekts zu bewerten. Dies ist besonders wichtig, da das Kubernetes-Projekt mit über 100.000 Commits und Tausenden von Mitwirkenden enorm gewachsen ist.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Die traditionellen Methoden zur Berichterstattung über die Aktivitäten in der Kubernetes-Community, wie devstats und GitHub-Daten, waren oft unzureichend und einseitig. Der neue Jahresbericht zielt darauf ab, die menschliche Seite der Beiträge sichtbar zu machen und nicht nur kodierte Änderungen zu erfassen. Dies bedeutet, dass Entwickler und DevOps-Teams nun Zugang zu umfassenderen Informationen haben, die über die üblichen „Hilfe gesucht“- oder „gute erste Aufgabe“-Listen hinausgehen.

Kubernetes 1.21: Endlich stabile Metriken für zuverlässiges Monitoring!

Mon, 26 Apr 2021 02:00:00 +0000

Kubernetes 1.21 bringt mit dem Abschluss des Metrics Stability Frameworks die ersten offiziell unterstützten stabilen Metriken. Diese neuen stabilen Metriken bieten nicht nur Unterstützungsgarantien, sondern auch Sicherheitsmechanismen, wenn Sie auf problematische Metriken stoßen.

Sie können die Liste der stabilen Kubernetes-Metriken hier einsehen.

Was sind stabile Metriken und warum benötigen wir sie?

Eine stabile Metrik ist eine, die aus Sicht des Verbrauchs über mehrere Kubernetes-Versionen hinweg zuverlässig konsumiert werden kann, ohne das Risiko eines Ingestionsfehlers. Die Stabilität von Metriken ist ein kontinuierliches Anliegen der Community. Die Überwachungsinfrastruktur von Clustern geht häufig von der Stabilität bestimmter Control-Plane-Metriken aus. Daher haben wir einen Mechanismus zur Versionierung von Metriken als ordnungsgemäße API eingeführt, mit Stabilitätsgarantien rund um einen formalen Prozess zur Abwertung von Metriken.

Die Zukunft der Kubernetes-Netzwerktechnologie: Gateway API im Fokus

Sun, 25 Apr 2021 02:00:00 +0000

Die Ingress-Ressource gehört zu den vielen Erfolgsgeschichten von Kubernetes. Sie hat ein vielfältiges Ökosystem von Ingress-Controllern hervorgebracht, die in Hunderttausenden von Clustern auf standardisierte und konsistente Weise eingesetzt werden. Diese Standardisierung erleichterte es den Nutzern, Kubernetes zu übernehmen. Fünf Jahre nach der Einführung von Ingress zeigen sich jedoch Anzeichen einer Fragmentierung in verschiedene, aber auffallend ähnliche CRDs und überlastete Anmerkungen. Die gleiche Portabilität, die Ingress so weit verbreitet machte, schränkte auch seine Zukunft ein.

CronJobs in Kubernetes 1.21: Jetzt in voller Blüte!

Sun, 11 Apr 2021 02:00:00 +0000

In Kubernetes v1.21 hat die Ressource CronJob die allgemeine Verfügbarkeit (GA) erreicht. Dies bedeutet nicht nur, dass CronJobs nun stabil und bereit für den produktiven Einsatz sind, sondern auch, dass wir die Leistung seit Kubernetes v1.19 erheblich verbessert haben, durch die Implementierung eines neuen Controllers.

Bereits in Kubernetes v1.20 haben wir einen überarbeiteten v2-Controller für CronJobs eingeführt, der zunächst als Alpha-Feature verfügbar war. In v1.21 verwenden wir nun standardmäßig diesen neueren Controller, und die CronJob-Ressource selbst ist jetzt GA (Gruppenversion: batch/v1).

Fünf Jahre Kubernetes Dashboard: Ein Rückblick auf die Evolution

Fri, 12 Mar 2021 01:00:00 +0000

In Oktober 2020 feierte das Kubernetes Dashboard offiziell sein fünfjähriges Bestehen. Als Hauptprojekt-Maintainer können wir kaum glauben, dass seit unserem ersten Commit so viel Zeit vergangen ist. Doch wenn wir mit etwas Nostalgie zurückblicken, erkennen wir, dass sich in dieser Zeit einiges getan hat. Es wird Zeit, “unser Baby” mit einem kurzen Rückblick zu feiern.

Wie Alles Begann

Die ursprüngliche Idee hinter dem Kubernetes Dashboard war es, eine Web-Oberfläche für Kubernetes bereitzustellen. Wir wollten die Funktionalitäten von kubectl in einer intuitiven Web-UI widerspiegeln. Der Hauptvorteil der Nutzung der UI liegt darin, dass man schnell Dinge erkennen kann, die nicht wie erwartet funktionieren (Überwachung und Fehlersuche). Zudem ist das Kubernetes Dashboard ein großartiger Ausgangspunkt für Nutzer, die neu im Kubernetes-Ökosystem sind.

Datenschutz

Fri, 06 Apr 2012 00:00:00 +0000

Impressum

Fri, 06 Apr 2012 00:00:00 +0000

15-Factor App

Mon, 01 Jan 0001 00:00:00 +0000

AI Crawler Dokumentation

Mon, 01 Jan 0001 00:00:00 +0000

Ansible mit Polycrate

Mon, 01 Jan 0001 00:00:00 +0000

Application Specialist Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Sovereignty Framework

Mon, 01 Jan 0001 00:00:00 +0000

Cloud-native Consulting & Support

Mon, 01 Jan 0001 00:00:00 +0000

Compliance Compass

Mon, 01 Jan 0001 00:00:00 +0000

Compliance Framework

Mon, 01 Jan 0001 00:00:00 +0000

Consulting

Mon, 01 Jan 0001 00:00:00 +0000

Cyber Resilience Act

Mon, 01 Jan 0001 00:00:00 +0000

Digital Operational Resilience Act

Mon, 01 Jan 0001 00:00:00 +0000

Docker Essentials Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Endpoint Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

Allgemeines

Was ist das Fair Use Prinzip bei ayedo?

Wir bei ayedo sind stets bemüht, Ihnen einen sinnvollen und hochwertigen Service zu bieten. Dazu gehört auch ein hilfreicher, umfangreicher und gut erreichbarer persönlicher Support, der über das vertraglich Vereinbarte hinausgeht. Wir glauben fest daran, dass eine kollaborative Zusammenarbeit effektiver ist als das starre Festhalten an Rahmenbedingungen. Unser Fair Use Prinzip ist eine freiwillige Leistung, die solange funktioniert, wie sie nicht einseitig ausgenutzt wird. Sollte dies der Fall sein, behalten wir uns vor, diese Leistung nach eigenem Ermessen zu reduzieren oder einzustellen und unsere Services nur innerhalb der vereinbarten Rahmenbedingungen zu erbringen.

GDPR / DSGVO

Mon, 01 Jan 0001 00:00:00 +0000

Karriere

Mon, 01 Jan 0001 00:00:00 +0000

T-Shaped Individuals

Alles in allem sind wir ein Team aus T-Shaped Individuals - das heißt wir zeichnen uns aus durch ein breites Spektrum an gut ausgeprägten Fähigkeiten und tiefer Expertise in einem oder wenigen ausgewählten Bereichen.

Hast du also einige der für uns wichtigen Skills und Traits und bist nebenbei Experte in einem unserer Handlungsfelder, dann wollen wir dich vermutlich kennenlernen.

Kubernetes in Production Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes On-Premises Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Loadbalancer

Mon, 01 Jan 0001 00:00:00 +0000

Loopback

Mon, 01 Jan 0001 00:00:00 +0000

Managed Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

NIS-2-Richtlinie

Mon, 01 Jan 0001 00:00:00 +0000

Observability

Mon, 01 Jan 0001 00:00:00 +0000

Plattform

Mon, 01 Jan 0001 00:00:00 +0000

Polycrate Development Operations Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Polycrate Essentials Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Polycrate Platform Architecture Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Polycrate Platform Building Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Polycrate Platform Operations Workshop

Mon, 01 Jan 0001 00:00:00 +0000

RSS & JSON Feeds

Mon, 01 Jan 0001 00:00:00 +0000

S3 Storage

Mon, 01 Jan 0001 00:00:00 +0000

Software Compliance Workshop

Mon, 01 Jan 0001 00:00:00 +0000

Unternehmen

Mon, 01 Jan 0001 00:00:00 +0000

Workshops

Mon, 01 Jan 0001 00:00:00 +0000

Die Experten für **Cloud** und **Hosting** on ayedo

Polycrate CLI 0.32.0 released: SDD-Erweiterungen für Agent-Workflows

Spec-Typen nach Conventional Commits

GitOps-Plattformunabhängigkeit durch Polycrate-Automatisierung

GitOps-Plattformunabhängigkeit durch Polycrate-Automatisierung

Polycrate-getriebene Automatisierung für Plattformunabhängigkeit: Deklarative IaC im Fokus

TL;DR

Kubernetes-Plattformen für Cloud-Unabhängigkeit via Polycrate

TL;DR

Zero-Trust-Architektur als Baustein der digitalen Souveränität

TL;DR

Digitale Souveränität ist kein Buzzword – sondern Compliance-Anforderung

Einleitung

Vom politischen Narrativ zur operativen Pflicht

Der Mythos der sicheren Cloud:

Warum Verschlüsselung allein nicht ausreicht

Einleitung

Die Komfortzone der Technik

US-Cloud im Einsatz:

Welche Risiken Unternehmen konkret unterschätzen

Einleitung

Zwischen Komfort und Kontrollverlust

Warum europäische Cloud-Strategien ohne US-Risiko neu gedacht werden müssen

Einleitung

US-Zugriff auf Cloud-Daten:

Warum Kontrolle wichtiger ist als der Serverstandort

Einleitung

Bring-Your-Own-IP (BYOIP) in regulierten Netzen: Souveränität im Routing

Stretched Cluster vs. Multi-Region: Architekturentscheidungen für maximale Resilienz

Failover ohne DNS-Latenz: BGP Anycast für KRITIS-Plattformen

Single Point of Failure Standort: Warum ein Rechenzentrum für KRITIS nicht reicht

Die hybride Data-Plattform: Kubernetes als universelle Abstraktionsschicht

Artifact-Management für Data Science: Versionierung von Modellen und ETL-Jobs mit Harbor

S3-kompatibler Speicher On-Prem: CEPH als skalierbares Backend für Data-Lakes

Analytische Datenbanken im Cluster: ClickHouse und TimescaleDB für High-Volume-Daten

Real-Time Ingestion: Apache Kafka als Event-Streaming-Backbone für die Industrie

Skalierbare Datenpipelines: Apache Airflow im orchestralen Kubernetes-Betrieb

Polycrate API für Teams: Zentrales Monitoring und Remote-Triggering

TL;DR

Polycrate API als Team-Plattform statt Einzel-CLI

Auditierbare Operations: SSH-Sessions und CLI-Aktivitäten mit Polycrate API

TL;DR

Warum Operations-Audit heute Chefsache ist

Action Runs und Polycrate API: Jede Automatisierung mit Audit-Log

TL;DR

Warum Action Runs für Compliance so wichtig sind

GPU-Elastizität ohne Lock-in: Hybrid-Cloud-Strategien für KI-Workloads

Entwicklungsumgebungen on Demand: Reproduzierbare Stacks mit Coder auf Kubernetes

KI im E-Commerce: Lokale LLMs für Textgenerierung sicher betreiben

Souveränes Tracking: Server-Side Google Tag Manager im eigenen Container

Performance-Boost für die Suche: OpenSearch und Typesense im Cluster-Betrieb

Shopware hochverfügbar: Strategien für 99,9 % Erreichbarkeit

Von isolierten Instanzen zur E-Commerce-Plattform: Warum klassisches Hosting nicht skaliert

Effiziente Hintergrund-Prozesse: Wie Redis und RabbitMQ die App entlasten

Die Anatomie einer souveränen Business-Plattform: So greifen Nextcloud, Zammad und Co. ineinander

Mattermost in der Industrie: ChatOps für den Außendienst statt privater Messenger

Dein erster produktiver Polycrate-Workspace: Eine Checkliste für den Start

TL;DR

Warum der erste Workspace zählt

Die Plattform im Modell: Wie Cloud Native KI-Engineering in der Produktion unterstützt

TL;DR

Hauptinhalt

Ankündigung von Kubescape 4.0: Unternehmensstabilität trifft auf die KI-Ära

TL;DR

Hauptinhalt

F5 Erhält Goldmitgliedschaft in der Cloud Native Computing Foundation

TL;DR

Hauptinhalt

Das Polycrate-Ökosystem: PolyHub, API, MCP und die Zukunft der Automatisierung

TL;DR

Das Polycrate-Ökosystem im Überblick

CNCF Backstage-Dokumentation hebt die Projektentwicklung zum globalen Open-Source-Standard für Platform Engineering hervor

TL;DR

Hauptinhalt

Rechtssicher unterschreiben: Digitale Signaturen ohne Datenabfluss nach Übersee

Higress tritt der CNCF bei: Bereitstellung eines Enterprise-Grade AI Gateways und nahtloser Übergang von Nginx Ingress

TL;DR

Hauptinhalt

Zammad vs. Zendesk: Wann sich der Wechsel auf Open-Source-Ticketing lohnt

Digitale Souveränität als Wettbewerbsvorteil im B2B-Vertrieb

Die Experten für Cloud und Hosting on ayedo