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

Ventajas del modo sidecar nativo

En un despliegue tradicional de sidecar, Kubernetes trata al proxy de malla y a la aplicación como contenedores independientes con ciclos de vida separados. Esta diferencia provoca varios problemas operativos:

• Condición de carrera en el inicio: si el contenedor de la aplicación se inicia antes de que el sidecar istio-proxy esté listo, la aplicación no puede acceder a la red. Sidecar Graceful Startup mitiga este problema, pero la situación persiste cuando el sidecar tarda en iniciarse.

• Orden de apagado: si el sidecar istio-proxy se detiene antes que el contenedor de la aplicación, esta pierde el acceso a la red. Sidecar Graceful Shutdown mitiga esto, aunque puede prolongar el tiempo de finalización del pod.

• Pods zombi por Jobs: cuando un contenedor de aplicación dentro de un Job termina tras completar su tarea, el proxy sidecar sigue ejecutándose e impide que el pod finalice.

• Falta de red para contenedores de inicialización: los contenedores init que se ejecutan antes del inicio del proxy sidecare no tienen acceso a la red. Una solución alternativa consiste en exclude specific ports from sidecar traffic redirection.

El modo sidecar nativo resuelve estos cuatro problemas. El proxy de malla se define como un contenedor sidecar nativo (un contenedor init con restartPolicy: Always), por lo que Kubernetes garantiza que:

1. Se inicie antes que los contenedores regulares y permanezca en ejecución durante todo el ciclo de vida del pod.

2. Se detenga únicamente después de que todos los contenedores regulares hayan terminado.

3. Finalice automáticamente cuando el último contenedor regular termine, lo que evita la creación de pods zombi.

4. Se ejecute antes que otros contenedores init y les proporcione acceso a la red a través del proxy de malla.

Comparación entre sidecar tradicional y sidecar nativo

Comprobación del modo de despliegue

Para determinar qué modo sidecar utiliza un pod, revise su especificación en busca de dos indicadores: la ubicación del contenedor istio-proxy y la presencia de restartPolicy: Always.

kubectl get pod <pod-name> -o yaml

Reemplace <pod-name> con el nombre real del pod.

Modo sidecar nativo: la salida incluye istio-proxy en la sección initContainers:

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
    ...

Modo sidecar tradicional: el contenedor istio-proxy aparece en el campo containers en lugar de initContainers, y no se establece restartPolicy: Always.

En el modo sidecar nativo, las configuraciones del proxy sidecar relacionadas con el ciclo de vida (como el inicio gradual y el apagado gradual) no son necesarias y no surten efecto. Para consultar la lista completa de ajustes del proxy sidecar, consulte Configure sidecar proxies .

Cambio al modo sidecar tradicional

Algunos componentes MutatingWebhook de terceros configurados en Kubernetes versión 8 o anterior pueden modificar la definición del pod de manera que entre en conflicto con los contenedores sidecar nativos. Por ejemplo, el componente logsidecar-injector de KubeSphere puede eliminar la definición del sidecar nativo y provocar fallos en la creación del pod. Si encuentra problemas similares, cambie al modo sidecar tradicional.

Los webhooks mutantes pueden modificar los pods según diversas condiciones. Antes de cambiar de modo, compruebe si algún webhook de admisión en su clúster interfiere con los contenedores sidecar nativos.