updated the content as per the review comments

content/en/docs/concepts/workloads/pods/init-containers.md

@@ -328,6 +328,10 @@ limit.
 Pod level control groups (cgroups) are based on the effective Pod request and
 limit, the same as the scheduler.
 
+{{< note >}}
+This section also present under [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) page.
+{{< /note >}}
+
 ### Pod restart reasons
 
 A Pod can restart, causing re-execution of init containers, for the following

content/en/docs/concepts/workloads/pods/sidecar-containers.md

@@ -7,25 +7,22 @@ weight: 50
 <!-- overview -->
 {{< feature-state for_k8s_version="v1.28" state="alpha" >}}
 
-Sidecar containers are the secondary containers that runs along with the main
+Sidecar containers are the secondary containers that run along with the main
 application container within the same {{< glossary_tooltip text="Pod" term_id="pod" >}}.
-These containers are used to enhance or extend the functionality of the primary container
-by providing additional services, or functionality such as logging, monitoring, security,
-or data synchronization, without directly altering the primary application code.
+These containers are used to enhance or to extend the functionality of the main application
+container by providing additional services, or functionality such as logging, monitoring,
+security, or data synchronization, without directly altering the primary application code.
 
 <!-- body -->
 
-Starting with Kubernetes 1.28 in alpha, a feature gate named `SidecarContainers`
-allows you to specify a `restartPolicy` for containers listed with a Pod's `initContainers`
-field. These restartable _sidecar_ containers are independent of other
-[init containers](/docs/concepts/workloads/pods/init-containers/) and main application
-container within the same pod. These can be started, stopped, or restarted independently
-of the main container and other init containers.
-Container [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)
-can also be added to control their lifecycle.
+Starting with Kubernetes 1.28, a feature gate named `SidecarContainers` allows you to
+specify a `restartPolicy` for containers listed in a Pod's `initContainers` field. These
+restartable _sidecar_ containers are independent with other [init containers](/docs/concepts/workloads/pods/init-containers/) and main application container within
+the same pod. These can be started, stopped, or restarted without effecting the main
+application container and other init containers.
 
 If an init container is created with its `restartPolicy` set to `Always`, it will
-start and remain running during the entire life of the Pod, which is useful for
+start and remain running during the entire life of the Pod. This can be helpful for
 running supporting services separated from the main application containers.
 
 If a `readinessProbe` is specified for this init container, its result will be used
@@ -56,9 +53,8 @@ has finished.
 Here's an example of a Job with two containers, one of which is a sidecar:
 
 {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}}
-By default, this feature is not available in Kubernetes. To avail this feature,
-we need to enable the feature gate `SidecarContainers` by setting the value **true**
-to it.
+By default, this feature is not available in Kubernetes. To avail this feature, you
+need to enable the feature gate named `SidecarContainers` by setting the value **true** to it.
 
 ## Differences from regular containers
 
@@ -80,17 +76,39 @@ providing additional services.
 
 Sidecar containers run concurrently with the main application container. They are active
 throughout the lifecycle of the pod and can be started and stopped independently of the
-main container.
+main container. Unlike [init containers](/docs/concepts/workloads/pods/init-containers/),
+sidecar containers support [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle.
 
 These containers can interact directly with the main application containers, sharing
 the same network namespace, filesystem, and environment variables. They work closely
 together to provide additional functionality.
 
 ## Resource sharing within containers
 
-Given the ordering and execution for init containers, there are certain rules
-for resource usage apply. [Resource sharing within containers](/docs/concepts/workloads/pods/init-containers/#resource-sharing-within-containers) under init
-containers page explains more details on this.
+Given the ordering and execution for init containers, the following rules
+for resource usage apply:
+
+* The highest of any particular resource request or limit defined on all init
+  containers is the *effective init request/limit*. If any resource has no
+  resource limit specified this is considered as the highest limit.
+* The Pod's *effective request/limit* for a resource is the higher of:
+  * the sum of all app containers request/limit for a resource
+  * the effective init request/limit for a resource
+* Scheduling is done based on effective requests/limits, which means
+  init containers can reserve resources for initialization that are not used
+  during the life of the Pod.
+* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the
+  QoS tier for init containers and app containers alike.
+
+Quota and limits are applied based on the effective Pod request and
+limit.
+
+Pod level control groups (cgroups) are based on the effective Pod request and
+limit, the same as the scheduler.
+
+{{< note >}}
+This section also present under [init containers](/docs/concepts/workloads/pods/init-containers/) page.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}