2019 is almost coming to an end and with that we have the last release of Kubernetes for the year. Pn December 09, 2019, the Kubernetes 1.17 Release Team announced all of the major highlights on their log. Here are some of my picks.
Cloud Provider Labels reach General Availability If you are using kubernetes, let’s say in Azure, right now you would see the instance type under a label named beta.kubernetes.io/instance-type. With 1.17, this is now node.kubernetes.io/instance-type. With this label you can do things such as ‘schedule this workload on nodes that are of this type (e.g.: nodes that have GPU on them).
Add IPv4/IPv6 Dual Stack Support This is an interesting one and will likely be useful in scenarios where IPv6 is needed - think about IoT devices in the field.
What if a user would like to schedule a workload on a node even if the node have a taint such as NetworkUnavailable ? This might seem counter intuitive but apparently there are some advanced scheduling use cases where this could be desired as indicated (here)[https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/taint-node-by-condition.md]
For example, if a CNI network is not detected on the node (e.g. a network is unavailable), the Node Controller will taint the node with node.kubernetes.io/network-unavailable=:NoSchedule. This will then allow users to add a toleration to their PodSpec, ensuring that the pod can be scheduled to this node if necessary. If the kubelet did not update the node’s status after a grace period, the Node Controller will only taint the node with node.kubernetes.io/unreachable; it will not taint the node with any unknown condition.
Digging a little further, the example (here)[https://github.com/kubernetes/kubernetes/issues/45717] describes a real world scenario where this might be applicable:
- Kubelet goes NotReady if the CNI network is not up (or ready).
- The scheduler will ignore this node even if hostNetwork could be used.
To be clear: the node still (it must) have connectivity. The issue here is about a CNI network either 1) not being installed or 2) ready. Think about Calico, kubenet, Weave, etc).
Bottom line: If the workload tolerates (has a taint) for the specific condition, then the scheduler should do it’s job. Another scenario would be for bare metal hosts where adding an overlay might not be desired.
January 2020 will start with a major event by the Release team. Mark your calendars for this one:
Join members of the Kubernetes 1.17 release team on Jan 7th, 2020 to learn about the major features in this release. Register here