Lower-level detail relevant to creating or administering a Kubernetes cluster.

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. To add a project to this list, read the content guide before submitting a change. More information. This page shows you how to migrate your Docker Engine nodes to use cri-dockerd instead of dockershim. You should follow these steps in these scenarios: You want to switch away from dockershim and still use Docker Engine to run containers in Kubernetes.

This page contains information about the kubernetes.io analytics dashboard. View the dashboard. This dashboard is built using Google Looker Studio and shows information collected on kubernetes.io using Google Analytics 4 since August 2022. Using the dashboard By default, the dashboard shows all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more.

In Kubernetes, some objects are owners of other objects. For example, a ReplicaSet is the owner of a set of Pods. These owned objects are dependents of their owner. Ownership is different from the labels and selectors mechanism that some resources also use. For example, consider a Service that creates EndpointSlice objects. The Service uses labels to allow the control plane to determine which EndpointSlice objects are used for that Service.

This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters. You can set up an HA cluster: With stacked control plane nodes, where etcd nodes are colocated with control plane nodes With external etcd nodes, where etcd runs on separate nodes from the control plane You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.

A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by the control plane. Kubernetes v1.32 supports clusters with up to 5,000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet all of the following criteria: No more than 110 pods per node No more than 5,000 nodes No more than 150,000 total pods No more than 300,000 total containers You can scale your cluster by adding or removing nodes.

This document catalogs the communication paths between the API server and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider). Node to Control Plane Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminates at the API server.

FEATURE STATE: Kubernetes v1.11 [beta] Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds. Kubernetes believes in automated, API-driven infrastructure without tight coupling between components. The cloud-controller-manager is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

Production-Grade Container Orchestration

Kubernetes volumes provide a way for containers in a pod to access and share data via the filesystem. There are different kinds of volume that you can use for different purposes, such as: populating a configuration file based on a ConfigMap or a Secret providing some temporary scratch space for a pod sharing a filesystem between two different containers in the same pod sharing a filesystem between two different pods (even if those Pods run on different nodes) durably storing data so that it stays available even if the Pod restarts or is replaced passing configuration information to an app running in a container, based on details of the Pod the container is in (for example: telling a sidecar container what namespace the Pod is running in) providing read-only access to data in a different container image Data sharing can be between different local processes within a container, or between different containers, or between Pods.