The Kubernetes development team has recently released through an announcement the release of the new version "Kubernetes 1.18" in which the development team mentions that it is a version 'fit and finished'.
In this new version significant work has been done to improve beta and stable functionality to guarantee a better user experience. An equal effort has been made to add new developments and exciting new features that promise to further enhance the user experience.
For those unaware of Kubernetes, they should know that is an open source system to automate the implementation, scaling and management of containerized applications.
It was originally designed by Google, although its development has subsequently been entrusted to the Open Source Cloud Computing Foundation (CNCF), which today has allowed container orchestration technology to mature rapidly, thanks to the contributions of technology giants.
What's new in Kubernetes 1.18?
This new version stands out for having the ability to use service account tokens as a general authentication method. For example, if you want a pod to manage other Kubernetes resources, such as a deployment or a service, it can be associated with a service account and create the necessary roles and role bindings.
Kubernetes service accounts (KSAs) send JSON web tokens (JWT) to the API server to authenticate. This makes the API server the only source of authentication for service accounts.
Kubernetes 1.18pprovides a functionality which allows the API server to provide an OpenID Connect discovery document A containing the public keys of the token in addition to other metadata.
Another change that stands out from Kubernetes 1.81 is the ability to configure HPA Velocity for specific pods. Horizontal Pod Autoscaler (HPA) was useda to allow a Kubernetes cluster to automatically respond to high / low traffic. With HPA, the user can ask the controller to create more modules in response to CPU spikes, other measurements, or measurements provided by the application.
Kubernetes 1.18 has an overview of profiles to run multiple configurations of planner. Generally, there are two types of workloads in Kubernetes: long-term services (for example, web servers, APIs, etc.) and tasks that run to completion (better known as the name Jobs).
Due to the obvious differences between workload types, some users resort to creating full clusters for different needs. For example, one cluster to manage data mining and another to serve the application APIs.
The reason is that they need the decision process to differ. For example, the default scheduler settings promote high availability.
On the other hand, we can also find the ability to define a pod broadcast rule at the cluster level, which has made it possible to ensure that pods will be scheduled in Availability Zones (provided you are using a multi-zone cluster) to ensure maximum availability and resource utilization.
The functionality enables the topologySpreadConstraints specification, which identifies areas by searching for nodes with the same topologyKey tag. Nodes with the same TopologyKey tag belong to the same area. The configuration was to distribute the pods evenly in the different areas. However, the downside is that this setting must be applied at the pod level. Pods that do not have the configuration will not be evenly distributed across fault domains.
Last but not least, we can also find the ability to ignore the change in the volume property. By default, when a volume is mounted in a container on a Kubernetes cluster, all files and directories within this volume have their property changed to the value provided through the fsGroup.
All this to allow fsGroup to read and write the volume. However, this behavior has been shown to be undesirable in some cases.
This new version of Kubernetes comes with a number of changes and we've only mentioned a few of the most important ones. If you want to know the complete list you can do it by visiting the following link