Delen via

Problemen met API-servers en etcd in Azure Kubernetes Services oplossen

  • Artikel

Deze handleiding is ontworpen om u te helpen bij het identificeren en oplossen van onwaarschijnlijke problemen die u mogelijk ondervindt op de API-server in grote AKS-implementaties (Microsoft Azure Kubernetes Services).

Microsoft heeft de betrouwbaarheid en prestaties van de API-server getest op een schaal van 5000 knooppunten en 200.000 pods. Het cluster met de API-server heeft de mogelijkheid om automatisch uit te schalen en Kubernetes Service Level Objectives (SLO's) te leveren. Als u te maken krijgt met hoge latenties of time-outs, komt dit waarschijnlijk doordat er een resourcelek optreedt in de gedistribueerde etc map (etcd) of omdat een client die in overtreding is, overmatige API-aanroepen heeft.

Vereisten

  • Azure CLI.

  • Het kubectl-hulpprogramma Kubernetes . Als u kubectl wilt installeren met behulp van Azure CLI, voert u de opdracht az aks install-cli uit.

  • Diagnostische AKS-logboeken (met name kube-auditgebeurtenissen) die zijn ingeschakeld en verzonden naar een Log Analytics-werkruimte. Als u wilt bepalen of logboeken worden verzameld met behulp van resourcespecifieke of diagnostische modus van Azure, controleert u de blade Diagnostische instellingen in de Azure Portal.

  • De Standard-laag voor AKS-clusters. Als u de gratis laag gebruikt, bevatten de API-server en etcd beperkte resources. AKS-clusters in de gratis laag bieden geen hoge beschikbaarheid. Dit is vaak de hoofdoorzaak van problemen met de API-server en etcd.

  • De kubectl-aks-invoegtoepassing voor het rechtstreeks uitvoeren van opdrachten op AKS-knooppunten zonder het Kubernetes-besturingsvlak te gebruiken.

Symptomen

De volgende tabel bevat een overzicht van de veelvoorkomende symptomen van API-serverfouten:

Symptoom Omschrijving
Time-outs van de API-server Frequente time-outs die buiten de garanties in de SLA van de AKS API-server vallen. Bijvoorbeeld: kubectl time-out van opdrachten.
Hoge latentie Hoge latenties waardoor de Kubernetes-SLO's mislukken. De opdracht duurt bijvoorbeeld kubectl meer dan 30 seconden om pods weer te geven.
API-serverpod in CrashLoopbackOff de status of geconfronteerd met webhook-aanroepfouten Controleer of u geen aangepaste toegangswebhook hebt (zoals de Kyverno-beleidsengine ) die de aanroepen naar de API-server blokkeert.

Controlelijst voor probleemoplossing

Als u hoge latentietijden ondervindt, volgt u deze stappen om de betreffende client en de typen API-aanroepen te bepalen die mislukken.

Stap 1: de belangrijkste gebruikersagents identificeren op het aantal aanvragen

Als u wilt bepalen welke clients de meeste aanvragen genereren (en mogelijk de meeste API-serverbelasting), voert u een query uit die lijkt op de volgende code. De volgende query bevat de top 10 gebruikersagents op basis van het aantal verzonden API-serveraanvragen.

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| summarize count() by UserAgent
| top 10 by count_
| project UserAgent, count_

Opmerking

Als uw query geen resultaten retourneert, hebt u mogelijk de verkeerde tabel geselecteerd om diagnostische logboeken op te vragen. In de resourcespecifieke modus worden gegevens naar afzonderlijke tabellen geschreven, afhankelijk van de categorie van de resource. Diagnostische logboeken worden naar de AKSAudit tabel geschreven. In de diagnostische modus van Azure worden alle gegevens naar de AzureDiagnostics tabel geschreven. Zie Azure-resourcelogboeken voor meer informatie.

Hoewel het handig is om te weten welke clients het hoogste aanvraagvolume genereren, is hoog aanvraagvolume alleen mogelijk geen reden tot bezorgdheid. Een betere indicator van de werkelijke belasting die elke client genereert op de API-server is de reactielatentie die ze ervaren.

Stap 2: De gemiddelde latentie van API-serveraanvragen per gebruikersagent identificeren en in kaart brengen

Voer de volgende query uit om de gemiddelde latentie van API-serveraanvragen per gebruikersagent te identificeren, zoals weergegeven in een tijddiagram:

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by UserAgent, bin(start_time, 5m)
| render timechart

Deze query is een vervolg op de query in de sectie 'Identificeer de belangrijkste gebruikersagents op basis van het aantal aanvragen' . Het kan u meer inzicht geven in de werkelijke belasting die door elke gebruikersagent in de loop van de tijd wordt gegenereerd.

Tip

Door deze gegevens te analyseren, kunt u patronen en afwijkingen identificeren die kunnen duiden op problemen in uw AKS-cluster of toepassingen. U ziet bijvoorbeeld dat een bepaalde gebruiker een hoge latentie ondervindt. Dit scenario kan het type API-aanroepen aangeven dat overmatige belasting veroorzaakt op de API-server of enzovoort.

Stap 3: Ongeldige API-aanroepen identificeren voor een bepaalde gebruikersagent

Voer de volgende query uit om de latentie van het 99e percentiel (P99) van API-aanroepen in verschillende resourcetypen voor een bepaalde client te tabuleren:

AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend HttpMethod = Verb
| extend Resource = tostring(ObjectRef.resource)
| where UserAgent == "DUMMYUSERAGENT" // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource
| render table

De resultaten van deze query kunnen handig zijn om de soorten API-aanroepen te identificeren die mislukken voor de upstream Kubernetes-SLO's. In de meeste gevallen kan een client die zich beledigt te veel LIST aanroepen voor een grote set objecten of objecten die te groot zijn. Helaas zijn er geen harde schaalbaarheidslimieten beschikbaar om gebruikers te helpen bij de schaalbaarheid van API-servers. Schaalbaarheidslimieten voor API-servers of etcd zijn afhankelijk van verschillende factoren die worden uitgelegd in Schaalbaarheidsdrempels voor Kubernetes.

Oorzaak 1: Een netwerkregel blokkeert het verkeer van agentknooppunten naar de API-server

Een netwerkregel kan verkeer tussen de agentknooppunten en de API-server blokkeren.

Voer de volgende kubectl-aks-opdrachten uit om te controleren of een onjuist geconfigureerd netwerkbeleid de communicatie tussen de API-server en agentknooppunten blokkeert:

kubectl aks config import \
    --subscription <mySubscriptionID> \
    --resource-group <myResourceGroup> \
    --cluster-name <myAKSCluster>

kubectl aks check-apiserver-connectivity --node <myNode>

De opdracht voor het importeren van configuratie haalt de gegevens van de virtuele-machineschaalset op voor alle knooppunten in het cluster. Vervolgens gebruikt de opdracht check-apiserver-connectivity deze informatie om de netwerkverbinding tussen de API-server en een opgegeven knooppunt te controleren, met name voor het onderliggende schaalsetexemplaren.

Opmerking

Als de uitvoer van de check-apiserver-connectivity opdracht het Connectivity check: succeeded bericht bevat, is de netwerkverbinding niet mogelijk.

Oplossing 1: Het netwerkbeleid herstellen om de verkeersblokkering te verwijderen

Als de uitvoer van de opdracht aangeeft dat er een verbindingsfout is opgetreden, configureert u het netwerkbeleid opnieuw, zodat het verkeer tussen de agentknooppunten en de API-server niet onnodig wordt geblokkeerd.

Oorzaak 2: Een beledende client lekt etcd-objecten en resulteert in een vertraging van etcd

Een veelvoorkomend probleem is het continu maken van objecten zonder ongebruikte objecten in de etcd-database te verwijderen. Dit kan prestatieproblemen veroorzaken wanneer etcd te veel objecten (meer dan 10.000) van welk type dan ook behandelt. Een snelle toename van wijzigingen in dergelijke objecten kan er ook toe leiden dat de databasegrootte van etcd (standaard 4 gigabyte) wordt overschreden.

Als u het gebruik van de etcd-database wilt controleren, gaat u naar Problemen vaststellen en oplossen in de Azure Portal. Voer het hulpprogramma Etcd-beschikbaarheidsproblemen uit door te zoeken naar 'etcd' in het zoekvak. In het diagnosehulpprogramma ziet u de uitsplitsing van het gebruik en de totale databasegrootte.

Azure Portal schermopname van de Etcd-beschikbaarheidsdiagnose voor Azure Kubernetes Service (AKS).

Als u alleen een snelle manier wilt om de huidige grootte van uw etcd-database in bytes weer te geven, voert u de volgende opdracht uit:

kubectl get --raw /metrics | grep -E "etcd_db_total_size_in_bytes|apiserver_storage_size_bytes|apiserver_storage_db_total_size_in_bytes"

Opmerking

De metrische naam in de vorige opdracht verschilt voor verschillende Kubernetes-versies. Voor Kubernetes 1.25 en eerder gebruikt etcd_db_total_size_in_bytesu . Voor Kubernetes 1.26 tot en met 1.28 gebruikt u apiserver_storage_db_total_size_in_bytes.

Oplossing 2: quota definiëren voor het maken van objecten, het verwijderen van objecten of het beperken van de levensduur van objecten in etcd

Als u wilt voorkomen dat etcd de capaciteit bereikt en downtime van clusters veroorzaakt, kunt u het maximum aantal resources beperken dat wordt gemaakt. U kunt ook het aantal revisies dat wordt gegenereerd voor resource-exemplaren vertragen. Als u het aantal objecten wilt beperken dat kan worden gemaakt, kunt u objectquota definiëren.

Als u objecten hebt geïdentificeerd die niet meer in gebruik zijn, maar resources in beslag nemen, kunt u overwegen deze te verwijderen. U kunt bijvoorbeeld voltooide taken verwijderen om ruimte vrij te maken:

kubectl delete jobs --field-selector status.successful=1

Voor objecten die ondersteuning bieden voor automatisch opschonen, kunt u TTL-waarden (Time to Live) instellen om de levensduur van deze objecten te beperken. U kunt uw objecten ook labelen, zodat u alle objecten van een specifiek type bulksgewijs kunt verwijderen met behulp van labelkiezers. Als u eigenaarverwijzingen tussen objecten tot stand brengt, worden alle afhankelijke objecten automatisch verwijderd nadat het bovenliggende object is verwijderd.

Oorzaak 3: Een beledende client maakt overmatige LIST- of PUT-aanroepen

Als u vaststelt dat etcd niet wordt overbelast met te veel objecten, kan een beledende client te veel LIST of PUT aanroepen naar de API-server maken.

Oplossing 3a: Uw API-aanroeppatroon afstemmen

Overweeg het API-aanroeppatroon van uw client af te stemmen om de druk op het besturingsvlak te verminderen.

Oplossing 3b: Een client beperken die het besturingsvlak overweldigt

Als u de client niet kunt afstemmen, kunt u de functie Prioriteit en eerlijkheid in Kubernetes gebruiken om de client te beperken. Met deze functie kunt u de status van het besturingsvlak behouden en voorkomen dat andere toepassingen mislukken.

De volgende procedure laat zien hoe u de LIST Pods-API van een offending-client kunt beperken die is ingesteld op vijf gelijktijdige aanroepen:

  1. Creatie een FlowSchema dat overeenkomt met het API-aanroeppatroon van de betreffende client:

    apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema
metadata:
  name: restrict-bad-client
spec:
  priorityLevelConfiguration:
    name: very-low-priority
  distinguisherMethod:
    type: ByUser
  rules:
  - resourceRules:
    - apiGroups: [""]
      namespaces: ["default"]
      resources: ["pods"]
      verbs: ["list"]
    subjects:
    - kind: ServiceAccount
      serviceAccount:
        name: bad-client-account
        namespace: default

  2. Creatie een configuratie met lagere prioriteit om slechte API-aanroepen van de client te beperken:

    apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: PriorityLevelConfiguration
metadata:
  name: very-low-priority
spec:
  limited:
    assuredConcurrencyShares: 5
    limitResponse:
      type: Reject
  type: Limited

  3. Bekijk de vertraagde aanroep in de metrische gegevens van de API-server.

    kubectl get --raw /metrics | grep "restrict-bad-client"

Oorzaak 4: Een aangepaste webhook kan een impasse veroorzaken in API-serverpods

Een aangepaste webhook, zoals Kyverno, veroorzaakt mogelijk een impasse in API-serverpods.

Controleer de gebeurtenissen die betrekking hebben op uw API-server. Mogelijk ziet u gebeurtenisberichten die lijken op de volgende tekst:

Er is een interne fout opgetreden: het aanroepen van webhook 'mutate.kyverno.svc-fail': kan webhook niet aanroepen: Post "https://kyverno-system-kyverno-system-svc.kyverno-system.svc:443/mutate/fail?timeout=10s": write unix @->/tunnel-uds/proxysocket: write: broken pipe

In dit voorbeeld blokkeert de validerende webhook het maken van bepaalde API-serverobjecten. Omdat dit scenario kan optreden tijdens bootstrap, kunnen de API-server en Konnectivity-pods niet worden gemaakt. Daarom kan de webhook geen verbinding maken met deze pods. Deze reeks gebeurtenissen veroorzaakt de impasse en het foutbericht.

Oplossing 4: Webhook-configuraties verwijderen

U kunt dit probleem oplossen door de configuraties voor valideren en muteren van de webhook te verwijderen. Als u deze webhook-configuraties in Kyverno wilt verwijderen, raadpleegt u het artikel Over het oplossen van problemen met Kyverno.

Disclaimerinformatie van derden

Microsoft verstrekt contactgegevens van derden om u te helpen aanvullende informatie over dit onderwerp te vinden. Deze contactinformatie kan zonder voorafgaande kennisgeving worden gewijzigd. Microsoft garandeert de juistheid van contactgegevens van derden niet.

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.