![\"Negen](\"\/wp-content\/uploads\/2020\/10\/92dc510aa9d785a31d310816b18bf854.png\")
<\/p>\n<\/p>\n
Hallo allemaal! Mijn naam is Oleg Sidorenkov, ik werk bij het bedrijf DomClick als teamleider van de infrastructuur. We hebben 'Cube' al meer dan drie jaar in productie en in die tijd hebben we veel interessante momenten meegemaakt. Vandaag zal ik jullie vertellen hoe je met de juiste aanpak nog meer prestaties uit 'vanilla' Kubernetes kunt halen voor je cluster. Klaar, set, go! <\/p>\n
Jullie weten allemaal goed dat Kubernetes een schaalbaar open-source systeem is voor het orkestreren van containers; of beter gezegd, vijf binaries die magie verrichten door de levenscyclus van jullie microservices in een serveromgeving te beheren. Bovendien is het een vrij flexibele tool die, net als een Lego-bouwer, kan worden samengesteld voor maximale aanpassing aan verschillende taken.<\/p>\n
En het lijkt allemaal goed: gooi servers in de cluster zoals brandhout in de kachel en je hebt geen zorgen. Maar als je voor ecologie bent, dan ga je nadenken: 'Hoe kan ik het vuur in de kachel ondersteunen en ook het bos sparen?'. Met andere woorden, hoe vind je manieren om de infrastructuur te verbeteren en de kosten te verlagen.<\/p>\n
![\"Negen](\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\")
<\/p>\n
Een van de meest alledaagse, maar effectieve methoden is het invoeren van requests\/limits. Verdeel applicaties over namespaces en namespaces over ontwikkelingsteams. Stel de waarden voor CPU-tijd, geheugen en tijdelijke opslag in voor de applicatie voordat je deze uitrolt.<\/p>\n
resources:\n requests:\n memory: 2Gi\n cpu: 250m\n limits:\n memory: 4Gi\n cpu: 500m<\/code><\/pre>\nVia ervaring hebben we geconcludeerd: het heeft geen zin om requests meer dan twee keer de limits te laten zijn. De omvang van de cluster wordt berekend op basis van requests, en als je applicaties met een verschil in middelen opzet, bijvoorbeeld 5-10 keer, stel je je voor wat er met je node gebeurt wanneer deze vol raakt met pods en plotseling een belasting krijgt. Niets goeds. Op zijn minst throttling, en op zijn ergst zeg je vaarwel tegen de worker en krijg je cyclusbelasting op de andere nodes nadat de pods beginnen te migreren.<\/p>\n
Bovendien kunt u met behulp van limitranges<\/code> je kunt aan het begin waarden voor middelen voor de container instellen \u2014 minimaal, maximaal en standaard:<\/p>\n\u279c ~ kubectl beschrijf limietranges --namespace ops\nNaam: limiet-bereik\nNamespace: ops\nType Resource Min Max Standaard Verzoek Standaard Limiet Max Limiet\/Bericht Verhouding\n---- -------- --- --- ------------------- ---------------- -----------------------\nContainer cpu 50m 10 100m 100m 2\nContainer ephemeral-storage 12Mi 8Gi 128Mi 4Gi -\nContainer geheugen 64Mi 40Gi 128Mi 128Mi 2<\/code><\/pre>\nVergeet niet de resources van de namespace te beperken, zodat \u00e9\u00e9n team niet alle resources van het cluster kan opvorderen:<\/p>\n
\u279c ~ kubectl beschrijf resourcequota's --namespace ops\nNaam: resource-quota\nNamespace: ops\nResource Gebruikt 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>\nZoals te zien in de beschrijving resourcequota's<\/code>, als het ops-team pods wil implementeren die nog eens 10 cpu gaan verbruiken, dan zal de scheduler dit niet toestaan en een foutmelding geven:<\/p>\nFout bij het maken: pods \"nginx-proxy-9967d8d78-nh4fs\" is verboden: quota overschreden: resource-quota, aangevraagd: limits.cpu=5, requests.cpu=5, gebruikt: limits.cpu=77250m, requests.cpu=53850m, beperkt: limits.cpu=10, requests.cpu=10<\/code><\/pre>\nOm een dergelijke taak op te lossen, kan je een tool schrijven, bijvoorbeeld zoals