These changes include the following:Ĭoncurrent API server and etcd scale ups: In the past, when the control plane needed to be scaled we would wait for the control plane nodes to be scaled before scaling etcd. Multiple engineering teams implemented several changes that together increased the speed. With our latest updates, the control plane can now scale in 10 minutes or less, which represents a 4x improvement. Long scaling delays could cause API and etcd latencies to increase or even cause the API server to become temporarily unresponsive. This time was felt most acutely by customers whose requests to the kube-apiserver steadily increased (linear growth). Previously, control plane scaling could take as long as 50 minutes.
The latest enhancement involves reducing the amount of time it takes to scale the control plane. Since introducing control plane auto scaling, we’ve been looking at ways to further improve the scaling experience for our customers. These enhancements are a great example of the flywheel effect where AWS releases a feature in response to customer feedback, solicits feedback from end users about its impact, and uses that feedback to continue improving the customer experience. Now we use a variety of metrics to scale the control plane, including the number of worker nodes and the size of the etcd database. As we learned how the control plane behaved under different conditions, we adjusted our metrics to make scaling more responsive. At first, we used basic metrics such as CPU/memory for scaling. Today, the control plane is scaled automatically when certain metrics are exceeded. When this happened, they had to file a ticket with AWS support to have their cluster control plane resized. However, as usage of EKS grew, we discovered there were customers who occasionally exceeded the provisioned capacity of the cluster. This initially included automated upgrades, patching, and backups, which we often refer to as “undifferentiated heavy lifting.” We analyzed volumes of data to create a control plane that would work for the vast majority of our customers. When EKS launched in 2018, it aimed to reduce our customers’ operational burden by offering a managed control plane for Kubernetes. Many of them were running self-managed clusters on Amazon Elastic Computer Cloud (EC2) and were having challenges upgrading, scaling, and maintaining the Kubernetes control plane. Years before Amazon Elastic Kubernetes Service (EKS) was released, our customers told us they wanted a service that would simplify Kubernetes management.
0 kommentar(er)
