{"id":2028,"date":"2019-10-07T06:34:41","date_gmt":"2019-10-07T10:34:41","guid":{"rendered":"http:\/\/soul-repairs.com\/?p=2028"},"modified":"2019-10-10T16:07:22","modified_gmt":"2019-10-10T20:07:22","slug":"kubernetes-openshift-resource-protection-with-limit-ranges-and-resource-quotas","status":"publish","type":"post","link":"https:\/\/soul-repairs.com\/blog\/2019\/10\/07\/kubernetes-openshift-resource-protection-with-limit-ranges-and-resource-quotas\/","title":{"rendered":"Kubernetes\/OpenShift Resource Protection with Limit Ranges and Resource Quotas"},"content":{"rendered":"

One of the most crucial metrics of success for an enterprise application platform is if the platform can protect: a) the applications running on it, and b) itself (and its underlying infrastructure). A<\/em>ll threats to an application platform eventually come from something within<\/em> that platform – an application can be hacked, and then it attacks other applications; or there could be a privilege escalation attack going after the underlying host infrastructure; or an application can accidentally hoard platform resources, choking out other apps from being able to run.<\/p>\n

<\/p>\n

The solution to this is some amount of isolation – like quarantining someone who’s sick so they don’t get other<\/em> people sick. And one of the reasons we love OpenShift is that it does exactly this – it effectively isolates applications. On OpenShift, applications can operate in their defined box o’ resources, and they usually can’t destroy each other or the underlying platform.<\/p>\n

\"\"<\/p>\n

In addition to keeping the applications, the platform, and the infrastructure more secure, this also<\/em> enables the power of ownership <\/strong>and at least one piece of the goal that is “DevOps.” Because applications are inherently more isolated, infrastructure admins can spend less<\/em> time and energy worrying about applications, and more<\/em> time focusing on\u00a0keeping the platform healthy and secure.<\/p>\n

This is part of why developer self-service is possible, because the applications in one namespace\/project can’t easily hurt the applications in another. One of the most important pieces of any Kubernetes-based container platform being successful is properly setting up resource boundaries and sandboxing. In OpenShift, these resource boundaries are called LimitRanges and ResourceQuotas<\/a>. These are set at the project<\/em> level – and it’s super important to set these limits on every<\/strong> project. You never know when someone will deploy some really inefficient code or have a massive increase in workload – and that’s the great part about these. You don’t have<\/em> to know.<\/p>\n

Like many OpenShift features, these are also part of Kubernetes itself. Pretty much everything we’ll say from here on out applies to Kubernetes as much as OpenShift.<\/p>\n

Overview<\/h2>\n

Clusters (running instances of OpenShift) have physical<\/em> limitations for their CPU and memory. Somewhere under each cluster is some<\/em> real hardware that has an actual, real maximum amount of resources because of what the hardware contains. Within a cluster, are projects<\/strong> (namespaces, buckets in which applications are logically grouped) which contain\u00a0pods<\/strong> (running instances of an application).<\/p>\n

There are three different types of resource boundaries in OpenShift. Collectively, they’re sometimes called “capping.”\u00a0<\/span><\/p>\n