{"id":80076,"date":"2020-05-03T01:42:34","date_gmt":"2020-05-02T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt"},"modified":"2020-05-03T01:42:34","modified_gmt":"2020-05-02T23:42:34","slug":"proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","title":{"rendered":"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Bem. overs.<\/b>: dette materiale fra det uddannelsesprojekt <noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/\">learnk8s<\/a><\/noindex> \u2014 svar p\u00e5 et popul\u00e6rt sp\u00f8rgsm\u00e5l ved design af infrastruktur baseret p\u00e5 Kubernetes. Vi h\u00e5ber, at de tilstr\u00e6kkeligt udf\u00f8rlige beskrivelser af fordele og ulemper ved hver l\u00f8sning vil hj\u00e6lpe med at tr\u00e6ffe det optimale valg for dit projekt.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/d3cc3b7e686e39032b1f02f3e8b6c46c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>TL;DR<\/b>: det samme s\u00e6t arbejdsbyrder kan k\u00f8res p\u00e5 flere store klynger (hver klynge vil have et stort antal arbejdsbyrder) eller p\u00e5 mange sm\u00e5 (med et lavt antal arbejdsbyrder i hver klynge).<\/p>\n<p>Nedenfor er en tabel, der vurderer fordele og ulemper ved hver tilgang:<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/ab5b5fefc97c3befddbaeb0791f8a90d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00e5r Kubernetes bruges som platform til drift af applikationer, opst\u00e5r der ofte flere grundl\u00e6ggende sp\u00f8rgsm\u00e5l om nuancerne ved konfiguration af klynger:<\/p>\n<ul>\n<li> <i>Hvor mange klynger skal der bruges?<\/i><\/li>\n<li> <i>Hvor store skal de v\u00e6re?<\/i><\/li>\n<li> <i>Hvad skal hver klynge inkludere?<\/i><\/li>\n<\/ul>\n<p>\nI denne artikel vil jeg fors\u00f8ge at besvare alle disse sp\u00f8rgsm\u00e5l ved at analysere fordele og ulemper ved hver tilgang.<\/p>\n<h2>Problemstillingen<\/h2>\n<p>\nSom softwareudvikler udvikler du sandsynligvis samtidig mange applikationer.<\/p>\n<p>Desuden bliver mange forekomster af disse applikationer sandsynligvis k\u00f8rt i forskellige milj\u00f8er \u2014 for eksempel kan det v\u00e6re <i>dev<\/i>, <i>test<\/i> og <i>prod<\/i>.<\/p>\n<p>Som resultat f\u00e5r man en hel matrix af applikationer og milj\u00f8er:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/f2a811fa82e1e433463ba25d29f837e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Applikationer og milj\u00f8er<\/i><\/p>\n<p>I det ovenst\u00e5ende eksempel vises 3 applikationer og 3 milj\u00f8er, hvilket giver i alt 9 mulige kombinationer.<\/p>\n<p>Hver applikationsinstans udg\u00f8r en selvst\u00e6ndig deploymentsenhed, som kan arbejdes med uafh\u00e6ngigt af de andre.<\/p>\n<p><i>Bem\u00e6rk venligst, at <b>applikationsinstans<\/b> kan best\u00e5 af mange <b>komponenter<\/b>, s\u00e5som front-end, back-end, database osv. I tilf\u00e6lde af en mikrotjenesteapplikation vil instansen inkludere alle mikrotjenester.<\/i><\/p>\n<p>Som et resultat har brugere af Kubernetes flere sp\u00f8rgsm\u00e5l:<\/p>\n<ul>\n<li> Burde alle applikationsinstanser placeres i \u00e9n klynge?<\/li>\n<li> B\u00f8r der oprettes en separat klynge for hver applikationsinstans?<\/li>\n<li> Eller m\u00e5ske skulle man bruge en kombination af de ovenn\u00e6vnte tilgange?<\/li>\n<\/ul>\n<p>\nAlle disse muligheder er helt levedygtige, da Kubernetes er et fleksibelt system, der ikke begr\u00e6nser brugeren i sine muligheder.<\/p>\n<p>Her er nogle af de mulige veje:<\/p>\n<ul>\n<li> en stor f\u00e6lles klynge;<\/li>\n<li> en masse af sm\u00e5 specialiserede klynger;<\/li>\n<li> \u00e9n klynge pr. applikation;<\/li>\n<li> \u00e9n klynge pr. milj\u00f8.<\/li>\n<\/ul>\n<p>\nSom vist nedenfor befinder de f\u00f8rste to tilgange sig i hver ende af skalaen:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/99b8fd0d1e4173705e7996cf8ccb6eec.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fra et par store klynger (til venstre) til mange sm\u00e5 (til h\u00f8jre)<\/i><\/p>\n<p><i>Generelt betragtes en klynge som \u00abst\u00f8rre\u00bb end en anden, hvis den har et st\u00f8rre samlet antal noder og pods. For eksempel er en klynge med 10 noder og 100 pods st\u00f8rre end en klynge med 1 node og 10 pods.<\/i><\/p>\n<p>Godt, lad os komme i gang!<\/p>\n<h2>1. \u00c9n stor f\u00e6lles klynge<\/h2>\n<p>\nDen f\u00f8rste mulighed er at placere alle arbejdsbyrder i \u00e9n klynge:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/283fc3c3f5ccb40a157ccff600628114.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u00c9n stor klynge<\/i><\/p>\n<p>I denne tilgang anvendes klyngen som en generel <b>infrastrukturplatform<\/b> \u2014 alt, hvad du beh\u00f8ver, implementerer du bare i den eksisterende Kubernetes-klynge.<\/p>\n<p><i><noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/overview\/working-with-objects\/namespaces\/\">Namespaces<\/a><\/noindex> Kubernetes g\u00f8r det muligt at adskille dele af klyngen logisk fra hinanden, s\u00e5 hver applikationsinstans kan bruge sit eget namespace.<\/i><\/p>\n<p><i>Lad os se p\u00e5 fordele og ulemper ved denne tilgang.<\/i><\/p>\n<h3>+ Effektiv ressourceudnyttelse<\/h3>\n<p>\nI tilf\u00e6lde af \u00e9n enkelt klynge kr\u00e6ves der kun \u00e9n kopi af alle de ressourcer, der er n\u00f8dvendige for at k\u00f8re og administrere Kubernetes-klyngen.<\/p>\n<p>For eksempel g\u00e6lder dette for master-noder. Normalt er der 3 master-noder per Kubernetes-klynge, s\u00e5 for \u00e9n enkelt klynge forbliver antallet s\u00e5dan (til sammenligning vil 10 klynger have brug for 30 master-noder).<\/p>\n<p>Den ovenfor n\u00e6vnte nuance g\u00e6lder ogs\u00e5 for andre tjenester, der fungerer p\u00e5 tv\u00e6rs af hele klyngen, s\u00e5som load balancers, Ingress-controllere, autentificerings-, lognings- og overv\u00e5gningstjenester.<\/p>\n<p>I en enkelt klynge kan alle disse tjenester bruges direkte til alle arbejdsbyrder (der er ikke behov for at oprette kopier af dem, som ved flere klynger).<\/p>\n<h3>+ Billighed<\/h3>\n<p>\nSom en konsekvens af ovenst\u00e5ende er f\u00e6rre klynger normalt billigere, da der ikke er omkostninger til overfl\u00f8dige ressourcer.<\/p>\n<p>Dette g\u00e6lder is\u00e6r for master-noder, som kan koste betydelige penge uanset placering (on-premises eller i skyen).<\/p>\n<p>Nogle administrerede Kubernetes-tjenester, s\u00e5som <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/kubernetes-engine\">Google Kubernetes Engine (GKE)<\/a><\/noindex> eller <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/aks\/\">Azure Kubernetes Service (AKS)<\/a><\/noindex>, de giver et gratis administrationslag. I dette tilf\u00e6lde er omkostningssp\u00f8rgsm\u00e5let ikke s\u00e5 presserende.<\/p>\n<p>Der findes ogs\u00e5 managed-tjenester, der opkr\u00e6ver et fast gebyr for driften af hver Kubernetes-klynge (for eksempel, <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/eks\/\">Amazon Elastic Kubernetes Service, EKS<\/a><\/noindex>).<\/p>\n<h3>+ Effektiv administration<\/h3>\n<p>\nDet er lettere at administrere \u00e9n klynge end flere.<\/p>\n<p>Administration kan inkludere f\u00f8lgende opgaver:<\/p>\n<ul>\n<li> opdatering af Kubernetes-version;<\/li>\n<li> ops\u00e6tning af CI\/CD-pipeline;<\/li>\n<li> installation af CNI-plugin;<\/li>\n<li> ops\u00e6tning af brugerautentifikationssystem;<\/li>\n<li> installation af adgangskontrolcontroller;<\/li>\n<\/ul>\n<p>\nog mange andre...<\/p>\n<p>I tilf\u00e6lde af \u00e9n klynge skal man kun g\u00f8re alt dette \u00e9n gang.<\/p>\n<p>For mange klynger skal operationerne gentages mange gange, hvilket sandsynligvis kr\u00e6ver nogen automatisering af processerne og v\u00e6rkt\u00f8jer for at sikre konsistens og ensartethed i processen.<\/p>\n<p><i>Lad os nu tale om ulemperne.<\/i><\/p>\n<h3>\u2212 Enkelt punkt for fejl<\/h3>\n<p>\nI tilf\u00e6lde af, at <i>den eneste<\/i> klynge fejler, vil <i>alle<\/i> arbejdsbyrderne straks stoppe med at fungere!<\/p>\n<p>Der findes mange scenarier, hvor noget kan g\u00e5 galt:<\/p>\n<ul>\n<li> opdatering af Kubernetes medf\u00f8rer uventede bivirkninger;<\/li>\n<li> en f\u00e6lles klyngekomponent (for eksempel CNI-plugin) fungerer ikke som forventet;<\/li>\n<li> en af klyngekomponenterne er forkert konfigureret;<\/li>\n<li> fejl i den underliggende infrastruktur.<\/li>\n<\/ul>\n<p>\nEn s\u00e5dan h\u00e6ndelse kan for\u00e5rsage betydelig skade p\u00e5 alle arbejdsbyrder, der er hostet i den f\u00e6lles klynge.<\/p>\n<h3>\u2212 Manglende streng isolation<\/h3>\n<p>\nAt arbejde i en f\u00e6lles klynge betyder, at applikationer deler hardware, netv\u00e6rksressourcer og operativsystemet p\u00e5 klyngeknuderne.<\/p>\n<p>I en vis forstand er to containere med to forskellige applikationer, der k\u00f8rer p\u00e5 den samme knude, ligesom to processer, der k\u00f8rer p\u00e5 den samme maskine under det samme OS-kernel.<\/p>\n<p><i>Linux-containere giver en vis form for isolation, men den er langt fra s\u00e5 st\u00e6rk som den, virtualiserede maskiner tilbyder. I bund og grund er processen i en container den samme proces, der k\u00f8rer i v\u00e6rtsoperativsystemet.<\/i><\/p>\n<p>Dette kan blive et problem med hensyn til sikkerhed: en s\u00e5dan opbygning tillader teoretisk set urelaterede applikationer at interagere med hinanden (bevidst eller ubevidst).<\/p>\n<p>Desuden deler alle arbejdsbyrder i Kubernetes-klusteret nogle f\u00e6lles klaseservices, s\u00e5som <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/dns-pod-service\/\">DNS<\/a><\/noindex> \u2014 g\u00f8r det muligt for applikationer at finde tjenester fra andre applikationer i klyngen.<\/p>\n<p><i>Alle de ovenn\u00e6vnte punkter kan have forskellige betydninger afh\u00e6ngigt af de sikkerhedskrav, der stilles til applikationerne.<\/i><\/p>\n<p>Kubernetes leverer forskellige v\u00e6rkt\u00f8jer til at forhindre sikkerhedsproblemer, s\u00e5som <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/pod-security-policy\/\">PodSecurityPolicies<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">NetworkPolicies<\/a><\/noindex>. Men for at konfigurere dem korrekt kr\u00e6ves der en vis erfaring; desuden kan de ikke lukke alle sikkerhedshuller.<\/p>\n<p>Det er vigtigt altid at huske, at Kubernetes oprindeligt er designet til <i>f\u00e6lles brug<\/i>, og ikke til <i>isolering og sikkerhed<\/i>.<\/p>\n<h3>\u2212 Mangel p\u00e5 streng multi-tenancy<\/h3>\n<p>\nI betragtning af de mange f\u00e6lles ressourcer i Kubernetes-klusteret er der mange m\u00e5der, hvorp\u00e5 forskellige applikationer kan \"tr\u00e6de hinanden over t\u00e6erne\".<\/p>\n<p>For eksempel kan en applikation monopolisere en f\u00e6lles ressource (som CPU eller hukommelse) og ber\u00f8ve andre applikationer, der k\u00f8rer p\u00e5 den samme node, adgangen til den.<\/p>\n<p>Kubernetes leverer forskellige mekanismer til at kontrollere s\u00e5dan adf\u00e6rd, s\u00e5som <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/\">ressourceanmodninger og -gr\u00e6nser<\/a><\/noindex> <i>(se ogs\u00e5 artiklen \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\"> CPU-gr\u00e6nser og aggressiv throttling i Kubernetes <\/a><\/noindex>\" - red.)<\/i>, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/resource-quotas\/\">ResourceQuotas<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/limit-range\/\">LimitRanges<\/a><\/noindex>. Men ligesom med sikkerheden er deres ops\u00e6tning ret kompleks, og de kan ikke forhindre alle uforudsete bivirkninger.<\/p>\n<h3>\u2212 Stort antal brugere<\/h3>\n<p>\nI tilf\u00e6lde af et enkelt kluster skal der gives adgang til mange mennesker. Og jo flere de er, jo h\u00f8jere er risikoen for, at de kan \"bryde noget\".<\/p>\n<p>Inden for klusteret kan man kontrollere, hvem der kan g\u00f8re hvad ved hj\u00e6lp af <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/\">rollebaseret adgangskontrol (RBAC)<\/a><\/noindex> <i>(se artiklen \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/470503\/\"> Users and RBAC Authorization in Kubernetes <\/a><\/noindex>\" - red.)<\/i>. Det vil dog ikke forhindre brugere i at \"bryde\" noget inden for deres ansvarsomr\u00e5de.<\/p>\n<h3>\u2212 Kluster kan ikke vokse uendeligt<\/h3>\n<p>\nEn klynge, der anvendes til alle arbejdsbyrder, vil sandsynligvis v\u00e6re ret stor (i antallet af noder og pods).<\/p>\n<p>Men her opst\u00e5r et andet problem: klustre i Kubernetes kan ikke vokse uendeligt.<\/p>\n<p>Der er en teoretisk gr\u00e6nse for st\u00f8rrelsen af et kluster. I Kubernetes er den cirka <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/setup\/best-practices\/cluster-large\/\">5000 noder, 150.000 pods og 300.000 containere<\/a><\/noindex>.<\/p>\n<p>Men i virkeligheden kan problemer opst\u00e5 meget tidligere \u2014 for eksempel efter kun <noindex><a rel=\"nofollow\" href=\"https:\/\/events19.lfasiallc.com\/wp-content\/uploads\/2017\/11\/BoF_-Not-One-Size-Fits-All-How-to-Size-Kubernetes-Clusters_Guang-Ya-Liu-_-Sahdev-Zala.pdf\">500 noder<\/a><\/noindex>.<\/p>\n<p>Problemet er, at store klynger l\u00e6gger et h\u00f8jt pres p\u00e5 Kubernetes kontrolplanet. Med andre ord kr\u00e6ver det omhyggelig konfiguration for at holde klyngen i drift og bruge ressourcer effektivt.<\/p>\n<p><i>Dette problem diskuteres i den relevante artikel p\u00e5 den oprindelige blog med titlen \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/kubernetes-node-size\">Architecting Kubernetes clusters \u2014 choosing a worker node size<\/a><\/noindex>\u00bb.<\/i><\/p>\n<p><i>Men lad os overveje den modsatte tilgang: mange sm\u00e5 klynger.<\/i><\/p>\n<h2>2. Mange sm\u00e5, specialiserede klynger<\/h2>\n<p>\nI denne tilgang bruger du en separat klynge til hver deployerede enhed:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/2320f62d945944f2e26f07252e9b8440.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Mange sm\u00e5 klynger<\/i><\/p>\n<p>For form\u00e5let med denne artikel henviser <i>til den deployerede enhed<\/i> som en instans af applikationen \u2014 for eksempel en dev-version af en separat applikation.<\/p>\n<p>I denne strategi bruges Kubernetes som en specialiseret <b>runtime<\/b> for individuelle applikationsinstanser.<\/p>\n<p><i>Lad os se p\u00e5 fordele og ulemper ved denne tilgang.<\/i><\/p>\n<h3>+ Begr\u00e6nset 'explosionsradius'<\/h3>\n<p>\nVed en \u00abfejl\u00bb i klyngen begr\u00e6nses de negative konsekvenser til de arbejdsbyrder, der var udrullet i denne klynge. Alle andre arbejdsbyrder forbliver ur\u00f8rt.<\/p>\n<h3>+ Isolation<\/h3>\n<p>\nArbejdsbelastninger, der er placeret i individuelle klynger, deler ikke ressourcer som CPU, hukommelse, operativsystem, netv\u00e6rk eller andre tjenester.<\/p>\n<p>Som et resultat f\u00e5r vi en stram isolation mellem ikke-relaterede applikationer, hvilket kan have en positiv indvirkning p\u00e5 deres sikkerhed.<\/p>\n<h3>+ F\u00e5 brugere<\/h3>\n<p>\nDa hver klynge kun indeholder et begr\u00e6nset antal arbejdsbelastninger, reduceres antallet af brugere med adgang til den.<\/p>\n<p>Jo f\u00e6rre personer der har adgang til klyngen, desto lavere er risikoen for, at noget 'g\u00e5r i stykker'.<\/p>\n<p><i>Lad os se p\u00e5 ulemperne.<\/i><\/p>\n<h3>\u2212 Ineffektiv ressourceanvendelse<\/h3>\n<p>\nSom n\u00e6vnt tidligere kr\u00e6ver hver Kubernetes klynge et bestemt s\u00e6t styringsressourcer: master-noder, kontrolplane komponenter, overv\u00e5gnings- og logningsl\u00f8sninger.<\/p>\n<p>Ved et stort antal sm\u00e5 klynger skal der tildeles en st\u00f8rre andel ressourcer til administration.<\/p>\n<h3>\u2212 Omkostninger<\/h3>\n<p>\nIneffektiv ressourceanvendelse f\u00f8rer automatisk til h\u00f8je udgifter.<\/p>\n<p>For example, the presence of 30 master nodes instead of three with the same computing power will inevitably reflect on costs.<\/p>\n<h3>\u2212 Challenges of administration<\/h3>\n<p>\nManaging multiple Kubernetes clusters is much more complicated than working with a single one.<\/p>\n<p>For example, you will need to configure authentication and authorization for each cluster. Upgrading the Kubernetes version will also have to be done multiple times.<\/p>\n<p>It is likely that automation will need to be applied to increase the efficiency of all these tasks.<\/p>\n<p><i>Now let's look at less extreme scenarios.<\/i><\/p>\n<h2>3. One cluster for each application<\/h2>\n<p>\nIn this approach, you create a separate cluster for all instances of a specific application:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/238ee74d4e4dc42b7daeadc1ce484905.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cluster per application<\/i><\/p>\n<p>This path can be seen as a generalization of the principle of \"<b>a separate cluster for each team<\/b>\", since typically a team of engineers works on developing one or more applications.<\/p>\n<p><i>Lad os se p\u00e5 fordele og ulemper ved denne tilgang.<\/i><\/p>\n<h3>+ The cluster can be tailored to the application<\/h3>\n<p>\nIf the application has specific needs, they can be implemented in the cluster without affecting other clusters.<\/p>\n<p>S\u00e5danne behov kan omfatte arbejdere med GPU, bestemte CNI-plugins, service mesh eller en anden tjeneste.<\/p>\n<p>Each cluster can be tailored to the application it runs, containing only what is necessary.<\/p>\n<h3>\u2212 Different environments in one cluster<\/h3>\n<p>\nThe downside of this approach is that application instances from different environments coexist in one cluster.<\/p>\n<p>For example, the production version of the application runs in the same cluster as the development version. This also means that developers operate in the same cluster as the production version of the application.<\/p>\n<p>If a failure occurs in the cluster due to developers' actions or bugs in the dev version, the prod version could potentially be affected \u2014 a significant drawback of this approach.<\/p>\n<p><i>And finally, the last scenario on our list.<\/i><\/p>\n<h2>4. One cluster for each environment<\/h2>\n<p>\nThis scenario provides for allocating a separate cluster for each environment:<\/p>\n<p><img decoding=\"async\" alt=\"Design af Kubernetes-klynger: hvor mange skal der v\u00e6re?\" src=\"\/wp-content\/uploads\/2020\/05\/157da599edf178832b1b15459786fbc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>One cluster per environment<\/i><\/p>\n<p>For instance, you might have clusters <i>dev<\/i>, <i>test<\/i> og <i>prod<\/i>, where you will run all instances of the application intended for a specific environment.<\/p>\n<p><i>Here are the pros and cons of this approach.<\/i><\/p>\n<h3>+ Isolation of the production environment<\/h3>\n<p>\nDenne tilgang sikrer, at alle milj\u00f8er er isolerede fra hinanden. Dette er s\u00e6rligt vigtigt for produktionsmilj\u00f8et.<\/p>\n<p>Produktionsversionerne af applikationen er nu uafh\u00e6ngige af, hvad der sker i andre klynger og milj\u00f8er.<\/p>\n<p>S\u00e5 hvis der pludselig opst\u00e5r et problem i udviklerklyngen, vil produktionsversionerne af applikationerne forts\u00e6tte med at fungere, som om intet er sket.<\/p>\n<h3>+ Klyngen kan tilpasses til milj\u00f8et<\/h3>\n<p>\nHver klynge kan tilpasses sit milj\u00f8. For eksempel kan man:<\/p>\n<ul>\n<li> installere udviklings- og fejlfindingv\u00e6rkt\u00f8jer i udviklerklyngen;<\/li>\n<li> installere testv\u00e6rkt\u00f8jer og frameworks i klyngen; <i>test<\/i>;<\/li>\n<li> bruge kraftigere hardware og netv\u00e6rksforbindelser i klyngen; <i>prod<\/i>.<\/li>\n<\/ul>\n<p>\nDette \u00f8ger effektiviteten i b\u00e5de udviklingen og driften af applikationerne.<\/p>\n<h3>+ Adgangsbegr\u00e6nsning til produktionsklyngen<\/h3>\n<p>\nBehovet for at arbejde direkte med produktionsklyngen opst\u00e5r sj\u00e6ldent, s\u00e5 man kan betydeligt begr\u00e6nse antallet af personer, der har adgang til den.<\/p>\n<p>Man kan g\u00e5 endnu l\u00e6ngere og helt fjerne personers adgang til denne klynge, og alle implementeringer udf\u00f8res med et automatiseret CI\/CD v\u00e6rkt\u00f8j. Denne tilgang vil maksimalt reducere risikoen for menneskelige fejl, hvor det er mest kritisk.<\/p>\n<p><i>Lad os nu tale om ulemperne.<\/i><\/p>\n<h3>\u2212 Manglende isolation mellem applikationer<\/h3>\n<p>\nDen st\u00f8rste ulempe ved tilgangen er den manglende hardware- og ressourceisolering mellem applikationerne.<\/p>\n<p>Ikke-relaterede applikationer deler ressourcerne i klyngen: systemkernel, processor, hukommelse og nogle andre tjenester.<\/p>\n<p>Som n\u00e6vnt kan dette v\u00e6re potentielt farligt.<\/p>\n<h3>\u2212 Manglende mulighed for at lokalisere applikationsafh\u00e6ngigheder<\/h3>\n<p>\nHvis en applikation har s\u00e6rlige krav, skal de opfyldes i alle klynger.<\/p>\n<p>For eksempel, hvis en applikation kr\u00e6ver GPU, skal hver klynge have mindst \u00e9n worker med GPU (selv hvis den kun bruges af denne applikation).<\/p>\n<p>Som resultat risikerer vi h\u00f8jere omkostninger og ineffektiv ressourceudnyttelse.<\/p>\n<h2>Konklusion<\/h2>\n<p>\nN\u00e5r der er et bestemt s\u00e6t applikationer, kan de placeres i flere store klynger eller i mange sm\u00e5.<\/p>\n<p>Artiklen diskuterer fordele og ulemper ved forskellige tilgange, fra \u00e9n global klynge til flere sm\u00e5 og specialiserede:<\/p>\n<ul>\n<li> \u00e9n stor f\u00e6lles klynge;<\/li>\n<li> en masse af sm\u00e5 specialiserede klynger;<\/li>\n<li> \u00e9n klynge pr. applikation;<\/li>\n<li> \u00e9n klynge pr. milj\u00f8.<\/li>\n<\/ul>\n<p>\n<i>S\u00e5 hvilken tilgang skal man v\u00e6lge?<\/i><\/p>\n<p>Som altid afh\u00e6nger svaret af brugsscenariet: det er n\u00f8dvendigt at veje fordele og ulemper ved de forskellige tilgange og v\u00e6lge den mest optimale variant.<\/p>\n<p>Men valget er ikke begr\u00e6nset til de n\u00e6vnte eksempler - man kan bruge enhver kombination af dem!<\/p>\n<p>For eksempel kan man organisere et par klynger til hvert team: en klynge til udvikling (hvor der vil v\u00e6re milj\u00f8er <i>dev<\/i> og <i>test<\/i>) og en klynge til <i>production<\/i> (hvor produktionsmilj\u00f8et vil v\u00e6re).<\/p>\n<p>Ved at basere sig p\u00e5 oplysningerne fra denne artikel kan du optimere fordele og ulemper til det specifikke scenarie. Held og lykke!<\/p>\n<h2>P.S.<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/484954\/\">Visuelt guide til fejlfinding i Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480946\/\">Logs i Kubernetes (og mere) i dag: forventninger og realiteter<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/478306\/\">Service Mesh: hvad hver Software Engineer b\u00f8r vide om den mest hypede teknologi<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468679\/\">Sikkerhedsalfabetet i Kubernetes: autentifikation, autorisation, revision<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/498100\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u043e\u0442 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u043e\u0442 \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430 learnk8s \u2014 \u043e\u0442\u0432\u0435\u0442 \u043d\u0430 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u0432\u043e\u043f\u0440\u043e\u0441 \u043f\u0440\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u043d\u0430 \u0431\u0430\u0437\u0435 Kubernetes. \u041d\u0430\u0434\u0435\u0435\u043c\u0441\u044f, \u0447\u0442\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0440\u0430\u0437\u0432\u0451\u0440\u043d\u0443\u0442\u044b\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u043f\u043b\u044e\u0441\u043e\u0432 \u0438 \u043c\u0438\u043d\u0443\u0441\u043e\u0432 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0438\u0437 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043e\u043f\u0442\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u0439 \u0432\u044b\u0431\u043e\u0440 \u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430. TL;DR: \u043e\u0434\u0438\u043d \u0438 \u0442\u043e\u0442 \u0436\u0435 \u043d\u0430\u0431\u043e\u0440 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 (\u043d\u0430 \u043a\u0430\u0436\u0434\u044b\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80077,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80076","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Design af Kubernetes-klynger: hvor mange skal der v\u00e6re? | ProHoster","description":"Bem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-02T23:42:34+00:00","article:modified_time":"2020-05-02T23:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80076","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:24:58","updated":"2022-10-02 20:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/80076","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=80076"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/80076\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/80077"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=80076"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=80076"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=80076"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}