Problemen met API-servers en etcd in Azure Kubernetes Services oplossen
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
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.
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_bytes
u . 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:
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
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
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.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor