Compartilhar via

Considerações gerais sobre 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. Fornece uma visão geral das considerações de nível de funcionalidade que são comuns e importantes 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.

Nota

Este artigo é a parte dois 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 neste artigo são divididas em quatro categorias:

considerações de arquitetura e rede

  • Suporte ao sistema operacional
  • Espaços de endereço de rede
  • Noções básicas sobre o fluxo de tráfego
  • Planejando sub-redes
  • Número de IPs de entrada disponíveis
  • Rotas definidas pelo usuário e suporte ao gateway NAT
  • Integração de rede privada
  • Cobertura de 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 sobre segurança

  • Fornecendo segurança para o tráfego intra cluster usando políticas de rede
  • Grupos de segurança de rede
  • Integração do Azure Key Vault
  • Suporte à identidade gerenciada
  • Avaliações de vulnerabilidade e proteção contra ameaças com o Defender para Contêineres
  • Linhas de base de segurança
  • Azure Well-Architected Estrutura 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 Estrutura para a Excelência Operacional

considerações sobre 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 Estrutura 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 maduro para aplicativos Web e APIs, rede, observabilidade, ferramentas de desenvolvedor e operações: AKS (Serviço de Kubernetes do Azure), AKS Automático, 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 página de categoria de produto dos serviços de contêiner.

Nota

Algumas seções distinguem o AKS Standard do AKS Automatic. Se uma seção não distinguir entre os dois, pressupõe-se paridade de funcionalidades.

Considerações de arquitetura

Esta seção descreve as decisões arquitetônicas difíceis de reverter ou corrigir sem exigir um tempo de inatividade significativo ou uma nova implantação. É especialmente necessário ter essa consideração em mente para componentes fundamentais, como rede e segurança.

Essas considerações não são específicas para os pilares da Estrutura Well-Architected. No entanto, eles merecem um escrutínio extra e avaliação em relação aos requisitos das empresas quando você escolhe um serviço de contêiner do Azure.

Nota

O AKS Automatic é uma solução mais opinativa do que o AKS Standard. Alguns recursos pré-configurados não podem ser desabilitados. Este guia não destaca esses recursos. Para obter informações atualizadas sobre essas restrições e a comparação de recursos Standard vs Automáticos, consulte: Comparação de recursos Standard e Automáticos do AKS.

Suporte ao sistema operacional

A maioria dos aplicativos em contêineres é executada em contêineres do Linux, que são compatíveis com 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 AKS Automático Aplicativo Web para contêineres
Suporte ao Linux ✅ ✅ ✅ ✅
suporte ao Windows ❌ ✅ ❌ ✅
suporte ao sistema operacional misto ❌ ✅ ❌ ❌*

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

Considerações sobre rede

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

  • Container Apps é uma oferta de PaaS que fornece muitos recursos de rede gerenciados pelo Azure, como descoberta de serviço, domínios internos gerenciados e controles de rede virtual.
  • do AKS é o mais configurável dos três serviços e fornece mais controle sobre o fluxo de rede. Por exemplo, ele fornece controladores de entrada personalizados e o controle do tráfego intra cluster por meio de políticas 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 os complementos do ecossistema do 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 para o 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 mais familiar do Azure são incentivadas a considerar os Aplicativos de Contêiner.

Tenha em mente que a rede é uma camada de infraestrutura fundamental. Geralmente, é difícil fazer alterações no design sem implantar novamente a carga de trabalho, o que pode levar ao tempo de inatividade. Portanto, se sua carga de trabalho tiver requisitos de rede específicos, examine esta seção cuidadosamente antes de restringir a seleção do 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 azul/verde 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		 Necessá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.

Noções básicas sobre o 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 de 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 do aplicativo para sua carga de trabalho não é o único fator que determina o volume de rede em que 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 aplica-se apenas 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 colocados. Portanto, você precisará introduzir dispositivos de rede adicionais do Azure para balanceamento de carga de entrada se precisar de entrada pública e privada. 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 adicionais de Aplicativos de Contêiner são necessários, portanto, uma sub-rede adicional deve ser alocada para cada ambiente.

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

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

Nota

Você não pode redimensionar sub-redes que têm recursos implantados neles. Tome cuidado extra ao planejar sua rede para evitar a necessidade de reimplantar componentes de carga de trabalho inteiros, 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

Os Aplicativos de Contêiner permitem 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 dentro de 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 recebem apenas tráfego por meio do IP de entrada único 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 UDRs (rotas definidas pelo usuário) 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 da 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 por meio da rede virtual e as regras associadas da rede afetam o tráfego conforme o esperado.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Suporte UDR Plano somente de consumo: ❌
Plano de perfil de carga de trabalho: ✅		 ✅ ✅
Suporte ao Gateway da NAT Plano somente de 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 o Aplicativo Web para Contêineres

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

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

Cobertura de protocolo

Uma consideração importante para a plataforma de hospedagem são os protocolos de rede suportados para solicitações de aplicativo de entrada. O Aplicativo Web para Contêineres é a opção mais rigorosa, dando suporte apenas a HTTP e HTTPS. Além disso, os Aplicativos de Contêiner permitem conexões TCP de entrada. O AKS é o mais flexível, oferecendo suporte ao uso irrestrito de TCP e UDP em portas auto-selecionadas.

Aplicativos de Contêiner AKS Aplicativo Web para Contêineres
Suporte a protocolo e a 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 a WebSocket ✅ ✅ ✅
suporte a 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, recursos HTTP internos dos 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 dão 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.

Por outro lado, 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 ao interagir 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 da Camada 4 Gerenciado pelo Azure Responsabilidade compartilhada Gerenciado pelo Azure
Balanceador de carga da Camada 7 Gerenciado pelo Azure Compartilhado ou autogerenciado Gerenciado pelo Azure

Descoberta de serviço

Em arquiteturas de nuvem, os runtimes podem ser removidos e recriados a qualquer momento para reequilibrar recursos, portanto, os endereços IP de instância são 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. Nenhuma configuração de DNS adicional é necessária. 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 habilitar 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 maneira endereçável.

Importante

Somente os Aplicativos de Contêiner e o 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 iguais em desenvolvimento/teste e produção. Com o Aplicativo Web para Contêineres, os nomes de serviço devem ser exclusivos em ambientes diferentes 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 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/A Pronto para uso
TLS gerenciado para domínios personalizados na 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 do Kubernetes, por exemplo, o popular cert-manager 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 os dados sejam transmitidos.

O Aplicativo Web para Contêineres tem suporte interno do mTLS 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 Aplicativo encaminha.

Os Aplicativos de Contêiner também têm suporte interno para mTLS. Ele encaminha o certificado do cliente no cabeçalho HTTP X-Forwarded-Client-Certpara o aplicativo. Você também pode facilmente habilitar 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 do 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 consideradas. Para obter mais detalhes e saber mais sobre os recursos de rede específicos para 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 a segurança de rede e proteger o tráfego de rede.

Considerações de segurança

A falha ao resolver 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 guardrails adicionais. Sua escolha do serviço de contêiner do Azure precisa dar suporte a 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, integram-se com as principais ofertas de segurança, incluindo Key Vault 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.

Os clusters automáticos do AKS vêm com uma configuração padrão protegida, com muitas configurações de segurança de cluster, aplicativo e rede habilitadas por padrão. Essas configurações iniciais não apenas reduzem o tempo de implantação, mas também fornecem aos usuários uma configuração padronizada que é pré-validada e, portanto, fornece aos usuários uma base sólida para as responsabilidades operacionais do segundo dia. Essa base ajuda a reduzir a curva de aprendizado do gerenciamento de cluster de longo prazo para equipes que são novas na tecnologia.

Para obter uma comparação detalhada, examine cuidadosamente as seguintes considerações para garantir que os requisitos de segurança da carga de trabalho possam ser atendidos.

Segurança do painel 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êiner. 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 privados do AKS, 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 do Servidor de API à VNet (prévia) , em que o servidor de API é integrado a uma sub-rede delegada. Confira a documentação para saber mais.

Há consequências de implementar acesso restrito à API do Kubernetes na rede. Mais notavelmente, o gerenciamento só pode ser executado de dentro da rede privada. Normalmente, isso significa que você precisa implantar agentes auto-hospedados para o Azure DevOps ou o 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 Kubernetes Não configurável no PaaS Configurável: IP público ou IP privado

Essas considerações não se aplicam aos Aplicativos de Contêiner. Como é 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 intra 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 o AKS e implementar políticas de rede, uma tecnologia nativa de nuvem que permite a configuração granular da rede de Camada 4 nos clusters do 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 dá suporte a mais isolamento de carga de trabalho 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 à VNet: somente saída

Restrições de IP internas para entrada

Os Aplicativos de Contêiner e o Aplicativo Web para Contêineres fornecem restrições de IP de origem internas para o tráfego de entrada para aplicativos individuais. O AKS pode alcançar a mesma funcionalidade, mas requer a funcionalidade nativa do Kubernetes por meio do recurso de API do Serviço Kubernetes, no qual você pode definir valores para loadBalancerSourceRanges.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Restrições de IP internas para entrada ✅ ❌* ✅
Consumo de recursos - Consome recursos de cluster -

Nota

O AKS oferece restrições de IP de entrada, mas é um recurso nativo do Kubernetes e não o Azure Native como os outros serviços.

Segurança no nível do aplicativo

Você precisa proteger cargas de trabalho não apenas no nível de rede e infraestrutura, mas também no nível da carga de trabalho e do 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 Key Vault, que fornece segurança aprimorada para esses componentes. Em vez de armazenar e configurar segredos em código ou em um serviço de computação do Azure, todos os aplicativos devem se integrar ao Key Vault.

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 key vault 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 obter mais informações, consulte:

Suporte à identidade gerenciada

A Identidade Gerenciada pode ser usada por aplicativos para autenticar nos serviços protegidos da ID do Microsoft Entra sem precisar usar chaves ou segredos. Os Aplicativos de Contêiner e o Aplicativo Web para Contêiner oferecem suporte nativo interno do Azure para identidade gerenciada no nível do aplicativo. O suporte à identidade gerenciada no nível do aplicativo para AKS é realizado por meio de ID da Carga de Trabalho do Entra. O AKS também requer a identidade gerenciada relacionada à infraestrutura, para permitir operações de cluster para o Kubelet, o plano de controle e vários complementos do AKS.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Suporte a identidade gerenciada por infraestrutura N/A ✅ N/A
Suporte a identidade gerenciada de pull de contêiner ✅ ✅ ✅
suporte para identidade gerenciada de aplicativos ✅ ✅ ✅

Para obter mais informações, consulte:

Avaliações de vulnerabilidade e proteção contra ameaças 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. Há suporte para avaliações de vulnerabilidade nos registros de contêiner do Azure, portanto, elas podem ser usadas por qualquer serviço de contêiner do Azure, não apenas pelos descritos neste artigo. No entanto, a proteção de runtime do Defender para Contêineres está disponível apenas para o AKS.

À medida que 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 do ecossistema do Kubernetes.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Proteção contra runtime ❌ ✅ ❌

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 verificações 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 as 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 a segurança para serviços de contêiner, consulte as seguintes linhas de base de segurança específicas do serviço:

Nota

Os clusters automáticos do AKS são configurados com configurações de segurança específicas. Verifique se eles estão alinhados com suas necessidades de carga de trabalho.

Well-Architected Estrutura de Segurança

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

Para obter diretrizes de segurança mais completas sobre o AKS, consulte Well-Architected Revisão do 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 regulares e aplicação de patch 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 em relação à 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 clusters. Você pode disparar atualizações manualmente ou aproveitar os canais de autoatualização do cluster e o recurso 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.

Os Aplicativos de Contêiner e o 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ção do AKS.

Aplicativos de contêiner AKS AKS Automático Aplicativo Web para contêineres
Atualizações do plano de controle Plataforma Cliente Plataforma Plataforma
Atualizações e correções do host Plataforma Cliente Plataforma Plataforma
Atualizações e patches de imagens de contêiner Cliente Cliente Cliente Cliente

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, o processamento da CPU e a memória. Cargas de trabalho diferentes exigem diferentes quantidades 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 que estão disponíveis para um serviço específico do Azure. Eles 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 à habilidade 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 restantes do Azure, 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 implementar inicializações e desligamentos normales de seus aplicativos para evitar o 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 de hardware flexível 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 Dedicado dos Aplicativos de Contêiner (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 as SKUs disponíveis em cada serviço para garantir que suas necessidades sejam atendidas.

Escalabilidade do aplicativo

A medida típica na qual disparar 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 com base 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 Aplicativo Web para Contêineres não dá suporte a configurações personalizadas de dimensionador, como 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. Configuração adicional necessária. Sim. Específico do recurso do Azure.

O AKS Automatic habilita o Dimensionador Automático de Pod Horizontal, o KEDA (Dimensionamento Automático Controlado por Eventos do Kubernetes) e o VPA (Dimensionador Automático de Pod Vertical) por padrão.

Observabilidade

Instrumentação de carga de trabalho

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

  • Instrumentação automática. Nenhuma alteração de código é necessária.
  • 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/A
Instrumentação manual Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry

*O AKS e o Aplicativo Web para Contêineres dão suporte à instrumentação automática para determinadas configurações de cargas de trabalho do Linux e do Windows, dependendo do idioma do aplicativo. Para obter mais informações, consulte estes artigos:

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

Logs e métricas

Todos os serviços de contêiner do Azure fornecem funcionalidade de log e métrica de aplicativo e plataforma. Os logs de aplicativo são logs de console gerados pela carga de trabalho. Os logs de plataforma capturam eventos que ocorrem no nível da plataforma, fora do escopo do aplicativo, como dimensionamento e implantações. As métricas são valores numéricos que descrevem algum aspecto de um sistema em um momento, permitindo que você monitore e alerte sobre o desempenho e a integridade do sistema.

O Azure Monitor é o principal serviço de registro em log e métricas no Azure que se integra a esses serviços. O Azure Monitor usa logs de recursos para separar logs de diferentes fontes em categorias e coleta métricas para fornecer insights sobre o desempenho dos recursos. Uma maneira de determinar quais logs e métricas estão disponíveis em cada serviço do Azure é examinar as categorias de log de recursos e as métricas disponíveis para cada um dos serviços.

Aplicativos de contêiner AKS AKS Automático Aplicativo Web para contêineres
Suporte para streaming de log ✅ ✅ ✅ ✅
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 O mesmo que o AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs e muito mais
Coleta e monitoramento de métricas Métricas por meio do Azure Monitor; métricas personalizadas por meio de métricas do Dapr Métricas por meio do Azure Monitor; métricas personalizadas por meio do Prometheus (requer configuração manual) Prometheus Gerenciado pré-configurado para coleta de métricas e Grafana Gerenciado para visualização; métricas via Azure Monitor Métricas por meio do Azure Monitor
Prometheus e Grafana pré-configurados ❌ Requer configuração manual ✅ Prometheus e Grafana gerenciados são pré-configurados por padrão. ❌

Aplicativos de Contêiner abstrai todos os seus logs internos do Kubernetes em duas categorias: logs de console, que contêm logs de contêiner de carga de trabalho e logs do sistema, que contêm todos os logs relacionados à plataforma. Para métricas, os Aplicativos de Contêiner se integram ao Azure Monitor para coletar métricas padrão e dão suporte a métricas personalizadas por meio da integração do Dapr para cenários avançados.

O AKS fornece todos os logs relacionados ao Kubernetes e controle granular sobre o que é registrado. O AKS mantém a compatibilidade completa com as ferramentas de cliente do Kubernetes para streaming de log, como kubectl. Para métricas, o AKS integra-se ao Azure Monitor para coletar métricas de cluster e de nó. A coleção de métricas personalizadas usando o Prometheus e a visualização com o Grafana são possíveis, mas exigem configuração e configuração manuais.

Automático do AKS vem pré-configurado com ferramentas de monitoramento específicas. Ele usa o Prometheus Gerenciado para a coleção de métricas e o Grafana Gerenciado para visualização. As métricas de cluster e aplicativo são coletadas automaticamente e podem ser visualizadas. O AKS Automatic também se integra ao Azure Monitor para coleta de logs e métricas.

O Aplicativo Web para Contêineres fornece várias 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. As métricas são coletadas por meio do Azure Monitor, permitindo que você monitore o desempenho do aplicativo e a utilização de recursos.

Well-Architected Estrutura 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 examinar as diretrizes completas de Excelência Operacional para os seguintes serviços:

Fiabilidade

de Confiabilidade refere-se à capacidade de um sistema 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 da infraestrutura, o Azure é responsável por lidar com falhas físicas, como falhas de hardware e interrupções de energia, em datacenters. Falhas ainda podem acontecer. As equipes de carga de trabalho devem selecionar a camada de serviço apropriada do Azure 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 funcionam os SLAs (contratos de nível de serviço) e as zonas de disponibilidade.

Contratos de nível de serviço

A confiabilidade é normalmente medida por métricas orientadas por 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, em 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 os torna opções econômicas para ambientes de não produção. Para ambientes de produção, no entanto, é uma prática recomendada escolher uma camada paga que tenha um SLA.

Fatores adicionais para o AKS

O AKS tem SLAs diferentes 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 disponibilidade. 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

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

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

Característica Aplicativos de contêiner AKS Aplicativo Web para contêineres
Suporte à zona de disponibilidade Completo Completo Completo

Por exemplo, um aplicativo ou infraestrutura configurado para executar uma única instância ficará indisponível se ocorrer um problema na zona de disponibilidade em que 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, distribuídas 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 está controlando 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 responde.

Outra consideração importante é a frequência com que essas verificações de integridade são solicitadas do 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 dá 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 sondas de inicialização são embutidas e não podem ser alteradas. Ele envia uma solicitação HTTP para a porta inicial do contêiner. Qualquer resposta do aplicativo é considerada um início bem-sucedido.
  • Ele não suporta investigações de preparação. Se a sonda de inicialização for bem-sucedida, a instância de contêiner será adicionada ao conjunto de instâncias saudáveis.
  • Ela envia a verificação de integridade em intervalos de um minuto. Você não pode alterar o intervalo.
  • O limite mínimo que você pode definir para que uma instância não saudável seja removida do mecanismo de balanceamento de carga interno é 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:

Autocorreção

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á nenhuma opção para reiniciar uma instância de contêiner imediatamente após uma verificação de integridade falhar. 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 a verificações de integridade. Ele usa várias 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 aplicações sem interrupção

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 dão suporte a implantações de tempo de inatividade zero, mas de maneiras diferentes.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Estratégia de tempo de inatividade zero Atualização gradual atualização sem interrupção, além de todas as outras estratégias do Kubernetes Slots de implantação

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

Limites de recursos

Outro componente importante de um ambiente compartilhado confiável é o 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 inválido.

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 nos quais você pode executar vários aplicativos Web em contêineres. No entanto, você não pode restringir um dos aplicativos a uma determinada quantidade de CPU ou memória. Todos eles competem pelos mesmos recursos de plano do Serviço de Aplicativo. Se você quiser isolar os recursos do aplicativo, precisará criar planos adicionais do Serviço de Aplicativo.
  • Aplicativos de Contêiner: você pode definir limites de CPU e de memória por aplicativo em seu ambiente. No entanto, você está restrito a um conjunto de combinações permitidas de de CPU ede memória. Por exemplo, você não pode configurar uma vCPU e um GiB de memória, mas 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 seu cluster dessa forma.

Well-Architected Estrutura para Confiabilidade

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

Conclusão

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

Em geral, quando você compara os serviços de contêiner do Azure, um tema surge: o AKS apresenta a infraestrutura mais subjacente, oferecendo assim o maior controle e configurabilidade, enquanto o AKS Automatic oferece um equilíbrio entre controle e simplicidade automatizando muitas tarefas operacionais.

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 gerenciada do GitOps, muitas equipes optam por configurar e operar o ArgoCD por conta própria.

As equipes de carga de trabalho que, por exemplo, não exigem aplicativos CNCF, têm menos experiência de operações ou preferem se concentrar nos recursos do aplicativo 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 de nuvem adicionais para descoberta de serviço, dimensionamento automático controlado por eventos, integração 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 tenha em mente que você também precisa verificar sua escolha examinando os requisitos individuais em detalhes e combinando-os com conjuntos de recursos específicos do serviço.

Colaboradores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autores principais:

Outros colaboradores:

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

Próximas etapas