ECS vs. EKS: Qual serviço de contêiner da AWS é ideal para você?

O que é ECS?

O ECS é o serviço de orquestração de contêineres gerenciado e proprietário da Amazon. Ele oferece uma maneira simples e segura de executar aplicativos em contêineres. Projetado para ser simples, o ECS reduz as decisões dos clientes em relação às configurações de computação, rede e segurança sem sacrificar a escala ou os recursos.

Há algumas terminologias e componentes com os quais você precisa se familiarizar para o ECS.

1. Grupo
2. Provedor de capacidade
3. Definição da tarefa
4. Tarefa
5. Serviço

Grupo

Um cluster do ECS inclui serviços, tarefas e provedores de capacidade. Ele também contém o plano de controle do ECS, que é gerenciado pela AWS e não é visível para nós.

Provedor de capacidade

Os contêineres precisam de um servidor para serem executados, seja uma máquina virtual na nuvem ou seu computador local. No contexto do ECS, você pode selecionar o "Launch Type" para executar seus contêineres no Elastic Compute Cloud (EC2) ou no Fargate.

Guia Infraestrutura do console do AWS ECS.

Tarefa

Uma tarefa é um conjunto de contêineres em execução configurados de acordo com uma definição de tarefa. Essencialmente, ele representa uma instância de uma definição de tarefa, da mesma forma que um contêiner serve como uma instância de uma imagem.

Definição da tarefa

Temos um Dockerfile para nosso aplicativo e criamos uma imagem a partir dele. Enviamos a imagem para um registro de contêiner, como o DockerHub ou o AWS ECR. E agora? Prosseguimos com a criação de uma definição de tarefa, que é uma configuração ou projeto para nossos contêineres (a serem implantados em um cluster ECS) que inclui as seguintes informações:

• Imagem(ns). Uma tarefa pode conter mais de uma imagem.
• O número da porta que será usado para você se comunicar com o nosso aplicativo.
• Volumes.
• Recursos (CPU e memória) a serem reservados para nossos aplicativos.

Definição da tarefa no console do AWS ECS.

Serviço

O que acontece quando executamos um contêiner autônomo e ele falha? Nada acontece. Ele permanece no estado de falha. Esse comportamento é idêntico se criarmos uma tarefa autônoma no ECS. Usamos o serviço ECS para garantir que nossos aplicativos estejam sempre ativos. Um serviço garante que um número desejado de tarefas esteja ativo e em execução o tempo todo.

Se uma tarefa falhar ou o servidor subjacente que a hospeda (e, portanto, o contêiner) ficar inativo, o serviço criará uma nova tarefa em um provedor de capacidade disponível.

Implementação do ECS

Agora que já abordamos os conceitos básicos do ECS, vamos executar uma imagem simples do Nginx e acessá-la. Usando o cluster do ECS e a definição de tarefa acima, criarei um serviço que faz referência à definição de tarefa:

Serviços no console do AWS ECS.

Esse serviço, por sua vez, criará uma tarefa.

Uma tarefa no console do AWS ECS.

Acessando o endereço IP público da tarefa:

Acessou com sucesso o aplicativo em execução no ECS.

O que é EKS?

Antes de mergulhar no Elastic Kubernetes Service(EKS), é essencial que você entenda o que é o Kubernetes. O Kubernetes é um mecanismo de orquestração de contêineres de código aberto que automatiza a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres. 

Para saber mais, recomendo que você confira o curso Introdução ao Kubernetes. 

No entanto, a inicialização e o gerenciamento de um cluster do Kubernetes do zero podem ser complexos e demorados. Muitos componentes e configurações necessários para instalar o Kubernetes são semelhantes entre organizações e equipes. Para abstrair esse trabalho pesado indiferenciado e simplificar a adoção do Kubernetes, a AWS desenvolveu o EKS.

O EKS é um serviço gerenciado do Kubernetes fornecido pela AWS que lida com grande parte da sobrecarga operacional. Ele simplifica a implantação, o dimensionamento e o gerenciamento do Kubernetes ao lidar com o plano de controle em nome dos usuários. Ao abstrair a necessidade de gerenciar esses componentes, o Amazon EKS permite que os usuários se concentrem na execução de suas cargas de trabalho em contêineres e no gerenciamento de nós de trabalho ou tarefas Fargate.

Esta seção discute brevemente o EKS. Para obter mais informações sobre, consulte o artigo Fundamentos da orquestração de contêineres com o AWS Elastic Kubernetes Service (EKS).

Há algumas terminologias e componentes com os quais você precisa se familiarizar para o EKS:

1. Cluster (nós mestre e de trabalho)
2. Arquivos de manifesto
3. Pods
4. ReplicaSet
5. kubectl utilitário de linha de comando

Grupo

Um cluster do Kubernetes é um grupo de servidores ou máquinas virtuais no qual as cargas de trabalho do Kubernetes são executadas. Ele consiste no nó mestre (comumente chamado de plano de controle) e nos nós de trabalho. 

No EKS, o nó mestre é gerenciado pela AWS em sua própria VPC; ele é abstraído de nós. Enquanto isso, podemos gerenciar os nós de trabalho por meio de instâncias do EC2 ou usar o Fargate sem servidor.

Conectividade de rede do plano de controle do EKS. Fonte da imagem: AWS

Pods

Um pod é um recurso da API do Kubernetes. Eles são as menores unidades implantáveis no Kubernetes. Eles são um grupo de um ou mais contêineres e contêm especificações sobre a imagem a ser usada, a porta, os comandos etc.

Guia Recursos no console do AWS EKS.

ReplicaSet

Idêntico a um pod, um ReplicaSet também é um recurso da API do Kubernetes. Ele garante que o número desejado de pods esteja sempre em execução.

Arquivos de manifesto

Os arquivos de manifesto do Kubernetes são arquivos de configuração usados para definir o estado desejado dos recursos do Kubernetes de forma declarativa. Esses arquivos descrevem quais recursos devem existir em um cluster do Kubernetes, suas configurações e como eles interagem entre si.

Normalmente, os arquivos de manifesto são gravados em YAML:

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Utilitário de linha de comando para você se comunicar com o cluster do Kubernetes. Podemos usar o comando kubectl para criar, gerenciar e excluir recursos do Kubernetes de forma imperativa ou usá-lo junto com os arquivos de manifesto de forma declarativa.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Implementação do EKS

Vamos agora demonstrar como o EKS funciona executando e acessando a mesma imagem do Nginx. 

Para simplificar, criarei uma instância/nó de trabalho do EC2 em uma sub-rede pública, implantarei o aplicativo lá, exporei-o por meio de um recurso de serviço do Kubernetes do tipo NodePort e o acessarei por meio do IP público da instância. 

Usarei o manifesto do pod e do serviço acima e o comando kubectl para criar o pod:

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

O cluster EKS tem uma instância do EC2:

Instância EC2/nó de trabalho.

Localize o endereço IPv4 público da instância.

O endereço IP público da instância EC2/nó de trabalho.

Acessando o endereço IP público da instância com a porta 31000:

Acessou com sucesso o aplicativo em execução no EKS.

ECS vs. EKS: Semelhanças

Agora que já abordamos os conceitos básicos do ECS e do EKS, podemos ver algumas semelhanças entre eles. Isso não é surpreendente, pois ambas são ferramentas de orquestração de contêineres.

Capacidade de computação

Ambos os serviços permitem que os aplicativos sejam executados no EC2, em que os usuários são responsáveis pela manutenção, aplicação de patches e atualização das instâncias do EC2, ou no AWS Fargate, a opção de computação sem servidor em que o AWS gerencia os servidores subjacentes, eliminando a necessidade de gerenciamento da infraestrutura.

Modelo de gerenciamento de carga de trabalho

Ambos os serviços têm estruturas e abordagens semelhantes para gerenciar e manter os recursos do aplicativo.

No AWS ECS, a configuração que define como os contêineres devem ser executados é chamada de definição de tarefa, enquanto no AWS EKS, isso é feito usando um arquivo de manifesto de pod. Uma vez implantado, o aplicativo em contêiner no ECS é executado em uma tarefa, enquanto no EKS ele é executado em um pod. Para garantir que um número específico de tarefas ou pods esteja sempre em execução, o ECS usa um serviço, enquanto o EKS depende de um conjunto de réplicas para essa funcionalidade.

Integração profunda com outros serviços do AWS

Como um serviço de contêiner no AWS, a Amazon fez um grande esforço para garantir que o ECS e o EKS se integrassem bem a outros serviços do AWS. 

Para a rede, há o Amazon VPC, que permite que os contêineres sejam executados em ambientes isolados com controle total sobre as configurações de rede, grupos de segurança e sub-redes. Balanceadores de carga para rotear o tráfego para contêineres. 

Soluções como EBS, EFS e S3 estão disponíveis para lidar com os requisitos de armazenamento persistente para aplicativos em contêineres.

Ambos os serviços usam o AWS IAM para controlar o acesso e as permissões de forma granular. Isso determina quais recursos do AWS o aplicativo em contêiner pode acessar, como S3, DynamoDB ou RDS.

Resumo das principais semelhanças

ECS vs. EKS: Diferenças

Entender as diferenças entre o Amazon ECS e o Amazon EKS é importante para que você possa decidir entre eles. 

Nesta seção, analisaremos suas principais diferenças em termos de facilidade de uso, escalabilidade, personalização e custo, ajudando você a determinar qual serviço se alinha melhor aos seus requisitos técnicos e metas comerciais.

Facilidade de uso e curva de aprendizado

O EKS foi desenvolvido com base no Kubernetes, portanto, é necessário que você esteja familiarizado com os conceitos e as ferramentas do Kubernetes. Assim, a curva de aprendizado do EKS será mais acentuada do que a do ECS. Isso envolve entender como o comando kubectl funciona e alguns outros recursos básicos essenciais da API do Kubernetes, como serviços (que não devem ser confundidos com o termo "serviços" usado no contexto do ECS), mapas de configuração, ingress, etc. A seção "O que é EKS" acima mal arranha a superfície do que o EKS oferece.

O ECS e o EKS exigem conhecimento dos serviços da AWS, como CloudWatch, IAM, ASG, etc. Felizmente, isso é tudo o que você precisa para o ECS, mas não para o EKS. Assim, o ECS vence em termos de facilidade de uso.

Escalabilidade

Ambos os serviços podem ser dimensionados igualmente bem quando configurados corretamente. No entanto, a forma como eles são dimensionados é diferente. O ECS oferece suporte ao dimensionamento automático por meio do ECS Service Auto Scaling para tarefas e do ECS Cluster Auto Scaling para instâncias. Ele usa apenas serviços nativos do AWS, como métricas do CloudWatch e políticas de dimensionamento do ASG.

No entanto, o EKS usa recursos de dimensionamento nativos do Kubernetes, como o Horizontal Pod Autoscaler (HPA) para pods e o Cluster Autoscaler para instâncias. O Cluster Autoscaler não é instalado no cluster EKS por padrão e, portanto, exige que o usuário o instale por conta própria. Isso aumenta a complexidade, pois a configuração adequada é necessária nos recursos do AWS (por exemplo, funções do IAM) e nos recursos da API do Kubernetes (por exemplo, contas de serviço) para que o Cluster Autoscaler funcione, o que exige que você faça chamadas à API do AWS para aumentar e diminuir a escala.

Um novo recurso recentemente implementado para o EKS, o EKS AutoMode, pode resolver essa complexidade adicional. Ele transfere o gerenciamento e o dimensionamento dos nós de trabalho do EKS para o AWS, mas tem custos adicionais.

Flexibilidade e personalização

Conforme mencionado, o ECS é o serviço de orquestração de contêineres gerenciado e proprietário da Amazon, projetado para ser simples. O AWS lida com a maioria das tarefas de gerenciamento de clusters, oferecendo configurações predefinidas que se adaptam às cargas de trabalho comuns de contêineres, mas que podem não atender aos requisitos de nichos específicos. Embora reduza a complexidade, ele limita as opções de personalização em comparação com o Kubernetes.

O EKS fornece todo o poder do Kubernetes, permitindo que os usuários personalizem implantações, agendamento de pods, classes de armazenamento e políticas de rede para atender às suas necessidades. Os recursos avançados de orquestração, como definições de recursos personalizados (CRDs) e operadores, permitem uma flexibilidade inigualável no design de aplicativos. 

O EKS também pode ser integrado a várias ferramentas e plug-ins de código aberto do ecossistema Kubernetes, como Prometheus, Grafana e Istio, permitindo que os desenvolvedores criem soluções altamente personalizadas. Assim, o EKS vence a competição em termos de flexibilidade e personalização.

Custo

Além dos custos padrão para recursos de rede (por exemplo, endereços IPv4 públicos, gateways NAT) e recursos de computação e armazenamento (por exemplo, instâncias EC2, Fargate e volumes EBS) que se aplicam tanto ao ECS quanto ao EKS, O ECS tem um custo mais baixo e uma estrutura de custos muito mais simples.

Não há cobranças para o plano de controle do ECS. Em outras palavras, se você criasse um cluster ECS sem nenhuma tarefa em execução, não incorreria em nenhum custo. Enquanto isso, para o EKS, há custos para o plano de controle gerenciado pela AWS, independentemente de você ter aplicativos em execução no cluster do Kubernetes.

O custo do plano de controle do EKS varia de acordo com a versão do Kubernetes usada. Uma versão do Kubernetes com suporte padrão custa US$ 0,10 por cluster por hora, enquanto uma com suporte estendido custa US$ 0,60 por cluster por hora.

Resumo das principais diferenças

Quando você deve escolher o ECS?

A escolha depende dos requisitos do seu aplicativo, das metas comerciais, da experiência da equipe, do orçamento operacional e das prioridades gerais.

O ECS, por ser mais simples e econômico, é ideal para equipes com orçamentos mais apertados, necessidades de menor tempo de colocação no mercado e preferência por operações simplificadas. Ele é particularmente adequado para aplicativos que não exigem portabilidade em ambientes híbridos ou de várias nuvens e foi projetado para ser executado exclusivamente no AWS. Como um serviço específico do AWS, o ECS se alinha perfeitamente às cargas de trabalho confinadas ao ecossistema do AWS.

Embora tanto o ECS quanto o EKS ofereçam suporte ao Fargate para implementações de contêineres sem servidor, o ECS oferece uma integração mais direta. Com o ECS, você pode escolher diretamente as tarefas a serem executadas no Fargate sem configuração adicional. Por outro lado, o Fargate com EKS requer a especificação de rótulos de pod para determinar quais cargas de trabalho devem ser executadas no Fargate, adicionando uma camada de complexidade. Isso torna o ECS uma opção atraente para equipes que buscam uma experiência sem servidor mais simples.

Quando você deve escolher o EKS?

O Kubernetes, a plataforma subjacente do EKS, é independente da nuvem, permitindo que as cargas de trabalho sejam executadas de forma consistente no AWS, em outros provedores de nuvem e em ambientes locais. Essa portabilidade é particularmente vantajosa para organizações que operam em configurações de várias nuvens ou infraestrutura híbrida no local. O Azure e o Google Cloud também oferecem serviços gerenciados do Kubernetes - o Azure Kubernetes Service (AKS) e o Google Kubernetes Engine (GKE), respectivamente - destacando a onipresença do Kubernetes em ambientes de nuvem modernos.

O EKS é ideal se o seu aplicativo ou caso de uso exigir personalização e extensibilidade avançadas. Por exemplo, o Kubernetes oferece suporte à criação de CRDs (Custom Resource Definitions, Definições de Recursos Personalizados), que permitem que você defina recursos personalizados para gerenciar configurações específicas de aplicativos ou integrar-se a sistemas externos. Essa flexibilidade é um diferencial importante para a EKS.

Embora o EKS abstraia o plano de controle e conte com a AWS para gerenciá-lo, operar com eficiência em um ambiente EKS ainda exige familiaridade com os recursos e conceitos da API do Kubernetes. Portanto, a experiência da equipe em Kubernetes é crucial para aproveitar a plataforma de forma eficaz.

O EKS também oferece uma ampla variedade de complementos personalizáveis que podem ser instalados para ampliar a funcionalidade do cluster. Esses add-ons facilitam o provisionamento de um cluster com as ferramentas operacionais necessárias, simplificando a configuração e aumentando a produtividade.

Seleção de complementos do EKS.

Em resumo, o EKS é adequado para arquiteturas de microsserviços ou aplicativos com vários componentes interconectados que exigem alto controle e granularidade. É particularmente vantajoso para equipes que precisam de opções avançadas de personalização ou que operam em ambientes em que a portabilidade da carga de trabalho é essencial.

ECS vs. Fluxograma de decisão do EKS. Imagem do autor.

Ferramentas e integrações

Seja um aplicativo em contêiner ou um aplicativo executado diretamente em uma VM, o monitoramento e a observabilidade são fundamentais. Como fazem parte do ecossistema da AWS, tanto o ECS quanto o EKS podem aproveitar as ferramentas da AWS e os serviços de terceiros para aprimorar todo o ciclo de vida de desenvolvimento de software (SDLC) para aplicativos em contêineres.

Monitoramento e registro

O monitoramento e o registro são essenciais para a visibilidade de seus aplicativos e infraestrutura. O AWS fornece ferramentas nativas e oferece suporte a integrações de terceiros para o ECS e o EKS, como o Amazon CloudWatch para métricas, registros e alarmes. 

O AWS X-Ray para rastrear solicitações em microsserviços facilita a análise e a depuração de problemas de desempenho em tarefas ECS ou pods EKS. Ferramentas de terceiros, como Datadog, Prometheus, Grafana e New Relic, oferecem recursos aprimorados de visualização e alerta adaptados aos contêineres.

Pipelines de CI/CD

Os pipelines de CI/CD ajudam a automatizar testes, varreduras e implantações, garantindo iterações mais rápidas e redução do esforço manual. As ferramentas populares de CI/CD, como os pipelines do GitLab e o GitHub Actions, integram-se ao ECS e ao EKS para permitir compilações, testes e implementações de contêineres. Essas ferramentas funcionam com contêineres Docker para ECS ou gráficos Helm para EKS.

Infraestrutura como código (IaC)

A IaC é fundamental para a criação de uma infraestrutura consistente e repetível, minimizando o tempo de provisionamento e reduzindo o risco de erro humano associado às configurações manuais por meio do Console de gerenciamento do AWS. 

As ferramentas populares de IaC incluem o Terraform e o AWS CloudFormation. Embora ambos sejam amplamente usados, o Terraform costuma ser preferido por seus recursos independentes de nuvem, permitindo que as equipes gerenciem a infraestrutura em vários provedores de nuvem usando uma única ferramenta.

Rede e segurança

O AWS fornece recursos robustos de rede e segurança para o ECS e o EKS para garantir a comunicação segura e o controle de acesso, como a rede VPC do AWS para isolar recursos em sub-redes privadas. AWS WAF e Shield: Proteja os aplicativos hospedados no ECS e no EKS contra vulnerabilidades comuns da Web e ataques DDoS. AWS KMS para criptografar volumes EBS e segredos do Kubernetes armazenados no etcd.

Conclusão

O ECS e o EKS são serviços robustos de orquestração de contêineres fornecidos pela AWS, cada um adaptado para atender a diferentes necessidades de aplicativos e prioridades da equipe. 

O ECS é mais fácil de começar, mais simples de provisionar, implementar e manter, e tem custos operacionais mais baixos. Em contrapartida, o EKS tem uma curva de aprendizado mais acentuada e maior complexidade inicial, mas oferece flexibilidade inigualável e opções avançadas de personalização, o que o torna ideal para equipes com requisitos especializados ou complexos. 

A escolha entre ECS e EKS depende das necessidades do seu aplicativo, da experiência da equipe e do equilíbrio desejado entre simplicidade e controle.

Se você deseja fortalecer seu conhecimento sobre o AWS, o curso Conceitos do AWS é um ótimo ponto de partida. Para se aprofundar nas ferramentas e tecnologias da AWS, confira o curso AWS Cloud Technology and Services. Além disso, para os interessados em dominar a conteinerização, o Containerization and Virtualization Track oferece insights valiosos para ajudar você a se destacar no gerenciamento e na implantação de contêineres.