What’s New In Kubernetes 1.21?

In this world of technology, frameworks or development platforms are evolving to serve the best performance results to developers and users. And Kubernetes is not apart from this. It is a portable, extensible, open-source platform to manage containerized workloads and services, that facilitates declarative configuration and automation. It has large, rapidly growing ecosystem. Now, Kubernetes came with its new version Kubernetes 1.21 with some amazing features and improvements. But what are these new enhancements? Let’s dig in and find out.

New Features Of Kubernetes 1.21-

1. New Memory Manager-

Container deployments are dependent on memory. And those deployments must use memory wisely, otherwise they could wind up  by draining your cluster of precious resources. Memory manager is a new feature in the ecosystem which enables guaranteed memory allocation for pods in the Guaranteed QoS class. With this, you will be able to find two different allocation strategies:

• Single: NUMA is for high-performance and performance-sensitive apps.
• Multi-NUMA defeats situation that can’t be managed with single-NUMA strategy

Memory manager initializes a memory table collection for every NUMA node that results in memory map objects. Memory table and memory maps are constructed like-

type MemoryTable struct {
 
        TotalMemSize uint64 `json:"total"`
        SystemReserved uint64 `json:"systemReserved"`
        Allocatable uint64 `json:"allocatable"`
        Reserved uint64 `json:"reserved"`
        Free uint64 `json:"free"`
}
 
type NodeState struct {
       NumberOfAssignments int `json:"numberOfAssignments"`
       MemoryMap map[v1.ResourceName]*MemoryTable `json:"memoryMap"`
       Nodes []int `json:"nodes"`
}
 
type NodeMap map[int]*NodeState

2. Flexible Scheduler-

Every workload is not the same. With release of 1.21 the scheduler will receive two new features- Nominated nodes and Pod affinity. 

• Nominated nodes allow cloud native developers to define preferred node, by using .status.nominatedNodeName filed in Pod. If scheduler fils to fit incoming pod into preferred node, it will preempt lower-priority pods to make room.
• Pod affinity selector allows developers to define node affinity into deployment. It allows developer to constrain which nodes pods will be scheduled on.

3. Indexed Job-

Now, jobs associated with index so that job controller can check annotation while creating pods. This enhancement eases the deploying of highly parallelisable workloads into Kubernetes especially for HPC use cases. The job controller will create Pods for the lowest indexes that don’t already have active or succeeded pods. If there are multiple pod for an index, the controller will remove all but one. Active pods that do not have an index are removed and finished pods that don’t have an index won’t count towards failures or successes.

4. ReplicateSet Downscaling-

For anybody that deals with a Kubernetes deployments, you understand that autoscaling is one of the most significant highlights. One issue that has plagued Kubernetes autoscaling is downscaling after a load spike passes.  With Kubernetes 1.21, there are two new downscale strategies, means you will no longer need to manually check when it comes time to downscale a deployment. The strategies are-

• ReplicaSet deletion cost makes it feasible for you to annotate Pods, using controller.kubernetes.io/pod-deletion-cost=X(here X is a number between 0 and 10). Pods with a lower deletion cost value will be removed first.
• Random Pod selection on ReplicaSet downscale – that uses LogarithmicScaleDown to semi-randomly select pods to downscale.

5. Metric Cardinality Enforcement-

Previously, there have been occurrences of metrics causing memory leaks. In such cases, the issue couldn’t be solved until a new Kubernetes binary was released. 

To remove this issue, this enhancement introduces two new command line options in Kubernetes 1.21.

The –disabled-metrics flag will allow you to disable problematic metrics.

The –allow-label-value option allows you to define a list of accepted values for a metric.

6. Depreciation Of Pod Security Policy-

Pod security Policies restrict what can be done within the scope of deployment, like setting execution limits to a list of users or allowing resource access for things like network or volumes. PSP have been in beta for some time now, with no indication of effort made to take the feature stable state. Resulting in, PSP are being marked as deprecated in Kubernetes 1.21 and will be completely removed in Kubernetes 1.25. Users should consider Open Policy Gatekeeper (OPA) for policy enforcement. Canonical Kubernetes will support OPA in its distributions and is anticipating with users to ensure all their policy requirements can be met.

7. Metrics Stability Enhancement-

This enhancement follows up on the recent efforts to better handle the deprecation of Kubernetes features. Now, the metrics come with two categories, either ALPHA or STABLE. Alpha metrics can be deleted any time, but stable metrics are guaranteed to not change. Hence deprecation life cycle has been put into a place to better handle deprecation of stable metrics. 

When stable metric is deprecated, it will be marked as deprecated. This will come in the form of a notice in the description text (Deprecated from x.y), and a warning log will be removed in metric registration.

After some releases, the metric will be hidden, not being registered by default. Sysadmins can enable those metrics back with the command line-

--show-hidden-metrics-for-version.

On the next release, the metric will be removed.

8. Service Internal Traffic Policy-

This enhancement is a step to build more efficient networking in Kubernetes. After ServiceTrafficPolicy feature gate is enabled, a new spec.trafficPolicy field will be available on Service objects. When,

•  this field is set to Cluster, routing will behave as usual,
• Set to Topology, it will use topology-aware routing. 
• Set to PreferLocal, it will redirect traffic to services on the same node.
• and Set to Local, it will only send traffic to services on the same node.

9. IngressClass namespaced params-

Due to this enhancement, you can specify parameters for an IngressClass with Namespace scope:

apiVersion: networking.k8s.io/v1
 kind: IngressClass
 metadata:
   name: external-lb
 spec:
   controller: example.com/ingress-controller
   parameters:
     apiGroup: k8s.example.com
     kind: IngressParameters
     name: external-lb
     namespace: external-configuration
     scope: Namespace

10. CRIContainerLogRotation-

It summarizes the work done to finally bring this feature up to Stable after being in beta since Kubernetes 1.11. For container runtimes that communicate with kubelet via the Container Runtime interface(CRI), the kubelet is the one in charge of handling the container runtime logs, and providing the log file path to the container runtime. While implementing log rotation, it was decided that kubelet took care of this too.

Here two command line options have been added to tweak log rotation behavior : –container-log-max-size and –container-log-max-files.