Kubernetes - temme skyen

Når du vil bruke Linux til å levere tjenester til en bedrift, må disse tjenestene være sikre, elastiske og skalerbare. Fine ord, men hva mener vi med dem?

‘Sikker’ betyr at brukere kan få tilgang til dataene de trenger, være skrivebeskyttet eller skrivetilgang. Samtidig blir ingen data eksponert for noen part som ikke har rett til å se dem. Sikkerhet er villedende: du kan tro at du har alt beskyttet bare for å finne ut senere at det er hull. Å designe sikkerhet fra starten av et prosjekt er langt enklere enn å prøve å ettermontere det senere.

‘Motstandsdyktig’ betyr at tjenestene dine tåler feil i infrastrukturen. En feil kan være en serverdisk-kontroller som ikke lenger kan få tilgang til noen disker, noe som gjør dataene utilgjengelige. Eller feilen kan være en nettverkssvitsj som ikke lenger gjør det mulig for to eller flere systemer å kommunisere. I denne sammenheng er et “enkelt feilpunkt” eller SPOF en feil som påvirker tjenestetilgjengeligheten negativt. En elastisk infrastruktur er en uten SPOF.

‘Scalable’ beskriver systemers evne til å håndtere pigger av etterspørsel elegant. Det dikterer også hvor lett endringer kan gjøres i systemer. For eksempel å legge til en ny bruker, øke lagringskapasiteten eller flytte en infrastruktur fra Amazon Web Services til Google Cloud - eller til og med flytte den internt.

Så snart infrastrukturen utvides utover en server, er det mange muligheter for å øke sikkerheten, motstandskraften og skalerbarheten. Vi vil se på hvordan disse problemene tradisjonelt er blitt løst, og hvilken ny teknologi som er tilgjengelig som endrer ansiktet til databehandling for store applikasjoner.

Få mer Linux!

Liker du det du leser? Vil du ha mer Linux og åpen kildekode? Vi kan levere, bokstavelig talt! Abonner på Linux-format i dag til en god pris. Du kan få utgaver, digitale utgaver eller hvorfor ikke begge deler? Vi leverer til døren din over hele verden mot et enkelt årlig gebyr. Så gjør livet ditt bedre og enklere, abonner nå!

For å forstå hva som er mulig i dag, er det nyttig å se på hvordan teknologiprosjekter tradisjonelt har blitt implementert. Tilbake i gamle dager - det vil si for mer enn 10 år siden - ville bedrifter kjøpe eller lease maskinvare for å kjøre alle komponentene i applikasjonene deres. Selv relativt enkle applikasjoner, for eksempel et WordPress-nettsted, har flere komponenter. Når det gjelder WordPress, er det behov for en MySQL-database sammen med en webserver, for eksempel Apache, og en måte å håndtere PHP-kode på. Så de ville bygge en server, sette opp Apache, PHP og MySQL, installere WordPress og de skulle gå.

I det store og hele fungerte det. Det fungerte bra nok til at det fremdeles er et stort antall servere konfigurert på akkurat den måten i dag. Men det var ikke perfekt, og to av de større problemene var motstandsdyktighet og skalerbarhet.

Manglende motstandskraft betød at ethvert betydelig problem på serveren ville føre til tap av service. Tydeligvis vil en katastrofal feil ikke bety noe nettsted, men det var heller ikke rom for å utføre planlagt vedlikehold uten å påvirke nettstedet. Selv installering og aktivering av en rutinemessig sikkerhetsoppdatering for Apache vil kreve noen sekunders avbrudd for nettstedet.

Resiliensproblemet ble i stor grad løst ved å bygge ‘klynger med høy tilgjengelighet’. Prinsippet var å ha to servere som kjørte nettstedet, konfigurert slik at feilen på den ene ikke resulterte i at nettstedet var nede. Tjenesten som ble levert var spenstig selv om de enkelte serverne ikke var det.

Abstrakte skyer

En del av Kubernetes kraft er abstraksjonen den gir. Fra et utviklerperspektiv utvikler de applikasjonen for å kjøre i en Docker-container. Docker bryr seg ikke om den kjører på Windows, Linux eller et annet operativsystem. Den samme Docker-containeren kan tas fra utviklerens MacBook og kjøres under Kubernetes uten noen endringer.

Selve Kubernetes-installasjonen kan være en enkelt maskin. Selvfølgelig vil mange av fordelene med Kubernetes ikke være tilgjengelige: det blir ingen automatisk skalering; det er et åpenbart enkelt feilpunkt, og så videre. Som et bevis på konseptet i et testmiljø fungerer det imidlertid.

Når du er klar for produksjon, kan du kjøre internt eller hos en skyleverandør som AWS eller Google Cloud. Cloud-leverandørene har noen innebygde tjenester som hjelper til med å kjøre Kubernetes, men ingen av dem er harde krav. Hvis du vil flytte mellom Google, Amazon og din egen infrastruktur, setter du opp Kubernetes og beveger deg over. Ingen av søknadene dine må endres på noen måte.

Og hvor er Linux? Kubernetes kjører på Linux, men operativsystemet er usynlig for applikasjonene. Dette er et viktig skritt i modenhet og brukbarhet til IT-infrastrukturer.

Slashdot-effekten

Skalerbarhetsproblemet er litt vanskeligere. La oss si at WordPress-siden din får 1000 besøkende i måneden. En dag blir virksomheten din nevnt på Radio 4 eller frokost-TV. Plutselig får du mer enn en måneds besøkende på 20 minutter. Vi har alle hørt historier om nettsteder som "krasjer", og det er vanligvis derfor: mangel på skalerbarhet.

De to serverne som hjalp med motstandsdyktighet, kunne håndtere en høyere arbeidsbelastning enn en server alene kunne, men det er fortsatt begrenset. Du ville betalt for to servere 100 prosent av tiden, og mest av tiden fungerte begge perfekt. Det er sannsynlig at en alene kan drive nettstedet ditt. Deretter nevner John Humphrys virksomheten din i dag, og du trenger 10 servere for å håndtere belastningen - men bare i noen timer.

Den bedre løsningen på både elastisitets- og skalerbarhetsproblemet var cloud computing. Sett opp en serverforekomst eller to - de små serverne som kjører applikasjonene dine - på Amazon Web Services (AWS) eller Google Cloud, og hvis en av forekomsten mislyktes av en eller annen grunn, vil den automatisk startes på nytt. Sett opp automatisk skalering riktig, og når Mr Humphrys får arbeidsbelastningen på webserverforekomstene til å øke raskt, blir flere serverforekomster automatisk startet for å dele arbeidsmengden. Senere, når renten går ned, stoppes disse ekstra tilfellene, og du betaler bare for det du bruker. Perfekt … eller er det?

Mens skyløsningen er mye mer fleksibel enn den tradisjonelle frittstående serveren, er det fortsatt problemer. Det er ikke enkelt å oppdatere alle skyforekomster som kjører. Å utvikle for skyen har også utfordringer: den bærbare datamaskinen utviklerne bruker kan være lik skyforekomsten, men det er ikke det samme. Hvis du forplikter deg til AWS, er det vanskelig å migrere til Google Cloud. Og antar at du av en eller annen grunn ikke vil overgi databehandlingen til Amazon, Google eller Microsoft?

Beholdere har dukket opp som et middel til å pakke applikasjoner med alle deres avhengigheter opp i en enkelt pakke som kan kjøres hvor som helst. Beholdere, for eksempel Docker, kan kjøres på bærbare datamaskiner til utviklerne på samme måte som de kjører på skyforekomster, men det blir stadig mer utfordrende å administrere en flåte containere etter hvert som antallet containere vokser.

Svaret er containerorkestrering. Dette er et betydelig skift i fokus. Før sørget vi for at vi hadde nok servere, det være seg fysiske eller virtuelle, for å sikre at vi kunne betjene arbeidsmengden. Å bruke autoskalering av skyleverandørene hjalp, men vi har fortsatt å gjøre med tilfeller. Vi måtte konfigurere lastbalansere, brannmurer, datalagring og mer manuelt. Med orkestrering av containere blir alt dette (og mye mer) ivaretatt. Vi spesifiserer resultatene vi trenger, og verktøyene for containerorkestrering oppfyller våre krav. Vi spesifiserer hva vi vil ha gjort, snarere enn hvordan vi vil at det skal gjøres.

Kontinuerlig integrasjon og kontinuerlig distribusjon kan fungere bra med Kubernetes. Her er en oversikt over Jenkins som brukes til å bygge og distribuere et Java-program

Bli en Kubernete

Kubernetes (ku-ber-net-eez) er det ledende containerorkesteringsverktøyet i dag, og det kom fra Google. Hvis noen vet å kjøre enorme IT-infrastrukturer, gjør Google det. Opprinnelsen til Kubernetes er Borg, et internt Google-prosjekt som fremdeles brukes til å kjøre de fleste av Googles applikasjoner, inkludert søkemotoren, Gmail, Google Maps og mer. Borg var en hemmelighet helt til Google publiserte et papir om det i 2015, men papiret gjorde det veldig tydelig at Borg var den viktigste inspirasjonen bak Kubernetes.

Borg er et system som administrerer beregningsressurser i Googles datasentre og holder Googles applikasjoner, både produksjon og ellers, til tross for maskinvarefeil, ressursutmattelse eller andre problemer som kan oppstå som ellers kan ha forårsaket et brudd. Den gjør dette ved nøye å overvåke tusenvis av noder som utgjør en Borg "celle" og containerne som kjører på dem, og starte eller stoppe containere etter behov som svar på problemer eller svingninger i belastningen.

Kubernetes selv ble født ut av Googles GIFEE-initiativ (‘Googles infrastruktur for alle andre’), og ble designet for å være en vennligere versjon av Borg som kan være nyttig utenfor Google. Den ble donert til Linux Foundation i 2015 gjennom dannelsen av Cloud Native Computing Foundation (CNCF).

Kubernetes tilbyr et system der du "erklærer" dine containeriserte applikasjoner og tjenester, og det sørger for at applikasjonene kjører i henhold til disse erklæringene. Hvis programmene dine krever eksterne ressurser, for eksempel lagring eller belastningsbalanser, kan Kubernetes klargjøre disse automatisk. Det kan skalere applikasjonene dine opp eller ned for å holde tritt med endringer i belastning, og kan til og med skalere hele klyngen når det er nødvendig. Komponentene til programmet ditt trenger ikke en gang å vite hvor de kjører: Kubernetes tilbyr interne navngivningstjenester til applikasjoner slik at de kan koble til “wp_mysql” og automatisk kobles til riktig ressurs. ’

Sluttresultatet er en plattform som kan brukes til å kjøre applikasjonene dine på hvilken som helst infrastruktur, fra en enkelt maskin gjennom et lokalt systemstativ til skybaserte flåter av virtuelle maskiner som kjører på en hvilken som helst større skyleverandør, alle med samme containere og konfigurasjon. Kubernetes er leverandør-agnostiker: kjør det hvor du vil.

Kubernetes er et kraftig verktøy, og er nødvendigvis komplisert. Før vi kommer inn i en oversikt, må vi introdusere noen begreper som brukes i Kubernetes. Beholdere kjører enkeltapplikasjoner, som diskutert ovenfor, og er gruppert i bøtter. En pod er en gruppe tett sammenkoblede containere som distribueres sammen på samme vert og deler noen ressurser. Containerne i en pod fungerer som et team: de vil utføre relaterte funksjoner, for eksempel en applikasjonsbeholder og en loggbeholder med spesifikke innstillinger for applikasjonen.

En oversikt over Kubernetes som viser mesteren som kjører nøkkelkomponentene og to noder. Merk at i praksis kan hovedkomponentene være delt over flere systemer

Fire viktige Kubernetes-komponenter er API-serveren, planleggeren, kontrolleren og en distribuert konfigurasjonsdatabase kalt etcd. API-serveren er hjertet av Kubernetes, og fungerer som det primære endepunktet for alle administrasjonsforespørsler. Disse kan genereres av en rekke kilder, inkludert andre Kubernetes-komponenter, for eksempel planleggeren, administratorer via kommandolinje eller nettbaserte dashbord og selve containeriserte applikasjoner. Den validerer forespørsler og oppdaterer data lagret i etcd.

Planleggeren avgjør hvilke noder de forskjellige podene skal kjøre på, med tanke på begrensninger som ressurskrav, maskinvare- eller programvarebegrensninger, arbeidsmengde, tidsfrister og mer.

Controller Manager overvåker klyngens tilstand, og vil prøve å starte eller stoppe pods som nødvendigvis via API-serveren for å bringe klyngen til ønsket tilstand. Den administrerer også noen interne tilkoblinger og sikkerhetsfunksjoner.

Hver node kjører en Kubelet-prosess, som kommuniserer med API-serveren og administrerer containere - vanligvis ved bruk av Docker - og Kube-Proxy, som håndterer nettverksproxyering og lastbalansering i klyngen.

Det etcd distribuerte databasesystemet henter navnet sitt fra /etc mappe på Linux-systemer, som brukes til å holde systemkonfigurasjonsinformasjon, pluss suffikset ‘d’, ofte brukt for å betegne en demonprosess. Målet med etcd er å lagre nøkkelverdidata på en distribuert, konsistent og feiltolerant måte.

API-serveren holder alle tilstandsdataene sine i etcd og kan kjøre mange forekomster samtidig. Planleggeren og kontrollerbehandleren kan bare ha en aktiv forekomst, men bruker et leiesystem for å bestemme hvilken løpende forekomst som er mesteren. Alt dette betyr at Kubernetes kan kjøre som et svært tilgjengelig system uten noen feilpunkter.

Sette alt sammen

Så hvordan bruker vi disse komponentene i praksis? Det som følger er et eksempel på å sette opp et WordPress-nettsted ved hjelp av Kubernetes. Hvis du ønsket å gjøre dette på ekte, ville du sannsynligvis bruke en forhåndsdefinert oppskrift kalt et rordiagram. De er tilgjengelige for en rekke vanlige applikasjoner, men her ser vi på noen av trinnene som er nødvendige for å få et WordPress-nettsted i gang på Kubernetes.

Den første oppgaven er å definere et passord for MySQL:

 kubectl opprett hemmelig generisk mysql-pass - fra-bokstavelig = passord = DIN_PASSWORD

kubectl vil snakke med API-serveren, som vil validere kommandoen og deretter lagre passordet i etcd. Våre tjenester er definert i YAML-filer, og nå trenger vi noe vedvarende lagring for MySQL-databasen.

 apiVersion: v1 type: PersistentVolumeClaim metadata: navn: mysql-pv-claim etiketter: app: wordpress spec: accessModes: - ReadWriteEn gang ressurser: forespørsler: lagring: 20Gi

Spesifikasjonen skal for det meste være selvforklarende. Navn- og etikettfeltene brukes til å referere til denne lagringen fra andre deler av Kubernetes, i dette tilfellet vår WordPress-container.

Når vi har definert lagringen, kan vi definere en MySQL-forekomst og peke den til den forhåndsdefinerte lagringen. Det blir etterfulgt av å definere selve databasen. Vi gir databasen et navn og en etikett for enkel referanse i Kubernetes.

Nå trenger vi en annen container for å kjøre WordPress. En del av spesifikasjonen for containerdistribusjon er:

 type: Implementeringsmetadata: navn: wordpress etiketter: app: wordpress spec: strategi: type: Gjenopprett

Strategitypen “Gjenopprett” betyr at hvis noen av koden som inneholder applikasjonen endres, vil kjørende forekomster bli slettet og gjenskapt. Andre alternativer inkluderer å kunne sykle nye forekomster i og fjerne eksisterende forekomster, en etter en, slik at tjenesten kan fortsette å kjøre under distribusjon av en oppdatering. Til slutt erklærer vi en tjeneste for WordPress selv, som består av PHP-koden og Apache. En del av YAML-filen som erklærer dette er:

 metadata: navn: wordpress etiketter: app: wordpress spec: porter: - port: 80 velger: app: wordpress nivå: frontend type: LoadBalancer

Legg merke til den siste linjen, og definer tjenestetypen som LoadBalancer. Det instruerer Kubernetes om å gjøre tjenesten tilgjengelig utenfor Kubernetes. Uten denne linjen ville dette bare være en intern “kun Kubernetes” -tjeneste. Og det er det. Kubernetes vil nå bruke disse YAML-filene som en erklæring om hva som kreves, og vil sette opp pods, tilkoblinger, lagring og så videre etter behov for å få klyngen til "ønsket" tilstand.

Bruk oversiktsvisningen for å få en oversikt over Kubernetes i aksjon

Dette har nødvendigvis bare vært en høy oversikt over Kubernetes, og mange detaljer og funksjoner i systemet er utelatt. Vi har glanset over autoskalering (både pods og nodene som utgjør en klynge), cron-jobber (starter containere etter en tidsplan), Ingress (HTTP-belastningsbalansering, omskriving og SSL-avlasting), RBAC (rollebasert tilgangskontroll) , nettverkspolicyer (brannmur), og mye mer. Kubernetes er ekstremt fleksibel og ekstremt kraftig: for enhver ny IT-infrastruktur må den være en seriøs konkurrent.

Ressurser

Hvis du ikke er kjent med Docker, start her: https://docs.docker.com/get-started.

Det er en interaktiv veiledning om distribusjon og skalering av en app her: https://kubernetes.io/docs/tutorials/kubernetes-basics.

Og se https://kubernetes.io/docs/setup/scratch for hvordan du bygger en klynge.

Du kan spille med en gratis Kubernetes-klynge på https://tryk8s.com.

Til slutt kan du pore over et langt, teknisk papir med en utmerket oversikt over Googles bruk av Borg og hvordan det påvirket utformingen av Kubernetes her: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.

Finn ut mer om Tiger Computing.