Simplifique o gerenciamento da computação com o AWS Fargate

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 ter 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 Pods pendentes 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.

Você pode usar a opção Ajustar recursos do pod com o Vertical Pod Autoscaler para definir o tamanho correto inicial da CPU e da memória para o Pods Fargate e, em seguida, usar a opção Escalar implantações de pod com o Horizontal Pod Autoscaler para dimensionar esses 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 implantado no Fargate que precise de credenciais do IAM, atribua-as ao seu 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 AWS ou a zona de disponibilidade na qual um Pod está implantado.

Não é possível implantar o Fargate Pods em 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 esse impacto, mas há situações em que os Pods precisam ser excluídos quando não são despejados com êxito. Há algumas medidas que você pode tomar para minimizar a interrupção. Para ter mais informações, consulte Definir ações para AWS eventos de aplicação de patches do Fargate OS.

O plugin CNI do Amazon VPC para Amazon EKS é instalado em nós do Fargate. Não é possível usar plug-ins CNI alternativos para clusters do Amazon EKS com nós do Fargate.

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

O Amazon EKS não oferece suporte ao Fargate Spot.

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 trabalho do Kubernetes é marcado como Completed ou Failed, o Pods que o Job cria normalmente continua a existir. 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