Kubernetes adoption is growing, and as organizations increasingly use it to automate the deployment, management, and scaling of containerized applications, more teams are paying attention to the reliability, security, and cost efficiency of their workloads. Last year, Fairwinds created a new Kubernetes benchmark report, based on an evaluation of more than 100,000 Kubernetes workloads intended to help organizations better understand their container configurations and compare their results to those of their peers. This year, Fairwinds updated the Benchmark Report based on the data from 2022 (over 150,000 workloads), and compared the data from the previous year to analyze how things have improved (or not) in the past year.
Kubernetes security, cost efficiency, and reliability remain top concerns to cloud native users. What your development teams want to know now that they have worked so hard to establish their Kubernetes environment and worked to properly configure their workloads is how your configurations look compared to your peers in the cloud native ecosystem.
According to the benchmark data, people are still not configuring Kubernetes such that it is aligned to best practices. Unfortunately, that translates into unnecessary risk, cloud cost overruns, and even (potentially) lost customers due to poor application performance. The latest Kubernetes Benchmark Report can help you better understand where to best spend your time and money to improve configurations.
Hundreds of organizations are using the Fairwinds Insights platform, running over 150,000 workloads in 2022. By evaluating the results from benchmarking clusters against reliability, security, and cost efficiency metrics, we can see that things are actually getting worse, not better. 2021 data showed many results with less than 10% of workloads impacted, but this year that changed across all the core issues. So why is that happening?
As Kubernetes usage expands, it has become harder for DevOps to manage the potential configuration risks introduced by new teams. In other words, they are outnumbered — Kubernetes adoption is outpacing their ability to apply the necessary policies and controls. Rather than relying on manual processes and trying to reference and crosscheck policies and enforce them, we need to help them by automating Kubernetes governance and guardrails.
Whether you are developing applications and services using cloud native technologies or are on the DevOps and platform engineering teams who are building the infrastructure, you need a platform that is highly performant, secure, and cost effective.
We divided the Benchmark Report into three sections again this year: reliability, security, and cost efficiency. Where are you lagging behind and how can you improve your Kubernetes configurations?
Kubernetes reliability can be impacted by six key configuration issues, many of which can be difficult to address. It’s not easy to know what values to assign for each application, resulting in no limits, insufficient limits, or limits that are set too high during testing and never corrected. This year, only about 17% or organizations had set memory requests and limits for over 90% of their workloads — a significant drop from last year’s 41%. Similarly, many organizations are missing liveness and readiness probes, relying on cached versions of Docker images, and missing CPU requests and limits. New this year, we are now checking for deployments that have only a single replica, because replica deployments help maintain the stability and high availability of containers.
There are nine different security-related Kubernetes configurations we evaluated in this year’s report, not only showing how organizations were doing last year, but showing some serious swings this year. Forty-two percent of organizations were turning off insecure capabilities for most of their workloads in 2021 but, surprisingly, this year only 10% are. The latest report shows that 33% of organizations have more than 90% of workloads running with insecure capabilities.
Another important security setting is readOnlyRootFilesystem, which prevents a container from writing to its file system. There was another significant swing in terms of security in the latest report, which shows that organizations may not be aware of the need to override insecure defaults in Kubernetes. The report also shows some surprising shifts in the ability of containers to run as privileged. Also covered in this report, allowing containers to run as root, workloads impacted by image vulnerabilities, outdated Helm charts, outdated container images, and deprecated API versions.
When it comes to cost efficiency, it appears that most organizations are doing a decent job when setting CPU requests and limits. Few are setting workload limits too high, and even fewer are setting those limits too low. Areas for improvement in terms of cost efficiency include setting memory limits more carefully - many are setting memory limits too high, with 30% of organizations seeing at least 50% of their workloads impacted, thereby wasting considerable cloud resources. A considerable number are setting memory limits too low in some cases, which can reduce the reliability of clusters and potentially result in failing applications. The report also highlights where memory requests are set too low or too high, how many workloads are impacted, and how those requests can be adjusted to right-size requests.
Container and Kubernetes technology can bring significant value to businesses, but without understanding these essential configurations and how to set them appropriately, it can be difficult to navigate the complexities inherent in Kubernetes. This report helps you to better understand your cluster deficiencies, where to make investments, and how to configure Kubernetes to have a positive business impact. By reviewing this data, you can learn and make adjustments to improve your Kubernetes deployment and make sure your applications and services are as reliable, secure, and cost efficient as possible in the year ahead.
Read the complete Kubernetes Benchmark Report today.
