rename blog to recent devs in kubelet to speed up pod startup and update according to comments

Author: pacoxu

content/en/blog/_posts/2023-04-02-how-to-speed-up-pod-startup-from-kubelet-side.md renamed to content/en/blog/_posts/2023-03-22-recent-developments-in-kubelet-to-speed-up-pod-startup.md

@@ -1,15 +1,15 @@
 ---
 layout: blog
-title: "How to speed up pod startup from kubelet side? "
-date: 2023-04-02T16:00:00+0000
+title: "Recent developments in kubelet to speed up Pod startup"
+date: 2023-03-21T16:00:00+0000
 slug: speed-up-pod-startup
 ---
 
-**Author**: Paco Xu(DaoCloud), Sergey Kanzhelev, Ruiwen Zhao(Google)
+**Authors**: Paco Xu(DaoCloud), Sergey Kanzhelev(Google), Ruiwen Zhao(Google)
 
 How can pod start-up time be accelerated on nodes in large clusters? This is a common issue that cluster administrators may face.
 
-This blog post focuses on methods to speed up pod start-up from the kubelet side. It does not involve the creation time of pods by controller-manager through kube-apiserver, nor does it include scheduling time for pods.
+This blog post focuses on methods to speed up pod start-up from the kubelet side. It does not involve the creation time of pods by controller-manager through kube-apiserver, nor does it include scheduling time for pods or webhooks executed on it.
 
 We have mentioned some important factors here to consider from the kubelet's perspective, but this is not an exhaustive list. As Kubernetes v1.27 is set to release soon, this blog will highlight significant changes in v1.27 that aid in speeding up pod start-up.
 
@@ -25,25 +25,26 @@ We are introducing a new feature in kubelet that sets a limit on the number of p
 
 To limit the number of simultaneous image pulls, you can configure the `maxParallelImagePulls` field in kubelet. By setting `maxParallelImagePulls` to a value of _n_, only _n_ images will be pulled concurrently. Any additional image pulls beyond this limit will wait until at least one ongoing pull is complete.
 
-More detials can be found in the KEP <https://kep.k8s.io/3673>.
+You can find more details in the associated KEP: [Kubelet limit of Parallel Image Pulls](https://kep.k8s.io/3673)
+ (KEP-3673). The improvement will arrive as part of Kubernetes v1.27 (scheduled for release in April 2023).
 
-## bump default API QPS limits for Kubelet
+## Raised default API query-per-second limits for kubelet
 
-To improve pod startup in scenarios with multiple pods on a node, particularly sudden scaling situations, it is necessary for Kubelet to synchronize the pod status and prepare configmaps, secrets or volumes. This requires a large bandwidth to access kube-apiserver.
+To improve pod startup in scenarios with multiple pods on a node, particularly sudden scaling situations, it is necessary for Kubelet to synchronize the pod status and prepare configmaps, secrets, or volumes. This requires a large bandwidth to access kube-apiserver.
 
 In versions prior to v1.27, the default `kubeAPIQPS` was 5 and `kubeAPIBurst` was 10. However, Kubelet has increased these defaults to 50 and 100 respectively for better performance during pod startup. It's worth noting that this isn't the only reason why we've bumped up the API QPS limits for Kubelet.
 
 1. It has a potential to be hugely throttled now (default QPS = 5)
 2. In large clusters they can generate significant load anyway as there are a lot of them
 3. They have a dedicated PriorityLevel and FlowSchema that we can easily control
 
-In old days, we always encounter `volume mount timeout` on kubelet in node with more than 50 pods during pod start up. We suggest our customers to bump 3 or 4 times of kube api QPS and especially with customers that is using bare-metal(physical machines).
+In old days, we always encounter `volume mount timeout` on kubelet in node with more than 50 pods during pod start up. We suggest our customers to bump `kubeAPIQPS` to 20 and `kubeAPIBurst` to 40 and especially with customers that is using bare-metal(physical machines).
 
 More detials can be found in the KEP <https://kep.k8s.io/1040> and <https://github.com/kubernetes/kubernetes/pull/116121>.
 
-## Evented PLEG will enhance the scalability of kubelet
+## Event triggered updates to container status
 
-`Evented PLEG` is set to be in beta for v1.27, enabled by default. It aids pod startup in large clusters by reducing unnecessary work during inactivity through replacing periodic polling. The current `Generic PLEG` incurs non-negligible overhead due to frequent container status polling, which worsens with Kubelet's parallelism, leading to poor performance and reliability issues. For these reasons, it is recommended that we use Evented PLGE instead. Further details can be found in the KEP <https://kep.k8s.io/3386>.
+`Evented PLEG` (PLEG is short for "Pod Lifecycle Event Generator") is set to be in beta for v1.27, disabled by default (needs to be enabled explicitly). It aids pod startup by reducing unnecessary work during inactivity through replacing periodic polling. The current `Generic PLEG` incurs non-negligible overhead due to frequent container status polling, which worsens with Kubelet's parallelism, leading to poor performance and reliability issues. For these reasons, it is recommended that we use Evented PLEG instead. Further details can be found in the KEP <https://kep.k8s.io/3386>.
 
 ## What's more?