Ajánlott eljárások a nagy számítási feladatok teljesítményéhez és méretezéséhez az Azure Kubernetes Service-ben (AKS)

Feljegyzés

Ez a cikk a nagy számítási feladatok általános ajánlott eljárásait ismerteti. A kis és közepes számítási feladatokra vonatkozó ajánlott eljárásokért tekintse meg az Azure Kubernetes Service (AKS) kis és közepes számítási feladatok teljesítményével és méretezésével kapcsolatos ajánlott eljárásokat.

A fürtök AKS-ben való üzembe helyezése és karbantartása során az alábbi ajánlott eljárásokkal optimalizálhatja a teljesítményt és a skálázást.

Ne feledje, hogy a nagy relatív kifejezés. A Kubernetes többdimenziós méretezési borítékot használ, és a számítási feladat méretezési borítékja a használt erőforrásoktól függ. Egy 100 csomópontot és több ezer podot vagy CRD-t tartalmazó fürt például nagynak tekinthető. A vezérlősík szempontjából egy 1000 csomópontos fürt 1000 podot és számos más erőforrást tartalmazhat. A Kubernetes-vezérlősík skálázásához a legjobb jel az API-kiszolgáló HTTP-kéréseinek sikeressége és késése, mivel ez a vezérlősík terhelésének proxyja.

Ebben a cikkben a következő tudnivalókat ismerheti meg:

  • Az AKS és a Kubernetes vezérli a sík méretezhetőségét.
  • A Kubernetes-ügyfél ajánlott eljárásai, beleértve a visszalépést, az órákat és a lapozást.
  • Az Azure API és a platform szabályozási korlátai.
  • Funkciókorlátozások.
  • Ajánlott eljárások a hálózatkezelés és a csomópontkészlet skálázásához.

Az AKS és a Kubernetes vezérli a sík méretezhetőségét

Az AKS-ben a fürtök olyan csomópontokból (fizikai vagy virtuális gépekből (virtuális gépek)) állnak, amelyek Kubernetes-ügynököket futtatnak, és amelyeket az AKS által üzemeltetett Kubernetes vezérlősík felügyel. Bár az AKS optimalizálja a Kubernetes vezérlősíkját és összetevőit a méretezhetőség és a teljesítmény szempontjából, továbbra is a felsőbb rétegbeli projektkorlátok kötik.

A Kubernetes többdimenziós méretezési borítékkal rendelkezik, amelynek minden erőforrástípusa dimenziót jelöl. Nem minden erőforrás egyforma. Az órák például általában titkos kódokra vannak beállítva, ami a kube-apiserver felé irányuló listahívásokat eredményez, amelyek költséggel járnak, és aránytalanul nagyobb terhelést jelentenek a vezérlősíkon, mint az órák nélküli erőforrások.

A vezérlősík kezeli a fürt összes erőforrás-méretezését, így minél jobban skálázza a fürtöt egy adott dimenzión belül, annál kevesebbet skálázhat más dimenziókon belül. Ha például több százezer podot futtat egy AKS-fürtben, az hatással van arra, hogy a vezérlősík mennyi podváltozást (podmutáció másodpercenként) támogat.

A boríték mérete arányos a Kubernetes vezérlősík méretével. Az AKS három vezérlősíkszintet támogat az Alap termékváltozat részeként: Ingyenes, Standard és Prémium szint. További információ: Ingyenes, Standard és Prémium tarifacsomagok az AKS-fürtkezeléshez.

Fontos

Javasoljuk, hogy éles vagy nagy léptékű számítási feladatokhoz használja a Standard vagy a Premium szintet. Az AKS automatikusan felskálázza a Kubernetes vezérlősíkot a következő méretezési korlátok támogatásához:

  • AKS-fürtönként legfeljebb 5000 csomópont
  • 200 000 pod AKS-fürtönként (Az Azure CNI átfedésével)

A méretezési korlát küszöbértékének átlépése a legtöbb esetben teljesítménycsökkenést eredményez, de nem eredményezi a fürt azonnali feladatátvételét. A Kubernetes vezérlősík terhelésének kezeléséhez fontolja meg a skálázást az aktuális skálázás 10–20%-ának megfelelő kötegekben. Egy 5000 csomópontos fürt esetében például 500–1000 csomópontra skálázható. Bár az AKS automatikusan skálázja a vezérlősíkot, nem történik meg azonnal.

Az API Priority and Fairness (APF) használatával bizonyos ügyfeleket és kéréstípusokat szabályozhat a vezérlősík védelme érdekében a nagy adatforgalom és terhelés során.

Kubernetes-ügyfelek

A Kubernetes-ügyfelek a Kubernetes-fürtben üzembe helyezett alkalmazás-ügyfelek, például operátorok vagy figyelési ügynökök, amelyeknek kommunikálniuk kell a Kube-API-kiszolgálóval olvasási vagy mutációs műveletek végrehajtásához. Fontos, hogy optimalizálja ezeknek az ügyfeleknek a viselkedését, hogy minimalizálja a Kube-API-kiszolgálóhoz és a Kubernetes vezérlősíkhoz hozzáadott terhelést.

Az API-kiszolgáló forgalmát és az ügyfél viselkedését a Kube auditnaplóiban elemezheti. További információ: A Kubernetes vezérlősík hibaelhárítása.

A LIST-kérelmek költségesek lehetnek. Ha olyan listákkal dolgozik, amelyek több mint néhány ezer kis objektumot vagy több mint néhány száz nagyméretű objektumot tartalmazhatnak, a következő irányelveket kell figyelembe vennie:

  • Vegye figyelembe, hogy egy új erőforrástípus (CRD) definiálásakor hány objektum (CR) létezni fog.
  • Az ETCD- és API-kiszolgáló terhelése elsősorban a létező objektumok számán alapul, nem a visszaadott objektumok számán. Ezek az irányelvek még akkor is érvényesek, ha mezőválasztóval szűri a listát, és csak kis számú találatot kér le. Az egyetlen kivétel az egyetlen objektum beolvasása a következő szerint metadata.name: .
  • Ha lehetséges , kerülje az ismétlődő LIST-hívásokat, ha a kódnak meg kell őriznie a memóriában lévő objektumok frissített listáját. Ehelyett fontolja meg a legtöbb Kubernetes-kódtárban biztosított Informer-osztályok használatát. Az informátorok automatikusan egyesítik a LIST és a WATCH funkciókat a memóriabeli gyűjtemény hatékony fenntartása érdekében.
  • Fontolja meg, hogy erős konzisztenciára van-e szüksége, ha az informátorok nem felelnek meg az igényeinek. Látnia kell a legfrissebb adatokat, egészen a lekérdezés kiadásának pontos időpontjáig? Ha nem, állítsa be a következőt ResourceVersion=0: . Emiatt az API-kiszolgáló gyorsítótára az ETCD helyett a kérést szolgálja ki.
  • Ha nem tudja használni az Informereket vagy az API-kiszolgáló gyorsítótárát, olvassa el a nagy listákat adattömbökben.
  • Kerülje a szükségesnél gyakrabban a listázást. Ha nem tudja használni az informátorokat, fontolja meg, hogy az alkalmazás milyen gyakran listázza az erőforrásokat. Miután elolvasta az utolsó objektumot egy nagy listában, ne kérdezd le azonnal újra ugyanazt a listát. Inkább várjon egy kicsit.
  • Fontolja meg az ügyfélalkalmazás futó példányainak számát. Nagy különbség van abban, hogy egyetlen vezérlő sorolja fel az objektumokat, és hogy mindegyik csomópont podjai ugyanezt teszik. Ha azt tervezi, hogy az ügyfélalkalmazás több példánya is rendszeresen nagy számú objektumot listáz, a megoldás nem méretezhető nagy fürtökre.

Az Azure API és a platform szabályozása

A felhőalkalmazások terhelése idővel változhat olyan tényezőktől függően, mint az aktív felhasználók száma vagy a felhasználók által végrehajtott műveletek típusai. Ha a rendszer feldolgozási követelményei túllépik a rendelkezésre álló erőforrások kapacitását, a rendszer túlterheltté válhat, és gyenge teljesítmény és hibák léphetnek fel.

A felhőalkalmazások eltérő terhelési méreteinek kezeléséhez engedélyezheti, hogy az alkalmazás egy megadott korlátig használjon erőforrásokat, majd a korlát elérésekor szabályozza őket. Az Azure-ban a szabályozás két szinten történik. Az Azure Resource Manager (ARM) szabályozza az előfizetésre és a bérlőre vonatkozó kéréseket. Ha a kérelem az előfizetés és a bérlő szabályozási korlátai alatt van, az ARM átirányítja a kérést az erőforrás-szolgáltatónak. Az erőforrás-szolgáltató ezután a műveleteire szabott szabályozási korlátokat alkalmaz. További információ: ARM-szabályozási kérések.

Szabályozás kezelése az AKS-ben

Az Azure API korlátai általában előfizetés-régió kombinációs szinten vannak meghatározva. Például egy adott régióban lévő előfizetés összes ügyfele osztozik egy adott Azure API API-jának API-korlátain, például a virtuálisgép-méretezési csoportok PUT API-jain. Minden AKS-fürt több AKS-tulajdonú ügyféllel rendelkezik, például felhőszolgáltatóval vagy fürt automatikus skálázásával, vagy olyan ügyfél tulajdonában lévő ügyfelekkel, mint a Datadog vagy a saját üzemeltetésű Prometheus, amelyek Azure API-kat hívnak. Ha egy adott régión belül több AKS-fürtöt futtat egy előfizetésben, a fürtöken belüli összes AKS-tulajdonú és ügyfél által birtokolt ügyfél közös API-korlátokkal rendelkezik. Ezért az előfizetési régióban üzembe helyezhető fürtök száma az üzembe helyezett ügyfelek számának, hívási mintáinak, valamint a fürtök általános méretének és rugalmasságának függvénye.

A fenti szempontokat szem előtt tartva az ügyfelek általában előfizetési régiónként 20–40 kis és közepes méretű fürtöt tudnak üzembe helyezni. Az alábbi ajánlott eljárásokkal maximalizálhatja az előfizetések méretezését:

Mindig frissítse a Kubernetes-fürtöket a legújabb verzióra. Az újabb verziók számos olyan fejlesztést tartalmaznak, amelyek a teljesítményt és a szabályozással kapcsolatos problémákat kezelik. Ha a Kubernetes frissített verzióját használja, és továbbra is szabályozást lát a tényleges terhelés vagy az előfizetésben lévő ügyfelek száma miatt, próbálkozzon az alábbi lehetőségekkel:

  • Hibák elemzése az AKS-problémák diagnosztizálása és megoldása használatával: Az AKS-sel diagnosztizálhatja és megoldhatja a hibákat, azonosíthatja a kiváltó okot, és megoldási javaslatokat kaphat.
    • A fürt automatikus méretezési időközének növelése: Ha a diagnosztikai jelentések azt mutatják, hogy a fürt automatikus skálázási szabályozása észlelhető, növelheti a vizsgálati időközt, hogy csökkentse a virtuálisgép-méretezési csoportokhoz érkező hívások számát a fürt automatikus skálázási eszközéről.
    • Konfigurálja újra a külső alkalmazásokat, hogy kevesebb hívást kezdeményezhessenek: Ha felhasználói ügynökök szerint szűr a Kérések megtekintése arányban, és szabályozza a részletes diagnosztikai adatokat, és azt látja, hogy egy külső alkalmazás, például egy monitorozási alkalmazás nagy számú GET-kérést végez, módosíthatja ezeknek az alkalmazásoknak a beállításait, hogy csökkentse a GET-hívások gyakoriságát. Győződjön meg arról, hogy az alkalmazás-ügyfelek exponenciális visszalépést használnak az Azure API-k hívásakor.
  • A fürtök felosztása különböző előfizetésekre vagy régiókra: Ha nagy számú fürt és csomópontkészlet használja a virtuálisgép-méretezési csoportokat, feloszthatja őket különböző előfizetésekre vagy régiókra ugyanabban az előfizetésben. A legtöbb Azure API-korlát meg van osztva az előfizetési régió szintjén, így a fürtöket áthelyezheti vagy skálázhatja különböző előfizetésekre vagy régiókra, hogy feloldhassa az Azure API szabályozásának letiltását. Ez a lehetőség különösen akkor hasznos, ha azt várja, hogy a fürtök nagy aktivitással rendelkezzenek. Ezekre a korlátokra nincsenek általános irányelvek. Ha konkrét útmutatásra van szüksége, létrehozhat egy támogatási jegyet.

Funkciókorlátozások

Az AKS-fürtök nagyobb léptékű pontokra való skálázása során tartsa szem előtt az alábbi funkciókra vonatkozó korlátozásokat:

Feljegyzés

A vezérlősík skálázási művelete során akár 15 percig is megemelkedett API-kiszolgálói késés vagy időtúllépések fordulhatnak elő. Ha továbbra is problémákat tapasztal a támogatott korlátra való skálázás során, nyisson meg egy támogatási jegyet.

  • Az Azure Network Policy Manager (Azure npm) legfeljebb 250 csomópontot támogat.
  • Egyes AKS-csomópontmetrikák, köztük a csomópontlemez-használat, a csomópont processzor-/memóriahasználata, valamint a hálózati be- és kimenő hálózat nem lesznek elérhetők az Azure Monitor platformmetrikáiban a vezérlősík felskálázása után. Annak ellenőrzéséhez, hogy a vezérlősík fel lett-e skálázva, keresse meg a "control-plane-scaling-status" konfigurációtérképet
kubectl describe configmap control-plane-scaling-status -n kube-system
  • A Leállítás és indítás funkció nem használható 100-nál több csomópontot tartalmazó fürtökkel. További információ: AKS-fürt leállítása és indítása.

Hálózat

Az AKS-fürtök nagyobb méretezési pontokra való skálázása során tartsa szem előtt az alábbi ajánlott hálózatkezelési eljárásokat:

  • Felügyelt NAT használata a fürt kimenő forgalmához legalább két nyilvános IP-címmel a NAT-átjárón. További információ: Felügyelt NAT-átjáró létrehozása az AKS-fürthöz.
  • Az Azure CNI Overlay használatával fürtenként akár 200 000 podot és 5000 csomópontot is skálázhat. További információ: Az Azure CNI átfedéses hálózatkezelésének konfigurálása az AKS-ben.
  • Ha az alkalmazásnak közvetlen pod–pod kommunikációra van szüksége a fürtök között, használja az Azure CNI-t dinamikus IP-lefoglalással, és fürtenként legfeljebb 50 000 alkalmazás podot skálázhat, podonként egy irányítható IP-címmel. További információ: Azure CNI-hálózatkezelés konfigurálása dinamikus IP-kiosztáshoz az AKS-ben.
  • Ha belső Kubernetes-szolgáltatásokat használ egy belső terheléselosztó mögött, javasoljuk, hogy hozzon létre egy belső terheléselosztót vagy szolgáltatást egy 750 csomópontos skálázás alatt az optimális skálázási teljesítmény és a terheléselosztó rugalmassága érdekében.
  • Az Azure npm legfeljebb 250 csomópontot támogat. Ha nagyobb fürtökre szeretné érvényesíteni a hálózati szabályzatokat, fontolja meg a Cilium által működtetett Azure CNI használatát, amely az Azure CNI robusztus vezérlősíkját a Cilium adatsíkkal kombinálva biztosítja a nagy teljesítményű hálózatkezelést és biztonságot.

Csomópontkészlet skálázása

Az AKS-fürtök nagyobb léptékű pontokra való skálázása során tartsa szem előtt az alábbi csomópontkészlet-méretezési ajánlott eljárásokat:

  • Rendszercsomópont-készletek esetén használja a Standard_D16ds_v5 termékváltozatot vagy egy egyenértékű mag/memória virtuálisgép-termékváltozatot rövid élettartamú operációsrendszer-lemezekkel, hogy elegendő számítási erőforrást biztosítson a kube-system podokhoz.
  • Mivel az AKS csomópontkészletenként legfeljebb 1000 csomópontot tartalmazhat, javasoljuk, hogy hozzon létre legalább öt felhasználói csomópontkészletet, hogy akár 5000 csomópontot is felskálázhassa.
  • Nagy léptékű AKS-fürtök futtatásakor a fürt automatikus skálázási funkcióját használva, amikor csak lehetséges, biztosítsa a csomópontkészletek dinamikus skálázását a számítási erőforrások iránti igény alapján. További információ: AKS-fürtök automatikus méretezése az alkalmazásigényeknek megfelelően.
  • Ha több mint 1000 csomópontot skáláz, és nem használja a fürt automatikus skálázását, javasoljuk, hogy egyszerre 500–700 csomópontból álló kötegekben skálázható. A skálázási műveleteknek kétperces és öt perces várakozási idővel kell rendelkezniük a vertikális felskálázási műveletek között, hogy megakadályozzák az Azure API szabályozását. További információ: API management: Gyorsítótárazási és szabályozási szabályzatok.

Fürtfrissítési szempontok és ajánlott eljárások

  • Amikor egy fürt eléri az 5000 csomópontkorlátot, a fürtfrissítések le lesznek tiltva. Ez a korlátozás megakadályozza a frissítést, mert a maximális túlfeszültség-tulajdonságkorláton belül nincs elérhető csomópontkapacitás a gördülő frissítések végrehajtásához. Ha a fürt ennél a korlátnál van, javasoljuk, hogy a fürt frissítése előtt 3000 csomópont alatt skálázhatja le a fürtöt . Ez további kapacitást biztosít a csomópontok átviteléhez, és minimalizálja a vezérlősík terhelését.
  • Az 500-nál több csomóponttal rendelkező fürtök frissítésekor ajánlott a csomópontkészlet kapacitásának 10–20%-át meghaladó maximális túlfeszültség-konfigurációt használni. Az AKS az alapértelmezett 10%-os értékkel konfigurálja a frissítéseket a maximális túlfeszültséghez. Csomópontkészletenként testre szabhatja a maximális túlfeszültség-beállításokat, hogy lehetővé tegye a frissítési sebesség és a számítási feladatok megszakadása közötti kompromisszumot. A maximális túlfeszültség-beállítások növelésekor a frissítési folyamat gyorsabban befejeződik, de a frissítési folyamat során fennakadások léphetnek fel. További információt a csomópontok túlfeszültség-frissítésének testreszabása című témakörben talál.
  • További fürtfrissítési információkért lásd : AKS-fürt frissítése.