Compartilhar via

Considerações gerais da arquitetura para escolher um serviço de contêiner do Azure

  • Artigo

Este artigo orienta você pelo processo de escolha de um serviço de contêiner do Azure. Ele fornece uma visão geral das considerações em nível de recurso que são comuns e críticas para algumas cargas de trabalho. Ele pode ajudá-lo a tomar decisões para garantir que sua carga de trabalho atenda aos requisitos de confiabilidade, segurança, otimização de custos, excelência operacional e eficiência de desempenho.

Observação

Este artigo é a segunda parte de uma série que começa com Escolher um serviço de contêiner do Azure. É altamente recomendável que você leia esse artigo de visão geral primeiro para obter um contexto para essas considerações de arquitetura.

Visão geral

As considerações deste artigo estão divididas em quatro categorias:

Considerações sobre arquitetura e rede

  • Suporte do sistema operacional
  • Espaços de endereço de rede
  • Reconhecimento do fluxo de tráfego
  • Planejando sub-redes
  • Número de IPs de entrada disponíveis
  • Rotas definidas pelo usuário e suporte a gateway NAT
  • Integração de rede privada
  • Cobertura do protocolo
  • Balanceamento de carga
  • Descoberta de serviço
  • Domínios personalizados e TLS gerenciado
  • TLS Mútuo
  • Conceitos de rede para serviços específicos do Azure

Considerações de segurança

  • Como fornecer segurança para o tráfego dentro do cluster usando diretivas de rede
  • Grupos de segurança de rede
  • Integração do Azure Key Vault
  • Suporte de identidade gerenciada
  • Proteção contra ameaças e avaliações de vulnerabilidades com o Defender para Contêineres
  • Linhas de base de segurança
  • Azure Well-Architected Framework para Segurança

Considerações operacionais

  • Atualizações e patches
  • Atualizações de imagem de contêiner
  • Escalabilidade vertical da infraestrutura
  • Escalabilidade horizontal da infraestrutura
  • Escalabilidade do aplicativo
  • Observabilidade
  • Well-Architected Framework para Excelência Operacional

Considerações sobre a confiabilidade

  • Contratos de nível de serviço
  • Redundância via zonas de disponibilidade
  • Verificações de integridade e recuperação automática
  • Implantações de aplicativos sem tempo de inatividade
  • Limites de recursos
  • Well-Architected Framework para Confiabilidade

Observe que este artigo se concentra em um subconjunto de serviços de contêiner do Azure que oferecem um conjunto de recursos sólido para aplicativos Web e APIs, rede, observabilidade, ferramentas de desenvolvedor e operações: Serviço de Kubernetes do Azure (AKS), Aplicativos de Contêiner do Azure e Aplicativo Web para Contêineres. Para obter uma lista completa de todos os serviços de contêiner do Azure, consulte a página de categoria de produto de serviços de contêiner.

Observação

Neste guia, o termo carga de trabalho refere-se a uma coleção de recursos de aplicativo que dão suporte a uma meta de negócios ou à execução de um processo de negócios. Uma carga de trabalho usa vários componentes, como APIs e armazenamentos de dados, que trabalham juntos para fornecer funcionalidade específica de ponta a ponta.

Considerações de arquitetura

Esta seção descreve decisões de arquitetura que são difíceis de reverter ou corrigir sem exigir tempo de inatividade significativo ou reimplantação. É muito importante ter essa consideração em mente para componentes fundamentais, como rede e segurança.

Essas considerações não são específicas dos pilares do Well-Architected Framework. No entanto, elas merecem análise e avaliação extras em relação aos requisitos de negócios quando você escolhe um serviço de contêiner do Azure.

Suporte do sistema operacional

A maioria dos aplicativos conteinerizados é executada em contêineres Linux, que têm suporte de todos os serviços de contêiner do Azure. Suas opções são mais limitadas para componentes de carga de trabalho que exigem contêineres do Windows.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte a Linux ✅ ✅ ✅
Suporte do Windows ❌ ✅ ✅
Suporte ao sistema operacional misto ❌ ✅ ❌*

*O suporte ao sistema operacional misto para o Aplicativo Web para Contêineres requer Planos do Serviço de Aplicativo do Azure separados para Windows e Linux.

Considerações de rede

É importante entender o design de rede no início de seus processos de planejamento devido às restrições de segurança e conformidade e às diretrizes impostas. Em geral, as principais diferenças entre os serviços do Azure abordados neste guia dependem da preferência:

  • Os Aplicativos de Contêiner são uma oferta de PaaS que fornece muitos recursos de rede gerenciados pelo Azure, como descoberta de serviço e domínios gerenciados internos. As equipes de carga de trabalho que precisam de um pouco mais de configurabilidade podem usar perfis de carga de trabalho/dedicados antes de considerar alternativas para maximizar suas opções de rede.
  • O AKS é o mais configurável dos três serviços e fornece o maior controle sobre o fluxo de rede. Por exemplo, ele fornece controladores de entrada personalizados e o controle do tráfego dentro do cluster por meio de diretivas de rede do Kubernetes. As equipes de carga de trabalho podem aproveitar vários complementos de rede gerenciados do Azure, bem como instalar e operar quaisquer complementos do ecossistema Kubernetes mais amplo.
  • O Aplicativo Web para Contêineres é um recurso do Serviço de Aplicativo. Assim, os conceitos de rede, especialmente a integração de rede privada, são muito específicos do Serviço de Aplicativo. Esse serviço será familiar para equipes de carga de trabalho que já usam o Serviço de Aplicativo. As equipes que não têm experiência com o Serviço de Aplicativo e que desejam uma integração de rede virtual do Azure mais familiar são incentivadas a considerar os Aplicativos de Contêiner.

Lembre-se de que a rede é uma camada fundamental de infraestrutura. Muitas vezes, é difícil fazer alterações no design sem reimplantar a carga de trabalho, o que pode levar ao tempo de inatividade. Portanto, se sua carga de trabalho tiver requisitos de rede específicos, revise esta seção cuidadosamente antes de restringir sua seleção de serviço de contêiner do Azure.

Espaços de endereço de rede

Ao integrar aplicativos em redes virtuais, você precisa fazer algum planejamento de endereço IP para garantir que endereços IP suficientes estejam disponíveis para instâncias de contêiner. Durante esse processo, planeje endereços adicionais para atualizações, implantações azuis/verdes e situações semelhantes em que instâncias extras são implantadas, o que consome endereços IP adicionais.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Sub-redes dedicadas: Plano de consumo: opcional
Plano dedicado: obrigatório		 Obrigatório Opcional
Requisitos de endereço IP Plano de consumo: consulte Ambiente somente de consumo.
Plano dedicado: consulte Ambiente de perfis de carga de trabalho.		 Consulte Redes virtuais do Azure para AKS. Consulte Requisitos de sub-rede do Serviço de Aplicativo.

Observe que os requisitos do AKS dependem do plug-in de rede escolhido. Alguns plug-ins de rede para AKS exigem reservas de IP mais amplas. Os detalhes estão fora do escopo deste artigo. Para obter mais informações, consulte Conceitos de rede para AKS.

Reconhecimento do fluxo de tráfego

Os tipos de fluxo de tráfego necessários para uma solução podem afetar o design da rede.

As seções a seguir fornecem informações sobre várias restrições de rede. Essas restrições afetam sua necessidade de implantar sub-redes adicionais, dependendo se você precisar:

  • Várias cargas de trabalho colocalizadas.
  • Entrada privada e/ou pública.
  • Um fluxo controlado de acesso de tráfego leste-oeste em um cluster (para Aplicativos de Contêiner e AKS) ou em uma rede virtual (para todos os serviços de contêiner do Azure).

Planejamento de sub-rede

Garantir que você tenha uma sub-rede grande o suficiente para incluir instâncias de seu aplicativo para sua carga de trabalho não é o único fator que determina o espaço ocupado pela rede onde esses aplicativos são implantados.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte para cargas de trabalho colocalizadas em uma sub-rede* ❌* ✅ N/A*

*Isso descreve uma prática recomendada, não uma limitação técnica.

Para Aplicativos de Contêiner, a integração de sub-rede se aplica somente a um único ambiente de Aplicativos de Contêiner. Cada ambiente de Aplicativos de Contêiner é restrito a um único IP de entrada, público ou privado.

Cada ambiente de Aplicativos de Contêiner destina-se apenas a uma única carga de trabalho na qual os aplicativos dependentes são colocalizados. Portanto, você precisa introduzir dispositivos de rede adicionais do Azure para balanceamento de carga de entrada se precisar de entrada pública e privada. Os exemplos incluem o Gateway de Aplicativo do Azure e o Azure Front Door. Além disso, se você tiver várias cargas de trabalho que precisam ser segregadas, ambientes de Aplicativos de Contêiner adicionais serão necessários, portanto, uma sub-rede adicional deverá ser alocada para cada ambiente.

O AKS fornece controle granular de fluxo de rede leste-oeste dentro do cluster na forma de diretiva de rede Kubernetes. Esse controle de fluxo permite segmentar várias cargas de trabalho com diferentes limites de segurança de rede no mesmo cluster.

Para o Web App for Containers, não há restrições sobre quantos aplicativos você pode integrar a uma única sub-rede, desde que a sub-rede seja grande o suficiente. Não há práticas recomendadas para controle de acesso entre aplicativos Web na mesma rede virtual. Cada aplicativo Web gerencia independentemente o controle de acesso para o tráfego leste-oeste ou norte-sul da rede virtual ou da Internet, respectivamente.

Observação

Não é possível redimensionar sub-redes que tenham recursos implantados nelas. Tome cuidado extra ao planejar sua rede para evitar a necessidade de reimplantar componentes inteiros da carga de trabalho, o que pode levar ao tempo de inatividade.

Número de IPs de entrada disponíveis

A tabela a seguir leva em consideração a seção de planejamento de sub-rede anterior para definir quantos IPs podem ser expostos para um número arbitrário de aplicativos hospedados em uma única implantação de um serviço de contêiner do Azure.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Número de IPs de entrada Um Muitos Ambiente do Serviço de Aplicativo: Um
Nenhum Ambiente do Serviço de Aplicativo: Muitos

O Aplicativos de Contêiner permite um IP por ambiente, público ou privado. O AKS permite qualquer número de IPs, públicos ou privados. O Aplicativo Web para Contêineres, fora de um Ambiente do Serviço de Aplicativo, permite um IP público para todos os aplicativos em um plano do Serviço de Aplicativo e vários IPs privados diferentes que usam pontos de extremidade privados do Azure.

É importante observar que os aplicativos Web integrados a um Ambiente do Serviço de Aplicativo só recebem tráfego por meio do IP de entrada única associado ao Ambiente do Serviço de Aplicativo, seja ele público ou privado.

Rotas definidas pelo usuário e suporte a gateway NAT

Se uma carga de trabalho exigir rotas definidas pelo usuário (UDRs) e recursos de gateway NAT para controle de rede granular, os Aplicativos de Contêiner exigirão o uso de perfis de carga de trabalho. A compatibilidade de gateway UDR e NAT não está disponível no plano somente de consumo para ACA.

O AKS e o Aplicativo Web para Contêineres implementam esses dois recursos de rede por meio da funcionalidade de rede virtual padrão ou integração de rede virtual, respectivamente. Para elaborar, os pools de nós do AKS e o Aplicativo Web para Contêineres em um Ambiente de Serviço de Aplicativo já são recursos de rede virtual diretos. O Aplicativo Web para Contêineres que não estão em um Ambiente do Serviço de Aplicativo oferece suporte a UDRs e gateway NAT via integração de rede virtual. Com a integração de rede virtual, o recurso tecnicamente não reside diretamente na rede virtual, mas todo o seu acesso de saída flui pela rede virtual, e as regras associadas à rede afetam o tráfego conforme o esperado.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte a UDR Plano somente para consumo: ❌
Plano de perfil de carga de trabalho: ✅		 ✅ ✅
Suporte ao Gateway da NAT Plano somente para consumo: ❌
Plano de perfil de carga de trabalho: ✅		 ✅ ✅

Integração de rede privada

Para cargas de trabalho que exigem rede privada de Camada 4 estrita para entrada e saída, você deve considerar Aplicativos de Contêiner, AKS e o SKU de Ambiente de Serviço de Aplicativo de locatário único, onde as cargas de trabalho são implantadas em uma rede virtual autogerenciada, fornecendo os controles de rede privada granulares habituais.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Entrada privada em uma rede virtual ✅ ✅ Via ponto de extremidade privado
Saída privada de uma rede virtual ✅ ✅ Via integração de rede virtual
Ponto de extremidade público totalmente suprimido ✅ ✅ Somente Ambiente do Serviço de Aplicativo
Rede privada com Aplicativo Web para Contêineres

O Aplicativo Web para Contêineres fornece recursos de rede adicionais que não são exibidos da mesma maneira pelos outros serviços do Azure descritos neste artigo. Para implementar requisitos rigorosos de rede privada, as equipes de carga de trabalho precisam se familiarizar com esses conceitos de rede. Analise cuidadosamente estes recursos de rede:

Se você quiser uma solução de PaaS e preferir conceitos de rede compartilhados entre várias soluções do Azure, considere os Aplicativos de Contêiner.

Cobertura do protocolo

Uma consideração importante para a plataforma de hospedagem são os protocolos de rede que têm suporte para solicitações de aplicativo de entrada (entrada). O Web App for Containers é a opção mais rigorosa, suportando apenas HTTP e HTTPS. Os Aplicativos de Contêiner também permitem conexões TCP de entrada. O AKS é o mais flexível, suportando o uso irrestrito de TCP e UDP em portas selecionadas automaticamente.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte a protocolo e porta HTTP (porta 80)*
HTTPS (porta 443)*
TCP (portas 1-65535, exceto 80 e 443)		 TCP (qualquer porta)
UDP (qualquer porta)		 HTTP (porta 80)
HTTPS (porta 443)
Suporte para WebSocket ✅ ✅ ✅
Suporte do HTTP/2 ✅ ✅ ✅

*No ambiente Aplicativos de Contêiner, HTTP/S pode ser exposto em qualquer porta para comunicação dentro do cluster. Nesse cenário, os recursos internos de HTTP de Aplicativos de Contêiner, como CORS e afinidade de sessão, não se aplicam.

Os Aplicativos de Contêiner e o Aplicativo Web para Contêineres oferecem suporte ao TLS 1.2 para sua entrada HTTPS interna.

Balanceamento de carga

Com os Aplicativos de Contêiner e o Aplicativo Web para Contêineres, o Azure abstrai totalmente os balanceadores de carga de Camada 4 e Camada 7.

Em contraste, o AKS usa um modelo de responsabilidade compartilhada no qual o Azure gerencia a infraestrutura subjacente do Azure que a equipe de carga de trabalho configura fazendo interface com a API do Kubernetes. Para o balanceamento de carga da Camada 7 no AKS, você pode escolher opções gerenciadas pelo Azure, por exemplo, o complemento de roteamento de aplicativo gerenciado AKS ou o Gateway de Aplicativo para Contêineres, ou implantar e autogerenciar um controlador de entrada de sua escolha.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Balanceador de carga - Camada 4 Gerenciado pelo Azure Responsabilidade compartilhada Gerenciado pelo Azure
Balanceador de carga - Camada 7 Gerenciado pelo Azure Compartilhado ou autogerenciado Gerenciado pelo Azure

Descoberta de serviço

Em arquiteturas de nuvem, os tempos de execução podem ser removidos e recriados a qualquer momento para reequilibrar os recursos, para que os endereços IP da instância sejam alterados regularmente. Essas arquiteturas usam FQDNs (nomes de domínio totalmente qualificados) para comunicação confiável e consistente.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Descoberta de serviço FQDN gerenciado pelo Azure Kubernetes configuráveis FQDN gerenciado pelo Azure

Os Aplicativos Web para Contêineres fornecem FQDNs de entrada pública (comunicação norte-sul) prontos para uso. Não requer configuração de DNS adicional. No entanto, não há nenhum mecanismo interno para facilitar ou restringir o tráfego entre outros aplicativos (comunicação leste-oeste).

Os Aplicativos de Contêiner também fornecem FQDNs de entrada pública. No entanto, os Aplicativos de Contêiner vão além, permitindo que o FQDN do aplicativo seja exposto e restringindo o tráfego apenas dentro do ambiente. Essa funcionalidade facilita o gerenciamento da comunicação leste-oeste e habilita componentes como o Dapr.

As implantações do Kubernetes não são inicialmente detectáveis dentro ou fora do cluster. Você deve criar serviços do Kubernetes conforme definido pela API do Kubernetes, que expõe aplicativos à rede de forma endereçável.

Importante

Somente Aplicativos de Contêiner e AKS fornecem descoberta de serviço por meio de esquemas DNS internos em seus respectivos ambientes. Essa funcionalidade pode simplificar as configurações de DNS em ambientes de desenvolvimento/teste e produção. Por exemplo, você pode criar esses ambientes com nomes de serviço arbitrários que precisam ser exclusivos apenas dentro do ambiente ou cluster, para que possam ser os mesmos em desenvolvimento/teste e produção. Com o Aplicativo Web para Contêineres, os nomes de serviço devem ser exclusivos em diferentes ambientes para evitar conflitos com o DNS do Azure.

Domínios personalizados e TLS gerenciado

Os Aplicativos de Contêiner e o Aplicativo Web para Contêineres fornecem soluções prontas para uso para domínios personalizados e gerenciamento de certificados.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Configurar domínios personalizados Pronto para uso BYO Pronto para uso
TLS gerenciado para FQDNs do Azure Pronto para uso N/D Pronto para uso
TLS gerenciado para domínios personalizados Em versão prévia BYO Pronto para uso ou BYO

Os usuários do AKS são responsáveis por gerenciar DNS, configurações de cluster e certificados TLS para seus domínios personalizados. Embora o AKS não ofereça TLS gerenciado, os clientes podem aproveitar o software do ecossistema Kubernetes, por exemplo, o popular gerenciador de certificados para gerenciar certificados TLS.

TLS Mútuo

Outra alternativa para restringir o tráfego de entrada é o TLS mútuo (mTLS). O TLS mútuo é um protocolo de segurança que garante que o cliente e o servidor em comunicação sejam autenticados. Para realizar a autenticação, ambas as partes trocam e verificam certificados antes que qualquer dado seja transmitido.

O Aplicativo Web para Contêineres tem suporte mTLS interno para conexões de cliente de entrada. No entanto, o aplicativo precisa validar o certificado acessando o X-ARR-ClientCert cabeçalho HTTP que a plataforma do Serviço de Aplicativos encaminha.

Os Aplicativos de Contêiner também têm suporte integrado para mTLS. Eles encaminham o certificado do cliente para o aplicativo no cabeçalho HTTP X-Forwarded-Client-Cert. Você também pode habilitar facilmente o mTLS automático para comunicação interna entre aplicativos em um único ambiente.

O TLS mútuo no AKS pode ser implementado por meio da malha de serviço baseada em Istio como um complemento gerenciado, que inclui recursos mTLS para conexões de cliente de entrada e comunicação dentro do cluster entre serviços. As equipes de carga de trabalho também podem optar por instalar e gerenciar outra oferta de malha de serviço do ecossistema Kubernetes. Essas opções tornam a implementação do mTLS no Kubernetes a mais flexível.

Conceitos de rede específicos do serviço

As seções anteriores descrevem algumas das considerações mais comuns a serem levadas em conta. Para obter mais detalhes e saber mais sobre os recursos de rede específicos de serviços de contêiner individuais do Azure, consulte estes artigos:

As seções anteriores se concentram no design de rede. Continue para a próxima seção para saber mais sobre segurança de rede e proteção de tráfego de rede.

Considerações de segurança

A falha em lidar com os riscos de segurança pode levar a acesso não autorizado, violações de dados ou vazamentos de informações confidenciais. Os contêineres oferecem um ambiente encapsulado para seu aplicativo. Os sistemas de hospedagem e as sobreposições de rede subjacentes, no entanto, exigem proteções adicionais. Sua escolha de serviço de contêiner do Azure precisa dar suporte aos seus requisitos específicos para proteger cada aplicativo individualmente e fornecer medidas de segurança adequadas para impedir o acesso não autorizado e reduzir o risco de ataques.

Visão geral da comparação de segurança

A maioria dos serviços do Azure, incluindo Aplicativos de Contêiner, AKS e Aplicativo Web para Contêineres, integra-se às principais ofertas de segurança, incluindo Cofre de Chaves e identidades gerenciadas.

Dos serviços deste guia, o AKS oferece a maior configurabilidade e extensibilidade em parte por apresentar componentes subjacentes, que muitas vezes podem ser protegidos por meio de opções de configuração. Por exemplo, os clientes podem desabilitar contas locais para o servidor de API do Kubernetes ou ativar atualizações automáticas para nós subjacentes por meio de opções de configuração.

Para obter uma comparação detalhada, analise cuidadosamente as considerações a seguir para garantir que seus requisitos de segurança de carga de trabalho possam ser atendidos.

Segurança do plano de controle do Kubernetes

O AKS oferece a maior flexibilidade das três opções consideradas neste artigo, fornecendo acesso total à API do Kubernetes para que você possa personalizar a orquestração de contêineres. Esse acesso à API do Kubernetes, no entanto, também representa uma superfície de ataque significativa, e você precisa protegê-la.

Importante

Observe que esta seção não é relevante para o Aplicativo Web para Contêineres, que usa a API do Azure Resource Manager como seu plano de controle.

Segurança baseada em identidade

Os clientes são responsáveis por proteger o acesso baseado em identidade à API. Pronto para uso, o Kubernetes fornece seu próprio sistema de gerenciamento de autenticação e autorização, que também precisa ser protegido com controles de acesso.

Para aproveitar um único plano de vidro para gerenciamento de identidade e acesso no Azure, é uma prática recomendada desabilitar contas locais específicas do Kubernetes e, em vez disso implementar a integração do Microsoft Entra gerenciada pelo AKS junto com o Azure RBAC para Kubernetes. Se você implementar essa prática recomendada, os administradores não precisarão executar o gerenciamento de identidade e acesso em várias plataformas.

Aplicativos de Contêiner AKS
Controles de acesso à API do Kubernetes Sem acesso Acesso completo

Os clientes que usam Aplicativos de Contêiner não têm acesso à API do Kubernetes. A Microsoft fornece segurança para essa API.

Segurança baseada em rede

Se você quiser restringir o acesso à rede ao plano de controle do Kubernetes, precisará usar o AKS, que fornece duas opções. A primeira opção é usar clusters AKS privados, que usam o Link Privado do Azure entre a rede privada do servidor de API e a rede privada do cluster AKS. A segunda opção é a integração de VNet do Servidor de API (versão preliminar), em que o servidor de API é integrado a uma sub-rede delegada. Para saber mais, consulte a documentação.

Há consequências na implementação de acesso restrito à rede para a API do Kubernetes. Mais notavelmente, o gerenciamento pode ser realizado apenas a partir da rede privada. Normalmente, isso significa que você precisa implantar agentes auto-hospedados para o Azure DevOps ou GitHub Actions. Para saber mais sobre outras limitações, consulte a documentação específica do produto.

Aplicativos de Contêiner AKS
Segurança de rede da API do Kubernetes Não configurável em PaaS Configurável: IP público ou IP privado

Essas considerações não se aplicam aos Aplicativos de Contêiner. Por ser PaaS, a Microsoft abstrai a infraestrutura subjacente.

Segurança da rede do plano de dados

Os recursos de rede a seguir podem ser usados para controlar o acesso a, de e dentro de uma carga de trabalho.

Usando políticas de rede para fornecer segurança para o tráfego dentro do cluster

Algumas posturas de segurança exigem segregação de tráfego de rede em um ambiente, por exemplo, quando você usa ambientes multilocatários para hospedar aplicativos de várias camadas ou várias camadas. Nesses cenários, você deve escolher AKS e implementar políticas de rede, uma tecnologia nativa da nuvem que permite a configuração granular da rede de Camada 4 em clusters Kubernetes.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Políticas de rede Plano de consumo: ❌
Plano dedicado: ❌		 ✅ ❌

Dos três serviços do Azure descritos neste artigo, o AKS é o único que oferece suporte a isolamento de carga de trabalho adicional dentro do cluster. Não há suporte para políticas de rede em Aplicativos de Contêiner ou Aplicativo Web para Contêineres.

Grupos de segurança de rede

Em todos os cenários, você pode regular a comunicação de rede dentro da rede virtual mais ampla usando grupos de segurança de rede, o que permite usar regras de tráfego de Camada 4 que regulam a entrada e a saída no nível da rede virtual.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Grupos de segurança de rede Plano de consumo: ✅
Plano dedicado: ✅		 ✅ ✅ Aplicativos integrados à rede virtual: somente saída

Restrições de IP para entrada

Normalmente, as restrições de tráfego de rede são aplicadas por meio das regras de Camada 4 descritas acima. No entanto, em cenários de PaaS de aplicativos sem integração de rede virtual, pode ser útil restringir o tráfego na camada de aplicativo.

Os Aplicativos de Contêiner e o Aplicativo Web para Contêineres fornecem restrições internas de IP de origem para tráfego de entrada em aplicativos individuais.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Restrições de IP de entrada na camada de aplicativo Pronto para uso Auto-gerenciado ou via complemento gerenciado Pronto para uso
Consumo de recursos - Consome recursos de cluster -

Para cargas de trabalho do AKS, a implementação depende do controlador de entrada escolhido. Tanto o complemento de roteamento de aplicativo gerenciado pelo Azure quanto o autogerenciado consomem recursos de cluster.

Segurança no nível do aplicativo

Você precisa proteger as cargas de trabalho não apenas no nível de rede e infraestrutura, mas também no nível de carga de trabalho e aplicativo. As soluções de contêiner do Azure se integram às ofertas de segurança do Azure para ajudar a padronizar a implementação e os controles de segurança para seus aplicativos.

Integração do Key Vault

É uma prática recomendada armazenar e gerenciar segredos, chaves e certificados em uma solução de gerenciamento de chaves como o Cofre de Chaves, que fornece segurança aprimorada para esses componentes. Em vez de armazenar e configurar segredos no código ou em um serviço de computação do Azure, todos os aplicativos devem se integrar ao Cofre de Chaves.

A integração do Key Vault permite que os desenvolvedores de aplicativos se concentrem no código do aplicativo. Todos os três serviços de contêiner do Azure descritos neste artigo podem sincronizar automaticamente segredos do serviço Cofre de Chaves e fornecê-los ao aplicativo, normalmente como variáveis de ambiente ou arquivos montados.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Integração do Key Vault ✅ ✅ ✅

Para saber mais, veja:

Suporte de identidade gerenciada

Os aplicativos com identidades gerenciadas atribuídas podem acessar recursos do Azure sem senhas. Todos os serviços de contêiner mencionados neste guia oferecem suporte a identidades gerenciadas.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte de identidade gerenciada ✅ ✅ ✅

Para saber mais, veja:

Proteção contra ameaças e avaliações de vulnerabilidades com o Defender para Contêineres

A proteção contra ameaças contra vulnerabilidades também é importante. É uma prática recomendada usar o Defender para contêineres. As avaliações de vulnerabilidade têm suporte nos registros de contêiner do Azure, portanto, podem ser usadas por qualquer serviço de contêiner do Azure, não apenas pelos descritos neste artigo. A proteção de tempo de execução do Defender para contêineres, no entanto, está disponível apenas para AKS.

Como o AKS expõe a API nativa do Kubernetes, a segurança do cluster também pode ser avaliada com ferramentas de segurança específicas do Kubernetes a partir do ecossistema Kubernetes.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Proteção contra ameaças contra CLR ❌ ✅ ❌

Para obter mais informações, consulte Matriz de suporte a contêineres no Defender para Nuvem.

Observe que as avaliações de vulnerabilidade de imagem de contêiner não são varreduras em tempo real. O registro de contêiner do Azure é verificado em intervalos regulares.

Linhas de base de segurança

Em geral, a maioria dos serviços de contêiner do Azure integra ofertas de segurança do Azure. No geral, tenha em mente que um conjunto de recursos de segurança é apenas uma pequena parte da implementação da segurança na nuvem. Para obter mais informações sobre como implementar segurança para serviços de contêiner, consulte as seguintes linhas de base de segurança específicas do serviço:

As linhas de base de segurança abrangem outras integrações do Azure, incluindo criptografia de hardware e registro em log, que estão fora do escopo deste artigo.

Well-Architected Framework para Segurança

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner descritos aqui.

Para obter orientações de segurança mais completas sobre o AKS, consulte Revisão do Well-Architected Framework - AKS.

Considerações operacionais

Para executar com êxito uma carga de trabalho em produção, as equipes precisam implementar práticas de excelência operacional, incluindo registro em log centralizado, monitoramento, escalabilidade, atualizações e aplicação de patch regulares e gerenciamento de imagens.

Atualizações e patches

É importante que o sistema operacional subjacente de um aplicativo seja atualizado e corrigido regularmente. Tenha em mente, no entanto, que a cada atualização há um risco de falha. Esta seção e a próxima descrevem as principais considerações para os três serviços de contêiner no que diz respeito à responsabilidade compartilhada entre o cliente e a plataforma.

Como um serviço Kubernetes gerenciado, o AKS fornecerá as imagens atualizadas para o sistema operacional do nó e os componentes do plano de controle. Mas as equipes de carga de trabalho são responsáveis por aplicar atualizações aos seus clusters. Você pode acionar atualizações manualmente ou aproveitar o recurso de canais de atualização automática de cluster para garantir que seus clusters estejam atualizados. Consulte o guia de operações do dia 2 do AKS para saber mais sobre como aplicar patches e atualizar clusters do AKS.

Aplicativos de Contêiner e Aplicativo Web para Contêineres são soluções de PaaS. O Azure é responsável pelo gerenciamento de atualizações e patches, para que os clientes possam evitar a complexidade do gerenciamento de atualizações do AKS.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Atualizações do plano de controle Plataforma Cliente Plataforma
Patches e atualizações de host Plataforma Cliente Plataforma
Atualizações e patches de imagens de contêiner Customer Cliente Customer

Atualizações de imagem de contêiner

Independentemente da solução de contêiner do Azure, os clientes são sempre responsáveis por suas próprias imagens de contêiner. Se houver patches de segurança para imagens base de contêiner, é sua responsabilidade reconstruir suas imagens. Para obter alertas sobre essas vulnerabilidades, use o Defender para contêineres para contêineres hospedados no Registro de Contêiner.

Escalabilidade

O dimensionamento é usado para ajustar a capacidade de recursos para atender às demandas, adicionando mais capacidade para garantir o desempenho e removendo a capacidade não utilizada para economizar dinheiro. Ao escolher uma solução de contêiner, você precisa considerar restrições de infraestrutura e estratégias de dimensionamento.

Escalabilidade vertical da infraestrutura

O dimensionamento vertical refere-se à capacidade de aumentar ou diminuir a infraestrutura existente, ou seja, computar CPU e memória. Cargas de trabalho diferentes exigem quantidades diferentes de recursos de computação. Ao escolher uma solução de contêiner do Azure, você precisa estar ciente das ofertas de SKU de hardware disponíveis para um serviço específico do Azure. Elas variam e podem impor restrições adicionais.

Para o AKS, examine os tamanhos das máquinas virtuais na documentação do Azure e as restrições do AKS por região.

Estes artigos fornecem detalhes sobre as ofertas de SKU para os outros dois serviços:

Escalabilidade horizontal da infraestrutura

O dimensionamento horizontal refere-se à capacidade de aumentar ou diminuir a capacidade por meio de nova infraestrutura, como nós de VM. Durante aumentos ou diminuições de dimensionamento, a camada de consumo de Aplicativos de Contêiner abstrai as máquinas virtuais subjacentes. Para os serviços de contêiner do Azure restantes, você gerencia a estratégia de dimensionamento horizontal usando a API padrão do Azure Resource Manager.

Observe que o dimensionamento horizontal e vertical inclui o rebalanceamento de instâncias, portanto, também cria um risco de tempo de inatividade. O risco é menor do que o risco correspondente com o dimensionamento vertical. No entanto, as equipes de carga de trabalho são sempre responsáveis por garantir que seus aplicativos possam lidar com falhas e por implementar inicializações e desligamentos normais de seus aplicativos para evitar tempo de inatividade.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Dimensionamento horizontal e vertical da infraestrutura Plano de consumo: N/A
Plano dedicado: configurável		 Configurável Configurável
Provisionamento flexível de hardware Plano de consumo: N/A
Plano dedicado: abstraído com perfis de carga de trabalho		 Qualquer SKU da VM Abstraído. Consulte Plano do Serviço de Aplicativo.

Importante

As opções de provisionamento de hardware disponíveis por meio do plano Aplicativos Contêiner Dedicados (perfis de carga de trabalho) e do Aplicativo Web para Contêineres (planos do Serviço de Aplicativo) não são tão flexíveis quanto o AKS. Você precisa se familiarizar com os SKUs disponíveis em cada serviço para garantir que suas necessidades sejam atendidas.

Escalabilidade do aplicativo

A medida típica para acionar o dimensionamento de infraestrutura e aplicativos é o consumo de recursos: CPU e memória. Algumas soluções de contêiner podem dimensionar a contagem de instâncias de contêiner em métricas com contexto específico do aplicativo, como solicitações HTTP. Por exemplo, AKS e Aplicativos de Contêiner podem dimensionar instâncias de contêiner com base em filas de mensagens via KEDA e muitas outras métricas por meio de seus dimensionadores. Esses recursos fornecem flexibilidade ao escolher a estratégia de escalabilidade para seu aplicativo. O Aplicativo Web para Contêineres depende das opções de escalabilidade fornecidas pelo Azure. (Consulte a tabela a seguir.) O Web App for Containers não oferece suporte a configurações personalizadas de dimensionador como o KEDA.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Dimensionamento horizontal de contêiner HTTP, TCP ou baseado em métricas (CPU, memória, orientado a eventos). Baseado em métricas (CPU, memória ou personalizado). Manual, baseado em métricas ou automático (versão preliminar).
Escalabilidade orientada a eventos Sim. Nativo de nuvem. Sim. Nativo de nuvem. Requer configuração adicional. Sim. Específico do recurso do Azure.

Observabilidade

Instrumentação de carga de trabalho

Reunir métricas para aplicativos complexos ou de várias camadas pode ser um desafio. Para obter métricas, você pode integrar cargas de trabalho em contêineres com o Azure Monitor de duas maneiras:

  • Instrumentação automática. Não é necessário alterar o código.
  • Instrumentação manual. Alterações mínimas de código necessárias para integrar e configurar o SDK e/ou o cliente.
Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Instrumentação automática via plataforma ❌ ❌ Suporte parcial*
Instrumentação automática via agente ❌ Suporte parcial* N/D
Instrumentação manual Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry

*AKS e Web App para Containers têm suporte para instrumentação automática para determinadas configurações de cargas de trabalho Linux e Windows, dependendo do idioma do aplicativo. Para obter mais informações, confira estes tópicos:

A instrumentação no código do aplicativo é de responsabilidade dos desenvolvedores de aplicativos, portanto, é independente de qualquer solução de contêiner do Azure. Sua carga de trabalho pode usar soluções como:

Logs

Todos os serviços de contêiner do Azure fornecem funcionalidade de log de aplicativo e plataforma. Os logs do aplicativo são logs de console gerados pela carga de trabalho. Os logs da plataforma capturam eventos que ocorrem no nível da plataforma, fora do escopo do seu aplicativo, como dimensionamento e implantações.

As principais diferenças entre a funcionalidade de registro em log para serviços de contêiner dizem respeito ao log da plataforma: o que é registrado e como os logs são organizados internamente. O Azure Monitor é o principal serviço de log no Azure que se integra a esses serviços. O Monitor usa logs de recursos para separar logs provenientes de diferentes fontes em categorias. Uma maneira de determinar quais logs estão disponíveis em cada serviço do Azure é examinar as categorias de log de recursos disponíveis para cada um dos serviços.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte para streaming de log (streaming em tempo real) ✅ ✅ ✅
Suporte para o Azure Monitor ✅ ✅ ✅
Logs de recursos do Azure Monitor Console e sistema Servidor de API do Kubernetes, Auditoria, Agendador, Dimensionador automático de Cluster e muito mais ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs e muito mais

Para obter uma descrição detalhada de cada um dos logs de recursos na tabela, selecione os links na tabela.

Aqui está um breve resumo dos recursos de log dos serviços de contêiner:

  • Os Aplicativos de Contêiner abstraem todos os seus logs internos do Kubernetes em duas categorias. Um deles, chamado de logs de Console, contém os logs de contêiner de carga de trabalho. Uma segunda categoria do Sistema contém todos os logs relacionados à plataforma.
  • O AKS fornece todos os logs relacionados ao Kubernetes e controle granular sobre o que pode ser registrado. Ele também mantém total compatibilidade com ferramentas de cliente Kubernetes para streaming de log, como kubectl.
  • O Aplicativo Web para Contêineres fornece muitas categorias de logs de recursos porque sua plataforma (Serviço de Aplicativo) não é exclusiva para cargas de trabalho de contêiner. Para operações específicas de contêiner que gerenciam sua plataforma Docker interna, ele fornece a categoria de log AppServicePlatformLogs. Outra categoria importante é AppServiceEnvironmentPlatformLogs, que registra eventos como dimensionamento e alterações de configuração.

Well-Architected Framework para Excelência Operacional

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner descritos aqui. Consulte estes artigos para revisar as diretrizes completas de Excelência Operacional para os seguintes serviços:

Confiabilidade

Confiabilidade refere-se à capacidade de um sistema de reagir a falhas e permanecer totalmente funcional. No nível de software de aplicativo, as cargas de trabalho devem implementar práticas recomendadas como cache, repetição, padrões de disjuntor e verificações de integridade. No nível de infraestrutura, o Azure é responsável por lidar com falhas físicas, como falhas de hardware e quedas de energia, em datacenters. As falhas ainda podem acontecer. As equipes de carga de trabalho devem selecionar a camada de serviço do Azure apropriada e aplicar as configurações de instância mínima necessárias para implementar failovers automáticos entre zonas de disponibilidade.

Para escolher a camada de serviço apropriada, você precisa entender como os SLAs (contratos de nível de serviço) e as zonas de disponibilidade funcionam.

Contratos de nível de serviço

A confiabilidade geralmente é medida por métricas orientadas aos negócios, como SLAs, ou métricas de recuperação, como RTOs (Objetivos de Tempo de Recuperação).

O Azure tem muitos SLAs para serviços específicos. Não existe um nível de serviço de 100%, porque falhas sempre podem ocorrer em software e hardware, e na natureza, por exemplo, tempestades e terremotos. Um SLA não é uma garantia, mas sim um contrato de disponibilidade de serviço com suporte financeiro.

Para obter os SLAs e detalhes mais recentes, baixe o documento SLA mais recente para o Microsoft Online Services no site de licenciamento da Microsoft.

Níveis gratuitos vs. pagos

Geralmente, as camadas gratuitas de serviços do Azure não oferecem um SLA, o que as torna opções econômicas para ambientes que não são de produção. Para ambientes de produção, no entanto, é uma prática recomendada escolher uma camada paga que tenha um SLA.

Fatores adicionais para AKS

O AKS tem diferentes SLAs para diferentes componentes e configurações:

  • Plano de controle. O servidor de API do Kubernetes tem um SLA separado.
  • Plano de dados. Os pools de nós usam os SLAs de SKU de VM subjacentes.
  • Zonas de disponibilidades. Há SLAs diferentes para os dois planos, dependendo se o cluster AKS tem zonas de disponibilidade habilitadas e executando várias instâncias em zonas de disponibilidade.

Observe que, quando você usa vários serviços do Azure, os SLOs compostos podem diferir e ser menores do que os SLAs de serviço individuais.

Redundância com zonas de disponibilidade

As zonas de disponibilidade são datacenters distintos que têm energia elétrica, resfriamento e assim por diante independentes, dentro de uma única região. A redundância resultante aumenta a tolerância a falhas sem exigir a implementação de arquiteturas de várias regiões.

O Azure tem zonas de disponibilidade em todos os países em que o Azure opera uma região de datacenter. Para permitir que várias instâncias de contêineres cruzem zonas de disponibilidade, certifique-se de selecionar SKUs, camadas de serviço e regiões que fornecem suporte à zona de disponibilidade.

Recurso Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte à zona de disponibilidade Completo Completo Completo

Por exemplo, um aplicativo ou infraestrutura configurada para executar uma única instância ficará indisponível se ocorrer um problema na zona de disponibilidade onde o hardware está hospedado. Para usar totalmente o suporte à zona de disponibilidade, você deve implantar cargas de trabalho com uma configuração mínima de três instâncias do contêiner, espalhadas entre zonas.

Verificações de integridade e recuperação automática

Os pontos de extremidade de verificação de integridade são cruciais para uma carga de trabalho confiável. Mas construir esses endpoints é apenas metade da solução. A outra metade é controlar o que a plataforma de hospedagem faz, e como, quando há falhas.

Para distinguir melhor entre os tipos de investigação de integridade, dê uma olhada nos tipos internos de investigações do Kubernetes:

  • Inicialização. Verifica se o aplicativo foi iniciado com êxito.
  • Preparação. Verifica se o aplicativo está pronto para lidar com solicitações de entrada.
  • Atividade. Verifica se o aplicativo ainda está em execução e responsivo.

Outra consideração importante é a frequência com que essas verificações de integridade são solicitadas ao aplicativo (granularidade interna). Se você tiver um longo intervalo entre essas solicitações, poderá continuar a fornecer tráfego até que a instância seja considerada não íntegra.

A maioria dos aplicativos oferece suporte a verificações de integridade por meio do protocolo HTTP(S). No entanto, alguns podem precisar de outros protocolos, como TCP ou gRPC, para executar essas verificações. Tenha isso em mente ao projetar seu sistema de verificação de integridade.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Investigações de inicialização ✅ ✅ Suporte parcial
Investigações de preparação ✅ ✅ ❌
Investigações de atividade ✅ ✅ ✅
Granularidade do intervalo Segundos Segundos 1 minuto
Suporte de protocolo HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

As verificações de integridade são mais fáceis de implementar no Aplicativo Web para Contêineres. Há algumas considerações importantes:

  • Suas investigações de inicialização são incorporadas e não podem ser alteradas. Ele envia uma solicitação HTTP para a porta inicial do contêiner. Qualquer resposta do seu aplicativo é considerada um início bem-sucedido.
  • Ele não suporta investigações de preparação. Se a investigação de inicialização for bem-sucedida, a instância de contêiner será adicionada ao pool de instâncias íntegras.
  • Ela envia a verificação de integridade em intervalos de um minuto. Não é possível alterar o intervalo.
  • O limite mínimo que você pode definir para que uma instância não íntegra seja removida do mecanismo interno de balanceamento de carga é de dois minutos. A instância não íntegra recebe tráfego por pelo menos dois minutos depois de falhar em uma verificação de integridade. O valor padrão dessa configuração é 10 minutos.

Os Aplicativos de Contêiner e o AKS, por outro lado, são muito mais flexíveis e oferecem opções semelhantes. Em termos de diferenças específicas, o AKS fornece as seguintes opções para executar verificações de integridade, que não estão disponíveis em aplicativos de contêiner:

Recuperação automática

Para identificar uma instância de contêiner incorreta e parar de enviar tráfego para ela é um começo. A próxima etapa é implementar a recuperação automática. A Recuperação automática é o processo de reiniciar o aplicativo em uma tentativa de recuperação de um estado não íntegro. Veja como os três serviços de contêiner se comparam:

  • No Aplicativo Web para Contêineres, não há opção de reiniciar uma instância de contêiner imediatamente após uma falha da verificação de integridade. Se a instância continuar falhando por uma hora, ela será substituída por uma nova instância. Há outro recurso, chamado recuperação automática, que monitora e reinicia as instâncias. Não está diretamente relacionado às verificações de integridade. Ele utiliza diversas métricas de aplicativo, como limites de memória, duração da solicitação HTTP e códigos de status.
  • Os Aplicativos de Contêiner e o AKS tentam reiniciar automaticamente uma instância de contêiner se a investigação de atividade atingir o limite de falha definido.

Implantações de aplicativos sem tempo de inatividade

A capacidade de implantar e substituir aplicativos sem causar nenhum tempo de inatividade para os usuários é crucial para uma carga de trabalho confiável. Todos os três serviços de contêiner descritos neste artigo oferecem suporte a implantações sem tempo de inatividade, mas de maneiras diferentes.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Estratégia sem tempo de inatividade Atualização sem interrupção Atualização contínua e todas as outras estratégias do Kubernetes Slots de implantação

Observe que as arquiteturas de aplicativos também devem oferecer suporte à implantação sem tempo de inatividade. Consulte Azure Well-Architected Framework para obter orientação.

Limites de recursos

Outro componente importante de um ambiente compartilhado confiável é seu controle sobre o uso de recursos (como CPU ou memória) de seus contêineres. Você precisa evitar cenários em que um único aplicativo ocupa todos os recursos e deixa outros aplicativos em um estado inadequado.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Limites de recursos (CPU ou memória) Por aplicativo/contêiner Por aplicativo/contêiner
Por namespace		 Por plano do Serviço de Aplicativo
  • Aplicativo Web para Contêineres: você pode hospedar vários aplicativos (contêineres) em um único plano do Serviço de Aplicativo. Por exemplo, você pode alocar um plano com dois núcleos de CPU e 4 GiB de RAM no qual você pode executar vários aplicativos Web em contêineres. No entanto, você não pode restringir um dos aplicativos a uma certa quantidade de CPU ou memória. Todos eles competem pelos mesmos recursos do plano do Serviço de Aplicativo. Se você quiser isolar os recursos do aplicativo, precisará criar planos adicionais do Serviço de Aplicativos.
  • Aplicativos de Contêiner: você pode definir limites de CPU e memória por aplicativo em seu ambiente. No entanto, você está restrito a um conjunto de combinações permitidas de CPU e memória. Por exemplo, você não pode configurar uma vCPU e 1 GiB de memória, mas você pode configurar uma vCPU e 2 GiB de memória. Um ambiente de Aplicativos de Contêiner é análogo a um namespace do Kubernetes.
  • AKS: você pode escolher qualquer combinação de vCPU e memória, desde que seus nós tenham o hardware para suportá-la. Você também pode limitar os recursos no nível do namespace se quiser segmentar o cluster dessa maneira.

Well-Architected Framework para Confiabilidade

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner no Azure. Se você quiser revisar as diretrizes completas de confiabilidade para um serviço específico, consulte estes artigos:

Conclusão

Soluções bem arquitetadas estabelecem as bases para cargas de trabalho bem-sucedidas. Embora as arquiteturas possam ser ajustadas à medida que a carga de trabalho cresce e as equipes progridem em suas jornadas de nuvem, algumas decisões, especialmente em relação à rede, são difíceis de reverter sem tempo de inatividade significativo ou reimplantação.

Em geral, quando você compara os serviços de contêiner do Azure, surge um tema: o AKS apresenta a infraestrutura mais subjacente, oferecendo assim a maior configurabilidade e extensibilidade. A quantidade de sobrecarga operacional e complexidade é altamente variável para cargas de trabalho AKS. Algumas equipes podem reduzir consideravelmente a sobrecarga operacional usando complementos e extensões gerenciados pela Microsoft, bem como recursos de atualização automática. Outros clientes podem preferir o controle total do cluster para aproveitar a extensibilidade total do Kubernetes e do ecossistema CNCF. Por exemplo, embora a Microsoft ofereça o Flux como uma extensão GitOps gerenciada, muitas equipes optam por configurar e operar o ArgoCD por conta própria.

Equipes de carga de trabalho que, por exemplo, não exigem aplicativos CNCF, têm menos experiência em operações ou preferem se concentrar em recursos de aplicativos podem preferir uma oferta de PaaS. Recomendamos que eles considerem primeiro os Aplicativos de Contêiner.

Embora os Aplicativos de Contêiner e o Aplicativo Web para Contêineres sejam ofertas de PaaS que fornecem níveis semelhantes de infraestrutura gerenciada pela Microsoft, uma diferença importante é que os Aplicativos de Contêiner estão mais próximos do Kubernetes e fornecem recursos nativos da nuvem adicionais para descoberta de serviços, dimensionamento automático orientado a eventos, integração com Dapr e muito mais. No entanto, as equipes que não precisam desses recursos e estão familiarizadas com os modelos de rede e implantação do Serviço de Aplicativo podem preferir o Aplicativo Web para Contêineres.

As generalizações podem ajudá-lo a restringir a lista de serviços de contêiner do Azure a serem considerados. Mas lembre-se de que você também precisa verificar sua escolha examinando requisitos individuais em detalhes e combinando-os com conjuntos de recursos específicos do serviço.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas