Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Implantação de nós do modo automático do EKS em zonas locais

O modo automático do EKS fornece gerenciamento simplificado de clusters com provisionamento automático de nós. As zonas locais da AWS ampliam a infraestrutura da AWS para locais geográficos mais próximos dos seus usuários finais, reduzindo a latência para aplicações sensíveis a esse atraso. Este guia orienta você no processo de implantação de nós do modo automático do EKS em zonas locais da AWS, permitindo a execução de aplicações conteinerizadas com menor latência para usuários em áreas geográficas específicas.

Este guia também demonstra como usar taints e tolerâncias do Kubernetes para garantir que apenas workloads específicas sejam executadas em nós das zonas locais, ajudando você a controlar custos e otimizar o uso de recursos.

Pré-requisitos

Antes de começar a implantar nós do modo automático do EKS em zonas locais, certifique-se de que os seguintes pré-requisitos estejam configurados:

Etapa 1: criação de uma sub-rede na zona local

A primeira etapa para a implantação de nós do modo automático do EKS em uma zona local é criar uma sub-rede nessa zona local. Essa sub-rede fornece a infraestrutura de rede aos seus nós e permite que eles se comuniquem com o restante da VPC. Siga as instruções presentes em Criação de uma sub-rede em uma zona local (no Guia do usuário das zonas locais da AWS) para criar uma sub-rede na zona local escolhida.

Etapa 2: criação de uma NodeClass para a sub-rede na zona local

Após criar a sub-rede da zona local, é necessário definir uma NodeClass que faça referência a essa sub-rede. A NodeClass é um recurso personalizado do Kubernetes que especifica os atributos de infraestrutura para os seus nós, incluindo quais sub-redes, grupos de segurança e configurações de armazenamento devem ser usados. No exemplo abaixo, criamos uma NodeClass chamada “local-zone” que direciona para uma sub-rede da zona local com base em seu nome. Você também pode usar o ID da sub-rede. Será necessário adaptar essa configuração para direcionar para a sua sub-rede da zona local.

Para obter mais informações, consulte Criar uma classe de nó para o Amazon EKS.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: local-zone
spec:
  subnetSelectorTerms:
    - id: <local-subnet-id>

Etapa 3: criação do NodePool com NodeClass e Taint

Com sua NodeClass configurada, agora você precisa criar um NodePool que utilize essa NodeClass. Um NodePool define as características de computação dos seus nós, incluindo os tipos de instância. O NodePool emprega a NodeClass como referência para determinar em qual local as instâncias devem ser iniciadas.

No exemplo abaixo, criamos um NodePool que faz referência à NodeClass “local-zone”. Também adicionamos um taint aos nós para garantir que apenas pods com uma tolerância correspondente possam ser agendados nesses nós das zonas locais. Isso é particularmente importante para nós das zonas locais, que normalmente têm custos mais elevados e devem ser usados apenas por workloads que se beneficiam especificamente da latência reduzida.

Para obter mais informações, consulte Criar um grupo de nós para o Modo Automático do EKS.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-node-pool
spec:
  template:
    metadata:
      labels:
        node-type: local-zone
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: local-zone
      taints:
        - key: "aws.amazon.com/local-zone"
          value: "true"
          effect: NoSchedule

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32"]

O taint com a chave aws.amazon.com/local-zone e o efeito NoSchedule garante que pods sem uma tolerância correspondente não sejam agendados nesses nós. Isso evita que workloads comuns sejam executadas acidentalmente na zona local, o que poderia gerar custos inesperados.

Etapa 4: implantação de workloads com tolerância e afinidade de nó

Para um controle ideal sobre a alocação de workloads em nós das zonas locais, use taints e tolerâncias e a afinidade de nó simultaneamente. Essa abordagem combinada oferece os seguintes benefícios:

A seguir, apresentamos um exemplo de uma Deployment configurada para ser executada especificamente em nós das zonas locais:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: low-latency-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: low-latency-app
  template:
    metadata:
      labels:
        app: low-latency-app
    spec:
      tolerations:
      - key: "aws.amazon.com/local-zone"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "node-type"
                operator: "In"
                values: ["local-zone"]
      containers:
      - name: application
        image: my-low-latency-app:latest
        resources:
          limits:
            cpu: "1"
            memory: "1Gi"
          requests:
            cpu: "500m"
            memory: "512Mi"

Esta Deployment conta com duas configurações de agendamento fundamentais:

Juntas, essas configurações garantem que sua aplicação sensível à latência seja executada apenas em nós das zonas locais, e que as aplicações comuns não consumam os recursos dessas zonas locais, a menos que sejam explicitamente configuradas para isso.

Etapa 5: verificação com o Console da AWS

Após configurar a NodeClass, o NodePool e as Deployments, você deve verificar se os nós estão sendo provisionados na zona local conforme o esperado e se as workloads estão sendo executadas neles. É possível usar o Console de Gerenciamento da AWS para verificar se as instâncias do EC2 estão sendo iniciadas na sub-rede mais adequada da zona local.

Além disso, você pode verificar a lista de nós do Kubernetes usando o comando kubectl get nodes -o wide para confirmar se os nós estão sendo integrados ao cluster com os rótulos e os taints configurados corretamente:

kubectl get nodes -o wide
kubectl describe node <node-name> | grep -A 5 Taints

Você também pode verificar se os pods das workloads estão agendados nos nós das zonas locais:

kubectl get pods -o wide

Essa abordagem garante que apenas workloads com tolerância específica para o taint da zona local sejam agendadas nesses nós, ajudando você a controlar custos e a fazer o uso mais eficiente dos seus recursos de zonas locais.