Shulou(Shulou.com)06/01 Report--

Today, I would like to talk to you about the updates of Kubernetes v1.19, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Kubernetes version 1.19 has finally arrived! This is the second version in 2020 and the longest release cycle to date, lasting a total of 20 weeks. It consists of 33 enhancements. Twelve enhancements entered the stable version, 18 enhancements entered the beta version, and 13 enhancements entered the alpha version.

Increase the Kubernetes support window to one year

A survey conducted by the long-term support (LTS) working group in early 2019 showed that a large proportion of Kubernetes users failed to upgrade during the current nine-month support period. This and other reactions in the survey indicate that if the patch support period is extended to 12-14 months, 30% of users will be able to keep their deployment on a supported version. This is true regardless of whether users are using a self-built version or a commercial distribution. As a result, extending the support period will result in more than 80% of users using the supported version, rather than the current 50-60%. The annual support period provides users with the required buffer period and is more in line with the familiar annual planning cycle. Starting with Kubernetes version 1.19, the support window will be extended to one year.

Storage capacity tracking

Traditionally, Kubernetes schedulers have been based on the assumption that additional persistent storage can be used anywhere in the cluster with unlimited capacity. Topology constraints address the first point, but so far, Pod scheduling has not taken into account that the remaining storage capacity may not be sufficient to start a new pod. Storage capacity tracking is a new Alpha feature that solves this problem by adding an API to the CSI driver to report storage capacity and use this information when selecting nodes for Pod in Kubernetes Scheduler. This feature can be used as a basis for supporting dynamic provisioning of local volumes and other volume types with large capacity constraints.

General temporary storage

Kubernetes provides a volume plug-in whose lifecycle is bound to Pod and can be used as temporary space (such as built-in emptydir volume types) or to load some data into Pod (such as built-in configmap and secret volume types). The new generic scratch volume alpha feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume and binds the life cycle of that volume to Pod. It can be used to provide temporary storage different from the root disk, such as persistent memory or a separate local disk on that node. All StorageClass parameters for volume provisioning are supported. Supports all the features supported by PersistentVolumeClaims, such as storage capacity tracking, snapshots and restores, and volume resizing.

CSI Volume health monitoring

The Alpha version of CSI Health Monitoring is released with Kubernetes 1.19. This feature enables CSI drivers to share abnormal volume conditions from the underlying storage system with Kubernetes so that they can be reported as events on PVC or Pod. This feature is the basis for Kubernetes's program detection and resolution of individual volume health problems.

Upgrade from Ingress to GA

In terms of pushing Ingress API to GA, API itself has been in the Beta version for a long time, so much so that it has reached its de facto GA state through use and adoption (including users and load balancer Ingress controller providers). It is not a feasible way to give up it without a full replacement. It is obviously a useful API and captures a set of extraordinary use cases. At this point, it seems more cautious to declare the current API as the V1 version that the community will support, while developing a V2 Ingress API or a completely different API with superset capabilities.

Structured log

Prior to v1.19, logging in the Kubernetes control plane did not guarantee any uniform structure of log messages and references to Kubernetes objects in these logs. This makes it difficult to parse, process, store, query, and analyze logs, and forces administrators and developers to rely in most cases on temporary solutions based on some regular expressions. Because of these problems, any analysis solution based on these logs is difficult to implement and maintain.

New klog method

This version of Kubernetes introduces a new method for the klog library, which provides a more structured interface for formatting log messages. Every existing formatting log method (Infof,Errorf) is matched by a structured method (InfoS,ErrorS). The new logging method takes the log message as the first parameter and the list of key-value pairs as the second parameter of the variable parameter. This approach allows for the gradual adoption of structured logging without the need to convert all Kubernetes to a new API at once.

Client TLS Certificate rotation of Kubelet

Kubelet uses private keys and certificates to authenticate kube-apiserver. The certificate is provided to kubelet through an out-of-cluster mechanism when it is first started. Since Kubernetes v1.8, the cluster has included a (beta) process to obtain the initial certificate / key pair and rotate as the certificate expires, which can be stabilized in Kubernetes v1.19.

During the kubelet startup process, the file system is scanned for existing certificate / key pairs managed by the Certificate Manager. If a certificate / key is available, it will be loaded. If not, kubelet checks the encoded certificate value in the configuration file or the file reference in the kubeconfig. If the certificate is an bootstrap certificate, it will be used to generate a key, create a certificate signing request, and request a signed certificate from the API server.

As the expiration approaches, the certificate manager is responsible for providing the correct certificate, generating a new private key, and requesting a new certificate. As kubelet requests the signing of the certificate as part of its startup process, certificate signing requests from kubelet are constantly automatically approved to make the cluster easy to manage.

Other updates

The following features usher in a stable version

Seccomp

Kubelet client TLS certificate rotation

Restrict node access to API

Redesign Event API

Ingress graduated from V1 stable Edition.

CertificateSigningRequest API

No need for Docker to build Kubelet

Major change

Node Topology Manager

New endpoint API

Extend the Kubernetes support cycle to one year

Other important changes

Run multiple Scheduling Profiles

CertificateSigningRequest API

Immutable Secrets and ConfigMaps

Release note

See the full details of the Kubernetes 1.19 release in our release notes (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md)).

Usability

Kubernetes 1.19 can be downloaded from GitHub (https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0)). To get started with Kubernetes, check out these interactive tutorials (https://kubernetes.io/docs/tutorials/) or run your local Kubernetes cluster using a Docker container "node" with KinD (Kubernetes in Docker). You can also easily install 1.19 using kubeadm.

Release team

This version was released through the efforts of hundreds of people who contributed technical and non-technical content. Special thanks to the release team led by T aylor Dolezal, a senior developer advocate at HashiCorp. Thirty-four release team members coordinated all aspects of the release, from documentation to testing, validation, and functional integrity.

With the development of the Kubernetes community, our release process represents an amazing performance of collaboration in open source software development. Kubernetes continues to acquire new users at a rapid pace. This growth creates a positive feedback loop, and more contributors submit code to create a more dynamic ecosystem. To date, Kubernetes has more than 49000 individual contributors and an active community of more than 3000

Publish Logo

Everyone inspired this Kubernetes version 1.19 Logo! This version is a bit like a marathon, and it also proves that when the world is a wild place, we can get together and do incredible things.

Kubernetes 1.19 releases Logo

"emphasize claws-Localization" was chosen as the release theme because it captures the positive prospects of the release team despite the good state of the world. The characters shown in the 1.19 logo represent the personality of everyone on our release team, from emo to peppy, and more!

About designers: Hannah Beth Ragloff (Hannabeth Lagerlof) is a visual designer based in Los Angeles, California. She has a wide range of backgrounds in environmental and graphic design. Hannabeth creates art and user experience to inspire connections. You can find Hannabeth on Twitter as @ emanate_design.

In the long run

The content of this release is also different from the enhanced features. Traditionally, we have 3-4 weeks, from calling for enhancements to freezing enhancements, when contributors can confirm whether a feature will become part of the cycle. This release cycle is very special, and we have five weeks to complete the same milestone. The extended time gives contributors more time to plan and determine the graduation of their respective functions.

The milestone for contributors to achieve functionality is extended from the usual 5 weeks to 7 weeks. Contributors spend 40% more time studying their functions, reducing fatigue and having more time to think about how to achieve it. We also noticed that last-minute busyness was greatly reduced. The number of exception requests in this cycle has also decreased-6, compared with 14 in the previous release cycle.

Ecosystem renewal

CNCF has just finished its first virtual KubeCon. All lectures are on demand and can be attended by anyone who registers. It's not too late!

Certified Kubernetes Security specialist (CKS) will be launched in November! CKS focuses on clustering and system hardening, minimizing micro-service vulnerabilities and supply chain security.

CNCF released its second "status quo of Cloud Native Development", which shows a massive increase in the number of cloud native developers using container and serverless technologies.

Kubernetes.dev, a website focused on Kubernetes contributors, has been launched. It centralizes contributor documentation, resources, and project activity information into a central location.

After reading the above, do you have any further understanding of the updates to Kubernetes v1.19? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.