When you specify a Pod, you can optionally specify how much of each resource a container needs. The most common resources to specify are CPU and memory (RAM); there are others. When you specify the resource request for containers in a Pod, the kube-scheduler uses this information to decide which node to place the Pod on. When you specify a resource limit for a container, the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set.

This task demonstrates running multiple Jobs based on a common template. You can use this approach to process batches of work in parallel. For this example there are only three items: apple, banana, and cherry. The sample Jobs process each item by printing a string then pausing. See using Jobs in real workloads to learn about how this pattern fits more realistic use cases. Before you begin You should be familiar with the basic, non-parallel, use of Job.

This page guides you through configuring Node overprovisioning in your Kubernetes cluster. Node overprovisioning is a strategy that proactively reserves a portion of your cluster's compute resources. This reservation helps reduce the time required to schedule new pods during scaling events, enhancing your cluster's responsiveness to sudden spikes in traffic or workload demands. By maintaining some unused capacity, you ensure that resources are immediately available when new pods are created, preventing them from entering a pending state while the cluster scales up.

This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.34.x to version 1.35.x, and from version 1.35.x to 1.35.y (where y > x). Skipping MINOR versions when upgrading is unsupported. For more details, please visit Version Skew Policy. To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: Upgrading a kubeadm cluster from 1.33 to 1.34 Upgrading a kubeadm cluster from 1.

Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using kubectl apply to recursively create and update those objects as needed. This method retains writes made to live objects without merging the changes back into the object configuration files. kubectl diff also gives you a preview of what changes apply will make. Before you begin Install kubectl. You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. A PersistentVolume (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a StorageClass. A PersistentVolumeClaim (PVC) is a request for storage by a user that can be fulfilled by a PV.

This tutorial shows you how to run Apache Cassandra on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application state). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. StatefulSets make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see StatefulSet. Note:Cassandra and Kubernetes both use the term node to mean a member of a cluster.

Note This tutorial applies only for new clusters. Pod Security is an admission controller that carries out checks against the Kubernetes Pod Security Standards when new pods are created. It is a feature GA'ed in v1.25. This tutorial shows you how to enforce the baseline Pod Security Standard at the cluster level which applies a standard configuration to all namespaces in a cluster. To apply Pod Security Standards to specific namespaces, refer to Apply Pod Security Standards at the namespace level.

This document describes persistent volumes in Kubernetes. Familiarity with volumes, StorageClasses and VolumeAttributesClasses is suggested. Introduction Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim. A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

A detailed look at the different policy levels defined in the Pod Security Standards.