Mestring av AKS-feilsøking #1: Løse tilkoblings- og DNS-feil (2023)

AKS eller Azure Kubernetes Service er en fullstendig administrert Kubernetes container orkestreringstjeneste som lar deg distribuere, skalere og administrere containeriserte applikasjoner enkelt. Men selv med de mest robuste systemene kan det oppstå problemer som krever feilsøking.

Dette blogginnlegget markerer begynnelsen på en tredelt serie, som stammer fra en intensiv en-dags bootcamp fokusert på avansert AKS-nettverkstriage og feilsøkingsscenarier. Det tilbyr en praktisk tilnærming til å diagnostisere og løse vanlige AKS-nettverksproblemer, med sikte på å utruste leserne med raske feilsøkingsferdigheter for deres AKS-miljø.

Hvert innlegg går gjennom et sett med scenarier som simulerer typiske problemer. Detaljerte oppsettinstruksjoner vil bli gitt for å bygge et funksjonelt miljø. Det vil da bli introdusert feil som gjør at oppsettet ikke fungerer. Det vil bli gitt tips om hvordan du kan utrede og feilsøke disse problemene ved å bruke vanlige verktøy som f.ekskubectl, nslookup og tcpdump. Hvert scenario avsluttes med reparasjoner for problemene og forklaring av trinnene som er tatt for å løse problemet.

Før du setter opp AKS, sørg for at du har en Azure-konto og et abonnement, med tillatelser som lar deg opprette ressursgrupper og distribuere AKS-klynger. PowerShell må være tilgjengelig da PS-skript vil bli brukt. Følg instruksjonene gitt i denneGithub-lenkeå sette opp AKS og kjøre scenarier. Det anbefales også at du leser deg opp om feilsøkinginngåendeogutgåendenettverksscenarier som kan oppstå i ditt AKS-miljø.

For innkommende scenarier gjelder feilsøking av tilkoblingsproblemer applikasjoner som er vert på AKS-klyngen.Linkbeskriver problemer knyttet til brannmurregler, nettverkssikkerhetsgrupper eller belastningsbalansere, og gir veiledning om å verifisere nettverkstilkobling, sjekke applikasjonslogger og undersøke nettverkstrafikk for å identifisere potensielle flaskehalser.

For utgående tilgang,feilsøkingsscenarierer relatert til trafikk som forlater AKS-klyngen, for eksempel problemer med tilkobling til eksterne ressurser som databaser, APIer eller andre tjenester som er vert utenfor AKS-klyngen.

Figuren nedenfor viser AKS-miljøet, som bruker et tilpasset VNet med sin egen NSG knyttet til det tilpassede undernettet. AKS-oppsettet bruker det tilpassede subnettet og vil ha sin egen NSG opprettet og koblet til nettverksgrensesnittet til Nodepool. Eventuelle endringer i AKS-nettverket legges automatisk til dens NSG. For å bruke AKS NSG-endringer på den tilpassede subnett-NSG, må de imidlertid legges til eksplisitt.

Objektiv: Målet med denne øvelsen er å feilsøke og løse tilkobling mellom pods og tjenester innenfor den samme Kubernetes-klyngen.

Oppsett: AKS-klyngeoppsett med 2 Pods opprettet av deres respektive distribusjoner og eksponert ved bruk av Cluster IP Service.

Trinn 1: Sett opp miljøet

Sett opp AKS somskissert i dette manuset.
Opprett navneområdestudent og angi kontekst til dette navneområdet

kubectl opprette ns student
kubectl config set-context --current --namespace=student

# Bekreft gjeldende navneområde
kubectl config view --minify --output 'jsonpath={..namespace}'

Trinn 2: Opprett to distribusjoner og respektive tjenester

Lag en distribusjon nginx-1 med et enkelt nginx-bilde:

kubectl opprette distribusjon nginx-1 --image=nginx

Vis distribusjonen som en ClusterIP-tjeneste:

kubectl expose distribusjon nginx-1 --navn nginx-1-svc --port=80 --target-port=80 --type=ClusterIP

Gjenta trinnene ovenfor for å opprette nginx-2-distribusjon og en tjeneste:

kubectl opprette distribusjon nginx-2 --image=nginx
kubectl expose distribusjon nginx-2 --navn nginx-2-svc --port=80 --target-port=80 --type=ClusterIP

Bekreft distribusjon og tjenestefunksjon. Pods skal kjøre og tjenester lytte på Port 80.

kubectl få alt

Trinn 3: Bekreft at du kan få tilgang til begge tjenestene fra klyngen ved å bruke klynge-IP-adresser

# Tjenester returnert: nginx-1-svc for pod/nginx-1, nginx-2-svc for pod/nginx-2
kubectl få svc

# Få verdiene til og
kubectl få pods

# nedenfor skal presentere HTML-side fra nginx-2
kubectl exec -it -- curl nginx-2-svc:80

# nedenfor bør presentere HTML-side fra nginx-1
kubectl exec -it -- curl nginx-1-svc:80

# sjekk endepunkter for tjenestene
kubectl få ep

Trinn 4: Sikkerhetskopier eksisterende distribusjoner

Sikkerhetskopier distribusjonen knyttet til nginx-2-distribusjon:

kubectl få deployment.apps/nginx-2 -o yaml > nginx-2-dep.yaml

Sikkerhetskopier tjenesten knyttet til nginx-2-tjenesten:

kubectl få service/nginx-2-svc -o yaml > nginx-2-svc.yaml

Trinn 5: Simuler service nede

Slett nginx-2-distribusjon

kubectl slette -f nginx-2-dep.yaml

Brukødelagt.yamldistribusjonsfil funnet iLab1mappe

kubectl gjelder -f broken.yaml

Bekreft at alle pods kjører

kubectl få alt

Trinn 6: Feilsøk problemet

Nedenfor er inngående flyt. Bekreft hvert trinn ovenfra og ned.

Sjekk tilstanden til nodene i klyngen for å se om det er et nodeproblem

kubectl får noder

Bekreft at du ikke lenger har tilgangnginx-2-svcfra klyngen

kubectl exec -it  -- curl nginx-2-svc:80
# msg Kunne ikke koble til nginx-2-svc port 80: Tilkobling nektet

Bekreft at du har tilgangnginx-1-svcfra klyngen

kubectl exec -it  -- curl nginx-1-svc:80
# viser HTML-side

Bekreft at du har tilgangnginx-2lokalt. Dette bekrefter ingen problemer med nginx-2-applikasjonen.

kubectl exec -it  -- curl localhost:80
# viser HTML-side

Sjekk endepunktene ved å bruke kommandoen nedenfor og kontroller at de riktige endepunktene stemmer overens med tjenestene deres. Det bør være minst 1 Pod tilknyttet en tjeneste, men ingen ser ut til å eksistere for nginx-2-tjenesten, men nginx-2-tjeneste/pod-tilknytning er bra.

kubectl få ep

Sjekk etikettvelgeren som brukes av tjenesten som opplever problemet, ved å bruke kommandoen nedenfor:

kubectl beskriver tjenesten

Sørg for at den samsvarer med etikettvelgeren som brukes av dens korresponderende distribusjon ved å bruke describe-kommandoen:

kubectl beskriver distribusjon

Bruk 'k get svc' og 'k get deployment' for å få tjeneste- og distribusjonsnavn.

Merker du noen avvik?

Bruk tjenesteetikettvelgeren fra #3, sjekk at podene valgt av tjenesten samsvarer med podene opprettet av distribusjonen ved å bruke følgende kommando

kubectl get pods --selector=

Hvis ingen resultater returneres, må det være en etikettvelger som ikke samsvarer.

Fra figuren nedenfor returnerer velgeren brukt av distribusjonen pods, men ikke velgeren som brukes av tilsvarende tjeneste.

Sjekk tjeneste- og pod-logger og sørg for at HTTP-trafikk blir sett. Sammenlign nginx-1 pod og servicelogger med nginx-2. Sistnevnte viser ikke GET-forespørsler, og antyder ingen innkommende trafikk.

k logger pod/ # ingen innkommende trafikk
k logger pod/ # HTTP-trafikk som vist nedenfor

k logger svc/
k logger svc/

Trinn 7: Gjenopprett tilkoblingen

Sjekk etikettvelgeren tjenesten er knyttet til, og få tilknyttede pods:

# Få etikett
kubectl beskriver tjenesten nginx-2-svc

# Når du forsøker å skaffe pods ved å bruke tjenesteetiketten, resulterer det i "ingen ressurser funnet" eller "ingen pods tilgjengelig".
kubectl beskriver pods -l app=nginx-2

Oppdater distribusjon og bruk endringer.

kubectl slette -f nginx-2-dep.yaml

Iødelagt.yaml, oppdater etikettene 'app: nginx-02' til 'app: nginx-2', som vist nedenfor

kubectl bruk -f broken.yaml # eller bruk dep-nginx-2.yaml

k beskriv pod
k get ep # nginx-2 svc bør ha pods i motsetning til før

Bekreft at du nå kan få tilgang til den nyopprettede tjenesten fra klyngen:

# Bør returnere HTML-side fra nginx-2-svc
kubectl exec -it  -- curl nginx-2-svc:80# Bekreft ovenfor fra loggene
k logger pod/

Trinn 8: Bruk av egendefinerte domenenavn

For øyeblikket vil tjenester i navneområdet ditt «student» løse bruk..svc.cluster.local.

Kommandoen nedenfor skal returnere nettsiden.

k exec -it  -- curl nginx-2-svc.student.svc.cluster.local

Søke omødelagt2.yamliLab1mappen og start CoreDNS på nytt

kubectl gjelder -f broken2.yaml
kubectl slett pods -l=k8s-app=kube-dns -n kube-system

# Overvåk for å sikre at pods kjører
kubectl få pods -l=k8s-app=kube-dns -n kube-system

Bekreft om DNS-oppløsning fungerer og den skulle mislykkes med "krøll: (6) Kunne ikke løse vert:"

k exec -it  -- curl nginx-2-svc.student.svc.cluster.local
k exec -it  -- curl nginx-2-svc

Sjekk DNS-konfigurasjonsfilene i kube-system som viser konfigurasjonskartet, som nedenfor.

k få cm -A -n kube-system | grep dns

Beskriv hver av de du finner ovenfor og se etter inkonsekvenser

k beskrive cm coredns -n kube-system
k beskrive cm coredns-autoscaler -n kube-system
k beskrive cm coredns-custom -n kube-system

Siden den egendefinerte DNS-filen inneholder de brytende endringene, kan du enten redigere coredns-custom og fjerne datadelen ELLER slette ConfigMap 'coredns-custom'. Sletting av kube-dns-pods bør gjenopprette slettede ConfigMap 'coredns-custom'.

kubectl slette cm coredns-custom -n kube-system
kubectl slett pods -l=k8s-app=kube-dns -n kube-system

# Overvåk for å sikre at pods kjører
kubectl få pods -l=k8s-app=kube-dns -n kube-system

Bekreft at DNS-oppløsningen fungerer som før.

kubectl exec -it  -- curl nginx-2-svc.student.svc.cluster.local

# Utfordringslaboratorie: Løs ved hjelp av FQDN aks.com #

# Kjør under kommandoen for å få vellykket DNS-oppløsning
k exec -it  -- curl nginx-2-svc.aks.com# Løsning #k anvende -f working2.yaml
kubectl slett pods -l=k8s-app=kube-dns -n kube-system# Overvåk for å sikre at pods kjører
kubectl få pods -l=k8s-app=kube-dns -n kube-system
# Bekreft arbeidet ved å bruke under cmd
k exec -it  -- curl nginx-2-svc.aks.com
# Gå tilbake til standard
k slett cm coredns-custom -n kube-system
kubectl slett pods -l=k8s-app=kube-dns -n kube-system
# Overvåk for å sikre at pods kjører
kubectl få pods -l=k8s-app=kube-dns -n kube-system

Trinn 9: Hva var i de ødelagte filene

Iødelagt.yamldistribusjonsetiketter stemte ikke overens med tjenesten, dvs. det burde vært nginx-2

Iødelagt2.yamlbruddendringer ble gjort som løste «student.svc.cluster.local» til «bad.cluster.local», noe som brøt DNS-oppløsningen.

$kubectl_apply=@"
apiVersjon: v1
type: ConfigMap
metadata:
navn: coredns-tilpasset
navneområde: kube-system
data:
internal-custom.override: | # hvilket som helst navn med .server-utvidelse
omskriv stopp {
navn regulert uttrykk (.*)\.svc\.cluster\.local {1}.bad.cluster.local.
svarnavn (.*)\.bad\.cluster\.local {1}.svc.cluster.local.
}
"@
$kubectl_apply | kubectl gjelder -f -

Trinn 10: Opprydding

k slett deployment/nginx-1 deployment/nginx-2 service/nginx-1-svc service/nginx-2-svc
eller bare slett navneområde > k slett ns student

Objektiv: Målet med denne øvelsen er å feilsøke og løse Pod DNS-oppslag og DNS-oppløsningsfeil.

Oppsett:Klyngelayout som vist nedenfor har NSG brukt på AKS-undernett, med nettverkspolicyer i kraft.

Trinn 1: Sett opp miljøet

Sett opp AKS somskissert i dette manuset.
Opprett og bytt til det nyopprettede navneområdet

kubectl opprette ns student
kubectl config set-context --current --namespace=student

# Bekreft gjeldende navneområde
kubectl config view --minify --output 'jsonpath={..namespace}'

Klone løsningerGithub-lenkeog endre katalog til Lab2, dvs. cd Lab2.

Trinn 2: Bekreft at DNS-oppløsningen fungerer i klyngen

Opprett pod for DNS-validering i Pod

kubectl kjøre dns-pod --image=nginx --port=80 --restart=Aldri
kubectl exec -it dns-pod -- bash

# Kjør disse kommandoene ved bash-ledeteksten
apt-get update -y
apt-get install dnsutils -y
exit

Test og bekreft at DNS-oppløsningen løses til riktig IP-adresse.

kubectl exec -it dns-pod -- nslookup kubernetes.default.svc.cluster.local

Trinn 3: Bryt DNS-oppløsningen

FraLab2mappe gjelderødelagt1.yaml

kubectl gjelder -f broken1.yaml

Bekreft at du kjører under kommandoen, resulterer i 'tilkobling tidsavbrutt; ingen servere kunne nås'

kubectl exec -it dns-pod -- nslookup kubernetes.default.svc.cluster.local

Trinn 4: Feilsøk DNS-oppløsningsfeil

Bekreft at DNS-oppløsningen fungerer i AKS-klyngen

kubectl exec -it dns-pod -- nslookup kubernetes.default.svc.cluster.local
# Hvis svaret "tilkoblingen ble tidsavbrutt; ingen servere kunne nås, fortsett deretter nedenfor med feilsøking

Valider DNS-tjenesten som skal vise port53i bruk

kubectl få svc kube-dns -n kube-system

Sjekk logger for pods knyttet til kube-dns

$coredns_pod=$(kubectl get pods -n kube-system -l k8s-app=kube-dns -o=jsonpath='{.items[0].metadata.name}')
kubectl logger -n kube-system $coredns_pod

Hvis et tilpasset ConfigMap er til stede, kontroller at konfigurasjonen er riktig.

kubectl beskrive cm coredns-custom -n kube-system

Se etter nettverkspolicyer som er gjeldende. Hvis DNS-relatert, beskriv og bekreft ingen blokkere. Hvis nettverkspolicy er en blokkering, fjern den.

kubectl få nettverkspolicy -A
NAVNEROMMET NAVN POD-VELGER
kube-system block-dns-ingress k8s-app=kube-dns

kubectl beskriver nettverkspolicy block-dns-ingress -n kube-system
# skal vises på Ingress-bane som ikke tillater DNS-trafikk til UDP 53

Fjern den krenkende politikken

kubectl slett nettverkspolicy block-dns-ingress -n kube-system

Bekreft at DNS-oppløsningen fungerer i AKS-klyngen. Nedenfor er en annen måte å lage en Pod for å utføre oppgaven som nslookup og slette ved fullføring

kubectl run -it --rm --restart=Aldri test-dns --image=busybox --kommando -- nslookup kubernetes.default.svc.cluster.local
# Hvis DNS-oppløsningen fungerer som den skal, bør du se den riktige IP-adressen knyttet til domenenavnet

Sjekk at NSG har noen DENY-regler som kan blokkere port 80. Hvis den finnes, fjern den

# Under CLI-trinn kan også utføres som et oppslag på Azure-portalen under NSG

Trinn 5: Opprett ekstern tilgang via Loadbalancer

Utsett dns-pod med servicetype Load Balancer.

kubectl expose pod dns-pod --name=dns-svc --port=80 --target-port=80 --type LoadBalancer

Bekreft tildeling av ekstern IP.

kubectl få svc

Bekreft at ekstern IP-tilgang fungerer innenfor klyngen.

kubectl exec -it dns-pod -- curl

Bekreft fra nettleseren at ekstern IP-tilgang mislykkes fra internett til klyngen.

krølle

Trinn 6: Feilsøk ødelagt ekstern tilgang via Loadbalancer

Sjekk om AKS NSG brukt på VM-skalasettet har en Inbound HTTP Allow-regel.
Sjekk om AKS Custom NSG brukt på subnettet har en ALLOW-regel, og hvis ingen gjelder som nedenfor.

$custom_aks_nsg = "custom_aks_nsg" # <- verifiser
$nsg_list=az nettverk nsg list --query "[?contains(name,'$custom_aks_nsg')].{Name:name, ResourceGroup:resourceGroup}" --output json# Trekk ut tilpasset AKS-undernett NSG-navn, NSG-ressursgruppe
$nsg_name=$(ekko $nsg_list | jq -r '.[].Name')
$resource_group=$(echo $nsg_list | jq -r '.[].ResourceGroup')
echo $nsg_list, $nsg_name, $resource_group
$EXTERNAL_IP=""
az network nsg rule create --name AllowHTTPInbound `
--ressursgruppe$ressursgruppe--nsg-navn$nsg_name`
--destination-port-range80--destinasjon-adresse-prefiks$EXTERNAL_IP`
--kildeadresseprefikserInternett--protokolltcp`
--prioritet 100 --tilgang tillat

Etter ~60-årene, bekreft fra nettleseren at ekstern IP-tilgang lykkes fra internett til klyngen.

krølle

Trinn 7: Hva var i de ødelagte filene

Broken1.yaml er en nettverkspolicy som blokkerer UDP-inngangsforespørsler på port 53 til alle Pods

Trinn 8: Opprydding

k slett pod/dns-pod
eller
k slette ns elev

az network nsg rule delete --name AllowHTTPInbound `
--ressursgruppe $ressursgruppe --nsg-navn $nsg_navn

Dette innlegget viser vanlige tilkoblings- og DNS-problemer som kan oppstå når du arbeider med AKS.Theførste scenariofokuserer på å løse tilkoblingsproblemer mellom pods og tjenester innenfor Kubernetes-klyngen. Vi møtte problemer der de tilordnede etikettene for en distribusjon ikke samsvarte med de tilsvarende pod-etikettene, noe som resulterte i ikke-funksjonelle endepunkter. I tillegg har vi identifisert og rettet problemer med CoreDNS-konfigurasjon og tilpassede domenenavn.andre scenarioadresserer feilsøking av DNS og ekstern tilgangsfeil. Vi undersøkte hvordan feil konfigurerte nettverkspolicyer kan påvirke DNS-trafikken negativt. Ineste artikkel, den andre av den tredelte serien, vil vi fordype oss i feilsøkingsscenarier relatert til endepunkttilkobling på tvers av virtuelle nettverk og takle portkonfigurasjonsproblemer som involverer tjenester og deres tilhørende pods.

Eksempelskriptene støttes ikke av noe Microsofts standard støtteprogram eller -tjeneste. Eksempelskriptene leveres SOM DE ER uten noen form for garanti. Microsoft fraskriver seg videre alle underforståtte garantier, inkludert, uten begrensning, eventuelle underforståtte garantier for salgbarhet eller egnethet for et bestemt formål. Hele risikoen som oppstår ved bruk eller ytelse av eksempelskriptene og dokumentasjonen forblir hos deg. Microsoft, dets forfattere eller noen andre som er involvert i opprettelsen, produksjonen eller leveringen av skriptene skal ikke under noen omstendigheter holdes ansvarlige for skader overhodet (inkludert, uten begrensning, skader for tap av forretningsfortjeneste, forretningsavbrudd, tap av forretningsinformasjon , eller annet økonomisk tap) som oppstår ved bruk av eller manglende evne til å bruke eksempelskriptene eller dokumentasjonen, selv om Microsoft har blitt informert om muligheten for slike skader.