![\"Nine](\"\/wp-content\/uploads\/2020\/10\/92dc510aa9d785a31d310816b18bf854.png\")
<\/p>\n<\/p>\n
Hello everyone! My name is Oleg Sidorenkov, and I work at DomClick as the head of the infrastructure team. We have been running 'Kubik' in production for over three years now, and during this time, we have experienced many interesting moments with it. Today, I will share how, with the right approach, you can extract even more performance from 'vanilla' Kubernetes for your cluster. Ready steady go! <\/p>\n
As you all know, Kubernetes is a scalable open-source system for container orchestration; or rather, 5 binaries that perform magic by managing the lifecycle of your microservices in a server environment. Additionally, it is a quite flexible tool that you can build like a Lego set for maximum customization to fit various tasks.<\/p>\n
And everything seems fine: just throw servers into the cluster like logs into a fire, and you won't have a care in the world. But if you are an eco-conscious person, you might think: 'How can I maintain the fire in the stove while preserving the forest?'. In other words, how to find ways to improve the infrastructure and reduce costs.<\/p>\n
![\"Nine](\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\")
<\/p>\n
One of the simplest yet most effective methods is to implement requests\/limits. Divide applications by namespaces, and namespaces by development teams. Set resource use values for CPU, memory, and ephemeral storage for the application before deployment.<\/p>\n
resources:\n requests:\n memory: 2Gi\n cpu: 250m\n limits:\n memory: 4Gi\n cpu: 500m<\/code><\/pre>\nThrough experience, we concluded: do not inflate requests beyond limits by more than double. The cluster's capacity is calculated based on requests, and if you set applications with a resource difference of, say, 5-10 times, just imagine what will happen to your node as it fills up with pods and suddenly receives a load. Nothing good. At best, throttling; at worst, you will say goodbye to a worker and create cyclical loads on other nodes once the pods start migrating.<\/p>\n
In addition, using limitranges<\/code> you can set resource values for a container at the start \u2014 minimum, maximum, and default:<\/p>\n\u279c ~ kubectl describe limitranges --namespace ops\nName: limit-range\nNamespace: ops\nType Resource Min Max Default Request Default Limit Max Limit\/Request 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>\nDon't forget to limit the resources of the namespace so that one team cannot take all the cluster resources:<\/p>\n
\u279c ~ kubectl describe resourcequotas --namespace ops\nName: resource-quota\nNamespace: ops\nResource Used 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>\nAs seen from the description resourcequotas<\/code>, if the ops team wants to deploy pods that will consume another 10 cpu, the scheduler will not allow this and will throw an error:<\/p>\nError creating: pods \"nginx-proxy-9967d8d78-nh4fs\" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10<\/code><\/pre>\nTo solve such a task, you can write a tool, for example, like