Kubernetes: 6 open source tools to put your cluster to the test

The Kubernetes ecosystem includes an ever-growing number of tools and services you can plug in: Let’s look at six useful tools for putting your Kubernetes cluster and applications to the test.
Up
130 readers like this
kubernetes trends 2021

Kubernetes has earned an overall reputation as an extensible and pluggable platform for orchestrating containers. That roughly means that you can use it in concert with many other tools and services if you so choose.

This includes a flourishing category of tools built to help you boost the reliability, security, and the overall health of your Kubernetes cluster, and the applications that run on it. Many of them are open source and free to use. That makes Kubernetes experimentation and learning more accessible for individuals and teams alike, among other benefits.

[ Kubernetes terminology, demystified: Read How to explain Kubernetes in plain English and get our Kubernetes glossary cheat sheet for IT and business leaders. ]

While Kubernetes goes hand-in-hand with things like resiliency, security, and automation, it's not sorcery.
The general principle here: While Kubernetes goes hand-in-hand with things like resiliency, security, and automation, it’s not sorcery and witchcraft. There’s work involved in properly configuring and continuously optimizing your environment. (A commercial platform, like Red Hat's OpenShift, built on top of the open source project can take some of that burden off your plate.)

6 tools for testing Kubernetes clusters and applications

Let’s look at six useful tools for putting your Kubernetes cluster and applications to the test – often in an automated or semi-automated fashion.

1. Kubernetes Dashboard

This is a good place to start since Dashboard is a multi-purpose web UI that you can use to deploy, manage, and monitor applications and resources in Kubernetes. It’s essentially a tool for doing stuff (that’s the technical term) in Kubernetes and then keeping an eye on that stuff, too. Dashboard gives you a visual means of checking on the state of your cluster and its resources at any given point, and also provides information about errors if they occur.

Kubernetes Dashboard helps users to interpret the K8s cluster and its resources in a more graphical format.
“Kubernetes Dashboard helps users to interpret the K8s cluster and its resources in a more graphical format. It is a Web GUI that can be configured along with the cluster,” says Raghu Kishore Vempati, director of technology at Capgemini Engineering. “Dashboard is also useful for managers and ops team members who [need] to quickly capture the status of [their] clusters and the applications deployed on them.”

Dashboard is not deployed by default in Kubernetes, although most Kubernetes distributions like Red Hat OpenShift build and expand upon its capabilities, adding SSO support as well. On its own, Kubernetes Dashboard requires running a kubectl (that’s the Kubernetes command line interface) command to turn it on. The official Kubernetes documentation offers clear instructions for doing so, as well as for many other facets of using Dashboard, including how to deploy a containerized application.

From a security POV, it’s also worth noting that Dashboard could be itself viewed as a potentially leaky surface in terms of data security, since it exposes information about the environment. So it initially runs with narrow role-based access control (RBAC) settings by default. Similarly, you will only be able to access the Dashboard from the local machine where the kubectl proxy command is run unless you change the default settings.

[ Read also: OpenShift and Kubernetes: What’s the difference? ]

2. Kube-monkey

Kube-monkey is a version of Netflix’s famous (in IT circles, at least) Chaos Monkey, designed specifically to test Kubernetes clusters. Chaos Monkey essentially asks: “What happens to our application if this machine fails?” It does this by randomly terminating production VMs and containers. As a manifestation of the broader discipline of chaos engineering, the core idea behind the open source tool is to foster resilient, fault-tolerant applications by treating failure as a given in any environment.

Kube-monkey brings that practice to Kubernetes, deleting pods in your cluster – “random pod death,” as the documentation puts it – to promote the development of more resilient services. This is a means of automating chaos testing in your environment, too, as it runs according to a schedule that you configure.

[ Read also: 6 Kubernetes workflows and processes you can automate. ]

You retain some additional control over the chaos, in that it’s not totally random: kube-monkey operates with an opt-in model, meaning that it must be granted permission to terminate pods in a given application before the monkey runs amok.

[ Want to learn more? Get the free eBooks: Getting Started with Kubernetes and O'Reilly: Kubernetes patterns for designing cloud-native apps. ]

3. Kube-hunter

This open source tool allows pen-testing of your cluster and its nodes.
Kubernetes has lots of native security controls that require proper configuration and fine-tuning over time. The community commitment to the platform’s security has also led to the creation of various commercial and open source tools for further ensuring the security of your applications and environment. Kube-hunter is a good example: it’s an open source tool for pen-testing your cluster and its nodes.

Basically, penetration testing is to security what chaos testing is to resiliency. By assuming that you have weaknesses that an attacker can exploit (because you almost certainly do), you more proactively build security into your systems. You’re attacking yourself to discover holes before someone else does. It can also help promote a healthier culture that doesn’t treat security as “someone else’s job,” but a mindset that permeates your software supply chain and all of the individual roles its success depends upon.

4. Project Quay

Speaking of software supply chains: Their security is as hot a topic as ever, says Red Hat technology evangelist Gordon Haff. As noted in a recent MIT Sloan CIO Symposium panel discussion, that attention is now tangibly impacting IT budgets. Haff analyzed recent research in which IT leaders indicated security was their number-one funding priority, a sea change from the days when it was treated as an afterthought line item.

Given that Kubernetes is increasingly becoming a part of software supply chains, it follows that its security is paramount, as is the security of any associated containers you’re operating.

This is particularly important in any scenario where you’re downloading and running container images from a repository, but also for homegrown development, too.

"Have all the appropriate patches been applied to that container you downloaded or built to deploy in your Kubernetes environment?"
Haff poses an example question, one that probably isn’t asked as frequently as it should: “Have all the appropriate patches been applied to that container you downloaded or built to deploy in your Kubernetes environment – especially if it’s been a while since you last inspected it?”

That’s one of the main ideas behind Project Quay, a container image registry designed to boost the security of your repositories via vulnerability scanning and tight access control. The enterprise version of Project Quay is Red Hat Quay (which is available as a hosted service or on-premises.)

“Project Quay includes Clair, a container vulnerability scanner,” Haff says. “Clair scans every image pushed to Quay and continuously scans images to provide a real-time view of any known vulnerabilities in your containers.”

Since containers and Kubernetes go hand-in-hand, container security and Kubernetes security are likewise intertwined. Running a container image with a known vulnerability could provide an opening for a much larger breach in your environment.

5. Kube-burner

Here’s one container image you can find via Quay: kube-burner. This recently released tool puts a Kubernetes cluster to the stress-test by creating or deleting a large number of objects. Red Hat’s Raul Sevilla Canavate recently wrote a blog post about how the OpenShift PerfScale team uses this to test scalability in Red Hat OpenShift 4 – recommended reading. He also notes that kube-burner works with other distributions and the underlying open source version of Kubernetes since all it needs is a Kubernetes API.

Given that scalability is one of Kubernetes’ featured promises, this is a welcome addition to the toolbox – now you can put that potential to a practical test.

6. Kube-bench

Sometimes the tricky part of determining the health of a system comes down to a deceptively simple challenge: What does “healthy” look like? You can substitute in other words for healthy, like resilient or secure.

This is where a framework like the Center for Internet Security (CIS) Kubernetes Benchmark can assist. They’re industry-grounded guidelines that even include a scoring system for evaluating the security of your Kubernetes environment. Applying this manually could be a bit time-consuming – it’s a (free) downloadable PDF, and the most recent version (1.6) runs 271 pages long. Doing so once? Maybe. Doing so regularly? That’s less appealing. Enter kube-bench.

“Kube-bench is a very useful open source tool that runs checks on a Kubernetes cluster according to CIS Security Benchmark,” Vempati says. “It provides clear outputs for the checks, [including] whether they’ve passed or failed.”

Two other outputs are “Warn” (which indicates that closer inspection of a particular test is needed) and “Information” (which is exactly what it sounds like and requires no next steps.) Among other configuration options, you can choose to run kube-bench on a subset of benchmarks or against a particular version of Kubernetes. Regardless of configuration, the principle more or less remains the same: It’s another way to evaluate the security posture of your environment, this time against industry-accepted standards.

[ Get the free eBook: O'Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]

Kevin Casey writes about technology and business for a variety of publications. He won an Azbee Award, given by the American Society of Business Publication Editors, for his InformationWeek.com story, "Are You Too Old For IT?" He's a former community choice honoree in the Small Business Influencer Awards.

Social Media Share Icons