Kubernetes verstehen statt nur benutzen: ayedo bietet ab sofort praxisnahe IT-Workshops an
Technologische Unabhängigkeit beginnt mit dem eigenen Know-how. ayedo bietet praxisnahe Workshops zu Kubernetes, Docker, GitOps und Polycrate für IT-Teams.
Operations
Betrieb, Beobachtbarkeit und Stoerungsbeherrschung produktiver Systeme.
48 von 742 Einträgen
Neu bei ayedo: Domains, Anycast DNS und Edge Cloud aus einer Hand
Domains jetzt bei ayedo registrieren: Von der Domain über Anycast DNS bis zu Loadbalancern auf der Edge Cloud – digitale Infrastruktur aus einer Hand.
DDoS-Scrubbing und Resilienz: Schutz bei Überlast
Wie DDoS-Scrubbing, Anycast, getrennte Failure Domains und kontrolliertes Failover Anwendungen bei Überlast schützen.
Weekly Backlog KW 41/2026
Technische Leistungsfähigkeit allein reicht nicht: Diese Ausgabe verbindet KI-Agenten, GitHub-Ausfälle, digitale Souveränität, Edge Cloud, Kubernetes 1.37 und europäische Infrastruktur.
Kubernetes migriert von cgroup v1 zu v2
Was der Wechsel auf cgroup v2 für Clustermanagement, Ressourcenisolierung und Betrieb bedeutet – und warum Europa konsistente Infrastrukturstandards braucht.
JD Group – Eine leistungsfähige Edge Cloud beginnt im Netzwerk
Partner Spotlight: Warum eine leistungsfähige Edge Cloud nicht nur Compute, sondern starke Netzwerkanbindung, Peering, Routing und Redundanz braucht.
Authentik-Föderation in der Praxis: undokumentiertes Verhalten bei Sources, Gruppen und Enrollment
Praxisbericht zur Föderation zweier Authentik-Instanzen per OIDC: undokumentiertes Verhalten bei Gruppen-Sync, Source-Enrollment, Expression Policies und Login-Flows – mit konkreten Mustern, die stattdessen funktionieren.
Proxmox VE Grundlagen Workshop
Proxmox VE Schulung für Administratoren: In 3 Tagen VMs, LXC, Storage, Netzwerk, Rechte, Firewall sowie Backup und Restore praktisch prüfen.
Einführung in Linux Workshop
Linux für Windows-Umsteiger: Terminal, Bash, Berechtigungen und Shell-Scripting in 3 Tagen live online lernen. Eigene Cloud-Umgebung, maximal 8 Teilnehmer.
Weekly Backlog KW 39/2026
Wer trägt eigentlich die Konsequenzen unserer Technologieentscheidungen? Diese Ausgabe über Cloud-Verträge, Cyberabwehr, Standortdaten, KI-Politik, Edge Cloud, Security und Kubernetes.
Weekly Backlog KW 38/2026
Abhängigkeiten sind bequem. Bis sie wehtun. Diese Ausgabe dreht sich um digitale Souveränität, Security, VMware-Exit, Edge Cloud und Kubernetes v1.37.
Building the Edge — Part 8
Der Anfang einer Plattform – warum jede Architektur irgendwann an den Punkt gelangt, an dem sie das Netzwerk neu denken muss.
Building the Edge — Part 7
Gute Plattformen entstehen nicht durch mehr Infrastruktur – sondern durch klar definierte Verantwortlichkeiten.
Building the Edge — Part 6
Eine Verbindung ist noch kein HTTP-Request – warum moderne Edge-Plattformen deutlich früher beginnen, als viele Architekturdiagramme vermuten lassen.
Building the Edge — Part 5
Compute ist nicht die Plattform – warum moderne Anwendungen heute aus zwei Plattformen bestehen.
Building the Edge — Part 4
Warum Hochverfügbarkeit heute im Netzwerk beginnt – Ausfälle sind kein Ausnahmezustand, sondern ein Architekturprinzip.
Building the Edge — Part 3
Eine IP-Adresse kann an drei Orten gleichzeitig existieren – warum Anycast keine Funktion, sondern eine Eigenschaft des Internets ist.
Building the Edge — Part 2
Das Internet kennt keine Anwendungen – warum BGP nicht versucht, den schnellsten Weg zu finden.
level66 – Wenn Hosting nur das Nebenprodukt ist
Partner Spotlight: Warum level66.network mit Peering, hoher Netzwerkkapazität und DDoS-Mitigation ein wichtiger Infrastrukturpartner für die ayedo Edge Cloud ist.
Kubernetes 1.38: Was wir bisher wissen
Kubernetes 1.38 ist für Dezember 2026 geplant. Wir zeigen, welche Features sich abzeichnen und welche Termine für den Release-Zyklus wichtig sind.
Polycrate Platform Operations Workshop
Hands-on Polycrate Workshop für Platform Operators: Actions, Backups, Monitoring, Support-Workflows und App Deployments. Ein Tag intensives Training. Made in Germany.
Digitale Souveränität endet nicht im Rechenzentrum:
Eine Anwendung kann vollständig in Deutschland betrieben werden und trotzdem bei jedem einzelnen Zugriff von US-Infrastruktur abhängig sein.
Building the Edge — Part 1
Die unterschätzte Architektur moderner Anwendungen – warum moderne Anwendungen nicht erst im Rechenzentrum beginnen.
TLS-Zertifikate für öffentliche Kubernetes-Endpunkte
TLS für Kubernetes endet nicht zwingend am Ingress. Eine zentrale TLS-Termination an der ayedo Edge Cloud vereinfacht Zertifikatsverwaltung, WAF-Integration und Traffic-Steuerung. Zusätzliche Verschlüsselung bis zum Cluster schützt jedoch weitere Netzwerkabschnitte. Die richtige Entscheidung hängt von Trust Boundaries, Betriebsmodell, Compliance und gewünschter Fehlerisolierung ab.
Loadbalancer für Kubernetes providerunabhängig betreiben
Ein Kubernetes Service vom Typ `LoadBalancer` bindet den öffentlichen Zugang häufig an den jeweiligen Cloud- oder Infrastrukturprovider. Eine eigenständige Edge-Schicht trennt diese Verantwortung vom Cluster: Routing, Schutz, TLS und Erreichbarkeit werden zentral organisiert, während Kubernetes bei ayedo oder einem anderen Provider betrieben werden kann. Das reduziert Providerabhängigkeiten und vereinfacht Multi-Cloud-Architekturen.
Kubernetes-API-Server sicher über die Edge erreichbar
Ein öffentlich erreichbarer Kubernetes-API-Server muss nicht direkt aus dem Internet auf seine Backend-Adresse zugreifen lassen. Eine vorgeschaltete Edge-Schicht kann Routing, TLS, DDoS-Schutz und Backend-Cloaking übernehmen. Entscheidend bleibt die Trennung zwischen öffentlicher Erreichbarkeit, kryptografischer Authentisierung und tatsächlicher Berechtigung im Cluster.
Security-Entscheidungen an der Edge nachvollziehbar machen
Edge Security Monitoring macht sichtbar, wie sich Schutzmaßnahmen auf den öffentlichen Traffic auswirken. Traffic- und Usage-Statistiken helfen, WAF-Regeln, DDoS-Schutz und exponierte Endpunkte betrieblich zu bewerten. Sie erklären jedoch weder individuelle Angriffe vollständig noch ersetzen sie Logs, Traces und anwendungsnahe Security-Telemetrie.
Multi-Cloud-Security mit zentraler Edge-Architektur
Multi-Cloud Security scheitert häufig nicht an fehlenden Schutzfunktionen, sondern an ihrer verteilten Umsetzung. Eine zentrale Edge-Architektur bündelt öffentlichen Zugang, WAF, DDoS-Schutz, TLS-Terminierung und Routing vor heterogenen Backends. Provider-Unabhängigkeit, eigenes Autonomous System und Aktiv-Aktiv-Betrieb reduzieren dabei Kontroll- und Abhängigkeitspunkte.
DDoS-Schutz an der Edge mit Anwendungslogik koppeln
DDoS-Schutz und Anwendungssicherheit adressieren unterschiedliche Angriffsebenen. Die Edge kann Volumen, Protokolle, Verbindungsraten und Request-Muster bewerten und schädlichen Traffic frühzeitig verwerfen. Ob ein gültiger Request fachlich missbräuchlich ist, lässt sich jedoch meist erst im Anwendungskontext erkennen. Wirksamer Schutz kombiniert daher beide Ebenen mit klaren Zuständigkeiten.
TLS, WAF und Backend: Eine Schichtenarchitektur
Eine belastbare **Security-Schichtenarchitektur** verteilt Schutzaufgaben auf unterschiedliche Ebenen: TLS schützt die Transportverbindung, die WAF bewertet HTTP-Anfragen und das Backend bleibt für Autorisierung, Validierung und Datenschutz verantwortlich. Entscheidend sind die Übergabepunkte zwischen diesen Schichten. Jede Entschlüsselung, Weiterleitung und Protokollumwandlung erzeugt dabei eigene Vertrauens- und Betriebsanforderungen.
Security-Funktionen zwischen Edge und Anwendung verteilen
Security-Funktionen gehören nicht pauschal an einen einzigen Ort. Die Edge eignet sich für Schutzmaßnahmen mit hoher Sichtbarkeit, großem Skalierungsbedarf und standardisierbaren Regeln. Die Anwendung bleibt für Identität, Autorisierung und fachliche Zugriffskontrollen verantwortlich. Entscheidend sind Kontextbedarf, Fehlkonfigurationsrisiko und die Frage, wie früh ein Angriff erkannt und begrenzt werden kann.
Öffentliche Angriffsflächen systematisch reduzieren
Eine öffentliche Angriffsfläche entsteht nicht nur durch einzelne Schwachstellen, sondern durch die gesamte Internet-exponierte Architektur. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination und Backend Cloaking müssen deshalb als zusammenhängende Security-Zone vor den Backends betrachtet werden. Entscheidend ist, welcher Traffic die Backends überhaupt erreicht und unter welchen Bedingungen.
TLS Termination an der Edge architektonisch planen
TLS Termination an der Edge verkürzt den Weg von Client zu geschütztem Einstiegspunkt, verschiebt aber Verantwortlichkeiten. Zertifikate, Vertrauensgrenzen und Backend-Verbindungen müssen deshalb getrennt geplant werden. Die zentrale Frage lautet nicht, ob TLS am öffentlichen Eingang endet, sondern welche Verbindungen danach weiterhin verschlüsselt und wie ihre Identitäten geprüft werden.
DDoS-Schutz an der Edge und seine Grenzen im Backend
DDoS-Schutz an der Edge reduziert volumetrischen und netzwerkseitigen Angriffsdruck, bevor er die öffentliche Infrastruktur eines Unternehmens erreicht. Scrubbing schützt damit den Eingang zu Anwendungen und APIs. Es ersetzt jedoch weder Backend-Sicherheit noch Authentisierung, Ressourcenlimits oder fachliche Prüfungen gegen missbräuchliche Nutzung.
Anycast und Backend-Failover im Aktiv-Aktiv-Betrieb
Aktiv-Aktiv-Failover entsteht nicht durch einen einzelnen Mechanismus, sondern durch das Zusammenspiel von Anycast, verteilten Edge-PoPs, belastbaren Health Checks und dynamischer Backend-Auswahl. Fällt ein Backend aus, muss die Edge den Zustand erkennen und neue Verbindungen gezielt an verfügbare Backends verteilen, ohne einen zentralen Primärpfad vorauszusetzen.
Netzwerk-Routing und Application-Routing trennen
Netzwerk-Routing und Application-Routing lösen unterschiedliche Probleme. Anycast und Layer 4 bestimmen, wie Traffic einen Edge-Einstieg erreicht und zu welchem Transportziel weiterläuft. Layer 7 entscheidet dagegen anhand von Hostnames, Pfaden oder HTTP-Eigenschaften, welcher Service die Anfrage verarbeitet. Diese Ebenen müssen getrennt modelliert werden, damit Architektur, Betrieb und Fehlersuche beherrschbar bleiben.
Proxy Protocol im Backend-Pool korrekt einsetzen
Proxy Protocol überträgt Verbindungsinformationen aus einem Proxy- oder Loadbalancing-Layer an das Backend. Damit können Anwendungen die ursprüngliche Client-IP und weitere Transportdaten auswerten. Voraussetzung sind ein abgestimmtes Protokoll, kompatible Listener und eine konsistente Konfiguration im gesamten Backend-Pool.
TLS Termination an der Edge: Routing sicher gestalten
TLS Termination beendet die äußere HTTPS-Verbindung an der Edge und schafft den technischen Übergabepunkt für anwendungsbezogenes Routing. Damit werden Host-, Pfad- und Header-Regeln möglich. Die Architektur muss jedoch klar festlegen, welche Sicherheits- und Routingaufgaben die Edge übernimmt und welche Kontrolle beim Backend verbleibt.
Failover über mehrere Provider mit der Edge Cloud
Providerunabhängiges Failover trennt den öffentlichen Traffic-Eingang von der Compute-Infrastruktur. Die Edge übernimmt Anycast, DNS, Schutz, TLS und Health Checks, während Backends oder Kubernetes-Cluster bei unterschiedlichen Providern betrieben werden. Backend Cloaking verhindert dabei, dass Failover-Architekturen durch öffentlich erreichbare Ursprungsdienste unnötig exponiert werden.
Failure Domains im Edge-Design für öffentliche Dienste
Failover ist nur dann belastbar, wenn Ersatzpfade nicht von derselben Ausfallgrenze abhängen wie der Primärpfad. Backend, Cluster, Provider, Netzwerk und Edge müssen deshalb getrennt bewertet werden. Eine Multi-PoP-Architektur mit eigenem Autonomous System und Aktiv-Aktiv-Betrieb erweitert den Designraum für Hochverfügbarkeit, ersetzt aber keine saubere Abhängigkeitenanalyse.
Aktiv/passiv oder Aktiv-Aktiv: Failover richtig wählen
Aktiv-passiv Failover ist nicht grundsätzlich einfacher, Aktiv-Aktiv nicht automatisch überlegen. Entscheidend sind Umschaltzeit, Datenkonsistenz, Wartungsanforderungen und die Fähigkeit der Anwendung, parallele Verarbeitung zu unterstützen. Die Edge Cloud verteilt öffentlichen Traffic unabhängig davon, welches Modell im Backend verwendet wird, und muss Health Checks, Routing und Failover zuverlässig abbilden.
Aktiv-Aktiv-Failover: Lastverteilung und Konsistenz
Aktiv-Aktiv-Failover verteilt produktiven Traffic gleichzeitig auf mehrere Backends. Dadurch bleiben einzelne Ausfälle für Nutzer und Clients oft transparent. Der Preis ist zusätzlicher Aufwand: Sitzungen, Datenänderungen und Nebenwirkungen müssen über die beteiligten Instanzen hinweg konsistent oder bewusst fehlertolerant gestaltet werden.
Backend-Pools im Failover: Zustände, Routing und Recovery
Backend-Pools sind kein statisches Verzeichnis von Zielsystemen, sondern ein Betriebsmodell für Lastverteilung, Zustandsbewertung und kontrolliertes Recovery. Failover beginnt mit Health Checks, endet aber erst, wenn Rückfall, Konsistenz und erneute Belastbarkeit des Primärpools geprüft sind. Ohne definierte Zustandsübergänge kann die Rückkehr zum Regelbetrieb neue Ausfälle erzeugen.
Routing-basiertes Failover für APIs und Webanwendungen
Routing-basiertes Failover entscheidet an der Edge, welcher erreichbare Backend-Pool eine Anfrage oder Verbindung erhält. Im Gegensatz zu DNS-Failover muss der Client nicht erst einen neuen Zielnamen auflösen. Das verkürzt den Reaktionsweg, macht Gesundheitszustände unmittelbar nutzbar und trennt öffentlichen Zugang von der eigentlichen Compute-Infrastruktur.
Aktiv-Aktiv-Architektur für hochverfügbare Plattformen
Eine Aktiv-Aktiv-Architektur verteilt Edge-Funktionen über mehrere PoPs, statt einen Standort als passiven Ersatz vorzuhalten. Dadurch werden Failover und Wartung zu laufenden Betriebsprozessen. Für interne Plattformdienste bedeutet das: Der öffentliche Zugang, Schutzfunktionen und Routing müssen selbst ausfallsfähig sein – unabhängig davon, wo die Backends betrieben werden.