Top 5 features in Kubernetes 1.26 that reduce the complexity of the technology

The official new Kubernetes release was recently introduced. The theme this time is Electrifying. Yet, a big part of K8s users would be electrified by the fact the technology has become less hard. The K8s community strives to achieve this goal in every release including the last one.

Kubernetes 1.26 has several features and initiatives that make the technology less complicated and ease users’ experience. Let’s take a look at five of such electrifying and useful improvements.

1. CEL for admission control

The feature is based on the CRD validation which appeared in Kubernetes 1.23. That KEP introduced Common Expression Language (CEL) as a more “organic” alternative to webhooks. The new one proposes the practical implementation of CEL in the admission control process.

In admissionregistration.k8s.io group the new resource is added: ValidatingAdmissionPolicy. It contains CEL expressions to approve admission policies and defines how policies can be configured. The example:

# Policy definition
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "replicalimit-policy.example.com"
spec:
  paramKind:
    group: rules.example.com
    kind: ReplicaLimit
    version: v1
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - name: max-replicas
      expression: "object.spec.replicas <= params.maxReplicas"
      messageExpression: "'object.spec.replicas must be no greater than ' + string(params.maxReplicas)"
      reason: Invalid
      # ...other rule related fields here...

This improvement doesn’t replace webhooks completely because they can support features which are not suitable for built-in implementation.

2. Provision volumes from cross-namespace snapshots

There’s no way to create a persistent volume claim in the necessary namespace if a volume snapshot is placed in another one. This is an annoying restriction in some tasks. For example when a snapshot is used as a source image for various namespaces (in KubeVirt it’s one of VM image usage patterns).

The feature makes it possible to create volumes from snapshots in different places. That means API PersistentVolumeClaim can now process VolumeSnapshots with many source namespaces. Also, the improvement expands CSI external provisioner functionality.

For security purposes, ReferenceGrant is used. Snapshots beyond the namespace boundary that are not allowed will be prohibited.

3. Auth API to get self user attributes

Kubernetes doesn’t have a resource representing a user and their attributes. It’s impossible to get it from the kubeconfig file. K8s uses authenticators to get data from external webhooks, tokens, OIDC providers, or X.509 certificates. These tools expand methods of authentication but reduce the capabilities of its troubleshooting. It’s not easy to understand which authenticator is used and what rights a user gets.

The new feature adds in the authentication.k8s.io group the API endpoint SelfSubjectReview. Also, a new command is introduced: kubectl auth who-am-i. It allows a user to see their attributes after the authentication procedure is completed.

The command creates a POST request like this:

POST /apis/authentication.k8s.io/v1alpha1/selfsubjectreviews

{
"apiVersion": "authentication.k8s.io/v1alpha1",
"kind": "SelfSubjectReview"
}

In response, the API server fills the user’s status in userInfo with attributes and returns it:

{
  "apiVersion": "authentication.k8s.io/v1alpha1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "name": "jane.doe",
      "uid": "b6c7cfd4-f166-11ec-8ea0-0242ac120002",
      "groups": [
        "viewers",
        "editors",
        "system:authenticated"
      ],
      "extra": {
        "provider_id": ["token.company.dev"]
      }
    }
  }
}

There are various output formats, from plain to detailed. You can select them through certain flags. Besides, you can get the output in JSON or YAML format.

This feature is useful for Kubernetes clusters with a complicated process of authentication. It helps to get full userInfo after all authentication procedures are finished.

4. Kubernetes component health SLIs

Service Level Agreement (SLA) consists of two basic concepts: Service Level Objectives (SLO) and Service Level Indicators (SLI). You can calculate SLO only if you can configure and analyze SLI.

Currently, the availability of K8s components data is rendered in the unstructured format. Agents of monitoring systems and kubelet handle this. It’s hard to create SLO with such an intricate approach because you need to use an external service to analyze data and transform it into SLI.

The feature allows sending SLI data in the structured Prometheus format and consistently. So, monitoring agents can use it and create SLI. There is no necessity to use the Prometheus exporter.

The new endpoint /metrics/sli is added in API Kubernetes. Also, there are two new metrics:

• gauge shows the current status of a healthcheck;
• counter calculates a summary of all healthchecks.

5. Allow StatefulSet to control start replica ordinal numbering

You can’t migrate StatefulState between namespaces without application downtime. For example, if you restore StatefulState from its copy, an application goes down till StatefulState is not restored. The migration on the Pod level is also not perfect: You need to reschedule new Pods after they start.

The improvement expands the mechanism of StatefulSet’s replicas management. By default a StatefulSet of N replicas numbers Pods from ordinal 0 to N-1. With the new feature, StatefulSet can do it from ordinal k to N+k-1. The starting number is added in the new field spec.ordinals.start. Now the original StatefulSet can be sliced at ordinal k between the source and target StatefulSet. It helps the controller to operate Pods in a more flexible fashion.

This option is useful in cases where you need to transfer a StatefulSet from one cluster to another, or between namespaces. In combination with PodDistruptionBudgets you can migrate replicas seamlessly.

Matured features

Finally, some beta and stable features that more or less improve the UX:

• Retriable and non-retriable Pod failures for Jobs (#3329, beta) helps to take into account unwanted reasons for a Job restart. Thus, you can stop a Job ahead of schedule and ignore backoffLimit.
• Kubelet credential provider (#2133, stable) is an extended plugin mechanism. It allows kubelet to get cloud providers’ credentials from their registries dynamically.
• Taking taints/tolerations into consideration when calculating PodTopologySpread skew (#3094, beta) improves the Pod scheduling mechanism during the skew process. For this new fields were added: NodeAffinity and NodeTaints in TopologySpreadConstraint.
• Tracking Terminating Endpoints (#1672, stable) allows not to use Pod information to check whether an endpoint is terminated or not.
• Kubectl events (#1440, beta) — the command which expanded events logging functionality and solved the limitations of kubectl get events.