Container Service for Kubernetes (ACK) strictly abides by the terms of the Certified Kubernetes Conformance Program. This topic describes the changes made to Kubernetes 1.16.
|Core component||Version||Upgrade notes|
|Kubernetes||1.16.6||In Kubernetes 1.16, the built-in CoreDNS version is 1.6.2. Compared with CoreDNS 1.3.1
in Kubernetes 1.14. the new version has the following changes:
The Corefile will be automatically migrated to match the new CoreDNS version when you upgrade Kubernetes to 1.16.
|Docker||19.03.5 (containerd 1.2.10)||None.|
- Performance optimizations
Compared with Kubernetes 1.14, Kubernetes 1.16.6 has the following performance optimizations.
Compared with previous versions, Docker 19.03.5 has the following improvements:
- Optimizes PodAffinity to improve performance by 100%.
- Optimizes serialization operations. Enhances the performance of the pod list operation by 40%. Enhances the performance of the node list operation by 30%.
- Enhances the performance of processing apply requests that involve large map objects on the server side.
- Optimizes the heartbeat solution based on node leases. Reduces the number of lease queries sent to the API server or etcd by 50,000 per minute in a cluster of 8,000 nodes.
- Dramatically speeds up the pod creation process. When it comes to creating stateless
pods, which does not involve mounting volumes such as ConfigMap or secrets to the
- both Kubernetes 1.16.6 and 1.14 meet the SLAs defined by SIG Scalability. 99% of pods can be started within five seconds given that images are already pulled.
- In the worst-case scenario, it takes Kubernetes 1.14 nearly five seconds to create a pod whereas Kubernetes 1.16.6 needs only three seconds under the same conditions.
Docker 19.03.5 improves runtime stability as follows:
- The built-in buildkit speeds up image builds.
- The runC runtime optimizes systemd detection logic. Containers start faster and occupy less memory.
- Fixes the issue where pods occasionally restart during exec health checks.
- Fixes vulnerability CVE-2018-15664, which is exposed by the docker cp command.
- Fixes the issue where Docker does not respond when a rich container running multiple processes exits.
- Fixes the handle leak issue in containerd.
- Feature enhancements
Compared with Kubernetes 1.14, Kubernetes 1.16.6 has the following important changes.
- The following API versions are not supported by default: extensions/v1beta1, apps/v1beta1,
and apps/v1beta2. apps/v1beta1 and all resources defined in apps/v1beta1 are replaced
by apps/v1. The daemonsets, deployments, and replicasets resources defined in extensions/v1beta1
are replaced by apps/v1. The networkpolicies resource defined in extensions/v1beta1
is replaced by networking.k8s.io/v1.
Note To ensure compatibility with your workloads, Container Service for Kubernetes has added support for the preceding API versions in Kubernetes 1.16.6 and will end the support in Kubernetes 1.18. We recommend that you change the API versions as soon as possible.
- The following kubelet security control parameters are deprecated and removed: AllowPrivileged, HostNetworkSources, HostPIDSources, and HostIPCSources. Instead, access control parameters such as PodSecurityPolicy are added for enhanced security.
- More features have stabilized. For example, CustomResourceDefinitions (CRDs) and admission webhooks are now in general availability.
- The following API versions are not supported by default: extensions/v1beta1, apps/v1beta1, and apps/v1beta2. apps/v1beta1 and all resources defined in apps/v1beta1 are replaced by apps/v1. The daemonsets, deployments, and replicasets resources defined in extensions/v1beta1 are replaced by apps/v1. The networkpolicies resource defined in extensions/v1beta1 is replaced by networking.k8s.io/v1.
- Enhanced stability and performance
- Adds retries for idempotent functions to improve the success rate of cluster creation.
- Existing containers are not restarted during a kubelet upgrade.
- Fixes kubelet startup failures caused by hugetlb.
- Improved observability
- Optimizes logs of liveness probes sent from SLB to apiserver.
- Adjusts the aggregationcontroller log level.
- Optimizes the outputs of the get cs command in managed clusters.
- Optimizes monitoring metrics on sandboxed containers based on compatibility with existing metrics APIs.