Orquestração de contêineres em nuvem
A popularidade das plataformas de conteinerização de aplicações segue crescendo ano após ano e vem se tornando um padrão para a entrega de aplicações distribuídas. A orquestração de contêineres traz muitos benefícios associados a alguns desafios interessantes para os times de operação.
Guilherme Belinelo, CTO da dataRain Consulting
A popularidade das plataformas de conteinerização de aplicações segue crescendo ano após ano e vem se tornando um padrão para a entrega de aplicações distribuídas. A orquestração de contêineres, ou “containers” se você preferir a grafia em inglês como um neologismo, assim como usaremos neste breve artigo, tem trazido muitos benefícios associados a alguns desafios interessantes para os times de operação.
Mas, para compreender o motivo desta popularização, vamos antes entender que, por ter um sistema operacional como base, compartilhado entre os diferentes containers, a plataforma de conteinerização consegue fazer melhor uso do hardware ao evitar o overhead do SO. Isso difere do caso tradicional de máquinas virtuais para as quais é necessário subir o sistema operacional inteiro sobre um hypervisor para só então poder rodar suas aplicações em cima.
Outro aspecto bastante interessante é que o container já promove, nativamente, o conceito de microsserviço, no qual cada container executa uma tarefa especializada, reduzindo significativamente seu “footprint” e melhorando as características de alta disponibilidade e segurança do cluster como um todo.
Porém, nem tudo traz consigo apenas os “prós” e precisamos levar em conta também alguns “contras” da abordagem de arquiteturas baseadas em containers. Um bastante importante é o “container sprawl” (espalhamento de containers) – sim, do mesmo jeito que acontecia com as VMs (máquinas virtuais) –, que, dado à facilidade com que é criado, permite que as áreas usuárias lancem diversos deles, levando quase sempre a um aumento muito rápido do número de containers a ser gerenciado.
Isso traz dificuldade de como trabalhar com os containers em escalas corporativas. Nesse momento, as ferramentas de orquestração aparecem para resgatar os SysAdmins e colocam (alguma) ordem na bagunça, podendo ser separadas em basicamente em dois grupos:
• Ferramental de orquestração não gerenciado (ou “self hosted”).
• Ferramental de orquestração gerenciado.
No caso das soluções não gerenciadas, você fica responsável por cuidar de todos os aspectos relacionados a subir e manter o cluster, com atividades de administração, atualizações de software, implementação de alta disponibilidade e escalabilidade, suporte técnico avançado (N2 e N3), gerenciamento da segurança e aderência a requisitos de conformidade.
Por outro lado, se não é necessário acesso pleno ao control plane — máquinas “master” que gerenciam as cargas de trabalho em nós, “workers” — e você pode optar pelas soluções de orquestração mais comuns de mercado, por exemplo o Kubernetes, as soluções gerenciadas em cloud são geralmente o melhor o caminho a ser seguido.
Com o provisionamento da infraestrutura em poucos minutos, guiados por “wizards” automáticos, você pode se preocupar mais com a arquitetura dos seus containers, microsserviços e comunicação entre eles, do que com a infraestrutura que fica por baixo.
Por esta razão, o rápido desenvolvimento e adoção do Kubernetes resultaram em muitas implementações diferentes do aplicativo. A CNCF – Cloud Native Computing Foundation lista atualmente mais de 90 ofertas certificadas do Kubernetes. Para garantir alguma consistência entre as plataformas, a CNCF se concentra em três princípios fundamentais”
• Consistência: a capacidade de interagir de forma consistente com qualquer instalação do Kubernetes.
• Atualizações oportunas: os fornecedores devem manter as versões atualizadas, pelo menos anualmente.
• Confirmabilidade: Qualquer usuário final pode verificar a conformidade usando o Sonobuoy.
Esses são os requisitos básicos para a CNCF quando se trata de Kubernetes, mas os provedores de nuvem têm ecossistemas tão ricos que provavelmente haverá discrepâncias mais significativas. Continuamos a examinar os muitos recursos e limitações atuais dos serviços Kubernetes gerenciados dos três maiores provedores de nuvem:
• Serviço EKS – Elastic Kubernetes da Amazon.
• Serviço AKS – Azure Kubernetes da Microsoft.
• GKE – Kubernetes Engine do Google.
Os serviços de container da Amazon e do Azure são relativamente semelhantes. O ECR – Elastic Container Registry, da Amazon, é um serviço pago em camadas, que fornece um SLA com suporte financeiro e um serviço gratuito de digitalização de imagens e recursos como tags de imagem imutáveis. O ACR – Azure Container Registry, do Azure, também é um serviço pago em camadas, que fornece um SLA com suporte financeiro e serviço de digitalização de imagens pago, com o scanner Qualys e recursos como assinatura de imagem, marcas imutáveis e bloqueio de imagens e repositórios.
O ECR atualizou recentemente a capacidade de seu registro. Com a mudança de ECRs para suportar regiões e contas cruzadas, os usuários não precisam configurar e gerenciar a redundância entre zonas como faziam anteriormente. O preço do Azure é uma taxa de uso diário e com base na quantidade de armazenamento necessária, mas não cobra pela largura de banda da rede. A Microsoft também oferece redundância geográfica como parte de seu plano premium.
Por fim, o Google concluiu sua mudança de seu registro de contêiner existente, o Google Container Registry, para um produto Artifact Registry completo. A empresa optou por se concentrar em mais formatos de imagem suportados, digitalização de imagem integrada e autorização binária para uma oferta mais segura.
