De fleste av applikasjonene som kjører på et distribuert system som Kubernetes er alltid live som webservere eller databaser eller API -servere. Men det er en separat klasse av objekter som er ment å løpe en gang eller bare våkne opp hver gang og løpe kurset. Periodiske jobber som TLS -sertifikatfornyelser med agenter som CertBot er klassisk eksempel på slike jobber som kjører på tradisjonelle servere. Disse gjøres ved hjelp av CRON -verktøyet i UNIX -systemer.

Kubernetes har en analog måte å kjøre en gangsprosesser Arbeidsplasser og periodiske prosesser som Cron Jobs.

Vi vil starte med et typisk eksempel på hvilke jobber som er og demonstrere et standardeksempel fra de offisielle dokumentene. Fra dette eksemplet vil det være lett å forstå hva det betyr ved å kjøre en jobb med hell i Kubernetes 'kontekst.

For å følge med, vil jeg anbefale deg å bruke Kataconda lekeplass til Kubernetes som vil gi en ut av boksen Kubernetes -klyngen uten at du må konfigurere en manuelt eller risikere en produksjonsklynge for eksperimenter manuelt.

Kubernetes jobber

Jobber er høyere nivå Kubernetes abstraksjoner, ligner på replikasetter og distribusjoner. Men i motsetning til POD -er som administreres av distribusjoner og replikasetter, utfører Pods en jobb med å fullføre arbeidet og avslutte.

Når et spesifisert antall pods når fullført, sies jobben å ha fullført. Hva er kriteriene som definerer en vellykket avslutning av en pod, er noe vi vil definere i jobbens YAML -fil. Da vil jobbkontrolleren sikre at et visst antall pods har avsluttet og jobben sies å være fullført.

La oss skape en jobb som skriver ut sifre av Pi opptil 2000 steder i loggene som vi vil undersøke. Lag en fil og ring den jobben min.Yaml og lagre følgende innhold i det;

Apiversion: Batch/V1
Kind: Jobb
metadata:
Navn: Pi
spesifikasjon
mal:
spesifikasjon
Containere:
- Navn: Pi
Bilde: Perl
Kommando: ["Perl", "-Mbignum = BPI", "-Wle", "Print BPI (2000)"]
RestartPolicy: Aldri
BackoffLimit: 4

Lag jobben, ved å bruke denne filen:

$ kubectl opprette -f ./jobb.Yaml

Du vil legge merke til at jobben med tar noen sekunder til et par minutter å løpe, og når den først er gjort. Når du prøver å liste opp alle podene som bruker:

$ kubectl få pods
Navnet klar status starter alderen på nytt
PI-WG6ZP 0/1 fullført 0 50S

Du vil se at statusen til PI -relatert pod er Fullført ikke løpe eller avsluttes.Du kan også kopiere av navnet på pod slik at vi kan bekrefte at Pi faktisk er beregnet til 2000 sifre. Det spesifikke navnet på poden kan variere i saken din.

$ kubectl logger pi-wg6zp

Interessant nok har ikke poden Avsluttet Det er fremdeles veldig aktivt, bare at det ikke er noen applikasjoner som kjører inni den. Ligner på å bare slå på datamaskinen din og ikke bruke den. Hvis poden ble avsluttet, ville vi ikke ha klart å trekke loggene fra den, i utgangspunktet.

For å rydde opp i jobben og alle belgene som ble opprettet, kjør kommandoen:

$ kubectl slett -f my -jobs.Yaml

Du kan lære mer om jobbspesifikasjonene og hvordan du skriver spesifikasjonen din i den offisielle dokumentasjonen.

Cron Jobs

Cron Jobs ligner på Cron -verktøyet i UNIX som går med jevne mellomrom i henhold til en plan som vi ønsker. Det er ikke en supertabil ting i Kubernetes, på dette tidspunktet, så det kan være lurt å være forsiktig med å bruke. For å sitere de offisielle dokumentene:

“En cronjobb skaper et jobbobjekt Om En gang per utførelsestid for planen. Vi sier "om" fordi det er visse omstendigheter der det kan skapes to jobber, eller ingen jobb kan opprettes. Vi prøver å gjøre disse sjeldne, men forhindrer dem ikke helt. Derfor bør jobber være idempotent”

Begrepet idempotent betyr at Cron -jobben, enten det utføres en eller to ganger eller et hvilket som helst antall tid, vil ha samme effekt på systemet. Å sjekke for oppdateringer, overvåke den slags operasjoner kan betraktes som idempotent. Men å endre data, eller skrive til en database er ikke blant disse.

La oss skrive en cronjobb som ville skrive en "hei, verden!”Melding i loggene sammen med en tidsstempel på da den meldingen ble skrevet. Lag fil som heter My-Cronjob.yaml og til det skriv følgende innhold:

Apiversion: Batch/V1beta1
Kind: Cronjob
metadata:
Navn: My-Cronjob
spesifikasjon
Planlegg: " */1 * * * *"
JobTemplate:
spesifikasjon
mal:
spesifikasjon
Containere:
- Navn: Hei
Bilde: Busybox
args:
- /bin/sh
- -c
- Dato; ekko hei fra Kubernetes -klyngen
RestartPolicy: Onfailure

Planleggingsdelen av jobben er den mest avgjørende. Det følger standard cron -konvensjonen, det er en liste over tall atskilt etter mellomrom. De fem tallene representerer,

1. Minutt (0-59)
2. Time (0-23)
3. Månedens dag (1-31)
4. Måned (1-12)
5. Ukens dag (0-6) fra søndag

Bruker stjerne (*) for et felt betyr enhver tilgjengelig verdi av dette feltet (som et jokertegn) og den første oppføringen i planen vår “ */1 * * * *” indikerte at jobben må kjøres hvert minutt uavhengig av timen, dag eller måned av året. Bruke */5 vil skrive ut meldingen hvert 5. minutt.

Du kan lære mer om Cronjob YAML -spesifikasjonen i de offisielle dokumentene. La oss se alle belgene som kjører for jobben, som vi kalte My-Cronjob.

$ kubectl få pods
Navnet klar status starter alderen på nytt
My-Cronjob-1534457100-HFHZF 0/1 fullført 0 2M
My-Cronjob-1534457160-GK85L 0/1 fullført 0 1M
My-Cronjob-1534457220-BJ22X 0/1 fullført 0 57S

Å grave i tømmerstokkene til hver av belgene ville avsløre en enkelt melding med en tidsstempel, siden de alle ble opprettet til forskjellige tider, vil de alle ha forskjellige tidsstempler.

$ Kubectl Log My-Cronjob-1534457100-HFHZF

For å slette Cronjob kjører ganske enkelt:

$ kubectl slett -f my -cronjob.Yaml

Dette vil også slette eventuelle pods som ble opprettet i den rette prosessen.

Referanser

Du kan lære mer om Kubernetes-jobber her og for Cron-jobber du kan besøke denne delen av deres godt strukturerte dokumentasjon.