Alibaba Cloud Service Mesh:Configure sidecar proxies

Descrição do parâmetro

Este parâmetro calcula automaticamente os recursos do sidecar com base nos contêineres de aplicação. Ativar este parâmetro substitui as Resource settings for injected Istio proxies. Esse recurso aloca recursos aos sidecars com base na configuração máxima de recursos dos contêineres de aplicação, permitindo que os recursos do sidecar sejam ajustados dinamicamente para diferentes Pods. As seguintes estratégias de cálculo são suportadas:

• Recursos máximos do contêiner: O sistema percorre todos os contêineres no Pod e usa o maior valor de recurso como base de cálculo.

• Nome do contêiner especificado: O sistema usa os recursos do contêiner com o nome especificado no Pod como base de cálculo. Para usar essa estratégia, especifique um contêiner como base de cálculo. Se o contêiner especificado não for encontrado no Pod, serão usados os recursos do sidecar configurados em Resource settings for injected Istio proxies. Além disso, se o Pod contiver a anotação scaled-resource.inject.istio.alibabacloud.com/container-ref, o contêiner definido na anotação terá precedência como base de cálculo.

Exemplo de configuração

Os exemplos a seguir mostram os efeitos reais de diferentes porcentagens de recursos em diferentes cenários. A configuração de exemplo do contêiner é a seguinte:

resources:
  requests:
    cpu: 300m
    memory: 512Mi
  limits:
    cpu: 500m
    memory: 1Gi

resources:
  limits:
    cpu: 500m
    memory: 1Gi

resources:
  requests:
    cpu: 300m
    memory: 512Mi

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Resource Settings.

2. Na seção Resource Settings, selecione Configure sidecar resources by ratio.

3. Configure a Proportion of Resources, selecione a Computing Policy (opcional) e clique em Update Settings.

   Selecione a estratégia de cálculo de Maximum Resource Capacity ou Specify a container name. conforme suas necessidades.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Visualize os recursos do proxy Istio configurados.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   Configuração normal de aplicação

   Configuração normal Se a porcentagem de recursos for definida como 50, o que significa que o sidecar obtém 50% dos recursos configurados para o contêiner de aplicação, a alocação final de recursos do sidecar será: ... resources: requests: cpu: 150m memory: 256Mi limits: cpu: 250m memory: 512Mi

   Configuração mínima Se a porcentagem de recursos for definida como 20, o que significa que o sidecar obtém 20% dos recursos configurados para o contêiner de aplicação, a alocação final de recursos do sidecar será: ... resources: requests: cpu: 100m memory: 128Mi limits: cpu: 100m memory: 204Mi

   Sem requests configurado

   Se a porcentagem de recursos for definida como 50, o que significa que o sidecar obtém 50% dos recursos configurados para o contêiner de aplicação, a alocação final de recursos do sidecar será:

   ...
   resources:
     requests:
       cpu: 100m
       memory: 128Mi
     limits:
       cpu: 250m
       memory: 512Mi

   Sem limits configurado

   Se a porcentagem de recursos for definida como 50, o que significa que o sidecar obtém 50% dos recursos configurados para o contêiner de aplicação, a alocação final de recursos do sidecar será:

   ...
   resources:
     requests:
       cpu: 150m
       memory: 256Mi

Descrição do parâmetro

Este parâmetro especifica os recursos mínimos de CPU e memória que o contêiner istio-init requer em tempo de execução e os recursos máximos de CPU e memória que o contêiner pode solicitar em Pods nos quais proxies sidecar são injetados. O contêiner istio-init é um contêiner de inicialização executado quando um Pod com um proxy sidecar injetado é iniciado. Ele configura regras de roteamento de interceptação de tráfego para o contêiner do proxy sidecar.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Resource Settings.

2. (Opcional) Na seção Resource Settings, selecione Configure Resources for istio-init Container.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Em Limits on Resources, defina CPU como 1 núcleo e Memory como 512 MiB. Em Required Resources, defina CPU como 0,1 núcleos e Memory como 128 MiB. Em seguida, clique em Update Settings na parte inferior da página.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Visualize os recursos do contêiner init istio-init configurados.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             cpu: '1'
             memory: 512Mi
           requests:
             cpu: 100m
             memory: 128Mi
   ...

   Se o campo resources do contêiner init chamado istio-init no Pod estiver definido com os valores de recurso alvo, a configuração Configure Resources for istio-init Container entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica os recursos dinâmicos overcommit do ACK alocados ao proxy Istio injetado e ao contêiner init istio-init. Para mais informações sobre recursos dinâmicos overcommit, consulte Enable dynamic resource overcommitment.

Este parâmetro é configurado da mesma forma que as Resource settings for injected Istio proxies e as Resource settings for the istio-init init container. Após a configuração, se um Pod tiver o label koordinator.sh/qosClass de recursos dinâmicos overcommit do ACK, recursos dinâmicos overcommit do ACK serão alocados ao proxy Istio e ao contêiner init istio-init no Pod, em vez de recursos regulares de CPU e memória do Kubernetes.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado, clique em Resource Settings, selecione Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy, configure os parâmetros relacionados e clique em Update Settings na parte inferior da página.

   Parâmetro	Subparâmetro	Descrição
   Configure Resources for Injected Sidecar Proxy (ACK Dynamically Overcommitted Resources)	Limits on Resources	Defina CPU como 2000 milinúcleos e Memory como 2048 MiB.
   	Required Resources	Defina CPU como 200 milinúcleos e Memory como 256 MiB.
   istio-init container resource (ACK dynamic oversold resource)	Limits on Resources	Defina CPU como 1000 milinúcleos e Memory como 1024 MiB.
   	Required Resources	Defina CPU como 100 milinúcleos e Memory como 128 MiB.

2. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

3. Execute o comando a seguir para visualize os recursos do contêiner init istio-init configurados.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   metadata:
   ...
     labels:
       koordinator.sh/qosClass: BE
   spec:
     containers:
       - args:
   ...
         name: istio-proxy
   ...
         resources:
           limits:
             kubernetes.io/batch-cpu: 2k
             kubernetes.io/batch-memory: 2Gi
           requests:
             kubernetes.io/batch-cpu: '200'
             kubernetes.io/batch-memory: 256Mi
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             kubernetes.io/batch-cpu: 1k
             kubernetes.io/batch-memory: 1Gi
           requests:
             kubernetes.io/batch-cpu: '100'
             kubernetes.io/batch-memory: 128Mi
   ...

   O contêiner istio-proxy (contêiner do proxy Istio) e o contêiner init istio-init no Pod contêm o campo resources definido com os valores de recurso alvo. Isso indica que a configuração Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica o número de threads de trabalho do contêiner do proxy sidecar. Especifique um número inteiro não negativo como o número de threads de trabalho. Se você definir este parâmetro como 0, o número de threads de trabalho será determinado automaticamente com base nos recursos de CPU solicitados ou no limite de recursos de CPU configurado para o proxy sidecar. O limite de recursos tem precedência sobre os recursos solicitados.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Resource Settings.

2. (Opcional) Na seção Resource Settings, selecione Number of Sidecar Proxy Threads.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Number of Sidecar Proxy Threads como 3 e clique em Update Settings na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar executa três threads de trabalho em tempo de execução.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize a concorrência do Istio-Proxy configurada.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
   ...
         name: istio-proxy
   ...

   O parâmetro concurrency do contêiner istio-proxy está definido como 3. Isso indica que a configuração Number of Sidecar Proxy Threads entrou em vigor.

Descrição do parâmetro

Especifique uma lista de intervalos de endereços IP separados por vírgulas (,). Cada intervalo de endereços IP deve estar em notação CIDR. Quando uma workload com um proxy sidecar injetado acessa outros serviços, apenas as solicitações cujos endereços IP de destino estejam dentro dos intervalos de endereços configurados são interceptadas pelo contêiner do proxy sidecar. Outras solicitações são enviadas diretamente aos destinos sem passar pelo proxy sidecar. Por padrão, este parâmetro é definido como *, o que indica que o contêiner do proxy sidecar intercepta todo o tráfego de saída da workload.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Addresses to Which External Access Is Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Addresses to Which External Access Is Redirected to Sidecar Proxy como 192.168.0.0/16,10.1.0.0/24 e clique em Update Settings na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar intercepta solicitações cujos endereços IP de destino estejam dentro dos dois blocos CIDR 192.168.0.0/16 e 10.1.0.0/24.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize os intervalos de endereços para interceptação de tráfego de saída configurados.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '192.168.0.0/16,10.1.0.0/24'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   Os parâmetros de runtime do contêiner istio-init incluem -i 192.168.0.0/16,10.1.0.0/24. Isso indica que a configuração Addresses to Which External Access Is Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Addresses to Which External Access Is Not Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Addresses to Which External Access Is Not Redirected to Sidecar Proxy como 10.1.0.0/24 e clique em Update Settings na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar não intercepta solicitações cujos endereços IP de destino estejam dentro do bloco CIDR 10.1.0.0/24.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize os intervalos de endereços excluídos da interceptação de tráfego de saída configurados.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - '192.168.0.1/32,10.1.0.0/24'
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   Os parâmetros de runtime do contêiner istio-init incluem -x 192.168.0.1/32,10.1.0.0/24. 192.168.0.1/32 é o bloco CIDR de endereço de host padrão. 10.1.0.0/24 corresponde ao intervalo de endereços IP configurado para o proxy sidecar. Isso indica que a configuração Addresses to Which External Access Is Not Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Especifique uma lista de portas separadas por vírgulas (,). O tráfego destinado às portas na lista é interceptado pelo contêiner do proxy sidecar. Por padrão, este parâmetro é definido como *, o que indica que o contêiner do proxy sidecar intercepta todo o tráfego de entrada da workload.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Ports on Which Inbound Traffic Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Ports on Which Inbound Traffic Redirected to Sidecar Proxy como 80.443 e clique em Update Settings.

   Essa configuração indica que o contêiner do proxy sidecar intercepta apenas as solicitações enviadas para a porta 80 e a porta 443 da workload.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize as portas de interceptação de tráfego de entrada configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '80,443'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Os parâmetros de runtime do contêiner istio-init incluem -b 80,443, que corresponde às portas de entrada configuradas para o proxy sidecar. Isso indica que a configuração Ports on Which Inbound Traffic Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Ports on Which Outbound Traffic Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Ports on Which Outbound Traffic Redirected to Sidecar Proxy como 80.443 e clique em Update Settings na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar intercepta solicitações enviadas para serviços na porta 80 e na porta 443.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize as portas de interceptação de tráfego de saída configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-q'
           - '80,443'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Os parâmetros de runtime do contêiner istio-init incluem -q 80,443, que corresponde às portas de saída configuradas para o proxy sidecar. Isso indica que a configuração Ports on Which Outbound Traffic Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy como 8000 e clique em Update Settings na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar deixa de interceptar solicitações enviadas para a porta 8000 da workload.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize as portas de bypass de tráfego de entrada configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020,8000'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   Os parâmetros de runtime do contêiner istio-init incluem -d 15090,15021,15081,9191,8000. As portas 15090,15021,15081,9191 são as portas de aplicação do proxy sidecar e são excluídas da interceptação por padrão. A porta 8000 corresponde às portas de entrada configuradas para o proxy sidecar. Isso indica que a configuração Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Especifique uma lista de portas separadas por vírgulas (,), que representa as portas de service de destino de todo o tráfego de saída. Solicitações cujas portas de service de destino estejam na lista não são interceptadas pelo contêiner do proxy sidecar, independentemente de o endereço IP de destino estar dentro dos intervalos de endereços de saída interceptados ou de a porta de destino estar na lista de portas de saída interceptadas.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Opcional) Na seção Enable/Disable Sidecar Proxy by Ports or IP Addresses, selecione Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global.

3. Defina Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy como 8000 e clique em Update Configurations na parte inferior da página.

   Essa configuração indica que o contêiner do proxy sidecar deixa de interceptar solicitações enviadas para serviços na porta 8000.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize as portas de bypass de tráfego de saída configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-o'
           - '8000'
   ...
         name: istio-init
   ...
                               

   Os parâmetros de runtime do contêiner istio-init incluem -o 8000, que corresponde às portas de saída configuradas para o proxy sidecar. Isso indica que a configuração Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy entrou em vigor.

Descrição do parâmetro

Ative ou desative o recurso de proxy DNS para contêineres de proxy sidecar. Após ative o recurso de proxy DNS, os contêineres de proxy sidecar interceptam as solicitações DNS das workloads para melhorar o desempenho e a disponibilidade do Service Mesh. Todas as solicitações das workloads são redirecionadas para o contêiner do proxy sidecar. Como os contêineres de proxy sidecar armazenam localmente os mapeamentos entre endereços IP e nomes de domínio locais, eles podem retornar respostas DNS diretamente às workloads sem enviar solicitações para serviços DNS remotos. Se uma solicitação DNS não puder ser tratada pelo contêiner do proxy sidecar, o sidecar encaminhará diretamente a solicitação DNS. Para mais informações, consulte Use DNS proxy in ASM.

Exemplo de configuração

1. Na página Configure the agent parameters of the injected Sidecar, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em DNS Proxy.

2. (Opcional) Na seção DNS Proxy, selecione Enable DNS Proxy, ative o switch à direita e clique em Update Settings.

   Esta etapa é obrigatória nas abas Namespace e workload. Pule esta etapa na aba global. Ativar o switch habilita o recurso de proxy DNS para o proxy sidecar.

3. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

4. Execute o comando a seguir para visualize o recurso de proxy DNS configurado.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
         env:
   ...
           - name: ISTIO_META_DNS_AUTO_ALLOCATE
             value: 'true'
           - name: ISTIO_META_DNS_CAPTURE
             value: 'true'
   ...
         name: istio-proxy
                               

   As variáveis de ambiente ISTIO_META_DNS_AUTO_ALLOCATE e ISTIO_META_DNS_CAPTURE do contêiner istio-proxy estão definidas como true. Isso indica que a configuração DNS Proxy entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica variáveis de ambiente adicionais adicionadas aos contêineres de proxy sidecar. Configure os dois tipos a seguir de variáveis de ambiente do proxy sidecar.

Exemplo de configuração

1. Na página Sidecar Proxy Drain Duration at Pod Termination, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Manage Environment Variables for Sidecar Proxy, selecione Manage Environment Variables for Sidecar Proxy (EXIT_ON_ZERO_ACTIVE_CONNECTIONS).

   Esta etapa é obrigatória nas abas Sidecar Graceful Shutdown e Namespace. Pule esta etapa na aba workload.

3. Ative o switch à direita de global (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) e clique em Sidecar Graceful Shutdown.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize as variáveis de ambiente do proxy sidecar configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: EXIT_ON_ZERO_ACTIVE_CONNECTIONS
             value: 'true'
         name: istio-proxy
   ...

   A variável de ambiente EXIT_ON_ZERO_ACTIVE_CONNECTIONS é adicionada às variáveis de ambiente do sidecar do contêiner istio-proxy no Pod. Isso indica que a configuração Update Configurations entrou em vigor.

Descrição do parâmetro

HoldApplicationUntilProxyStarts é um parâmetro de gerenciamento de ciclo de vida para proxies sidecar. HoldApplicationUntilProxyStarts está ativado por padrão, o que significa que, para um Pod com um proxy sidecar injetado, o contêiner do proxy sidecar deve iniciar com sucesso antes que os contêineres de aplicação no Pod iniciem. Isso garante que o tráfego enviado aos contêineres de aplicação não seja perdido porque o proxy sidecar ainda não terminou de iniciar.

Se este parâmetro for desativado, o contêiner do proxy sidecar e os contêineres de aplicação no Pod iniciam ao mesmo tempo. Quando um grande número de Pods é implantado em um cluster, os contêineres de proxy sidecar podem iniciar lentamente devido à carga pesada no APIServer. Desative HoldApplicationUntilProxyStarts para acelerar a implantação.

Exemplo de configuração

O exemplo a seguir mostra como desativar HoldApplicationUntilProxyStarts na aba Manage Environment Variables for Sidecar Proxy.

1. Na página global, clique em na aba Configure the agent parameters of the injected Sidecar e clique em global.

2. Desative o switch à direita de Lifecycle Management (HoldApplicationUntilProxyStarts) e clique em Sidecar Graceful Startup.

   Essa configuração indica que a capacidade HoldApplicationUntilProxyStarts está desativada.

3. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

4. Execute o comando a seguir para visualize a configuração HoldApplicationUntilProxyStarts.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - command:
   ...
         name: sleep
   ...
         env:
           - name: PROXY_CONFIG
             value: >-
               {..."holdApplicationUntilProxyStarts":false,...}
   ...
         name: istio-proxy
   ...

   Após desativar a capacidade holdApplicationUntilProxyStarts, o contêiner istio-proxy não é mais declarado forçadamente antes dos contêineres de aplicação, e o campo lifecycle padrão não é mais declarado. Nesse caso, o Service Mesh não garante mais que o contêiner do proxy sidecar inicie com sucesso antes que os contêineres de aplicação iniciem.

Descrição do parâmetro

A duração de drenagem de término do proxy sidecar é um parâmetro de gerenciamento de ciclo de vida para proxies sidecar. Após a injeção de um proxy sidecar em um Pod, o tráfego do Pod de aplicação é interceptado pelo contêiner do proxy sidecar.

Quando um Pod começa a parar, o service correspondente deixa de encaminhar tráfego para o Pod. Após o contêiner do proxy sidecar receber o sinal de saída, ele aguarda por um período de tempo. Durante esse período, o contêiner para de aceitar novo tráfego de entrada, mas continua processando o tráfego de entrada existente. O tráfego de saída não é afetado e ainda pode ser enviado normalmente. Esse período é chamado de duração de drenagem de término do proxy sidecar. A duração padrão de drenagem de término dos contêineres de proxy sidecar é 5s. Configure uma duração em s, como 10s.

Se as chamadas de interface fornecidas pelo service parado demorarem muito e excederem a duração de drenagem de término do contêiner do proxy sidecar, as conexões de entrada e saída existentes serão encerradas mesmo que não tenham sido totalmente processadas, o que pode causar a perda de algumas solicitações. Nesse caso, use este parâmetro para estender a duração de drenagem de término do proxy sidecar, permitindo que o tráfego de entrada e saída seja totalmente processado.

A duração de drenagem de término do proxy sidecar deve ser especificada em segundos com a unidade s, como 10s.

Exemplo de configuração

1. Na página Update Settings, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Lifecycle Management, selecione Lifecycle Management.

   Esta etapa é obrigatória nas abas Sidecar Proxy Drain Duration at Pod Termination e Namespace. Pule esta etapa na aba workload.

3. Defina global como 10s e clique em Sidecar Proxy Drain Duration at Pod Termination.

   Essa configuração indica que o proxy sidecar aguarda 10 segundos para processar conexões existentes durante o término.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize a duração de drenagem de término do proxy sidecar configurada.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: '10'
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."terminationDrainDuration":"10s"}
   ...
         name: istio-proxy
   ...

   O contêiner istio-proxy no Pod está configurado com a variável de ambiente TERMINATION_DRAIN_DURATION_SECONDS definida como 10, e a variável de ambiente PROXY_CONFIG registra terminationDrainDuration como 10s. Isso indica que a configuração Update Settings entrou em vigor.

Descrição do parâmetro

O parâmetro de ciclo de vida do proxy sidecar permite personalizar totalmente os hooks de ciclo de vida do contêiner dos contêineres de proxy sidecar. Para este parâmetro, insira um campo de hook de ciclo de vida do contêiner (lifecycle) declarado no formato JSON. Este campo substitui o campo de hook de ciclo de vida do contêiner padrão do contêiner do proxy sidecar. Para mais informações, consulte Container lifecycle hooks.

Exemplo de configuração

1. Na página Sidecar Proxy Drain Duration at Pod Termination, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Lifecycle Management, selecione Lifecycle Management.

   Esta etapa é obrigatória nas abas Lifecycle of Sidecar Proxy e Namespace. Pule esta etapa na aba workload.

3. Em global, insira o conteúdo YAML a seguir e clique em Lifecycle of Sidecar Proxy.

   Este conteúdo YAML configura os parâmetros de hook postStart e preStop.

   • postStart: aguarda o pilot-agent iniciar após o início do contêiner sidecar.

   • preStop: dorme por 13 segundos antes que o contêiner sidecar pare.

   {
     "postStart": {
       "exec": {
         "command": [
           "pilot-agent",
           "wait"
         ]
       }
     },
     "preStop": {
       "exec": {
         "command": [
           "/bin/sh",
           "-c",
           "sleep 13"
         ]
       }
     }
   }

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize o ciclo de vida do proxy sidecar configurado.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
   ...
           lifecycle:
           postStart:
             exec:
               command:
               - pilot-agent
               - wait
           preStop:
             exec:
               command:
               - /bin/sh
               - -c
               - sleep 13
         name: istio-proxy
   ...

   O campo de hook de ciclo de vida do contêiner (lifecycle) do contêiner istio-proxy no Pod é alterado para a configuração alvo. Isso indica que a configuração Update Settings entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica a política de acesso dos contêineres de proxy sidecar para serviços externos. Serviços externos são serviços fora da malha que não estão registrados no Service Mesh. Por padrão, todos os serviços nos clusters Kubernetes gerenciados pelo Service Mesh são serviços registrados. Registre manualmente serviços no Service Mesh declarando recursos ServiceEntry. Serviços que não estão registrados são considerados serviços externos.

Exemplo de configuração

1. Na aba Sidecar Traffic Configuration da página global, clique em Configure the agent parameters of the injected Sidecar, selecione REGISTRY_ONLY à direita de Outbound Traffic Policy e clique em Outbound Traffic Policy.

   Essa configuração restringe os serviços na malha de acessar serviços externos.

2. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

3. Crie o arquivo sleep.yaml com o seguinte conteúdo.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

4. Execute o comando a seguir para implantar a aplicação sleep.

   kubectl apply -f sleep.yaml -n default

5. Execute o comando a seguir para usar a aplicação sleep para acessar um service externo.

   kubectl exec -it {sleep-pod-name} -c sleep -- curl www.aliyun.com -v

   Saída esperada:

   *   Trying *********...
   * Connected to www.aliyun.com (********) port 80 (#0)
   > GET / HTTP/1.1
   > Host: www.aliyun.com
   > User-Agent: curl/7.87.0-DEV
   > Accept: */*
   >
   * Mark bundle as not supporting multiuse
   < HTTP/1.1 502 Bad Gateway
   < date: Mon,********* 03:25:00 GMT
   < server: envoy
   < content-length: 0
   <
   * Connection #0 to host www.aliyun.com left intact

   A resposta 502 indica que a aplicação sleep com um proxy sidecar injetado não consegue acessar o service externo www.aliyun.com. Isso indica que a configuração Update Settings entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica a política de interceptação dos proxies sidecar para tráfego de entrada. Por padrão, os contêineres de proxy sidecar usam a política iptables REDIRECT para interceptar o tráfego de entrada enviado para workloads de aplicação. Após o tráfego de entrada ser interceptado por redirecionamento, a aplicação só consegue ver o endereço IP do contêiner do proxy sidecar como o endereço IP de source das solicitações e não consegue ver o endereço IP original do cliente.

Se você alterar a política de interceptação de tráfego de entrada para a política de proxy transparente (TPROXY), o Service Mesh permite que os contêineres de proxy sidecar interceptem o tráfego de entrada no modo de proxy transparente iptables. Após configurar este parâmetro, a aplicação consegue ver o endereço IP original do cliente. Para mais informações, consulte Obtain client source IP in Service Mesh.

Exemplo de configuração

1. Na página Outbound Traffic Policy, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Sidecar Traffic Interception Mode, selecione Sidecar Traffic Interception Mode.

   Esta etapa é obrigatória nas abas Sidecar Traffic Interception Mode e Namespace. Pule esta etapa na aba workload.

3. À direita de global, selecione Sidecar Traffic Interception Mode e clique em TPROXY.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize a política de interceptação de tráfego de entrada do sidecar configurada.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."interceptionMode":"TPROXY",...}
           - name: ISTIO_META_POD_PORTS
             value: |-
               [
               ]
   ...
         name: istio-proxy
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - TPROXY
   ...
         name: istio-init
   ...

   As variáveis de ambiente do sidecar do contêiner istio-proxy no Pod registram "interceptionMode":"TPROXY", e o contêiner istio-init também executa o comando de inicialização com o parâmetro TPROXY. Isso indica que a configuração Update Settings entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica o nível de log dos contêineres de proxy sidecar. Por padrão, os proxies sidecar usam o nível de log info. Altere o nível de log dos proxies sidecar para qualquer um dos sete níveis: info, debug, trace, warning, error, critical e off, para obter mais ou menos informações de log dos proxies sidecar.

Exemplo de configuração

1. Na página Sidecar Traffic Interception Mode, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Monitoring Statistics, selecione Monitoring Statistics.

   Esta etapa é obrigatória nas abas Log Level e Namespace. Pule esta etapa na aba workload.

3. À direita de global, selecione error e clique em Log Level.

   Essa configuração indica que o proxy sidecar gera logs no nível error, e apenas logs no nível error ou superior são gerados.

4. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

5. Execute o comando a seguir para visualize o nível de log do proxy sidecar configurado.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=error'
   ...
         name: istio-proxy
   ...

   Os parâmetros de runtime do contêiner istio-proxy estão definidos como --proxyLogLevel=error. Isso indica que a configuração Update Settings entrou em vigor.

Descrição do parâmetro

Este parâmetro define as estatísticas personalizadas do Envoy relatadas pelos proxies sidecar. O Envoy é a implementação técnica dos proxies sidecar e pode coletar e relatar uma série de métricas. No entanto, o Service Mesh habilita a coleta e exposição de apenas algumas métricas por padrão para reduzir a sobrecarga de desempenho nos proxies sidecar. Use este parâmetro para especificar métricas adicionais que os proxies sidecar precisam coletar e relatar por correspondência de prefixo, correspondência de sufixo ou correspondência de expressão regular.

Exemplo de configuração

1. Na página Log Level, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. Na seção Monitoring Statistics, selecione proxyStatsMatcher, selecione Monitoring Statistics e defina-o como .outlier_detection..

   Essa configuração adiciona a coleta de métricas de circuit breaking para o proxy sidecar.

3. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

4. Execute o comando a seguir para visualize as estatísticas personalizadas do proxy sidecar configuradas.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Saída esperada:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
    ...
           - name: PROXY_CONFIG
             value: >-
               {..."proxyStatsMatcher":{"inclusionRegexps":[".*outlier_detection.*"]},...}
   ...

   As estatísticas personalizadas nas variáveis de ambiente do sidecar do contêiner istio-proxy no Pod foram atualizadas. Isso indica que a configuração proxyStatsMatcher entrou em vigor.

Descrição do parâmetro

Este parâmetro especifica os parâmetros de runtime do processo Envoy nos contêineres de proxy sidecar. Configure o seguinte parâmetro de runtime.

Exemplo de configuração

1. Na página Regular Expression Match, clique em na aba correspondente ao nível de configuração do proxy sidecar desejado e clique em Configure the agent parameters of the injected Sidecar.

2. (Opcional) Na seção Manage Environment Variables for Sidecar Proxy, insira 5000 no campo de entrada à direita de Envoy Runtime Parameters e clique em Limits on Downstream Connections.

3. Redeploy the workload para que a configuração do proxy sidecar entre em vigor.

4. Execute o comando a seguir para visualize as variáveis de ambiente do proxy sidecar configuradas.

kubectl get pod -n <namespace> <pod-name> -o yaml

Saída esperada:

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - args:
...
      env:
        - name: PROXY_CONFIG
          value: >-
            {"concurrency":2,"configPath":"/etc/istio/proxy","discoveryAddress":"istiod-1-22-6.istio-system.svc:15012","holdApplicationUntilProxyStarts":true,"interceptionMode":"REDIRECT","proxyMetadata":{"BOOTSTRAP_XDS_AGENT":"false","DNS_AGENT":"","EXIT_ON_ZERO_ACTIVE_CONNECTIONS":"true"},"runtimeValues":{"overload.global_downstream_max_connections":"5000"},"terminationDrainDuration":"5s","tracing":{"zipkin":{"address":"zipkin.istio-system:9411"}}}
      name: istio-proxy
...

O campo "runtimeValues":{"overload.global_downstream_max_connections":"5000"} é adicionado à variável de ambiente PROXY_CONFIG na configuração do sidecar do contêiner istio-proxy no Pod. Isso indica que a configuração de Parâmetros de runtime do Envoy entrou em vigor.