STRESS

A stress command is a tool for generating workloads and stress tests on a Linux system. It can be used to simulate high CPU, memory, and I/O usage to test the stability and performance of the system.

Installation:

I am using the free CentOS version in my lab, so change the commands according to your distribution. Switch to the root user from the normal user in the Linux box and follow the below process.

yum install stress -y

After this, we have to find the number of cores inside the Linux operating system. To fetch the core information from the Linux operating system, use the below command, as shown below:

cat /proc/cpuinfo | grep processor | wc -l

/proc/cpuinfo = related to the CPU information.

grep processor = search for the processor in the file.

wc -l = number of word lines counted in the file.

Without a timeout, use the below command, as shown below:

stress --cpu 4 --io 2 --vm 2 --vm-bytes 512M

--cpu 4 will stress 4 CPUs at 100% load.

--io 2 will generate two I/O operations per worker thread.

--vm 2 will create two worker threads for stressing the memory.

--vm-bytes 512M will allocate 512 megabytes of memory per worker thread.

To check the command output, go into the duplication of the same server and check the top command as shown below:

top

If you want to check with the timeout option, use the below command as shown below:

stress --cpu 4 --io 2 --vm 2 --vm-bytes 512M --timeout 60s

Again, check with the top command, as shown below:

Therefore, the stress here is applied successfully in Linux. Now we will continue through the Kubernetes part.

Kubernetes

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.

Kubernetes provides a way to manage containerized applications across multiple hosts. It does this by providing a set of abstractions that allow you to define how your applications should be deployed and scaled. For example, you can use Kubernetes to define how many replicas of an application should be running, or how to distribute those replicas across different hosts.

Kubernetes also provides several features that make it easy to manage your applications. For example, it can automatically restart containers that fail, or scale your applications up or down based on demand.

Install the Kubernetes cluster and follow the below process.

Why stress in Kubernetes pod?

We can use stress in the Kubernetes pod manifest file to stress test our applications. Stress is a tool that can be used to generate loads on a system. It can be used to test the performance of our applications under load.

Now we will go through how we can create stress in Kubernetes by targeting a specific pod that is hosting an application.

First of all, create the target manifest yaml file as shown below:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-stress
spec:
  containers:
  - name: nginx
    image: ubuntu/nginx
    ports:
    - containerPort: 80
  - name: stress
    image: progrium/stress
    command: ["stress", "--cpu", "2", "--io", "1", "--vm", "1", "--vm-bytes", "128M", "--timeout", "60s"]

These manifest files are in YAML format, so try to follow the format as shown above and save them as a file with your comfortable name and the extension stress.yaml

kubectl apply -f stress.yaml

kubectl get all --all-namespaces

As you can see in the above output, the nginx-stress pod is running successfully, whatever the yaml file we have created.

Now we are trying to see the pod functionality by using the below command

kubectl describe pod/nginx-stress -n default

Here we have applied two containers in one pod, like the Nginx and stress containers in manifest stress. After applying the file, the pod is created and running successfully.

Due to the stress involved in the manifest file, the pod is automatically going down.

Check if there are any events related to the pod that indicates stress or errors, such as CrashLoopBackOff, Failed, or Error. This is an indication that our stress commands are working successfully.

kubectl get pods

We have created a stress manifest and nginx file with a timeout of 60 seconds, so it is randomly running for 60 seconds and getting down for 60 seconds, as shown in the above images. If you observe the above output due to stress, it was varying.

The stress here is applied successfully.