Az Azure Kubernetes Service (AKS) alkalmazásainak hálózatkezelési fogalmai
Az alkalmazásfejlesztés tárolóalapú mikroszolgáltatás-megközelítésében az alkalmazásösszetevők együttműködnek a feladataik feldolgozásában. A Kubernetes különböző erőforrásokat biztosít az együttműködéshez:
- Az alkalmazásokhoz belsőleg vagy külsőleg is csatlakozhat, és közzéteheti azokat.
- Az alkalmazások terheléselosztásával magas rendelkezésre állású alkalmazásokat hozhat létre.
- A biztonság javítása érdekében korlátozhatja a podok és csomópontok közötti hálózati forgalom áramlását.
- Konfigurálhatja a bejövő forgalmat az SSL/TLS leállításához vagy több összetevő útválasztásához az összetettebb alkalmazásokhoz.
Ez a cikk bemutatja azokat az alapvető fogalmakat, amelyek hálózatkezelést biztosítanak az alkalmazások számára az AKS-ben:
A Kubernetes hálózatkezelési alapjai
A Kubernetes egy virtuális hálózati réteget alkalmaz az alkalmazásokon vagy azok összetevőin belüli és közötti hozzáférés kezelésére:
Kubernetes-csomópontok és virtuális hálózat: A Kubernetes-csomópontok virtuális hálózathoz csatlakoznak. Ez a beállítás lehetővé teszi, hogy a podok (a Kubernetes alapszintű üzembehelyezési egységei) bejövő és kimenő kapcsolattal rendelkezzenek.
Kube-proxy összetevő: a kube-proxy minden csomóponton fut, és felelős a szükséges hálózati szolgáltatások biztosításáért.
Konkrét Kubernetes-funkciókkal kapcsolatban:
- Terheléselosztó: A terheléselosztóval egyenletesen oszthatja el a hálózati forgalmat a különböző erőforrások között.
- Bejövőforgalom-vezérlők: Ezek megkönnyítik a 7. rétegbeli útválasztást, amely elengedhetetlen az alkalmazásforgalom irányításához.
- Kimenő forgalom szabályozása: A Kubernetes lehetővé teszi a fürtcsomópontok kimenő forgalmának kezelését és szabályozását.
- Hálózati szabályzatok: Ezek a házirendek lehetővé teszik a biztonsági intézkedéseket és a podok hálózati forgalmának szűrését.
Az Azure-platform kontextusában:
- Az Azure leegyszerűsíti az AKS-fürtök (Azure Kubernetes Service) virtuális hálózatkezelését.
- Kubernetes-terheléselosztó létrehozása az Azure-ban egyidejűleg beállítja a megfelelő Azure-terheléselosztó-erőforrást.
- Amikor hálózati portokat nyit meg a podok felé, az Azure automatikusan konfigurálja a szükséges hálózati biztonsági csoportszabályokat.
- Az Azure az új bejövő útvonalak létrehozásakor a HTTP-alkalmazások útválasztásának külső DNS-konfigurációit is kezelheti.
Azure-beli virtuális hálózatok
Az AKS-ben üzembe helyezhet egy fürtöt, amely az alábbi hálózati modellek egyikét használja:
Kubenet-hálózatkezelés
A hálózati erőforrások általában az AKS-fürt üzembe helyezésekor jönnek létre és vannak konfigurálva.
Azure Container Networking Interface (CNI) hálózatkezelés
Az AKS-fürt csatlakozik a meglévő virtuálishálózat-erőforrásokhoz és -konfigurációkhoz.
Kubenet (alapszintű) hálózatkezelés
Az AKS-fürt létrehozásának alapértelmezett konfigurációja a kubenet hálózatkezelési beállítás. Kubenettel:
- A csomópontok IP-címet kapnak az Azure-beli virtuális hálózati alhálózattól.
- A podok logikailag eltérő címtérből kapnak IP-címet, mint a csomópontok Azure-beli virtuális hálózati alhálózata.
- A hálózati címfordítás (NAT) konfigurálása lehetővé teszi, hogy a podok hozzáférjenek az Azure-beli virtuális hálózat erőforrásaihoz.
- A forgalom forrás IP-címe a csomópont elsődleges IP-címére lesz lefordítva.
A csomópontok a Kubenet Kubernetes beépülő modult használják. Engedélyezheti az Azure-platform számára a virtuális hálózatok létrehozását és konfigurálását, vagy dönthet úgy, hogy az AKS-fürtöt egy meglévő virtuális hálózati alhálózatban helyezi üzembe.
Csak a csomópontok kapnak egy nem módosítható IP-címet. A podok NAT használatával kommunikálnak az AKS-fürtön kívüli más erőforrásokkal. Ez a módszer csökkenti a podok használatához szükséges ip-címek számát a hálózati térben.
Feljegyzés
Bár az AKS-fürtök alapértelmezett hálózati beállítása a kubenet, amely virtuális hálózatot és alhálózatot hoz létre, éles környezetben nem ajánlott. A legtöbb éles üzemelő példány esetében érdemes megtervezni és használni az Azure CNI hálózatkezelését a kiváló méretezhetőség és a teljesítmény jellemzői miatt.
További információ: Kubenet-hálózatkezelés konfigurálása AKS-fürtökhöz.
Azure CNI (speciális) hálózatkezelés
Az Azure CNI használatával minden pod kap egy IP-címet az alhálózatból, és közvetlenül elérhetővé válik. Ezeket az IP-címeket előre kell megtervezni, és egyedinek kell lenniük a hálózati térben. Minden csomópont rendelkezik egy konfigurációs paraméterrel a támogatott podok maximális számához. A csomópontonkénti IP-címek egyenértékű száma ezután előtérként van fenntartva. Ez a megközelítés az IP-címek kimerüléséhez vagy a fürtök nagyobb alhálózatban való újraépítéséhez vezethet az alkalmazás igényeinek növekedésével, ezért fontos a megfelelő tervezés. A tervezési kihívások elkerülése érdekében lehetővé válik az Azure CNI-hálózatkezelés funkció a IP-címek dinamikus kiosztásához és a továbbfejlesztett alhálózati támogatáshoz.
Feljegyzés
A Kubernetes korlátozásai miatt az erőforráscsoport nevének, a virtuális hálózat nevének és az alhálózat nevének legalább 63 karakternek kell lennie.
A kubenettől eltérően az ugyanazon virtuális hálózaton lévő végpontok felé történő forgalom nem lesz lefordítva (NAT) a csomópont elsődleges IP-címére. A virtuális hálózaton belüli forgalom forráscíme a pod IP-címe. A virtuális hálózaton kívüli forgalom továbbra is a csomópont elsődleges IP-címére irányítja a hálózati adaptereket.
A csomópontok az Azure CNI Kubernetes beépülő modult használják.
További információ: Azure CNI konfigurálása AKS-fürtökhöz.
Azure CNI átfedéses hálózatkezelés
Az Azure CNI Overlay az Azure CNI fejlődését jelenti, amely a virtuális hálózati IP-címek podokhoz való hozzárendeléséből eredő skálázhatósági és tervezési kihívásokat kezeli. Az Azure CNI Overlay privát CIDR IP-címeket rendel a podokhoz. A privát IP-címek elkülönülnek a virtuális hálózattól, és több fürtben is újra felhasználhatók. Az Azure CNI Overlay mérete meghaladhatja a Kubenet-fürtökben érvényes 400 csomópontkorlátot. A legtöbb fürt esetében az Azure CNI Overlay az ajánlott beállítás.
A Ciliumon alapuló Azure CNI
A Cilium által üzemeltetett Azure CNI a Cilium használatával biztosítja a nagy teljesítményű hálózatkezelést, a megfigyelhetőséget és a hálózati szabályzatok érvényesítését. Natív módon integrálható az Azure CNI Overlay szolgáltatással a méretezhető IP-címkezelés (IPAM) érdekében.
Emellett a Cilium alapértelmezés szerint kikényszeríti a hálózati házirendeket anélkül, hogy külön hálózati házirendmotort kellene igényelnie. A Cilium által üzemeltetett Azure CNI az Azure Network Policy Manager 250 csomópont/20 K pod korlátja felett méretezhető ePBF-programok és hatékonyabb API-objektumstruktúra használatával.
Az Azure CNI Powered by Cilium a hálózati házirendek kikényszerítését igénylő fürtök esetében ajánlott.
Saját CNI használata
Az AKS-ben nem Microsoft CNI-t is telepíthet a Saját CNI szolgáltatással.
Hálózati modellek összehasonlítása
Mind a Kubenet, mind az Azure CNI hálózati kapcsolatot biztosít az AKS-fürtök számára. Azonban mindegyiknek vannak előnyei és hátrányai. Magas szinten a következő szempontokat kell figyelembe venni:
kubenet
- Fenntartja az IP-címteret.
- A Kubernetes belső vagy külső terheléselosztóit használja a fürtön kívüli podok eléréséhez.
- Manuálisan kezelheti és kezelheti a felhasználó által definiált útvonalakat (UDR-eket).
- Fürtenként legfeljebb 400 csomópont lehet.
Azure CNI
- A podok teljes virtuális hálózati kapcsolatot kapnak, és közvetlenül elérhetők a csatlakoztatott hálózatokról származó privát IP-címükön keresztül.
- Több IP-címterületre van szükség.
| Hálózati modell | Mikor érdemes használni? |
|---|---|
| Kubenet | • Az IP-címtér-beszélgetés prioritás. • Egyszerű konfiguráció. • Fürtenként kevesebb mint 400 csomópont. • A Kubernetes belső vagy külső terheléselosztói elegendőek ahhoz, hogy a fürtön kívülről érjék el a podokat. • A felhasználó által megadott útvonalak manuális kezelése és karbantartása elfogadható. |
| Azure CNI | • A podokhoz teljes virtuális hálózati kapcsolat szükséges. • Speciális AKS-funkciókra (például virtuális csomópontokra) van szükség. • Elegendő IP-címtér áll rendelkezésre. • Podról podra és podról virtuális gépre való kapcsolat szükséges. • A külső erőforrásoknak közvetlenül kell elérniük a podokat. • AKS hálózati szabályzatokra van szükség. |
| Azure CNI Overlay | • Az IP-címek hiánya aggodalomra ad okot. • Csomópontonként legfeljebb 1000 csomópont és 250 pod méretezése elegendő. • A podkapcsolatok további ugrása elfogadható. • Egyszerűbb hálózati konfiguráció. • Az AKS kimenő követelményeinek eleget lehet tenni. |
A kubenet és az Azure CNI között a következő viselkedésbeli különbségek léteznek:
| Funkció | Kubenet | Azure CNI | Azure CNI Overlay | A Ciliumon alapuló Azure CNI |
|---|---|---|---|---|
| Fürt üzembe helyezése meglévő vagy új virtuális hálózaton | Támogatott – Manuálisan alkalmazott UDR-ek | Támogatott | Támogatott | Támogatott |
| Pod-pod kapcsolat | Támogatott | Támogatott | Támogatott | Támogatott |
| Pod-VM kapcsolat; Virtuális gép ugyanabban a virtuális hálózaton | Működik, ha a pod kezdeményezi | Mindkét módon működik | Működik, ha a pod kezdeményezi | Működik, ha a pod kezdeményezi |
| Pod-VM kapcsolat; Virtuális gép társhálózatban | Működik, ha a pod kezdeményezi | Mindkét módon működik | Működik, ha a pod kezdeményezi | Működik, ha a pod kezdeményezi |
| Helyszíni hozzáférés VPN vagy Express Route használatával | Működik, ha a pod kezdeményezi | Mindkét módon működik | Működik, ha a pod kezdeményezi | Működik, ha a pod kezdeményezi |
| Hozzáférés a szolgáltatásvégpontok által védett erőforrásokhoz | Támogatott | Támogatott | Támogatott | |
| Kubernetes-szolgáltatások közzététele terheléselosztó szolgáltatás, App Gateway vagy bejövőforgalom-vezérlő használatával | Támogatott | Támogatott | Támogatott | Ugyanezek a korlátozások átfedéses mód használata esetén |
| Windows-csomópontkészletek támogatása | Nem támogatott | Támogatott | Támogatott | Csak Linux rendszeren érhető el, Windowshoz nem. |
| Alapértelmezett Azure DNS és privát zónák | Támogatott | Támogatott | Támogatott |
Az Azure CNI-ről és a kubenetről további információt az Azure CNI-ről és a kubenetről, valamint az Azure CNI hálózatkezelésének konfigurálása az AKS-ben és a Kubenet-hálózatkezelés használata az AKS-ben című témakörben talál.
Támogatási hatókör a hálózati modellek között
Bármilyen hálózati modellt is használ, a Kubenet és az Azure CNI is üzembe helyezhető az alábbi módok egyikével:
- Az Azure-platform automatikusan létrehozhatja és konfigurálhatja a virtuális hálózati erőforrásokat egy AKS-fürt létrehozásakor.
- Az AKS-fürt létrehozásakor manuálisan hozhatja létre és konfigurálhatja a virtuális hálózati erőforrásokat, és csatolhatja őket ezekhez az erőforrásokhoz.
Bár a kubenet és az Azure CNI is támogatja az olyan képességeket, mint a szolgáltatásvégpontok vagy az UDR-ek, az AKS támogatási szabályzatai határozzák meg, hogy milyen módosításokat hajthat végre. Példa:
- Ha manuálisan hozza létre a virtuális hálózati erőforrásokat egy AKS-fürthöz, akkor a rendszer támogatja a saját UDR-ek vagy szolgáltatásvégpontok konfigurálásakor.
- Ha az Azure-platform automatikusan létrehozza az AKS-fürt virtuális hálózati erőforrásait, nem módosíthatja manuálisan az AKS által felügyelt erőforrásokat a saját UDR-ek vagy szolgáltatásvégpontok konfigurálásához.
Bemeneti vezérlők
LoadBalancer típusú szolgáltatás létrehozásakor egy mögöttes Azure Load Balancer-erőforrást is létrehoz. A terheléselosztó úgy van konfigurálva, hogy egy adott porton ossza el a forgalmat a szolgáltatás podjai között.
A LoadBalancer csak a 4. rétegben működik. A 4. rétegben a szolgáltatás nem tud a tényleges alkalmazásokról, és nem tud további útválasztási szempontokat figyelembe venni.
A bejövőforgalom-vezérlők a 7. rétegben működnek, és intelligensebb szabályokat használhatnak az alkalmazásforgalom elosztásához. A bejövő forgalomvezérlők általában a bejövő URL-cím alapján különböző alkalmazásokba irányítják a HTTP-forgalmat.
Bejövő forgalom beállításainak összehasonlítása
Az alábbi táblázat a különböző bejövőforgalom-vezérlők beállításai közötti funkcióbeli különbségeket sorolja fel:
| Szolgáltatás | Alkalmazás-útválasztási bővítmény | Application Gateway tárolókhoz | Azure Service Mesh/Istio-alapú szolgáltatásháló |
|---|---|---|---|
| Bejövő/átjáróvezérlő | NGINX bejövőforgalom-vezérlő | tárolókhoz készült átjáró Azure-alkalmazás | Istio Bejövő átjáró |
| API | Bejövő API | Bejövő API és átjáró API | Átjáró API |
| Üzemeltetés | Fürtben | Üzemeltetett Azure | Fürtben |
| Méretezés | Automatikus skálázás | Automatikus skálázás | Automatikus skálázás |
| Terheléselosztás | Belső/külső | Külső | Belső/külső |
| SSL-leállítás | Fürtben | Igen: Kiszervezés és E2E SSL | Fürtben |
| mTLS | n/a | Igen a háttérrendszerhez | n/a |
| Statikus IP-cím | n/a | FQDN | n/a |
| Az Azure Key Vault által tárolt SSL-tanúsítványok | Igen | Igen | n/a |
| Azure DNS-integráció a DNS-zónakezeléshez | Igen | Igen | n/a |
Az alábbi táblázat felsorolja azokat a forgatókönyveket, amelyekben az egyes bejövőforgalom-vezérlőket használhatja:
| Bejövő forgalom beállítás | Mikor érdemes használni? |
|---|---|
| Felügyelt NGINX – Alkalmazás-útválasztási bővítmény | • Fürtön belüli üzemeltetett, testre szabható és méretezhető NGINX bejövőforgalom-vezérlők. • Alapszintű terheléselosztási és útválasztási képességek. • Belső és külső terheléselosztó konfigurálása. • Statikus IP-címkonfiguráció. • Integráció az Azure Key Vaulttal a tanúsítványkezeléshez. • Integráció az Azure DNS-zónákkal a nyilvános és privát DNS-kezeléshez. • Támogatja a bejövő API-t. |
| Application Gateway tárolókhoz | • Azure-beli bejövő átjáró. • A vezérlő által felügyelt rugalmas üzembehelyezési stratégiák, vagy saját Application Gateway for Containers használata. • Speciális forgalomkezelési funkciók, például az automatikus újrapróbálkozások, a rendelkezésre állási zóna rugalmassága, a háttérbeli célhoz való kölcsönös hitelesítés (mTLS), a forgalom felosztása / súlyozott kerek időszeletelés és automatikus skálázás. • Integráció az Azure Key Vaulttal a tanúsítványkezeléshez. • Integráció az Azure DNS-zónákkal a nyilvános és privát DNS-kezeléshez. • Támogatja a bejövő és az átjáró API-kat. |
| Istio Bejövő átjáró | • Megbízott alapján, ha az Istio-val használ egy szolgáltatáshálót. • Speciális forgalomkezelési funkciók, például sebességkorlátozás és kapcsolatcsoportok megszakadása. • Az mTLS támogatása • Támogatja az átjáró API-t. |
Bejövő erőforrás létrehozása
Az alkalmazás-útválasztási bővítmény ajánlott módja egy bejövőforgalom-vezérlő konfigurálásának az AKS-ben. Az alkalmazás-útválasztási bővítmény az Azure Kubernetes Service (AKS) teljes körűen felügyelt bejövőforgalom-vezérlője, amely a következő funkciókat biztosítja:
Felügyelt NGINX bejövőforgalom-vezérlők egyszerű konfigurálása Kubernetes NGINX bejövőforgalom-vezérlő alapján.
Integráció az Azure DNS-sel a nyilvános és privát zónakezeléshez.
SSL-leállítás az Azure Key Vaultban tárolt tanúsítványokkal.
További információ az alkalmazás-útválasztási bővítményről: Felügyelt NGINX-bejövő forgalom az alkalmazás-útválasztási bővítményrel.
Ügyfélforrás IP-címének megőrzése
Konfigurálja a bejövőforgalom-vezérlőt, hogy megőrizze az ügyfél forrás IP-címét az AKS-fürt tárolóinak kérései esetén. Amikor a bejövőforgalom-vezérlő átirányítja egy ügyfél kérését az AKS-fürt egy tárolójához, a kérés eredeti forrás IP-címe nem érhető el a céltároló számára. Ha engedélyezi az ügyfél forrás IP-címének megőrzését, az ügyfél forrás IP-címe az X-Forwarded-For kérelem fejlécében érhető el.
Ha ügyféloldali IP-címmegőrzést használ a bejövőforgalom-vezérlőn, nem használhat TLS-továbbítást. Az ügyfélforrás IP-címének megőrzése és a TLS-továbbítás más szolgáltatásokkal, például a LoadBalancer típusával is használható.
Az ügyfélforrás IP-címének megőrzésével kapcsolatos további információkért lásd : Hogyan működik az ügyfélforrás IP-megőrzése a LoadBalancer Servicesben az AKS-ben.
Kimenő (kimenő) forgalom szabályozása
Az AKS-fürtök egy virtuális hálózaton vannak üzembe helyezve, és kimenő függőségekkel rendelkeznek a virtuális hálózaton kívüli szolgáltatásoktól. Ezek a kimenő függőségek szinte teljesen definiálva vannak teljes tartománynevekkel (FQDN-ekkel). Az AKS-fürtök alapértelmezés szerint korlátlan kimenő (kimenő) internetkapcsolattal rendelkeznek, amely lehetővé teszi, hogy a futtatott csomópontok és szolgáltatások szükség szerint hozzáférjenek a külső erőforrásokhoz. Igény szerint korlátozhatja a kimenő forgalmat.
További információ: A fürtcsomópontok kimenő forgalmának szabályozása az AKS-ben.
Hálózati biztonsági csoportok
Egy hálózati biztonsági csoport szűri a virtuális gépek, például az AKS-csomópontok forgalmát. A szolgáltatások, például a LoadBalancer létrehozásakor az Azure-platform automatikusan konfigurálja a szükséges hálózati biztonsági csoportszabályokat.
Az AKS-fürtben lévő podok forgalmának szűréséhez nincs szükség a hálózati biztonsági csoportok szabályainak manuális konfigurálására. A szükséges portokat és továbbítást a Kubernetes Service-jegyzékek részeként határozhatja meg, és engedélyezheti az Azure-platform számára a megfelelő szabályok létrehozását vagy frissítését.
Ezenkívül hálózati szabályzatok használatával automatikusan alkalmazhat forgalomszűrési szabályokat a podokra.
További információt a hálózati biztonsági csoportok hálózati forgalmának szűrése című témakörben talál.
Hálózati szabályzatok
Alapértelmezés szerint az AKS-fürtök összes podja korlátozás nélkül tud forgalmat küldeni és fogadni. A nagyobb biztonság érdekében definiáljon olyan szabályokat, amelyek szabályozzák a forgalom áramlását, például:
- A háttéralkalmazások csak a szükséges előtér-szolgáltatásoknak vannak kitéve.
- Az adatbázis-összetevők csak a hozzájuk csatlakozó alkalmazásszintekhez érhetők el.
A hálózati házirend az AKS-ben elérhető Kubernetes-szolgáltatás, amely lehetővé teszi a podok közötti forgalom szabályozását. Engedélyezheti vagy letilthatja a pod felé irányuló forgalmat olyan beállítások alapján, mint a hozzárendelt címkék, a névtér vagy a forgalmi port. Bár a hálózati biztonsági csoportok jobbak az AKS-csomópontok számára, a hálózati házirendek a podok forgalmának szabályozására alkalmasabb, felhőalapú natív módon. Mivel a podok dinamikusan jönnek létre egy AKS-fürtben, a szükséges hálózati szabályzatok automatikusan alkalmazhatók.
További információt az Azure Kubernetes Service (AKS) hálózati házirendek használatával történő biztonságos forgalmát ismertető cikkben talál.
Következő lépések
Az AKS-hálózatkezelés első lépéseihez hozzon létre és konfiguráljon egy saját IP-címtartományokkal rendelkező AKS-fürtöt a Kubenet vagy az Azure CNI használatával.
A kapcsolódó ajánlott eljárásokért tekintse meg a hálózati kapcsolatokra és a biztonságra vonatkozó ajánlott eljárásokat az AKS-ben.
Az alapvető Kubernetes- és AKS-fogalmakkal kapcsolatos további információkért tekintse meg az alábbi cikkeket: