Kubernetes Version 1.23 is out! Here, unpack critical changes grouped into the Kubernetes API, containers and infrastructure, storage, networking, and security.
Join the DZone community and get the full member experience. The Christmas edition of Kubernetes comes with 45 new enhancements to make it more mature, secure, and scalable. In this blog, we’ll focus on the critical changes grouped into the Kubernetes API, containers and infrastructure, storage, networking, and security. Let’s start with the “face of Kubernetes”, which makes it scalable and expandable. There are three significant changes from api-machinery, CLI, and autoscaling SIGs that will be released as part of 1.23: Using kubectl get events makes it easier to watch the cluster’s overall state and solve problems. However, it’s limited by the options and data collection approach of the kubectl get command. That’s why there’s a new command being released as an alpha feature in 1.23: kubectl event. The new command will be beneficial for: Until feature graduation, you can check the design document for the upcoming features in subsequent releases. Thankfully, you can start using the kubectl events command just after installing the new kubectl version. Horizontal Pod Autoscaler (HPA) is the central component of Kubernetes that automatically scales the number of pods based on metrics. HPA can scale up or down many resources, such as replica sets, deployments, or stateful sets with well-known metrics like CPU utilization. It has been part of the Kubernetes API since 2015, and it’s finally graduating to general availability (GA). If you’re already using HPA in your clients and controllers, you can start using v2 instead of v2beta1. This graduation also means that you can use HPA in the long run, since it’s production-ready and now a core component of the Kubernetes API. CustomResourceDefinition (CRD) is the robust abstraction layer that extends Kubernetes and makes it work with all possible custom-defined resources. Because users define the new custom resources and their specifications, the validation could be tricky with Webhooks, controllers, and client tools. Thankfully, it is proposed using an inline expression language, such as Common Expression Language, and integrated into CRD for validation. With the 1.23 release, validation rules are provided as an alpha feature so that you can add x-kubernetes-validation-rules, similar to the following example from the Kubernetes Documentation: Let’s assume you want to create the following custom resource instance where it violates the second rule: Kubernetes API will respond with the following error message: If you are using CRDs in your cluster, you must also use validation mechanisms in your Open API schema and your controllers.
