Examining QoS in Action

Checking QoS with initial definition#

The output, limited to the relevant parts, is as follows.

The Pod was assigned Burstable QoS.

Its limits are different from requests, so it did not qualify for Guaranteed QoS.

Since its resources are set, and it is not eligible for Guaranteed QoS, Kubernetes assigned it the second best QoS.

Checking QoS with modified definition#

Now, let’s take a look at a slightly modified definition go-demo-2-qos.yml.

This time, we specified that both cpu and memory should have the same values for both the requests and the limits for the containers that will be created with the go-demo-2-db Deployment.

As a result, db Deployment should be assigned Guaranteed QoS.

The containers of the go-demo-2-api Deployment are void of any resources definitions.

api Deployment should be be assigned BestEffort QoS.

Applying the definition#

Let’s confirm that both assumptions (not to say guesses) are indeed correct.

We applied the new definition and output the rollout status of the go-demo-2-db Deployment.

Verification of db deployment#

Now we can describe the Pod created thought the go-demo-2-db Deployment and check its QoS.

The output, limited to the relevant parts, is as follows.

Memory and CPU limits and requests are the same and, as a result, the QoS is Guaranteed.

Verification of api deployment#

Let’s check the QoS of the Pods created through the go-demo-2-api Deployment.

The output, limited to the relevant parts, is as follows.

The three Pods created through the go-demo-2-api Deployment are without any resources definitions and, therefore, their QoS is set to BestEffort.

Destroying the objects#

We won’t be needing the objects we created so far so we’ll remove them before moving onto the next subject.

Try it yourself#

A list of all the commands used in the lesson is given below.