## 4.3.1.1.1.3  Regular and Native Sidecar Containers
Understand the differences between regular and native sidecar containers, learn about the default settings applied by the Istio module, and find out how to override these settings for specific workloads as needed.
## Advantages of Native Sidecar Containers
Every Pod in the Istio mesh gets an additional istio-proxy sidecar container, which intercepts network traffic to provide Istio features. For sidecar proxies, Istio uses two types of sidecar containers: regular sidecars and native sidecars. Native sidecars are init containers that have restartPolicy set to Always. This new approach, introduced with Kubernetes 1.28, allows for controlling the startup and shutdown sequence of containers within a Pod, which is not possible with sidecars deployed as regular containers.
Using native sidecars resolves the following problems that regular sidecars cause:
- When an application container starts before the regular istio-proxy sidecar container is ready, the application doesn't have network access at startup.
- When the regular istio-proxy sidecar stops before the application container stops, the application loses network access during shutdown.
- An init container runs before the regular istio-proxy sidecar container, so it can't access the network.
- A running regular istio-proxy sidecar container prevents Pods from being finished (for example, in the case of Jobs).
## Default Istio Proxy Sidecar Type
The Istio module configures the default type of the istio-proxy sidecar container, which is injected into all Pods that allow for Istio sidecar proxy injection. However, you can override this default setting for a specific Pod, allowing it to use another type of sidecar container regardless of the Istio module's default configuration. The default istio-proxy sidecar type varies depending on the particular version Istio module and the version of Istio:
| Istio module version   | Istio version   | Default Sidecar Type   |
|------------------------|-----------------|------------------------|
| 1.20 or lower          | 1.26 or lower   | Regular sidecars       |
| 1.21                   | 1.27            | Regular sidecars       |
| Istio module version                                   |   Istio version | Default Sidecar Type                                                       |
|--------------------------------------------------------|-----------------|----------------------------------------------------------------------------|
| 1.22                                                   |            1.27 | Native sidecars, unless you set compa- tibilityMode in the Istio CRto true |
| One of the next versions after 1.22 with updated Istio |            1.28 | Native sidecars                                                            |
## Configuring the Type of Istio Sidecar Proxy for a Particular Workload
You can configure the sidecar type explicitly for a particular workload:
- To inject istio-proxy as a native sidecar container, set the sidecar.istio.io/nativeSidecar annotation to "true" on a given Pod or in the Pod template.
- To inject istio-proxy as a regular sidecar container, set the sidecar.istio.io/nativeSidecar annotation to "false" on a given Pod or in the Pod template.
If you do not set the annotation, the default setting is used.
You must set the annotation at the Pod level. So, when a Pod is created by a parent resource (for example, Deployment, StatefulSet, ReplicaSet, DaemonSet, Job, CronJob), you must configure the annotation in the Pod template. See the example:
```
 Sample Code apiVersion: apps/v1 kind: Deployment metadata: name: test-deployment spec: template: metadata: annotations: sidecar.istio.io/nativeSidecar: "true" ...
```
Setting the sidecar type explicitly is especially recommended when a given workload works well only with one sidecar type and causes issues otherwise. This approach guarantees that the sidecar type doesn't change after the Istio module's upgrade. A good example are Job Pods, which can't finish if the main container stops because the istio-proxy sidecar container is still running. In this case, setting the sidecar.istio.io/ nativeSidecar annotation in the Pod template solves the problem.
## Support in the Istio Module
The Istio module fully supports both types of sidecar containers. In particular, during Istio version's update, the module detects which workloads should be restarted and restarts both sidecar types.
## Example of Istio Proxy Running as a Native Sidecar
Follow this example to observe the differences between regular sidecar containers and native sidecar containers.
##  Example
1. Create a namespace with Istio injection enabled:
##  Sample Code
kubectl create ns test kubectl label namespace test istio-injection=enabled
2. Create a workload with istio-proxy running as a native sidecar container:
## 
```
Sample Code kubectl apply -f - <<EOF apiVersion: batch/v1 kind: Job metadata: name: test-job namespace: test spec: template: metadata: annotations: sidecar.istio.io/nativeSidecar: "true" spec: containers: - name: test-job image: alpine:latest command: [ "/bin/sleep", "10" ] restartPolicy: Never EOF
```
3. To observe the progress, run:
## 
## 
```
Sample Code kubectl get pod -n test -w Output Code NAME             READY   STATUS     RESTARTS   AGE test-job-2tt95   0/2     Init:0/2   0          0s test-job-2tt95   0/2     Init:1/2   0          1s test-job-2tt95   0/2     Init:1/2   0          2s test-job-2tt95   0/2     PodInitializing   0          10s test-job-2tt95   1/2     PodInitializing   0          10s test-job-2tt95   2/2     Running           0          11s test-job-2tt95   1/2     Completed         0          21s test-job-2tt95   0/2     Completed         0          22s
```
See the key differences when compared to the istio-proxy run as a regular sidecar container:
- When the Pod starts, it has the Init status with two containers.
- The application container only starts after the istio-proxy native sidecar is fully operational.
- After the main container completes its job, the Pod finishes with the status Completed .
4. List init containers:
##  Sample Code
```
kubectl get pod -n test -o jsonpath='{.items[0].spec.initContainers[*].name}'
```
The output contains two containers, and istio-proxy is now an init container:
##  Output Code
istio-validation istio-proxy
5. List init containers:
## 
```
Sample Code kubectl get pod -n test -o jsonpath='{.items[0].spec.containers[*].name}'
```
The output includes only the application container without istio-proxy :
##  Output Code
test-job
## Known Hacks that Native Sidecars Can Replace
The /quitquitquit call
The istio-proxy sidecar offers an additional endpoint /quitquitquit that you can use in the following way to shut down istio-proxy :
curl -sf -XPOST http://127.0.0.1:15020/quitquitquitCopy to clipboardErrorCopied Using the endpoint is no longer required if istio-proxy runs as a native sidecar. Its lifecycle is bound to the main application container, so the istio-proxy sidecar shuts down automatically when the main container is finished.
The solution was proposed under issue #6324 .
runAsUser 1337 , or excludeOutboundIPRanges , or excludeOutboundPorts
Init containers are started before regular containers are started. This means that the istio-proxy running as a regular sidecar doesn't work when init containers are running. As a result init containers don't have network access.
By configuring UID 1337 , excludeOutboundIPRanges , or excludeOutboundPorts you can exclude the network traffic from being captured by the istio-proxy . This allows init containers to access the network, but they are able to connect only to resources outside service mesh.
This is no longer required if istio-proxy runs as a native sidecar because the istio-proxy is injected as the first init container and runs until the main application container finishes. So, init containers are able to access the network in the same way as regular application containers, and they may connect to resources inside and outside the service mesh.
The solution was proposed in the blog post Upcoming breaking change in SAP BTP, Kyma Runtime: Enabling the Istio CNI plugin .
## Related Information
Kubernetes v1.28: Introducing native sidecar containers Kubernetes Native Sidecars in Istio