AWS Fargate

Importante

O AWS Fargate com o Amazon EKS não está disponível para a AWS GovCloud (Leste dos EUA) e AWS GovCloud (Oeste dos EUA).

Este tópico discute o uso do Amazon EKS para executar Kubernetes do Pods no AWS Fargate. O Fargate é uma tecnologia que fornece capacidade computacional sob demanda do tamanho certo para contêineres. Com o Fargate, você não tem que provisionar, configurar ou escalar grupos de máquinas virtuais você mesmo para executar contêineres. Você também não precisa escolher tipos de servidor, decidir quando escalar grupos de nós ou otimizar o empacotamento dos clusters.

É possível controlar quais Pods serão iniciados no Fargate e como serão executados com os perfis do Fargate. Os perfis do Fargate são definidos como parte do seu cluster do Amazon EKS. O Amazon EKS integra o Kubernetes ao Fargate com controladores criados pela AWS usando o modelo extensível upstream fornecido pelo Kubernetes. Esses controladores são executados como parte do ambiente de gerenciamento do Kubernetes gerenciado pelo Amazon EKS e são responsáveis por agendar Pods nativos do Kubernetes. Os controladores do Fargate incluem um novo agendador que é executado com o agendador do Kubernetes, além de vários controladores de admissão de mutação e de validação. Quando você inicia um Pod que atende aos critérios de execução no Fargate, os controladores do Fargate em execução no cluster reconhecem, atualizam e agendar o Pod no Fargate.

Este tópico descreve os diferentes componentes dos Pods que são executados no Fargate e faz considerações especiais para o uso do Fargate com o Amazon EKS.

Considerações sobre o AWS Fargate

Veja a seguir algumas considerações sobre o uso do Fargate no Amazon EKS.

• Cada Pod executado no Fargate tem sua própria barreira de isolamento. Eles não compartilham o kernel subjacente, os recursos de CPU, os recursos de memória nem a interface de rede elástica com outro Pod.

• Os balanceadores de carga da rede e os balanceadores de carga da aplicação (ALBs) só podem ser usados com o Fargate com destinos IP. Para obter mais informações, consulte Criar um balanceador de carga da rede e Aplicação de roteamento e tráfego HTTP com Application Load Balancers.

• Os serviços expostos ao Fargate são executados somente no modo IP do tipo de destino e não no modo IP do nó. A maneira recomendada de verificar a conectividade de um serviço em execução em um nó gerenciado e um serviço em execução no Fargate é se conectar pelo nome de serviço.

• Os pods devem corresponder a um perfil do Fargate no momento em que são agendados para execução no Fargate. Pods que não correspondam a um perfil do Fargate podem ficar retidos como Pending. Se houver um perfil do Fargate correspondente, será possível excluir os Podspendentes criados para serem regendados no Fargate.

• Não há suporte a Deamonsets no Fargate. Se a aplicação exigir um daemon, reconfigure esse daemon para ser executado como um contêiner associado nos Pods.

• Não há suporte a contêineres privilegiados no Fargate.

• Os pods que são executados no Fargate não podem especificar HostPort ou HostNetwork no manifesto do Pod.

• O limite flexível de nofile e nproc padrão é 1.024, e o limite rígido é 65.535 para Pods do Fargate.

• No momento, GPUs não estão disponíveis no Fargate.

• Só há suporte a pods em execução no Fargate em sub-redes privadas (com acesso de gateway NAT aos serviços da AWS, mas não uma rota direta para um gateway da Internet), portanto, a VPC do cluster deve ter sub-redes privadas disponíveis. Para clusters sem acesso de saída à Internet, consulte Implementar clusters privados com acesso limitado à internet.

• É possível usar Ajustar os recursos de pods com o Vertical Pod Autoscaler para definir o tamanho correto da CPU e da memória para os Pods do Fargate e, em seguida, usar Escalar as implantações de pods com o Horizontal Pod Autoscaler para dimensionar a escala desses Pods. Se quiser que o Vertical Pod Autoscaler reimplante automaticamente os Pods no Fargate com combinações maiores de CPU e memória, defina o modo do Vertical Pod Autoscaler como Auto ou Recreate para garantir a funcionalidade correta. Para obter mais informações, consulte a documentação do Vertical Pod Autoscaler no GitHub.

• A resolução DNS e os nomes de host DNS devem estar habilitados para sua VPC. Para obter mais informações, consulte Visualizar e atualizar o suporte DNS para VPC.

• O Fargate do Amazon EKS adiciona defesa completa para aplicações do Kubernetes isolando cada pod em uma máquina virtual (VM). Essa barreira de VM impede o acesso aos recursos baseados em host usados por outros pods, no caso de um escape de contêiner, um método comum de atacar aplicações em contêiner e obter acesso a recursos fora do contêiner.

  O uso do Amazon EKS não altera suas responsabilidades no modelo de responsabilidade compartilhada. Você deve considerar cuidadosamente a configuração de controles de governança e segurança do cluster. A maneira mais segura de isolar uma aplicação é sempre executá-la em um cluster separado.

• Os perfis do Fargate são compatíveis com a especificação de sub-redes de blocos CIDR secundários da VPC. Talvez você queira especificar um bloco CIDR secundário. Isso porque existe um número limitado de endereços IP disponíveis em uma sub-rede. Como resultado, existe também um número limitado de Pods que podem ser criados no cluster. Usando diferentes sub-redes para os Pods, você pode aumentar o número de endereços IP disponíveis. Para obter mais informações, consulte Adicionar blocos CIDR IPv4 a uma VPC.

• O serviço de metadados de instância do Amazon EC2 (IMDS) não está disponível para Pods implantados em nós do Fargate. Se você tiver Pods implantados no Fargate que precisem de credenciais do IAM, atribua-as aos Pods usando Perfis do IAM para contas de serviço. Se os Pods precisarem de acesso a outras informações disponíveis por meio do IMDS, você deve fazer a codificação rígida dessas informações na especificação do Pod. Isso inclui a Região da AWS ou a zona de disponibilidade em que um Pod é implantado.

• Não é possível implantar Pods do Fargate no AWS Outposts, AWS Wavelength ou AWS Local Zones.

• O Amazon EKS deve aplicar patches nos Pods periodicamente para mantê-los seguros. Tentamos fazer atualizações de uma maneira que reduza o impacto, mas há situações em que os Pods deverão ser excluídos se não forem removidos com êxito. Há algumas medidas que você pode tomar para minimizar a interrupção. Para ter mais informações, consulte Aplicação de patches no sistema operacional do Fargate.

• O plugin CNI do Amazon VPC para Amazon EKS é instalado em nós do Fargate. Você não pode usar Plugins CNI compatíveis alternativos com nós do Fargate.

• Um Pod em execução no Fargate monta automaticamente um sistema de arquivos do Amazon EFS. Você não pode usar o provisionamento dinâmico de volume persistente com nós do Fargate, mas pode usar o provisionamento estático.

• Você não pode montar volumes do Amazon EBS em Pods do Fargate.

• Você pode executar o controlador da CSI do Amazon EBS em nós do Fargate, mas o DaemonSet do nó da CSI do Amazon EBS só pode ser executado em instâncias do Amazon EC2.

• Depois que um Kubernetes Job é marcado Completed ou Failed, o Pods que ele Job cria normalmente continua existindo. Esse comportamento permite que você visualize seus registros e resultados, mas com o Fargate você incorrerá em custos se não os limpar posteriormente Job.

  Para excluir automaticamente o relacionado Pods após uma Job conclusão ou falha, você pode especificar um período de tempo usando o controlador de tempo de vida (TTL). O exemplo a seguir mostra a especificação .spec.ttlSecondsAfterFinished em seu Job manifesto.

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: busybox
  spec:
    template:
      spec:
        containers:
        - name: busybox
          image: busybox
          command: ["/bin/sh", "-c", "sleep 10"]
        restartPolicy: Never
    ttlSecondsAfterFinished: 60 # <-- TTL controller