Szerkesztés

Share via

Az AKS hálózati architektúrája az Azure Stack HCI-n

Azure Stack
Windows Server

Ez a forgatókönyv bemutatja, hogyan tervezhet és valósíthat meg hálózati fogalmakat az Azure Kubernetes Service -csomópontok hibrid AKS-fürtökön való üzembe helyezéséhez.

Ez a cikk a Kubernetes-csomópontok és a Kubernetes-tárolók hálózattervezésére vonatkozó javaslatokat tartalmaz. Ez egy két cikkből álló architekturális alapkonfigurációs útmutató-készlet része. Az alaparchitektúra-javaslatokat itt találja.

Felépítés

Az alábbi képen az Azure Stack HCI-n vagy a Windows Server 2019/2022 adatközpontfürtökön futó Azure Kubernetes Service hálózati architektúrája látható:

Conceptual graphic showing network baseline architecture.

Töltse le az architektúra Visio-fájlját.

A forgatókönyv a következő összetevőkből és képességekből áll:

  • Az Azure Stack HCI (20H2) egy hiperkonvergens infrastruktúra (HCI) fürtmegoldás, amely virtualizált Windows- és Linux-számítási feladatokat, valamint azok tárolóit hibrid helyszíni környezetben üzemelteti. Az Azure Stack HCI-fürt 2–4 csomópontos fürtként van implementálva.
  • A Windows Server 2019/2022 adatközponti feladatátvevő fürt olyan független számítógépek csoportja, amelyek együttműködve növelik a fürtözött szerepkörök rendelkezésre állását és méretezhetőségét.
  • Az Azure Stack HCI-n futó Azure Kubernetes Service (AKS hibrid) az Azure Kubernetes Service (AKS) helyszíni implementációja, amely nagy méretekben automatizálja a tárolóalapú alkalmazások futtatását.
  • A [Active Directory tartományi szolgáltatások][] egy hierarchikus struktúra, amely a hálózaton lévő objektumok adatait tárolja. Identitás- és hozzáférési megoldást biztosít a felhasználókhoz, számítógépekhez, alkalmazásokhoz vagy más, a biztonsági határhoz tartozó erőforrásokhoz társított identitásokhoz.
  • [Felügyeleti fürt] [] más néven AKS-gazdagép felelős több számítási feladatfürt üzembe helyezéséért és felügyeletéért. A felügyeleti fürt 1 IP-címet használ fel a csomópontkészletből, de a frissítési műveletekhez további 2 IP-címet kell lefoglalnia. A felügyeleti fürt egy IP-címet is használ a VIP-készletből.
  • [Számítási feladatfürt] [] a Kubernetes magas rendelkezésre állású üzembe helyezése Linux rendszerű virtuális gépeket használ a Kubernetes vezérlősík-összetevőinek és Linux- és/vagy Windows-feldolgozó csomópontjainak futtatásához.
    • Vezérlősík. Linux-disztribúción fut, és API-kiszolgáló-összetevőket tartalmaz a Kubernetes API-val való interakcióhoz, valamint egy elosztott kulcs-érték tárolót stb. a fürt összes konfigurációjának és adatainak tárolásához. Egy IP-címet használ fel a csomópontkészletből és egy IP-címet a VIP-készletből.
    • Terheléselosztó. Linux rendszerű virtuális gépen fut, és terheléselosztási szolgáltatásokat biztosít a számítási feladatokat ellátó fürt számára. Egy IP-címet használ fel a csomópontkészletből és egy IP-címet a VIP-készletből.
    • Feldolgozó csomópontok. Futtatás tárolóalapú alkalmazásokat futtató Windows vagy Linux operációs rendszeren. A csomópontkészletBŐL származó IP-címeket használ fel, de a frissítési műveletekhez legalább 3 további IP-címet kell megterveznie.
    • Kubernetes-erőforrások. A podok az alkalmazás egyetlen példányát jelölik, amely általában 1:1-alapú leképezéssel rendelkezik egy tárolóval, de bizonyos podok több tárolót is tartalmazhatnak. Az üzemelő példányok egy vagy több azonos podot jelölnek. A podok és az üzemelő példányok logikailag egy névtérbe vannak csoportosítva, amely szabályozza az erőforrások felügyeletéhez való hozzáférést. Podonként 1 IP-címet használnak fel a VIP-készletből.
  • [Azure Arc] [] egy felhőalapú szolgáltatás, amely kiterjeszti az Azure Resource Manager-alapú felügyeleti modellt nem Azure-erőforrásokra, beleértve a virtuális gépeket (virtuális gépeket), a Kubernetes-fürtöket és a tárolóalapú adatbázisokat.
  • [Azure Policy] [] egy felhőalapú szolgáltatás, amely a tulajdonságok és a testre szabható üzleti szabályok összehasonlítása révén kiértékeli az Azure-beli és a helyszíni erőforrásokat az Azure Arctal való integráció révén.
  • [Azure Monitor] [] egy felhőalapú szolgáltatás, amely maximalizálja az alkalmazások és szolgáltatások rendelkezésre állását és teljesítményét azáltal, hogy átfogó megoldást kínál a felhőből és a helyszíni környezetekből származó telemetriai adatok gyűjtésére, elemzésére és kezelésére.
  • A [Felhőhöz készült Microsoft Defender][] egy egységes infrastruktúrabiztonsági felügyeleti rendszer, amely erősíti az adatközpontok biztonsági pozícióját, és fejlett fenyegetésvédelmet biztosít a felhőben és a helyszíni hibrid számítási feladatokban.

Összetevők

  • [Azure Stack HCI (20H2)] [1]
  • [Windows Server 2019/2022 adatközponti feladatátvevő fürt] []
  • [Azure Kubernetes Service (AKS)] []
  • [Windows Rendszergazda Center][]
  • [Azure-előfizetés] []
  • [Azure Arc] [2]
  • [Azure szerepköralapú hozzáférés-vezérlés (RBAC)] []
  • [Azure Monitor] [3]
  • [Felhőhöz készült Microsoft Defender][4]

Forgatókönyv részletei

A forgatókönyv használati eseteit a sorozat első cikkében, az Alapkonfiguráció architektúrájában ismertetjük.

Kubernetes-csomópontok hálózatkezelése

Az Azure Stack HCI AKS hálózatkezelési tervezésének fő szempontja a megfelelő IP-címeket biztosító hálózati modell kiválasztása. Az Azure Stack HCI AKS virtuális hálózatkezeléssel foglalja le az IP-címeket a Kubernetes-csomópont erőforrásaihoz. Két IP-cím-hozzárendelési modellt használhat:

  • A statikus IP-hálózatkezelés kiszámíthatóbb, de további erőfeszítéseket tesz a kezdeti konfigurációhoz.
  • A Dinamikus gazdagépkonfigurációs protokoll (DHCP) hálózatkezelése az IP-címek dinamikus kiosztását használja, és kevesebb erőfeszítést igényel, de ügyelnie kell arra, hogy ne használja ki a rendelkezésre álló IP-címek készletét. Emellett a virtuális IP-készletek és bizonyos fürtszintű erőforrások, például a felhőügynök szolgáltatás foglalásait és kizárási tartományait is kezelnie kell.

Mindkét hozzárendelési modellnek a következő IP-címeket kell megterveznie:

  • Virtuális IP-készlet
  • Kubernetes-csomópont virtuális gép IP-készlete

Virtuális IP-készlet

A virtuális IP-készlet olyan IP-címek készlete, amelyek kötelezőek az Azure Stack HCI bármely AKS-üzembe helyezéséhez. Tervezze meg a virtuális IP-készlet IP-címeinek számát a számítási feladatok fürtjeinek és a Kubernetes-szolgáltatások számának alapján. A virtuális IP-készlet ip-címeket biztosít az alábbi típusú erőforrásokhoz:

  • A felhőügynöknek lebegő IP-címet kell megadnia a virtuális IP-készletből.

  • A Kubernetes Virtual Appliance (KVA) virtuális gépen (felügyeleti fürt) futó API-kiszolgáló-összetevő a virtuális IP-készletből származó IP-címet használja. Az API-kiszolgáló a Kubernetes-vezérlősík egyik összetevője, amely elérhetővé teszi a Kubernetes API-t. Az API-kiszolgáló a Kubernetes vezérlősíkjának előtere. A KVA egy Mariner Linuxot futtató virtuális gép, amely egy Kubernetes-fürtöt üzemeltet. Az IP-cím lebegő, és az Azure Stack HCI-n az AKS-ben üzembe helyezhető egyéb KVA virtuális gépekhez is használható. A KVA virtuális gép egy Kubernetes virtuális IP-terheléselosztó szolgáltatást is üzemeltet.

  • Tervezze meg az IP-címzést a célkiszolgálókon üzembe helyezett vezérlősík virtuális gépek számához, mivel a virtuális IP-készletből további IP-címeket is használnak. A szempontokat a következő szakaszban ismertetjük.

  • A célfürt tartalmaz egy terheléselosztó virtuális gépet, amely HAProxy, és a célfürt virtuális IP-készletének tulajdonosa. Ez a virtuális gép az összes Kubernetes-szolgáltatást elérhetővé teszi a virtuális IP-készleten keresztül.

  • A Kubernetes-podokban futó alkalmazások a virtuális IP-készletBŐL származó IP-címeket használják.

  • A HAProxy terheléselosztó speciális virtuális gépként van üzembe helyezve, és több végpont bejövő kéréseinek terheléselosztására használható. A virtuális IP-készletből származó IP-címeket használnak, és minden számítási feladatfürthöz meg kell terveznie az IP-címzést.

Kubernetes-csomópont virtuális gép IP-készlete

A Kubernetes-csomópontok virtuális gépekként vannak üzembe helyezve az Azure Stack HCI-alapú AKS-ben. Győződjön meg arról, hogy az IP-címek számát a Kubernetes-csomópontok teljes száma alapján tervezi meg, és legalább három további IP-címet tartalmaz, amelyeket a frissítési folyamat során használ. Statikus IP-címkonfigurációhoz meg kell adnia a Kubernetes-csomópont virtuális gép IP-készletének tartományát, ez nem szükséges a DHCP-foglaláshoz. További IP-címek tervezése a következőhöz:

  • A KVA virtuális gép további IP-címet is használ a Kubernetes-hez a Kubernetes-csomópont virtuális gép IP-készletéből. Tervezze meg az IP-címek hozzáadását a frissítési folyamat során, mivel a KVA virtuális gép ugyanazt a virtuális IP-címet használja az API-szolgáltatáshoz, de a Kubernetes-csomópont virtuális gép IP-készletétől eltérő IP-címet igényel.
  • A vezérlősík virtuális gépei egy IP-címet használnak fel a Kubernetes-csomópont virtuálisgép-IP-készletéből az API-kiszolgáló szolgáltatáshoz. Ezek a virtuális gépek üzemeltetik az Azure ARC-ügynököt is, amely felügyeleti célból csatlakozik az Azure Portalhoz.
  • A csomópontkészlet csomópontjai (Linux vagy Windows) a Kubernetes-csomópont virtuális gépéhez lefoglalt IP-készletből származó IP-címeket fogják használni.

Microsoft helyszíni felhőszolgáltatás

Tervezze meg a Helyszíni Microsoft-felhő (MOC) IP-címtartományát, amely lehetővé teszi a felügyeleti vermet, hogy az Azure Stack HCI virtuális gépeit a felhőben felügyelje. Az MOC szolgáltatás IP-címfoglalása a mögöttes fizikai hálózaton található, és az Azure Stack HCI-fürtcsomópontokhoz konfigurált IP-címek az adatközpontban találhatók. Az Azure Stack HCI fizikai csomópontjaihoz az alábbi lehetőségek egyikével konfigurálhatja az IP-címeket:

  • Az Azure Stack HCI-fürtcsomópontok DHCP-alapú IP-címfoglalási móddal. Az MOC szolgáltatás egy IP-címet kap a fizikai hálózaton bemutatott DHCP-szolgáltatástól.
  • Statikus IP-foglalási modellel rendelkező Azure Stack HCI-fürtcsomópontok. Az MOC felhőszolgáltatás IP-címét kifejezetten ip-tartományként kell megadni osztály nélküli tartományközi útválasztási (CIDR) formátumban, és az alhálózatban kell lennie, mint az Azure Stack HCI-fürtcsomópontok IP-címeinek.

Terheléselosztó az Azure Stack HCI-n futó AKS-ben

Kis üzembe helyezés esetén használhatja a linuxos virtuális gépként üzembe helyezett beépített terheléselosztót, amely HAProxy + KeepAlive használatával küld forgalmat az AKS-fürt részeként üzembe helyezett alkalmazásszolgáltatásoknak. A HAProxy terheléselosztó végpontként konfigurálja a podokat a terheléselosztóban. Betölti a Kubernetes API-kiszolgálóra irányuló kérelmeket, és kezeli az alkalmazásszolgáltatások felé irányuló forgalmat.

Egyéni terheléselosztót is használhat a szolgáltatások felé irányuló forgalom kezeléséhez. Az egyéni terheléselosztó rugalmasabbá teszi az üzembe helyezést, és biztosítja, hogy az Azure Stack HCI-n futó AKS a meglévő, például a terheléselosztókat használó szoftveralapú hálózati (SDN-) üzemelő példányokkal együtt működjön. Egyéni terheléselosztók esetén a Kube-virtual IP virtuális IP-címmel és terheléselosztóval rendelkező Kubernetes-fürtöket biztosít a vezérlősíkhoz és a LoadBalancer típusú Kubernetes Serviceshez is. A kube-virtual IP-szolgáltatás automatikusan üzembe lesz helyezve minden feldolgozó csomóponton.

Az Azure Stack HCI-n futó AKS támogatja a MetalLB- vagy más OSS Kubernetes-alapú terheléselosztók használatát is a számítási feladatfürt szolgáltatásaihoz rendelt forgalom kiegyensúlyozásához. A MetalLB egy terheléselosztó-implementáció a nem fém kubernetes-fürtökhöz, szabványos útválasztási protokollokkal, például a Border Gateway protokoll BGP-vel. Használható a hálózati bővítményekkel, a Calicoval és a Flannellel is, de gondoskodnia kell arról, hogy az AKS Azure Stack HCI-n való telepítése során megadott virtuális IP-címtartomány ne legyen átfedésben az egyéni terheléselosztóhoz tervezett IP-címtartománysal.

A forgatókönyv üzembe helyezése

Bejövőforgalom-vezérlő üzembe helyezése

Fontolja meg a [bejövőforgalom-vezérlő][] implementálását a TLS leállításához, a megfordítható proxyhoz vagy a konfigurálható forgalom útválasztásához. A bejövőforgalom-vezérlők a 7. rétegben működnek, és intelligens szabályokat használhatnak az alkalmazásforgalom elosztásához. A Kubernetes bemeneti erőforrásainak használatával konfigurálhatók az egyes Kubernetes-szolgáltatásokhoz tartozó bejövő szabályok és útvonalak. Bejövőforgalom-vezérlő definiálásakor a forgalomirányítási szabályokat egyetlen, a fürt részeként futó erőforrásba összesíti.

Bejövőforgalom-vezérlő használatával külsőleg elérhető URL-címeken keresztül teheti elérhetővé a szolgáltatásokat. A bejövő forgalom http- és HTTPS-útvonalakat tesz elérhetővé a fürtön kívüli szolgáltatások számára. A forgalomirányítást a bejövő erőforráson meghatározott szabályok vezérlik. A bejövő HTTP-szabályok a következő információkat tartalmazzák:

  • Választható gazdagép. Ha nem ad meg gazdagépadatokat, a rendszer az összes bejövő HTTP-forgalomra alkalmazza a szabályt.
  • Egy service.name és egy service.port.name vagy service.port.number társított háttérrendszerrel rendelkező elérési utak listája.
  • A szolgáltatás- és portnevek kombinációját biztosító háttérrendszer.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Használjon bejövőforgalom-vezérlőt az alkalmazás különböző háttérrendszerei közötti forgalom kiegyensúlyozásához. A forgalom fel van osztva, és az elérési út adatai alapján különböző szolgáltatásvégpontokra és üzemelő példányokra érkezik.

Ha a HTTP-forgalmat ugyanazon AZ IP-címen több gazdagépnévre szeretné irányítani, minden gazdagéphez használhat egy másik bejövő erőforrást. A terheléselosztó IP-címén áthaladó forgalom a gazdagép neve és a bemeneti szabályban megadott elérési út alapján lesz irányítva.

Konténerekkel kapcsolatos hálózati fogalmak az Azure Stack HCI-n futó Azure Kubernetes Service (AKS) kapcsán

A Kubernetes absztrakciós réteget biztosít egy virtuális hálózatnak, így a tárolóalapú alkalmazások belsőleg vagy külsőleg is kommunikálhatnak. A kube-proxy összetevő minden csomóponton fut, és közvetlen hozzáférést biztosíthat a szolgáltatáshoz, terheléselosztókkal terjesztheti a forgalmat, vagy bejövő vezérlőket használhat az összetettebb alkalmazás-útválasztáshoz. A Kubernetes szolgáltatásokkal logikailag csoportosítja a podok egy készletét, és hálózati kapcsolatot biztosít. A következő Kubernetes-szolgáltatások érhetők el:

  • Fürt IP-címe: Ez a szolgáltatás létrehoz egy belső IP-címet a csak belső alkalmazások számára.
  • NodePort: Ez a szolgáltatás portleképezést hoz létre a mögöttes csomóponton, így az alkalmazás közvetlenül elérhető lesz a csomópont IP-címével és portjával.
  • LoadBalancer: A Kubernetes-szolgáltatásokat külsőleg is közzéteheti terheléselosztó-szabályok vagy bejövőforgalom-vezérlő használatával.
  • ExternalName:. Ez a szolgáltatás egy adott DNS-bejegyzést használ a Kubernetes-alkalmazáshoz.

Kubernetes-hálózatok

Az Azure Stack HCI AKS-ben a fürt az alábbi hálózati modellek egyikével telepíthető:

  • [Project Calico hálózatkezelés] []. Ez az Azure Stack HCI-n futó AKS alapértelmezett hálózati modellje, amely nyílt forráskódú hálózatkezelésen alapul, amely hálózati biztonságot nyújt tárolók, virtuális gépek és natív gazdagépalapú számítási feladatok számára. A Calico hálózati szabályzat bármilyen végponton alkalmazható, például podokon, tárolókon, virtuális gépeken vagy gazdagép-adaptereken. Minden szabályzat olyan szabályokból áll, amelyek olyan műveletek használatával szabályozzák a bejövő és kimenő forgalmat, amelyek engedélyezhetik, megtagadhatják, naplózhatják vagy továbbíthatják a forgalmat a forrás- és célvégpontok között. A Calico linuxos kiterjesztett Berkeley-csomagszűrőt (eBPF) vagy Linux kerneles hálózati folyamatot használhat a forgalom továbbításához. A Calico Windows rendszeren is támogatott a gazdagéphálózati szolgáltatás (HNS) használatával, amely tárolóvégpontonként hoz létre hálózati névtereket. A Kubernetes hálózati modellben minden pod megkapja a saját IP-címét, amely a podon belüli tárolók között van megosztva. A podok pod IP-címekkel kommunikálnak a hálózaton, az elkülönítés pedig hálózati házirendek használatával van meghatározva. A Calico CNI (Container Network Interface) beépülő modulokat használ a Kubernetes-podhálózathoz és a CNI IPAM (IP-címkezelés) beépülő modulhoz az IP-címek kiosztásához és kiadásához.
  • [Flannel overlay networking.] [] A flannel létrehoz egy virtuális hálózati réteget, amely átfedi a gazdahálózatot. Az átfedéses hálózatkezelés a hálózati csomagok beágyazását használja a meglévő fizikai hálózaton keresztül. A flannel leegyszerűsíti a IP-címkezelés (IPAM), támogatja a különböző alkalmazások és névterek közötti IP-újrahasználatot, és logikailag elkülöníti a tárolóhálózatokat a Kubernetes-csomópontok által használt aláfedő hálózattól. A hálózatelkülönítés a Virtual eXtensible Local Area Network (VXLAN) használatával érhető el, amely egy beágyazási protokoll, amely az adatközpontok közötti kapcsolatot alagúttal biztosítja a 2. rétegbeli kapcsolatok 3. rétegbeli hálózaton keresztüli nyújtásához. A Flannelt linuxos tárolók is támogatják a DaemonSet és a Windows-tárolók a Flannel CNI beépülő modullal.

Azure Stack HCI hálózatkezelés tervezése

Az általános hálózatkezelési kialakítás magában foglalja az Azure Stack HCI tervezési tevékenységeit.

Először is tervezzük meg az Azure Stack HCI hardverét és telepítését. Vásárolhat integrált rendszereket egy Microsoft hardverpartnertől az előre telepített Azure Stack HCI operációs rendszerrel, vagy vásárolhat érvényesített csomópontokat, és saját maga telepítheti az operációs rendszert. Az Azure Stack HCI virtualizálási gazdagépként szolgál, ezért a Kubernetes-kiszolgálói szerepköröknek virtuális gépeken kell futniuk.

Az Azure Stack HCI fizikai hálózati követelményei

A Microsoft nem minősíti a hálózati kapcsolókat, de bizonyos követelményekkel rendelkezik, amelyeket a berendezés gyártójának teljesítenie kell:

  • Standard: I Enterprise kiadás E 802.1Q, amely egy virtuális helyi hálózatot (VLAN) határoz meg.
  • Standard: I Enterprise kiadás E 802.1Qbb, amely meghatározza a prioritási folyamatvezérlést (PFC).
  • Standard: I Enterprise kiadás E 802.1Qaz, amely meghatározza a továbbfejlesztett átviteli kiválasztást (ETS).
  • Standard: I Enterprise kiadás E 802.1AB, amely meghatározza a Link Layer Topology Discovery (LLTD) protokollt.

Az Azure Stack HCI gazdagéphálózati követelményei

Érdemes lehet olyan hálózati adaptert használni, amely a Windows Server szoftveralapú adatközpont (SDDC) minősítését standard vagy prémium szintű kiegészítő minősítéssel (AQ) érte el.

Győződjön meg arról, hogy a hálózati adapter támogatja a következőket:

  • [Többsoros dinamikus virtuális gép] [] (Dynamic VMMQ vagy d.VMMQ) egy intelligens, fogadóoldali technológia a hálózati forgalom processzormagokra történő automatikus finomhangolásához.
  • A távoli közvetlen memóriahozzáférés (RDMA) egy hálózati verem kiszervezése a hálózati adapterhez. Lehetővé teszi, hogy az SMB-tárolóforgalom megkerülje az operációs rendszert feldolgozás céljából.
  • A vendég RDMA lehetővé teszi, hogy a virtuális gépek SMB-számítási feladatai ugyanazokat az előnyöket élvezik, mint az RDMA használata a gazdagépeken.
  • A Switch Embedded Teaming (Standard kiadás T) egy szoftveralapú összevonási technológia.

Fontolja meg a [Hálózati ATC][] használatát, amely szándékalapú vezérlést biztosít a gazdagépek hálózati konfigurációjának egyszerűsítése érdekében.

Az Azure Stack HCI-n futó AKS megbízható nagy sávszélességű, alacsony késésű hálózati kapcsolatot igényel az egyes kiszolgálócsomópontok között. Győződjön meg arról, hogy legalább egy hálózati adapter elérhető és dedikált a fürtkezeléshez. Azt is ellenőrizze, hogy a hálózat fizikai kapcsolói úgy vannak-e konfigurálva, hogy engedélyezik a forgalmat a használni kívánt VLAN-okon.

Virtuális kapcsoló

Az Azure Stack HCI leegyszerűsíti a hálózattervezést egy olyan virtuális kapcsoló konfigurálásával, amely használható a hálózatbesoroláshoz. A virtuális hálózati adapter (vNIC) különböző VLAN-okban helyezhető el a gazdagépek számára, hogy különböző forgalmat biztosítsanak a következő hálózatok számára:

  • Felügyeleti hálózat. A felügyeleti hálózat az észak-déli hálózat része, és gazdakommunikációra szolgál.
  • Számítási hálózat. A számítási hálózat az észak-déli hálózat része, és a virtuális gépek forgalmára szolgál. A szolgáltatásminőség (QOS), az egygyökerű I/O virtualizálás (SR-IOV) és a virtuális távoli közvetlen memóriahozzáférés (vRDMA) használatával igény szerint hangolhatja a hálózati teljesítményt.
  • Tárolóhálózat. A tárolóhálózat a kelet-nyugati hálózat része, és 10 GB+ajánlott átviteli sebességgel rendelkező RDMA-t igényel. A virtuális gépek élő áttelepítéséhez használatos.
  • Virtuálisgép-vendéghálózat.

Az RDMA-forgalom kelet-nyugati forgalmának előnyei

A kelet-nyugati hálózati forgalom a gazdagépek közötti kommunikációt jelenti, és nem tesz közzé külső hozzáférést. A forgalom a Rack (ToR) kapcsoló és a 2. réteg határán belül marad. A következő típusú forgalmat tartalmazza:

  • Fürt szívverései és csomópontok közötti kommunikáció
  • [SMB] Storage Bus Layer
  • [SMB] Fürt megosztott kötete
  • [SMB] Tároló újraépítése

Észak-déli forgalom

Az észak-déli forgalom az a külső forgalom, amely eléri az AKS-t az Azure Stack HCI-fürtön. Az Azure ARC integrációjával megtervezheti a figyelést, számlázást és biztonságkezelést lehetővé tevő Azure-szolgáltatások forgalmát. Az észak-déli forgalom a következő jellemzőkkel rendelkezik:

  • A forgalom egy ToR-kapcsolóból a gerincre vagy a gerincről egy ToR-kapcsolóra áramlik.
  • A forgalom elhagyja a fizikai állványt, vagy átlép egy 3. rétegbeli határt (IP).
  • A forgalom magában foglalja a felügyeletet (PowerShell, Windows Rendszergazda Center), a számítást (virtuális gépet) és a helyek közötti feszített fürtforgalmat.
  • Ethernet-kapcsolót használ a fizikai hálózathoz való kapcsolódáshoz.

Az Azure Stack HCI-n futó AKS több fürthálózati üzembe helyezési lehetőséget is használhat:

  • Több hálózati szándékot kombináló konvergens hálózat (MGMT, Compute, Storage). Ez a háromnál több fizikai csomópont esetében ajánlott üzembe helyezés, és minden fizikai hálózati adapternek ugyanahhoz a ToR-kapcsolóhoz kell csatlakoznia. A ROCEv2 használata erősen ajánlott.
  • A kapcsoló nélküli üzembe helyezés az észak-déli kommunikációt használja hálózati csapatként a számítási és felügyeleti hálózatok kombinálásával.
  • Hibrid üzembe helyezés mindkét üzemelő példány kombinációjaként.

Ajánlások

Az alábbi javaslatok a legtöbb forgatókönyvre vonatkoznak. Kövesse a javaslatokat, hacsak nem rendelkezik egy olyan követelménysel, amely felülírja azt.

Hálózatokra vonatkozó javaslatok

Az Azure Stack HCI-n futó AKS hálózattervezésének fő szempontja egy olyan hálózati modell kiválasztása, amely elegendő IP-címet biztosít a Kubernetes-fürthöz, valamint annak szolgáltatásaihoz és alkalmazásaihoz.

  • Fontolja meg statikus IP-címek implementálását, hogy az AKS az Azure Stack HCI-n szabályozhassa az IP-címhozzárendelést.

  • Az IP-címtartományokat megfelelően méretezheti, így elegendő ingyenes IP-címmel rendelkezik egy Kubernetes-csomópontkészlethez és egy virtuális IP-készlethez. Győződjön meg arról, hogy a virtuális IP-készlet elég nagy ahhoz, hogy a frissítéskor használjon gördülő frissítéseket, amelyekhez több IP-cím szükséges. A következőket tervezheti:

    • Proxybeállítások címzési/állomásnevei
    • A célfürt vezérlősíkjának IP-címei
    • Az Azure ARC IP-címei
    • IP-címek a feldolgozó és a vezérlősík csomópontjainak horizontális skálázására a célfürtökben

  • A virtuális IP-készletnek elég nagynak kell lennie ahhoz, hogy támogassa a külső útválasztóhoz való kapcsolódást igénylő alkalmazásszolgáltatások üzembe helyezését.

  • A Calico CNI implementálása továbbfejlesztett hálózati szabályzatot biztosít a pod- és alkalmazáskommunikáció szabályozásához.

  • Győződjön meg arról, hogy a fizikai fürtcsomópontok (HCI vagy Windows Server) ugyanabban az állványban találhatók, és ugyanahhoz a ToR-kapcsolóhoz csatlakoznak.

  • Tiltsa le az IPv6-ot az összes hálózati adapteren.

  • Győződjön meg arról, hogy a meglévő virtuális kapcsoló és a neve minden fürtcsomóponton megegyezik.

  • Ellenőrizze, hogy a fürthöz definiált összes alhálózat egymás és az internet között is elérhető-e.

  • Győződjön meg arról, hogy hálózati kapcsolat van az Azure Stack HCI-gazdagépek és a bérlői virtuális gépek között.

  • Engedélyezze a dinamikus DNS-frissítéseket a DNS-környezetben, hogy az Azure Stack HCI-n futó AKS regisztrálhassa a felhőügynök általános fürtnevét a DNS-rendszerben a felderítéshez.

  • Fontolja meg a hálózati forgalom irány szerinti besorolásának implementálását:

    • Az észak-déli forgalom az Azure Stack HCI-ből és a hálózat többi részéből érkező forgalom,
      • Menedzsment
      • Számítás
      • Helyek közötti feszített fürtforgalom
    • Kelet-nyugati forgalom az Azure Stack HCI-n belül:
      • Tárolási forgalom, beleértve az ugyanazon fürt csomópontjai közötti élő migrálást is.
      • Ethernet-kapcsoló vagy közvetlen kapcsolat.

Tárolási forgalmi modellek

  • Több alhálózat és VLAN használata a tárolási forgalom elkülönítéséhez az Azure Stack HCI-ben.
  • Fontolja meg a különböző típusú forgalom sávszélesség-lefoglalásának implementálását.

Megfontolások

A [Microsoft Azure Well-Architected Framework][] az ebben a forgatókönyvben követett vezérelvek készlete. A következő szempontok e szempontok kontextusában vannak keretbe foglalva.

Megbízhatóság

  • A Microsoft szoftveralapú számítással (Hyper-V-csomópontok feladatátvevő fürtje), a tárolással (Tárolóhelyek közvetlen beágyazott rugalmasságával) és a hálózatkezeléssel (szoftveralapú hálózatkezelés) járó beépített rugalmasság.
  • Fontolja meg az iparági szabványokat támogató hálózati kapcsoló kiválasztását, és biztosítsa a csomópontok közötti megbízható kommunikációt. A következő szabványok a következők:
    • Standard: I Enterprise kiadás E 802.1Q
    • Standard I Enterprise kiadás E 802.1Qbb
    • Standard I Enterprise kiadás E 802.1 Qas
    • Standard I Enterprise kiadás E 802.1 AB
  • Fontolja meg több gazdagép implementálását a felügyeleti fürtben és a Kubernetes-fürtben, hogy megfeleljen a számítási feladatok minimális rendelkezésre állási szintjének.
  • Az Azure Stack HCI-n futó AKS feladatátvételi fürtözést és élő migrálást használ a magas rendelkezésre állás és hibatűrés érdekében. Az élő áttelepítés egy Hyper-V szolgáltatás, amely lehetővé teszi a futó virtuális gépek transzparens áthelyezését egy Hyper-V-gazdagépről egy másikra anélkül, hogy az üzemidő észlelhető.
  • Győződjön meg arról, hogy az Architektúra szakaszban hivatkozott szolgáltatások támogatottak abban a régióban, amelyre az Azure Arc telepítve van.

Biztonság

  • Biztonságossá teheti a podok közötti forgalmat hálózati szabályzatok használatával az Azure Stack HCI AKS-ben.
  • Az Azure Stack HCI AKS API-kiszolgálója tartalmazza azt a hitelesítésszolgáltatót, amely tanúsítványokat ír alá a Kubernetes API-kiszolgáló és a kubelet közötti kommunikációhoz.
  • A Microsoft Entra egyszeri bejelentkezés (SSO) használatával biztonságos kapcsolatot hozhat létre a Kubernetes API-kiszolgálóval.
  • Az Azure RBAC használatával Microsoft Entra-identitásokkal kezelheti az Azure Arc-kompatibilis Kuberneteshez való hozzáférést az Azure-ban és a helyszíni környezetekben. További információ: [Az Azure RBAC használata Kubernetes-engedélyezéshez][].

Költségoptimalizálás

  • Az [Azure díjszabási kalkulátora][] segítségével becsülje meg az architektúrában használt szolgáltatások költségeit. A további ajánlott eljárásokat a [Microsoft Azure Well-Architected Framework] [költségoptimalizálás][] szakasza ismerteti.] []
  • Fontolja meg a hyper-threading implementálását a fizikai számítógépen a költség optimalizálása érdekében, mivel az Azure Stack HCI-alapú AKS számlázási egység egy virtuális mag.
  • Az Azure Arc vezérlősík funkciói külön költség nélkül érhetők el. Ez magában foglalja az erőforrás-szervezet azure-beli felügyeleti csoportokon és címkéken keresztüli támogatását, valamint az Azure RBAC-beli hozzáférés-vezérlést. Az Azure Arc-kompatibilis kiszolgálókhoz kapcsolódó Azure-szolgáltatások használatuknak megfelelően költségekkel járnak.
  • A költséghatékonyság érdekében legfeljebb két fürtcsomópontot használhat csak négy lemezzel és csomópontonként 64 gigabájtnyi memóriával. A költségek további csökkentése érdekében kapcsoló nélküli összekapcsolásokat használhat a csomópontok között, így szükségtelenné válik a redundáns kapcsolóeszközök használata.

Működés eredményessége

  • Egyszerűsített felügyelet a Windows Rendszergazda Center használatával. A Windows Rendszergazda Center az AKS Azure Stack HCI-n való létrehozásának és kezelésének felhasználói felülete. Telepíthető Windows 10/11 vagy Windows Server rendszerű virtuális gépekre, amelyeket regisztrálni kell az Azure-ban, és ugyanabban a tartományban vannak, mint az Azure Stack HCI vagy a Windows Server Datacenter fürt.
  • Integráció az Azure Arctal, vagy több olyan Azure-szolgáltatással, amely több felügyeleti, karbantartási és rugalmassági képességet biztosít (Azure Monitor, Azure Backup).
  • Ha a Kubernetes-fürt [az Azure Archoz van csatolva][Azure Arc-kompatibilis Kubernetes-szolgáltatáshoz], [kezelheti a Kubernetes-fürtöt a GitOps használatával][]. A hibrid Kubernetes-fürtök Azure Archoz való csatlakoztatásának ajánlott eljárásait a [Kubernetes-fürtökhöz készült Azure Arc hibrid felügyelet és üzembe helyezés][] forgatókönyvben tekintheti meg.
  • Az Azure Stack HCI platform az Azure Stack HCI-fürtök AKS virtuális hálózatkezelésének egyszerűsítésében is segít azáltal, hogy a "mögöttes" hálózatot magas rendelkezésre állású módon biztosítja.

Teljesítmény hatékonysága

  • Az Azure Stack HCI-tanúsítvánnyal rendelkező hardverek használata az alkalmazások jobb üzemidejéhez és teljesítményéhez, az egyszerűbb felügyelethez és műveletekhez, valamint a teljes bekerülési költség csökkentéséhez.
  • Tárolás: közvetlen Tárolóhelyek
    • Kötetkonfiguráció (beágyazott kétutas tükör és beágyazott tükrözött gyorsított paritás)
    • Lemezkonfiguráció (gyorsítótárazás, rétegek)
  • Győződjön meg arról, hogy a fürtcsomópontok fizikailag ugyanabban az állványban találhatók, és ugyanahhoz a ToR-kapcsolóhoz csatlakoznak.
  • IP-címfoglalásokat tervezhet az AKS-gazdagépek, számítási feladatok fürtöi, fürt API-kiszolgálók, Kubernetes Services és alkalmazásszolgáltatások konfigurálásához. A Microsoft azt javasolja, hogy legalább 256 IP-címet foglaljon le az AKS Azure Stack HCI-n való üzembe helyezéséhez.
  • Fontolja meg egy olyan bejövő vezérlő implementálását, amely a 7. rétegben működik, és intelligensebb szabályokat használ az alkalmazásforgalom elosztásához.
  • Grafikus feldolgozási egység (GPU) gyorsításának használata kiterjedt számítási feladatokhoz.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

Egyéb közreműködők:

Következő lépések