Production-Grade Container Orchestration

FEATURE STATE: Kubernetes 1.34 [beta] A Kubernetes kuberc configuration file allows you to define preferences for kubectl, such as default options and command aliases. Unlike the kubeconfig file, a kuberc configuration file does not contain cluster details, usernames or passwords. The default location of this configuration file is $HOME/.kube/kuberc. To provide kubectl with a path to a custom kuberc file, use the --kuberc command line option, or set the KUBERC environment variable.

FEATURE STATE: Kubernetes v1.19 [stable] The scheduling framework is a pluggable architecture for the Kubernetes scheduler. It consists of a set of "plugin" APIs that are compiled directly into the scheduler. These APIs allow most scheduling features to be implemented as plugins, while keeping the scheduling "core" lightweight and maintainable. Refer to the design proposal of the scheduling framework for more technical information on the design of the framework.

This page outlines the differences in how resources are managed between Linux and Windows. On Linux nodes, cgroups are used as a pod boundary for resource control. Containers are created within that boundary for network, process and file system isolation. The Linux cgroup APIs can be used to gather CPU, I/O, and memory use statistics. In contrast, Windows uses a job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host.

FEATURE STATE: Kubernetes v1.22 [alpha] This document describes how to run Kubernetes Node components such as kubelet, CRI, OCI, and CNI without root privileges, by using a user namespace. This technique is also known as rootless mode. Note:This document describes how to run Kubernetes Node components (and hence pods) as a non-root user. If you are just looking for how to run a pod as a non-root user, see SecurityContext.

FEATURE STATE: Kubernetes v1.26 [stable] Starting from Kubernetes v1.20, the kubelet can dynamically retrieve credentials for a container image registry using exec plugins. The kubelet and the exec plugin communicate through stdio (stdin, stdout, and stderr) using Kubernetes versioned APIs. These plugins allow the kubelet to request credentials for a container registry dynamically as opposed to storing static credentials on disk. For example, the plugin may talk to a local metadata server to retrieve short-lived credentials for an image that is being pulled by the kubelet.

Define a range of valid CPU resource limits for a namespace, so that every new Pod in that namespace falls within the range you configure.

FEATURE STATE: Kubernetes v1.26 [stable] Kubernetes keeps many aspects of how pods execute on nodes abstracted from the user. This is by design. However, some workloads require stronger guarantees in terms of latency and/or performance in order to operate acceptably. The kubelet provides methods to enable more complex workload placement policies while keeping the abstraction free from explicit placement directives. For detailed information on resource management, please refer to the Resource Management for Pods and Containers documentation.

FEATURE STATE: Kubernetes v1.11 [beta] 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. By decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, the cloud-controller-manager component enables cloud providers to release features at a different pace compared to the main Kubernetes project.

This page shows how to enable or disable an API version from your cluster's control plane. Specific API versions can be turned on or off by passing --runtime-config=api/<version> as a command line argument to the API server. The values for this argument are a comma-separated list of API versions. Later values override earlier values. The runtime-config command line argument also supports 2 special keys: api/all, representing all known APIs api/legacy, representing only legacy APIs.