Kubernetes Aarbechtsknäppchen: vill kleng oder e puer grouss?

Wann Dir e Kubernetes-Cluster erstellt, kënnen d'Froen optrieden: wéivill Aarbechterknäppchen fir ze konfiguréieren a wéi eng Zort? Wat ass besser fir en on-premise Cluster: kaaft verschidde mächteg Serveren oder benotzt eng Dosen al Maschinnen an Ärem Datenzenter? Ass et besser aacht Single-Core oder zwee Quad-Core Instanzen an der Wollek ze huelen?

D'Äntwerten op dës Froen sinn am Artikel. Daniel Weibel, Software Ingenieur an Enseignant vum Learnk8s Educatiounsprojet an der Iwwersetzung vum Kommando Kubernetes aaS vun Mail.ru.

Cluster Kapazitéit

Am Allgemengen kann e Kubernetes Stärekoup als grouss "Supernode" geduecht ginn. Seng Gesamt Rechenkraaft ass d'Zomm vun de Kräfte vun all sengen konstituéierten Noden.

Et gi verschidde Weeër fir Äert gewënschte Cluster Kapazitéit Zil z'erreechen. Zum Beispill brauche mir e Stärekoup mat enger Gesamtkapazitéit vun 8 Prozessorkären an 32 GB RAM, well eng Rei vun Uwendungen sou vill Ressourcen erfuerderen. Da kënnt Dir zwee Wirbelen installéieren mat 16 GB Erënnerung oder véier Wirbelen mat 8 GB Erënnerung, zwee Quad-Core Prozessoren oder véier Dual-Core.

Hei sinn nëmmen zwee méiglech Weeër fir e Cluster ze kreéieren:

Béid Optiounen produzéieren e Cluster mat der selwechter Kapazitéit, awer déi ënnescht Konfiguratioun huet véier méi kleng Wirbelen an déi iewescht Konfiguratioun huet zwee méi grouss Wirbelen.

Wéi eng Optioun ass besser?

Fir dës Fro ze beäntweren, kucke mer d'Virdeeler vun deenen zwou Optiounen. Mir hunn se an enger Tabell zesummegefaasst.

Verschidde grouss Wirbelen

Vill kleng Wirbelen

Méi einfach Clustermanagement (wann et on-premise ass)

Glat Autoskaléierung

Méi bëlleg (wann op der Plaz)

De Präis ass e bëssen anescht (an der Wollek)

Kann Ressource-intensiv Uwendungen lafen

Voll Replikatioun

Ressourcen gi méi effizient benotzt (manner Overhead op Systemdemonen
Méi héich Cluster Feeler Toleranz

Notéiert w.e.g. datt mir nëmmen iwwer Aarbechtsknäppchen schwätzen. D'Zuel an d'Gréisst vun den Haaptnoden auswielen ass e komplett anert Thema.

Also, loosst eis all Punkt aus der Tabell méi detailléiert diskutéieren.

Éischt Optioun: e puer grouss Wirbelen

Déi extremst Optioun ass en Aarbechter Node fir déi ganz Clusterkapazitéit. Am Beispill hei uewen wier dëst en eenzegen Aarbechter Node mat 16 CPU Cores an 16 GB RAM.

Plus

Plus Nr 1. Méi einfach Gestioun
Et ass méi einfach e puer Maschinnen ze managen wéi eng ganz Flott. Et ass méi séier Updates a Fixer auszerollen, an et ass méi einfach ze synchroniséieren. D'Zuel vun de Feeler an absoluten Zuelen ass och manner.

Notéiert w.e.g. datt all déi uewe genannte fir Är Hardware, Är Serveren, an net op Cloud Instanzen gëllen.

D'Situatioun ass anescht an der Wollek. Do gëtt d'Gestioun vum Cloud Service Provider gehandhabt. Also, d'Verwaltung vun zéng Wirbelen an der Wollek ass net vill anescht wéi d'Gestioun vun engem Node.

Traffic Routing a Lastverdeelung tëscht Pods an der Wollek automatesch duerchgefouert: Traffic, deen aus dem Internet kënnt, gëtt an den Haaptlaaschtbalancer geschéckt, deen den Traffic an den Hafen vun engem vun den Node weidergeleet (den NodePort-Service setzt den Hafen am Beräich 30000-32767 an all Clusternode). D'Regele vu Kube-Proxy viruleeden Traffic vum Node an de Pod. Hei ass wéi et ausgesäit fir zéng Pods op zwee Wirbelen:

Pro # 2: Manner Käschten pro Node
E mächtege Auto ass méi deier, awer d'Präisserhéijung ass net onbedéngt linear. An anere Wierder, een zéng-Kär Server mat 10 GB Erënnerung normalerweis méi bëlleg wéi zéng Single-Kär Serveren mat der selwechter Quantitéit vun Erënnerung.

Awer bemierkt datt dës Regel normalerweis net a Cloud Servicer funktionnéiert. An den aktuellen Präisschemaen vun all de grousse Cloud Ubidder eropgoen d'Präisser linear mat der Kapazitéit.

Also, an der Wollek kënnt Dir normalerweis net op méi mächtege Server späicheren.

Pro #3: Dir kënnt Ressourceintensiv Uwendungen lafen
E puer Applikatiounen erfuerderen mächteg Serveren an engem Cluster. Zum Beispill, wann eng Maschinn Léieren System verlaangt 8 GB Erënnerung, Dir wäert net fäheg sinn et op 1 GB Wirbelen ze lafen, awer nëmmen mat op d'mannst engem groussen Aarbechter Node.

Минусы

Nodeel Nr 1. Vill Pods pro Node
Wann déi selwecht Aufgab op manner Wirbelen ausgefouert gëtt, da wäert jidderee vun hinnen natierlech méi Pods hunn.

Dëst kéint e Problem ginn.

De Grond ass datt all Modul e puer Overhead un d'Container Runtime agefouert (zB Docker), souwéi de Kubelet an cAdvisor.

Zum Beispill probéiert e Kubelet regelméisseg all Container op engem Node fir Iwwerliewensfäegkeet - wat méi Container, wat méi Aarbecht de Kubelet muss maachen.

CAdvisor sammelt Ressourceverbrauchsstatistike fir all Container op engem Node, a kubelet freet regelméisseg dës Informatioun a liwwert se iwwer eng API. Erëm, méi Container bedeit méi Aarbecht fir béid cAdvisor a Kubelet.

Wann d'Zuel vun de Moduler eropgeet, kann et de System verlangsamen an och seng Zouverlässegkeet ënnergruewen.

Am Kubernetes Repository e puer beschwéiertdatt Node sprangen tëscht Ready / NotReady Statusen well regelméisseg Kubelet Kontrollen vun all Container op engem Node ze laang daueren.
Aus dësem Grond Kubernetes recommandéiert net méi wéi 110 Pods pro Node ze placéieren. Ofhängeg vun der Leeschtung vum Node, kënnt Dir méi Pods pro Node lafen, awer et ass schwéier virauszesoen ob et Problemer gëtt oder alles gutt funktionnéiert. Et ass derwäert d'Aarbecht am Viraus ze testen.

Nodeel Nr 2. Limitatioun op Replikatioun
Ze wéineg Noden limitéieren den effektiven Ausmooss vun der Applikatiounsreplikatioun. Zum Beispill, wann Dir eng héich Verfügbarkeetsapplikatioun mat fënnef Repliken awer nëmmen zwee Wirbelen hutt, da gëtt den effektive Replikatiounsgrad vun der Applikatioun op zwee reduzéiert.

Fënnef Repliken kënnen nëmmen iwwer zwee Wirbelen verdeelt ginn, a wann ee vun hinnen klappt, hëlt se e puer Repliken op eemol erof.

Wann Dir fënnef Wirbelen oder méi hutt, leeft all Replica op engem getrennten Node, an den Ausfall vun engem Node wäert maximal eng Replika ewechhuelen.

Also, héich Disponibilitéit Ufuerderunge kënnen eng gewëssen Minimum Zuel vun Wirbelen am Stärekoup verlaangen.

Nodeel Nr 3. Méi schlëmm Konsequenze vum Echec
Mat enger klenger Zuel vu Wirbelen huet all Echec méi sérieux Konsequenzen. Zum Beispill, wann Dir nëmmen zwee Wirbelen hutt an ee vun hinnen feelt, verschwannen d'Halschent vun Äre Moduler direkt.

Natierlech wäert Kubernetes d'Aarbechtslaascht vum gescheiterten Node op anerer migréieren. Awer wann et e puer vun hinnen sinn, da kann et net genuch fräi Kapazitéit sinn. Als Resultat sinn e puer vun Ären Uwendungen net verfügbar bis Dir de gescheitert Node bréngt.

Also, wat méi Noden, wat manner den Impakt vun Hardwarefehler ass.

Nodeel # 4: Méi autoscaling Schrëtt
Kubernetes huet e Cluster Auto-Scaling System fir Cloud Infrastruktur, wat Iech erlaabt automatesch Noden ze addéieren oder ewechzehuelen ofhängeg vun Ären aktuellen Bedierfnesser. Mat gréisseren Noden gëtt d'Autoskaléierung méi abrupt a clunky. Zum Beispill, op zwee Wirbelen, andeems en zousätzleche Node derbäigesat gëtt, wäert d'Clusterkapazitéit direkt ëm 50% erhéijen. An Dir musst fir dës Ressourcen bezuelen, och wann Dir se net braucht.

Also, wann Dir plangt automatesch Cluster-Skaléierung ze benotzen, wat méi kleng d'Knäppercher sinn, dest méi flexibel a kosteneffektiv Skala kritt Dir.

Loosst eis elo d'Virdeeler an Nodeeler vun enger grousser Zuel vu klenge Wirbelen kucken.

Zweet Optioun: vill kleng Wirbelen

D'Virdeeler vun dëser Approche stamen am Wesentlechen aus den Nodeeler vun der entgéintgesate Optioun mat verschiddene grousse Wirbelen.

Plus

Pro #1: Manner Impakt vum Echec
Wat méi Noden, wat manner Pods op all Node. Zum Beispill, wann Dir honnert Moduler pro zéng Wirbelen hutt, da wäert all Node eng Moyenne vun zéng Moduler hunn.

Op dës Manéier, wann ee vun de Wirbelen ausfällt, verléiert Dir nëmmen 10% vun der Aarbechtsbelaaschtung. D'Chancen sinn datt nëmmen eng kleng Unzuel vu Repliken betraff sinn an d'Gesamtapplikatioun bleift operationell.

Zousätzlech wäerten déi verbleiwen Noden wahrscheinlech genuch fräi Ressourcen hunn fir d'Aarbechtslaascht vum gescheiterten Node ze handhaben, sou datt Kubernetes d'Pods fräi kënne plangen an Är Uwendungen relativ séier an e funktionnellen Zoustand zréckkommen.

Pro # 2: Gutt Replikatioun
Wann et genuch Wirbelen ass, kann de Kubernetes Scheduler verschidde Wirbelen un all Repliken zouginn. Op dës Manéier, wann en Node feelt, gëtt nëmmen eng Replika betraff an d'Applikatioun bleift verfügbar.

Минусы

Nodeel Nr 1. Schwéier ze kontrolléieren
Grouss Zuel vu Wirbelen si méi schwéier ze managen. Zum Beispill muss all Kubernetes Node mat all deenen aneren kommunizéieren, dat heescht, d'Zuel vun de Verbindungen wiisst quadratesch, an all dës Verbindunge mussen verfollegt ginn.

Den Node Controller am Kubernetes Controller Manager geet regelméisseg duerch all Noden am Cluster fir d'Gesondheet ze kontrolléieren - wat méi Noden, wat méi Belaaschtung op de Controller.

D'Laascht op der etcd Datebank wiisst och - all Kubelet a Kube-Proxy rifft bewaacht fir etcd (iwwer d'API), op déi etcd Objektupdates iwwerdroe soll.

Am Allgemengen setzt all Aarbechter Node zousätzlech Belaaschtung op d'Systemkomponente vun de Masterknäppchen.

Kubernetes ënnerstëtzt offiziell Cluster mat Zuel vun Node bis zu 5000. Wéi och ëmmer, an der Praxis ginn et schonn 500 Wirbelen kann net-trivial Problemer verursaachen.

Fir eng grouss Zuel vun Aarbechter Wirbelen ze verwalten, sollt Dir méi mächteg Meeschtesch Wirbelen wielen. Zum Beispill, kube-up automatesch installéiert déi richteg VM Gréisst fir de Meeschtesch Node ofhängeg vun der Zuel vun Aarbechter Node. Dat ass, wat méi Aarbechterknäppchen, wat méi produktiv d'Masterknäppchen solle sinn.

Fir dës spezifesch Problemer ze léisen ginn et speziell Entwécklungen, wéi z Virtuell Kubelet. Dëse System erlaabt Iech Restriktiounen ëmzegoen a Cluster mat enger riesecher Unzuel vun Aarbechternoden ze bauen.

Nodeel # 2: Méi Overhead Käschten.
Op all Aarbechter Node leeft Kubernetes eng Rei vu Systemdemonen - dës enthalen d'Container Runtime (wéi Docker), Kube-Proxy a Kubelet, dorënner cAdvisor. Zesummen verbrauchen se eng gewëssen fixe Betrag u Ressourcen.

Wann Dir vill kleng Wirbelen hutt, ass den Undeel vun dësem Overhead op all Node méi grouss. Zum Beispill, virstellen, datt all System Daemon op engem eenzege Node zesummen benotzen 0,1 CPU Kär an 0,1 GB Erënnerung. Wann Dir een zéng-Kär Node mat 10 GB vun Erënnerung hutt, da verbrauchen Daemonen 1% vun der Clusterkapazitéit. Op der anerer Säit, op zéng Single-Core Noden mat 1 GB Erënnerung, huelen d'Dämonen 10% vun der Clusterkapazitéit.

Also, wat manner Noden, dest méi effizient gëtt d'Infrastruktur benotzt.

Nodeel Nr 3. Ineffizient Notzung vu Ressourcen
Op klenge Wirbelen kann et sinn datt déi verbleiwen Ressource Stécker ze kleng sinn fir all Aarbechtslaascht unzeweisen, sou datt se onbenotzt bleiwen.

Zum Beispill erfuerdert all Pod 0,75 GB Erënnerung. Wann Dir zéng Wirbelen hutt, jidderee mat 1GB Erënnerung, kënnt Dir zéng Pods lafen, andeems all Node mat 0,25GB vun onbenotzten Erënnerung hannerloosst.

Dëst bedeit datt 25% vum ganze Stärekoup Erënnerung verschwonnen ass.

Op engem grousse Node mat 10 GB Erënnerung, Dir kënnt 13 vun dëse Moduler lafen - an et gëtt nëmmen een onbenotzten Fragment vun 0,25 GB.

An dësem Fall sinn nëmmen 2,5% vun der Erënnerung verschwonnen.

Sou ginn d'Ressourcen méi optimal op gréisseren Noden benotzt.

Verschidde grouss Wirbelen oder vill kleng?

Also, wat ass besser: e puer grouss Wirbelen an engem Cluster oder vill kleng? Wéi ëmmer gëtt et keng kloer Äntwert. Vill hänkt vun der Aart vun der Applikatioun of.

Zum Beispill, wann eng Applikatioun 10 GB Erënnerung erfuerdert, sinn gréisser Noden eng offensichtlech Wiel. A wann d'Applikatioun zéngfach Replikatioun fir héich Disponibilitéit erfuerdert, ass et kaum de Risiko wäert fir Repliken op nëmmen zwee Wirbelen ze placéieren - et muss e Minimum vun zéng Wirbelen am Cluster sinn.

An zwëschen Situatiounen, maacht e Choix op Basis vun de Virdeeler an Nodeeler vun all Optioun. Vläicht sinn e puer Argumenter méi relevant fir Är Situatioun wéi anerer.

An et ass guer net néideg fir all Wirbelen déiselwecht Gréisst ze maachen. Näischt verhënnert datt Dir fir d'éischt mat Noden vun der selwechter Gréisst experimentéiert, dann Node vun enger anerer Gréisst derbäi addéieren, se an engem Cluster ze kombinéieren. Aarbechtsknäppchen an engem Kubernetes Cluster kënne komplett heterogen sinn. Also kënnt Dir probéieren d'Virdeeler vu béide Approche ze kombinéieren.

Et gëtt keen eenzegt Rezept, an all Situatioun huet seng eegen Nuancen, an nëmmen d'Produktioun wäert d'Wourecht weisen.

Iwwersetzung virbereet vum Cloud Plattform Team Mail.ru Cloud Léisunge.

Méi iwwer Kubernetes: 25 Nëtzlech Tools fir Cluster ze managen an z'installéieren.

Source: will.com