Skip to main content

Compute Resource Management

Pod Quality of Service

Quality of Service (QoS) in Kubernetes is a crucial concept that determines how resources are allocated and managed for pods. Puzl supports different QoS levels to cater to the varying requirements of containers.

In Kubernetes, QoS levels are based on the resource (RAM and CPU) requests and limits set for a container. More extensive explanation could be found in Kubernetes documentation.

Guaranteed

A Guaranteed QoS level means the pod has the same memory limit as its request and the same CPU limit as its request, ensuring stable resource allocation. Find the detailed example of the billing of such pods here.

Burstable

Pod has a Burstable QoS if it has memory limit higher than memory request, or it has CPU limit is higher than CPU request. Burstable pod can be terminated (evicted) if it consumes RAM over requested. The example of the Burstable pods' billing can be found here.

Shared or Exclusive CPU Cores

In Puzl's cloud environment, users have the flexibility to choose between shared or exclusive CPU cores based on their specific application needs. Shared cores are often suitable for less intensive tasks, while exclusive cores are recommended for high-performance requirements.

  • Puzl offers the option of selecting either shared or exclusive CPU cores to suit different computational needs.
  • Exclusive cores are allocated solely to your pod, ensuring no cross-socket traffic and optimal performance for intensive tasks.

To allocate exclusive CPU cores, you need to ensure that:

  1. Pod has a Guaranteed QoS.
  2. Requested CPU is an integer number.

Otherwise, shared CPU cores will be allocated.

note

Shared cores, while cost-effective, might experience performance drops in heavy L3 cache usage scenarios (in ResNet calculations, for example). In such cases, exclusive cores are advisable for maintaining performance efficiency.

Pod Statuses

In Puzl, these statuses provide insights into the lifecycle and current state of your pods, helping you to troubleshoot and manage your deployments more efficiently.

  • Pending: At this stage, the pod is awaiting the allocation of the requested resources.
  • Scheduled: Once the requested resources are allocated, the pod status changes to Scheduled, signifying that at least one of the pod's containers is in the process of downloading or extracting its Docker image. The compute resource billing is starting for the pod once it reached Scheduled status.
  • Running: This status means the pod is fully operational and functioning without any issues.
  • Succeeded: When all containers within a pod have completed their tasks successfully with an exit code of 0, the pod status is marked as Succeeded.
  • Failed: If at least one container within the pod finishes with a non-zero exit code, indicating an error or issue, the pod status is set to Failed.
  • Terminating: This status is shown when a request has been made to delete the pod.
  • Terminated: Finally, when the pod is completely deleted from the Kubernetes cluster, its status is updated to Terminated.

Virtual Machines

While Puzl primarily operates as a cloud-native platform, it also offers the flexibility of virtual machine creation. This capability aligns with traditional cloud services, allowing users to choose the most suitable environment for their applications.

  • Puzl supports the creation of virtual machines, providing a service comparable to classic cloud instances, VPS, or VDS offered by other providers.
  • The virtual machines in Puzl are based on KubeVirt, integrating seamlessly with Kubernetes environments.
  • Virtual machines are running as pods, so the rules of QoS and CPU cores allocation, described above, work for the VMs in the same way as for the plain pods.

Though virtual machines are available, Puzl advocates for a cloud-native approach, recommending running applications in Docker containers orchestrated via Kubernetes pods for optimal resource management and scalability.