FEATURE STATE: Kubernetes v1.29 [stable] Controlling the behavior of the Kubernetes API server in an overload situation is a key task for cluster administrators. The kube-apiserver has some controls available (i.e. the --max-requests-inflight and --max-mutating-requests-inflight command-line flags) to limit the amount of outstanding work that will be accepted, preventing a flood of inbound requests from overloading and potentially crashing the API server, but these flags are not enough to ensure that the most important requests get through in a period of high traffic.

Define a default memory resource limit for a namespace, so that every new Pod in that namespace has a memory resource limit configured.

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

This page explains how to configure the kubelet's cgroup driver to match the container runtime cgroup driver for kubeadm clusters. Before you begin You should be familiar with the Kubernetes container runtime requirements. Configuring the container runtime cgroup driver The Container runtimes page explains that the systemd driver is recommended for kubeadm based setups instead of the kubelet's default cgroupfs driver, because kubeadm manages the kubelet as a systemd service.

Production-Grade Container Orchestration

Define a default CPU resource limits for a namespace, so that every new Pod in that namespace has a CPU resource limit configured.

A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by the control plane. Kubernetes v1.34 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 page describes running Kubernetes across multiple zones. Background Kubernetes is designed so that a single Kubernetes cluster can run across multiple failure zones, typically where these zones fit within a logical grouping called a region. Major cloud providers define a region as a set of failure zones (also called availability zones) that provide a consistent set of features: within a region, each zone offers the same APIs and services.

Manage security and best-practices with policies.

Synopsis Set a context entry in kubeconfig. Specifying a name that already exists will merge new fields on top of existing values for those fields. kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace] Examples # Set the user field on the gce context entry without touching other values kubectl config set-context gce --user=cluster-admin Options --cluster string cluster for the context entry in kubeconfig --current Modify the current context