The release of Kubernetes 1.24, codenamed Stargazer, represents a watershed moment in the evolution of container orchestration. Named Stargazer to honor the global community of contributors—where every contributor is viewed as a star in the cloud-native sky—this version serves as a critical transition point between the legacy era of Docker-centric dependencies and a modernized, runtime-agnostic future. The theme of Stargazer evokes the sense of awe and wonder associated with astronomy, from ancient observers to the precision of the James Webb Space Telescope, reflecting the expansive ambitions of the Kubernetes project.
Historically, Kubernetes relied on a compatibility layer known as Dockershim to communicate with the Docker container runtime. Kubernetes 1.24 fundamentally alters this landscape by removing Dockershim entirely. This shift forces a migration toward the Container Runtime Interface (CRI), specifically the containerd runtime in many managed environments. For users of Amazon Elastic Kubernetes Service (Amazon EKS) and the Amazon EKS Distro, this means that Amazon Machine Images (AMIs) for version 1.24 exclusively support the containerd runtime.
From a lifecycle perspective, it is imperative to note that Kubernetes 1.24 has reached its End of Life (EOL) as of July 28, 2023. The final patch release for this series was 1.24.17. Because the release has reached EOL, it no longer receives security updates or bug fixes, making upgrades to supported versions a critical security requirement for any organization still operating on this version.
The Removal of Dockershim and the Transition to Containerd
The most significant architectural change in Kubernetes 1.24 is the complete removal of the Container Runtime Interface (CRI) for Docker, commonly referred to as Dockershim. For years, Dockershim allowed Kubernetes to interface with Docker, but as the ecosystem matured, the need for a standardized CRI became paramount.
The removal of Dockershim means that the kubelet can no longer communicate directly with Docker. In the context of Amazon EKS, this transition is absolute; the EKS-optimized AMIs for version 1.24 no longer support the container-runtime flag, nor do they support enable-docker-bridge or docker-config-json.
The impact of this change on the end-user is nuanced. While the runtime within the cluster has changed, the tools used to create images have not. Open Container Initiative (OCI) images generated by Docker build tools remain fully compatible and will continue to run in Kubernetes 1.24 clusters. Users can continue to use Docker for building containers outside the cluster without interruption.
However, the internal operational shift is profound. To facilitate this transition, Amazon developed the Detector for Docker Socket (DDS). This tool, implemented as a kubectl plugin, allows administrators to identify if any workloads or manifest files are mounting the docker.sock volume. This is critical because any application relying on direct access to the Docker socket will fail in a containerd-only environment.
The following table outlines the specific changes regarding runtime configuration in Amazon EKS 1.24:
| Feature | Status in Kubernetes 1.24 | Impact/Requirement |
|---|---|---|
| Dockershim | Removed | No longer supported as a CRI |
| Containerd | Primary Runtime | Default and only supported runtime for EKS AMIs |
| Docker Build Tools | Supported | OCI images still run as expected |
enable-docker-bridge |
Unsupported | Must be removed from worker node configurations |
docker-config-json |
Unsupported | Must be removed from worker node configurations |
container-runtime |
Unsupported | Must be removed from worker node configurations |
Native gRPC Probes and Application Health
Kubernetes 1.24 has elevated the gRPC probes functionality to Beta, making it available by default. This feature addresses a long-standing pain point for developers running gRPC-based microservices. Previously, if a developer wanted to implement liveness, readiness, or startup probes for a gRPC application, they were forced to either expose a separate HTTP endpoint or utilize an extra executable to perform the health check.
With the introduction of native gRPC probes, Kubernetes can now perform these checks directly against the gRPC service. This streamlines the architecture of the application, reduces the overhead of maintaining secondary health-check protocols, and ensures that the kubelet can accurately determine the state of the pod using the same protocol the application uses for its primary logic.
The three types of probes supported for gRPC are:
- Startup Probes: Used to determine when an application has successfully started.
- Liveness Probes: Used to determine if a container has entered a broken state requiring a restart.
- Readiness Probes: Used to determine if a container is ready to start accepting traffic.
Kubelet Image Credential Providers
The support for image credential providers in the kubelet has graduated from Alpha (introduced in version 1.20) to Beta in Kubernetes 1.24. This functionality is a significant improvement in security and flexibility for how nodes authenticate with container registries.
Traditionally, image credentials were stored as static secrets on the node's filesystem. This created a security risk and an operational burden. The image credential provider allows the kubelet to dynamically retrieve credentials for a container image registry using exec plugins.
For users of Amazon EKS Anywhere, this is implemented via the configuration of specific kubelet flags:
--image-credential-provider-config: Used to specify the configuration file for the provider.--image-credential-provider-bin-dir: Used to specify the directory containing the binary for the provider.
This allows for the use of Amazon ECR plugins or other managed identity providers, such as Cognito User Pools, where a Cognito binary acts as the credential provider. By moving away from static disk-based credentials, organizations can implement more robust identity management and reduce the surface area for credential theft.
Service ClusterIP and Static IP Assignment
Kubernetes 1.24 introduces an opt-in feature that allows for the soft-reservation of a range for static IP address assignments to Services. This is designed to prevent IP collisions in complex networking environments.
In a standard Kubernetes configuration, a Service ClusterIP can be assigned in two ways:
- Dynamically: The cluster automatically selects a free IP address from the configured Service IP range.
- Statically: The user manually specifies a particular IP address within the configured range.
Because Service ClusterIPs must be unique, attempting to create a service with an IP that is already allocated will result in an error. The new soft-reservation feature allows the cluster to prefer automatic assignment from the general pool while reserving specific ranges for static assignments, thereby reducing the risk of collision.
Control Plane and API Enhancements
The 1.24 release includes several critical updates to the control plane and the API structure to increase stability, security, and developer experience.
Leader Migration for Controller Managers
To increase high availability (HA) in the control plane, Kubernetes 1.24 implements Leader Migration for Controller Managers. Both the kube-controller-manager and the cloud-controller-manager can now apply new controller-to-controller-manager assignments. This ensures that if a leader fails or needs to be migrated, the process can happen without downtime, ensuring the cluster's management functions remain uninterrupted.
CertificateSigningRequest (CSR) Duration
The CertificateSigningRequest API has been extended to allow clients to request a specific duration for the issued certificate. This provides finer-grained control over certificate lifecycles, allowing security teams to issue short-lived certificates for high-risk tasks or longer-lived ones for stable infrastructure, rather than relying on a single global default.
Contextual Logging
Kubernetes 1.24 introduces contextual logging. This allows the caller of a function to control specific aspects of the logging process, including:
- Output formatting.
- Verbosity levels.
- Additional values.
- Names.
This improvement is vital for debugging complex distributed systems, as it allows developers to inject context into logs that makes tracing a specific request across multiple functions significantly easier.
OpenAPI v3 Support
Beta support has been introduced for publishing Kubernetes APIs in the OpenAPI v3 format. This modernization of the API specification allows for better tooling integration and more accurate documentation of the API surface.
Storage and Volume Management
Significant progress was made in 1.24 regarding the migration of storage plugins and the ability to modify existing volumes.
Volume Expansion
Kubernetes 1.24 adds support for resizing existing persistent volumes. This allows administrators to increase the size of a volume without having to migrate data to a new volume or recreate the persistent volume claim, greatly increasing the flexibility of stateful workloads.
In-Tree Storage Plugin Migration
As part of the broader move toward the Container Storage Interface (CSI), Kubernetes 1.24 continues the migration of internals from in-tree storage plugins to CSI plugins. This migration allows the original API to be maintained while the underlying implementation is shifted to the more flexible CSI model. Specifically, the Azure Disk and OpenStack Cinder plugins have been successfully migrated.
Security and Software Supply Chain
Security in Kubernetes 1.24 is focused on the integrity of the release process and the management of node certificates.
Release Artifact Signing
To enhance software supply chain security, release artifacts in 1.24 are signed using cosign signatures. There is also experimental support provided for verifying these image signatures. This ensures that the binaries and images being deployed are exactly what the Kubernetes release team produced and have not been tampered with.
Kubelet-Serving Certificates
A critical security change in version 1.24 relates to the issuance of kubelet-serving certificates. No kubelet-serving certificates will be issued if any Subject Alternative Names (SANs) cannot be confirmed. This is a security hardening measure, but it has a direct impact on operational tools. If these certificates are not issued, the following commands will cease to function:
kubectl execkubectl logs
Users must refer to the EKS user guide to determine if their configuration is impacted and apply the recommended workarounds and long-term resolutions.
Summary of Deprecations and Removals
Beyond the removal of Dockershim, Kubernetes 1.24 serves as a cleanup release for several deprecated features.
Dynamic Kubelet Configuration
Following its deprecation in Kubernetes 1.22, Dynamic Kubelet Configuration has been completely removed from the kubelet in version 1.24.
Pod Security Policies (PSP)
While not removed in 1.24, it is explicitly noted that Pod Security Policies are slated for removal in Kubernetes version 1.25. This serves as a final warning for users to migrate to the Pod Security Admission controller or other alternatives.
PriorityClasses and Pod Preemption
A new option has been added to PriorityClasses that allows administrators to enable or disable pod preemption. This provides more control over how the scheduler handles resource contention.
Technical Configuration and Deployment
Kubernetes 1.24 is available for download on GitHub and can be deployed using several methods.
Installation Tools
For those setting up new clusters or upgrading, the following tools are supported:
kubeadm: The standard tool for bootstrapping Kubernetes clusters.kind: Used for running local Kubernetes clusters using containers as "nodes".
Upgrade Path and Requirements
Before upgrading to Kubernetes 1.24, specifically in an EKS environment, the following steps are mandatory:
- Identify Dockershim dependencies using the Detector for Docker Socket (DDS) tool.
- Modify workloads to remove any mounts of
docker.sock. - Remove the flags
enable-docker-bridge,docker-config-json, andcontainer-runtimefrom worker node configurations. - Test all workloads using the containerd runtime.
Final Analysis of the Stargazer Release
Kubernetes 1.24 is not merely a version increment; it is a structural realignment of the platform. The removal of Dockershim represents the project's commitment to the Container Runtime Interface (CRI) and the removal of legacy technical debt. While this created a significant migration hurdle—specifically for those relying on the Docker socket—it paved the way for a more modular and performant architecture.
The introduction of native gRPC probes and the graduation of image credential providers to Beta demonstrate a focus on developer ergonomics and enterprise-grade security. By allowing the kubelet to dynamically retrieve credentials, Kubernetes 1.24 reduces the risk associated with static secrets and simplifies the integration with cloud-native identity providers.
From a networking perspective, the introduction of static IP reservations for Service ClusterIPs addresses critical stability needs for large-scale deployments where IP collision can lead to service outages. Furthermore, the advancements in the control plane, such as leader migration for controller managers, ensure that the orchestration layer remains resilient even during updates or failures.
In retrospect, the Stargazer release served as the necessary bridge to the modern era of Kubernetes. Although the version has since reached End of Life, the architectural changes introduced in 1.24—particularly the shift to containerd and the hardening of the software supply chain—remain foundational to the current state of the Kubernetes ecosystem. Organizations that successfully navigated the 1.24 transition were better positioned for the subsequent removal of Pod Security Policies in 1.25 and the continued evolution of the CSI and CRI standards.