Release of Kubernetes 1.24, a container orchestration system for isolated containers

The release of the container orchestration platform Kubernetes 1.24 is now available, enabling unified management of a cluster composed of isolated containers, while providing mechanisms for deployment, maintenance, and scaling of applications running in these containers. The project was originally created by Google but was later transferred to an independent platform overseen by the Linux Foundation. The platform is positioned as a community-driven universal solution, not tied to specific systems and capable of working with any applications in any cloud environments. The Kubernetes code is written in Go and is distributed under the Apache 2.0 license.

Features are provided for deploying and managing infrastructure, such as DNS database management, load balancing, distribution of containers across cluster nodes (migrating containers based on changes in load and service requirements), application-level health checks, account management, updating and dynamically scaling the running cluster without downtime. It is possible to deploy groups of containers while performing updates and rollback operations for the entire group simultaneously, as well as logically partitioning the cluster with resource separation. There is support for dynamic application migration, for which both local storage and network storage systems can be used.

Key changes in the new release:

  • Stabilized tools for storage capacity tracking are now available, which monitor free space in partitions and transmit data to the control node to prevent pods from being started on nodes with insufficient free space.
  • The ability to resize storage partitions has been stabilized. Users can change the size of existing partitions, and Kubernetes will automatically extend the partition and its associated file system without downtime.
  • The supply of the runtime Dockershim has been discontinued. It was positioned as a temporary solution for using Docker in Kubernetes but is not compatible with the standard CRI (container runtime interface) and complicates kubelet. To manage isolated containers, one should use a runtime that supports the CRI interface, such as containerd and CRI-O, or utilize the cri-dockerd wrapper that implements the CRI interface over the Docker Engine API.
  • Experimental support for verifying container images through digital signatures has been provided using the Sigstore service, which maintains a public log for authenticity confirmation (transparency log). To prevent supply chain attacks and component substitution, digital signature assurance for artifacts associated with releases has also been implemented, including all deployable Kubernetes executables.
  • By default, the activation of APIs in beta status has been discontinued in clusters (previously introduced experimental APIs are retained; this change only affects new APIs).
  • Testing support for the OpenAPI v3 format has been implemented.
  • An initiative has been introduced to transition plugins for storage handling to a unified CSI (Container Storage Interface) with API level compatibility maintained. Azure Disk and OpenStack Cinder plugins have been migrated to CSI.
  • The Kubelet Credential Provider has entered beta testing, allowing dynamic retrieval of credentials for the container image repository through plugin execution, without storing credentials in the node's file system.
  • The ability to reserve a range of IP addresses for service allocation has been provided. When this option is enabled, the cluster will automatically assign services only an IP address from a pre-allocated pool designated for each service, which helps prevent collisions when issuing free addresses from the general pool.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster