The Kubernetes 1.27 release, dubbed "Chill Vibes," introduces various enhancements and security updates, providing users with a more versatile, secure, and improved platform.
The Kubernetes 1.27 release, dubbed "Chill Vibes", introduces various enhancements and security updates, providing users with a more versatile, secure, and improved platform.
Announced more than a year ago, Kubernetes images are no longer published to k8s.gcr.io, the project's initial home since its inception. To maintain a secure environment, you must update to registry.k8s.io in v1.27. Additionally, patch releases for supported versions from v1.24 onwards will only be available there.
Kubernetes 1.27 bolsters security by allowing the kubelet to utilize seccomp by default. This feature, graduating to stable in this release, reduces containers' attack surface by restricting the system calls they can access. This provides a more secure environment for running applications. The feature must be enabled on each node.
First introduced in v1.22 as a beta feature, this functionality is now stable. In most cases, a parallel job requires pods to run with constraints, such as all in the same zone, or all on either GPU model x or y, but not a mix of both. The suspend field is the initial step towards achieving these semantics. suspend allows a custom queue controller to determine when a job should begin. However, once a job is unsuspended, the custom queue controller has no influence over where the job's pods will ultimately be placed.
This feature allows updating a Job's scheduling directives before it starts, which gives custom queue controllers the ability to influence pod placement while at the same time offloading actual pod-to-node assignment to kube-scheduler.
Upon creation, Pods are ready for scheduling. The Kubernetes scheduler diligently searches for nodes to accommodate all pending Pods. However, in real-world scenarios, some Pods may remain in a missing-essential-resources state for an extended period.
By adding or removing a Pod's .spec.schedulingGates, you can control when a Pod is ready for scheduling consideration.
Kubernetes does not have resources to identify and manage users within its API. Instead, it employs authenticators to obtain user attributes from tokens, certificates, OIDC providers, or webhooks. Version 1.26 introduced a new API endpoint for viewing the current users' attributes, which has advanced to Beta in 1.27.
The SelfSubjectReview API supports the kubectl auth who-am-i command and will reduce the complexity of authentication. This enhancement will aid users in debugging the authentication stack.
Pod.Spec.Container.{Liveness,Readiness,Startup} Probe--master-service-namespace command line argument--enable-taint-manager command line argument--pod-eviction-timeout command line argument