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

Por que usar o modo sidecar nativo

Em uma implantação tradicional de sidecar, o Kubernetes trata o proxy de malha e a aplicação como contêineres independentes com ciclos de vida separados. Essa incompatibilidade causa vários problemas operacionais:

• Condição de corrida na inicialização: se o contêiner da aplicação iniciar antes do sidecar istio-proxy ficar pronto, a aplicação não conseguirá acessar a rede. O recurso Inicialização Graceful do Sidecar atenua esse problema, mas ele persiste quando o sidecar demora para iniciar.

• Ordem de encerramento: caso o sidecar istio-proxy seja encerrado antes do contêiner da aplicação, esta perde o acesso à rede. O Encerramento Graceful do Sidecar mitiga essa situação, mas pode prolongar o tempo de término do pod.

• Pods zumbis em Jobs: quando um contêiner de aplicação em um Job termina após a conclusão da tarefa, o proxy sidecar continua em execução e impede o término do pod.

• Falta de rede para contêineres init: contêineres init executados antes do início do proxy sidecar não conseguem acessar a rede. Uma solução alternativa é excluir portas específicas do redirecionamento de tráfego do sidecar.

O modo sidecar nativo resolve todos esses quatro problemas. Como o proxy de malha é definido como um contêiner sidecar nativo (um contêiner init com restartPolicy: Always), o Kubernetes garante que ele:

1. Inicie antes dos contêineres regulares e permaneça em execução durante todo o ciclo de vida do pod.

2. Seja encerrado somente após o término de todos os contêineres regulares.

3. Saia automaticamente quando o último contêiner regular for encerrado, evitando pods zumbis.

4. Execute antes de outros contêineres init, concedendo-lhes acesso à rede por meio do proxy de malha.

Sidecar tradicional versus sidecar nativo

Verifique o modo de implantação

Para identificar qual modo sidecar um pod utiliza, inspecione sua especificação em busca de dois indicadores: a localização do contêiner istio-proxy e a presença de restartPolicy: Always.

kubectl get pod <pod-name> -o yaml

Substitua <pod-name> pelo nome real do pod.

Modo sidecar nativo: a saída inclui istio-proxy na seção 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: o contêiner istio-proxy aparece no campo containers em vez de initContainers, e não há definição de restartPolicy: Always.

No modo sidecar nativo, as configurações de proxy sidecar relacionadas ao ciclo de vida (como inicialização graceful e encerramento graceful) não são necessárias e não têm efeito. Para obter a lista completa de configurações de proxy sidecar, consulte Configure proxies sidecar .

Alterne para o modo sidecar tradicional

Alguns componentes MutatingWebhook de terceiros configurados no Kubernetes versão 8 ou anterior podem modifique a definição do pod e entrar em conflito com contêineres sidecar nativos. Por exemplo, o logsidecar-injector do KubeSphere pode remover a definição de sidecar nativo e causar falhas na criação do pod. Se você encontrar problemas semelhantes, alterne para o modo sidecar tradicional.

Webhooks de mutação podem modifique pods com base em várias condições. Antes de alternar os modos, verifique se algum webhook de admissão em seu cluster interfere nos contêineres sidecar nativos.