Rechenlösungen in der Cloud

Eine virtuelle Maschine (VM) ist ein in Software definierter Computer. Sie hat virtuelle Prozessoren, Arbeitsspeicher, Datenträger, eine Netzwerkverbindung und ein eigenes Betriebssystem. Ein Hypervisor teilt einen physischen Server unter VMs auf und isoliert sie voneinander. Eine laufende Cloud-VM heißt auch Instanz.

Wähle die Ressourcen

Die zentralen Dienste sind Amazon EC2, Azure Virtual Machines und Google Compute Engine. Bei jedem mietest du Infrastruktur; du verwaltest das Betriebssystem und die Anwendung. Das ist Infrastructure as a Service (IaaS).

Beim Start einer VM triffst du mehrere zusammenhängende Entscheidungen:

• Standort: eine Region und, wo angeboten, eine Verfügbarkeitszone.
• Abbild: eine Vorlage mit Betriebssystem und vorinstallierter Software. AWS nennt sie Amazon Machine Image (AMI); Azure und Google bieten öffentliche und eigene Abbilder an.
• Größe: die vCPUs, der Arbeitsspeicher und die zugehörige Kapazität. Eine vCPU ist die der VM zugewiesene Recheneinheit.
• Datenträger: persistenter Speicher, von dem das Betriebssystem startet.
• Netzwerk: eine Schnittstelle in einem Subnetz und Regeln für den Datenverkehr. Eine öffentliche IP-Adresse ist optional.

AWS verwendet EBS-Volumes, VPC-Subnetze und Sicherheitsgruppen. Azure verwendet verwaltete Datenträger, VNet-Subnetze und Netzwerksicherheitsgruppen. Google verwendet persistente Datenträger, VPC-Subnetze und Firewallregeln. Die Namen unterscheiden sich, die Ressourcen erfüllen aber vergleichbare Aufgaben.

Verfolge eine Startentscheidung

Ein Team braucht einen Linux-Webserver in Frankfurt. Es wählt die Region Europe (Frankfurt), ein Ubuntu-AMI und m7g.large mit 2 vCPUs und 8 GiB Arbeitsspeicher. Es ergänzt ein EBS-Startvolume mit 30 GiB und verbindet die VM mit einem VPC-Subnetz. Seine Sicherheitsgruppe erlaubt HTTPS über Port 443 aus dem Internet und SSH über Port 22 nur aus dem Büronetzwerk. Das Abbild liefert den Ausgangspunkt für die Software; die Größe liefert Rechenkapazität; die Verkehrsregeln entscheiden, wer eine Verbindung herstellen kann.

Verfolge Lebenszyklus und Rechnung

Eine VM wird erstellt, läuft, kann angehalten und gestartet werden und wird schließlich gelöscht. Rechenkosten fallen an, solange sie für den Betrieb zugeordnet ist, auch wenn die CPU-Auslastung nahe null liegt. Das Anhalten beendet normalerweise die Rechenkosten, aber beibehaltene Datenträger und reservierte öffentliche IP-Adressen können weiterhin Geld kosten. Prüfe bei Azure auf „Stopped (deallocated)“: Ein Herunterfahren innerhalb des Gastbetriebssystems kann die VM im Zustand „Stopped“ belassen, wobei die Rechenleistung weiterhin berechnet wird.

Temporäre lokale Datenträger unterscheiden sich von persistenten Startdatenträgern. AWS Instance Store, temporäre Azure-Datenträger und Google Local SSD halten Daten auf dem physischen Host; beim Anhalten, Verschieben oder Aufheben der Zuordnung einer VM können sie verloren gehen. Lege Dateien, die erhalten bleiben müssen, in persistentem Speicher ab. Prüfe nach dem Löschen einer VM die verbliebenen kostenpflichtigen Ressourcen. Eine Sicherheitsgruppe allein verursacht keine eigenständige Gebühr, während ein nicht gelöschter Datenträger weiterhin Kosten verursachen kann.

Erkenne die Wartungszuständigkeit

Der Anbieter wartet das Rechenzentrum, die physische Hardware und den Hypervisor. Du spielst Patches für das Gastbetriebssystem ein, aktualisierst installierte Software, schützt Daten und verwaltest Zugriffe und Firewalleinstellungen. Das Mieten einer VM überträgt das Einspielen von Patches für das Gastbetriebssystem nicht auf den Anbieter.

Ein dedizierter Host reserviert einen physischen Server für deine Nutzung und ist für Lizenzen nützlich, die an physische Kerne gebunden sind. Eine Bare-Metal-Instanz stellt Hardware ohne Hypervisor-Schicht bereit. Azure Virtual Desktop und Amazon WorkSpaces übertragen dagegen in der Cloud gehostete Desktops an die Geräte der Benutzer.

Eine Instanzfamilie legt das Verhältnis von Rechenleistung, Arbeitsspeicher, Speicher und Beschleunigern fest. Ihre Größe bestimmt, wie viel du von diesen Ressourcen erhältst. Wähle die Familie nach dem wichtigsten Bedarf der Workload und dann eine Größe, die alle Anforderungen erfüllt.

Erkenne die wichtigsten Familien

Schneller lokaler Speicher macht Daten nicht persistent. Auch für eine Workload mit speicheroptimierten Instanzen brauchst du einen Plan für Daten, die den Ausfall des Hosts überstehen müssen.

Lies den Namen

In m7g.large bedeutet m universell, 7 ist die Generation, g steht für AWS Graviton und large ist die Größe. Dieselbe Familie wächst von 2 vCPUs und 8 GiB bei large auf 4 vCPUs und 16 GiB bei xlarge und dann auf 8 vCPUs und 32 GiB bei 2xlarge.

In Azures Standard_D4s_v5 ist D die Familie, 4 die Anzahl der vCPUs, s steht für die Unterstützung von Premium-SSD und v5 ist die Version. Googles e2-standard-4 nennt die E2-Serie, das Standard-Arbeitsspeicherverhältnis und 4 vCPUs. Eine vCPU ist oft ein Hardware-Thread; bei Graviton ist sie ein ganzer Kern. Betrachte nicht die vCPU jedes Anbieters als identischen physischen Kern.

Gehe eine Größenwahl durch

Eine interne Berichtsanwendung braucht bei Spitzenlast 2 vCPUs und 6 GiB. Vergleiche diese AWS-Größen:

• c7g.large: 2 vCPUs und 4 GiB; der Arbeitsspeicher reicht nicht aus.
• m7g.large: 2 vCPUs und 8 GiB; beide Anforderungen sind erfüllt, mit 2 GiB Reserve.
• r7g.large: 2 vCPUs und 16 GiB; sie liefert viel mehr Arbeitsspeicher, als diese Anwendung braucht.

Die universelle Größe ist der sinnvolle Ausgangspunkt. Ihr Arbeitsspeicher pro vCPU beträgt $8÷2=4$ GiB. Die rechenoptimierte und die arbeitsspeicheroptimierte Wahl bieten jeweils 2 beziehungsweise 8 GiB pro vCPU. Googles E2-Typen highcpu, standard und highmem mit 4 vCPUs unterscheiden sich ebenso im Arbeitsspeicher: 4 GB, 16 GB und 32 GB.

Rightsizing bedeutet, die tatsächliche Nutzung zu messen und die Wahl anzupassen. Prüfe vor einer Verkleinerung neben der CPU- auch die Arbeitsspeicher-, Datenträger- und Netzwerknutzung. AWS Compute Optimizer, Azure Advisor und Googles Maschinentypempfehlungen können helfen. Die Größenänderung einer bestehenden VM erfordert ein Anhalten oder einen Neustart. Plane daher eine Unterbrechung für eine Anwendung auf einem einzelnen Server ein.

Unterscheide Leistungsspitzen von Unterbrechungen

Burstfähige AWS-T-, Azure-B- und Google-E2-Typen mit gemeinsam genutzten Kernen eignen sich für gering ausgelastete Workloads mit kurzen Spitzen. AWS T und Azure B sammeln CPU-Guthaben unterhalb einer Grundleistung und verbrauchen es oberhalb davon. Ist das Guthaben aufgebraucht, kehren Azure B und AWS T im Standardmodus zur Grundleistung zurück; aktuelle AWS-T-Typen verwenden standardmäßig den unbegrenzten Modus und können zusätzliche CPU-Leistung berechnen.

Spot-VMs nutzen freie Kapazität, die der Anbieter kurzfristig zurückfordern kann. Sie passen zu neu startbarer Stapelverarbeitung mit gespeichertem Fortschritt. Eine einzelne Produktionsdatenbank passt schlecht dazu. Googles ältere unterbrechbare VMs haben außerdem eine maximale Lebensdauer von 24 Stunden; diese Grenze ist keine bestimmende Regel für moderne Spot-VMs.

Ein Dienst steht vor zwei verschiedenen Problemen: mehr eingehender Arbeit und ausfallender Hardware. Skalierung verändert die Kapazität. Hochverfügbarkeit hält den Dienst nutzbar, wenn Teile ausfallen. Eine Architektur kann ein Problem lösen und das andere ungelöst lassen.

Ändere Größe oder Anzahl

Vertikale Skalierung verändert die Größe einer Maschine: Aus 2 vCPUs und 8 GiB werden zum Beispiel 8 vCPUs und 32 GiB. Hochskalieren fügt Ressourcen hinzu; Herunterskalieren entfernt sie. So lässt sich einer bestehenden Anwendung direkt mehr Kapazität geben, aber die Maschine muss meist neu starten, die größte Größe ist begrenzt und die Maschine bleibt eine einzelne mögliche Ausfallstelle.

Horizontale Skalierung verändert die Anzahl der Kopien. Aus drei Webservern können neun werden und danach wieder drei. Horizontales Hochskalieren fügt Instanzen hinzu; horizontales Herunterskalieren entfernt sie. Ein Load Balancer verteilt Webanfragen, während Hintergrundprozesse Aufträge aus einer gemeinsamen Warteschlange übernehmen können. Die Anwendung muss unterstützen, dass mehrere Kopien gemeinsam nutzbare Arbeit leisten. Eine gemeinsam genutzte Datenbank kann weiterhin den Datendurchsatz begrenzen oder ausfallen, selbst wenn viele Webserver funktionsfähig bleiben.

Skalierbarkeit ist die Fähigkeit, durch Hinzufügen von Ressourcen mehr Arbeit zu bewältigen. Elastizität ist das automatische, zeitnahe Wachstum und Schrumpfen bei verändertem Bedarf. Ein Shop, der automatisch von 4 Servern nachts auf 20 während einer Verkaufsaktion wechselt, ist elastisch. Eine feste Gruppe mit Reservekapazität kann hochverfügbar sein, ohne elastisch zu sein.

Mache Kopien ersetzbar

Eine zustandslose Anwendungsinstanz hält keine einmaligen Daten vor, die eine spätere Anfrage braucht. Speichere Warenkörbe, Sitzungen und hochgeladene Dateien in einer gemeinsamen Datenbank, einem Cache oder einem Speicherdienst. Dann kann eine Anfrage jede Instanz erreichen, und beim horizontalen Herunterskalieren kann eine entfernt werden, ohne dass die Warenkörbe ihrer Benutzer verloren gehen.

Ein Warenkorb zum Beispiel, der nur im Arbeitsspeicher eines Webservers liegt, verschwindet, wenn dieser Server beendet wird. Den Benutzer durch Sitzungsaffinität auf diesem Server zu halten, schützt den Warenkorb nicht vor dessen Ausfall. Den Warenkorb in gemeinsamen Speicher zu verschieben, verändert, was sicher entfernt werden kann.

Halte nach einem Zonenausfall genügend Kapazität vor

Verfügbarkeitszonen sind getrennte Standorte innerhalb einer Region mit unabhängiger Stromversorgung, Kühlung und Vernetzung. Die Verteilung von Instanzen auf Zonen schützt vor dem Ausfall einer ganzen Zone. Mehrere Instanzen in einer Zone teilen weiterhin deren Risiko.

Angenommen, eine Anwendung muss nach dem Ausfall einer beliebigen von 3 Zonen die Kapazität von 4 Instanzen behalten. Die beiden verbleibenden Zonen müssen jeweils 2 Instanzen liefern:

Betreibe 2 Instanzen in jeder Zone, insgesamt 6. Beim Ausfall einer beliebigen Zone bleiben 4. Das ist Reservekapazität für einen Ausfall und keine Erhöhung des normalen Bedarfs der Workload. Ein Load Balancer leitet Anfragen an die verbleibenden Instanzen; auch jeder gemeinsam genutzte Datendienst braucht eine geeignete Verfügbarkeit.

Erkenne Azure-Verfügbarkeitsgruppen

Eine Verfügbarkeitsgruppe verteilt VMs innerhalb eines Rechenzentrums auf Hardware-Fehlerdomänen und Wartungs-Updatedomänen. Eine Fehlerdomäne teilt sich Hardware wie Stromversorgung und Netzwerk-Switches. Gruppen unterstützen bis zu 3 Fehlerdomänen; Updatedomänen sind standardmäßig 5 und können bis zu 20 erreichen. Sie verringern die Risiken durch Rack-Ausfälle und geplante Neustarts. Zonen begegnen dem größeren Risiko, dass ein ganzer Rechenzentrumsstandort ausfällt.

Automatische Skalierung fügt bei verändertem Bedarf Instanzen hinzu und entfernt sie. Amazon EC2 Auto Scaling verwendet Auto Scaling-Gruppen, Azure verwendet Virtual Machine Scale Sets mit Regeln für die automatische Skalierung und Google verwendet verwaltete Instanzgruppen mit einem Autoscaler.

Beginne mit einer wiederholbar einsetzbaren Vorlage

Eine neue Instanz braucht dasselbe Abbild, dieselbe Größe, dieselben Netzwerkeinstellungen und Startanweisungen wie die anderen. AWS verwendet eine Startvorlage, Azure ein VM-Modell der Skalierungsgruppe und Google eine Instanzvorlage. Eine Änderung, die von Hand innerhalb einer laufenden VM vorgenommen wird, verschwindet beim Ersetzen dieser VM, sofern sie nicht in der wiederholbaren Einrichtung enthalten ist.

Die Gruppe hat drei Kapazitätseinstellungen:

• Minimum: die Untergrenze, die die Gruppe aufrechterhält.
• Gewünscht: die Anzahl, die sie aktuell auszuführen anstrebt.
• Maximum: die Obergrenze, die sie nicht überschreiten darf.

Bei Minimum 2, gewünschter Kapazität 4 und Maximum 10 strebt die Gruppe 4 Instanzen an. Richtlinien können die gewünschte Kapazität zwischen 2 und 10 verändern. Das Maximum erlaubt Wachstum; es auf 10 zu setzen, führt nicht von selbst 10 VMs aus und berechnet sie nicht. Es begrenzt die Instanzanzahl, nicht alle Kosten der Anwendung.

Wähle den Auslöser einer Änderung

Zielverfolgung versucht, eine Metrik nahe einem Zielwert zu halten, etwa die durchschnittliche CPU-Auslastung bei 50 %. Stufenweise oder regelbasierte Skalierung ändert die Kapazität beim Überschreiten eines Schwellenwerts, etwa indem sie 2 Instanzen hinzufügt, nachdem die CPU-Auslastung 5 Minuten lang über 70 % geblieben ist. Geplante Skalierung legt die Kapazität zu bekannten Zeiten fest. Prädiktive Skalierung prognostiziert den Bedarf anhand früherer Muster und stellt im Voraus Kapazität bereit.

Eine tägliche Spitze um 08:00 Uhr spricht dafür, Instanzen vor 08:00 Uhr bereitzustellen. Wartest du auf einen Alarm wegen hoher CPU-Auslastung, ist die Spitze bereits da, während die zusätzlichen VMs noch starten.

Ermittle die Kapazität bei Zielverfolgung

Vier identische Instanzen erreichen durchschnittlich 80 % CPU-Auslastung, und das Ziel liegt bei 50 %. Für eine vereinfachte Schätzung bei konstanter Last summiere zuerst die Arbeit in Instanz-Prozentpunkten:

Dividiere durch den Zielwert pro Instanz:

Runde auf 7 Instanzen auf, weil bei 6 der Durchschnitt über dem Ziel bliebe. Bei 7 beträgt die Schätzung $320÷7\approx \mathrm{45,7}\mathrm{\%}$. Liegt das Maximum der Gruppe bei 6, stoppt sie dort und erreicht durchschnittlich etwa 53,3 %.

Unterscheide Bereitschaft von Fehlerbehebung

Eine VM braucht Zeit zum Hochfahren, Ausführen ihrer Startaufgaben und Bestehen der Zustandsprüfungen. Die Aufwärmphase verhindert, dass unvollständige Messwerte einer neuen Instanz eine Skalierungsentscheidung verzerren. Eine Abklingzeit begrenzt schnelle Änderungen in beide Richtungen.

Skalierungsgruppen können auch ausgefallene VMs ersetzen, um die gewünschte Kapazität wiederherzustellen. Prüfungen auf Anwendungsebene und Reparaturaktionen müssen konfiguriert werden: Eine VM kann laufen, während ihre Webanwendung defekt ist. Bei Azure kann eine Reparaturaktion neu starten, aus dem Abbild neu erstellen oder ersetzen; Google nennt die Wiederherstellung automatische Selbstheilung. Ein Load Balancer kann eine defekte Anwendung erkennen, aber die Skalierungsgruppe muss so konfiguriert sein, dass sie diese Information für die Reparatur nutzt.

Horizontales Herunterskalieren entfernt Instanzen. Bewahre Protokolle zentral und dauerhafte Daten außerhalb ihrer lokalen Dateien auf, damit beim Entfernen einer funktionsfähigen Kopie keine einmaligen Informationen verloren gehen.

Ein Load Balancer gibt Clients eine Eingangsadresse und leitet eingehenden Datenverkehr an funktionsfähige Server weiter. AWS nennt die Servergruppe Zielgruppe; Azure verwendet Backend-Pool; Google verwendet Backend-Dienst. Clients brauchen keine neue Adresse, wenn sich die Gruppe ändert.

Leite Datenverkehr und erkenne Ausfälle

Eine Zustandsprüfung testet ein Ziel wiederholt, zum Beispiel durch eine Anfrage an /health alle 10 Sekunden. Nach genügend fehlgeschlagenen Prüfungen wird das Ziel als fehlerhaft markiert und erhält keinen neuen Datenverkehr, bis es wieder eine Prüfung besteht. Die Erkennung dauert, weil die Prüfungen in Abständen laufen.

Weiterleitung und Reparatur sind verschiedene Aufgaben. Der Load Balancer sendet keine neuen Anfragen mehr an ein ausgefallenes Ziel. Eine Skalierungsgruppe oder ein Administrator repariert oder ersetzt diesen Server. Ein Load Balancer allein fügt keine Verarbeitungskapazität für die Anwendung hinzu.

Das Round-Robin-Verfahren wählt funktionsfähige Ziele der Reihe nach. Die Auswahl nach den wenigsten Verbindungen oder wenigsten offenen Anfragen bevorzugt das Ziel mit weniger laufender Arbeit. Hashbasiertes Routing ordnet Verbindungsdaten einschließlich Adressen und Ports einem Ziel zu. Eine Verbindung bleibt zusammen, aber eine neue Verbindung desselben Benutzers kann anderswo landen.

Sitzungsaffinität, auch Sticky Sessions genannt, hält die Anfragen eines Benutzers auf einem Server. Sie kann eine Anwendung mit lokalen Sitzungen unterstützen, verteilt den Datenverkehr aber ungleichmäßiger und lässt Sitzungen beim Ausfall dieses Servers ungeschützt. Gemeinsamer Sitzungsspeicher ermöglicht es anderen funktionsfähigen Servern, die Arbeit des Benutzers fortzusetzen.

Berechne die Wirkung eines Serverausfalls

Drei funktionsfähige Server teilen sich 900 Anfragen pro Minute gleichmäßig. Jeder bearbeitet:

Ein Server besteht seine Zustandsprüfungen nicht mehr. Dieselbe Arbeit geht nun an zwei:

Kann jeder nur 400 Anfragen pro Minute bearbeiten, bleibt trotz Weiterleitung an funktionsfähige Server eine Überlastung. Die Gruppe braucht Reservekapazität oder mehr Instanzen. Automatische Skalierung verändert die Kapazität; Lastverteilung verteilt sie.

Wähle die passende Schicht für die Weiterleitung

Ein Dienst auf Schicht 7 kann auch TLS terminieren, also HTTPS am Einstiegspunkt entschlüsseln, und mit einer Web Application Firewall zusammenarbeiten. Ein Dienst auf Schicht 4 prüft keinen HTTP-Pfad, um sein Backend auszuwählen. Prüfe, welche Transportprotokolle ein bestimmtes Produkt unterstützt.

AWS Elastic Load Balancing bietet Application Load Balancer auf Schicht 7, Network Load Balancer auf Schicht 4 und Gateway Load Balancer für Netzwerk-Appliances innerhalb einer Region. Azure Load Balancer arbeitet auf Schicht 4; Application Gateway ist regional auf Schicht 7; Front Door bietet einen globalen Einstiegspunkt auf Schicht 7. Google Cloud Load Balancing bietet Application und Network Load Balancer in regionalen und globalen Ausführungen.

Verbinde Weiterleitung und Skalierung

Ist die Integration konfiguriert, melden sich neue Gruppeninstanzen als Ziele an und erhalten Datenverkehr, sobald sie funktionsfähig sind. Beim Entfernen ermöglicht Connection Draining, dass aktive Anfragen abgeschlossen werden, bevor ein Ziel verschwindet. Eine Bereitstellung über mehrere Zonen leitet bei einem Ausfall an funktionsfähige Zonen weiter, sofern diese genügend Kapazität haben. Schon zwei Server profitieren von diesem gemeinsamen Einstiegspunkt und der zustandsabhängigen Weiterleitung.

Ein Container führt eine Anwendung und ihre Abhängigkeiten als isolierten Prozess auf einem Host aus. Indem du ihre Bibliotheken und ihre Laufzeitumgebung mitverpackst, lässt sich die getestete Software in der Produktion reproduzierbar ausführen.

Image, Containerregistrierung und laufende Kopie

Ein Image ist die schreibgeschützte Vorlage; eine Containerregistrierung speichert und verteilt Images; ein Container ist eine laufende Kopie. Amazon ECR, Azure Container Registry und Google Artifact Registry bieten Containerregistrierungen an. Die Open Container Initiative definiert Standardformate für Images; Docker trug dazu bei, ihre Nutzung zu verbreiten.

Ein Team verpackt zum Beispiel seine Python-Bestell-API als orders-api:1.4, testet sie, überträgt sie in eine Containerregistrierung und startet aus diesem Image 3 Produktionscontainer. Umgebungseinstellungen und der Zugriff auf externe Dienste müssen weiterhin konfiguriert werden.

Teile einen Betriebssystemkern statt ein Gastbetriebssystem zu starten

Jede VM enthält ein vollständiges Gastbetriebssystem hinter einem Hypervisor. Container teilen sich den Betriebssystemkern des Hosts, der Ressourcen und Prozesse verwaltet. Sie müssen weniger Software mitführen und starten: Images sind oft mehrere zehn oder hundert Megabyte groß, und der Start dauert Sekunden oder weniger. VM-Abbilder sind häufig mehrere Gigabyte groß und brauchen Minuten zum Hochfahren. Ein Host kann daher mehr Container als vollständige VMs ausführen.

Das Teilen wirkt sich auch auf die Isolation aus. Ein Fehler im Betriebssystemkern des Hosts kann mehrere Container betreffen, während getrennte Gastbetriebssystemkerne VMs stärker voneinander abgrenzen. Linux-Container brauchen einen Linux-Kern; Windows-Container brauchen Windows. Das Image muss auch zur Prozessorarchitektur passen, etwa x86 oder Arm. Container laufen häufig auf Cloud-VMs.

Ersetze Software und bewahre Daten auf

Aktualisiere einen Container, indem du ein korrigiertes Image erstellst und alte Kopien ersetzt. Ein von Hand eingespielter Patch verschwindet beim Ersetzen und lässt andere Replikate unverändert.

Dasselbe gilt für Laufzeitdateien in der beschreibbaren Schicht. Eine dort erstellte Rechnung muss vor dem Ersetzen auf einem persistenten Volume oder in einem Speicherdienst gesichert werden. Die Containerregistrierung bewahrt Anwendungspakete auf, keine Dokumente, die laufende Container erstellen.

Trenne Dienste, wenn es hilft

Ein Monolith wird als eine Einheit bereitgestellt. Microservices teilen eine Anwendung in über das Netzwerk verbundene Dienste auf, die getrennt bereitgestellt und skaliert werden. Ein Shop kann Container für den Zahlungsdienst hinzufügen, ohne weitere Kopien des Katalogdienstes hinzuzufügen.

Ein Orchestrator platziert Container auf Hosts, startet ausgefallene Kopien neu, skaliert sie, stellt Versionen bereit und verbindet Dienste. Kubernetes übernimmt dies ebenso wie einfachere verwaltete Containerdienste. Container brauchen kein Kubernetes.

Kubernetes stellt Container auf einer Gruppe von Maschinen bereit und verwaltet sie. Diese Gruppe heißt Cluster. Kubernetes ist quelloffen, entstand bei Google und wird von der Cloud Native Computing Foundation gepflegt. Dieselbe Plattform kann in verschiedenen Clouds und privaten Rechenzentren laufen.

Verstehe die Teile des Clusters

Die Steuerungsebene speichert die Konfiguration, plant Arbeit ein und koordiniert den Cluster. Worker-Knoten, meist VMs, stellen Rechenleistung und Arbeitsspeicher bereit, die Container nutzen.

Ein Pod ist die kleinste Einheit, die Kubernetes einplant. Er enthält einen oder mehrere Container, die sich eine Netzwerkadresse teilen und gemeinsam auf einem Knoten bleiben. Ein Pod ist keine separate VM. Mehrere Pods können sich denselben Worker-Knoten teilen, wenn ihr Ressourcenbedarf darauf Platz findet.

Du legst einen Sollzustand fest: zum Beispiel 3 Replikate von orders-api:1.4. Kubernetes bemüht sich, 3 Pods am Laufen zu halten. Fällt ein Pod aus, erstellt es einen Ersatz; nach dem Ausfall eines Knotens können Ersatz-Pods auf verbleibenden Knoten mit verfügbarer Kapazität laufen. Ein Kubernetes-Service bietet einen stabilen Namen und eine stabile Adresse, um Pods zu erreichen, auch wenn sich deren einzelne Adressen ändern.

Skaliere Pods und Maschinen getrennt

Ein Horizontal Pod Autoscaler (HPA) ändert die Pod-Anzahl anhand von Metriken wie dem CPU-Bedarf. Ein Cluster Autoscaler ändert die Knotenkapazität, wenn Pods keinen Platz finden oder Knoten nicht mehr gebraucht werden. Pods hinzuzufügen, ohne Platz für ihre Ausführung zu haben, erzeugt ausstehende Arbeit und keine zusätzliche Verarbeitungskapazität.

Angenommen, jeder Pod fordert 0,5 vCPU an und jeder Knoten hat 2 vCPUs für Pods verfügbar. Ignoriere in diesem Beispiel andere Ressourcenbegrenzungen. Ein Knoten kann aufnehmen:

Erhöht der HPA die gewünschte Anzahl auf 10 Pods, nehmen zwei Knoten nur 8 auf. Der Bedarf beträgt:

Runde auf 3 Knoten auf. Der dritte Knoten bietet Platz für die letzten 2 Pods. Verwende die für Pods verfügbare Kapazität, denn auch das Betriebssystem des Knotens und Kubernetes-Komponenten brauchen Ressourcen. Bei der tatsächlichen Einplanung sind neben der CPU auch Arbeitsspeicher und Platzierungsregeln wichtig.

Teile die Verwaltungsaufgaben auf

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE) betreiben verwaltete Steuerungsebenen. Der Anbieter wartet diese Steuerungsebene einschließlich ihrer Verfügbarkeit und Aktualisierungen. Du verwaltest Images, Anwendungseinstellungen, Zugriffe und Ressourcenanforderungen der Workloads. In vielen Betriebsarten verwaltest du auch die Auswahl und Aktualisierung der Worker-Knoten. Clustergebühren können getrennt von den Knotenkosten anfallen.

Bei GKE Standard wählst du die Knoten selbst und bezahlst die Knoten-VMs. GKE Autopilot stellt Knoten bereit und verwaltet sie; in der Regel werden die angeforderten Pod-Ressourcen berechnet. EKS kann geeignete Pods auf AWS Fargate ausführen, sodass du die Knoten-VMs nicht verwalten musst. Diese Betriebsarten verringern den Betriebsaufwand und schränken zugleich einige Auswahlmöglichkeiten für den Host ein.

Entscheide, ob die Komplexität hilft

Kubernetes passt zu vielen unabhängig bereitgestellten Diensten und zu Teams, die eine gemeinsame Plattform über mehrere Anbieter hinweg brauchen. Seine Werkzeuge und Workload-Definitionen verbessern die Portabilität, obwohl angebundene Cloud-Datenbanken, Identitätssysteme und Netzwerke weiterhin Änderungen erfordern können.

Für eine einfache Webanwendung kann eine Hostingplattform oder ein Serverless-Containerdienst weniger Aufwand bedeuten. Verwaltetes Kubernetes behebt keinen Fehler in deinem Image und wählt nicht die richtige Arbeitsspeicheranforderung für dich. Geht einer Anwendung wiederholt der Arbeitsspeicher aus, muss das Team die Anwendung und ihre Einstellungen untersuchen, auch wenn die Steuerungsebene vollständig verwaltet wird.

Serverless-Containerdienste führen deine Images auf vom Anbieter verwalteten Hosts aus. Du wählst weiterhin Ressourcen aus, wartest das Image und konfigurierst die Anwendung. Skalierung und Abrechnung hängen vom Dienst ab.

Trenne Orchestrierung von Rechenleistung

Amazon ECS orchestriert Container als Aufgaben. Ein ECS-Dienst hält eine gewünschte Anzahl von Aufgaben aufrecht, optional hinter einem Load Balancer. Aufgaben laufen auf EC2-Hosts, die du verwaltest, oder auf der Rechenplattform Fargate.

Fargate unterstützt auch geeignete EKS-Pods. Du wählst vCPUs und Arbeitsspeicher für Aufgaben oder Pods und bezahlst, solange diese Ressourcen laufen; du wählst, patchst oder skalierst die zugrunde liegenden EC2-Hosts nicht. Die automatische Skalierung von ECS-Diensten nutzt Richtlinien, die du konfigurierst. Fargate liefert Rechenleistung, nicht die gewünschte Anzahl von Aufgaben der Anwendung. ECS auf EC2 bietet mehr Kontrolle über Host und Instanzfamilie bei höherem Verwaltungsaufwand.

Vergleiche Azure- und Google-Dienste

Azure Container Instances (ACI) startet einen Container oder eine kleine Gruppe ohne Cluster und rechnet pro Sekunde ab. Es eignet sich für Tests und einfache, zeitlich begrenzte Aufgaben, hat aber keine integrierte automatische Skalierung.

Azure Container Apps verbirgt die zugrunde liegende Kubernetes-Plattform. Konfigurierte Regeln skalieren containerisierte Anwendungen anhand von HTTP-Datenverkehr oder Ereignissen, bei geeigneten Workloads auch bis auf null.

Google Cloud Run bietet Dienste für eingehende Anfragen und Aufträge, die bis zum Abschluss laufen. Dienste können von null aus wachsen und wieder schrumpfen. Die anfragebasierte Abrechnung der Rechenleistung umfasst die Verarbeitung von Anfragen sowie Start und Herunterfahren. Ohne Mindestanzahl und ohne laufende Instanzen kostet ungenutzte Rechenleistung nichts; Datenbanken und gespeicherte Images können weiterhin Kosten verursachen. Cloud Run hostet auch Cloud Run functions, die mit Funktionscode statt einem vom Kunden bereitgestellten Anwendungs-Image starten.

Wäge Einsparungen im Leerlauf gegen Startverzögerung ab

Eine interne Buchungs-API ist an Werktagen von 08:00 bis 18:00 Uhr ausgelastet: 10 Stunden an 5 Tagen oder 50 der 168 Stunden einer Woche. Gelegentlich treffen auch nachts Anfragen ein. Cloud Run oder Container Apps können bei Spitzenlast mehrere Kopien ausführen und in ruhigen Zeiten zwischen Anfragen auf null kommen.

Eine Anfrage nach einer Leerlaufphase muss möglicherweise auf einen Kaltstart warten. Eine ständig bereitgehaltene Mindestinstanz verringert die Verzögerung innerhalb ihrer Kapazität und verursacht laufende Kosten. Eine Spitze über diese Kapazität hinaus kann weiterhin zusätzliche Instanzen kalt starten.

Wähle die nötige Kontrolle über den Host

Diese Dienste beschränken den Hostzugriff und legen Ressourcen- und Laufzeitgrenzen fest. Du kannst keine Hostagenten installieren oder den Betriebssystemkern des Hosts ändern. VMs oder geeignete Kubernetes-Knoten erfüllen diese Anforderungen. Für standardmäßige containerisierte APIs können einfachere Dienste den Aufwand für den Betrieb von Kubernetes vermeiden; ACI ist eine direkte Option für eine einfache Containergruppe.

Eine Serverless-Funktion ist Code, der ausgeführt wird, wenn ein passendes Ereignis eintrifft. Der Anbieter verwaltet die Server und die verwaltete Laufzeitumgebung. AWS Lambda, Azure Functions und Google Cloud Run functions bieten dieses Modell Function as a Service (FaaS) an.

Verbinde einen Auslöser mit einem Aufruf

Ein Auslöser startet eine Ausführung, die als Aufruf bezeichnet wird. Zu den Auslösern gehören HTTP-Anfragen, hochgeladene Dateien, Warteschlangennachrichten, Datenbankänderungen und Zeitpläne. Ein Foto-Upload kann eine Funktion auslösen, die ein Vorschaubild mit 200 Pixeln erstellt und im Speicher sichert. Ohne Uploads muss bei einer bedarfsgesteuerten Bereitstellung keine Funktionsrechenleistung laufen.

Der Anbieter skaliert die Ausführung mit den eintreffenden Ereignissen innerhalb der Grenzen für Gleichzeitigkeit und Dienstnutzung. Viele gleichzeitige Funktionen können viele Datenbankverbindungen öffnen. Die Funktionsebene kann noch Raum zum Skalieren haben, während die Datenbank ihn nicht mehr hat. Begrenze die Gleichzeitigkeit auf das, was verbundene Systeme bewältigen können.

Funktionen sind zwischen Aufrufen zustandslos. Ein späterer Aufruf kann eine neue Umgebung verwenden und sich deshalb nicht auf den Arbeitsspeicher oder temporäre Dateien eines früheren Aufrufs verlassen. Speichere Zähler, Sitzungen und dauerhafte Ergebnisse in einer Datenbank, einem Cache oder Objektspeicher. Eine bereits bereitstehende Umgebung kann wiederverwendet werden, diese Wiederverwendung garantiert aber keine dauerhafte Speicherung.

Berechne den verbrauchsabhängigen Einsatz

Die standardmäßige On-Demand-Abrechnung von Lambda kombiniert die Anzahl der Aufrufe und GB-Sekunden (GB-s): zugewiesener Arbeitsspeicher in GB multipliziert mit der Laufzeit in Sekunden. Nimm für eine beispielhafte Berechnung an, dass jeder von 3.000.000 Aufrufen 0,2 Sekunden mit 0,5 GB Arbeitsspeicher läuft. Ignoriere Freikontingente und alle anderen Dienste.

Bei angenommenen Preisen von 0,0000167 US-Dollar pro GB-s und 0,20 US-Dollar pro Million Anfragen kostet die Rechenleistung 5,01 US-Dollar und die Anfragen kosten 0,60 US-Dollar, insgesamt 5,61 US-Dollar. Diese Preise sind angenommen, um das Modell zu lernen. Cloud Run functions erfasst auch die CPU; Azure-Tarife können bereite oder zugeordnete Instanzen berechnen.

Bei 100.000.000 ansonsten identischen Aufrufen beträgt der Verbrauch 10.000.000 GB-s: 167 US-Dollar für Rechenleistung plus 20 US-Dollar für Anfragen zu diesen angenommenen Preisen. Eine VM kostet bei angenommenen 0,04 US-Dollar pro Stunde für 730 Stunden 29,20 US-Dollar. Ein fairer Vergleich prüft aber auch, ob sie dieselbe Arbeit bewältigen kann, und berücksichtigt ihren Betriebsaufwand. Bei sprunghafter Nachfrage ist es vorteilhaft, ungenutzte Kapazität zu vermeiden; gleichmäßige Last kann dauerhaft laufende Rechenressourcen begünstigen.

Prüfe Laufzeitgrenzen und Startverzögerung

Standard-Rechenressourcen von Lambda erlauben höchstens 15 Minuten pro Aufruf und bis zu 10.240 MB Arbeitsspeicher. Eine 40-minütige Konvertierung passt nicht in diesen Aufruf. Ein Containerauftrag, eine VM oder kürzere Schritte können passen; Zeitüberschreitungsregeln unterscheiden sich bei anderen Tarifen und Rechenmodi.

Ein Kaltstart tritt auf, wenn eine neue Ausführungsumgebung vorbereitet werden muss, nach einer Leerlaufphase oder beim horizontalen Hochskalieren. Wiederverwendete, bereits bereitstehende Umgebungen starten schneller. Bereitgestellte Gleichzeitigkeit bei Lambda, ständig bereite Instanzen bei Azure Premium oder Flex Consumption und Mindestinstanzen bei Cloud Run verringern Startverzögerungen gegen zusätzliche Kosten.

Der Anbieter wartet Server und die verwaltete Laufzeitumgebung. Du behebst weiterhin Fehler in deinem Code und den enthaltenen Bibliotheken, schützt Geheimnisse, konfigurierst Berechtigungen und sicherst Daten. Serverless nimmt dir die Serververwaltung ab, nicht die Verantwortung für die Anwendung.

Eine Anwendungshostingplattform nimmt deinen Code oder dein Container-Image entgegen und stellt die Infrastruktur für dessen Ausführung bereit. Sie ist eine Platform as a Service (PaaS): Bereitstellung, Zustandsüberwachung, Serverbetrieb und Skalierung erfolgen über die Plattform, während du die Anwendung entwickelst.

Vergleiche die wichtigsten Plattformen

AWS Elastic Beanstalk erstellt gewöhnliche AWS-Ressourcen für deine Anwendung, häufig EC2-Instanzen in einer Auto Scaling-Gruppe hinter einem Elastic Load Balancer. Es übernimmt Bereitstellungen und Zustandsüberwachung. Für Beanstalk selbst fällt keine zusätzliche Dienstgebühr an; du bezahlst die erstellten Ressourcen. Diese Ressourcen bleiben in deinem Konto sichtbar, und du kannst ihre Konfiguration anpassen.

Azure App Service hostet Webanwendungen, APIs und mobile Backends aus Code oder Containern. Ein App Service-Plan legt Region, Instanzgröße und -anzahl fest. Anwendungen in diesem Plan teilen sich diese Instanzen. Dedizierte Tarife berechnen den Plan auch bei geringer Auslastung der Anwendungen. Funktionen wie automatische Skalierung und Bereitstellungsslots hängen vom gewählten Tarif ab.

Google App Engine hat eine Standard- und eine flexible Umgebung. Die Standardumgebung verwendet unterstützte Laufzeitumgebungen in einer Sandbox und kann bei geeigneter automatischer Skalierung auf null skalieren. Die flexible Umgebung führt Container auf Compute-Engine-VMs aus, erlaubt mehr Anpassungen und hält mindestens eine Instanz am Laufen. Cloud Run ist ein weiterer Weg, eine bereits als Container verpackte Anwendung zu hosten.

Gib eine neue Version sicher frei

Ein Shop-Team aus zwei Personen nutzt einen App Service-Tarif mit Bereitstellungsslots. Es betreibt 2 Instanzen und stellt eine neue Version in einem Testslot bereit, einem separaten Ort zum Testen der Version, bevor Kunden sie nutzen. Nach dem Test tauscht es Test- und Produktionsslot. Die alte Version bleibt im anderen Slot für eine mögliche Rücksetzung verfügbar.

Während einer Verkaufsaktion erhöht die konfigurierte Regel für die automatische Skalierung den Plan auf 5 Instanzen, nachdem die durchschnittliche CPU-Auslastung über 70 % geblieben ist, und setzt ihn bei sinkendem Bedarf auf 2 zurück. Die Plattform führt die Skalierung durch, aber das Team wählt weiterhin Plan, Regeln und Grenzen. Es installiert weder das Hostbetriebssystem noch den Webserver.

Behalte die passenden Aufgaben

Du wartest auf jeder Plattform Code, enthaltene Bibliotheken, Einstellungen, Geheimnisse, Daten und Zugriffe. App Service und App Engine warten ihr Hostbetriebssystem und ihre verwaltete Laufzeitumgebung. Beanstalk erlaubt mehr EC2-Anpassungen; AWS veröffentlicht Plattformaktualisierungen, und du spielst sie ein oder aktivierst verwaltete Plattformaktualisierungen. Zusätzliche Software, die du installierst, muss ebenfalls gepflegt werden.

Eine Plattform unterscheidet sich von SaaS. Bei PaaS stellst du die Anwendung bereit, die du entwickelst; bei SaaS nutzt du die fertige Anwendung eines anderen, etwa eine E-Mail-Suite. Plattformspezifische Einstellungen und Dienstintegrationen können auch einen späteren Anbieterwechsel erschweren.

Decke einfachere Hostinganforderungen ab

Amazon Lightsail bündelt einen virtuellen privaten Server, Speicher und Datenübertragung in einem vorhersehbaren monatlichen Paket. Es eignet sich für kleine Websites, bringt aber weiterhin VM-Verantwortlichkeiten mit sich. Eine statische Website besteht aus Dateien wie HTML, CSS, JavaScript und Bildern. AWS Amplify Hosting, Azure Static Web Apps und Firebase Hosting können diese Dateien weltweit bereitstellen, ohne dass du einen Webserver warten musst. Eine Anwendung, die vollständige Kontrolle über das Hostbetriebssystem benötigt, gehört auf VMs.

Vergleiche Rechenmodelle anhand derselben Workload. Prüfe Kontrolle, Betriebsaufwand, Start, Abrechnung, Grenzen und Portabilität.

Wer wartet was?

Daten und Zugriffe bleiben durchgehend in der Verantwortung des Kunden. Bei Elastic Beanstalk muss außerdem entschieden werden, wie Plattformaktualisierungen eingespielt werden.

Vergleiche Datenverkehr und nutzbare Kapazität

Eine VM braucht meist eine Minute oder länger zum Hochfahren und Bestehen der Prüfungen; ein Container startet oft in Sekunden; eine bereits bereitstehende Funktion kann in Millisekunden mit der Arbeit beginnen. Eine neue Umgebung kann eine Kaltstartverzögerung verursachen. Bereitgehaltene Kapazität verringert diese Verzögerung bei laufenden Kosten.

Ein Verzeichnisdienst, der über Nacht wenig genutzt wird, kann von der Skalierung auf null profitieren; gleichmäßiger Bedarf kann zugeordnete Rechenressourcen begünstigen. Vergleiche vor den monatlichen Gesamtkosten gleichwertigen Datendurchsatz, Arbeitsspeicher und Gleichzeitigkeit: Eine günstige VM kann möglicherweise nicht dieselbe Arbeit leisten wie viele gleichzeitige Funktionsaufrufe. Berücksichtige auch den Betriebsaufwand.

VMs und dedizierte Hostingpläne werden für die Zeit ihrer Zuordnung berechnet, ob sie ausgelastet sind oder nicht. Die standardmäßige On-Demand-Abrechnung von Lambda kombiniert Anfragen und GB-Sekunden; andere Funktionstarife verwenden andere Abrechnungsgrößen. Null Instanzen beseitigt Rechenkosten im Leerlauf nur, wenn kein kostenpflichtiges Minimum bestehen bleibt. Für Speicher und Datenbanken können weiterhin Kosten anfallen.

Prüfe Grenzen und Wechsel zwischen Plattformen

Langlebige Prozesse passen zu VMs oder geeigneten Containern. Ein einzelner Aufruf mit Lambda-Standard-Rechenressourcen ist auf 15 Minuten begrenzt, sodass ein ununterbrochener zweistündiger Auftrag eine andere kompatible Ausführungsoption braucht. Funktionen können sich nicht darauf verlassen, dass lokaler Zustand Aufrufe überdauert; ersetzbare Container und VMs in Skalierungsgruppen brauchen ebenfalls extern gespeicherte dauerhafte Daten.

Vollständige Kontrolle über das Gastbetriebssystem, Änderungen am Betriebssystemkern und spezialisierte Lizenzsoftware sprechen für VMs. Viele unabhängig bereitgestellte Dienste können Kubernetes rechtfertigen. Standard-Webanwendungen passen oft zu Hostingplattformen; kurze ereignisgesteuerte Aufgaben passen zu Funktionen.

Container-Images lassen sich zwischen kompatiblen Hosts verschieben, und Kubernetes bietet gemeinsame Bereitstellungswerkzeuge über Clouds hinweg. Datenbanken, Identitäten und Netzwerke können weiterhin Änderungen brauchen. VM-Migration hängt von Formaten und Werkzeugen der Anbieter ab; Funktionen und Plattformen sind stärker an Einstellungen und Auslöser der Anbieter gebunden. Verschiedene Komponenten können verschiedene Modelle nutzen.

Prüfe zuerst die Anforderungen, die eine Lösung ausschließen könnten. Vergleiche dann Datenverkehr, Kosten und Teamkenntnisse.

Finde die entscheidende Einschränkung

1. Prüfe den Zugriff auf das Gastbetriebssystem sowie spezielle Software, Hardware und Lizenzierung.
2. Prüfe bei kurzer ereignisgesteuerter Arbeit die Laufzeit, den Zustand und die Gleichzeitigkeit von Funktionen.
3. Vergleiche bei containerisierten Anwendungen die Kontrolle durch Kubernetes mit einfacheren verwalteten Diensten.
4. Ziehe für als Code bereitgestellte Standard-Webanwendungen eine Hostingplattform in Betracht.
5. Prüfe Startverzögerung, Datenverkehrsmuster, Ressourcengrenzen und gesamte Betriebskosten.

Ordne die betrieblichen Anwendungsfälle zu

Ein Hersteller unterstützt eine Buchhaltungsanwendung nur auf Windows Server, mit einer kernbasierten Lizenz. VMs erhalten diese Umgebung; nutze einen dedizierten Host, wenn die Lizenzierung nach physischen Kernen es verlangt. Kopien über mehrere Zonen brauchen eine kompatible Anwendungs- und Datenarchitektur. Der weitgehend unveränderte Umzug heißt Rehosting oder Lift and Shift und behält die Wartung des Gastbetriebssystems bei.

Foto-Uploads steigen von einigen wenigen nachts auf Tausende pro Minute. Kurze unabhängige Aufgaben zur Erstellung von Vorschaubildern passen zu Funktionen, die durch Uploads ausgelöst werden. Sie skalieren mit den Eingängen; prüfe Kaltstarts, Laufzeitgrenzen und die Kapazität nachgelagerter Dienste.

Ein Händler hat 30 Microservices, 6 Teams und die Anforderung einer Plattform auf zwei Clouds. Verwaltetes Kubernetes liefert gemeinsame Orchestrierungswerkzeuge. Ein Start-up mit 3 Diensten und ohne Kubernetes-Erfahrung kann Cloud Run, Container Apps oder ECS mit Fargate nutzen und bleibt ohne Hostarbeit für Images und Anwendung verantwortlich.

Die Agentur eines Museums entwickelt eine Ticketwebsite, hat aber kein Betriebspersonal. Eine Hostingplattform liefert Bereitstellungswerkzeuge und Skalierung für Eröffnungstage. App Service und App Engine warten Hosts; bei Beanstalk ist eine Entscheidung zu Plattformaktualisierungen nötig, etwa für verwaltete Aktualisierungen.

Ein zweistündiger nächtlicher Bericht passt zu einem Containerauftrag oder einer VM mit geeigneter Laufzeitgrenze, nicht zu einem einzelnen Aufruf mit Lambda-Standard-Rechenressourcen. Spot kann Kosten senken, wenn der Auftrag Fortschritte speichert und nach einer Unterbrechung fortgesetzt wird.

Mehrtägiges GPU-Training braucht beschleunigte VMs oder geeignete Kubernetes-GPU-Knoten. Dauerhaft gespeicherte Prüfpunkte machen Spot praktikabel, indem sie den verlorenen Fortschritt begrenzen.

Erkläre eine gestufte Entscheidung

Ein Unternehmen kann zunächst per Rehosting umziehen, um sein Rechenzentrum schnell zu verlassen, und dann ausgewählte Komponenten mit Containern, Hostingplattformen oder Funktionen modernisieren. Rehosting allein behält das alte Betriebsmodell bei.

Zum Beispiel: „Nutze Cloud Run, weil die API bereits containerisiert ist, der Datenverkehr nachts aussetzt und das Team keinen Serveradministrator hat; berücksichtige einen Kaltstart nach einer Leerlaufphase.“