DOCSEARCHbyAlgolia
Submit Docs

Kubernetes Enhancements

repository·master·Indexed 26 days ago

https://github.com/kubernetes/enhancements

Central repository for tracking Kubernetes Enhancement Proposals (KEPs) and their lifecycle from Alpha to Stable. Includes documentation on API deprecation compliance using kubectl warnings, Prometheus metrics, and audit logs, as well as the StorageVersion API for managing encoding versions in High Availability (HA) API server deployments.

Tokens
116.3K
Snippets
137
Records
575
Agent score
86%

What's inside kubernetes-enhancements

  1. Overview of KEP-3659: ApplySet redesign for kubectl apply --prune

    master

    KEP-3659 proposes a redesign of the kubectl apply --prune functionality. The current alpha implementation of --prune has design flaws regarding performance, correctness, and UX. This KEP introduces a new implementation based on the concept of an ApplySet.

    An ApplySet is a low-level object grouping mechanism designed to be safer, more performant, and interoperable with other ecosystem tools. It aims to solve issues like object leakage, scalability problems, and difficulty using custom resources (CRDs) with pruning.

  2. Overview of KEP-4080: Generic Control Plane Staging Repositories

    master

    KEP-4080 proposes the creation of new staging repositories, tentatively named k/generic-controlplane, to factor out core functionality from kube-apiserver and kube-controller-manager. This allows developers to build reusable, kube-based control planes without needing to vendor the entire k/k repository.

    Key Features of k/generic-controlplane:

    • Modular Library: A customizable library for building working kube-based control planes.
    • Sample Binary: Provides a sample-generic-controlplane binary to demonstrate plumbing.
    • Resource Customization: Allows in-code customization of which native resources (e.g., secrets, configmaps, RBAC, admission webhooks) are served.
    • CRD Support: Optionally includes the ability to define resources via CustomResourceDefinition objects.
    • Delegation: Optionally supports delegating object handling to other servers via APIService objects.
    • Agnostic Architecture: Can be used in separate binaries or all-in-one binaries (similar to hyperkube or k3s patterns).

    Exclusions

    To maintain a clear separation of concerns, k/generic-controlplane does not include definitions for managing containerized workloads, such as:

    • nodes
    • pods
    • daemonsets
    • ingresses
    • services
    • persistentvolumes

  3. Overview of Headlamp Kubernetes UI

    master

    Headlamp is a Kubernetes user interface designed for flexibility and extensibility. It is being moved to the SIG UI to serve as a central hub for the CNCF community.

    Key Features

    • Plugin System: A robust system for customization and third-party integrations.
    • Deployment Modes: Supports both a Desktop application and an in-cluster web interface.
    • Technology Stack: Built using TypeScript, React, Material UI, Vite, and Go.
    • Capabilities: Includes multi-cluster support, a relational graph view of clusters, and easy setup for community plugins.

    Distribution Types

    • Headlamp (Default): Includes core Kubernetes UI functionality plus a set of pre-installed plugins intended for general users.
    • Headlamp Base: A minimal version containing only universally desired features. This is intended for developers and vendors who want to build custom UIs by adding their own plugins and branding.

  4. Overview of Contextual Logging (KEP-3077)

    master

    Contextual logging is a design pattern in Kubernetes that replaces the use of a global logger with a logr.Logger instance passed through functions via context.Context or as an explicit parameter. This approach builds upon structured logging principles.

    Key Capabilities

    • Key/Value Attachment: Callers can attach key/value pairs that are automatically included in all subsequent log messages within that context.
    • Component Identification: Add names to describe which component or operation triggered a log message.
    • Verbosity Control: Reduce the volume of log messages emitted by a callee by adjusting the verbosity level within the passed logger.
    • Decoupling: Third-party components using Kubernetes packages (like client-go) are no longer forced to use klog. They can use any implementation of logr.Logger.
    • Test Isolation: During unit testing, individual test cases can use their own logger instances to ensure log output is correctly associated with specific tests.

  5. Overview of KEP-2953: Kustomize plugin graduation

    master

    KEP-2953 proposes a convergence of Kustomize's various alpha extension mechanisms into a single feature driven by the Kubernetes Resource Model (KRM). The goal is to provide a unified story for plugin distribution, discovery, and trust, making Kustomize extensions suitable for full inclusion in kubectl kustomize.

    Key Terminology

    • KRM: Kubernetes Resource Model.
    • Plugin: Refers to both the program implementing a generator, transformer, or validator, and the KRM-style YAML configuration required to use it.
    • Plugin provider: The program that implements the plugin (e.g., a container, a script, or a Go program). This is analogous to a controller for a custom resource.
    • Plugin runtime: The substrate used to execute the plugin provider. Supported runtimes include container and exec.
    • Plugin config: The KRM-style YAML document that declares the desired state the plugin implements. It may specify the plugin provider to execute and the specification to follow.

  6. Overview of Out-of-Tree Azure Cloud Provider

    master
    The Azure cloud provider is transitioning from an in-tree implementation to an out-of-tree model. This involves moving the cloud-controller-manager and storage drivers into dedicated repositories to allow for independent development and releases. The goal is to provide a well-tested version of the cloud-controller-manager with feature parity to the original in-tree kube-controller-manager.

  7. Overview of KEP-6060: API Server Authentication to Admission Webhooks

    master

    KEP-6060 introduces a mechanism for kube-apiserver to authenticate itself to admission webhooks. Previously, kube-apiserver did not authenticate to webhooks by default, allowing any entity with network access to the webhook to potentially impersonate the API server (as demonstrated by CVE-2025-1974).

    To resolve this, the enhancement implements three core components:

    1. Webhook Authentication Clients: Updated to request service account tokens from kube-apiserver and present them to admission webhooks.
    2. Token Dispensing: kube-apiserver is updated to issue these tokens to authenticated and authorized principals.
    3. Token Verification Library: A new library for webhook maintainers to verify these tokens.

    The implementation augments the TokenRequest API to allow clients to request specific claims in the JWT token, and ensures tokens intended for admission webhooks are bound to a specific webhook configuration object (either validating or mutating).

  8. Overview of Out-of-Tree Credential Providers

    master

    This Kubernetes Enhancement Proposal (KEP) introduces a mechanism for using external, pluggable credential providers to obtain container image registry credentials. This replaces the legacy in-tree credential providers that relied on cloud provider-specific SDKs embedded directly within the Kubernetes core.

    By using this mechanism, Kubelet can obtain registry credentials from a cloud provider-specific binary instead of having the logic built into the Kubernetes binary itself. This supports the migration of cloud SDK usage out of the main Kubernetes tree.

  9. Overview of Storage Capacity Constraints for Pod Scheduling

    master

    This enhancement introduces a mechanism to track and expose storage capacity available via CSI drivers. This allows the Kubernetes scheduler to make informed decisions when scheduling pods that require ephemeral inline volumes or persistent volumes with delayed binding (WaitForFirstConsumer).

    By exposing capacity through a new API, the scheduler can reduce the frequency of pod scheduling failures caused by attempting to create volumes on nodes where the underlying storage system lacks sufficient capacity.

  10. Overview of Kubelet Tracing (KEP-2831)

    master
    KEP-2831 introduces distributed tracing to the kubelet to improve observability and troubleshooting of node-level interactions. The kubelet generates and exports spans using OpenTelemetry libraries in the OpenTelemetry format. This allows developers to monitor the path of requests through the kubelet, including interactions with the API server, the Container Runtime Interface (CRI), the Container Network Interface (CNI), and the Container Storage Interface (CSI).

  11. Overview of KEP-2906: Kustomize Function Catalog

    master
    KEP-2906 proposes a new API (kind) to improve the distribution and discovery of Kustomize functions. This mechanism is intended for use with Kustomization, Components, and Composition resources. It provides a standardized way to define collections of Kustomize functions and KRM-style configuration resources, allowing Kustomize to automate function usage and eliminate manual installation steps. The goal is to create a standard that other KRM-style transformer orchestrators (like KPT) can also adopt.

  12. Overview of KEP-3037: Client-go Alternative Services

    master

    KEP-3037 proposes an enhancement to client-go to support High Availability (HA) for Kubernetes clusters without requiring external load balancers or Services abstractions for bootstrapping.

    Currently, HA clusters rely on external load balancers or Services (like kubernetes.default) to distribute traffic among multiple control-plane nodes. This creates a 'chicken and egg' problem for components like kube-proxy, kubenet, and in-cluster clients that depend on the very networking services they are trying to bootstrap.

    This feature allows API servers to announce a list of available control-plane nodes to clients via Alt-Svc headers, enabling client-go to connect to multiple nodes directly.