Kubernetes 1.26 - (Electrifying): What changes for production

Kubernetes 1.26, Electrifying, delivers 37 enhancements: 11 graduating to Stable, 10 to Beta, and 16 entering Alpha. Its official theme and release logo recognize the distributed computing resources and community effort behind Kubernetes while highlighting the growing importance of energy consumption and environmental sustainability in software systems (release announcement ).

Operationally, this release advances CSI migration, Windows HostProcess containers, scheduling controls, admission policy, resource allocation, and observability. It also introduces consequential upgrade requirements: Kubernetes 1.26 images are published exclusively through registry.k8s.io, and kubelets now require a container runtime that supports CRI v1.

Key highlights and graduations

Release architecture and distribution

registry.k8s.io becomes exclusive for Kubernetes 1.26

Kubernetes 1.26 is the first release published exclusively through the registry.k8s.io container image registry. No Kubernetes 1.26 image tags are published to the legacy k8s.gcr.io registry; only tags for releases before 1.26 continue to be updated there.

Production impact: clusters, mirrors, admission policies, firewalls, proxy allowlists, and installation automation must permit access to registry.k8s.io. Environments that hard-code k8s.gcr.io should be reviewed before upgrading.

Storage

Stable: vSphere in-tree to CSI migration

Migration from the in-tree vSphere storage driver to CSI is Stable in Kubernetes 1.26.

Production impact: vSphere operators can rely on the Stable migration capability while moving away from the in-tree integration. Driver compatibility and deployment-specific migration steps should still be validated against the storage provider before upgrading.

Stable: Azure File in-tree to CSI migration

Migration from the in-tree Azure File driver to CSI is also Stable.

Production impact: Azure File users should align their clusters with the CSI-based implementation and verify that the required CSI components are available before moving workloads dependent on the in-tree driver.

Stable: delegation of fsGroup to CSI drivers

Kubernetes can now supply a Pod’s fsGroup to a CSI driver when mounting a volume. A supporting CSI driver can apply the setting during attach or mount, including through mount options, instead of requiring the kubelet to perform ownership and permission changes after mounting.

Previously, the kubelet applied the requested ownership and permission changes according to .spec.securityContext.fsGroupChangePolicy.

Production impact: capable CSI drivers can handle volume permissions more efficiently or in a storage-specific manner. Operators should confirm driver support and test permission behavior before changing existing workload assumptions.

Node and workload management

Stable: Windows HostProcess containers

Support for Windows privileged containers, known as HostProcess containers, is Stable. These containers can access host resources, including network resources, with privileges similar to processes running directly on the Windows host.

Production impact: HostProcess containers enable host-level management and networking workloads on Windows nodes. Because they receive extensive host access, their images, identities, admission controls, and deployment permissions require careful security review.

Stable: Job tracking without lingering Pods

Job tracking without lingering Pods graduated to Stable.

Production impact: this is a Stable workload-management capability in 1.26. The supplied release excerpt does not describe its detailed behavior or migration considerations, so operators relying on Job cleanup semantics should verify them in the official changelog .

Stable: kubelet credential provider

The kubelet credential provider capability graduated to Stable.

Production impact: production use no longer depends on a pre-Stable feature designation. Existing credential-provider integrations should nevertheless be tested as part of worker-node upgrades.

Stable: CPUManager and DeviceManager improvements

The release announcement lists CPUManager and DeviceManager among the Stable graduations.

Production impact: the supplied excerpts do not specify the exact behavior that graduated. Clusters using CPU pinning, device plugins, or specialized hardware should review the complete 1.26 changelog before changing feature gates or node policies.

Alpha: Dynamic Resource Allocation

Dynamic Resource Allocation introduces an alternative to the existing countable resource interface, such as requesting nvidia.com/gpu: 2. It provides an API model closer to persistent volumes and allows third-party developers to participate in resource scheduling. Device injection uses the Container Device Interface.

The capability is controlled by the DynamicResourceAllocation feature gate.

Production impact: this Alpha feature is relevant to accelerators and other specialized devices that need richer allocation semantics. Treat it as experimental and validate the supporting runtime, drivers, and resource integrations outside production.

Networking and Services

Stable: Service internal traffic policy

Service Internal Traffic Policy graduated to Stable.

Production impact: the feature has reached Stable status, but the supplied source excerpt does not provide its exact configuration or behavior. Validate existing Service policies against the complete release notes before changing production routing.

Stable: mixed protocols for LoadBalancer Services

Support for mixed protocols in Services with type=LoadBalancer graduated to Stable.

Production impact: clusters can use the Stable capability where the relevant networking and load-balancer implementation supports it. Cloud-provider and load-balancer compatibility still requires deployment-specific verification.

Stable: reserving Service IP ranges for dynamic and static allocation

The capability to reserve Service IP ranges for dynamic and static IP allocation graduated to Stable.

Production impact: this can improve coordination between dynamically and statically allocated Service addresses. The exact configuration and operational procedure are not included in the supplied excerpts and should be checked in the full release notes.

Scheduling

Beta: node inclusion policy for Pod topology spread

NodeInclusionPolicyInPodTopologySpread graduated to Beta. A nodeInclusionPolicy in topologySpreadConstraints can control whether taints and tolerations are considered when Kubernetes calculates topology-spread skew.

Production impact: operators gain more control over how eligible nodes affect topology distribution. Existing scheduling behavior should be tested before applying the policy broadly.

Alpha: Pod scheduling readiness

PodSchedulingReadiness introduces .spec.schedulingGates in the Pod API. External users and controllers can use scheduling gates to hold a Pod out of scheduling until policy-specific prerequisites have been satisfied.

Production impact: controllers can prevent premature scheduling instead of allowing Pods to enter repeated scheduling attempts before external resources or decisions are ready. As an Alpha feature, it should be evaluated cautiously and kept out of critical production paths unless the associated risks are accepted.

Security and software supply chain

Beta: signed Kubernetes release artifacts

Signing of Kubernetes release artifacts graduated to Beta. Kubernetes release artifacts are signed keylessly using cosign, and both binaries and container images can be verified.

Production impact: platform teams can add provenance verification to artifact-promotion and image-mirroring workflows. Organizations should define how signature verification integrates with their own release controls before making it an enforcement requirement.

Alpha: CEL-based admission control

Kubernetes 1.26 introduces a v1alpha1 API for validating admission policies using Common Expression Language expressions. The feature provides in-process policy evaluation as an alternative to some policies implemented through admission webhooks.

Using it requires:

• the ValidatingAdmissionPolicy feature gate; and
• the admissionregistration.k8s.io/v1alpha1 API enabled through --runtime-config.

Production impact: CEL policies can reduce reliance on an external webhook for suitable validation use cases. However, both the API and feature are Alpha in 1.26; policy authors should expect change and should not assume production stability.

Architecture and observability

Alpha: metrics framework extension

The metrics framework extension entered Alpha. It adds Internal and Beta metadata fields to Kubernetes metrics, representing metric maturity stages. Documentation is also published for metrics in the Kubernetes codebase.

Production impact: monitoring teams can make more informed decisions about which metrics are suitable for durable dashboards and alerts. Alpha or internal metrics should not be treated as stable interfaces.

Alpha: component health SLIs

Component health Service Level Indicators entered Alpha. Enabling the ComponentSLIs feature gate adds a metrics endpoint that exposes health-check data in metric form, allowing Service Level Objectives to be calculated from that data.

Production impact: operators can evaluate control-plane and component health through SLI-oriented telemetry. Endpoint availability and metric stability remain Alpha considerations.

Feature-gate metrics

Each Kubernetes component exposes feature metrics that allow operators to determine whether active feature gates are enabled. The relevant metric is:

kubernetes_feature_enabled

Production impact: platform teams can use component metrics to detect unintended feature-gate drift across clusters or component replicas.

Graduation summary

The release announcement identifies these 11 Stable enhancements:

1. Windows privileged, or HostProcess, containers
2. vSphere in-tree to CSI driver migration
3. Supplying a Pod’s fsGroup to a CSI driver during mount
4. Azure File in-tree to CSI driver migration
5. Job tracking without lingering Pods
6. Service Internal Traffic Policy
7. Kubelet Credential Provider
8. Mixed protocols in Services with type=LoadBalancer
9. Reserving Service IP ranges for dynamic and static allocation
10. CPUManager
11. DeviceManager

Although the release contains 10 Beta and 16 Alpha enhancements in total, the supplied excerpts do not enumerate all of them. Only explicitly supported graduations are described here; consult the official Kubernetes 1.26 changelog for the complete inventory.

Deprecations, removals, and breaking changes

Kubernetes 1.26 deprecates or removes 12 features. Several are direct upgrade blockers and require action before control-plane or worker-node rollout.

Removed: CRI v1alpha2

Kubernetes 1.26 removes support for the deprecated Container Runtime Interface v1alpha2. The kubelet must negotiate CRI v1 with the node’s container runtime.

If the runtime does not support CRI v1, the kubelet will not register the node.

For containerd, this means:

• containerd 1.5 and older are not supported by Kubernetes 1.26;
• containerd must be upgraded to version 1.6.0 or later before upgrading the node.

The same requirement applies to any other runtime that supports only CRI v1alpha2. Operators should obtain migration guidance from the runtime vendor where necessary.

Removed API: flow control v1beta1

The v1beta1 flow control API group is removed.

Operator action: inventory manifests, clients, operators, and automation that use this API before upgrading the API server. The supplied excerpts do not identify the exact replacement API version, so the migration target must be confirmed manually from the full 1.26 changelog and Kubernetes documentation .

Removed API: HorizontalPodAutoscaler v2beta2

The v2beta2 HorizontalPodAutoscaler API is removed.

Operator action: update stored manifests, deployment templates, generators, clients, and controllers that still submit HPA resources through v2beta2. The supplied excerpts do not state the replacement API version; verify the supported target in the official changelog and documentation rather than assuming one.

Removed: in-tree GlusterFS driver

The in-tree GlusterFS driver, which was already deprecated in Kubernetes 1.25, is removed in 1.26.

Operator action: identify PersistentVolumes, StorageClasses, and automation that depend on the in-tree GlusterFS integration. A supported migration destination is not specified in the supplied sources and requires manual verification before upgrading.

Removed: in-tree OpenStack Cinder integration

The deprecated in-tree OpenStack storage integration for the cinder volume type is removed.

The documented migration direction is to use the external OpenStack cloud provider and CSI driver from cloud-provider-openstack .

Operator action: migrate affected storage workloads before upgrading. Confirm that external cloud-provider and CSI components are installed, configured, and tested.

Removed: in-tree OpenStack cloud provider

The in-tree OpenStack cloud provider is removed separately from the Cinder storage integration.

Operator action: migrate to the external OpenStack cloud provider before the control plane is upgraded. The supplied excerpt does not provide flags or a complete procedure, so deployment-specific instructions must be verified manually.

Removed: kube-proxy userspace modes

The kube-proxy userspace modes are removed.

Operator action: inspect kube-proxy configuration for reliance on a userspace mode and migrate before rollout. The supplied source does not enumerate the exact removed values or replacement configuration.

Removed: dynamic kubelet configuration

Dynamic kubelet configuration is removed.

Operator action: identify node-management processes that depend on dynamically delivered kubelet configuration and replace that workflow before worker upgrades. No exact replacement procedure is included in the supplied excerpts.

Removed: in-tree credential management code

In-tree credential management code is removed.

Operator action: review image-pull and node credential integrations, especially where a legacy in-tree implementation may still be assumed. The release announcement does not enumerate the removed providers or configuration keys, so the exact impact requires verification in the complete changelog.

Removed: legacy logging command-line arguments

Legacy command-line arguments related to logging are removed.

Operator action: audit component startup arguments and static Pod manifests. The supplied release excerpt does not list the individual flags, so their exact names must be confirmed in the v1.26.0 deprecation and urgent-upgrade sections of the official changelog .

Deprecated: non-inclusive kubectl flag

A non-inclusive kubectl flag is deprecated.

Operator action: review scripts and user workflows after consulting the full release notes. The exact flag is not named in the supplied excerpts and is intentionally not inferred here.

Deprecated: kube-apiserver command-line arguments

Some kube-apiserver command-line arguments are deprecated.

Operator action: compare current API server arguments with the complete 1.26 release notes. Exact flag names and replacements are not available in the supplied excerpts.

Deprecated: kubectl run command-line arguments

Some kubectl run command-line arguments are deprecated.

Operator action: inspect scripts, CI pipelines, and operational runbooks that invoke kubectl run. Confirm the exact affected flags and migration syntax in the official changelog before modifying automation.

Upgrade impact and operational notes

1. Read the complete v1.26.0 upgrade notes

The official changelog contains dedicated v1.26.0 sections for urgent upgrade notes, deprecations, API changes, features, regressions, and dependency changes. Review those sections against the exact patch release you plan to deploy:

• Kubernetes 1.26 changelog
• Kubernetes 1.26.0 GitHub release

The supplied changelog is truncated and also contains later 1.26 patch releases. Deployment-specific issues not covered in this article require manual review.

2. Audit removed APIs before the control-plane upgrade

Search manifests, Helm templates, GitOps repositories, controllers, and generated clients for:

flow control v1beta1
HorizontalPodAutoscaler v2beta2

The supplied sources do not provide a verified discovery command or replacement API versions, so use the API-auditing method approved for your environment and confirm migration targets in the official documentation.

Any component that continues to submit a removed API after the API server upgrade can fail. Complete API migration before upgrading the control plane.

3. Validate the image-registry transition

Ensure every environment involved in installation or operation can retrieve Kubernetes 1.26 images from:

registry.k8s.io

Review:

• registry mirrors and pull-through caches;
• firewall, proxy, and DNS policies;
• image allowlists and admission policies;
• disconnected-environment synchronization;
• installation and upgrade automation that rewrites image locations.

Do not expect a Kubernetes 1.26 tag to appear under k8s.gcr.io.

4. Upgrade container runtimes before kubelets

Before upgrading any worker to Kubernetes 1.26, verify that its runtime supports CRI v1.

For containerd, upgrade to 1.6.0 or later first. A node whose runtime only supports CRI v1alpha2 will fail to register after its kubelet is upgraded.

This is the only minimum runtime dependency explicitly supported by the supplied release sources. Other runtime, operating-system, networking, and storage compatibility requirements must be checked with their respective vendors.

5. Validate removed storage and cloud integrations

Before the control-plane or worker rollout, identify dependencies on:

• the in-tree GlusterFS driver;
• the in-tree OpenStack Cinder integration;
• the in-tree OpenStack cloud provider;
• the vSphere in-tree storage driver;
• the Azure File in-tree storage driver.

GlusterFS and the OpenStack in-tree integrations are removed. vSphere and Azure File CSI migration are Stable, but the corresponding external components and provider-specific prerequisites still need to be present and tested.

6. Review control-plane and node configuration

Audit component arguments and configuration for:

• removed legacy logging flags;
• deprecated kube-apiserver flags;
• removed kube-proxy userspace modes;
• removed dynamic kubelet configuration;
• removed in-tree credential management;
• feature gates associated with Alpha functionality.

The supplied excerpts do not enumerate every affected flag or configuration value. Do not remove or rename flags based solely on this summary; compare the deployed configuration with the complete changelog.

7. Treat Alpha APIs as experimental

The following highlighted capabilities are Alpha in 1.26:

• metrics framework extension;
• component health SLIs;
• Dynamic Resource Allocation;
• CEL-based validating admission policy;
• Pod scheduling readiness.

Enabling CEL admission requires both ValidatingAdmissionPolicy and the admissionregistration.k8s.io/v1alpha1 API through --runtime-config. Dynamic Resource Allocation is controlled by DynamicResourceAllocation, while component health SLIs use ComponentSLIs.

Evaluate these capabilities in non-production environments and plan for API or behavioral changes.

8. Roll out and validate workers deliberately

After runtime compatibility is established, upgrade workers in controlled batches. Validate that upgraded kubelets register successfully and that storage, networking, credentials, device allocation, and Windows HostProcess workloads behave as expected.

The supplied source material does not define a specific control-plane or worker upgrade command sequence. Follow the procedure appropriate to your Kubernetes distribution and consult the official Kubernetes documentation .

Conclusion

Kubernetes 1.26 Electrifying combines substantial Stable graduations with several changes that demand advance preparation. CSI migration, Windows HostProcess containers, Service networking, kubelet credentials, and resource management become more mature, while new Alpha work explores policy, scheduling readiness, richer device allocation, and SLI-oriented observability.

The critical upgrade tasks are clear: move image workflows to registry.k8s.io, ensure every runtime supports CRI v1, migrate removed APIs, and eliminate dependencies on removed in-tree storage, cloud-provider, kube-proxy, logging, credential, and kubelet-configuration functionality.

Official resources

• Kubernetes 1.26: Electrifying release announcement
• Official Kubernetes 1.26 changelog and release notes
• Kubernetes 1.26.0 GitHub release tag
• Kubernetes documentation