Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# Allocating excessive memory
Let's explore another possible situation through yet another updated definition `go-demo-2-insuf-node`. Just as before, the change is only in the `resources` of the `go-demo-2-db` Deployment. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-2-db
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: db
        image: mongo:3.3
        resources:
          limits:
            memory: 8Gi
            cpu: 0.5
          requests:
            memory: 12Gi
            cpu: 0.3

This time we specify that the requested memory is twice as much as the total memory of the node (6GB). The memory limit is even higher.




## Applying the definition
Let's apply the change and observe what happens.

kubectl apply \
    -f go-demo-2-insuf-node.yml \
    --record

kubectl get pods

The output of the latter command is as follows:

NAME              READY STATUS  RESTARTS AGE
go-demo-2-api-... 1/1   Running 0        8m
go-demo-2-api-... 1/1   Running 0        8m
go-demo-2-api-... 1/1   Running 0        9m
go-demo-2-db-...  0/1   Pending 0        13s



This time, the status of the Pod is "Pending". Kubernetes could not place it anywhere in the cluster and is waiting until the situation changes.

Even though memory requests are associated with containers, it often makes sense to translate them into Pod requirements. We can say that the requested memory of a Pod is the sum of the requests of all the containers that form it. In our case, the Pod has only one container, so the requested memory for the Pod and the container are equal. The same can be said for limits.

During the scheduling process, Kubernetes sums the requests of a Pod and looks for a node that has enough available memory and CPU. If Pod's request cannot be satisfied, it is placed in the pending state in the hope that resources will be freed on one of the nodes or that a new server will be added to the cluster. Since such a thing will not happen in our case, the Pod created through the `go-demo-2-db` Deployment will be pending forever unless we change the memory request again.

> **Note:**  When Kubernetes cannot find enough free resources to satisfy the resource requests of all the containers that form a Pod, it changes its state to `Pending`. Such Pods will remain in this state until the requested resources become available.

## Looking into the Deployment's description
Let's describe the `go-demo-2-db` Deployment and see whether there is some additional useful information in it.



Explore what happens when we allocate excessive resources than required by an application.


Allocating Excessive Resources

Explore what happens when we allocate excessive resources than required by an application.

Allocating Excessive Resource than the Actual Usage

Allocating excessive memory