This page shows how to connect to services running on the Kubernetes cluster. 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.

Production-Grade Container Orchestration

FEATURE STATE: Kubernetes v1.14 [stable] Pods can have priority. Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. Warning:In a cluster where not all users are trusted, a malicious user could create Pods at the highest possible priorities, causing other Pods to be evicted/not get scheduled.

Dynamic volume provisioning allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when users create PersistentVolumeClaim objects. Background The implementation of dynamic volume provisioning is based on the API object StorageClass from the API group storage.

This page describes security considerations and best practices specific to the Windows operating system. Protection for Secret data on nodes On Windows, data from Secrets are written out in clear text onto the node's local storage (as compared to using tmpfs / in-memory filesystems on Linux). As a cluster operator, you should take both of the following additional measures: Use file ACLs to secure the Secrets' file location. Apply volume-level encryption using BitLocker.

FEATURE STATE: Kubernetes v1.35 [stable](enabled by default) This page shows you how to configure dynamic resource allocation (DRA) in a Kubernetes cluster by enabling API groups and configuring classes of devices. These instructions are for cluster administrators. About DRA A Kubernetes feature that lets you request and share resources among Pods. These resources are often attached devices like hardware accelerators. With DRA, device drivers and cluster admins define device classes that are available to claim in workloads.

This page shows how to change the access mode on an existing PersistentVolume to use ReadWriteOncePod. 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 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 shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption. In Kubernetes 1.35 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).