Kubernetes 1.6: Made with stability in mind

We are happy to announce the first Kubernetes release in 2017 – Kubernetes 1.6.

Kubernetes 1.6 is big step towards the enterprise readiness. The most notable changes have happened not only with the new features, but also with enhancing the alpha and beta features from the previous releases in terms of stability.

What’s new:

Etcd v3 is used by default as a storage backend for APIServer. Enabling etcd v3 brings significant improvements in terms of performance, efficiency, reliability and concurrency. Performance testing results for Kubernetes clusters with etcd v3 enabled, have been showing the significant performance – with 5k nodes and 300k pods!
Also, for the users of existing 1.5-based clusters, the option to maintain v2 compatibility is provided as well.

Role-based access control (RBAC) has graduated to beta, and defines secure default roles for control plane, node, and controller components.

DaemonSet rolling updates – is a new feature, implemented for already existing DaemonSet objects. Prior to 1.6 release, DaemonSet template spec could be updated; but running pods won’t. Bringing an ability to update the DaemonSet object will add an option to automate pod updates when the DeamonSet was changed.

Kubelet TLS Bootstrap feature now is promoted to beta. This feature provides an API for the Kubelet to request TLS certificates from the API server. Before the feature has been enabled, when a kubelet has been running for the first time, it must be given TLS assets or generate them itself. In the first case, this is a burden on the cluster admin and a significant logistical barrier to secure Kubernetes rollouts. In the second, the kubelet must self-sign its certificate and forfeits many of the advantages of a PKI system. Instead, we propose that the kubelet generate a private key and a CSR for submission to a cluster-level certificate signing process.

kubefed has graduated to Beta. The command-line tool, first released as alpha in 1.5; in 1.6 is available as beta and now it supports hosting federation on the on-premises clusters, automatically configures kube-dns in joining clusters and allows passing arguments to federation components.

The Docker-CRI implementation, already present as Alpha, in 1.6 has graduated to Beta and is enabled by default in kubelet. CRI is a Container Runtime interface – the big step forward from monolith architecture to the pluggable and customizeable one. Also, other runtimes (cri-o, frakti, rkt) are supported as alpha.

The multiple schedulers feature is now in Beta. This feature allows you to run multiple schedulers in parallel, each responsible for different sets of pods. When using multiple schedulers, the scheduler name is now specified in a new-in-1.6 schedulerName field of the PodSpec rather than using the scheduler.alpha.kubernetes.io/name annotation on the Pod. When you upgrade to 1.6, the Kubernetes default scheduler will start using the schedulerName field of the PodSpec and will ignore the annotation.

Node affinity/anti-affinity and pod affinity/anti-affinity are now in Beta. Node affinity/anti-affinity allow you to specify rules for restricting which node(s) a pod can schedule onto, based on the labels on the node. Pod affinity/anti-affinity allow you to specify rules for spreading and packing pods relative to one another, across arbitrary topologies (node, zone, etc.) These affinity rules are now be specified in a new-in-1.6 affinity field of the PodSpec. Kubernetes 1.6 continues to support the alpha scheduler.alpha.kubernetes.io/affinity annotation on the Pod if you explicitly enable the alpha feature “AffinityInAnnotations”, but it will be removed in a future release. When you upgrade to 1.6, if you have not enabled the alpha feature, then the scheduler will use the affinity field in PodSpec and will ignore the annotation. If you have enabled the alpha feature, then the scheduler will use the affinity field in PodSpec if it is present, and otherwise will use the annotation.

Taints and tolerations are now in Beta. This feature allows you to specify rules for “repelling” pods from nodes by default, which enables use cases like dedicated nodes and reserving nodes with special features for pods that need those features. We’ve also added a NoExecute taint type that evicts already-running pods, and an associated tolerationSeconds field to tolerations to delay the eviction for a specified amount of time. As before, taints are created using kubectl taint (but internally they are now represented as a field taints in the NodeSpec rather than using the scheduler.alpha.kubernetes.io/taints annotation on Node). Tolerations are now specified in a new-in-1.6 tolerations field of the PodSpec rather than using the scheduler.alpha.kubernetes.io/tolerations annotation on the Pod. When you upgrade to 1.6, the scheduler will start using the fields and will ignore the annotations,

We are happy to see the Kubernetes project moving forward with the newly presented features in 1.6 release, that are enhancing stability, functionality and enterprise readiness. Feel free to check out the whole changelog to find out more.

Ihor Dvoretskyi is a member of the Kubernetes team at Mirantis, focused on upstream Kubernetes-related efforts. He also acts as a product manager at the Kubernetes community and been responsible for the features track at Kubernetes 1.6 release team.

Superuser is always interested in community content. Email editorATopenstack.org for details.

Tags: Kubernetes