What’s New in Kubernetes 1.14? A Structured Deep‑Dive into Windows Support, Local PV, and Core Enhancements

Kubernetes 1.14.0 was officially released on March 25, bringing a substantial set of new features and improvements. Because the release notes are voluminous, the article categorizes the changes by theme to help readers quickly grasp the most important technical updates.

Windows Node Production‑Ready

Pods now support readiness and liveness probes, multi‑container pods with process isolation and shared volumes, native ConfigMap and Secret handling, emptyDir, and resource quotas. Some features such as graceful termination, termination messages, privileged containers, HugePages, and pod eviction policies are still missing.

Services can expose DNS‑based environment variables and support NodePort, ClusterIP, LoadBalancer, and Headless types, but hostNetwork mode is not yet supported on Windows.

All standard workload controllers (ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, CronJob) work with Windows containers.

Additional capabilities include pod‑ and container‑level metrics, Horizontal Pod Autoscaler, kubectl exec, preemption, resource quotas, and CNI networking. Windows host OS version must match the container image OS; 1.14 supports Windows Server 2019, with future Hyper‑V isolation planned.

Major cloud providers, such as Alibaba Cloud Container Service (ACK), have already added Windows container support for mixed Linux/Windows workloads.

Local Persistent Volumes (Local PV) GA

Local PV allows Kubernetes to use host‑attached storage (e.g., SSDs) for persistent volumes, offering lower latency, higher stability, and lower cost compared to remote storage—especially beneficial for databases and search engines.

Local PV is now GA in 1.14, but users must handle risks: no dynamic provisioning in the open‑source solution, the scheduler requires extra logic to ensure sufficient disk capacity, and fault tolerance is limited—node or disk failures can cause data loss.

Alibaba Cloud’s local-volume-provisioner can automate SSD/NVMe volume creation, but robustness remains a challenge.

Pod Priority and Preemption Stabilized

Priority and preemption ensure high‑priority pods can displace lower‑priority ones when resources are scarce. The article explains how priority influences scheduling order and how the preemption mechanism evicts lower‑priority pods to make room for urgent workloads, noting complexities such as node selection, starvation avoidance, affinity constraints, and cross‑node preemption.

Pod Readiness Gates (Pod Ready++)

Prior to 1.14, a pod was considered Ready if all its containers were running. The new Readiness Gates feature lets users attach external checks (e.g., Service, DNS, storage readiness) via a custom controller, providing a more accurate readiness signal.

Native Application Management – Kustomize Built‑In

Kustomize is now a built‑in kubectl subcommand, enabling overlay‑based YAML generation without Helm‑style string substitution. This supports Git‑style workflows (fork/modify/rebase) for managing large numbers of manifests.

kubectl Usability Improvements

Wildcard support for kubectl cp to copy multiple files.

New kubectl auth can-i --list --namespace=ns1 to list RBAC permissions for a namespace.

Ability to delete resources across all namespaces with kubectl delete xxx --all-namespaces, combined with label and field selectors for precise bulk deletions.

Stability Enhancements

Graceful pod eviction replaces forced etcd deletions.

Kubelet now stops unknown‑state containers before recreating them, preventing duplicate instances.

Fixes for high‑disk‑IO pods causing node Ready/NotReady flapping and related massive pod evictions.

Resolution of a Kubelet deadlock caused by event‑channel overload under heavy load.

Large‑Scale Performance Optimizations

kubectl

now performs parallel API server resource discovery, yielding >10× speedup in large clusters.

APIServer limits PATCH request size to 10,000 operations to protect against overload and mitigate CVE‑2019‑1002100.

Aggregated API spec merging has been dramatically accelerated, improving API server CPU usage by an order of magnitude.

All referenced enhancements include links to the corresponding GitHub enhancement proposals or pull requests for further technical details.