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. ]
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.
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? ]
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. ]
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.
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.
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.
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.
“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. ]
What to read next
Subscribe to our newsletter.
Keep up with the latest advice and insights from CIOs and IT leaders.