Når du vil bruge Linux til at levere tjenester til en virksomhed, skal disse tjenester være sikre, modstandsdygtige og skalerbare. Smukke ord, men hvad mener vi med dem?
'Sikker' betyder, at brugere kan få adgang til de data, de har brug for, det være sig skrivebeskyttet adgang eller skriveadgang. Samtidig udsættes ingen data for nogen part, der ikke har tilladelse til at se dem. Sikkerhed er vildledende: du kan tro, at du kun har alt beskyttet for senere at finde ud af, at der er huller. At designe sikkerhed fra starten af et projekt er langt nemmere end at forsøge at eftermontere det senere.
'Modstandsdygtig' betyder, at dine tjenester tåler fejl inden for infrastrukturen. En fejl kan være en serverdiskcontroller, der ikke længere har adgang til nogen diske, hvilket gør dataene utilgængelige. Eller fejlen kan være en netværksafbryder, der ikke længere gør det muligt for to eller flere systemer at kommunikere. I denne sammenhæng er et “enkelt fejlpunkt” eller SPOF en fejl, der påvirker tilgængeligheden af tjenester negativt. En elastisk infrastruktur er en uden SPOF'er.
'Skalerbar' beskriver systemernes evne til at håndtere efterspørgselsspidser yndefuldt. Det dikterer også, hvor let ændringer kan foretages i systemer. For eksempel tilføje en ny bruger, øge lagerkapaciteten eller flytte en infrastruktur fra Amazon Web Services til Google Cloud - eller endda flytte den internt.
Så snart din infrastruktur udvider sig ud over en server, er der mange muligheder for at øge sikkerheden, modstandsdygtigheden og skalerbarheden. Vi ser på, hvordan disse problemer traditionelt er blevet løst, og hvilken ny teknologi der er til rådighed, der ændrer ansigten ved stor applikationscomputering.
Få mere Linux!
Nyder du det, du læser? Vil du have mere Linux og open source? Vi kan levere, bogstaveligt talt! Abonner på Linux-format i dag til en god pris. Du kan få udskriftsproblemer, digitale udgaver eller hvorfor ikke begge dele? Vi leverer til din dør over hele verden til et enkelt årligt gebyr. Så gør dit liv bedre og lettere, abonner nu!
For at forstå, hvad der er muligt i dag, er det nyttigt at se på, hvordan teknologiprojekter traditionelt er blevet implementeret. Tilbage i gamle dage - det vil sige for mere end 10 år siden - ville virksomheder købe eller lease hardware til at køre alle komponenterne i deres applikationer. Selv relativt enkle applikationer, såsom et WordPress-websted, har flere komponenter. I tilfælde af WordPress er der brug for en MySQL-database sammen med en webserver, såsom Apache, og en måde at håndtere PHP-kode på. Så de ville oprette en server, oprette Apache, PHP og MySQL, installere WordPress, og så skulle de gå.
I det store og hele fungerede det. Det fungerede godt nok, at der stadig er et stort antal servere konfigureret på præcis den måde i dag. Men det var ikke perfekt, og to af de større problemer var modstandsdygtighed og skalerbarhed.
Manglende modstandsdygtighed betød, at ethvert væsentligt problem på serveren ville resultere i tab af service. Det er klart, at en katastrofal fiasko ikke betyder noget websted, men der var heller ikke plads til at udføre planlagt vedligeholdelse uden at påvirke webstedet. Selv installation og aktivering af en rutinemæssig sikkerhedsopdatering til Apache ville kræve et par sekunders afbrydelse for hjemmesiden.
Modstandsproblemet blev stort set løst ved at opbygge 'klynger med høj tilgængelighed'. Princippet var at have to servere, der kørte hjemmesiden, konfigureret således, at fejlen hos en af dem ikke resulterede i, at hjemmesiden var nede. Den leverede tjeneste var modstandsdygtig, selvom de enkelte servere ikke var det.
Abstrakte skyerEn del af Kubernetes magt er den abstraktion, den tilbyder. Fra en udviklers perspektiv udvikler de applikationen til at køre i en Docker-container. Docker er ligeglad med, om det kører på Windows, Linux eller et andet operativsystem. Den samme Docker-container kan tages fra udviklerens MacBook og køres under Kubernetes uden nogen ændringer.
Selve Kubernetes-installationen kan være en enkelt maskine. Selvfølgelig er mange af fordelene ved Kubernetes ikke tilgængelige: der vil ikke være nogen automatisk skalering; der er et åbenlyst enkelt fejlpunkt osv. Som et bevis på konceptet i et testmiljø fungerer det dog.
Når du er klar til produktion, kan du køre internt eller hos en Cloud-udbyder som AWS eller Google Cloud. Cloud-udbyderne har nogle indbyggede tjenester, der hjælper med at køre Kubernetes, men ingen af dem er hårde krav. Hvis du vil flytte mellem Google, Amazon og din egen infrastruktur, skal du oprette Kubernetes og bevæge dig over. Ingen af dine applikationer skal ændres på nogen måde.
Og hvor er Linux? Kubernetes kører på Linux, men operativsystemet er usynligt for applikationerne. Dette er et vigtigt skridt i modenhed og anvendelighed af IT-infrastrukturer.
Slashdot-effekten
Skalerbarhedsproblemet er lidt vanskeligere. Lad os sige, at dit WordPress-sted får 1.000 besøgende om måneden. En dag nævnes din virksomhed på Radio 4 eller morgenmads-tv. Pludselig får du mere end en måneds værdi af besøgende på 20 minutter. Vi har alle hørt historier om websteder, der 'går ned', og det er typisk derfor: manglende skalerbarhed.
De to servere, der hjalp med modstandsdygtighed, kunne styre en højere arbejdsbyrde end en server alene kunne, men det er stadig begrænset. Du ville betale for to servere 100 procent af tiden, og det meste af tiden fungerede begge perfekt. Det er sandsynligt, at en alene kunne køre dit websted. Derefter nævner John Humphrys din virksomhed i dag, og du har brug for 10 servere til at håndtere belastningen - men kun i et par timer.
Den bedre løsning på både modstandsdygtighed og skalerbarhedsproblemer var cloud computing. Opret en serverforekomst eller to - de små servere, der kører dine applikationer - på Amazon Web Services (AWS) eller Google Cloud, og hvis en af forekomsterne mislykkedes af en eller anden grund, ville den automatisk genstartes. Opsæt automatisk skalering korrekt, og når hr. Humphrys får arbejdsbelastningen på dine webserverforekomster til hurtigt at stige, startes yderligere serverforekomster automatisk for at dele arbejdsbyrden. Senere, når renterne går ud, stoppes disse ekstra tilfælde, og du betaler kun for det, du bruger. Perfekt … eller er det?
Mens cloudløsningen er meget mere fleksibel end den traditionelle enkeltstående server, er der stadig problemer. Opdatering af alle kørende skyinstanser er ikke ligetil. Udvikling til skyen har også udfordringer: Den bærbare computer, som dine udviklere bruger, kan ligne skyinstansen, men det er ikke det samme. Hvis du forpligter dig til AWS, er migrering til Google Cloud en kompleks opgave. Og antag, af en eller anden grund, at du simpelthen ikke vil aflevere din computer til Amazon, Google eller Microsoft?
Beholdere er opstået som et middel til at pakke applikationer med alle deres afhængigheder op i en enkelt pakke, der kan køres hvor som helst. Containere, såsom Docker, kan køre på dine udviklers bærbare computere på samme måde som de kører på dine skyinstanser, men at administrere en flåde af containere bliver stadig mere udfordrende, efterhånden som antallet af containere vokser.
Svaret er containerorkestrering. Dette er et betydeligt skift i fokus. Før sørgede vi for, at vi havde nok servere, hvad enten de var fysiske eller virtuelle, for at sikre, at vi kunne servicere arbejdsbyrden. Brug af cloududbydernes autoskalering hjalp, men vi havde stadig at gøre med forekomster. Vi var nødt til at konfigurere load balancers, firewalls, datalagring og mere manuelt. Med containerorkestrering er alt dette (og meget mere) taget hånd om. Vi specificerer de resultater, vi har brug for, og vores containerorkestreringsværktøjer opfylder vores krav. Vi specificerer, hvad vi vil have gjort, snarere end hvordan vi vil have det gjort.
Bliv en Kubernete
Kubernetes (ku-ber-net-eez) er det førende værktøj til containerorkestrering i dag, og det kom fra Google. Hvis nogen ved, hvordan man kører enorme it-infrastrukturer, gør Google det. Oprindelsen til Kubernetes er Borg, et internt Google-projekt, der stadig bruges til at køre de fleste af Googles applikationer inklusive dens søgemaskine, Gmail, Google Maps og mere. Borg var en hemmelighed, indtil Google offentliggjorde et papir om det i 2015, men papiret gjorde det meget tydeligt, at Borg var den vigtigste inspiration bag Kubernetes.
Borg er et system, der administrerer beregningsressourcer i Googles datacentre og holder Googles applikationer, både produktion og andet, kørende på trods af hardwarefejl, ressourceudmattelse eller andre problemer, der opstår, der ellers kunne have forårsaget en afbrydelse. Det gør det ved nøje at overvåge de tusinder af noder, der udgør en Borg "celle", og containerne, der kører på dem, og starte eller stoppe containere efter behov som reaktion på problemer eller udsving i belastningen.
Kubernetes selv blev født ud af Googles GIFEE-initiativ ('Googles infrastruktur til alle andre') og blev designet til at være en mere venlig version af Borg, der kunne være nyttig uden for Google. Det blev doneret til Linux Foundation i 2015 gennem dannelsen af Cloud Native Computing Foundation (CNCF).
Kubernetes tilbyder et system, hvor du "erklærer" dine containeriserede applikationer og tjenester, og det sørger for, at dine applikationer kører i henhold til disse erklæringer. Hvis dine programmer kræver eksterne ressourcer, såsom opbevaring eller belastningsafbalancere, kan Kubernetes klargøre dem automatisk. Det kan skalere dine applikationer op eller ned for at holde trit med ændringer i belastning og kan endda skalere hele din klynge, når det er nødvendigt. Dit programs komponenter behøver ikke engang at vide, hvor de kører: Kubernetes leverer interne navngivningstjenester til applikationer, så de kan oprette forbindelse til “wp_mysql” og automatisk blive forbundet til den rigtige ressource. '
Slutresultatet er en platform, der kan bruges til at køre dine applikationer på enhver infrastruktur, fra en enkelt maskine gennem et lokalt rack af systemer til skybaserede flåder af virtuelle maskiner, der kører på enhver større skyudbyder, der alle bruger de samme containere og konfiguration. Kubernetes er provider-agnostiker: kør det, hvor du vil.
Kubernetes er et stærkt værktøj og er nødvendigvis komplekst. Før vi kommer ind i en oversigt, er vi nødt til at introducere nogle udtryk, der bruges inden for Kubernetes. Containere kører enkeltapplikationer som beskrevet ovenfor og er grupperet i bælg. En pod er en gruppe tæt forbundne containere, der er indsat sammen på den samme vært og deler nogle ressourcer. Containerne i en pod fungerer som et team: de udfører relaterede funktioner såsom en applikationscontainer og en logningscontainer med specifikke indstillinger til applikationen.
Fire vigtige Kubernetes-komponenter er API-serveren, planlæggeren, controller-manager og en distribueret konfigurationsdatabase kaldet etcd. API-serveren er kernen i Kubernetes og fungerer som det primære slutpunkt for alle ledelsesanmodninger. Disse kan genereres af en række kilder, herunder andre Kubernetes-komponenter, såsom planlæggeren, administratorer via kommandolinje eller webbaserede dashboards og selve containeriserede applikationer. Det validerer anmodninger og opdaterer data gemt i etcd.
Planlæggeren bestemmer, hvilke noder de forskellige bælg skal køre på, idet der tages hensyn til begrænsninger såsom ressourcekrav, eventuelle hardware- eller softwarebegrænsninger, arbejdsbyrde, deadlines og mere.
Controller Manager overvåger klyngens tilstand og vil forsøge at starte eller stoppe pods som nødvendigvis via API-serveren for at bringe klyngen til den ønskede tilstand. Det styrer også nogle interne forbindelser og sikkerhedsfunktioner.
Hver node kører en Kubelet-proces, der kommunikerer med API-serveren og administrerer containere - generelt ved hjælp af Docker - og Kube-Proxy, som håndterer netværksproxyering og belastningsbalancering inden i klyngen.
Det etcd distribuerede databasesystem stammer sit navn fra /etc mappe på Linux-systemer, som bruges til at indeholde systemkonfigurationsoplysninger plus suffikset 'd', der ofte bruges til at betegne en dæmonproces. Målet med etcd er at gemme nøgleværdidata på en distribueret, konsistent og fejltolerant måde.
API-serveren holder alle sine tilstandsdata i etcd og kan køre mange forekomster samtidigt. Planlægnings- og controller-manager kan kun have en aktiv forekomst, men bruger et leasesystem til at bestemme, hvilken kørende instans der er masteren. Alt dette betyder, at Kubernetes kan køre som et meget tilgængeligt system uden nogen enkelte fejlpunkter.
Samler det hele
Så hvordan bruger vi disse komponenter i praksis? Det følgende er et eksempel på opsætning af et WordPress-websted ved hjælp af Kubernetes. Hvis du ville gøre dette rigtigt, ville du sandsynligvis bruge en foruddefineret opskrift kaldet et rordiagram. De er tilgængelige til en række almindelige applikationer, men her ser vi på nogle af de trin, der er nødvendige for at få et WordPress-websted til at køre på Kubernetes.
Den første opgave er at definere en adgangskode til MySQL:
kubectl oprette hemmelig generisk mysql-pass - fra-bogstavelig = adgangskode = DIN_PASSWORD
kubectl vil tale med API-serveren, som validerer kommandoen og derefter gemmer adgangskoden i etcd. Vores tjenester er defineret i YAML-filer, og nu har vi brug for vedvarende opbevaring til MySQL-databasen.
apiVersion: v1 kind: PersistentVolumeClaim metadata: navn: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: anmodninger: storage: 20Gi
Specifikationen skal for det meste være selvforklarende. Navn og etiketfelter bruges til at henvise til denne opbevaring fra andre dele af Kubernetes, i dette tilfælde vores WordPress-container.
Når vi har defineret lageret, kan vi definere en MySQL-forekomst og pege på den foruddefinerede lagerplads. Herefter defineres selve databasen. Vi giver databasen et navn og en etiket til nem reference inden for Kubernetes.
Nu har vi brug for en anden container til at køre WordPress. En del af containerinstallationsspecifikationen er:
kind: Implementeringsmetadata: navn: wordpress labels: app: wordpress spec: strategi: type: Recreate
Strategitypen "Genskab" betyder, at hvis nogen af koden, der omfatter applikationen, ændres, vil kørende forekomster blive slettet og genskabt. Andre muligheder inkluderer at være i stand til at cykle nye forekomster i og fjerne eksisterende forekomster en efter en, hvilket gør det muligt for tjenesten at fortsætte med at køre under implementeringen af en opdatering. Endelig erklærer vi en tjeneste til WordPress selv, der omfatter PHP-koden og Apache. En del af YAML-filen, der erklærer dette, er:
metadata: navn: wordpress labels: app: wordpress spec: porte: - port: 80 vælger: app: wordpress tier: frontend type: LoadBalancer
Bemærk den sidste linje, idet du definerer servicetype som LoadBalancer. Det instruerer Kubernetes om at gøre tjenesten tilgængelig uden for Kubernetes. Uden denne linje ville dette kun være en intern “kun Kubernetes” -tjeneste. Og det er det. Kubernetes vil nu bruge disse YAML-filer som en erklæring om, hvad der kræves, og vil oprette pods, forbindelser, opbevaring og så videre efter behov for at bringe klyngen i den "ønskede" tilstand.
Dette har nødvendigvis kun været en oversigt på højt niveau af Kubernetes, og mange detaljer og funktioner i systemet er udeladt. Vi har glanset over autoskalering (både pods og de noder, der udgør en klynge), cron-job (start af containere efter en tidsplan), Ingress (HTTP-belastningsbalancering, omskrivning og SSL-offloading), RBAC (rollebaseret adgangskontrol) , netværkspolitikker (firewalling) og meget mere. Kubernetes er ekstremt fleksibel og ekstremt kraftfuld: for enhver ny IT-infrastruktur skal den være en seriøs udfordrer.
Ressourcer
Hvis du ikke er fortrolig med Docker, skal du starte her: https://docs.docker.com/get-started.
Der er en interaktiv tutorial om implementering og skalering af en app her: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Og se https://kubernetes.io/docs/setup/scratch for, hvordan man opbygger en klynge.
Du kan spille med en gratis Kubernetes-klynge på https://tryk8s.com.
Endelig kan du pore et langt, teknisk papir med et fremragende overblik over Googles brug af Borg og hvordan det påvirkede designet af Kubernetes her: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Få mere at vide om Tiger Computing.
- Bedste skyopbevaring i 2022-2023 online: gratis, betalte og forretningsmuligheder
Nyder du det, du læser? Vil du have mere Linux og open source? Vi kan levere, bogstaveligt talt! Abonner på Linux-format i dag til en god pris. Du kan få udskriftsproblemer, digitale udgaver eller hvorfor ikke begge dele? Vi leverer til din dør over hele verden til et enkelt årligt gebyr. Så gør dit liv bedre og lettere, abonner nu!