How to use an ASM serverless gateway to support elastic business scenarios - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Um gateway serverless do ASM oferece operações elásticas e sem nós ao utilizar nós virtuais e o Elastic Container Instance (ECI). Este tópico descreve como usar um gateway serverless do ASM para dar suporte a cargas de trabalho elásticas.

Pré-requisitos

Certifique-se de que um cluster ACK (incluindo as edições Basic, Pro e Dedicated) esteja adicionado à sua instância do ASM. Para mais informações, consulte Add a cluster to an ASM instance.

Nota
Ao criar um gateway do ASM no console do ASM para um cluster Serverless Kubernetes (ASK), os pods do gateway já executam no ECI. Não é necessário executar as etapas deste tópico. Para mais informações sobre como crie um gateway, consulte crie an ingress gateway service.
Implante o componente ack-virtual-node. Para mais informações, consulte Deploy the virtual node controller and use it to crie Elastic Container Instance-based pods.
An ingress gateway service has been deployed.

Conceitos-chave

Conceito	Descrição
Elastic Container Instance (ECI)	O alibaba cloud Elastic Container Instance (ECI) é um serviço de computação serverless que permite executar contêineres sem gerenciar servidores. Ele oferece um ambiente de execução de contêineres seguro e isolado, com inicialização rápida. Com o ECI, você pode focar em suas aplicações em vez da infraestrutura subjacente. O faturamento é cobrado por segundo, com base nos recursos consumidos pelos seus contêineres. Para mais informações, consulte What is Elastic Container Instance? e Billing overview.
nó virtual	Nós virtuais são ideais para cargas de trabalho com padrões de tráfego flutuantes, pois ajudam a reduzir os custos de computação e melhoram a elasticidade dos recursos.
taint	Um taint em um nó repele um conjunto de pods. Por padrão, os nós virtuais em um cluster ACK têm o taint `virtual-kubelet.io/provider=alibabacloud:NoSchedule`. Isso impede o agendamento acidental de pods em recursos do ECI.
toleration	Uma toleration permite o agendamento de um pod em um nó com um taint correspondente. Para permitir o uso de recursos do ECI por um pod no seu cluster ACK, configure as seguintes `tolerations` para tolerar o taint `virtual-kubelet.io/provider=alibabacloud:NoSchedule`. Para mais informações, consulte Deploy the virtual node controller and use it to create Elastic Container Instance-based pods. `tolerations: - key: virtual-kubelet.io/provider operator: Equal value: alibabacloud effect: NoSchedule` Nota Taints e tolerations atuam em conjunto para evitar o agendamento de pods em nós inadequados. É possível aplicar um ou mais taints a um nó. Se um pod não tolerar um taint específico, não será agendado em um nó com esse taint. Se um pod tolerar um taint específico, poderá ser agendado em um nó com esse taint, mas isso não é obrigatório. Para mais informações, consulte a documentação oficial do Kubernetes sobre Taints and Tolerations.
node affinity (nodeAffinity)	O node affinity especifica regras que influenciam o agendamento dos pods. Essas regras podem ser preferências "suaves", as quais o agendador tenta satisfazer, ou requisitos "rígidos", que devem ser atendidos para o agendamento do pod em um nó.

Etapa 1: Adicionar um rótulo a um nó

execute o comando abaixo para consultar os nomes dos nós no cluster:

kubectl get nodes

Em seguida, execute o comando a seguir para adicionar um rótulo ao nó de destino:

# Command format
kubectl label nodes <node-name> <label-key>=<label-value>

# Example
kubectl label nodes node1 mykey4pod=asmgateway

Etapa 2: Adicionar um taint a um nó

Para adicionar um taint a um nó, defina e execute este comando:

kubectl taint nodes node1 mykey=myvalue:NoSchedule

Este comando adiciona um taint ao nó chamado node1. O taint possui a chave mykey, o valor myvalue e o efeito NoSchedule. Apenas pods com uma toleration correspondente podem ser agendados no nó node1.

Etapa 3: Configurar node affinity e tolerations

configure os parâmetros nodeAffinity e tolerations do seu gateway do ASM. As regras de nodeAffinity garantem o agendamento dos pods do gateway em nós específicos, enquanto as tolerations permitem o agendamento em nós com o taint criado na Etapa 2.

Acesse o console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha ASM Gateways > Ingress Gateway.
Na página Ingress Gateway, localize o gateway de destino e clique em View YAML na coluna Actions.

Na caixa de diálogo Edit, adicione o seguinte conteúdo abaixo do campo spec e clique em OK.

   affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - preference:
            matchExpressions:
              - key: type
                operator: In
                values:
                  - virtual-kubelet
          weight: 20
        - preference:
            matchExpressions:
              - key: mykey4pod
                operator: In
                values:
                  - asmgateway
          weight: 80
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: mykey4pod
                operator: In
                values:
                  - asmgateway
          - matchExpressions:
              - key: type
                operator: In
                values:
                  - virtual-kubelet
  tolerations:
    - effect: NoSchedule
      key: virtual-kubelet.io/provider
      operator: Equal
      value: alibabacloud
    - effect: NoSchedule
      key: mykey
      operator: Equal
      value: myvalue

A tabela a seguir descreve os parâmetros principais. Para mais informações, consulte a documentação oficial do Kubernetes sobre Assigning Pods to Nodes.

Parâmetro	Descrição
`preferredDuringSchedulingIgnoredDuringExecution`	O agendador tenta encontrar nós que atendam às regras. Caso não encontre nenhum nó correspondente, ainda assim agenda o pod. Este parâmetro está associado a duas `matchExpressions`. O valor de `weight` é relativo, e o agendador prefere a regra com o valor maior. Um `weight` de `80` indica preferência pela execução do pod em nós ECS com o rótulo especificado, enquanto um `weight` de `20` indica preferência pela execução em recursos do ECI.
`requiredDuringSchedulingIgnoredDuringExecution`	O agendador agenda pods apenas em nós que atendem a essa regra. Este parâmetro está associado a duas entradas `matchExpressions`: uma direciona os pods para o nó ECS com o rótulo especificado e a outra direciona os pods para recursos do ECI.
`tolerations`	Este parâmetro permite que o pod tolere o taint `virtual-kubelet.io/provider=alibabacloud:NoSchedule`, o que possibilita seu agendamento em recursos do ECI.

Verifique se os pods do gateway foram agendados conforme o esperado.
1. Acesse o console do ACK. No painel de navegação à esquerda, clique em Clusters.
2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Pods.
3. Na parte superior da página Pods, selecione o namespace istio-system e verifique se os pods do gateway estão em execução nos nós esperados.
  
  Se os pods estiverem em execução nos nós de destino, o node affinity e as tolerations do gateway do ASM foram configurados com sucesso.