![\"Ni](\"\/wp-content\/uploads\/2020\/10\/92dc510aa9d785a31d310816b18bf854.png\")
<\/p>\n<\/p>\n
Hej alle sammen! Mit navn er Oleg Sidorenkov, og jeg arbejder som leder af infrastrukturteamet hos DomClick. Vi har v\u00e6ret i gang med at k\u00f8re 'Kuben' i produktion i over tre \u00e5r, og i l\u00f8bet af den tid har vi oplevet mange forskellige interessante \u00f8jeblikke. I dag vil jeg fort\u00e6lle jer, hvordan man med den rette tilgang kan presse endnu mere ydeevne ud af 'vanilje' Kubernetes til jeres klynge. Klar, parat, g\u00e5! <\/p>\n
I kender alle godt til, at Kubernetes er et skalerbart system med \u00e5ben kildekode til orkestrering af containere; eller 5 bin\u00e6re filer, der udf\u00f8rer magi ved at styre livscyklus for jeres mikrotjenester i servermilj\u00f8et. Desuden er det et ret fleksibelt v\u00e6rkt\u00f8j, som kan samles som et Lego-s\u00e6t for maksimal tilpasning til forskellige opgaver.<\/p>\n
Og det ser ud til at fungere godt: smid servere ind i klyngen som br\u00e6nde i ovnen, og v\u00e6r ikke bekymret. Men hvis du t\u00e6nker p\u00e5 milj\u00f8et, vil du overveje: 'Hvordan kan jeg holde ilden i ovnen i gang og samtidig sk\u00e5ne skoven?'. Med andre ord, hvordan finde m\u00e5der at forbedre infrastrukturen og reducere omkostningerne.<\/p>\n
![\"Ni](\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\")
<\/p>\n
En af de mest banale, men effektive metoder er at indf\u00f8re requests\/limits. Del applikationerne op i namespaces, og del namespaces op efter udviklingsteam. Angiv for applikationen f\u00f8r deployment v\u00e6rdierne for CPU-forbrug, hukommelse og ephemeral lager.<\/p>\n
resources:\n requests:\n memory: 2Gi\n cpu: 250m\n limits:\n memory: 4Gi\n cpu: 500m<\/code><\/pre>\nVi er erfaret kommet frem til, at man ikke b\u00f8r overdrive requests i forhold til limits med mere end det dobbelte. St\u00f8rrelsen p\u00e5 klyngen beregnes ud fra requests, og hvis du angiver en forskel i ressourcer for applikationer, f.eks. 5-10 gange, s\u00e5 forestil dig, hvad der sker med din node, n\u00e5r den fyldes med pods og pludselig f\u00e5r belastning. Intet godt. Som minimum throttling, og som maksimum, kan du sige farvel til workeren og opleve cyklisk belastning p\u00e5 de andre noder, n\u00e5r pods begynder at flytte rundt.<\/p>\n
Derudover, ved hj\u00e6lp af limitranges<\/code> kan du i starten angive ressourcemyderne for containeren \u2014 minimum, maksimum og standard:<\/p>\n\u279c ~ kubectl beskrive limitranges --namespace ops\nNavn: limit-range\nNamespace: ops\nType Ressource Min Max Standard Anmodning Standard Gr\u00e6nse Max Gr\u00e6nse\/Anmodnings Ratio\n---- -------- --- --- --------------- ------------- -----------------------\nContainer cpu 50m 10 100m 100m 2\nContainer ephemeral-storage 12Mi 8Gi 128Mi 4Gi -\nContainer memory 64Mi 40Gi 128Mi 128Mi 2<\/code><\/pre>\nHusk at begr\u00e6nse ressourcerne i namespace, s\u00e5 et hold ikke kan tage alle ressourcerne i klyngen:<\/p>\n
\u279c ~ kubectl beskrive resourcequotas --namespace ops\nNavn: resource-quota\nNamespace: ops\nRessource Bruges Hard\n-------- ---- ----\nlimits.cpu 77250m 80\nlimits.memory 124814367488 150Gi\npods 31 45\nrequests.cpu 53850m 80\nrequests.memory 75613234944 150Gi\nservices 26 50\nservices.loadbalancers 0 0\nservices.nodeports 0 0<\/code><\/pre>\nSom det fremg\u00e5r af beskrivelsen resourcequotas<\/code>, hvis holdet ops \u00f8nsker at implementere pods, der vil forbruge yderligere 10 cpu, vil planl\u00e6ggere ikke tillade dette og give en fejlmeddelelse:<\/p>\nFejl ved oprettelse: pods \"nginx-proxy-9967d8d78-nh4fs\" er forbudt: overskredet kvote: resource-quota, anmodet: limits.cpu=5, requests.cpu=5, brugt: limits.cpu=77250m, requests.cpu=53850m, begr\u00e6nset: limits.cpu=10, requests.cpu=10<\/code><\/pre>\nFor at l\u00f8se en s\u00e5dan opgave kan man skrive et v\u00e6rkt\u00f8j, for eksempel som