Processen att schemalägga containrar i ett containerorkestreringsramverk som Kubernetes eller Docker SWARM kan beskrivas som att helt enkelt allokera körtidsresurser till arbetsbelastningar. I en värld där det finns obegränsade (eller åtminstone tillräckliga) resurser och alla arbetsbelastningar är lika, skulle nuvarande containerschemaläggningssystem anses vara tillräckliga. Men i den verkliga världen av företagsdatorer vet vi att inte alla arbetsbelastningar är lika och de flesta organisationer har resursbegränsningar. Vidare har stora organisationer unika behov och vill sköta sina arbetsbelastningar på ett specifikt sätt, därför gör vi affärsmässiga förutsättningar för avancerad schemaläggning.
Processen att schemalägga containrar i ett containerorkestreringsramverk som Kubernetes eller Docker SWARM kan beskrivas som att helt enkelt allokera körtidsresurser till arbetsbelastningar. I en värld där det finns obegränsade (eller åtminstone tillräckliga) resurser och alla arbetsbelastningar är lika, skulle nuvarande containerschemaläggningssystem anses vara tillräckliga. Men i den verkliga världen av företagsdatorer vet vi att inte alla arbetsbelastningar är lika och de flesta organisationer har resursbegränsningar. Vidare har stora organisationer unika behov och vill sköta sina arbetsbelastningar på ett specifikt sätt, därför gör vi affärsmässiga förutsättningar för avancerad schemaläggning.
När du experimenterar med containrar eller driver ett par små pilotprojekt kan containerschemaläggning verkligen vara väldigt enkelt. Men när du väl går bortom triviala användningsfall blir schemaläggning av containrar mycket mer komplex och en extremt avgörande utmaning.
Följande avsnitt diskuterar inneboende komplexiteter mer i detalj och illustrerar behovet av kraftfull, automatiserad containerschemaläggning.
Behållarmiljöer är dynamiska, inte statiska
Även om det kan tyckas att tjänstebaserade arkitekturer är statiska och involverar långvariga tjänster som inte förändras mycket alls, är detta långt ifrån fallet. På grund av komponenternas dynamiska natur, som inkluderar replikeringskontroller och dynamisk lastbalansering, kan antalet och arten av exekverande tjänstkomponenter ändras flera gånger under en dag. Krav och randvillkor som de som anges nedan måste förväntas ändras när som helst. Detta kommer vanligtvis att kräva en förändring av arbetsbelastningen på grund av:
- Systemfel och därmed ett behov av att schemalägga en tjänst eller en del av dess komponenter
- Omfördelning, tillägg eller borttagning av resurser, t.ex. i en molnmiljö
- Efterfrågan och prioritet för arbetsbelastningar kan förändras, särskilt i förhållande till andra arbetsbelastningar, t.ex. tid på dagen efterfrågan
Programuppdateringar för en specifik tjänst eller några av dess komponenter kan också orsaka dynamiska förändringar i en miljö. Också icke-service, mer övergående arbetsbelastningar kan kräva prioritet och skapa resursbegränsningar. Arbetsbelastningar som batchjobb, interaktivt arbete, mjukvarubyggen (t.ex. triggade genom CI/CD-ramverk) eller testsvitsuppgifter, återigen härrörande från CI/CD-ramverk, kan också skapa konflikter och kan göra det nödvändigt att balansera om arbetsbelastningen.
Containerschemaläggning är mycket komplext och inte enkelt
Med containrar finns det många fler (och mycket mindre) rörliga delar än med traditionella, mer monolitiska applikationsutvecklingsmetoder. Till exempel har mikrotjänstapplikationskomponenter ömsesidigt beroende, olika behov och använder repliker av tjänstekomponenter för att uppnå skala. Det finns också fler beroenden av mjukvarudefinierade lager för nätverk och lagring. Varje incheckning av en ingenjör kan utlösa en lavin av bygg-/installations-/teststeg och automatiserad orkestrering som säkerställer att serviceberedskap och hälsa kommer att skapa eller avveckla servicekomponenter på begäran. Med DevOps inblandade finns det fler intressenter som påverkar verksamheten – varje applikationsingenjör och varje enskilt utvecklingssteg kan påverka verksamheten direkt. Konsekvent och pålitlig serviceleverans baserad på dessa rörliga pusselbitar blir en utmaning, särskilt när man skalar upp och breder ut sig med högre servicepriser och fler tjänster.
Containerschemaläggning måste hantera resursbegränsningar
En värld av cloud computing skapar en illusion av obegränsad tillgång på resurser, men dessa molnresurser är ofta begränsade. De är vanligtvis begränsade av budget eller av tillgänglighet och hästkrafter för de önskade noderna. Begränsningar kan också införas genom skalbarheten av arbetsbelastningar och avvägningar mellan kostnad och nytta kan begränsa ekonomisk avkastning över en viss tröskel. Om du behöver köra mer arbete än du har resurser att ta emot, blir schemaläggning en svår beslutsprocess av "vem springer och vem gör inte?", "vem går först, vem går härnäst?" och "vem får mer och vem får mindre?"
Ett behov av kraftfull och automatiserad schemaläggning
Det är ingen hemlighet att containrar tas i bruk i en rekordstor takt och medan de flesta organisationer fortfarande befinner sig i pilot-, dev- eller testlägen, kommer begränsningar att diktera behovet av avancerade och automatiserade schemaläggningsverktyg när driftsättningar kommer till produktion och slutligen skalas. .
- Att automatisera beslutsfattandet för att hantera alla kombinationer av utmaningar som resursbegränsningar, komplexa containeranvändningsfall eller dynamiskt föränderliga miljöer och gränsvillkor är den största utmaningen inom containerorkestrering
- Automatiserad schemaläggning kräver kraftfulla policyer och en effektiv implementering av dem
- Utan kraftfull och automatiserad schemaläggning kommer du att tvingas acceptera resursslöseri eller så måste du göra justeringar manuellt hela tiden samtidigt som du aldrig uppnår ett optimalt resultat
Så utan avancerad schemaläggning skulle du slösa tid, ansträngning och pengar. Och ju mer dynamisk din miljö blir (tänk moln) och ju mer avancerade dina användningsfall är, desto mer kommer du att slösa.
Vi introducerar Navops Command – Superpowers for Kubermetes
Ingenjörerna på Google som var involverade i skapandet av Kubernetes såg redan i början att avancerad schemaläggning skulle krävas och tog i sin Kubernetes modulära arkitektur hänsyn till möjligheten att enkelt ersätta Kubernetes schemaläggare eller använda flera schemaläggare parallellt. Univa har många års erfarenhet av schemaläggning av högpresterande datorer och tekniska datorapplikationer. Vi bygger vidare på vår beprövade expertis och har utformat Navops Command-schemaläggningskapacitet för att vara Kubernetes-medveten med ett snyggt containerorienterat webbgränssnitt såväl som API:er och ett kommandoradsgränssnitt. Systemet tillför containervärlden koncept som proportionell resursdelning, resurskvoter, åtkomstkontrollistor och resursinterleaving. Besök www.navos.io/command.html för att lära dig mer och ansöka om tidig tillgång.
Av Fritz Ferstl, CTO och affärsutveckling, EMEA, Univa
Fritz har mer än 23 år som en ledande expert inom distribuerad arbetsbelastning och resurshantering. Hans erfarenhet sträcker sig från grid computing till cloud computing, high performance computing, virtualisering och containeroptimering. Som CTO för Univa Corporation, definierar han Univas produkt- och teknikriktning för att stödja flera hundra stora företagskunder inom alla branschvertikaler och på uppdrag av deras krav på hantering av arbetsbelastning. Inom dessa kunder finns många av världens största företag inom datormiljöer.
Blir molnbaserad och undviker turbulens
Anmäl dig till StorageReviews nyhetsbrev
