🥇Vyrovnávání zátěže a škálování dlouhodobých připojení v Kubernetes

Tento článek vám pomůže pochopit, jak funguje vyvažování zátěže v Kubernetes, co se stane při škálování dlouhodobých připojení a proč byste měli zvážit vyvažování na straně klienta, pokud používáte HTTP/2, gRPC, RSockets, AMQP nebo jiné protokoly s dlouhou životností. .

Něco málo o tom, jak je provoz v Kubernetes přerozdělován

Kubernetes poskytuje dvě pohodlné abstrakce pro nasazení aplikací: Služby a Nasazení.

Nasazení popisují, jak a kolik kopií vaší aplikace by mělo být v daném okamžiku spuštěno. Každá aplikace je nasazena jako Pod a je jí přidělena IP adresa.

Služby mají podobnou funkci jako load balancer. Jsou navrženy tak, aby distribuovaly provoz mezi více modulů.

Pojďme se podívat, jak to vypadá.

Na níže uvedeném diagramu můžete vidět tři instance stejné aplikace a load balancer:
Nástroj pro vyrovnávání zatížení se nazývá služba a je mu přidělena adresa IP. Jakýkoli příchozí požadavek je přesměrován na jeden z modulů:
Scénář nasazení určuje počet instancí aplikace. Téměř nikdy nebudete muset expandovat přímo pod:
Každému modulu je přiřazena vlastní IP adresa:

Je užitečné uvažovat o službách jako o sbírce IP adres. Při každém přístupu ke službě se ze seznamu vybere jedna z IP adres a použije se jako cílová adresa.

Vypadá to takto.

Do služby je přijat požadavek curl 10.96.45.152:
Služba vybere jako cíl jednu ze tří adres pod:
Provoz je přesměrován na konkrétní pod:

Pokud se vaše aplikace skládá z frontendu a backendu, budete mít pro každý z nich službu i nasazení.

Když frontend zadá požadavek na backend, nemusí přesně vědět, kolik podů backend obsluhuje: může jich být jeden, deset nebo sto.

Frontend také neví nic o adresách podů obsluhujících backend.

Když frontend zadá požadavek na backend, použije IP adresu backendové služby, která se nemění.

Zde je návod, jak to vypadá.

Pod 1 požaduje interní backend komponentu. Namísto výběru konkrétního pro backend zadá požadavek na službu:
Služba vybere jeden z backendových modulů jako cílovou adresu:
Provoz přechází z Pod 1 do Pod 5, vybrané službou:
Pod 1 přesně neví, kolik podů jako pod 5 se skrývá za službou:

Ale jak přesně služba distribuuje požadavky? Zdá se, že se používá vyvažování mezi jednotlivými okruhy? Pojďme na to přijít.

Balancování ve službách Kubernetes

Služby Kubernetes neexistují. Pro službu, které je přiřazena IP adresa a port, neexistuje žádný proces.

Můžete to ověřit přihlášením do libovolného uzlu v klastru a spuštěním příkazu netstat -ntlp.

Nebudete moci ani najít IP adresu přidělenou službě.

IP adresa služby je umístěna v řídicí vrstvě, v řadiči a zaznamenána v databázi - atd. Stejnou adresu používá další komponenta - kube-proxy.
Kube-proxy obdrží seznam IP adres pro všechny služby a vygeneruje sadu pravidel iptables na každém uzlu v clusteru.

Tato pravidla říkají: „Pokud vidíme IP adresu služby, musíme upravit cílovou adresu požadavku a odeslat ji na jeden z modulů.“

Servisní IP adresa se používá pouze jako vstupní bod a neobsluhuje ji žádný proces naslouchající této IP adrese a portu.

Podívejme se na to.

Uvažujme shluk tří uzlů. Každý uzel má pody:
Vázané lusky lakované béžovou barvou jsou součástí služby. Protože služba neexistuje jako proces, je zobrazena šedě:
První modul požaduje službu a musí přejít na jeden z přidružených modulů:
Ale služba neexistuje, proces neexistuje. Jak to funguje?
Než požadavek opustí uzel, projde pravidly iptables:
Pravidla iptables vědí, že služba neexistuje, a nahrazují její IP adresu jednou z IP adres podů spojených s touto službou:
Požadavek obdrží platnou IP adresu jako cílovou adresu a je zpracován normálně:
V závislosti na topologii sítě požadavek nakonec dosáhne pod:

Dokáže iptables vyvážit zatížení?

Ne, iptables se používají k filtrování a nebyly navrženy pro vyvažování.

Je však možné napsat sadu pravidel, která fungují jako pseudobalancér.

A přesně to je implementováno v Kubernetes.

Pokud máte tři moduly, kube-proxy napíše následující pravidla:

Vyberte prvního podřízeného s pravděpodobností 33 %, jinak přejděte k dalšímu pravidlu.
Vyberte druhé s pravděpodobností 50 %, jinak přejděte k dalšímu pravidlu.
Vyberte třetí pod.

Tento systém má za následek, že každý modul je vybrán s pravděpodobností 33 %.

A neexistuje žádná záruka, že modul 2 bude vybrán jako další po modulu 1.

Poznámka: iptables používá statistický modul s náhodným rozdělením. Algoritmus vyvažování je tedy založen na náhodném výběru.

Nyní, když rozumíte tomu, jak služby fungují, pojďme se podívat na zajímavější scénáře služeb.

Dlouhodobá připojení v Kubernetes se ve výchozím nastavení neškálují

Každý HTTP požadavek z frontendu na backend je obsluhován samostatným TCP spojením, které se otevírá a zavírá.

Pokud frontend odešle do backendu 100 požadavků za sekundu, otevře a zavře se 100 různých TCP spojení.

Můžete zkrátit dobu zpracování požadavků a zatížení tím, že otevřete jedno TCP spojení a použijete ho pro všechny následující HTTP požadavky.

Protokol HTTP má funkci zvanou HTTP keep-alive neboli opětovné použití připojení. V tomto případě se k odesílání a přijímání více požadavků a odpovědí HTTP používá jediné připojení TCP:

Tato funkce není ve výchozím nastavení povolena: podle toho musí být nakonfigurován server i klient.

Samotné nastavení je jednoduché a dostupné pro většinu programovacích jazyků a prostředí.

Zde je několik odkazů na příklady v různých jazycích:

Co se stane, když ve službě Kubernetes použijeme funkci keep-alive?
Předpokládejme, že jak frontend, tak backend podporují zachování.

Máme jednu kopii frontendu a tři kopie backendu. Frontend provede první požadavek a otevře TCP spojení s backendem. Požadavek dorazí ke službě, jeden z backendových modulů je vybrán jako cílová adresa. Backend odešle odpověď a frontend ji přijme.

Na rozdíl od obvyklé situace, kdy je TCP spojení po obdržení odpovědi uzavřeno, je nyní udržováno otevřené pro další HTTP požadavky.

Co se stane, když frontend odešle více požadavků na backend?

K předání těchto požadavků bude použito otevřené TCP spojení, všechny požadavky půjdou na stejný backend, kam šel první požadavek.

Neměly by iptables přerozdělovat provoz?

V tomto případě ne.

Když je vytvořeno TCP spojení, prochází pravidly iptables, která vybírají konkrétní backend, kam bude provoz směřovat.

Protože všechny následující požadavky jsou na již otevřeném TCP spojení, pravidla iptables se již nevolají.

Pojďme se podívat, jak to vypadá.

První modul odešle požadavek službě:
Už víte, co bude dál. Služba neexistuje, ale existují pravidla iptables, která požadavek zpracují:
Jako cílová adresa bude vybrán jeden z backendových modulů:
Žádost dorazí do modulu. V tomto okamžiku bude navázáno trvalé TCP spojení mezi dvěma moduly:
Jakýkoli další požadavek z prvního modulu projde již vytvořeným připojením:

Výsledkem jsou rychlejší doby odezvy a vyšší propustnost, ale ztrácíte možnost škálovat backend.

I když máte v backendu dva moduly, s konstantním připojením bude provoz vždy směřovat do jednoho z nich.

Lze to opravit?

Vzhledem k tomu, že Kubernetes neví, jak vyvážit trvalá připojení, je tento úkol na vás.

Služby jsou kolekce IP adres a portů nazývaných koncové body.

Vaše aplikace může získat seznam koncových bodů ze služby a rozhodnout, jak mezi ně rozdělit požadavky. Můžete otevřít trvalé připojení ke každému podu a vyrovnat požadavky mezi těmito připojeními pomocí kruhové obsluhy.

Nebo aplikujte více složité vyvažovací algoritmy.

Kód na straně klienta, který je zodpovědný za vyvažování, by se měl řídit touto logikou:

Získejte seznam koncových bodů ze služby.
Otevřete trvalé připojení pro každý koncový bod.
Když je třeba provést požadavek, použijte jedno z otevřených připojení.
Pravidelně aktualizujte seznam koncových bodů, vytvořte nové nebo ukončete stará trvalá připojení, pokud se seznam změní.

Takhle to bude vypadat.

Namísto toho, aby první modul odeslal požadavek službě, můžete vyrovnat požadavky na straně klienta:
Musíte napsat kód, který se zeptá, které moduly jsou součástí služby:
Jakmile budete mít seznam, uložte jej na straně klienta a použijte jej k připojení k modulům:
Jste odpovědní za algoritmus vyrovnávání zátěže:

Nyní vyvstává otázka: týká se tento problém pouze HTTP keep-alive?

Vyvažování zátěže na straně klienta

HTTP není jediný protokol, který může používat trvalá připojení TCP.

Pokud vaše aplikace používá databázi, pak se TCP spojení neotevře pokaždé, když potřebujete vytvořit požadavek nebo načíst dokument z databáze.

Místo toho se otevře a použije trvalé připojení TCP k databázi.

Pokud je vaše databáze nasazena na Kubernetes a přístup je poskytován jako služba, setkáte se se stejnými problémy, které jsou popsány v předchozí části.

Jedna replika databáze bude načtena více než ostatní. Kube-proxy a Kubernetes nepomohou vyvážit připojení. Musíte se postarat o vyvážení dotazů do vaší databáze.

V závislosti na knihovně, kterou používáte pro připojení k databázi, můžete mít různé možnosti řešení tohoto problému.

Níže je uveden příklad přístupu k databázovému clusteru MySQL z Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

Existuje mnoho dalších protokolů, které používají trvalá připojení TCP:

WebSockets a zabezpečené WebSockets
HTTP / 2
gRPC
RSockets
AMQP

S většinou těchto protokolů byste již měli být obeznámeni.

Ale pokud jsou tyto protokoly tak populární, proč neexistuje standardizované řešení vyvážení? Proč se logika klienta musí změnit? Existuje nativní řešení Kubernetes?

Kube-proxy a iptables jsou navrženy tak, aby pokryly většinu běžných případů použití při nasazení na Kubernetes. Toto je pro pohodlí.

Pokud používáte webovou službu, která odhaluje REST API, máte štěstí – v tomto případě se nepoužívají trvalá připojení TCP, můžete použít jakoukoli službu Kubernetes.

Jakmile ale začnete používat trvalá připojení TCP, budete muset vymyslet, jak rovnoměrně rozložit zátěž mezi backendy. Kubernetes neobsahuje hotová řešení pro tento případ.

Určitě však existují možnosti, které mohou pomoci.

Vyvažování dlouhodobých připojení v Kubernetes

V Kubernetes existují čtyři typy služeb:

ClusterIP
Port uzlu
LoadBalancer
Bezhlavý

První tři služby fungují na základě virtuální IP adresy, kterou používá kube-proxy k vytváření pravidel iptables. Ale základním základem všech služeb je bezhlavá služba.

Bezhlavá služba nemá přidruženou žádnou IP adresu a poskytuje pouze mechanismus pro načtení seznamu IP adres a portů podů (koncových bodů) s ní spojených.

Všechny služby jsou založeny na bezhlavé službě.

Služba ClusterIP je bezhlavá služba s některými doplňky:

Vrstva správy mu přidělí IP adresu.
Kube-proxy vygeneruje potřebná pravidla iptables.

Tímto způsobem můžete ignorovat kube-proxy a přímo použít seznam koncových bodů získaných ze služby headless k vyrovnávání zatížení vaší aplikace.

Jak ale můžeme přidat podobnou logiku všem aplikacím nasazeným v clusteru?

Pokud je vaše aplikace již nasazena, může se tento úkol zdát nemožný. Existuje však alternativní možnost.

Service Mesh vám pomůže

Pravděpodobně jste si již všimli, že strategie vyvažování zátěže na straně klienta je zcela standardní.

Po spuštění aplikace:

Získá seznam IP adres ze služby.
Otevírá a udržuje fond připojení.
Pravidelně aktualizuje fond přidáním nebo odebráním koncových bodů.

Jakmile aplikace chce podat žádost,:

Vybere dostupné připojení pomocí nějaké logiky (např. round-robin).
Vyřídí požadavek.

Tyto kroky fungují pro připojení WebSockets, gRPC i AMQP.

Tuto logiku můžete oddělit do samostatné knihovny a použít ji ve svých aplikacích.

Místo toho však můžete použít servisní sítě jako Istio nebo Linkerd.

Service Mesh rozšíří vaši aplikaci o proces, který:

Automaticky vyhledává servisní IP adresy.
Testuje připojení, jako jsou WebSockets a gRPC.
Vyrovnává požadavky pomocí správného protokolu.

Service Mesh pomáhá řídit provoz v rámci clusteru, ale je poměrně náročný na zdroje. Dalšími možnostmi jsou použití knihoven třetích stran, jako je Netflix Ribbon, nebo programovatelné proxy, jako je Envoy.

Co se stane, když problémy s vyvážením ignorujete?

Můžete se rozhodnout nepoužívat vyrovnávání zátěže a přesto nezaznamenat žádné změny. Podívejme se na několik pracovních scénářů.

Pokud máte více klientů než serverů, není to tak velký problém.

Řekněme, že existuje pět klientů, kteří se připojují ke dvěma serverům. I když nedojde k vyrovnání, budou použity oba servery:

Připojení nemusí být rovnoměrně rozmístěno: možná jsou čtyři klienti připojeni ke stejnému serveru, ale je velká šance, že budou použity oba servery.

Problematičtější je opačný scénář.

Máte-li méně klientů a více serverů, mohou být vaše prostředky nevyužité a objeví se potenciální úzké místo.

Řekněme, že existují dva klienti a pět serverů. V nejlepším případě budou dvě trvalá připojení ke dvěma serverům z pěti.

Zbývající servery budou nečinné:

Pokud tyto dva servery nezvládají požadavky klientů, horizontální škálování nepomůže.

Závěr

Služby Kubernetes jsou navrženy tak, aby fungovaly ve většině scénářů standardních webových aplikací.

Jakmile však začnete pracovat s aplikačními protokoly, které používají trvalá TCP spojení, jako jsou databáze, gRPC nebo WebSockets, služby již nejsou vhodné. Kubernetes neposkytuje interní mechanismy pro vyvažování trvalých připojení TCP.

To znamená, že musíte psát aplikace s ohledem na vyvažování na straně klienta.

Překlad připravil tým Kubernetes aaS z Mail.ru.

Co si k tématu ještě přečíst:

Zdroj: www.habr.com

Vyrovnávání zátěže a škálování dlouhodobých připojení v Kubernetes