Legacy API for managing workloads that can scale horizontally. Superseded by the Deployment and ReplicaSet APIs.

Node Conformance Test Node conformance test is a containerized test framework that provides a system verification and functionality test for a node. The test validates whether the node meets the minimum requirements for Kubernetes; a node that passes the test is qualified to join a Kubernetes cluster. Node Prerequisite To run node conformance test, a node must satisfy the same prerequisites as a standard Kubernetes node. At a minimum, the node should have the following daemons installed:

Kubernetes supports running nodes on either Linux or Windows. You can mix both kinds of node within a single cluster. This page provides an overview to networking specific to the Windows operating system. Container networking on Windows Networking for Windows containers is exposed through CNI plugins. Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch).

This task outlines the steps needed to update your container runtime to containerd from Docker. It is applicable for cluster operators running Kubernetes 1.23 or earlier. This also covers an example scenario for migrating from dockershim to containerd. Alternative container runtimes can be picked from this page. Before you begin Note: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically.

This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.30.x to version 1.31.x, and from version 1.31.x to 1.31.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.29 to 1.30 Upgrading a kubeadm cluster from 1.

Synopsis Update environment variables on a pod template. List environment variable definitions in one or more pods, pod templates. Add, update, or remove container environment variable definitions in one or more pod templates (within replication controllers or deployment configurations). View or modify the environment variable definitions on all containers in the specified pods or pod templates, or just those that match a wildcard. If "--env -" is passed, environment variables can be read from STDIN using the standard env syntax.

This page shows how to build the Kubernetes component and tool reference pages. Before you begin Start with the Prerequisites section in the Reference Documentation Quickstart guide. Follow the Reference Documentation Quickstart to generate the Kubernetes component and tool reference pages. What's next Generating Reference Documentation Quickstart Generating Reference Documentation for kubectl Commands Generating Reference Documentation for the Kubernetes API Contributing to the Upstream Kubernetes Project for Documentation

This page shows you how to localize the docs for a different language. Contribute to an existing localization You can help add or improve the content of an existing localization. In Kubernetes Slack, you can find a channel for each localization. There is also a general SIG Docs Localizations Slack channel where you can say hello. Note:For extra details on how to contribute to a specific localization, look for a localized version of this page.

SIG Docs approvers take week-long shifts managing pull requests for the repository. This section covers the duties of a PR wrangler. For more information on giving good reviews, see Reviewing changes. Duties Each day in a week-long shift as PR Wrangler: Review open pull requests for quality and adherence to the Style and Content guides. Start with the smallest PRs (size/XS) first, and end with the largest (size/XXL). Review as many PRs as you can.

Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up cluster resources. This allows the clean up of resources like the following: Terminated pods Completed Jobs Objects without owner references Unused containers and container images Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete Stale or expired CertificateSigningRequests (CSRs) Nodes deleted in the following scenarios: On a cloud when the cluster uses a cloud controller manager On-premises when the cluster uses an addon similar to a cloud controller manager Node Lease objects Owners and dependents Many objects in Kubernetes link to each other through owner references.