Die Kunst, Container zu skalieren: Verteilung
Beim Skalieren von Containern handelt es sich um mehr, als einfach einen Proxy vor einen Dienst zu setzen und sich dann zurückzuziehen. Zur Skalierung gehört mehr als nur die Verteilung. In der schnelllebigen Welt der Container sind zur Gewährleistung der Skalierbarkeit fünf verschiedene Funktionen erforderlich: Wiederholungsversuche, Leistungsschalter, Erkennung , Verteilung und Überwachung.
In diesem Beitrag zur Kunst der Container-Skalierung befassen wir uns mit der Verteilung.
Verteilung
Das Geheimrezept für die Skalierung von irgendetwas beruhte schon immer teilweise auf der Art und Weise, wie die Anfragen auf eine begrenzte Anzahl von Ressourcen verteilt werden. Nicht einmal die Cloud und ihre scheinbar unendliche Rechenleistung können dieses Rezept ändern. Zum Zeitpunkt des Eingangs einer Anfrage ist die Liste möglicher Ressourcen, die diese Anfrage annehmen und verarbeiten können, begrenzt. Zeitraum.
Die Entscheidung, wohin eine Anfrage gerichtet werden soll, ist daher ziemlich wichtig. Senden Sie es an die falsche Ressource, kann die Leistung darunter leiden. Senden Sie es an die richtige Ressource und der Verbraucher/Mitarbeiter wird mit dem Ergebnis zufrieden sein.
In der Anfangszeit von Scale basierten diese Entscheidungen ausschließlich auf Algorithmen. Rundenturnier. Wenigste Verbindungen. Schnellste Antwort. Diese bewährten Mechanismen bestehen auch heute noch, doch sind sie langsam aber sicher nicht mehr der einzige Faktor im Entscheidungsprozess, sondern nur noch ein weiterer.
Das liegt daran, dass wir uns nicht mehr ausschließlich auf verbindungsbasierte Entscheidungsprozesse (auch bekannt als „gutes altes Lastenausgleichssystem“) verlassen. Als es beim Lastenausgleich in erster Linie um die Verwaltung von TCP-Verbindungen ging, waren auf Verbindungen basierende Verteilungsschemata sinnvoll. Doch die Skalierung basiert heute ebenso sehr auf der Architektur wie auf den Algorithmen, und die Verteilung der Anfragen kann eine komplexe Berechnung sein, in die viele Variablen oberhalb (im wahrsten Sinne des Wortes) und jenseits der Layer-4-Protokolle einfließen.
Erschwerend kommt hinzu, dass die heutigen Architekturen selbst zunehmend verteilt sind. Nicht nur über Clouds, sondern auch über Container hinweg. Es können mehrere Versionen derselben App (oder API) gleichzeitig im Einsatz sein. Das für die Verteilung der Anfragen zuständige System muss diese erkennen und zwischen ihnen unterscheiden können, um die Zustellung an den richtigen Endpunkt sicherzustellen.
Heutzutage werden Entscheidungen nicht mehr nur auf Grundlage der Verbindungskapazität, sondern zunehmend auch auf Grundlage von Layer-7-Parametern (HTTP) getroffen. Hostnamen. API-Methoden (auch bekannt als URI). API-Schlüssel. Benutzerdefinierte HTTP-Header mit eingebetteten Versionsnummern. Standort. Gerät. Benutzer. Anfragen werden im jeweiligen Kontext ausgewertet und Entscheidungen innerhalb von Mikrosekunden getroffen.
Die heutige Verteilung erfordert einen mehrstufigen, architektonischen Ansatz. Je tiefer Sie in die App-Architektur vordringen, desto weniger granular wird Ihre Verarbeitung. Bis ein Proxy eine Entscheidung zum Lastausgleich zwischen X-Klonen desselben Mikrodienstes trifft, verwendet er möglicherweise lediglich herkömmliche, algorithmisch gesteuerte Gleichungen. Währenddessen treffen Ingress-Controller an den äußeren Rändern der Umgebung teilweise komplexe Entscheidungen auf Grundlage von HTTP-Layer-Variablen.
Nach außen wird die Verteilung durch die Architektur bestimmt. Im Inneren durch Algorithmen .
Beides sind kritische Komponenten – vielleicht die kritischsten – für die Skalierung von Containern.
Beide sind auf genaue Echtzeitinformationen zum Status (Integrität) der Ressourcen angewiesen, an die sie Anfragen verteilen. In den nächsten Beiträgen dieser Reihe befassen wir uns mit der Überwachung.