**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. # Simplifique o gerenciamento da computação com o AWS Fargate Este tópico discute o uso do Amazon EKS para executar pods do Kubernetes no AWS Fargate. O Fargate é uma tecnologia que fornece capacidade computacional sob demanda do tamanho certo para [contêineres](https://aws.amazon.com/what-are-containers). 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. Você pode controlar quais pods serão iniciados no Fargate e como serão executados com os [perfis do Fargate](fargate-profile.md). 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 upstream e extensível 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 no Fargate. 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 agendam o pod no Fargate. Este tópico descreve os diferentes componentes dos pods que são executados no Fargate, e faz considerações especiais quanto ao 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 seu próprio limite de computação. Um pod não compartilha 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](network-load-balancing.md#network-load-balancer) e [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md). + 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 reagendados no Fargate. + Não há suporte a Deamonsets no Fargate. Se a aplicação exigir um daemon, reconfigure-o para ser executado como um contêiner associado nos seus 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 padrão do `nofile` e do `nproc` é 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](private-clusters.md). + Você pode usar a opção [Ajustar recursos de pods com o Vertical Pod Autoscaler](vertical-pod-autoscaler.md) para definir o tamanho correto inicial da CPU e da memória para os pods do Fargate e, em seguida, usar a opção [Escalar implantações de pods com o Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) para escalar 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](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) 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](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating). + 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](security.md). 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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize). + O serviço de metadados de instância (IMDS) do Amazon EC2 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](iam-roles-for-service-accounts.md). Se os pods precisarem de acesso a outras informações disponíveis por meio do IMDS, você deve usar codificação rígida nessas informações na especificação do pod. Isso inclui a zona de disponibilidade ou a região da AWS em que um pod é implantado. + Não é possível implantar pods do Fargate no AWS Outposts, no AWS Wavelength ou nas zonas locais da AWS. + O Amazon EKS deve aplicar patches nos pods periodicamente para mantê-los seguros. Tentamos realizar as atualizações de uma forma que reduza o impacto, mas há situações em que os pods precisarão ser excluídos quando não forem removidos com êxito. Há algumas medidas que você pode tomar para minimizar a interrupção. Para obter mais informações, consulte [Definir ações para AWS eventos de aplicação de patches do Fargate OS](fargate-pod-patching.md). + O [plugin CNI do Amazon VPC para Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) é instalado em nós do Fargate. Não é possível usar [plug-ins CNI alternativos para clusters do Amazon EKS](alternate-cni-plugins.md) 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 CSI do Amazon EBS em nós do Fargate, mas o DaemonSet do nó CSI do Amazon EBS só pode ser executado em instâncias do Amazon EC2. + Depois que um [trabalho do Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/) é marcado como `Completed` ou `Failed`, os pods que o criam normalmente continuam a existir. Esse comportamento permite que você visualize os logs e resultados, mas com o Fargate você incorrerá em custos se não limpar o trabalho posteriormente. Para excluir automaticamente os pods relacionados após a conclusão do trabalho ou a falha, você pode especificar um período de tempo usando o controlador de vida útil (TTL). O exemplo a seguir mostra a especificação `.spec.ttlSecondsAfterFinished` em seu manifesto de trabalho. ``` 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 ``` ## Tabela de comparação do Fargate | Critérios | AWS Fargate | | --- | --- | | Pode ser implantado no [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | Não | | Pode ser implantado em uma [Zona local da AWS](local-zones.md) | Não | | Pode executar contêineres que exijam o Windows | Não | | Pode executar contêineres que exijam o Linux | Sim | | Pode executar workloads que exijam o chip do Inferentia | Não | | Pode executar workloads que exijam uma GPU | Não | | Pode executar workloads que exijam processadores ARM | Não | | Pode executar o AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Não | | Os pods compartilham um ambiente de runtime do kernel com outros pods | Não; cada pod tem um kernel dedicado | | Os pods compartilham recursos de CPU, memória, armazenamento e rede com outros pods. | Não; cada pod tem recursos dedicados e pode ser dimensionado independentemente para maximizar a utilização dos recursos | | Os pods podem usar mais hardware e memória do que o solicitado nas especificações do pod | Não; no entanto, o pod pode ser reimplantado usando uma configuração maior de vCPU e memória | | Deve implantar e gerenciar instâncias do Amazon EC2 | Não | | Deve proteger, manter e corrigir o sistema operacional das instâncias do Amazon EC2 | Não | | Pode fornecer argumentos de bootstrap na implantação de um nó, como argumentos [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) extras. | Não | | Pode atribuir endereços IP a pods de um bloco CIDR diferente do endereço IP atribuído ao nó. | Não | | É possível executar o SSH no nó | Não: não há nenhum sistema operacional de host de nó para SSH. | | Pode implantar sua própria AMI personalizada em nós | Não | | Pode implantar seu próprio CNI personalizado em nós | Não | | Você deve atualizar a AMI do nó por conta própria | Não | | Você deve atualizar a versão de Kubernetes do nó por conta própria | Não. Você não gerencia nós. | | Pode usar armazenamento do Amazon EBS com pods | Não | | Pode usar armazenamento do Amazon EFS com pods | [Sim](efs-csi.md) | | Pode usar armazenamento do Amazon FSx para Lustre com pods | Não | | Pode usar o Network Load Balancer para serviços | Sim, ao usar a opção [Criar um balanceador de carga de rede](network-load-balancing.md#network-load-balancer) | | Pods podem ser executados em uma sub-rede pública | Não | | Pode atribuir diferentes grupos de segurança da VPC a pods individuais | Sim | | Pode executar o Kubernetes DaemonSets | Não | | Compatível com `HostPort` e `HostNetwork` no manifesto do pod | Não | | Disponibilidade de regiões do AWS | [Algumas regiões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Pode executar contêineres em hosts dedicados do Amazon EC2 | Não | | Preços | Custo da memória do Fargate e das configurações da CPU. Cada pod tem seu próprio custo. Para obter mais informações, consulte [Preços do AWS Fargate](https://aws.amazon.com/fargate/pricing/). |