{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Bedste praksis for Kubernetes. Konfiguration af anmodninger og ressourcegr\u00e6nser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De bedste Kubernetes-praksis. Oprettelse af sm\u00e5 containere<\/a><\/noindex>
\nDe bedste Kubernetes-praksis. Organisering af Kubernetes med navnerum<\/a><\/noindex>
\nDe bedste Kubernetes-praksis. Kontrol af Kubernetes' levedygtighed med Readiness- og Liveness-tests<\/a><\/noindex><\/p>\n

For each Kubernetes resource, there is the possibility to configure two types of requirements \u2014 Requests and Limits. The first describes the minimum node resource requirements necessary to start a container or pod, while the second strictly limits the resources available to the container. <\/p>\n

When Kubernetes schedules a pod, it is essential that the containers have sufficient resources for normal operation. If you plan to deploy a large application on a node with limited resources, it is quite possible that it will not function due to insufficient memory or CPU power on that node. In this article, we will look at how to address resource shortages using resource requests and limits.<\/p>\n

Requests and Limits are mechanisms that Kubernetes uses to manage resources such as CPU and memory. Requests are what guarantee that a container receives the requested resource. If a container requests a resource, Kubernetes will only schedule it on a node that can provide it. Limits control that the resources requested by the container will never exceed a certain value.<\/p>\n

\"Bedste<\/a><\/noindex><\/p>\n

A container can only scale its computational power up to a certain limit, after which it will be restricted. Let's look at how this works. There are two types of resources \u2014 CPU and memory. The Kubernetes scheduler uses data about these resources to determine where to run your pods. A typical resource specification for a pod looks like this.<\/p>\n

\"Bedste
\n
\nHver container i en pod kan angive sine egne anmodninger og begr\u00e6nsninger, og alt dette er additivt. CPU-ressourcerne defineres i millikere. Hvis din container har brug for to fulde kerner til drift, indstiller du v\u00e6rdien til 2000m. Hvis containeren derimod kun har brug for \u00bc kerne, vil v\u00e6rdien v\u00e6re 250m. V\u00e6r opm\u00e6rksom p\u00e5, at hvis du tildeler en CPU-ressourcev\u00e6rdi, der overstiger antallet af kerner p\u00e5 den st\u00f8rste node, vil din pod ikke blive planlagt til at k\u00f8re overhovedet. En lignende situation vil opst\u00e5, hvis du har en pod, der kr\u00e6ver fire kerner, men dit Kubernetes-kluster kun best\u00e5r af to prim\u00e6re virtuelle maskiner.<\/p>\n

Medmindre din applikation er specielt designet til at udnytte fordelene ved flere kerner (som komplekse videnskabelige beregninger og databaseoperationer), er den bedste praksis at indstille CPU Requests til 1 eller mindre, for derefter at k\u00f8re flere replikaer for skalerbarhed. Denne l\u00f8sning vil give systemet st\u00f8rre fleksibilitet og p\u00e5lidelighed.<\/p>\n

N\u00e5r det kommer til CPU-begr\u00e6nsninger, bliver det mere interessant, da det betragtes som en komprimerbar ressource. Hvis din applikation begynder at n\u00e6rme sig gr\u00e6nsen for CPU-kraft, vil Kubernetes begynde at d\u00e6mpe din container ved at anvende CPU Throttling \u2014 nedsk\u00e6ring af CPU-frekvensen. Det betyder, at CPU'en vil blive kunstigt begr\u00e6nset, hvilket kan give applikationen d\u00e5rligere ydeevne, men processen vil ikke blive stoppet eller afbrudt. <\/p>\n

Hukommelsesressourcerne defineres i bytes. Normalt m\u00e5les v\u00e6rdien i indstillingerne i mebibytes (Mib), men du kan angive enhver v\u00e6rdi fra bytes til petabytes. Her g\u00e6lder det samme som for CPU \u2014 hvis du anmoder om en m\u00e6ngde hukommelse, der overstiger den tilg\u00e6ngelige hukommelse p\u00e5 dine noder, vil udf\u00f8relsen af denne pod ikke blive planlagt. Men i mods\u00e6tning til CPU-ressourcer kan hukommelse ikke komprimeres, fordi der ikke er nogen m\u00e5de at begr\u00e6nse dens brug p\u00e5. Derfor vil udf\u00f8relsen af containeren stoppe, s\u00e5 snart den overskrider den tildelte hukommelse.<\/p>\n

\"Bedste
\n
\nDet er vigtigt at huske, at du ikke kan konfigurere foresp\u00f8rgsler, der overstiger st\u00f8rrelsen af de ressourcer, som dine noder kan levere. Specifikationerne for de delte ressourcer til GKE-virtuelle maskiner kan findes via linkene under denne video.<\/p>\n

I en ideel verden vil standardindstillingerne for containeren v\u00e6re tilstr\u00e6kkelige til, at arbejdsprocesserne forl\u00f8ber glat. Men den virkelige verden er ikke s\u00e5dan; folk glemmer let at konfigurere ressourceanvendelse, eller hackere ops\u00e6tter foresp\u00f8rgsler og gr\u00e6nser, der overstiger infrastrukturens faktiske kapacitet. For at forhindre s\u00e5danne scenarier kan der konfigureres ressourcekvoter med ResourceQuota og gr\u00e6nseomr\u00e5der med LimitRange.<\/p>\n

Efter oprettelsen af navnerum kan de blive l\u00e5st med kvoter. For eksempel, hvis du har navnerummene prod og dev, anvendes en skabelon, hvor kvoterne for produktion slet ikke findes, mens kvoterne for udvikling er meget strenge. Dette giver prod muligheden for at tage alle eksisterende ressourcer i tilf\u00e6lde af en pludselig trafikstigning, hvilket helt l\u00e5ser dev.<\/p>\n

Ressourcekvoten kan se s\u00e5dan ud. I dette eksempel er der 4 afsnit \u2013 det er de 4 nederste linjer af koden.<\/p>\n

\"Bedste
\n
\nLad os se n\u00e6rmere p\u00e5 hver enkelt. Requests.cpu er det maksimale antal kombinerede CPU-ressourceforesp\u00f8rgsler, der kan komme fra alle containere i navnerummet. I dette eksempel kan du have 50 containere med foresp\u00f8rgsler p\u00e5 10m, fem containere med foresp\u00f8rgsler p\u00e5 100m eller blot \u00e9n container med en foresp\u00f8rgsel p\u00e5 500m. S\u00e5 l\u00e6nge det samlede antal requests.cpu i dette navnerum er mindre end 500m, er alt i orden.<\/p>\n

Den anmodede hukommelse requests.memory er den maksimale kombinerede m\u00e6ngde hukommelsesforesp\u00f8rgsler, som alle containere i navnerummet kan have. Som i det tidligere tilf\u00e6lde kan du have 50 containere med 2 MiB, fem containere med 20 MiB eller \u00e9n enkelt container med 100 MiB, s\u00e5 l\u00e6nge det samlede antal anmodet hukommelse i navnerummet er mindre end 100 Mebibyte.<\/p>\n

Limits.cpu er den maksimale samlede v\u00e6rdi af CPU-ressourcer, som alle containere i navnerummet kan bruge. Det kan betragtes som gr\u00e6nsen for CPU-ressourceforesp\u00f8rgsler.<\/p>\n

Endelig er limits.memory det maksimale bel\u00f8b af samlet hukommelse, som alle containere i navnerummet kan bruge. Denne begr\u00e6nsning omfatter de samlede hukommelsesforesp\u00f8rgsler.
\nSom standard arbejder containere i Kubernetes-clusteret med ubegr\u00e6nsede beregningsressourcer. Med ressourcetr\u00e6k kan clusteradministratorer begr\u00e6nse ressourceforbrug og -oprettelse baseret p\u00e5 navnerum. I navnerummet kan en pod eller container forbruge s\u00e5 meget CPU- og hukommelsesmagt som angivet i navnerummets ressourcetr\u00e6k. Der er dog bekymringer for, at en enkelt pod eller container kan monopolisere alle tilg\u00e6ngelige ressourcer. For at forhindre denne situation anvendes Limit Range \u2013 en politik for begr\u00e6nsning af ressourcefordeling (for pods eller containere) i navnerummet.<\/p>\n

Limit Range giver begr\u00e6nsninger, der kan:<\/p>\n