Kubernetes - tämja molnet

När du vill använda Linux för att tillhandahålla tjänster till ett företag måste dessa tjänster vara säkra, elastiska och skalbara. Fina ord, men vad menar vi med dem?

”Säker” betyder att användare kan få åtkomst till den information de behöver, vara skrivskyddad eller skrivåtkomst. Samtidigt exponeras ingen data för någon part som inte har behörighet att se den. Säkerhet är vilseledande: du kan tro att du har allt skyddat bara för att senare få reda på att det finns hål. Att designa säkerhet i början av ett projekt är mycket enklare än att försöka eftermontera det senare.

”Resilient” betyder att dina tjänster tolererar fel inom infrastrukturen. Ett fel kan vara en serverdiskstyrenhet som inte längre kan komma åt några diskar, vilket gör att data inte kan nås. Eller felet kan vara en nätverksswitch som inte längre gör det möjligt för två eller flera system att kommunicera. I detta sammanhang är en ”enstaka felpunkt” eller SPOF ett fel som påverkar tjänsternas tillgänglighet negativt. En motståndskraftig infrastruktur är en utan SPOF.

'Skalbar' beskriver systemens förmåga att hantera efterfrågan toppar graciöst. Det dikterar också hur lätt ändringar kan göras i systemen. Till exempel lägga till en ny användare, öka lagringskapaciteten eller flytta en infrastruktur från Amazon Web Services till Google Cloud - eller till och med flytta den internt.

Så snart din infrastruktur expanderar bortom en server finns det många alternativ för att öka säkerheten, motståndskraften och skalbarheten. Vi kommer att titta på hur dessa problem traditionellt har lösts och vilken ny teknik som finns tillgänglig som förändrar ansiktet på stora applikationsdatorer.

Få mer Linux!

Tycker du om vad du läser? Vill du ha mer Linux och öppen källkod? Vi kan leverera, bokstavligen! Prenumerera på Linux-format idag till ett förmånligt pris. Du kan få utskriftsproblem, digitala utgåvor eller varför inte båda? Vi levererar till din dörr över hela världen mot en enkel årlig avgift. Så gör ditt liv bättre och enklare, prenumerera nu!

För att förstå vad som är möjligt idag är det bra att titta på hur tekniska projekt traditionellt har implementerats. Förr i tiden - det vill säga för mer än tio år sedan - skulle företag köpa eller hyra ut hårdvara för att köra alla komponenter i deras applikationer. Även relativt enkla applikationer, till exempel en WordPress-webbplats, har flera komponenter. När det gäller WordPress behövs en MySQL-databas tillsammans med en webbserver, som Apache, och ett sätt att hantera PHP-kod. Så de skulle bygga en server, ställa in Apache, PHP och MySQL, installera WordPress och så skulle de gå.

I stort sett fungerade det. Det fungerade tillräckligt bra för att det fortfarande finns ett stort antal servrar konfigurerade på exakt så sätt idag. Men det var inte perfekt, och två av de större problemen var motståndskraft och skalbarhet.

Brist på motståndskraft innebar att alla betydande problem på servern skulle leda till förlust av tjänst. Uppenbarligen skulle ett katastrofalt misslyckande innebära ingen webbplats, men det fanns inget utrymme för att utföra schemalagt underhåll utan att påverka webbplatsen. Även installation och aktivering av en rutinmässig säkerhetsuppdatering för Apache skulle kräva några sekunders avbrott för webbplatsen.

Motståndskraftsproblemet löstes till stor del genom att bygga ”hög tillgänglighetskluster”. Principen var att ha två servrar som kör webbplatsen, konfigurerade så att enderas fel inte resulterade i att webbplatsen var nere. Tjänsten som tillhandahölls var elastisk även om de enskilda servrarna inte var det.

Abstrakt moln

En del av Kubernetes kraft är den abstraktion som den erbjuder. Ur utvecklarens perspektiv utvecklar de applikationen för att köras i en Docker-container. Docker bryr sig inte om det körs på Windows, Linux eller något annat operativsystem. Samma Docker-behållare kan tas från utvecklarens MacBook och köras under Kubernetes utan några ändringar.

Själva Kubernetes-installationen kan vara en enda maskin. Självklart kommer många av fördelarna med Kubernetes inte att finnas: det kommer inte att ske någon automatisk skalning; det finns en uppenbar enda punkt av misslyckande, och så vidare. Som ett bevis på konceptet i en testmiljö fungerar det dock.

När du är redo för produktion kan du köra internt eller hos en molnleverantör som AWS eller Google Cloud. Molnleverantörerna har några inbyggda tjänster som hjälper till att köra Kubernetes, men inget av det är hårda krav. Om du vill flytta mellan Google, Amazon och din egen infrastruktur ställer du in Kubernetes och flyttar över. Ingen av dina ansökningar behöver ändras på något sätt.

Och var är Linux? Kubernetes körs på Linux, men operativsystemet är osynligt för applikationerna. Detta är ett viktigt steg i mognad och användbarhet av IT-infrastrukturer.

Slashdot-effekten

Skalbarhetsproblemet är lite svårare. Låt oss säga att din WordPress-webbplats får 1 000 besökare per månad. En dag nämns ditt företag på Radio 4 eller frukost-TV. Plötsligt får du mer än en månads besökare på 20 minuter. Vi har alla hört historier om webbplatser som "kraschar", och det är vanligtvis därför: brist på skalbarhet.

De två servrarna som hjälpte till med motståndskraft kunde hantera en högre arbetsbelastning än en server ensam kunde, men det är fortfarande begränsat. Du skulle betala för två servrar 100 procent av tiden och för det mesta fungerade båda perfekt. Det är troligt att en ensam kan driva din webbplats. Sedan nämner John Humphrys ditt företag på Today och du skulle behöva 10 servrar för att hantera belastningen - men bara i några timmar.

Den bättre lösningen på både motståndskraft och skalbarhetsproblem var molnbearbetning. Ställ in en serverinstans eller två - de små servrarna som kör dina applikationer - på Amazon Web Services (AWS) eller Google Cloud, och om någon av instanserna av någon anledning misslyckades skulle den automatiskt startas om. Ställ in automatisk skalning korrekt och när Mr Humphrys gör att arbetsbelastningen på dina webbserverinstanser snabbt ökar startas ytterligare serverinstanser automatiskt för att dela arbetsbelastningen. Senare, när räntan avtar, stoppas dessa ytterligare fall och du betalar bara för det du använder. Perfekt … eller är det?

Medan molnlösningen är mycket mer flexibel än den traditionella fristående servern finns det fortfarande problem. Det är inte enkelt att uppdatera alla löpande molninstanser. Att utveckla för molnet har också utmaningar: den bärbara datorn som dina utvecklare använder kan likna molninstansen, men det är inte detsamma. Om du förbinder dig till AWS är migrering till Google Cloud ett komplext åtagande. Och antar att du av någon anledning inte vill överlämna din dator till Amazon, Google eller Microsoft?

Behållare har dykt upp som ett sätt att linda applikationer med alla sina beroenden i ett enda paket som kan köras var som helst. Behållare, som Docker, kan köras på utvecklarens bärbara datorer på samma sätt som de körs i dina molninstanser, men att hantera en behållarflotta blir alltmer utmanande när antalet containrar växer.

Svaret är containerorkestrering. Detta är en betydande fokusförskjutning. Tidigare såg vi till att vi hade tillräckligt med servrar, vare sig de var fysiska eller virtuella, för att säkerställa att vi kunde betjäna arbetsbelastningen. Att använda molnleverantörernas autoskalning hjälpte till, men vi hade fortfarande att göra med instanser. Vi var tvungna att konfigurera lastbalanserare, brandväggar, datalagring och mer manuellt. Med behållarorkestrering tas allt detta (och mycket mer) om hand. Vi specificerar de resultat vi behöver och våra verktyg för orkestrering av containrar uppfyller våra krav. Vi anger vad vi vill göra, snarare än hur vi vill att det ska göras.

Kontinuerlig integration och kontinuerlig distribution kan fungera bra med Kubernetes. Här är en översikt över Jenkins som används för att bygga och distribuera en Java-applikation

Bli en Kubernete

Kubernetes (ku-ber-net-eez) är det ledande containerorkesteringsverktyget idag och det kom från Google. Om någon vet hur man driver enorma IT-infrastrukturer gör Google det. Ursprunget till Kubernetes är Borg, ett internt Google-projekt som fortfarande används för att köra de flesta av Googles applikationer inklusive sökmotorn, Gmail, Google Maps och mer. Borg var en hemlighet tills Google publicerade en artikel om den 2015, men tidningen gjorde det mycket uppenbart att Borg var den viktigaste inspirationskällan bakom Kubernetes.

Borg är ett system som hanterar beräkningsresurser i Googles datacenter och håller Googles applikationer, både produktion och på annat sätt, igång trots hårdvarufel, resursutmattning eller andra problem som annars kan ha orsakat avbrott. Det gör det genom att noggrant övervaka tusentals noder som utgör en Borg-cell och behållarna som körs på dem och starta eller stoppa behållare efter behov som svar på problem eller svängningar i belastningen.

Kubernetes själv föddes ur Googles initiativ GIFEE ('Googles infrastruktur för alla andra') och utformades för att vara en vänligare version av Borg som kan vara användbar utanför Google. Det donerades till Linux Foundation 2015 genom bildandet av Cloud Native Computing Foundation (CNCF).

Kubernetes tillhandahåller ett system där du "deklarerar" dina containeriserade applikationer och tjänster, och det ser till att dina applikationer körs enligt dessa deklarationer. Om dina program kräver externa resurser, till exempel lagring eller belastningsbalansering, kan Kubernetes tillhandahålla dem automatiskt. Det kan skala dina applikationer upp eller ner för att hålla jämna steg med belastningsförändringar och kan till och med skala hela ditt kluster när det behövs. Ditt programs komponenter behöver inte ens veta var de kör: Kubernetes tillhandahåller interna namntjänster till applikationer så att de kan ansluta till “wp_mysql” och automatiskt anslutas till rätt resurs. ”

Slutresultatet är en plattform som kan användas för att köra dina applikationer på vilken infrastruktur som helst, från en enda maskin via ett lokalt systemsystem till molnbaserade flottor av virtuella maskiner som körs på alla större molnleverantörer, alla med samma behållare och konfiguration. Kubernetes är leverantör-agnostiker: kör det vart du vill.

Kubernetes är ett kraftfullt verktyg och är nödvändigtvis komplext. Innan vi går in i en översikt måste vi introducera några termer som används inom Kubernetes. Behållare kör enskilda applikationer, som diskuterats ovan, och är grupperade i kapslar. En pod är en grupp nära länkade containrar som distribueras tillsammans på samma värd och delar vissa resurser. Behållarna i en pod fungerar som ett team: de utför relaterade funktioner, till exempel en applikationsbehållare och en loggningsbehållare med specifika inställningar för applikationen.

En översikt över Kubernetes som visar mastern som kör nyckelkomponenterna och två noder. Observera att huvudkomponenterna i praktiken kan delas över flera system

Fyra viktiga Kubernetes-komponenter är API-servern, Scheduler, Controller Manager och en distribuerad konfigurationsdatabas som heter etcd. API-servern ligger i hjärtat av Kubernetes och fungerar som den primära slutpunkten för alla hanteringsförfrågningar. Dessa kan genereras av en mängd olika källor inklusive andra Kubernetes-komponenter, såsom schemaläggaren, administratörer via kommandoraden eller webbaserade instrumentpaneler och själva containerapplikationer. Det validerar förfrågningar och uppdaterar data lagrade i etcd.

Schemaläggaren avgör vilka noder de olika skivorna ska köras med hänsyn till begränsningar som resurskrav, hårdvaru- eller mjukvarubegränsningar, arbetsbelastning, deadlines och mer.

Controller Manager övervakar klustret och försöker starta eller stoppa pods som nödvändigtvis via API-servern för att få klustret till önskat tillstånd. Det hanterar också några interna anslutningar och säkerhetsfunktioner.

Varje nod kör en Kubelet-process, som kommunicerar med API-servern och hanterar behållare - vanligtvis med Docker - och Kube-Proxy, som hanterar nätverksproxyering och belastningsbalansering inom klustret.

Det etcd distribuerade databassystemet hämtar sitt namn från /etc mapp på Linux-system, som används för att hålla systemkonfigurationsinformation, plus suffixet 'd', som ofta används för att beteckna en demonprocess. Målet med etcd är att lagra nyckel-värdedata på ett distribuerat, konsekvent och feltolerant sätt.

API-servern behåller all sin tillståndsinformation i etcd och kan köra många instanser samtidigt. Schemaläggaren och controllerhanteraren kan bara ha en aktiv instans men använder ett leasessystem för att bestämma vilken löpande instans som är master. Allt detta innebär att Kubernetes kan köras som ett mycket tillgängligt system utan enstaka felpunkter.

Sätta ihop allting

Så hur använder vi dessa komponenter i praktiken? Vad som följer är ett exempel på att skapa en WordPress-webbplats med Kubernetes. Om du ville göra detta på riktigt skulle du förmodligen använda ett fördefinierat recept som kallas ett roderdiagram. De är tillgängliga för ett antal vanliga applikationer, men här tittar vi på några av de steg som krävs för att få en WordPress-webbplats igång på Kubernetes.

Den första uppgiften är att definiera ett lösenord för MySQL:

 kubectl skapa hemligt generiskt mysql-pass - från-literal = lösenord = DITT_PASSWORD

kubectl kommer att prata med API-servern, som kommer att validera kommandot och sedan lagra lösenordet i etcd. Våra tjänster definieras i YAML-filer, och nu behöver vi lite ihållande lagring för MySQL-databasen.

 apiVersion: v1 typ: PersistentVolumeClaim metadata: namn: mysql-pv-claim etiketter: app: wordpress spec: accessModes: - ReadWriteEn gång resurser: begäranden: lagring: 20Gi

Specifikationen bör vara mest självförklarande. Fältens namn och etiketter används för att referera till denna lagring från andra delar av Kubernetes, i detta fall vår WordPress-behållare.

När vi väl har definierat lagringen kan vi definiera en MySQL-instans och peka på den fördefinierade lagringen. Därefter definieras själva databasen. Vi ger databasen ett namn och en etikett för enkel referens inom Kubernetes.

Nu behöver vi en annan behållare för att köra WordPress. En del av specifikationen för containerdistribution är:

 typ: Implementeringsmetadata: namn: wordpress etiketter: app: wordpress spec: strategi: typ: Återskapa

Strategitypen "Återskapa" betyder att om någon av koden som innehåller applikationen ändras, kommer körande instanser att raderas och återskapas. Andra alternativ inkluderar att kunna cykla nya instanser i och ta bort befintliga instanser, en efter en, så att tjänsten kan fortsätta att köras under distributionen av en uppdatering. Slutligen förklarar vi en tjänst för WordPress själv, som består av PHP-koden och Apache. En del av YAML-filen som förklarar detta är:

 metadata: namn: wordpress etiketter: app: wordpress spec: portar: - port: 80 väljare: app: wordpress nivå: frontend typ: LoadBalancer

Notera den sista raden, definiera tjänsttyp som LoadBalancer. Det instruerar Kubernetes att göra tjänsten tillgänglig utanför Kubernetes. Utan den linjen skulle detta bara vara en intern tjänst "endast Kubernetes". Och det är allt. Kubernetes kommer nu att använda dessa YAML-filer som en deklaration av vad som krävs, och kommer att ställa in pods, anslutningar, lagring och så vidare efter behov för att få klustret i "önskat" tillstånd.

Använd översiktsvyn för att få en överblick över Kubernetes i aktion

Detta har nödvändigtvis bara varit en översikt på hög nivå av Kubernetes, och många detaljer och funktioner i systemet har utelämnats. Vi har glansat över autoskalning (både pods och noder som utgör ett kluster), cron-jobb (starta behållare enligt schema), Ingress (HTTP-belastningsbalansering, omskrivning och SSL-avlastning), RBAC (rollbaserad åtkomstkontroll) , nätverkspolicyer (brandvägg) och mycket mer. Kubernetes är extremt flexibelt och extremt kraftfullt: för varje ny IT-infrastruktur måste det vara en seriös utmanare.

Resurser

Om du inte känner till Docker, börja här: https://docs.docker.com/get-started.

Det finns en interaktiv handledning om hur du distribuerar och skalar en app här: https://kubernetes.io/docs/tutorials/kubernetes-basics.

Och se https://kubernetes.io/docs/setup/scratch för hur man bygger ett kluster.

Du kan spela med ett gratis Kubernetes-kluster på https://tryk8s.com.

Slutligen kan du pore över ett långt, tekniskt papper med en utmärkt översikt över Googles användning av Borg och hur det påverkade designen av Kubernetes här: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.

Ta reda på mer om Tiger Computing.