Production-Grade Container Orchestration

Synopsis Check whether an action is allowed. VERB is a logical Kubernetes API verb like 'get', 'list', 'watch', 'delete', etc. TYPE is a Kubernetes resource. Shortcuts and groups will be resolved. NONRESOURCEURL is a partial URL that starts with "/". NAME is the name of a particular Kubernetes resource. This command pairs nicely with impersonation. See --as global flag. kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] Examples # Check to see if I can create pods in any namespace kubectl auth can-i create pods --all-namespaces # Check to see if I can list deployments in my current namespace kubectl auth can-i list deployments.

FEATURE STATE: Kubernetes v1.35 [alpha](disabled by default) Every pod group defined in a Workload must declare a scheduling policy. This policy dictates how the scheduler treats the collection of Pods. Policy types The API currently supports two policy types: basic and gang. You must specify exactly one policy for each group. Basic policy The basic policy instructs the scheduler to treat all Pods in the group as independent entities, scheduling them using the standard Kubernetes behavior.

A Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain state.

The Kubernetes API lets you query and manipulate the state of objects in Kubernetes. The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server.

This page provides an overview of available configuration options and best practices for cluster multi-tenancy. Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing noisy neighbors. Clusters can be shared in many ways. In some cases, different applications may run in the same cluster. In other cases, multiple instances of the same application may run in the same cluster, one for each end user.

This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with Volumes is suggested. Introduction The CSI Volume Cloning feature adds support for specifying existing PVCs in the dataSource field to indicate a user would like to clone a Volume. A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume.

FEATURE STATE: Kubernetes v1.35 [alpha](disabled by default) Kubernetes nodes use declared features to report the availability of specific features that are new or feature-gated. Control plane components utilize this information to make better decisions. The kube-scheduler, via the NodeDeclaredFeatures plugin, ensures pods are only placed on nodes that explicitly support the features the pod requires. Additionally, the NodeDeclaredFeatureValidator admission controller validates pod updates against a node's declared features. This mechanism helps manage version skew and improve cluster stability, especially during cluster upgrades or in mixed-version environments where nodes might not all have the same features enabled.

An overview of the Pod Security Admission Controller, which can enforce the Pod Security Standards.

FEATURE STATE: Kubernetes v1.27 [beta] System component traces record the latency of and relationships between operations in the cluster. Kubernetes components emit traces using the OpenTelemetry Protocol with the gRPC exporter and can be collected and routed to tracing backends using an OpenTelemetry Collector. Trace Collection Kubernetes components have built-in gRPC exporters for OTLP to export traces, either with an OpenTelemetry Collector, or without an OpenTelemetry Collector. For a complete guide to collecting traces and using the collector, see Getting Started with the OpenTelemetry Collector.