The last several months have been a busy time for the Kubernetes community, and especially the Kubernetes release team, amid the challenges caused by the ongoing pandemic. The Kubernetes project itself has felt the impact, with the upcoming release of version 1.19 having been postponed and the project’s release schedule adjusted to accommodate the ongoing disruption to people’s lives. Only three new Kubernetes versions, instead of the usual four, will be released this year, and it is unclear whether this will be a permanent change going forward.
With its extended release cycle, the version 1.19 incorporates a number of changes and enhancements that emphasize the maturity and production readiness of Kubernetes, including several notable feature promotions to general availability (e.g., Ingress and seccomp), security enhancements (TLS 1.3 support), and improvements to address technical debt. This post covers the highlights of the release.
Notable New Features and Changes
Ingress goes GA
Introduced as an API in beta all the way back in Kubernetes version 1.1, Ingress handles external access to services in a cluster, exposing HTTP and HTTPS routes. It may also manage load balancing, terminate SSL/TLS, and provide name-based virtual hosting. In order for the Ingress resource to work, an Ingress controller must be used; the Kubernetes project currently supports and maintains GCE and nginx controllers, and a list of additional Ingress controllers is provided here.
In 1.19, Ingress graduates to general availability and is added to the networking v1 APIs. As part of this milestone, there are some key differences in v1 Ingress objects, including schema and validation changes. For example, the pathType field no longer has a default value and must be specified.
For more details, see the following:
PR: ingress: Add Ingress to v1 API and update backend to defaultBackend
seccomp goes GA
Seccomp is a security facility in the Linux kernel for restricting system calls that applications can make. Seccomp was introduced as a Kubernetes feature in alpha back in version 1.3. To date, applying seccomp profiles to pods required using annotations on a PodSecurityPolicy. In 1.19, seccomp is graduating to GA with a new seccompProfile field being added to pod and container securityContext objects. Note that support for the existing annotation is being deprecated and will be removed in version 1.22. Additionally, as part of ensuring Kubelet backwards compatibility, seccomp profiles will be enforced in the following priority order:
- Container-specific field.
- Container-specific annotation.
- Pod-wide field.
- Pod-wide annotation.
In conjunction with this change, the pod sandbox container is also configured with a separate runtime/default seccomp profile.
More details are covered in the following links:
PR: seccomp GA — Add new seccomp fields and update kubelet to use them
PR: Add seccomp least privilege for kuberuntime
KEP: Seccomp to GA
TLS 1.3 support
Kubernetes 1.19 addresses one of the recommendations that came out of the Kubernetes security audit conducted last year and adds support for new TLS 1.3 ciphers that can be used for Kubernetes.
View the relevant PR and security audit findings here:
PR: Add support for TLS 1.3 ciphers
Security audit recommendation: TOB-K8S-037: Kubelet supports insecure TLS ciphersuites
Node debugging
Now available in alpha, running the kubectl alpha debug command will create and run a new pod that runs in the host OS namespaces and can be used to troubleshoot nodes. This allows a user to inspect a running pod without restarting it and without having to enter the container itself to, for example, check the filesystem, execute additional debugging utilities, or initial network requests from the pod network namespace. Part of the motivation for this enhancement is to also eliminate most uses of SSH for node debugging and maintenance.
Learn more at the following resources:
PR: kubectl debug: support debugging nodes
KEP: Node Troubleshooting with Privileged Containers
Admission webhook warnings
With this change in beta in 1.19, admission webhooks can now return non-fatal warnings to API clients making requests. This enhancement is intended to make it easy for users and cluster administrators to recognize problematic API use, including use of deprecated APIs from clients such as kubectl.
The PR and broader proposal can be found at these links:
PR: Admission webhook warnings
KEP: Warning mechanism for use of deprecated APIs
Other notable changes
With the Kubernetes version 1.18 release a few months ago, we covered the release of the Pod Topology Spread feature in beta, which allows for simple definitions of complex pod layouts. A recent change in 1.19 has been added to automatically weight topologies and apply better differentiation between nodes and zones yields more balanced results across constraints.
We also described the new feature, Immutable Secrets and ConfigMaps, in our coverage of version 1.18. That feature has now been promoted to beta.
Another change in 1.19 ensures that the default volume mount created for service account credentials has file permissions that enable increased security while running non-root containers.
Version 1.19 now supports JSON logging output from Kubernetes components by passing the flag --log-format=json.
Finally, in 1.19 Kubernetes has changed terminology to reflect inclusive language.
Notable Deprecations
Hyperkube, an all-in-one binary for Kubernetes components, is now deprecated and will not be built by the Kubernetes project going forward.
Several, older beta API versions are deprecated in 1.19 and will be removed in version 1.22. We will provide a follow-on update since this means 1.22 will likely end up being a breaking release for many end users.
Looking Ahead
One feature enhancement that we have been tracking for some time is support for sidecar containers. This was slated to be released in 1.19 but has been postponed due to additional considerations by Kubernetes SIG-node. This enhancement will have a substantial impact for other projects such as Istio, and we will continue to track and provide updates as it works its way toward release in a future version of Kubernetes.
Summary
We have just highlighted the most notable enhancements in the Kubernetes 1.19 release, focusing on new features that the community has invested considerable effort in to make generally available as well as those that continue to improve the security posture of Kubernetes Check out the official release notes (soon to be published) for a complete list of changes.