Delen via

Waarneembaarheid van services voor Kubernetes met Azure Arc

  • Artikel

Waarneembaarheid is een toepassingskenmerk dat verwijst naar hoe goed de interne status of status van een systeem kan worden begrepen op basis van de externe uitvoer. We meten computersystemen door CPU-tijd, geheugen, schijfruimte, latentie, fouten en andere metrische gegevens te observeren. Hoe meer waarneembaar een systeem is, hoe gemakkelijker het is voor ons om te begrijpen wat het doet door het te bekijken.

De waarneembaarheid van een systeem heeft een aanzienlijk effect op de bedrijfskosten. Waarneembare systemen leveren zinvolle, bruikbare gegevens op aan hun operators, zodat ze gunstige resultaten kunnen bereiken en minder downtime hebben. Meer informatie vertaalt zich niet noodzakelijkerwijs in een meer waarneembaar systeem. Soms kan de hoeveelheid informatie die door een systeem wordt gegenereerd, het moeilijker maken om waardevolle gezondheidssignalen te identificeren van de ruis die door de toepassing wordt gegenereerd.

Serviceobserveerbaarheid is belangrijk omdat u hiermee inzicht krijgt in de prestaties en problemen in gedistribueerde en cloudsystemen op basis van dynamische architecturen.

Het implementeren van een oplossing voor het realiseren van waarneembaarheid van services kan u helpen:

  • Zorg ervoor dat eindgebruikers uw toepassing kunnen gebruiken en dat aan de verwachtingen van uw bedrijf wordt voldaan.
  • Een volledig systeem begrijpen en hoe het werkt met één deelvenster glas.
  • Stel een basislijn voor uw systeem vast en begrijp hoe verschillende omstandigheden van invloed zijn op de prestaties van uw systeem.
  • Actie-items genereren op basis van onverwachte scenario's en gedrag.

Kubernetes met Azure Arc biedt twee geïntegreerde uitbreidingsopties waarmee u de waarneembaarheid van services kunt bereiken: Open Service Mesh en zelf-hostende API Management-gateway. Deze opties worden uitvoerig besproken in de volgende ontwerpoverwegingen.

Architectuur

In het volgende diagram ziet u de drie pijlers van Services Waarneembaarheid met invloed op het gegevensvolume.

Een diagram met services waarneembaarheidpijlers.

In het volgende diagram ziet u verschillende Open Service Mesh-onderdelen die worden uitgevoerd in een Kubernetes-cluster met Arc. Er wordt ook een voorbeeldtoepassing weergegeven die is ingeschakeld in de service-mesh, die automatisch wordt geconfigureerd met een container met envoy-auto's.

Een diagram met Open Service Mesh dat wordt uitgevoerd in Kubernetes met Azure Arc.

Ontwerpoverwegingen

De drie pijlers van waarneembaarheid zijn metrische gegevens, logboeken en traceringen. Neem deze op in uw strategie voor waarneembaarheid om uw systeem waarneembaar te maken.

  • Metrische gegevens zijn numerieke waarden die een bepaald aspect van een systeem op een bepaald tijdstip beschrijven en die altijd met regelmatige tussenpozen worden verzameld.

In de volgende schermopname ziet u een visualisatie van een voorbeeld van een metrische HTTP-aanvraag voor een service. De metrische waarde in dit voorbeeld wordt weergegeven als HTTP-aanvraagsnelheid per minuut gedurende een opgegeven periode.

Een schermopname van de metrische H T T P-aanvraag voor een service.

  • Logboeken kunnen verschillende gegevenstypen opslaan die hun eigen structuren hebben. Een logboek bevat details over transacties waarmee u een vollediger verhaal voor een bepaalde gebeurtenis kunt verkrijgen. Toepassingslogboeken bevatten doorgaans tijdstempels, logboekniveaus en eventuele informatie die nodig is om de context van een gebeurtenis te begrijpen. Logboeken worden verzameld en verzonden naar een logboekservice voor opslag en analyse.

  • Gedistribueerde tracering is een diagnostische techniek waarmee gebruikers fouten en prestatieproblemen in toepassingen kunnen lokaliseren, met name die worden gedistribueerd over meerdere computers of processen. Met deze techniek worden aanvragen bijgehouden via een toepassing, waarbij werk dat door verschillende toepassingsonderdelen wordt uitgevoerd, correleert en die afgescheiden is van ander werk dat de toepassing kan uitvoeren voor gelijktijdige aanvragen.

In de volgende schermopname ziet u een visualisatie van een end-to-end transactie met behulp van Application Insights. Met deze visual kunt u eenvoudig inzicht krijgen in reactietijden, antwoordcodes en eventuele uitzonderingen die optreden tussen aanvragen in een transactieketen.

Een schermopname van end-to-end transactietracering.

De drie pijlers van metrische gegevens, logboeken en gedistribueerde tracering zijn onderling verbonden. Metrische gegevens worden opgeslagen als numerieke waarden in een tijdreeksdatabase. Ze zijn ook veel kleiner dan logboeken, waardoor ze gemakkelijker kunnen worden geëvalueerd en nuttig zijn voor waarschuwingen in bijna realtime. Logboeken leggen veel meer informatie vast en geven ze over dan metrische gegevens, waardoor ze nuttig zijn voor diepere foutopsporing. Traceringen zijn aanvraagbereik en handig om inzicht te krijgen in een aanvraag wanneer deze verschillende onderdelen van een gedistribueerd systeem doorkruist.

In de volgende tabel ziet u de impact van de verzameling voor de drie pijlers.

Verzamelingskenmerk Metrische gegevens voor Logboeken Gedistribueerde tracering
Accounts voor elke transactie Ja Ja Nee (steekproef)
Immuun voor kardinaliteitsproblemen Nr. Ja Ja
Kosten Laag Hoog Beperkt

Er zijn verschillende manieren waarop u serviceobserveerbaarheid kunt bereiken. U kunt een service-mesh gebruiken om dit te doen op de platformlaag, waarbij uw toepassing zich niet bewust en ongewijzigd is. U kunt een toepassing ook instrumenteren met een bibliotheek. Dit wordt meestal gedaan met behulp van een APM-hulpprogramma (Application Performance Monitoring), zoals Application Insights. API-gateways bieden waarneembaarheid in noord-zuidverkeer, maar ontbreken waarneembaarheid in pod-naar-podcommunicatie en configuratiegemak op schaal.

In de volgende secties wordt uitgelegd hoe u een service-mesh en de zelf-hostende API-gateway kunt gebruiken die beschikbaar is voor Azure Arc om waarneembaarheid van services te bereiken.

Service-mesh

Een service-mesh biedt mogelijkheden zoals verkeersbeheer, tolerantie, beleidshandhaving, transportbeveiliging, identiteitsbeveiliging en waarneembaarheid voor uw workloads. Uw toepassing wordt losgekoppeld van deze operationele mogelijkheden; de service-mesh verplaatst ze uit de toepassingslaag en omlaag naar de infrastructuurlaag. Dit wordt gedaan via een proxy met hoge prestaties die al het binnenkomende en uitgaande verkeer naar uw service mediat.

  • Kubernetes met Azure Arc biedt ondersteuning voor Open Service Mesh (OSM), een CNCF-project (Cloud Native Computing Foundation), dat wordt geïmplementeerd als een extensie. Open Service Mesh is een lichtgewicht, uitbreidbare, cloudeigen service-mesh waarmee gebruikers gelijkmatig kunnen beheren, beveiligen en out-of-the-box waarneembaarheidsfuncties kunnen krijgen voor zeer dynamische microserviceomgevingen.
  • Andere populaire Service Meshes waarvoor ondersteuning van leveranciers is vereist, zijn Istio, Consul Verbinding maken en Linkerd.
  • Afhankelijk van de functies die u gebruikt bij het implementeren van een service-mesh, kan er extra verantwoordelijkheid worden gelegd voor toepassingsoperators om een configuratie voor elke service te definiëren (zoals toegangsregels en onboardingservices). Clusteroperators moeten ook de service-meshcontroller beheren en er rekening mee houden. Vanwege de manier waarop service-mesh gebruikmaakt van het side-car-patroon, zijn toegangslogboeken van het besturingsvlak van de service-mesh en sidecar nodig bij het opsporen van fouten in uitgaand verkeer en inkomend verkeer.

Waarneembaarheid van service-mesh

Waarneembaarheid is een belangrijke functionaliteit van de vele die service-meshes bieden. Kies een Service Mesh die voldoet aan uw minimale waarneembaarheidsvereisten, zodat u de hoeveelheid complexiteit en onderdelen die de service-mesh kan gebruiken, kunt verminderen en moet worden geconfigureerd. Evalueer de volgende algemene functies en gebruiksvoorbeelden van waarneembaarheid die service-meshes bieden:

  • Het genereren van metrische gegevens, inclusief de vier gouden signalen: latentie, verkeer, fouten en verzadiging.
  • De RED-methode (Rate-calls/sec, Errors, Duration-call latencies), een subset van de vier gouden signalen en wordt gebruikt om services te meten. Uw service-mesh moet een gestandaardiseerde manier bieden om metrische RED-gegevens, traceringen, enzovoort te verzamelen.
  • Waarneembaarheid neemt toe, van het vergroten van de dekkingsbreedte tot alle services die deel uitmaken van uw service-mesh.
  • Functies die de acceptatie van waarneembaarheid verhogen door alle services automatisch te instrumenteren.
  • Sterke integratie met de pijlers voor waarneembaarheid van services. Uw service-mesh moet metrische gegevens kunnen schrooten en logboeken verzamelen die in uw bewakingsoplossing worden weergegeven. Zorg ervoor dat de telemetrieverzameling van uw service mesh uw bedrijfsbehoeften ondersteunt en goed kan worden geïntegreerd met uw bestaande bewakingsoplossing.

In het volgende diagram ziet u een voorbeeld van de Service Mesh Proxy-functionaliteit van het verzamelen en doorsturen van gegevens.

Een diagram met een voorbeeld van waarneembaarheid met een Service Mesh-proxy.

Zelf-hostende gateway voor API Management

Met de integratie tussen Azure API Management en Azure Arc in Kubernetes kunt u het API Management-gatewayonderdeel implementeren als een extensie in uw Kubernetes-cluster met Azure Arc. Hierdoor kan een containerversie van API Management-gateway worden uitgevoerd in uw cluster. Alle zelf-hostende gateways worden beheerd vanuit de API Management-service waarmee ze zijn gefedereerd, zodat u inzicht krijgt en een uniforme beheerervaring hebt voor alle interne en externe API's.

Als u de zelf-hostende gateway zo configureert dat binnenkomend verkeer wordt geaccepteerd om naar uw services te leiden, moet u beleid maken. Het beheer kan complexer worden naarmate uw serviceschaal groeit.

Zie het overzicht van de zelf-hostende gateway voor meer informatie

Waarneembaarheid van zelf-hostende gateways voor API Management

De zelf-hostende gateway verzendt metrische gegevens, stdout-logboeken en stderr-logboeken. De metrische gegevens die worden verzonden, kunnen worden geconfigureerd door een ConfigMap in uw cluster. Zie Geavanceerde bewaking voor meer informatie over geavanceerde bewaking met API Management.

Zelf-hostende gateway waarneembaarheidsaccounts voor extern verkeer (noord-zuid) dat binnen uw cluster binnenkomt, maar biedt geen waarneembaarheid voor pod-naar-pod-verkeer in uw cluster (oost-west).

Metrische gegevens en logboeken van de cloud: metrische gegevens worden standaard verzonden naar Azure Monitor. Met Log Analytics kunt u zelf-hostende gatewaycontainerlogboeken verzamelen en weergeven met behulp van Azure Monitor voor containers. Zie Lokale metrische gegevens en logboeken configureren voor de zelf-hostende gateway van Azure API Management voor meer informatie.

Lokale metrische gegevens en logboeken: Metrische gegevens en logboeken van uw zelf-hostende gateway kunnen worden geïntegreerd met uw lokale bewakingsprogramma's of worden verzonden door configuratietoewijzing. Metrische gegevens kunnen worden geconfigureerd voor publicatie naar metrische servers. Gatewaylogboeken worden standaard verzonden naar stdout en stderr. Zie Lokale metrische gegevens en logboeken configureren voor de zelf-hostende gateway van Azure API Management voor meer informatie.

Vergelijkingstabel voor technologie

In de volgende tabel ziet u verschillen tussen implementatieopties om u te helpen bij het kiezen van een methode voor het verkrijgen van waarneembaarheid van services.

Mogelijkheid Service Mesh Bewaking van toepassingsprestaties Zelf-hostende API Gateway
Ondersteuning voor Oost-West-verkeer Ja Ja Nr.
Mogelijkheid voor metrische gegevens Ja Ja Ja
Mogelijkheid voor logboekregistratie Ja Ja Aangepaste implementatie
Mogelijkheid voor gedistribueerde traceringen Ja Ja Ja
Implementatielaag Netwerk Toepassing Netwerk
Ondersteunde protocollen HTTP(S), TCP, gRPC N.v.t. HTTP(S), websockets
Configuratieverantwoordelijkheid Clusteroperators Toepassingsontwikkelaars Toepassingsoperators en clusteroperators
Configuratiecomplexiteit voor waarneembaarheid Laag Hoog Gemiddeld

Ontwerpaanaanvelingen

Implementeer Open Service Mesh om waarneembaarheid te krijgen in de status en prestaties van uw services. Open Service Mesh maakt gebruik van sidecarproxy's die zijn geïnjecteerd als een afzonderlijke container in dezelfde pods als uw workloads om telemetriegegevens te verkrijgen. Deze proxy's onderscheppen al het inkomende en uitgaande HTTP-verkeer naar uw workloads en rapporteren de gegevens naar Open Service Mesh. Met dit systeem hoeven serviceontwikkelaars hun code niet te instrumenteren om telemetriegegevens te verzamelen.

Schakel Open Service Mesh in met behulp van de kubernetes-clusterextensie met Azure Arc, waarmee Microsoft het besturingsvlak voor u kan beheren. Zie Open Service Mesh met Azure Arc implementeren (preview) voor meer informatie.

Schakel Azure Monitor Container Insights in om de beschikbaarheid en prestaties van uw toepassingen en services te maximaliseren. Het biedt een uitgebreide oplossing voor het verzamelen, analyseren en uitvoeren van telemetrie vanuit uw cloud- en on-premises omgevingen. Open Service Mesh met Azure Arc kan nauw worden geïntegreerd met Azure Monitor, waardoor u een naadloze methode krijgt om kritieke KPI's te bekijken en erop te reageren die worden geleverd door metrische OSM-gegevens en toepassingscontainerlogboeken. U kunt metrische OSM-gegevens inschakelen door deze stappen uit te voeren. Voor gedistribueerde tracering raden we Jaeger aan, die kan worden geïntegreerd met uw OSM-besturingsvlak.

Open Service Mesh biedt ook gedocumenteerde waarneembaarheidsintegraties voor metrische gegevens met Prometheus en Grafana, tracering met Jaeger en doorsturen van logboeken met Fluent Bit. Deze integraties bieden alternatieve opties als u geen azure-bewakingsoplossingen gebruikt. U kunt deze integraties gebruiken om naar behoefte uit te breiden naar andere interne bewakingshulpprogramma's.

U moet minimaal de volgende drie RED-metrische gegevens definiëren en deze meten voor alle services:

  • Aanvraagsnelheid: het aantal aanvragen dat de service ontvangt per seconde.
  • Fouten: het aantal mislukte aanvragen of het aantal mislukte aanvragen per seconde.
  • Duur: de hoeveelheid tijd die een service nodig heeft om een aanvraag af te handelen.

Open Service Mesh biedt verschillende vooraf geconfigureerde servicewerkmappen in Azure Monitor, zodat u geen dashboards en grafieken handmatig hoeft in te stellen. Met deze gedetailleerde telemetrie kunt u servicegedrag observeren en kunt u problemen met uw toepassingen oplossen, onderhouden en optimaliseren. Met behulp van de OSM-bewakingswerkmap in Azure Monitor kunt u het volgende doen:

  • Krijg een overzicht van alle services in uw mesh en krijg essentiële metrische gegevens op serviceniveau voor drie van de vier gouden signalen van bewaking: latentie, aanvragen en fouten.
  • Waarschuwingen definiëren, controleren en instellen op basis van serviceniveaudoelstellingen (SLO's), waarin de gebruikersprestaties van uw service worden samengevat.
  • Bekijk metrische grafieken voor afzonderlijke services, zodat u ze diep kunt analyseren met behulp van filters en uitsplitsingen, gegevens door middel van antwoordcode, protocol, doelpod, verkeersbron en meer.

Gebruik visualisaties uit de Gebruikersinterface van Jaeger om:

  • Bekijk een topologiegrafiekvisualisatie die laat zien welke microservices met elkaar communiceren, waar aanvragen heengaan en hoe lang ze duren.
  • Controleer op specifieke aanvragen en antwoorden om te zien hoe en wanneer deze plaatsvinden voor het bewaken en oplossen van problemen met gedistribueerde systemen.

Services waarneembaarheid slechts één discipline van uw strategie voor cloudbewaking. Raadpleeg voor meer informatie over beheerdisciplines het kritieke ontwerpgebied Management disciplines.

Volgende stappen

Zie de volgende artikelen voor meer informatie over uw hybride en multicloudcloudcloudtraject: