Alibaba Cloud Service Mesh:Configure dynamically overcommitted resources for sidecar proxies

Como funciona o overcommit dinâmico de recursos

No Kubernetes, o kubelet gerencia os recursos dos pods com base nas classes de qualidade de serviço (QoS): Guaranteed, Burstable e BestEffort. Essas classes são definidas pelas solicitações e limites de CPU e memória configurados em cada pod.

O ack-koordinator estende esse modelo ao monitorar a carga dos nós em tempo real e recuperar recursos alocados, mas não utilizados ativamente. Para diferenciar esses recursos recuperados da CPU e da memória convencionais, o ack-koordinator atribui a eles a prioridade Batch:

Os pods que consomem recursos Batch devem ter o rótulo koordinator.sh/qosClass: "BE", correspondente à classe de QoS BestEffort do Koordinator. Esse rótulo indica ao agendador para tratar o pod como um consumidor de baixa prioridade da capacidade recuperada.

Para obter detalhes sobre o modelo de overcommit, consulte Ativar overcommit dinâmico de recursos.

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster ACK Pro. Para mais informações, consulte Criar um cluster ACK Pro

  Nota

  Apenas clusters ACK Pro oferecem suporte a recursos com overcommit dinâmico.

• O recurso de overcommit dinâmico de recursos ativado no cluster ACK Pro. Para mais informações, consulte Ativar overcommit dinâmico de recursos

• O cluster ACK Pro adicionado a uma instância ASM com a versão 1.16 ou posterior. Para mais informações, consulte Adicionar um cluster a uma instância ASM

Etapa 1: Implantar o ConfigMap ack-slo-config

O ConfigMap ack-slo-config controla como o ack-koordinator recupera recursos ociosos em cada nó.

1. Crie um arquivo chamado configmap.yaml com o seguinte conteúdo. A tabela abaixo descreve os principais parâmetros. Para obter detalhes sobre todos os itens de configuração, consulte Ativar overcommit dinâmico de recursos.

   Parâmetro	Descrição	Valor de exemplo
   enable	Ativa o overcommit de recursos no nó.	true
   metricAggregateDurationSeconds	Intervalo em segundos para agregação de métricas de recursos do nó.	60
   cpuReclaimThresholdPercent	Percentual da CPU alocada passível de recuperação.	60
   memoryReclaimThresholdPercent	Percentual da memória alocada passível de recuperação.	70
   memoryCalculatePolicy	Método para calcular a disponibilidade de memória. O valor usage baseia os cálculos no consumo real de memória.	"usage"

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: ack-slo-config
        namespace: kube-system
      data:
        colocation-config: |
          {
            "enable": true,
            "metricAggregateDurationSeconds": 60,
            "cpuReclaimThresholdPercent": 60,
            "memoryReclaimThresholdPercent": 70,
            "memoryCalculatePolicy": "usage"
          }

2. Aplique o ConfigMap.

   • Se o ConfigMap ack-slo-config já existir no namespace kube-system, aplique um patch para preservar as outras configurações:

     kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

   • Caso o ConfigMap não exista, crie-o:

     kubectl apply -f configmap.yaml

3. Verifique os recursos Batch disponíveis em um nó. Substitua <node-name> pelo nome real do nó. Na saída, localize a seção allocatable. Se kubernetes.io/batch-cpu e kubernetes.io/batch-memory aparecerem em allocatable, o ConfigMap de overcommit estará funcionando corretamente.

      kubectl get node <node-name> -o yaml

      status:
        allocatable:
          # Unit: millicores. In this example, 50 cores are available.
          kubernetes.io/batch-cpu: 50000
          # Unit: bytes. In this example, 50 GB of memory is available.
          kubernetes.io/batch-memory: 53687091200

Etapa 2: Configurar recursos Batch para contêineres sidecar

Defina as solicitações e os limites de recursos Batch para o contêiner de proxy sidecar injetado e para o contêiner istio-init no console ASM.

1. Faça login no console ASM.

2. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

3. Na página Mesh Management, clique em nome da instância ASM de destino.

4. No painel de navegação à esquerda, escolha Data Plane Component Management > Sidecar Proxy Setting.

5. Na página Sidecar Proxy Setting, clique em aba global e, em seguida, clique em Resource Settings.

6. Selecione Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy e configure os valores dos recursos. Defina Resource Limits e Required Resources conforme a classe de QoS da sua carga de trabalho. A tabela a seguir apresenta valores de exemplo:

   Classe de QoS	Orientação
   Guaranteed	Defina Resource Limits e Required Resources com o mesmo valor.
   Burstable ou BestEffort	Configure Required Resources com um valor inferior a Resource Limits. Essa orientação também se aplica a recursos convencionais.

   Contêiner	Configuração	CPU	Memória
   Configure Resources for Injected Sidecar Proxy (ACK Dynamically Overcommitted Resources)	Resource Limits	2000 milicores	2048 MiB
   	Required Resources	200 milicores	256 MiB
   Configure Resources for istio-init Container (ACK Dynamically Overcommitted Resources)	Resource Limits	1000 milicores	1024 MiB
   	Required Resources	100 milicores	128 MiB

7. Clique em Update Settings.

Etapa 3: Implantar uma carga de trabalho com recursos Batch

Implante uma aplicação de exemplo que solicite recursos Batch. Cada pod que utilizar recursos Batch deve ter o rótulo koordinator.sh/qosClass: "BE" para que o ack-koordinator o agende como um consumidor BestEffort da capacidade recuperada.

1. Crie um arquivo chamado demo.yaml com o seguinte conteúdo:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sleep
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: sleep
        template:
          metadata:
            labels:
              app: sleep
              # Required. Assigns BestEffort QoS to the pod.
              koordinator.sh/qosClass: "BE"
          spec:
            terminationGracePeriodSeconds: 0
            containers:
            - name: sleep
              image: curlimages/curl
              command: ["/bin/sleep", "infinity"]
              imagePullPolicy: IfNotPresent
              resources:
                requests:
                  # 1 core (1000 millicores)
                  kubernetes.io/batch-cpu: "1k"
                  # 1 GiB
                  kubernetes.io/batch-memory: "1Gi"
                limits:
                  kubernetes.io/batch-cpu: "1k"
                  kubernetes.io/batch-memory: "1Gi"

2. Implante a aplicação:

      kubectl apply -f demo.yaml

Etapa 4 (opcional): Verificar limites de recursos

Após a implantação, confirme se os limites de recursos no nível de cgroup correspondem aos valores configurados.

1. Acesse o nó onde o pod está em execução e verifique o limite de CPU. Saída esperada:

      cat /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod****.slice/cri-containerd-****.scope/cpu.cfs_quota_us

      # 1 core = 100000 microseconds per CFS period
      100000

2. Verifique o limite de memória. Saída esperada:

      cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod****.slice/cri-containerd-****.scope/memory.limit_in_bytes

      # 1 GB = 1073741824 bytes
      1073741824

Se ambos os valores corresponderem à especificação do Deployment, os limites de recursos Batch estarão em vigor.