Kubernetes 1.9: Highlights Overview



    The next release of Kubernetes, 1.9, is due to happen this week. According to the current plan , this will happen today (December 13th). The main innovations that this issue will bring are already known: like last time , there really were a lot of them. Here is an overview of the most significant changes that come in Kubernetes with the upcoming 1.9 release.

    When writing this article, the following were used:


    ... and, of course, endless issues and pull requests in the project’s GitHub repositories.

    API


    Event API Redesign


    The architecture of the event API (and the EventRecorder library ) implements changes aimed at improvements in two directions:

    1. Reduce the impact of events on overall cluster performance .
    2. Make the object Eventmore structured in order to simplify further work with it (“the first and necessary step for the ability to automate its analysis”).

    Among the issues addressed by these changes are:

    • Events now send too many messages (for example, the inability to schedule a pod generates an event every few seconds);
    • the semantics of events is not always clear (for example, there is no distinction between the reasons for generating an event and the reasons for taking any actions related to the event);
    • increased load on the cluster due to events in the event of any problems (for example, the user created much more hearths than the cluster is able to withstand, which leads to repeated errors in their planning);
    • ...

    Comparison of old and new objects Event:



    All of this is described in detail in design-proposals: events-redesign . Current status is alpha version.

    Admission webhooks


    A beta version of a mechanism called admission webhooks has been added , which allows you to modify and / or accept and reject API requests . It belongs to the admission control stage and is triggered in the last steps of request processing before being saved to the database (etcd). In essence, these webhooks are similar to initializers (we wrote about them in the translated article “ What happens in Kubernetes when kubectl run starts? Part 1 ”) , however:

    • apply to all actions (creation, modification, deletion);
    • performed synchronously (i.e. long delays are unacceptable);
    • objects for which hooks are executed are not available until they are executed.

    An example of using admission webhooks from the documentation is to check one field of an object and set a value for its other field. Another example is the automatic addition of a service container (for example, performing a backup) by annotation of the hearth. For example, we have a sub with MySQL, with one container (in which MySQL itself), and this sub has a special annotation. When we create a sub, the request comes to the Kubernetes API, which sends the request to our application through the admission webhook , and the application sees the request, sees what is being created under, sees its own special annotation and does just rewrite - adds a second container to the under.

    A detailed description of admission webhooks is published here .

    Workload API


    Workload API was introduced last release Kubernetes and combines the interfaces related to "workload": DaemonSet, Deployment, ReplicaSet, StatefulSet. A separate API group was named for them apps, and with the release of K8s 1.9, all these changes received a stable status .

    The major changes to the Workload API introduced in Kubernetes 1.8 and 1.9 are summarized in the project documentation .

    Other


    • Support for conditions has been added to state StatefulSet(s DaemonSet) , which makes them compatible with other category controllers .core/v1
    • The flag has been --chunk-size={SIZE}added to kubectl get, and support for restricting data output by the API (API chunking) has generally received beta status.

    Storage facilities


    Out-of-Tree Volume Plugins (CSI)


    The existing volume plugins are part of Kubernetes: they are called “in-tree”, since all the code is included in the main project repository, and in compiled form they are distributed as part of the K8s binaries. This approach has an obvious minus: the support of third-party repositories by their manufacturers / developers depends on the release cycles of Kubernetes (in addition, all source code must be Open Source). This problem is partially solved by the Flexvolume plugin , however, this mechanism does not guarantee backward compatibility and (when installing the driver) requires the deployment of its files in certain places on nodes and wizards.

    The new approach is called Out-of-Tree CSI Volume Plugins.(CSI is the Container Storage Interface that defines how container orchestration systems can use third-party storage) . It is designed to implement a full-fledged API in Kubernetes, which allows you to:

    • Create volumes "outside the tree" (Kubernetes repository);
    • Do not require the inclusion of compiled code in K8s binaries;
    • Do not require direct access to Kubernetes machines to deploy these plugins (drivers).

    The authors proposed the following recommended mechanism for deploying CSI drivers in Kubernetes:



    Explanations for this scheme and details about the project as a whole are published in this document . Kubernetes 1.9 implementation status is alpha.

    Running mount inside the hearth


    A feature called Containerized mounts brings Kubernetes the ability to run mount utilities on pods, not on the host machine . Thus, the host system can remain a minimal GNU / Linux distribution without third-party software: for creating Ceph RBD ( /usr/bin/rbd), mounting GlusterFS ( mount.glusterfs), etc., and all utilities for working with volumes (operation provision / delete, attach / detach , mount / unmount) are placed in the hearths.

    Details of this feature are published in design-proposals: containerized-mounter-pod . Current status is alpha version.

    Resize volumes


    Basic resize operation support for existing PV ( PersistentVolume) appeared in Kubernetes 1.8. By 1.9, it had not reached the beta version, but noticeable progress is evident: support for resizing for file systems has been added, and with it for GCE, EBS, Cinder, and Ceph RBD volumes . Beta is expected for release 1.10.

    Other


    • Deletion PersistentVolumeClaimsused by any pods is now prevented (alpha version).
    • Options volumeModeand volumeDevicefor the PV ( PersistentVolume), allowing direct use of block devices instead of raw-file system (alpha version).

    Networks


    IPv6 Support


    Implemented basic IPv6 support, providing "all the features of Kubernetes on an IPv6 network instead of IPv4." At the moment, this implementation is in alpha version and includes:

    • Support for Kubernetes Cluster Deployment in IPv6 Only Mode
    • support for deploying a cluster with IPv6 through kubeadm ;
    • support for K8s control plane and data plane;
    • iptables kube-proxy backend support using ip6tables;
    • use of CNI 0.6.0 build for IPv6 network in hearths;
    • IPv6 support in kube-dns via SRV records;
    • limitations: from CNI plugins only bridgeand were tested local-ipam; lack of support for HostPorts; the netmask for the hearth / cluster should be / 66 or more.

    Other


    • An experimental mode has been added to kubeadm in which CoreDNS is used instead of kube-dns . We wrote more about the progress of the CoreDNS project here .
    • IPVS mode in kube-proxy , first introduced in K8s 1.8, went into beta status.

    Other components and changes


    Scheduler


    The cluster pod preemption mechanism has been improved with support PodDisruptionBudgetand nominated pods . In addition, support has been added to the scheduler for a new type of queue based on priorities (the pods with the highest priority will be planned first).

    When usinghostPort the hearths , it became possible to listen to the same port on different IP addresses.

    Authentication and Security


    An important innovation from SIG Auth is ClusterRole Aggregation for the ability to add permissions to existing ones, i.e. built in the RBAC, roles ( admin, edit, view).

    It can also be noted that:

    • format support has been added to RBAC ( PolicyRules) policy rules - for example, it will include ;*/subresource*/scalereplicationcontroller/scale
    • in PodSecurityPolicymade notable improvements, including multiple productivity gains when using a large number of policies in the cluster (authentication occurs now only valid for hearth policies, not all of the cluster policy) and support K8s additions .

    CLI


    The name of the feature kubectl diff speaks for itself: this is a new command that allows you to view the differences between the locally described Kubernetes object and the current state of the real object (in the cluster). Current status is alpha version.

    The kubeadm upgrade applyoption is added --etcd-upgrade, performing updates etcd in podah to a version that is officially supported by the target release Kubernetes (3.1.10 if K8s 1.9).

    In kubeadm appeared support Kubelet the Dynamic the Configuration , which means you can outrun configurations kubelet on the running cluster (itself a feature first appeared in the previous version of Kubernetes and retains the status of the alpha version with the prospect of upgrading to beta in K8s 1.10).

    Windows


    • Through kubeadm , you can now add Windows work nodes to the cluster .
    • In kubelet appeared support guidelines mount paths in Windows format, not just Linux absolute paths, as it was before.

    Openstack


    Improved integration with the cloud platform:

    • Added support for Cinder v3 API and fixed Cinder version detection;
    • OpenStack LBaaS v2 Provider has become customizable;
    • OpenStack Octavia v2 (not only Neutron LBaaS v2) can now be used for load balancing;
    • Extended support for OpenStack security groups.

    Other changes


    • Validation of third-party resources defined through Custom Resource Definition (CRD) has received beta status, and a sample CRD controller has been added .
    • In hyperkube (a binary file that includes all Kubernetes server components) cloud-controller-manager is added .
    • An update to cAdvisor to 0.28.1 added support for monitoring containerd.
    • AppArmor can now be disabled by setting a profile unconfined.
    • When kubelet starts , the dependency on Docker is no longer checked.
    • The format of container logs in CRI learned to split long lines into several, and fluentd introduced support for logs in CRI format.

    Compatibility


    • The supported version of etcd is 3.1.10 (Kubernetes 1.8 was 3.0.17).
    • Verified versions of Docker - from 1.11.2 to 1.13.1 and 17.03.x.
    • The Go version is 1.9.2 (instead of 1.8.3), the minimum supported is 1.9.1.
    • CNI version is 0.6.0.

    PS


    Read also in our blog:

    Tags:

    Also popular now: