Kubernetes v1.25 is out!!! Usually, the release notes document is an endless list of features, making them unreadable for the average user. For the average user, it's nearly impossible to understand who can benefit from the new version.

Here is the list of the most interesting capabilities of Kubernetes 1.25 and what you can get out of it.

1 - Hardcore Debugging & Troubleshooting For The Win!

Ephemeral Containers graduated to stable! They are containers that can be attached to a running pod for debugging/troubleshooting purposes. You may be familiar with it if you ever used the command kubectl debug.

Sometimes, in order to debug a running container, you need a magic tool. The problem is that if the tool wasn't packed with the image - you can't use it during runtime. Usually, those are the "heavy guns" for troubleshooting like debuggers, profilers, etc. Many people pack tools for extreme cases, tools with security risks that they will need 0.001% of the time.

What can you do with it?

Debug pods using a fresh image with debugging tools in it. Debug a node using a container. Copy a pod and attach a new container to it.

Who should be interested?

DevOps, SRE, Developers

Want to learn more?

https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/

Stage: Stable

2 - DaemonSet Upgrade Without Downtime

Daemon sets perform key functions in the cluster, from taking care of the basic needs of pods like networking and storage to metrics/logs exporters. Despite that fact, there was a risk in updating them because a node without a functional pod of networking (for example) can be useless. The previous process was: 1) delete the old version pod 2) spawn a new one. It means that if the new pod failed to start, the node would remain without a ready pod.

Version 1.25 introduced the ability to configure maxSurge for daemon sets. It allows to reverse the order of the process and delete the old pod only after the previous one is ready.

What can you do with it?

1. Upgrade your daemon sets with minimal downtime

Who should be interested?

• DevOps and infra teams that are responsible for daemon sets.
• Engineers/PMs that their applications run as a daemon set.

Want to learn more? https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/

Stage: Stable

3 - Say Hi To The New Security Configurations

The long process of migrating from Pod Security Policy to Pod Security Admission ended. Both allow to enforcement of a security policy but in a completely different way. The Pod Security Policy had usability issues that caused no one to really use it well.

What can you do with it?

1. Easily define a namespace that follows a restricted policy with all the latest security best practices using Pod Security Standards.
2. Turn on audit/warn/enforce policy using Kubernetes native Pod Security Admission.
3. Configuring security is much easier than before.

Who should be interested?

• Security people!!!
• DevOps that have PodSecurityPolicy in their clusters or start their journey toward Kubernetes Pods’ security.

Want to learn more?

• Pod Security Admission - https://kubernetes.io/docs/concepts/security/pod-security-admission/
• Pod Security Policy Deprecations (Why? What?) - https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/

Stage: Stable

4 - Set limits and requests for your ephemeral local storage

Local ephemeral storage got a few blind spots, especially around how much capacity is available and guarantees for a pod. A pod can use a local volume for files, you may know it as emptyDir. The most common use of it is local log and cache files. Because all the pods within the same node share the same disk, there is a possibility that one pod consumes all the space pushing the node into disk pressure. This is why the ability to configure requests and limits is important to assure stability.

What can you do with it?

• Set requests and limits for ephemeral local storage space needed to assure stability of pods & nodes.

Who should be interested?

• Engineers use ephemeral local storage and want to avoid/mitigate disk risks.

Stage: Stable

5 - Validate Your CRDs Instances Manifests

You have a CRD, and you want to make sure that anytime someone creates an instance of it - it will be validated based on your own rules. CRD Validation rules allow you to use Common Expression Language (CEL) to validate your CRDs.

What can you do with it?

1. Validate your own written CRD.
2. Make sure that you don’t make miss configurations when using CRDs like ArgoCD Apps, cert-manager’s certificate, etc.

Who should be interested?

• Users that interact with systems using CRDs.
• CRDs & operators maintainers.

Want to learn more? https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules

Status: moved to Beta

6 - One NetworkPolicy For Multiple Ports

Are struggling with defining a NetworkPolicy to one specific port at the time? The endPort configuration is for you!

Want to learn more? https://kubernetes.io/docs/concepts/services-networking/network-policies/#targeting-a-range-of-ports

Stage: Stable

What's Next?

• Kubernetes is changing! Every release brings in new things - stay on track and learn how to use it.

Follow me:

• hasnode
• Twitter - https://twitter.com/the_good_guym