What Is New in Kubernetes 1.18
Kubernetes 1.18 delivers a substantial set of enhancements focused on stability and extensibility. This release introduces several long-awaited beta features and refines existing ones to provide a more robust foundation for production workloads.
| Category | Key Highlights |
|---|---|
| New Features | Ingress graduates to V1, Kubernetes Topology Manager reaches Beta, Server-side Apply moves to Beta |
| Improvements | Enhanced Vertical Pod Autoscaling, Expanded Windows Support, Kubectl Debug graduates to Beta |
| API Changes | Introducing the IngressClass resource, deprecating extensions/v1beta1 Ingress |
| Deprecations | Several deprecated APIs are now scheduled for removal in future releases |
What are the major API changes in 1.18?
The most significant API change is the promotion of the Ingress API to networking.k8s.io/v1. This marks its stability and readiness for production use. The old extensions/v1beta1 and networking.k8s.io/v1beta1 Ingress APIs are now deprecated.
Alongside this, a new IngressClass resource is introduced, providing a better way to describe the type of Ingress controller that should be used. This replaces the deprecated kubernetes.io/ingress.class annotation.
How does Server-side Apply work in beta?
Server-side Apply moves to beta, shifting the responsibility of managing object field conflicts from kubectl to the API server. This provides a much clearer and more declarative way to manage resources through their entire lifecycle.
In practice, this means tools and controllers can better understand changes made to objects. The API server tracks which manager (e.g., kubectl, a controller) owns which fields, preventing unexpected overwrites and making collaborative editing safer.
What improvements did Topology Manager get?
The Kubernetes Topology Manager graduated to beta, enhancing performance for latency-sensitive workloads like those using CPUs and NICs. It now ensures that CPU and device allocations (e.g., SR-IOV VFs, GPU devices) are aligned with NUMA locality preferences.
This matters because it reduces cross-NUMA traffic, which can significantly improve application performance. The single-numa-node policy is particularly useful for high-performance computing and network function virtualization workloads.
Can I debug pods better with 1.18?
Yes, kubectl debug graduated to beta, offering a powerful way to troubleshoot running pods. You can now attach an ephemeral debug container to a running pod without restarting it, which is invaluable for investigating issues in production.
The command also supports creating a copy of a problematic pod with debugging changes, such as adding a new container or changing the entrypoint. This eliminates the need to manually craft pod specs just for debugging purposes.
kubectl debug -it my-pod --image=busybox --target=my-pod
What about Windows node support?
Support for Windows nodes continues to expand with improved stability and support for more APIs. Key improvements include support for preserving the service's source IP when using Direct Server Return (DSR) and general enhancements to the kube-proxy.
This release makes running Windows containers on Kubernetes more practical for mixed-OS environments, closing the gap with Linux-based workloads in terms of network functionality and overall reliability.
FAQ
Is the old Ingress API still usable in 1.18?
Yes, the extensions/v1beta1 and networking.k8s.io/v1beta1 Ingress APIs are deprecated but still functional. You should begin migrating your manifests to the stable networking.k8s.io/v1 API.
What is the practical benefit of Server-side Apply?
It prevents field ownership conflicts. If a controller and a human both edit a resource, the API server knows which entity owns which field, eliminating accidental overwrites and making collaborative edits predictable.
When should I use the Topology Manager?
Use it for workloads where low latency and high performance are critical, such as dataplane processing, AI/ML inference, or high-frequency trading. For most general-purpose web services, the default behavior is sufficient.
Does kubectl debug require a special container image?
No, you can use any container image you want. The power comes from attaching a debugging toolset (like busybox or a distroless debug image) to a running pod without affecting its original containers.
Are there any new kubectl commands in this release?
The main addition is the beta status of kubectl debug. Other commands have been refined, but no other major new commands were introduced. The focus was on maturing existing features.