Når du vil bruke Linux til å tilby tjenester til en virksomhet, må disse tjenestene være sikre, spenstige og skalerbare. Hyggelige ord, men hva mener vi med dem?
‘Sikre’ betyr at brukere kan få tilgang til dataene de trenger, være den som bare leser eller skriver tilgang. På samme tid blir ingen data utsatt for noen part som’er ikke autorisert til å se det. Sikkerhet er villedende: du kan tro at du har alt beskyttet bare for å finne ut senere at det er hull. Det er langt enklere å designe i sikkerhet fra starten av et prosjekt enn å prøve å ettermontere det senere.
‘Resilient’ betyr at tjenestene dine tåler feil innenfor infrastrukturen. En feil kan være en serverdiskkontroller som ikke lenger har tilgang til noen disker, noe som gjør dataene utilgjengelige. Eller feilen kan være en nettverksbryter som ikke lenger lar to eller flere systemer kommunisere. I denne sammenheng “enkelt feil punkt” eller SPOF er en feil som påvirker tjenestens tilgjengelighet negativt. En spenstig infrastruktur er en uten SPOF-er.
‘skalerbar’ beskriver systemenes evne til å håndtere pigg av etterspørsel grasiøst. 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 din utvides utover en server, er det mange muligheter for å øke sikkerheten, spenningen og skalerbarheten. Vi’Jeg vil se på hvordan disse problemene har blitt løst tradisjonelt, og hvilken ny teknologi som er tilgjengelig som endrer ansiktet til store applikasjonsberegninger.
For å forstå hva’er mulig i dag, det’Det er nyttig å se på hvordan teknologiprosjekter tradisjonelt har blitt implementert. Tilbake i gamle dager – det vil si for mer enn 10 år siden – ville virksomheter kjøpe eller lease maskinvare for å kjøre alle komponentene i applikasjonene sine. Selv relativt enkle applikasjoner, for eksempel et WordPress-nettsted, har flere komponenter. Når det gjelder WordPress, er det nødvendig med en MySQL-database sammen med en webserver, for eksempel Apache, og en måte å håndtere PHP-kode på. Så de’d bygge en server, sette opp Apache, PHP og MySQL, installere WordPress og slå dem av’d gå.
I det store og hele fungerte det. Det fungerte bra nok til at det fremdeles er et enormt antall servere som er konfigurert på akkurat den måten i dag. Men det var ikke’t perfekt, og to av de større problemene var spenst og skalerbarhet.
Mangel på spenst innebar at ethvert betydelig problem på serveren ville resultere i tap av tjenesten. Det er klart at en katastrofal svikt ville bety ingen 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 ville nødvendiggjøre noen sekunder’ strømbrudd for nettstedet.
Resiliensproblemet ble stort sett løst ved å bygge ‘klynger med høy tilgjengelighet’. Prinsippet var å ha to servere som kjører nettstedet, konfigurert slik at feilen på en av dem ikke gjorde det’t resulterer i at nettstedet er nede. Tjenesten som ble gitt var spenstig selv om de enkelte serverne ikke var det.
Abstrakte skyer
En del av kraften til Kubernetes er abstraksjonen den tilbyr. Fra en utvikler’I perspektiv utvikler de applikasjonen for å kjøre i en Docker-container. Docker gjør det ikke’t bryr seg om det’kjører på Windows, Linux eller et annet operativsystem. Den samme Docker-containeren kan tas fra utvikleren’s MacBook og kjør under Kubernetes uten endringer.
Selve Kubernetes-installasjonen kan være en enkelt maskin. Selvfølgelig vant mange av fordelene med Kubernetes’t være tilgjengelig: det blir ingen automatisk skalering; der’er et åpenbart eneste feil punkt, og så videre. Men som et bevis på konsept i et testmiljø, fungerer det.
Med en gang du’Når du er klar for produksjon, kan du kjøre internt eller hos en Cloud-leverandør som AWS eller Google Cloud. Cloud-leverandørene har noen innebygde tjenester som hjelper deg med å kjøre Kubernetes, men ingen av disse er harde krav. Hvis du vil flytte mellom Google, Amazon og din egen infrastruktur, setter du opp Kubernetes og går over. Ingen av applikasjonene 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 av IT-infrastrukturer.
Slashdot-effekten
Skalerbarhetsproblemet er litt vanskeligere. La’sier at WordPress-nettstedet ditt 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åned’besøkende verdt besøkende på 20 minutter. Vi’har alle hørt historier om nettsteder ‘krasj’, og det’s vanligvis hvorfor: mangel på skalerbarhet.
De to serverne som hjalp mot spenst, kunne styre en høyere arbeidsmengde enn en server alene kunne, men det’er fortsatt begrenset. Du’d betale for to servere 100 prosent av tiden, og mesteparten av tiden arbeidet begge to perfekt. Den’Det er sannsynlig at en alene kan drive nettstedet ditt. Da nevner John Humphrys virksomheten din i dag og deg’d trenger 10 servere for å håndtere belastningen – men bare i noen timer.
Den bedre løsningen på både resiliens- 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 ett av forekomstene mislyktes av en eller annen grunn, vil det automatisk bli startet på nytt. Sett opp automatisk skalering riktig, og når Mr Humphrys får arbeidsmengden på webserverforekomstene til å øke raskt, starter flere serverforekomster automatisk for å dele arbeidsmengden. Senere, etter hvert som renter dør, stoppes de ekstra tilfellene, og du betaler bare for det du bruker. Perfekt… eller er det?
Skyløsningen er mye mer fleksibel enn den tradisjonelle frittstående serveren, men det er fortsatt problemer. Oppdatering av alle skyforekomster som kjører, er ikke’t rett frem. Å utvikle for skyen har utfordringer også: den bærbare datamaskinen utviklerne dine bruker kan være lik skyforekomsten, men det’er ikke det samme. Hvis du forplikter deg til AWS, er migrering til Google Cloud et sammensatt tilsagn. Og antar at du, uansett grunn, bare ikke har det’t vil overlevere datamaskinen din til Amazon, Google eller Microsoft?
Beholdere har vist seg å være 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øre på utviklerne dine’ bærbare datamaskiner på samme måte som de kjører på skyforekomstene dine, men å administrere en flåte med containere blir stadig mer utfordrende etter hvert som antallet containere vokser.
Svaret er containerorkestrasjon. Dette er et betydelig fokusskifte. 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 skyleverandørene’ autoskalering hjalp, men vi hadde fremdeles å gjøre med forekomster. Vi måtte konfigurere lastbalansere, brannmurer, datalagring og mer manuelt. Med container-orkestrering blir alt det (og mye mer) ivaretatt. Vi spesifiserer resultatene vi trenger, og verktøyene for containerorkestring oppfyller kravene våre. Vi spesifiserer hva vi vil ha gjort, i stedet for hvordan vi vil ha det.
Kontinuerlig integrasjon og kontinuerlig distribusjon kan fungere godt med Kubernetes. Her’er en oversikt over Jenkins som brukes til å bygge og distribuere en Java-applikasjon
(Bildekreditt: Framtid)
Bli en Kubernete
Kubernetes (ku-ber-net-eez) er det ledende containerorkestreringsverktøyet i dag, og det kom fra Google. Hvis noen vet hvordan de skal drive IT-infrastruktur i stor skala, gjør Google det. Opprinnelsen til Kubernetes er Borg, et internt Google-prosjekt som’brukes fremdeles til å drive det meste av Google’applikasjoner inkludert søkemotoren, Gmail, Google Maps og mer. Borg var en hemmelighet til Google publiserte et papir om det i 2015, men avisen gjorde det veldig tydelig at Borg var den viktigste inspirasjonen bak Kubernetes.
Borg er et system som administrerer beregningsressurser i Google’s datasentre og holder Google’s applikasjoner, både produksjon og ellers, kjører til tross for maskinvarefeil, ressursutmattelse eller andre problemer som kan oppstå som ellers kan ha forårsaket et strømbrudd. Det gjør dette ved å nøye overvåke de tusenvis av noder som utgjør en Borg “celle” og containerne som kjører på dem, og starter eller stoppe containere etter behov som svar på problemer eller svingninger i belastningen.
Kubernetes ble selv født av Google’s GIFEE (‘Google’s Infrastruktur for alle andre’) initiativ, og ble designet til å være en vennligere versjon av Borg som kan være nyttig utenfor Google. Det ble gitt til Linux Foundation i 2015 gjennom dannelsen av Cloud Native Computing Foundation (CNCF).
Kubernetes tilbyr et system der du “erklære” dine containerte applikasjoner og tjenester, og det sørger for at applikasjonene dine kjører i henhold til deklarasjonene. Hvis programmene dine krever eksterne ressurser, for eksempel lagrings- eller lastbalanserer, kan Kubernetes skaffe dem automatisk. Den kan skalere applikasjonene opp eller ned for å følge med på endringer i belastningen, og kan til og med skalere hele klyngen når det er nødvendig. Programmet ditt’s komponenter don’trenger ikke engang å vite hvor de er’kjører på nytt: Kubernetes leverer interne navnetjenester til applikasjoner slik at de kan koble seg til “wp_mysql” og kobles automatisk 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 stedstativ med systemer til skybaserte flåter av virtuelle maskiner som kjører på en hvilken som helst større skyleverandør, og alle bruker samme containere og konfigurasjon. Kubernetes er leverandør-agnostiker: kjør den hvor du vil.
Kubernetes er et kraftig verktøy, og er nødvendigvis sammensatt. Før vi kommer inn på en oversikt, må vi introdusere noen begrep som brukes i Kubernetes. Beholdere kjører enkeltapplikasjoner, som diskutert over, og er gruppert i pods. En pod er en gruppe tett knyttet containere som er distribuert sammen på samme vert og deler noen ressurser. Beholderne 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 masteren som kjører nøkkelkomponentene og to noder. Legg merke til at masterkomponentene i praksis kan deles over flere systemer
(Bildekreditt: Framtid)
Fire viktige Kubernetes-komponenter er API-serveren, planleggeren, kontrolleren og en distribuert konfigurasjonsdatabase som heter etcd. API-serveren er kjernen i Kubernetes, og fungerer som det primære endepunktet for alle ledelsesforespørsler. Disse kan genereres av en rekke kilder, inkludert andre Kubernetes-komponenter, for eksempel planleggeren, administratorer via kommandolinjen eller nettbaserte dashboards, og containere-applikasjoner selv. Den validerer forespørsler og oppdaterer data som er lagret i etcd.
Planleggeren bestemmer hvilke noder de forskjellige podene skal kjøres, og tar hensyn til begrensninger som ressursbehov, eventuelle maskinvare- eller programvarebegrensninger, arbeidsmengde, frister og mer.
Controller Manager overvåker tilstanden til klyngen, 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 forbindelser 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 nettverksproxy og belastningsbalansering i klyngen.
Det distribuerte databasesystemet osv. Henter navnet fra /etc mappe på Linux-systemer, som brukes til å lagre systemkonfigurasjonsinformasjon, pluss suffikset ‘d’, ofte brukt til å betegne en daemon-prosess. Målene med etcd er å lagre data om nøkkelverdier 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 kontrollansvarlig kan bare ha en aktiv forekomst, men bruker et leasesystem for å bestemme hvilken kjørende forekomst som er masteren. Alt dette betyr at Kubernetes kan kjøres som et høyt tilgjengelig system uten noen eneste feilpunkter.
Sette alt sammen
Så hvordan bruker vi disse komponentene i praksis? Det følgende er et eksempel på å sette opp et WordPress-nettsted ved hjelp av Kubernetes. Hvis du ville gjøre dette på ordentlig, så du’d bruker sannsynligvis en forhåndsdefinert oppskrift kalt roretabell. De er tilgjengelige for en rekke vanlige applikasjoner, men her vi’Jeg vil se 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 opprette hemmelige generiske mysql-pass – fra-literal = passord = YOUR_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 litt vedvarende lagring for MySQL-databasen.
apiVersion: v1kind: PersistentVolumeClaimmetadata: name: mysql-pv-claimlabels: app: wordpressspec: accessModes: – ReadWriteOnceresources: 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 WordPress-beholderen vår.
En gang vi’Når vi har definert lagring, kan vi definere en MySQL-forekomst og peke den til den forhåndsdefinerte lagringen. At’s etterfulgt av å definere selve databasen. Vi gir den databasen et navn og etikett for enkel referanse i Kubernetes.
Nå trenger vi en annen container for å kjøre WordPress. En del av spesifikasjonen for containerdistribusjon er:
type: Deploymentmetadata: name: wordpresslabels: app: wordpressspec: strategy: type: Recreate
Strategitypen “Gjen” betyr at hvis noen av kodene som inneholder applikasjonen, endres, vil løpende forekomster bli slettet og gjenskapt. Andre alternativer inkluderer å kunne sykle nye forekomster i og fjerne eksisterende forekomster, én etter én, slik at tjenesten kan fortsette å kjøre under distribusjon av en oppdatering. Til slutt erklærer vi en tjeneste for WordPress selv, som inkluderer PHP-koden og Apache. En del av YAML-filen som erklærer dette er:
metadata: navn: wordpresslabels: app: wordpressspec: porter: – port: 80selector: app: wordpresstier: frontendtype: LoadBalancer
Legg merke til den siste linjen, definere tjenestetype som LoadBalancer. Dette pålegger Kubernetes å gjøre tjenesten tilgjengelig utenfor Kubernetes. Uten den linjen ville dette bare være et internt “Kubernetes bare” service. Og det’s 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 inn i “ønskede” stat.
Bruk oversikten til oversikten for å få et oversikt over Kubernetes i aksjon
(Bildekreditt: Ditching)
Dette har nødvendigvis bare vært en oversikt på høyt nivå av Kubernetes, og mange detaljer og funksjoner i systemet er utelatt. Vi’har glanset over autoscaling (både pods og nodene som utgjør en klynge), cron-jobber (start containere i henhold til en plan), Ingress (HTTP belastningsbalansering, omskriving og SSL offloading), RBAC (rollebaserte tilgangskontroller), nettverk policyer (brannmur), og mye mer. Kubernetes er ekstremt fleksibel og ekstremt kraftig: for all ny IT-infrastruktur må det være en alvorlig utfordrer.
ressurser
Hvis du’er ikke kjent med Docker start her: https://docs.docker.com/get-started.
Der’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.
Endelig kan du pore over en lang, teknisk artikkel med en utmerket oversikt over Google’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.
- Beste skylagring av 2019 på nettet: gratis, betalte og forretningsmessige alternativer
