KUBERNETES 1.30 has better naming

The open source China community team made its first live broadcast, telling the story behind the open source China community in the name of sharing."

After several critical vulnerabilities were discovered, Kubernetes began to seriously consider using user namespaces to protect Pods. In addition, more granular container extensions are provided.

Translated from Kubernetes 1.30 Gets Better at Naming Things , author Joab Jackson.

Please show your passport!

Following the public disclosure of container leaks in January last year, Kubernetes version 1.30 provides more security checkpoints and strengthens permissions and access control. Bad processes are no longer allowed to roam anonymously in K8s-managed containers and Pods.

Thanks to KEP 24 ("AppArmor Support"), Kubernetes containers and pods can be protected through AppArmor , a Linux security module that enforces policies at runtime. It limits what an application can do to the system based on its configuration file.

Users specify AppArmor configuration files through the API .

The enhancement proposal has been around for about three years. Permission enforcement is a difficult task.

Another enhancement: Pods can now have usernames, thanks to KEP 127 ("Support for User Namespaces"), something that was quickly pushed forward after a series of critical container vulnerabilities were discovered in January that exploited This lack of access rights issue.

Kat Cosgrove , head of the latest Kubernetes release, said this feature "allows you to better isolate pods."

Also for security reasons, KEP 3488 ("CEL for Admission Control") introduces a richer expression language for admission control, which Cosgrove said provides a "more dynamic and expressive force to evaluate any request for access."

"You can define and enforce some very complex policies in the Kubernetes API, which makes security and governance features easier to control without impacting performance."

Team Leader: Needs coordination

This version is nicknamed "Uwubernetes" and is quite conventional. No noteworthy features have been deprecated, and it brings some very timely security enhancements. Overall, v1.30 brings 45 enhancements - 17 stable, 18 Beta, and 10 Alpha.

The Cloud Native Computing Foundation 's Kubernetes release lead is a bit of a herding cat, Cosgrove said.

“There’s a lot of politics” to be done.

Cosgrove leads a large team with nine direct reports and 35 reporting to them. They are spread across the globe, across five different sub-teams.

Kubernetes enhancements

Incorporating a feature into the next version of Kubernetes involves multiple hurdles.

A proposed feature started as a Kubernetes Enhancement Proposal (KEP). A special interest group must sponsor a KEP to be considered for the next edition. Nominators enter an enhancement freeze period, after which no new KEPs will be considered.

Because of the random nature of nominations, the resulting stack of new features could be a "complete gamble," Cosgrove said. Cosgrove said that after the enhancement freeze period, the code freeze period takes effect and "a lot of KEPs will be abandoned during this period." Perhaps many people find that getting their code to production level is more laborious than expected .

In the latest round, 95 KEPs entered the enhancement freeze, but only 45 entered the code freeze.

"During the enhancement freeze, people are very optimistic about their ability to do something. That's okay, that's completely normal," Cosgrove said. "Then we face reality during the code freeze."

Testing has been completed throughout this time frame, and there may also have been several alpha and beta versions of the upcoming version released (which are not widely used). Therefore, release candidates will begin to be released shortly.

After all this coordination work is done, the SIG often asks the team release lead to take a break before jumping back into the fray.

"I'm ready to take some time off," Cosgrove said.

Kubernetes 1.30: Who are you?

Beyond security, other features bring nuance to operations. For example, KEP 1610 ("Pod Autoscaling Based on Container Resources") brings the ability to automatically scale Pods based on container resource usage.

"This allows you to configure autoscaling based on the resource usage of individual containers, rather than the total resource usage of the entire pod," Cosgrove said.

This kind of fine-tuning can help reduce cloud costs, for example, by eliminating the need to scale an entire pod to meet the needs of a specific resource-intensive container.

This was noticed by Sergey Pronin , a group manager at database service provider Percona .

To date, database systems have not played well with Kubernetes Pod autoscalers due to data constraints.

"As interest grows in data technologies that separate storage and compute (e.g., Neon , Xata ), this feature may enable users to scale correctly," Pronin noted in an email.

Pronin also pointed to KEP-4381 "DRA: Structured Parameters") as "a very important addition to the k8s ecosystem." Another feature used to better scale resources, dynamic resource allocation provides an API for requesting and sharing resources between Pods and containers within the Pod.

It was added to Kubernetes as an alpha feature in v1.26 , although the inclusion of structured parameters introduced in Kubernetes 1.30 seems to make it easier to use.

The documentation states, "Structured parameters for dynamic resource allocation provide a framework that allows drivers to manage resources themselves, 'using a specific 'structured model' predefined by Kubernetes."

This article was first published on Yunyunzhongsheng ( https://yylives.cc/ ), everyone is welcome to visit.