ee--- date: 2021-04-09, 2022-07-08 --- %% date:: [[2023-04-25]] parent:: %% # [[Testing Kubernetes]] [[Software Testing|Testing]] an application on a [[Kubernetes]] cluster comes with benefits and concerns that differentiate it from testing more traditional architectures. In most ways, testing an application on k8s is similar to [[Testing microservices]]. However, on this page are some concepts unique to Kubernetes deployments. ## Benefits of Kubernetes for testers ### Test environment management Kubernetes manifest files make it easy to spin up test environments virtually, reducing conflict and contention for environments by different teams. Being able to provision environments also makes it easier for developers to reproduce defects reported by testers. ### Tester empowerment Kubernetes decentralizes applications while centralizing information. That is, Kubernetes makes it easier to create replicas of environments by putting all the instructions necessary to create them into manifest files. Knowledge of how to use Kubernetes can be a very powerful tool for testers, who can suddenly experiment and test in their own environments without needing help from application or operations teams. ## Types of tests to run against a Kubernetes cluster ### [[Static testing]] Testing Kubernetes by necessity involves static testing of the Kubernetes manifest files in addition to the typical end-to-end testing activities. It can be advantageous to look at the manifest files _first_, as they describe the way that the application will be built. Here are a few things to consider when reviewing manifest files: - Do resource limits need to be put into place for pods? Resource limits set the bounds for acceptable resource utilization, because otherwise, it's possible for a pod to be technically available but operationally failing. - Are affinity/anti-affinity rules set up for redundancy? Replicas of pods do not protect against node failure if both replicas are on the same node. - Security considerations: are there endpoints that are exposed to the public that shouldn't be? - Are there replicas set up for all critical components? Kubernetes offloads a lot of the manual deployment steps to manifest files, so it can be beneficial to review the files to make sure that it's being configured correctly before those files are applied to a cluster. ### [[Operational testing]] The ease of environment provisioning also encourages nontraditional types of testing. More "destructive" test types like [[Chaos Engineering]] are easier to carry out when teams know there's a way of rebuilding the environment if they need to. [[kind]] is a way to run Kubernetes clusters within [[Docker]] [[Containerization|containers]] with the goal of testing Kubernetes. When carrying out any type of testing, [[Monitoring Kubernetes]] is important. ## References [^testproj]: Dey (2021). _The fundamentals of Kubernetes and its value for testing._ Accessed in April 2021 from [TestProject](https://blog.testproject.io/2021/02/23/the-fundamentals-of-kubernetes-and-its-value-for-testing/).