This page shows how to configure liveness, readiness and startup probes for containers. For more information about probes, see Liveness, Readiness and Startup Probes The kubelet uses liveness probes to know when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs.

This page provides an overview of the steps you should follow to upgrade a Kubernetes cluster. The Kubernetes project recommends upgrading to the latest patch releases promptly, and to ensure that you are running a supported minor release of Kubernetes. Following this recommendation helps you to stay secure. The way that you upgrade a cluster depends on how you initially deployed it and on any subsequent changes. At a high level, the steps you perform are:

This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption. In Kubernetes 1.34 there are two versions of KMS at-rest encryption. You should use KMS v2 if feasible because KMS v1 is deprecated (since Kubernetes v1.28) and disabled by default (since Kubernetes v1.29). KMS v2 offers significantly better performance characteristics than KMS v1. Caution:This documentation is for the generally available implementation of KMS v2 (and for the deprecated version 1 implementation).

FEATURE STATE: Kubernetes v1.33 [beta] (enabled by default: true) This page explains how to change the CPU and memory resource requests and limits assigned to a container without recreating the Pod. Traditionally, changing a Pod's resource requirements necessitated deleting the existing Pod and creating a replacement, often managed by a workload controller. In-place Pod Resize allows changing the CPU/memory allocation of container(s) within a running Pod while potentially avoiding application disruption.

FEATURE STATE: Kubernetes v1.26 [beta] Before you begin You will need to have the following tools installed: cosign (install guide) curl (often provided by your operating system) jq (download jq) Verifying binary signatures The Kubernetes release process signs all binary artifacts (tarballs, SPDX files, standalone binaries) by using cosign's keyless signing. To verify a particular binary, retrieve it together with its signature and certificate: URL=https://dl.k8s.io/release/v1.34.0/bin/linux/amd64 BINARY=kubectl FILES=( "$BINARY" "$BINARY.sig" "$BINARY.

All of the APIs in Kubernetes that let you write persistent API resource data support at-rest encryption. For example, you can enable at-rest encryption for Secrets. This at-rest encryption is additional to any system-level encryption for the etcd cluster or for the filesystem(s) on hosts where you are running the kube-apiserver. This page shows how to enable and configure encryption of API data at rest. Note:This task covers encryption for resource data stored using the Kubernetes API.

This page shows you how to specify the type of cascading deletion to use in your cluster during garbage collection. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

This tutorial shows you how to run a sample app on Kubernetes using minikube. The tutorial provides a container image that uses NGINX to echo back all the requests. Objectives Deploy a sample application to minikube. Run the app. View application logs. Before you begin This tutorial assumes that you have already set up minikube. See Step 1 in minikube start for installation instructions. Note:Only execute the instructions in Step 1, Installation.

Kubernetes lets you use a public key infrastructure (PKI) to authenticate to your cluster as a client. A few steps are required in order to get a normal user to be able to authenticate and invoke an API. First, this user must have an X.509 certificate issued by an authority that your Kubernetes cluster trusts. The client must then present that certificate to the Kubernetes API. You use a CertificateSigningRequest as part of this process, and either you or some other principal must approve the request.

Synopsis Create a role with single rule. kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none] Examples # Create a role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods # Create a role named "pod-reader" with ResourceName specified kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod # Create a role named "foo" with API Group specified kubectl create role foo --verb=get,list,watch --resource=rs.