Alibaba Cloud Service Mesh:Deploy mesh proxy in native sidecar mode

Why native sidecar mode

In a traditional sidecar deployment, Kubernetes treats the mesh proxy and the application as independent containers with separate lifecycles. This mismatch causes several operational issues:

• Startup race condition -- If the application container starts before the istio-proxy sidecar is ready, the application cannot reach the network. Sidecar Graceful Startup mitigates this, but the issue persists when the sidecar starts slowly.

• Shutdown ordering -- If the istio-proxy sidecar shuts down before the application container, the application loses network access. Sidecar Graceful Shutdown mitigates this but may extend pod termination time.

• Zombie pods from Jobs -- When an application container in a Job exits after the job completes, the sidecar proxy keeps running and prevents the pod from terminating.

• No network for init containers -- Init containers that run before the sidecar proxy starts cannot access the network. One workaround is to exclude specific ports from sidecar traffic redirection.

Native sidecar mode solves all four issues. The mesh proxy is defined as a native sidecar container (an init container with restartPolicy: Always), so Kubernetes guarantees that it:

1. Starts before regular containers and remains running throughout the pod lifecycle.

2. Shuts down only after all regular containers have terminated.

3. Exits automatically when the last regular container exits, preventing zombie pods.

4. Runs before other init containers, giving them network access through the mesh proxy.

Traditional sidecar vs. native sidecar

Verify the deployment mode

To determine which sidecar mode a pod uses, inspect its spec for two indicators: the location of the istio-proxy container and the presence of restartPolicy: Always.

kubectl get pod <pod-name> -o yaml

Replace <pod-name> with the actual pod name.

Native sidecar mode -- The output includes istio-proxy in the initContainers section:

apiVersion: v1
kind: Pod
metadata:
  name: sleep-xxxxxxxx-xxxxx
  namespace: default
spec:
  containers:
    ...
    - image: 'registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2'
      imagePullPolicy: IfNotPresent
      name: sleep
    ...
  initContainers:
    ...
    - image: registry-cn-hangzhou-vpc.ack.aliyuncs.com/acs/proxyv2:v1.22.2.35-ge64ec8af-aliyun
      imagePullPolicy: IfNotPresent
      name: istio-proxy
      ports:
        - containerPort: 15090
          name: http-envoy-prom
          protocol: TCP
      restartPolicy: Always  # Confirms native sidecar mode
    ...

Traditional sidecar mode -- The istio-proxy container appears in the containers field instead of initContainers, and no restartPolicy: Always is set.

In native sidecar mode, lifecycle-related sidecar proxy configurations (such as graceful startup and graceful shutdown) are not required and have no effect. For the full list of sidecar proxy settings, see Configure sidecar proxies.

Switch to traditional sidecar mode

Some third-party MutatingWebhook components configured on Kubernetes of version 8 or earlier can modify the pod definition in ways that conflict with native sidecar containers. For example, KubeSphere's logsidecar-injector can remove the native sidecar definition and cause pod creation failures. If you encounter similar issues, switch to traditional sidecar mode.

Mutating webhooks can modify pods based on various conditions. Before you switch modes, check whether any admission webhooks in your cluster interfere with native sidecar containers.