Kubectl -feilsøkingsfunksjonen

Et vanlig problem med nye Kubernetes -installasjoner er når en tjeneste ikke utfører ordentlig. Du har opprettet en tjeneste og kjører belgene dine via en distribusjon eller en annen oppgavelkontroller. Imidlertid skjer ingenting når du prøver å få tilgang til det. I dette innlegget vil vi forklare bakgrunnen for feilsøking, en ny funksjon i Kubectl. Hver pod i Kubernetes kjører som en Docker -beholder, som er atskilt ved hjelp av Linux Namespace Isolation -funksjonen. For prosesser har hver beholder sitt filsystem. Feilsøkingsfunksjonen automatiserer containervedlegg og deling av navneområder med en enkelt kommando og ingen manifestfiler.

Hver utvikler og DevOps -ingeniør som jobber med Kubernetes må feilsøke containeriserte arbeidsmengder og pods daglig. Enkle Kubectl -logger eller KUBECTL Beskriv pods kan ofte finne kilden til et problem. Visse problemer er imidlertid vanskeligere å spore opp. Du kan prøve Kubectl Exec i visse tilfeller. Selv det kanskje ikke er tilstrekkelig fordi noen containere, for eksempel Distroless, ikke engang har et skall som du kan SSH i. Så hvis alt det foregående mislykkes, hva er alternativene våre? Kubectl -feilsøkingen, som en ny instruksjon lagt til for ikke lenge siden (v1.18), ville være det rette verktøyet for feilsøking av arbeidsmengder på Kubernetes.

Forutsetninger

Før vi bruker Kubectl, må vi først validere operativsystemet. I vår situasjon kjører vi Ubuntu 20.04 på en datamaskin. Andre Linux -distribusjoner kan undersøkes for å forstå om de er egnet for dine behov eller ikke. En Minikube -klynge er pålagt å implementere Kubernetes -tjenestene på Linux. For å få denne guiden til å fungere, må du sette opp en Minikube -klynge på systemet ditt. Minikube gjør evaluering av kritiske trekk ved en Kubernetes -klynge en lek, med noe lett aktivert eller fjernet. Bruk kommandolinjeterminalen til å sette opp en Minikube -klynge. En av to tilnærminger er tilgjengelig for å åpne den. Se etter "terminal" i applikasjonssøkdelen av systemet ditt. En snarvei som kan brukes til dette er Ctrl+ALT+T:

$ Minikube Start

Hvordan du kjører kommandoer i en pod

Du vil observere hva en pod som opererer i klyngen ser i flere av fasene som følger. Å kjøre en interaktiv travelbox pod er den enkleste metoden for å gjøre dette:

$ kubectl run -it -rm -Restart = Never BusyBox -Image = GCR.IO/Google-Containers/BusyBox SH

Hvordan sette opp

La oss kjøre noen pods for denne leksjonen. Du kan enten bruke din egen informasjon fordi du sannsynligvis feilsøker din egen tjeneste, eller du enkelt kan følge med og få et annet datapunkt:

$ Kubectl Opprett distribusjon Hostnames -Image = GCR.io/server_hostname

Typen og navnet på ressursen som produseres eller endres vil bli skrevet ut av KUBECTL -instruksjoner, som deretter kan brukes i senere kommandoer. La oss øke antallet kopier i distribusjonen til tre:

$ KUBECTL skala distribusjon Hostnames -replicas = 3

Du kan sjekke om belgene dine fungerer ved å gjøre følgende:

$ kubectl få pods -l app = vertsnavn

Du kan også sjekke om belgene dine fungerer. På denne måten kan du få en liste over POD IP -adresser og teste dem med en gang:

$ kubectl get pods -l app = hostnames \

Eksempelbeholderen i dette innlegget bruker HTTP på porten for å oppgi vertsnavnet. Men hvis du feilsøker dette på egen hånd, bruk det portnummeret som belgene dine er på. Fra innsiden av en pod:

Hvis du ikke får resultatene du ønsker på dette stadiet, er det mulig at belgene dine ikke er sunne eller ikke lytter på porten du tror de er. Du kan ønske å undersøke Kubectl -tømmerstokkene, eller du må kanskje KUBECTL EXEC inn i belgene dine med en gang og feilsøke derfra. Hvis alle trinnene har vært utført nøyaktig så langt, kan du starte undersøkelsen om hvorfor tjenesten din ikke utfører ordentlig.

Er tjenesten opprettet?

Den skarpe leseren kan få en ide om at du ennå ikke har bygget en tjeneste, som faktisk er med vilje. Dette trinnet blir ofte oversett, men det er det første elementet å sjekke. Hvis tjenesten ikke er der ennå, oppretter du den først og sjekk om den fortsatt er der.

Faller målpodene under noen nettverkspolitiske inntrengningsregler?

Hvis du har noen nettverkspolitiske inntrengingsregler på plass som kan påvirke innkommende trafikk til vertsnavn-* pods, bør du gjennomgå dem.

Er tjenesten riktig definert?

Selv om det virker lite, dobbeltsjekk at tjenesten du har opprettet er nøyaktig og samsvarer med porten til pod. Løs tjenesten din på nytt og bekreft den. Hvis du har klart det så langt, har du bekreftet at tjenesten din er riktig definert og løst av DNS. Nå er det på tide å dobbeltsjekke at tjenesten henter belgene du opprettet.

Konklusjon

Denne artikkelen dekket alt du trenger å vite om Kubectls feilsøkingsfunksjon. Vi har også gitt omfattende eksempler for å hjelpe deg. Du kan følge alle trinnene i denne guiden for å få arbeidet ditt gjort effektivt. Vi håper du fant denne artikkelen nyttig. Finn flere tips og guider på Linux -hint.