Azure Kubernetes Application Network-architectuur (voorbeeld)

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals het is' en 'voor zover beschikbaar' en zijn uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning naar best vermogen. Zodoende zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

• Ondersteuningsbeleid voor AKS
• Veelgestelde vragen over ondersteuning voor Azure

Azure Kubernetes Application Network-architectuur is ingedeeld in drie lagen: een beheervlak, een besturingsvlak en een gegevensvlak. Elke laag heeft verschillende verantwoordelijkheden die samen een volledig beheerde, omgevingsgebaseerde servicenetwerkoplossing voor Azure Kubernetes Service (AKS) bieden. Deze architectuur maakt veilige en door beleid aangestuurde communicatie tussen services mogelijk, zonder de noodzaak van sidecars of aanpassingen aan uw toepassingen.

Dit artikel bevat een overzicht van de architectuurlagen van Azure Kubernetes Application Network, hoe ze communiceren en het detectiemodel voor meerdere clusters dat schaalbare communicatie tussen clusters mogelijk maakt. Zie het overzicht van Azure Kubernetes Application Network voor AKS voor meer informatie over Azure Kubernetes Application Network.

Overzicht van architectuurlagen voor toepassingsnetwerk

De architectuurlagen beheren de volgende verantwoordelijkheden:

• Beheervlak: verwerkt azure-resourcebewerkingen, zoals het maken, bijwerken en verwijderen van application network-resources en het beheren van clusterlidmaatschap.
• Besturingsvlak: beheert de mesh-configuratie, levenscyclus van certificaten en servicedetectie voor elk lidcluster.
• Gegevensvlak: beveiligt service-naar-service-verkeer rechtstreeks in het lidcluster met behulp van de ambient-modus, waarbij geen sidecars of wijzigingen in uw toepassingen nodig zijn.

Voor implementaties met meerdere clusters synchroniseert Application Network servicedetectiegegevens tussen lidclusters, zodat services transparant kunnen communiceren over clustergrenzen.

In het volgende diagram ziet u de architectuurlagen van Azure Kubernetes Application Network en hoe ze met elkaar en met uw AKS-clusters communiceren:

Beheervlak

Het beheervlak is de Azure-resourceprovider die alle resourcebewerkingen van het toepassingsnetwerk verwerkt. Wanneer u een toepassingsnetwerkresource maakt of lid wordt van een lidcluster, valideert het beheervlak de aanvraag, richt het ondersteunende Azure-resources zoals Azure Key Vault in voor certificaatopslag en organiseert het maken van een regionaal besturingsvlak voor het lid.

U communiceert met het beheervlak via de Azure CLI (az appnet) of de ARM-API. Het beheervlak coördineert alle downstreaminrichting, zodat besturingsvlak- en gegevensvlakonderdelen zonder handmatige tussenkomst worden geïmplementeerd.

beheerlaag

Het besturingsvlak is een volledig beheerde infrastructuur die buiten uw AKS-cluster wordt uitgevoerd. Wanneer een lidcluster lid wordt van een toepassingsnetwerk, wordt een toegewezen besturingsvlak ingericht in dezelfde Azure-regio als het lidcluster, waardoor de latentie tussen de onderdelen van het besturingsvlak en het gegevensvlak laag blijft.

Opmerking

Leden in verschillende Azure-regio's hebben besturingsvlakken geïmplementeerd in hun respectieve regio's.

Het besturingsvlak bevat de volgende onderdelen:

• Istiod: Maakt verbinding met de Kubernetes-API-server van het lidcluster om services te detecteren en te kijken naar configuratiewijzigingen. Het stuwt de xDS-configuratie naar ztunnel en waypoint-proxy's in het gegevensvlak. In implementaties met meerdere clusters maakt Istiod ook verbinding met de Kubernetes-API-servers van andere lidclusters om servicedetectie-informatie te verkrijgen, waardoor servicedetectie tussen clusters mogelijk is.
• Certificaatbeheer: richt CA-certificaten in en roteert deze door Azure Key Vault. Een basis-CA stelt een gedeelde vertrouwensgrens vast voor alle lidclusters en elk lid ontvangt een tussenliggende CA die kortdurende workloadcertificaten uitgeeft. Zie het overzicht van Azure Kubernetes Application Network-beveiliging voor meer informatie.
• Levenscyclusbeheer: Implementeert en upgradet alle onderdelen van het gegevensvlak in het lidcluster, waaronder ztunnel, Istio CNI, waypointproxy's en aangepaste resourcedefinities (CRD's). Zie Upgrades configureren voor leden van Azure Kubernetes Application Network voor meer informatie.

Gegevensvlak

Het gegevensvlak bestaat uit onderdelen die zijn geïmplementeerd in de naamruimte van het lidcluster applink-system. Application Network maakt gebruik van de Omgevingsmodus van Istio, dus er zijn geen sidecars opgenomen in uw workloads.

Het gegevensvlak bevat de volgende onderdelen:

• Ztunnel: Een L4-proxy op knooppuntniveau geïmplementeerd als een DaemonSet. Ztunnel onderschept service-naar-service-verkeer op het knooppunt, brengt mTLS-verbindingen transparant tot stand en dwingt L4-autorisatiebeleid af.
• Waypoint-proxy's: optionele L7-proxy's per naamruimte die HTTP-routering, verkeersverplaatsing, foutinjectie en L7-autorisatie bieden. Waypoint-proxy's worden alleen geïmplementeerd wanneer L7-beleidsregels zijn geconfigureerd voor een naamruimte.
• Oost-west-gateway: verwerkt verkeer tussen clusters in implementaties met meerdere clusters. U bent verantwoordelijk voor het bieden van netwerkconnectiviteit tussen oost-west-gateways in elk lidcluster. Voor meer informatie, zie detectie van multiclusterservice.
• Istio CNI: een DaemonSet die podnetwerken configureert voor het onderscheppen van omgevingsnetwerkverkeer.
• CRD's: Aangepaste Kubernetes-resourcedefinities voor het configureren van verkeerbeheer en beveiligingsbeleid.

Wanneer er een aanvraag wordt gedaan tussen services, onderschept ztunnel het verkeer, brengt een mTLS-verbinding met de ztunnel van de bestemming tot stand en levert de aanvraag aan de doelworkload. Als L7-beleid is geconfigureerd, routeert het verkeer via een waypoint-proxy voordat deze de bestemming bereikt. Voor verkeer tussen clusters routeert ztunnel via de gateway oost-west om workloads in externe lidclusters te bereiken.

Detectie van service met meerdere clusters

Application Network ondersteunt het verbinden van meerdere AKS-clusters in een geïntegreerde service-mesh. Services in het ene lidcluster kunnen communiceren met services in andere lidclusters, met mTLS eind-tot-eind afgedwongen over clustergrenzen.

In opensource Istio-implementaties met meerdere clusters maken besturingsvlakken doorgaans verbinding met de Kubernetes-API-servers van andere clusters om services en configuratiewijzigingen te detecteren. Application Network volgt een vergelijkbaar servicedetectiemodel, waarbij besturingsvlakken servicegegevens verkrijgen van lidclusters, zodat services kunnen worden gedetecteerd binnen de clustergrenzen. Met deze aanpak kunnen workloads in het ene lidcluster services in andere clusters oplossen en ermee communiceren zonder dat er wijzigingen in de toepassing nodig zijn. Als u een nieuw lidcluster toevoegt, wordt het mesh-lidmaatschap uitgebreid, zodat services in het nieuwe cluster kunnen worden gedetecteerd door andere leden.

Verkeer tussen clusters loopt via oost-west-gateways die in elk lidcluster zijn geïmplementeerd. U bent verantwoordelijk voor het bieden van netwerkbereikbaarheid tussen de oost-west-gateways van uw lidclusters, bijvoorbeeld via VNet-peering, VPN of andere connectiviteitsoplossingen. Al het verkeer tussen clusters wordt versleuteld met mTLS.

Hoe onderdelen communiceren

Het besturingsvlak maakt verbinding met de Kubernetes API-server van het lidcluster, kijkt naar service- en configuratiewijzigingen en pusht xDS-updates naar ztunnel- en waypoint-proxy's. Wanneer er meerdere leden bestaan, wisselt elk besturingsvlak ook servicegegevens uit via beheerde berichten, zodat elk lid een consistent overzicht heeft van alle services in de mesh.

Certificaatbeheer richt een root-CA in wanneer de toepassingsnetwerkresource wordt gemaakt en vaardigt tussenliggende CA's uit voor elk lidcluster. Workloadcertificaten worden uitgegeven met een geldigheidsperiode van 24 uur en worden elke 12 uur automatisch gedraaid. De volledige levenscyclus van het certificaat, van basis-CA tot tussenliggende certificaten en workloadcertificaten, wordt beheerd zonder handmatige tussenkomst.

Zie het overzicht van azure Kubernetes Application Network-beveiliging voor het volledige schema voor certificaathiërarchie en rotatie.

Verwante inhoud

Zie de volgende artikelen voor meer informatie over Azure Kubernetes Application Network:

• Overzicht van Azure Kubernetes-toepassingsnetwerk voor AKS
• Ondersteunde versies van Azure Kubernetes Application Network