Container Platform Networking a Cruise-on

A Google Kubernetes Engine használata többfelhős, privát hibrid hálózattal.

Szerzők: Karl Isenberg és Buck Wallander

Ez a Cruise PaaS-ről szóló sorozatunk harmadik része:

1. "Konténerplatform építése"
2. "Container Platform Security"

Maradjon velünk, ha többet szeretne megtudni a megfigyelhetőségről és a telepítésről!

Korábbi bejegyzéseinkben bemutattuk, hogy a Cruise PaaS hogyan ölel fel több Google Kubernetes Engine (GKE) fürtöt több Google Cloud Provider (GCP) környezetben és projektben, egy csomó kiegészítővel, amelyek növelik a GKE funkcionalitását és biztonságát, valamint privát hibrid-felhő hálózatunk.

Ebben a bejegyzésben kitérünk arra, hogy miért van szükségünk privát hibrid-felhő-hálózatra, és hogyan működik az, hogy egy újabb biztonsági réteget nyújtson a Cruise PaaS körül, valamint annak más belső Cruise-munkaterhelésekkel való interakciója.

Miért Privát? Miért hibrid?

Ahhoz, hogy a Cruise gyorsan (de biztonságosan) el tudjon haladni azon célunk felé, hogy egy teljesen autonóm járműveket használó fuvarozási szolgáltatást indítsunk el, hatalmas mennyiségű (virtuális és fizikai) hardverhez kell hozzáférnünk a legkülönfélébb munkaterhelések futtatásához. Ezek a munkaterhelések hatalmas tesztfolyamatokat, gépi tanulási fürtöket és adattudományi elemzéseket tartalmaznak, valamint több elosztott háttérrendszert, amelyek megkönnyítik az utazások megosztását, a térképezést és a flottakezelést. A hardverigények sokféleségének és mértékének kielégítése érdekében helyszíni adatközpontokat és több nyilvános felhőt is használunk.

Amikor az autó visszatér egy csomóponti helyre, a rögzített adatokat kivonják és feltöltik a felhőbe privát üvegszálas vonalakon keresztül.

Például az egyik hibrid kapcsolatot igénylő munkafolyamat az autókamerák, lidarok, radarok és más érzékelők felvételeinek elemzése. Sokan azt feltételezik, hogy az ilyen típusú adatokat az autóból a felhőbe sugározzák, de a valóságban annyi adat keletkezik ezekből a műszerekből, hogy az LTE-n vagy akár az 5G-n valós időben valós idejű streamelés egyszerűen lehetetlen. nincs elég sávszélesség. Ehelyett az érzékelőadatok az autóban lévő helyi lemezeken vannak pufferelve. Amikor az autó visszatér egy csomóponti helyre, a rögzített adatokat kivonják és feltöltik a felhőbe privát üvegszálas vonalakon keresztül.

Rengeteg más felhasználási eset is létezik, de ez önmagában elegendő egy privát hibrid hálózat szükségességéhez az esetlegesen érzékeny (és terjedelmes) adatok biztonságos átviteléhez az adatközpontok és a felhők között. A felhőbe kerülve az autóadatokat feldolgozzák, újraformázzák, darabokra vágják, és számos belső célra felhasználják, például tesztelésre, adatelemzésre, szimulációra és gépi tanulásra.

A Cruise nagyon komolyan veszi a biztonságot. Emiatt szinte az összes számítástechnikai infrastruktúránkban magánhálózatokat használunk, csak azokat a szolgáltatásokat tesszük ki a nyilvános internetnek, amelyekhez külsőleg is hozzá kell férni. A magánhálózaton való tartózkodás nem szünteti meg a belső szolgáltatások fokozott biztonságának szükségességét – ez csak egy újabb védelmet ad a kompromisszumokkal szemben.

A Cruise PaaS a régóta működő szolgáltatásaink, kötegelt munkáink és adatfolyamaink többségét a magánhálózaton futtatja. Ezenkívül biztonságos be- és kilépést biztosít a magánhálózatba és a nyilvános internetbe.

Ennek a hálózati funkciónak a GKE melletti biztosításához számos különböző felhő-erőforrás konfigurálása, kezelése és figyelése szükséges:

• "Virtuális privát felhők (VPC)"
• "Összekapcsolások"
• "Virtuális magánhálózatok (VPN)"
• "Alhálózatok"
• "CIDR tartományok"
• "Útvonalak"
• "NAT átjárók"
• "Tűzfalszabályok"
• "DNS szerverek"
• „Public HTTP(S) Load Balancers”
• „Nyilvános hálózati terheléselosztók”
• "Belső HTTP(S) terheléselosztók"
• "Belső TCP/UDP terheléselosztók"

Mindezen GCP-szolgáltatások mellett számos egyéni és nyílt forráskódú Kubernetes-kiegészítőt is telepítünk a GKE-hálózat kiegészítésére, integrálására vagy újrakonfigurálására.

GCP hibrid csatlakozási lehetőségek

Ahhoz, hogy helyszíni garázsainkat, irodáinkat és adatközpontjainkat távoli felhőszolgáltatókkal összekapcsolhassuk, szükségünk volt egy módra a privát „nagy kiterjedésű hálózat” (WAN) „gerincrendszerünk” kiterjesztésére.

Van egy „régi alapvető igazság” a hálózattervezésben: „Egy méret soha nem felel meg mindenkinek.” Minden hálózat más és más – mindegyiknek megvannak a maga üzleti céljai és a kapcsolódó kihívások, és nincs szerencsétlenség.

A Google tudja ezt, és mint ilyen, számos szállítási lehetőséget biztosított a felhőjéhez, amelyek mindegyike megvan a maga előnye és hátránya. Az alábbiakban egy gyors, magas szintű bepillantást nyújtunk ezekbe a csatlakozási módszerekbe:

Dedikált összekapcsolás

Egy „dedikált összekapcsolással” az adatközpont és a felhő közötti forgalom egy szolgáltató által telepített privát, fizikai vonalon halad át (vagy egy megosztott helymegosztási létesítményben lévő ketrecek között), hogy összekapcsolja webhelyét a Google peremhálózatával. Ön fizet (legalább) havi "portköltséget" a Google-nak a kapcsolat fenntartásáért, valamint a kapcsolódó szolgáltatói költségeket.

Előnyök:

• A GCP hálózati SLA hatálya alá tartozik
• Egyedi csatlakozásonként akár 200 Gbps (2 x 100 Gbps vonal) vagy 80 Gbps (8 x 10 Gbps vonal) sebességet támogat

Hátrányok:

• Kikötői és kiszállási költségek vonatkoznak rá
• Csak belső VPC alhálózati előtagok (nincs "nyilvános társviszony-létesítés" opció)
• „Internet Exchange” (IX) létesítményben való jelenlét szükséges
• Lassú kiépítési átfutási idő, ha új vonalakat kell telepíteni

Partnerek összekapcsolása

A „partner interconnect” révén az adatközpont és a felhő közötti forgalom a szolgáltató tulajdonában lévő meglévő vonalakon halad. Ez a szolgáltató ezután eladja Önnek a kapacitást a megosztott vonalán.

Előnyök:

• A GCP hálózati SLA hatálya alá tartozik
• Gyors kiépítési idő a harmadik fél szállítók számára előre biztosított kapacitásnak köszönhetően
• Egyedi kapcsolatonként 50 Mbps és 10 Gbps közötti sebességet támogat

Hátrányok:

• Kikötői és kiszállási költségek vonatkoznak rá
• Csak belső VPC alhálózati előtagok (nincs "nyilvános társviszony-létesítés" opció)
• Kisebb sávszélesség, mint a dedikált összekapcsolásnál
• Harmadik féltől származó hálózati bejárás és szükséges költségek

Virtuális magánhálózat

A „virtuális magánhálózat” (VPN) révén az adatközpont és a felhő közötti forgalom titkosítása a nyilvános interneten keresztül történik, a meglévő internetkapcsolat és sávszélesség használatával. A VPN-lezárás megköveteli, hogy egy statikus vagy útvonalalapú VPN-re képes helyszíni eszközt üzemeltetjen.

Előnyök:

• A GCP hálózati SLA hatálya alá tartozik
• Azonnali kiépítési idő
• Nincs szükség privát vonalra, az internetes átfedés miatt
• Támogatja a "dinamikus útválasztást" a "Border Gateway Protocol" (BGP) használatával

Hátrányok:

• Lassabb átvitel az IPSec overhead miatt
• Az internet-hozzáférés és a kriptográfiai gyorsítás költségei miatt méretarányosan drága

Közvetlen Peering

A „közvetlen társviszony-létesítéssel” az adatközpont és a Google közötti forgalom közvetlen kapcsolaton halad keresztül, például a Dedicated Interconnecten, de csak a nyilvános IP-címeket használja, nem a privát IP-címeket. Itt valójában nem is kell Google Cloud-ügyfélnek lennie. A közvetlen társviszony-létesítés az „internetes társviszony-létesítés” hagyományos útja a Google-lal összes közszolgáltatásukra, nem csak a GCP-re (YouTube, G Suite stb.).

Előnyök:

• 10 Gb és 100 Gb ingyenes nyilvános társkeresés a Google-lal
• Nincsenek kikötői vagy forgalmi költségek
• Csökkentett internetes kilépési arány a hálózatba a GCP-projektjeihez

Hátrányok:

• A GCP hálózati SLA nem vonatkozik rá
• Csak nyilvános Google IP-előtagok (nem VPC-tudatos)
• Internetes központban (IX) való jelenlét szükséges
• „szolgáltatótól független IP-címterületet” (PI) igényel – legalább /24 nyilvános IPv4-területet, amely nyilvános „autonóm rendszerszámmal” (ASN) van regisztrálva.
• A GCP integrálása a helyszíni hálózatba manuális folyamat lehet
• Nem minden érdekelt felet "fogad el a Google" a közvetlen társkereséshez

Cruise hibrid csatlakozási lehetőségek

A Cruise ezen csatlakozási lehetőségek keverékét használja a költséghatékonyság és a redundancia érdekében: közvetlen összekapcsolás a GCP VPC-k nagy sávszélességű eléréséhez, VPN-ek az olcsó, alacsony sávszélességű vészhelyzeti tartalékokhoz, valamint közvetlen társviszony-létesítés a nyilvános GCP-szolgáltatásokhoz való ingyenes, nagy sávszélességű hozzáféréshez.

A megbízhatóság és a redundancia kritikus fontosságú, hogy a GKE-ben futó szolgáltatások hálózatunk többi tagja számára mindig elérhetőek legyenek.

Az egyik legfontosabb hálózati mérőszámunk a Google Cloud Storage (GCS) átviteli képessége, amelyet adattóként használunk. Mivel azonban a GCS egy nyilvános szolgáltatás, a helyszíni GCS felé irányuló forgalom alapértelmezés szerint nem halad át a GCP-összeköttetéseken, hanem (esetleg lassabb) nyilvános internetszolgáltatói kapcsolatokat használ.

A probléma megkerüléséhez ideális lenne nyilvános társviszony-létesítést beállítani a GCP-összeköttetéseken keresztül (például „AWS Direct Connect Virtual Interfaces”), de a GCP jelenleg nem kínálja ezt. A GCP azonban kínál „Privát Google-hozzáférést (PGA) a helyszíni gazdagépekhez”, amely a nyilvános Google-szolgáltatásokat egy kis, kiszámítható nyilvános IP-tartományon (199.36.153.4/30) teszi elérhetővé. Annak érdekében, hogy a GCP API-domainek a privát intraneten belüli gazdagépeken lévő PGA IP-címekké váljanak, konfigurálnia kell a privát DNS-t egy DNS CNAME-vel (*.googleapis.com -› limited.googleapis.com), amely elfedi a nyilvános A rekordot. Ezután konfigurálhatja a VPC-n lévő GCP Cloud Routereket, hogy (BGP-n keresztül) reklámozzák a PGA IP-tartományt a helyszíni útválasztón. A meghirdetést követően a PGA IP-címek elérhetők a helyszínről a privát összeköttetéseken (vagy VPN-eken) keresztül.

Végül átirányításra van szükségünk a privát GCP VPC-alhálózataink és a nem GCP-alapú privát alhálózataink között a helyszíni és más felhők között. Míg a privát átviteli követelményeink (pl. az iroda a GKE-hez) alacsonyabbak, mint a nyilvános átviteli követelmények (pl. feltöltés a GCS-be), a megbízhatóság és a redundancia kritikus fontosságú ahhoz, hogy a GKE-ben futó szolgáltatások mindig elérhetőek legyenek hálózatunk többi része számára.

Privát hálózati gerinc

Lehetőségeink kiértékelése után úgy döntöttünk, hogy a IX. számú „helymegosztási létesítményekben” egy „point-of-presence” (PoP) rendszert telepítünk, ahol a Google és más felhőszolgáltatók is jelen vannak. Ezek a PoP-k ezután integrálhatók a WAN gerinchálózatunkba, lehetővé téve számunkra, hogy minimális erőfeszítéssel egyszerűen (és gyorsan) kapcsolódjunk a legtöbb felhőszolgáltatóhoz, szolgáltatóhoz és internetszolgáltatóhoz (ISP).

Miután felhőkapcsolataink létrejöttek ezekben a létesítményekben, útválasztóink hídként szolgálnak számos helyszíni privát és felhőhálózatunkhoz.

Minden IX-es létesítményben duplikált összeköttetéseket építünk ki a különböző "szél-elérhetőségi tartományokhoz". Ez lehetővé teszi számunkra, hogy fenntartsuk a rendelkezésre állást és az „SLA-t a Google-lal”. Ezek a tartományok elszigeteltséget biztosítanak az ütemezett karbantartás során, mert ugyanabban a városközpontban nem lesz egyszerre karbantartás miatt két domain. Ez az elkülönítés fontos, ha redundanciára épít.

Belső GCP-útválasztás

Miután létrejött a fizikai kapcsolat a Cruise és a GCP között, ezeket a kapcsolatokat "logikai kapcsolatokkal" osztjuk fel, amelyek VLAN-mellékletként ismertek. Ez végső soron lehetővé teszi számunkra, hogy BGP peering munkameneteket hozzunk létre fizikai útválasztóink és a VPC alhálózatainkat tartalmazó regionális felhőútválasztók között.

Ezen a ponton VPC-ink dinamikusan töltik fel az útvonalakat hálózatunk többi részéből, és lehetővé teszik a GKE és más számítási szolgáltatások teljes belső elérhetőségét a gerinchálózatunkon keresztül. Bármikor, amikor egy erőforrásnak kommunikálnia kell egy IP-címmel azon a VPC-n kívül, amelyben él (beleértve a más VPC-jeinket is), áthalad az Interconnect linken a PoP-nál a legjobb «útvonal-mutató alapján " eljutni oda.

Alhálózatok

A "Kubernetes hálózati modell" minden szolgáltatásnak és podnak egy teljes IP-címet ad az alkalmazásfejlesztés egyszerűsítése érdekében, de ez a tervezési választás a platform konfigurációjának és működésének bonyolításával jár, különösen több Kubernetes-fürt kezelésekor. A GKE-ben két különböző lehetőség kínálkozik a Kubernetes-stílusú hálózatok engedélyezésére: útvonal-alapú hálózatok és VPC-natív hálózatok.

Az útvonalalapú hálózat statikusan lefoglal egy összefüggő IP-blokkot (az alhálózat elsődleges IP-tartományából) minden egyes csomóponthoz, hogy az adott csomóponton lévő pod-ok használhassák. Ezután minden csomópont útválasztóként működik ezen IP-k számára. Ez az eredeti GKE hálózati megvalósítás, de ez nem egy "átfedő hálózat", mint amilyet más környezetekben a Kubernetes-fürtökhöz használhat.

A VPC-natív hálózatok alias IP-címeket (másodlagos IP-címeket) használnak, amelyeket ugyanaz az alhálózat kezel, amely a csomópont IP-címeit (elsődleges IP-címeket) kezeli. A VPC-natív hálózat az alapértelmezett és ajánlott lehetőség néhány jó okból:

1. Az alias IP-k natív módon irányíthatók a hálózaton belül, beleértve a társhálózatokat is.
2. Az alias IP-címeket a BGP-n keresztül a Cloud Router bejelentheti összeköttetések és VPN-ek segítségével, ha szükséges.
3. Az alias IP-címeket a hálózat más számítási erőforrásai nem használhatják, ami megakadályozza az ütközést, és lehetővé teszi a dedikált tűzfalszabályok alkalmazását.
4. Az alias IP-címek hozzáférhetnek a GCP által üzemeltetett szolgáltatásokhoz anélkül, hogy egy NAT-átjárón keresztül kilépnének.

Hátránya, hogy a VPC-natív hálózatok megterhelik a fürt üzemeltetőjét az egyes fürtök számára dedikált másodlagos IP-tartományok kiválasztásában és konfigurálásában. Az IPv4 CIDR-tartományok szeletelése és feldarabolása alapos találgatásokat igényel számos dolog tekintetében:

1. Klaszterek száma
2. Régiók száma
3. Csomópontok száma
4. A hüvelyek száma csomópontonként

Sajnos, hacsak nem vagy ügyes a jövő előrejelzésében, nem valószínű, hogy a kezdeti GKE CIDR blokkok kiállják az idő próbáját. Emiatt fontos, hogy GKE-fürtjeit eldobhatóra tervezze, hogy később módosíthassa a hálózati beállításokat.

Másodlagos IP-tartományok

Kezdetben úgy döntöttünk, hogy régiónként egy alhálózatot használunk, és mindegyiket több fürt osztja meg. Míg azonban az elsődleges IP-tartomány a létrehozás után bővíthető, a másodlagos IP-tartományok nem bővíthetők, amíg a GKE-fürt használja. Még ha ki is bővítené őket, egymás melletti, ki nem osztott IP-címeket kell elérhetővé tennie a hálózaton, ekkor azok előre is lefoglalhatók az alhálózaton.

A gyakorlatban az IP-blokkokat hiányos információk alapján kell kiosztani, és később újra kell értékelni, ahogy a fürt skálázódik, és további pod vagy szolgáltatás IP-címeket igényel. Ez megköveteli a fürt újbóli létrehozását, ami viszont a munkaterhelések fürtök közötti áttelepítését igényli: időigényes, bonyolult és hibákra hajlamos művelet.

Egészen a közelmúltig a GCP-alhálózatok legfeljebb 5 másodlagos IP-tartományt engedélyeztek, és bár a pod IP-tartományok megoszthatók a fürtök között, a szolgáltatási IP-tartományok nem. Ez a korlátozás azt jelentette, hogy egyetlen alhálózaton legfeljebb 4 GKE-fürtöt telepíthetett. A GKE-fürtök egy ideig történő telepítése és üzemeltetése után azonban nyilvánvaló volt, hogy régiónként több mint 4 fürtre lesz szükségünk. A legtöbb bérlőnk által használt általános célú megosztott fürtök mellett további elkülönítést igénylő fürtökre volt szükségünk a teszteléshez, fejlesztéshez és munkaterhelésekhez.

Visszajelzésünkre válaszul a Google szerencsére 30-ra növelte a másodlagos IP-tartományok maximális számát ("hálózati korlátonként"), ami némi lélegzetvételnyi időt adott nekünk.

Változás tervezése

Egy másik kihívás, hogy ha a fürtök megosztják a pod IP-tartományokat, az azt jelenti, hogy nem tudunk törölni egy pod IP-tartományt anélkül, hogy ne törölnénk az azt használó összes fürtöt, így nehéz megváltoztatni, hogy egy fürt mely IP-címeket használja. A dolgok egyszerűbbé és könnyebben módosíthatóvá tétele érdekében áttértünk az egyes GKE-fürtök alhálózatának kiépítésére. Ez egy kicsit több CIDR-matematizálást jelent, de jó építészeti választás, hogy a jövőben könnyen változtassunk a dolgokon.

Ennek a bonyolultságnak a nagy része egyszerűen az IPv4 összetettségének köszönhető. Miután a GCP, a GKE és a Kubernetes támogatja az IPv6-ot, sokkal egyszerűbbnek kell lennie, kevesebb előzetes döntéssel és CIDR-matematika nélkül. Csökkentheti a fürtök kezelésének bonyolultságát az útvonalalapú hálózatok használatával (a VPC-natív hálózatok helyett); a teljesítmény azonban megcsappanna, a behatolási lehetőségek korlátozottabbak lennének, a hamisítás elleni ellenőrzések le vannak tiltva, és a fürt legfeljebb 2000 csomópontra korlátozódna.

Ingress

A GKE bemeneti integrációkat tartalmaz, amelyeknek elég jónak kell lenniük a legtöbb alapvető használati esethez. Egy dolgot azonban figyelembe kell venni, hogy a nyilvános belépési lehetőségek (az internettől a fürtig) robusztusabbak és kiforrottabbak, mint a privát belépési lehetőségek (az intranettől a fürtig) fürt).

A GKE jelenleg négy integrált bemeneti megoldást kínál:

1. A „Külső HTTP(S) Load Balancer” nyilvánosbelépést biztosít, amely támogatja a HTTP(S) protokollt, és 7. rétegbeli terheléselosztást (fordított proxy) használ.
2. A "Belső HTTP(S) Load Balancer" (béta) privátbelépést biztosít, amely támogatja a HTTP(S)-t, és 7. rétegbeli terheléselosztást (fordított proxyk) használ.
3. A Network TCP/UDP Load Balancer (NLB) nyilvánosbelépést biztosít, amely támogatja a TCP-t vagy az UDP-t, és regionális 4. rétegbeli útválasztást (IP-fordítás) használ.
4. Az Internal TCP/UDP Load Balancer (ILB) (Béta) privátbelépést biztosít, amely támogatja a TCP-t vagy az UDP-t, és regionális 4-es szintű útválasztást (IP-fordítás) használ.

Nyilvános belépés

Nyilvános TCP/UDP belépés esetén az NLB-t a Cruise PaaS bérlők konfigurálhatják egy szabványos „Load Balancer típusú Kubernetes Service erőforrás” használatával. Az integrációt biztosító vezérlő a Kubernetes upstream GCP felhőszolgáltatójába van beépítve. Az NLB meglehetősen alacsonyan van implementálva a hálózati veremben, így nem biztosít olyan fejlett funkciókat, mint a munkamenet-ragadás, a beépített hitelesítés vagy az útvonal-alapú útválasztás. Általában csak nem HTTP-forgalomhoz használjuk az NLB-t, kivéve, ha az alkalmazásszintű HTTP-proxy, például az Nginx vagy az Envoy közvetítője.

A HTTP(S) nyilvános belépéshez a Google külső HTTP(S) terheléselosztót használjuk. A nyílt forráskódú „Google Load Balancer Controller (GLBC)” alapértelmezés szerint integrálva van a GKE-vel, lehetővé téve a Cruise PaaS bérlők számára, hogy egy szabványos „Kubernetes Ingress-erőforrás” használatával engedélyezzék a nyilvános bejutást. Ez a ("nemrég általánosan elérhető") megoldás tisztességes funkciókészlettel rendelkezik, beleértve a "Google Cloud Armor"-t (IP-engedélyezéshez), "Cloud Identity-Aware Proxy"-t (engedélyezéshez), HTTP/2- és websocket-támogatást, teljes elszigetelést a behatolások között példányok, és az opcionális TLS-lezárás.

Privát Ingress

TCP/UDP privát belépés esetén az ILB-t a Cruise PaaS bérlők konfigurálhatják a Kubernetes Service Load Balancer típusú erőforrással, ugyanazzal a mechanizmussal, mint az NLB konfigurálásakor, kivéve egy megjegyzéssel, amely azt priváttá teszi (cloud.google.com/ terheléselosztó típusú: belső). Az ILB gyakorlatilag nagyon hasonlít az NLB-hez, azzal a különbséggel, hogy csak a VPC-n belül érhető el, és alapértelmezés szerint csak ugyanazon a régión belül. Tehát az NLB-hez hasonlóan általában az ILB-t használjuk a nem HTTP-forgalomhoz.

A HTTP(S) privát bejutáshoz a Google nemrégiben kiadta az Envoy-alapú belső HTTP(s) Load Balancer-t (2019 közepén még béta állapotban van). Ez a megoldás nagyon ígéretesnek tűnik, de a béta még nem támogatja a Shared VPC-ket, a Google Cloud Armor-t vagy a Cloud Identity-Aware Proxy-t, így nagyobb érettségre van szüksége, mielőtt fontolóra vehetnénk a használatát. Ehelyett az "Nginx Ingress Controller"-t használtuk, amely lehetővé teszi a Cruise PaaS bérlők számára, hogy a Kubernetes Ingress erőforrás-definíción található megjegyzésekkel konfigurálják a terheléselosztást.

Íme egy diagram a kezdeti privát behatolási megoldásunkról, egy bónusz bólintással a „Külső DNS”-re, amelyet szeretnénk hozzáadni a DNS-rekordok könnyebb kezeléséhez:

A behatolási utunk azonban még korántsem ért véget. Miközben több régiót és szolgáltatási hálót vizsgálunk, minden bizonnyal ismételgetnünk kell a belépési megoldásainkat. Kövessétek figyelemmel a jövőbeli blogbejegyzéseket ezekről a témákról!

Kijárat

Ha a GKE-fürtcsomópontjai nyilvános IP-címekkel rendelkeznek, ingyenes kilépést kap az internetre, de ha a nagyobb biztonság érdekében privát alhálózatokon telepíti a csomópontokat (mint mi is), akkor a nyilvános kilépő forgalmának át kell haladnia egy NAT-átjárón, hogy elérje a Internet. Amikor eredetileg telepítettük a GKE-t, saját NAT-átjáróinkat kellett üzembe helyeznünk, a Google „NAT Gateway Terraform Module”-jának segítségével. A Google azonban 2019 elején elindította a „Cloud NAT”-ot, egy teljesen felügyelt megoldást, amely csökkentette mérnökcsapatunk kezelési költségeit.

Hálózati elkülönítés

Érdemes megjegyezni, hogy a Kubernetes natívan nem biztosít „Quality of Service” (QoS) funkciót a be- vagy kilépés elkülönítésére. Az összes hálózati forgalom megosztja az egyes csomópontok erőforrásait, és tágabb értelemben a hálózat erőforrásait. Ennek eredményeként egy Kubernetes pod elég könnyen felemészti a megosztott csomópont vagy a megosztott NAT-átjárók teljes sávszélességét, és szűk keresztmetszetet okoz, ha nem vigyázunk.

Ha most feltétlenül szüksége van a be- és kilépési szigetelésre, előfordulhat, hogy le kell húznia a magasabb rétegű absztrakciókat, és helyette alacsonyabb szintű absztrakciót kell használnia.

A Skylake virtuális gépekre való frissítés segített néhány hálózati szűk keresztmetszetein, mivel „a Google 32 Gbps-ra emelte a kilépési sávszélesség felső határát” (16+ magpéldányon). A legnagyobb sebesség azonban az azonos zóna virtuális gépek közötti forgalomra korlátozódik. Bár az új architektúra továbbra is gyorsabb, mint a korábbi Broadwell architektúra, nem lehet 32 ​​Gbps-t elérni a többzónás klaszteren belül vagy a régiók/felhők közötti teljes forgalomnál.

A „forgalom alakítása” az egyik módja annak, hogy növeljük a hálózati elszigetelést a munkaterhelések között. Például egy „szolgáltatásháló”, mint például az „Istio”, lehetővé teszi a sebességkorlátozást és a kvótákat oldalkocsis proxykkal és be-/kimeneti átjárókkal. Egy másik lehetőség a „Kubernetes Network Plugins” használata, mint például a „Bandwidth Plugin”, amely „a Calico része” a 3.8.0-s verzióban (a GKE-t továbbra is a 3.2.7 verzióban szállítjuk).

A hálózathasználaton alapuló automatikus skálázás egy másik módja annak, hogy elkerüljük az erőforrások kimerülését, csökkentve a bérlők egymásra gyakorolt ​​hatását. A NAT-átjáró automatikus skálázása segít maximalizálni a rendelkezésre állást VPC-szinten. Ha azonban a NAT-átjáróknak statikus nyilvános IP-címei vannak a tűzfal engedélyezőlistájához, akkor ezeket az engedélyezési listákat automatikusan vagy előzetesen frissíteni kell az automatikus skálázás engedélyezéséhez. A terhelési hálózati követelményeken alapuló GKE-fürt automatikus skálázása elméletileg a csomóponti szintű elérhetőség maximalizálását is segítené, de a Kubernetes még nem támogatja a hálózati erőforrásokon alapuló ütemezést. Mindkét lehetőség lehetséges, de jelentős befektetést igényel a megfelelő megoldás.

A konténerhálózat QoS még gyerekcipőben jár a virtuálisgép-infrastruktúra által biztosított szoftveresen meghatározott hálózati képességekhez képest. Ha most feltétlenül szüksége van a be- és kilépési elkülönítésre, előfordulhat, hogy vissza kell húznia a magasabb rétegű absztrakciókat, és helyette alacsonyabb szintű absztrakciót kell használnia, például a virtuális gépeknél. A Google Compute Engine (GCE) virtuális gépei ugyanúgy megosztják a gazdagép-hálózati erőforrásokat, mint a konténerek, de a GCE a „VM-enkénti kilépési átviteli korlát” használatával érvényesíti a QoS-t.

Méretezési szempontok

Nemrég a Google közzétett egy nagyszerű cikket, amely „iránymutatásokat tartalmaz a méretezhető (GKE) fürtök létrehozásához”, amely nagyszerű forrás, amely összegyűjti a GCP- és GKE-dokumentációban található megkötések nagy részét. Emellett a Kubernetes Scalability Special Interest Group (SIG) által összeállított "skálázhatósági küszöbök" némelyikére is épül.

Az egyik legfigyelemreméltóbb megszorítás az 5000 GKE csomópont korlátja. A GKE-dokumentumok ezt korlátnak, a Kubernetes-dokumentumok pedig a leromlott teljesítmény küszöbének nevezik, de kiderül, hogy ez egyben hálózati korlátozás is:

„Egyetlen VPC-hálózat akár 15 000 csatlakoztatott virtuális gépet is tartalmazhat, így gyakorlatilag egy VPC-natív fürt akár 5000 csomópontra is méretezhető.”

Lehetséges, hogy ezt a hálózatonkénti 15 000 virtuális gépes korlátot meg lehet növelni, de érdemes megjegyezni, hogy ez a VPC-re kiterjedő korlátozás, nem csak a fürt megkötése, így további fürtök hozzáadásával a VPC-n belül nem lesz több 5 000 csomópontnál. .

Tekintettel ezekre a megszorításokra, kísértést érezhet a csomópont méretének és sűrűségének maximalizálására, megtartva az alapértelmezett 100 pod/csomópontot. Ez a stratégia akkor is jó ötlet, ha ügynökönként fizet a démonokért, például a DataDogért. De amint fentebb említettük, mérlegelni kell, hogy a platform hálózati összetevői mennyire vertikálisan méretezhetők.

A nagy csomópontokkal kapcsolatos utolsó probléma az, hogy a Kubernetes nem kínál elszigetelést a másodpercenkénti lemezbeviteli/kimeneti műveletekhez (IOPS). Ez azt jelenti, hogy az alkalmazások munkaterhelései felhasználhatják az összes lemez IOPS-t, és megszakíthatják a kritikus összetevőket, például a Docker démont.

A GKE jelenlegi képességeivel a hálózati és lemezmegosztási problémák leküzdésének egyetlen módja a csomópontonként elérhető erőforrások maximalizálása (a legújabb virtuálisgép-architektúrák és a legnagyobb példánytípusok használatával), valamint a csomópontonként ütemezhető podok maximális számának csökkentése. Így minden egyes tok több egyedi kapacitással rendelkezik.

A hüvelyek csomópontonkénti csökkentése általában hatékony, de nem ideális megoldás. Ideális esetben a lemez- és hálózati erőforrásokat a Kubernetes többi erőforrásához (CPU, memória és GPU) hasonlóan kezelik. A kvóták, korlátok és az ütemezésre vonatkozó tippek jobb elkülönítést tesznek lehetővé a pod-ok, névterek és bérlők között. Egy másik probléma a csomópontok számának csökkentésével, hogy megnöveli az azonos munkaterheléshez szükséges csomópontok számát, ami nagyobb valószínűséggel lép fel a csomópontok számának korlátaira.

Előfordulhat, hogy nincs szüksége 5000 csomópontnál többre, különösen, ha 80 maggépről van szó, amelyek mindegyike 100 podot futtat. De ahogy közeledik a kemény csomópont korlátaihoz, valószínűleg más korlátozásokba ütközik, amelyek megkövetelik a GKE-hez tartozó összetevők és integrációk cseréjét, például a terheléselosztókat, a KubeDNS-t vagy a fürt automatikus skálázóját. A Cruise-nál a méretezési igényeink miatt ezeknek az alkatrészeknek a cseréjére már szükségünk volt, de a futásteljesítmény változhat.

Folytatjuk…

Ebben a bejegyzésben elmagyaráztuk, hogy a Cruise hogyan telepíti a Kubernetes-fürtöket magánhálózatokon, hogyan kapcsoljuk össze ezeket a hálózatokat a helyszíni adatközpontjainkkal, és hogyan helyezzük üzembe a méretezhető be- és kilépést a fürtjeink számára. A sorozat következő blogbejegyzésében fürtjeink megfigyelhetőségével és a rajtuk futó munkaterhelésekkel foglalkozunk.

Szeretne segíteni nekünk a platform megépítésében, amely utat nyit az autonóm járművek számára? Tekintse meg "nyitott pozícióinkat".

Frissítve 2019–10–16, hogy javítsa az útvonal-alapú hálózatok leírását és a VPC-natív hálózat előnyeit. Köszönjük Tim Hockinnak a hiba bejelentését.