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

Pourquoi utiliser le mode sidecar natif

Dans un déploiement sidecar traditionnel, Kubernetes traite le proxy de maillage et l'application comme des conteneurs indépendants dotés de cycles de vie distincts. Cette discordance entraîne plusieurs problèmes opérationnels :

• Condition de concurrence au démarrage -- Si le conteneur d'application démarre avant que le sidecar istio-proxy ne soit prêt, l'application ne peut pas accéder au réseau. La section Démarrage progressif du sidecar atténue ce problème, mais celui-ci persiste lorsque le sidecar démarre lentement.

• Ordre d'arrêt -- Si le sidecar istio-proxy s'arrête avant le conteneur d'application, l'application perd l'accès au réseau. La section Arrêt progressif du sidecar atténue ce problème, mais peut prolonger le temps de terminaison du pod.

• Pods zombies issus des Jobs -- Lorsqu'un conteneur d'application dans un Job se termine après l'exécution de la tâche, le proxy sidecar continue de s'exécuter et empêche la terminaison du pod.

• Absence de réseau pour les conteneurs d'initialisation -- Les conteneurs d'initialisation qui s'exécutent avant le démarrage du proxy sidecar ne peuvent pas accéder au réseau. Une solution de contournement consiste à exclure certains ports de la redirection du trafic sidecar.

Le mode sidecar natif résout ces quatre problèmes. Le proxy de maillage est défini comme un conteneur sidecar natif (un conteneur d'initialisation avec restartPolicy: Always). Kubernetes garantit ainsi les comportements suivants :

1. Il démarre avant les conteneurs standards et reste en cours d'exécution tout au long du cycle de vie du pod.

2. Il ne s'arrête qu'après la terminaison de tous les conteneurs standards.

3. Il se termine automatiquement lorsque le dernier conteneur standard se termine, évitant ainsi les pods zombies.

4. Il s'exécute avant les autres conteneurs d'initialisation, leur permettant d'accéder au réseau via le proxy de maillage.

Sidecar traditionnel contre sidecar natif

Vérifier le mode de déploiement

Pour déterminer le mode sidecar utilisé par un pod, inspectez sa spécification à la recherche de deux indicateurs : l'emplacement du conteneur istio-proxy et la présence de restartPolicy: Always.

kubectl get pod <pod-name> -o yaml

Remplacez <pod-name> par le nom réel du pod.

Mode sidecar natif -- La sortie inclut istio-proxy dans la section 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
    ...

Mode sidecar traditionnel -- Le conteneur istio-proxy apparaît dans le champ containers au lieu de initContainers, et aucun restartPolicy: Always n'est défini.

En mode sidecar natif, les configurations du proxy sidecar liées au cycle de vie (telles que le démarrage et l'arrêt progressifs) ne sont pas nécessaires et n'ont aucun effet. Pour la liste complète des paramètres du proxy sidecar, consultez la section Configurer les proxys sidecar .

Passer au mode sidecar traditionnel

Certains composants MutatingWebhook tiers configurés sur Kubernetes version 8 ou antérieure peuvent modifier la définition du pod d'une manière incompatible avec les conteneurs sidecar natifs. Par exemple, le composant logsidecar-injector de KubeSphere peut supprimer la définition du sidecar natif et provoquer des échecs de création de pod. Si vous rencontrez des problèmes similaires, passez au mode sidecar traditionnel.

Les webhooks mutants peuvent modifier les pods en fonction de diverses conditions. Avant de changer de mode, vérifiez si des webhooks d'admission dans votre cluster interfèrent avec les conteneurs sidecar natifs.