Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
As Instâncias de Contêiner do Azure fornecem uma maneira direta de executar contêineres do Linux ou do Windows no Azure, sem a necessidade de gerenciar máquinas virtuais (VMs) ou adotar um serviço mais complexo e de nível superior.
Este artigo descreve o suporte à confiabilidade em instâncias de contêiner, abrangendo resiliência intrarregional por meio de zonas de disponibilidade e implantações em várias regiões.
A fiabilidade é uma responsabilidade partilhada entre o Cliente e a Microsoft. Você pode usar este guia para determinar quais opções de confiabilidade atendem aos seus objetivos de negócios específicos e metas de tempo de atividade.
Recomendações de implantação de produção
Para aumentar a confiabilidade dos aplicativos de produção criados em instâncias de contêiner, recomendamos que você execute as seguintes ações:
Execute seus aplicativos em várias zonas de disponibilidade.
Considere se também deve executar grupos de contentores separados em várias regiões.
Use sondas de vivacidade para detetar e reiniciar automaticamente contentores não saudáveis.
Use sondas de prontidão para aguardar até que seus contêineres estejam prontos antes de receberem tráfego.
Use atualizações contínuas para aplicar progressivamente as alterações se você usar NGroups. Essa abordagem reduz a probabilidade de tempo de inatividade devido a atualizações.
Analise as práticas recomendadas e as considerações para instâncias de contêiner.
Visão geral da arquitetura de confiabilidade
Para usar instâncias de contêiner, implante um grupo de contêineres. Um grupo de contêineres contém um ou mais contêineres. Cada contêiner é criado a partir de uma imagem de contêiner, que é armazenada em um registro como o Registro de Contêiner do Azure.
Todos os contêineres em um grupo de contêineres são implantados juntos como uma única unidade lógica e compartilham a mesma infraestrutura física.
O diagrama a seguir mostra a relação entre grupos de contêineres, contêineres e imagens.
A imagem mostra dois contêineres dentro de uma seção de grupo de contêineres. Duas linhas pontilhadas conectam os contêineres a duas seções de imagem na seção do Registro.
As Instâncias de Contêiner fornecem os seguintes recursos para gerenciar grupos de contêineres:
NGroups (visualização) fornece um conjunto de recursos para gerenciar vários grupos de contêineres relacionados. Ao criar um NGroup, você define o número de grupos de contêineres a serem criados. As Instâncias de Contêiner fornecem recursos como implementações de atualização automatizadas e espalhamento de grupos de contêineres entre zonas de disponibilidade.
Os pools em espera criam um pool de grupos de contêineres pré-provisionados que podem ser usados em resposta ao tráfego de entrada. Os pools em espera são projetados para otimizar a criação de grupos de contêineres e não se destinam a aumentar sua resiliência.
Falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
SDKs fornecidos pela Microsoft geralmente lidam com falhas transitórias. Como você hospeda seus próprios aplicativos em instâncias de contêiner, tome medidas para reduzir a chance de falhas transitórias:
Execute vários grupos de contêineres para cargas de trabalho importantes para garantir que uma falha em um contêiner ou grupo de contêineres não afete todo o aplicativo.
Crie seu código de aplicativo para ser resiliente a falhas transitórias em serviços aos quais você se conecta, como usando políticas de repetição com estratégias de backoff.
Para obter mais informações sobre outros erros que podem ocorrer no tempo de execução e como respondê-los, consulte Problemas durante o tempo de execução do grupo de contêineres.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
As Instâncias de Contêiner oferecem suporte a zonas de disponibilidade de maneiras diferentes, dependendo de como você implanta seus grupos de contêineres:
Grupos de contêineres criados manualmente: Um grupo de contêineres individuais é um recurso zonal , o que significa que ele pode ser implantado em uma única zona de disponibilidade selecionada. Todos os contêineres dentro do grupo são implantados na mesma zona de disponibilidade. Se essa zona de disponibilidade tiver uma interrupção, o grupo de contêineres e todos os seus contêineres poderão enfrentar tempo de inatividade.
A imagem mostra três zonas de disponibilidade: Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. Um grupo de contêineres na Zona de Disponibilidade 1 inclui dois contêineres.
Observação
Para garantir que seu aplicativo continue a ser executado quando qualquer zona na região sofrer uma interrupção, recomendamos que você crie um mínimo de dois grupos de contêineres em duas zonas de disponibilidade diferentes.
Se você não especificar zonas de disponibilidade para usar em seu grupo de contêineres, ele será não zonal ou regional, o que significa que ele pode ser colocado em qualquer zona de disponibilidade dentro da região ou dentro da mesma zona. Se qualquer zona de disponibilidade na região tiver um problema, seu grupo de contêineres poderá enfrentar tempo de inatividade.
NGroups: Ao implantar um NGroup, você pode especificar uma ou mais zonas para implantá-lo. Se você implantar um NGroup em duas ou mais zonas, ele será um NGroup redundante de zona , e uma interrupção de uma zona de disponibilidade só causará problemas para os grupos de contêineres dentro da zona afetada.
A imagem mostra três zonas de disponibilidade. Cada zona de disponibilidade inclui um grupo de contêineres e dois contêineres. Um retângulo rotulado NGroupdesiredCount=3, zones=1,2,3 abrange todas as três zonas de disponibilidade.
Se não especificar zonas de disponibilidade para usar com o seu NGroup, ele não será associado a uma zona específica e poderá enfrentar interrupções de serviço se alguma zona de disponibilidade na região tiver um problema.
Pools de reserva: Ao implementar um pool de reserva, pode opcionalmente especificar uma ou mais zonas. A plataforma pode solicitar contêineres nas zonas selecionadas.
No entanto, os pools em espera não são redundantes de zona ou resilientes de zona porque não há garantia de que os contêineres sejam criados em várias zonas. Se ocorrer uma interrupção de zona, é possível que todos os contêineres no pool sejam colocados na zona afetada.
Como os pools em espera não foram projetados para oferecer suporte à resiliência a falhas de zona, este guia não descreve o comportamento detalhado dos pools em espera com zonas de disponibilidade.
Importante
Os pools de espera não foram projetados para serem resilientes à zona. Eles não devem ser usados para cargas de trabalho que exigem resiliência a falhas de zona.
Suporte de região
As implantações de grupos de contêineres zonais são suportadas em todas as regiões com zonas de disponibilidade.
Requerimentos
As implantações zonais estão disponíveis para grupos de contêineres Linux e Windows Server 2019.
Para selecionar uma zona de disponibilidade, você deve usar a SKU padrão. Os grupos de contentores zonais não estão disponíveis com a Confidential SKU.
Considerações
Os contêineres spot não oferecem suporte a zonas de disponibilidade e são sempre não zonais.
Custo
Não há custo extra para configurar zonas de disponibilidade para um grupo de contêineres.
Configurar o suporte à zona de disponibilidade
Crie grupos de contêineres com suporte à zona de disponibilidade. A abordagem que você usa para configurar zonas de disponibilidade depende de como você cria grupos de contêineres.
Grupos de contêineres criados manualmente: Para criar um grupo de contêineres zonais em uma zona específica, você pode usar um dos seguintes métodos:
NGroups: Você pode implantar um NGroup redundante de zona usando um modelo ARM e especificando várias zonas. Para obter mais informações, consulte Exemplo de NGroups com zonas.
Piscinas em espera: Você pode implantar um pool em espera que usa zonas de disponibilidade especificando uma ou mais zonas ao criar ou atualizar o pool. No entanto, os contêineres podem não ser criados em várias zonas. Os pools em espera não devem ser usados para cargas de trabalho que exigem resiliência a falhas de zona. Para mais informações, consulte Criar um pool de espera para instâncias de contêiner.
Habilite o suporte à zona de disponibilidade em recursos existentes. A abordagem que você usa para configurar zonas de disponibilidade depende de como você cria grupos de contêineres.
Grupos de contêineres criados manualmente: Não é possível habilitar zonas de disponibilidade em um grupo de contêineres não zonal existente. Você deve excluir o grupo de contêineres e criar um grupo de contêineres zonais.
NGroups: Não é possível habilitar zonas de disponibilidade em um NGroup não zonal existente. Você deve eliminar o NGroup e criar um NGroup com redundância de zona.
Piscinas em espera: Não é possível habilitar zonas de disponibilidade em um pool de espera não zonal existente. Você deve excluir o grupo de contêineres e criar um novo pool em espera que use várias zonas de disponibilidade.
Mova grupos de contêineres entre zonas ou desative o suporte à zona de disponibilidade. A abordagem usada para modificar zonas de disponibilidade depende de como você cria grupos de contêineres.
Grupos de contêineres criados manualmente: Para alterar a zona de disponibilidade de um grupo de contêineres, você deve excluir o grupo de contêineres e criar outro grupo de contêineres com a nova zona de disponibilidade. Para saber como excluir o grupo de contêineres, consulte os seguintes recursos:
NGroups: Você pode adicionar zonas a um NGroup, mas não pode remover zonas.
Piscinas em espera: Você pode adicionar zonas a um pool em espera, mas não pode remover zonas.
Distribuição de grupos de contêineres
A maneira como os grupos de contêineres são distribuídos entre as zonas de disponibilidade depende de como você implanta seus grupos de contêineres.
Grupos de contêineres criados manualmente: Você é responsável por distribuir seus grupos de contêineres criados manualmente em várias zonas de disponibilidade.
NGroups: Durante as operações de expansão, o NGroups exclui aleatoriamente instâncias, que podem não manter uma dispersão entre zonas de disponibilidade. As operações de expansão tentam reequilibrar a dispersão entre zonas.
Piscinas em espera: Um pool em espera pode criar contêineres em qualquer uma das zonas de disponibilidade que você configurar no pool. No entanto, os contêineres podem não ser criados em várias zonas. Os pools em espera não devem ser usados para cargas de trabalho que exigem resiliência a falhas de zona.
Planejamento e gerenciamento de capacidade
Para se preparar para falhas na zona de disponibilidade, considere o provisionamento excessivo do número de grupos de contêineres implantados. Esta abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem um desempenho degradado. Para obter mais informações, consulte Gerenciar a capacidade usando o provisionamento excessivo.
A abordagem que você usa para provisionar grupos de contêineres em excesso depende de como você implanta seus grupos de contêineres.
Grupos de contêineres criados manualmente: Você é responsável por planejar a capacidade de seus grupos de contêineres criados manualmente, incluindo o planejamento de quantos grupos de contêineres implantar em cada zona.
NGroup: Considere o provisionamento excessivo da capacidade do seu NGroup para tolerar a perda de uma zona.
Piscinas em espera: As piscinas em espera não são projetadas para serem resilientes contra falhas de zona. Considere o uso de vários pools de espera em zonas diferentes ou use NGroups.
Funcionamento normal
Esta seção descreve o que esperar quando os recursos de instâncias de contêiner são configurados para suporte à zona de disponibilidade e todas as zonas de disponibilidade estão operacionais.
Roteamento de tráfego entre zonas: Você é responsável por rotear o tráfego para seus contêineres. Por exemplo, você pode usar o Gateway de Aplicativo do Azure como um gateway e balanceador de carga para seus grupos de contêineres.
Se você usa NGroups ou pools em espera, é responsável pelo balanceamento de carga em cada contêiner. Você também precisa configurar seu sistema de roteamento de tráfego para detetar a integridade de cada grupo de contêineres e redirecionar o tráfego para um grupo alternativo quando necessário.
Replicação de dados entre zonas: Contêineres e grupos de contêineres são sem estado. Você pode anexar seu próprio compartilhamento de arquivos ou conectar-se a bancos de dados ou outros serviços de armazenamento de dentro de seus aplicativos. Você é responsável por garantir que esses compartilhamentos de arquivos e serviços de armazenamento sejam resilientes à zona. Analise os guias de confiabilidade de cada serviço para entender como tornar cada zona de componente resiliente.
Experiência de redução de zona
Esta seção descreve o que esperar quando os recursos de Instâncias de Contêiner são configurados para suporte à zona de disponibilidade e há uma interrupção da zona de disponibilidade.
Deteção e resposta: A responsabilidade pela deteção de falhas de zona e a resposta associada dependem de como você implanta seus grupos de contêineres.
Grupos de contêineres criados manualmente: Você precisa detetar a perda de uma zona de disponibilidade e iniciar um failover para um grupo de contêineres secundário criado em outra zona de disponibilidade.
NGroups: A plataforma de instâncias de contêiner é responsável por detetar uma falha em uma zona de disponibilidade e responder.
No entanto, você é responsável por garantir que o tráfego seja redirecionado para contêineres em uma zona saudável.
Piscinas em espera: Não é garantido que a plataforma de instâncias de contêiner responda a falhas de zona para pools em espera. Os pools em espera não devem ser usados para cargas de trabalho que exigem resiliência a falhas de zona.
Notificação: Container Instances não notifica quando uma zona está inativa. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço de Instâncias de Contêiner, incluindo quaisquer falhas de zona.
Configure alertas para receber notificações de problemas no nível da zona. Para obter mais informações, consulte Criar alertas de Integridade do Serviço no portal do Azure.
Solicitações ativas: Se uma zona falhar, é provável que todos os contêineres em execução nessa zona parem, incluindo qualquer trabalho ativo que estejam manipulando
Perda de dados esperada: Como os contentores e grupos de contentores são sem estado, não há perda de dados esperada de uma falha de zona. No entanto, você é responsável por garantir que cada componente em sua carga de trabalho seja resiliente à zona, incluindo serviços de armazenamento e bancos de dados.
Tempo de inatividade esperado: O tempo de inatividade que você pode esperar de uma falha de zona depende de como você implanta seus grupos de contêineres.
Grupos de contêineres criados manualmente: Para grupos de contêineres zonais, quando uma zona não está disponível, seu grupo de contêineres e seus contêineres ficam indisponíveis até que a zona de disponibilidade se recupere.
NGroups: Para NGroups, se uma zona ficar inativa, seu aplicativo permanecerá disponível porque os grupos de contêineres restantes dentro do NGroups continuarão a ser executados em outras zonas. Não se espera tempo de inatividade.
Piscinas de espera: As piscinas de espera não oferecem resiliência de zona. Se todos os grupos de contêineres no pool de espera estiverem em uma única zona, é possível que todos os grupos de contêineres e seus contêineres fiquem indisponíveis até que a zona de disponibilidade se recupere.
Reencaminhamento do tráfego: Como você é responsável por rotear o tráfego para seus contêineres, também é responsável pelo redirecionamento do tráfego se um grupo de contêineres falhar devido a uma interrupção da zona de disponibilidade.
Recuperação de zona
Depois que a zona se recupera, a plataforma do Azure reinicia automaticamente os grupos de contêineres que haviam sido interrompidos. Não é precisa qualquer ação da parte do cliente.
Testagem para falhas de zona
Não há como simular uma interrupção da zona de disponibilidade que contém seu grupo de contêineres. No entanto, você pode configurar manualmente gateways upstream ou balanceadores de carga para redirecionar o tráfego para um grupo de contêineres diferente em uma zona de disponibilidade diferente.
Suporte multi-região
Instâncias de contêiner é um serviço de região única. Se a região ficar indisponível, seus grupos de contêineres e seus contêineres também ficarão indisponíveis.
Abordagens multirregionais alternativas
Opcionalmente, você pode implantar grupos de contêineres separados em várias regiões. Você é responsável por implantar e configurar os grupos de contêineres em cada região. Você também precisa configurar o balanceamento de carga usando um serviço como o Azure Traffic Manager ou o Azure Front Door. Você é responsável por qualquer sincronização de dados, failover e failback.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.