Kubernetes is designed to function like a black box, regardless of the deployment environment or the Kubernetes version being used. In reality, Kubernetes can operate very differently across deployments, even when the same Kubernetes version is employed. This discrepancy highlights the need for smoke tests, which enables the swift identification of issues.
Being able to perform a production-equivalent smoke test is a critical part of deploying with confidence to Kubernetes clusters across different cloud providers or with newer Kubernetes versions. Smoke testing verifies that a Kubernetes cluster is functioning as expected after a new deployment or upgrade. It reduces downtime risks and ensures reliable deployment by identifying potential issues early on.
Smoke testing typically involves running a comprehensive deployment on a new target cluster to ensure essential components such as the Kubernetes API server, etcd datastore, and worker nodes are operational and can communicate with each other. The tests may include verifying the creation, scheduling, and scaling of Kubernetes resources such as pods, services, and deployments, as well as validating the correct functioning of cluster networking components. Smoke testing is commonly integrated into a CI/CD pipeline to ensure the health and operational status of Kubernetes clusters before deploying new applications or updates.
In this article, we explore various scenarios where smoke tests should be baked into the process. We will discuss the typical requirements for setting up smoke tests and how teams can streamline the smoke testing process with CAEPE™.
Common Smoke Testing Scenarios
New deployments / Different Kubernetes environments
The first scenario to consider is when you want to make sure any new deployments work well before you deploy them in a like cluster. For example, you are doing development in a local cluster or a dev cluster like K3s or K3D on your local machine and you move the application to a company self-hosted Rancher cluster, but your final target destination cluster is something more production focused such as a managed service such as Azure Kubernetes Service (AKS) or Amazon Elastic Kubernetes Service (EKS).
This is a common scenario, especially when organizations are concerned with managing costs of the cloud-based clusters. Smoke tests in these situations ensures things are working well in different environments.
Cloud provider migration / Kubernetes version upgrade
Another scenario is when you are moving Kubernetes-based applications to a different cloud provider or a newer version of Kubernetes. You want to check that your actual running configuration: the actual data and the way that things run in production for you, run that same way in that new provider.
Many teams tend to work with a set of “dummy data”. They load up and test databases and fake user data in the production-like environment or new cluster. Initially, everything looks great, but that sample data does not adequately capture the true reality of what is required by your production cluster.
Smoke testing with actual production data in that scenario is vital to ensuring the new environment can support existing production needs.
For example, if your application has a database with a massive amount of data and is expected to process many transactions, when you load in your dummy data, it may not have the same transactional footprint, and so if you have not properly scoped your new configuration or your new cluster, whether it be your disk speed or your network configuration on your hosts, or any of those kind of things, then you could potentially see unexpected issues where it may work, but it might be a lot slower than it should be. This is just one of the use cases where smoke tests with actual production data would be highly valuable.
Major change within your application
Another scenario where smoke testing could save some heartache is when there is a major change within your application. In this case, you are not testing the target but testing your source against a new target and you are not quite ready to push it to production yet.
You have these brand-new features and this major upgraded version that you are about ready to roll out. You want to deploy this on another cluster first that looks just like your production cluster. That is another important reason to smoke test – you are smoke testing your application to see if there might be a fire in the future.
How Smoke Testing for Kubernetes Clusters is Typically Set Up
Here is what setting up Smoke Testing for Kubernetes clusters typically entails:
Setting this up may not be outside the capabilities of your team, but rather it may be outside of the time that they have in a day and on top of all the other daily tasks they have on hand.
Smoke Test Your Applications With CAEPE – It Takes Minutes
That is why we built smoke testing as an end-to-end feature in CAEPE – to help the operators / administrators of your system save time for other higher value work. By our estimates, the manual work required to set up smoke tests could take up to a day of an experienced DevOps engineer’s time. With CAEPE, the process takes minutes.
CAEPE does not deploy clusters on its own. Rather, CAEPE will take your deploy automation and predefined infrastructure as code and use that to deploy new clusters. At the same time, CAEPE builds in knowledge of all your code, Docker and container image repositories. From CAEPE’s user-friendly interface, you can easily execute a smoke test and then easily move into User Acceptance Testing or even Production, if you have confirmed that it is working as expected.
Let’s see how this works in CAEPE:
In conclusion, smoke testing plays a vital role in ensuring the reliability and functionality of Kubernetes deployments. By verifying the proper functioning of essential components and validating cluster networking, smoke tests help identify potential issues early on and reduce downtime risks. I have highlighted common scenarios where smoke testing is crucial, such as new deployments, cloud provider migration, Kubernetes version upgrades, and major changes within applications.
To streamline the smoke testing process, I have provided an overview of how CAEPE simplifies smoke testing setup and execution, saving a lot of time for operators and administrators. With CAEPE’s user-friendly interface and repository integration, performing smoke tests and transitioning to UAT and production will be much easier and more efficient.
CAEPE Continuous Deployment
Manage workloads on Kubernetes anywhere robustly and securely.
- Shores up security by simplifying deployment anywhere, supporting managed services, native Kubernetes, self-hosted, edge and secure airgapped deployment targets.
- Supports GitOps and provides guided, UI-driven workflows for all major progressive delivery strategies.
- Has RBAC built-in, providing inherent enterprise access control for who can deploy.
- Supports extended testing capabilities enabling your team to run different tests quickly and easily.
Mike Johnson
Solution Architect, CAEPE
Mike “MJ” Johnson has over 20+ years of experience working across areas such as DevOps, DevSecOps, Cloud & IT System Administration. He has extensive experience implementing systems with Docker, Kubernetes and platforms such as ECR, AKS and GKE. As a Solution Architect with CAEPE, he is excited to work with customers on ensuring their enterprise DevOps roadmaps become a reality.
