Editar

Usar o Application Gateway Ingress Controller (AGIC) com um Serviço Kubernetes do Azure multilocatário

Azure Application Gateway
Azure Key Vault
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Bastion

Nesta solução, o Azure Web Application Firewall (WAF) fornece proteção centralizada para aplicativos Web implantados em um cluster multilocatário do Serviço Kubernetes do Azure (AKS) contra exploits e vulnerabilidades comuns. Os aplicativos Web executados no cluster do Serviço Kubernetes do Azure (AKS) e expostos por meio do Controlador de Ingresso do Gateway de Aplicativo (AGIC) podem ser protegidos contra ataques mal-intencionados, como injeção de SQL e scripts entre sites, usando uma Política WAF no Gateway de Aplicativo do Azure. A Política do WAF no Gateway de Aplicativo do Azure vem pré-configurada com conjuntos de regras principais do OWASP e pode ser alterada para outras versões CRS do OWASP com suporte.

Arquitetura

O diagrama exibe um diagrama desta solução Application Gateway Ingress Controller.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

O modelo ARM complementar implanta uma nova rede virtual com quatro sub-redes:

  • AksSubnet: Hospeda o cluster AKS
  • VmSubnet: Hospeda uma máquina virtual jump-box e pontos de extremidade privados
  • AppGatewaySubnet: Hospeda a camada WAF2 do Application Gateway.
  • AzureBastionSubnet: Hospeda o Azure Bastion

O cluster do Serviço Kubernetes do Azure (AKS) usa uma identidade gerenciada definida pelo usuário para criar recursos adicionais, como balanceadores de carga e discos gerenciados no Azure. O modelo ARM permite implantar um cluster AKS com os seguintes recursos:

O cluster AKS é composto pelo seguinte:

  • Pool de nós do sistema que hospeda apenas pods e serviços críticos do sistema. Os nós de trabalho têm coloração de nó que impede que pods de aplicação de seres agendados neste pool de nós.
  • Pool de nós de usuário que hospeda cargas de trabalho e artefatos de usuários.

Uma máquina virtual (VM) é implantada na mesma rede virtual que hospeda o cluster AKS. Quando você implanta o Serviço Kubernetes do Azure como um cluster privado, essa VM pode ser usada por administradores de sistema para gerenciar o cluster por meio da ferramenta de linha de comando Kubernetes. Os logs de diagnóstico de inicialização da máquina virtual são armazenados em uma conta de Armazenamento do Azure.

Um host do Azure Bastion fornece conectividade SSH segura e contínua para a VM de jumpbox, diretamente no portal do Azure por SSL. O Azure Container Registry (ACR) é usado para criar, armazenar e gerenciar imagens e artefatos de contêiner (como gráficos Helm).

A arquitetura inclui um Application Gateway que é usado pelo controlador de entrada. O Application Gateway é implantado em uma sub-rede dedicada e exposto à Internet pública por meio de um endereço IP público compartilhado por todas as cargas de trabalho do locatário. Uma Política de Firewall de Acesso à Web (WAF) está associada ao Application Gateway no nível raiz e no nível de ouvinte HTTP, para proteger as cargas de trabalho do locatário contra ataques mal-intencionados. A política é configurada no modo de Prevenção e usa o OWASP 3.1 para bloquear invasões e ataques detetados por regras. O invasor recebe uma exceção de "acesso não autorizado 403" e a conexão é fechada. O modo de prevenção registra esses ataques nos logs do WAF.

Um Cofre de Chaves é usado como um armazenamento secreto por cargas de trabalho executadas no Serviço Kubernetes do Azure (AKS) para recuperar chaves, certificados e segredos por meio de uma biblioteca de cliente, Driver CSI do Repositório de Segredos ou Dapr. O Azure Private Link permite que cargas de trabalho AKS acessem os Serviços PaaS do Azure, como o Cofre de Chaves, em um ponto de extremidade privado na rede virtual.

A topologia de exemplo inclui os seguintes pontos de extremidade privados:

  • Um ponto de extremidade privado para a conta de Armazenamento de Blob
  • Um ponto de extremidade privado para o Azure Container Registry (ACR)
  • Um ponto de extremidade privado para o Cofre da Chave
  • Se você optar por um cluster AKS privado, um ponto de extremidade privado para o servidor de API do cluster Kubernetes

A arquitetura também inclui as seguintes zonas DNS privadas para a resolução de nomes do nome de domínio totalmente qualificado (FQDN) de um serviço PaaS para o endereço IP privado do ponto de extremidade privado associado:

  • Uma Zona DNS Privada para a resolução de nomes do ponto de extremidade privado para a conta de Armazenamento de Blobs do Azure
  • Uma Zona DNS Privada para a resolução de nomes do ponto de extremidade privado para o Azure Container Registry (ACR)
  • Uma Zona DNS Privada para a resolução de nomes do ponto de extremidade privado para o Cofre da Chave do Azure
  • Se você implantar o cluster como privado, uma Zona DNS Privada para a resolução de nomes do ponto de extremidade privado para a API do Kubernetes Server

Existe um Link de Rede Virtual entre a rede virtual que hospeda o cluster AKS e as Zonas DNS Privadas acima. Um espaço de trabalho do Log Analytics é usado para coletar os logs e métricas de diagnóstico das seguintes fontes:

  • Cluster do Azure Kubernetes Service
  • Máquina virtual de caixa de salto
  • Gateway de Aplicação do Azure
  • Azure Key Vault
  • Grupos de segurança de rede do Azure

Componentes

  • O Registro de Contêiner do Azure é um serviço de registro do Docker gerenciado e privado baseado no Registro do Docker 2.0 de código aberto. Você pode usar os registros de contêiner do Azure com seus pipelines de desenvolvimento e implantação de contêiner existentes ou usar as Tarefas do Registro de Contêiner do Azure para criar imagens de contêiner no Azure. Crie sob demanda ou automatize totalmente as compilações com gatilhos, como confirmações de código-fonte e atualizações de imagem base.

  • Os Serviços Kubernetes do Azure simplificam a implantação de um cluster Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para o Azure. Como um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade. Como os mestres do Kubernetes são gerenciados pelo Azure, você gerencia e mantém apenas os nós do agente.

  • O Azure Key Vault armazena e controla com segurança o acesso a segredos como chaves de API, palavras-passe, certificados e chaves criptográficas. O Azure Key Vault também permite provisionar, gerenciar e implantar facilmente certificados públicos e privados Transport Layer Security/Secure Sockets Layer (TLS/SSL), para uso com o Azure e seus recursos internos conectados.

  • Gateway de Aplicativo do Azure O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web que permite gerenciar o tráfego de entrada para vários aplicativos Web downstream e APIs REST. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 - TCP e UDP) e roteiam o tráfego com base no endereço IP de origem e na porta para um endereço IP e uma porta de destino. Em vez disso, o Application Gateway é um balanceador de carga da camada de aplicativo (camada OSI 7). (OSI significa Open Systems Interconnection, TCP significa Transmission Control Protocol e UDP significa User Datagram Protocol.)

  • O Web Application Firewall ou WAF é um serviço que fornece proteção centralizada de aplicativos Web contra exploits e vulnerabilidades comuns. O WAF é baseado em regras dos conjuntos de regras principais do OWASP (Open Web Application Security Project). O WAF do Azure permite que você crie regras personalizadas que são avaliadas para cada solicitação que passa por uma política. Essas regras têm uma prioridade maior do que o resto das regras nos conjuntos de regras gerenciados. As regras personalizadas contêm um nome de regra, prioridade de regra e uma matriz de condições correspondentes. Se estas condições forem cumpridas, é tomada uma ação (para permitir ou bloquear).

  • O Azure Bastion é uma plataforma como serviço (PaaS) totalmente gerenciada que você provisiona dentro de sua rede virtual. O Azure Bastion fornece conectividade segura e contínua de protocolo de área de trabalho remota (RDP) e shell seguro (SSH) para as VMs em sua rede virtual, diretamente do portal do Azure por TLS.

  • As Máquinas Virtuais do Azure fornecem recursos de computação escalonáveis e sob demanda que oferecem a flexibilidade da virtualização, sem a necessidade de comprar e manter o hardware físico.

  • A Rede Virtual do Azure é o bloco de construção fundamental para as redes privadas do Azure. Com a Rede Virtual, os recursos do Azure (como VMs) podem se comunicar com segurança entre si, com a Internet e com redes locais. Uma Rede Virtual do Azure é semelhante a uma rede tradicional local, mas inclui benefícios de infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento.

  • As Interfaces de Rede Virtual permitem que as máquinas virtuais do Azure se comuniquem com a Internet, o Azure e os recursos locais. Você pode adicionar várias placas de interface de rede a uma VM do Azure, para que as VMs filhas possam ter seus próprios dispositivos de interface de rede dedicados e endereços IP.

  • O Azure Managed Disks fornece volumes de armazenamento em nível de bloco que o Azure gerencia em VMs do Azure. Os tipos de discos disponíveis são discos Ultra, unidades de estado sólido (SSDs) Premium, SSDs padrão e unidades de disco rígido padrão (HDDs).

  • O Armazenamento de Blobs do Azure é a solução de armazenamento de objetos da Microsoft para a nuvem. O armazenamento de blobs está otimizado para armazenar quantidades em grande escala de dados não estruturados. Os dados não estruturados são dados que não seguem uma definição ou um modelo de dados particular, como texto ou dados binários.

  • O Azure Private Link permite que você acesse os serviços PaaS do Azure (por exemplo, o Armazenamento de Blobs do Azure e o Cofre da Chave) e os serviços hospedados pelo Azure de propriedade do cliente/parceiro, por meio de um ponto de extremidade privado em sua rede virtual.

Alternativas

Nessa arquitetura, o Application Gateway Ingress Controller (AGIC) foi instalado usando o complemento AGIC para o Serviço Kubernetes do Azure (AKS). Você também pode instalar o Application Gateway Ingress Controller por meio de um gráfico Helm. Para uma nova configuração, usando uma linha na CLI do Azure, você pode implantar um novo Gateway de Aplicativo e um novo cluster AKS (com o AGIC habilitado como um complemento). O complemento também é um serviço totalmente gerenciado, que oferece benefícios adicionais, como atualizações automáticas e maior suporte. Ambas as formas de implantação do AGIC (Helm e o complemento AKS) são totalmente suportadas pela Microsoft. Além disso, o complemento permite uma melhor integração com o AKS, como um complemento de primeira classe.

O complemento Application Gateway Ingress Controller (AGIC) ainda é implantado como um pod em seu cluster AKS. No entanto, existem algumas diferenças entre a versão de implantação do Helm e a versão complementar do AGIC. A lista a seguir inclui as diferenças entre as duas versões:

  • Os valores de implantação do leme não podem ser modificados no complemento AKS:

    • usePrivateIp será definido como sendo false por padrão, isso pode ser substituído pela use-private-ip anotação
    • shared não é suportado pelo complemento

  • A AGIC implantada via Helm suporta ProhibitedTargets, o que significa que a AGIC pode configurar o Application Gateway especificamente para clusters AKS, sem afetar outros back-ends existentes.

  • Como o complemento AGIC é um serviço gerenciado, ele é atualizado automaticamente para a versão mais recente do complemento AGIC, ao contrário do AGIC implantado através do Helm (onde você deve atualizar manualmente o AGIC).

  • Você só pode implantar um complemento AGIC por cluster AKS, e cada complemento AGIC atualmente só pode direcionar uma instância do Application Gateway. Para implantações que exigem mais de um AGIC por cluster ou vários AGICs destinados a um Application Gateway, você pode continuar a usar o AGIC implantado via Helm.

Uma única instância do Azure Application Gateway Kubernetes Ingress Controller (AGIC) pode ingerir eventos de vários namespaces Kubernetes. Se o administrador do AKS decidir usar o Application Gateway como entrada, todos os namespaces usarão a mesma instância do Application Gateway. Uma única instalação do Ingress Controller monitorará namespaces acessíveis e configurará o Application Gateway ao qual ele está associado. Para obter mais informações, consulte Habilitar o suporte a vários namespaces em um cluster AKS com o Application Gateway Ingress Controller.

Para habilitar o suporte a vários namespaces, faça o seguinte:

  • Modifique o arquivo helm-config.yaml de uma das seguintes maneiras:

    • Exclua a watchNamespace chave inteiramente do arquivo helm-config.yaml . A AGIC observará todos os namespaces.
    • Defina watchNamespace como uma cadeia de caracteres vazia. A AGIC observará todos os namespaces.
    • Adicione vários namespaces, separados por uma vírgula (watchNamespace: default,secondNamespace). A AGIC observará exclusivamente esses namespaces.

  • Aplique as alterações do modelo Helm com este script: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

Uma vez implantado com a capacidade de observar vários namespaces, o AGIC fará o seguinte:

  • Listar recursos de entrada de todos os namespaces acessíveis
  • Filtrar para ingressar recursos anotados com kubernetes.io/ingress.class: azure/application-gateway
  • Compor a configuração combinada do Application Gateway
  • Aplique a configuração ao Application Gateway associado via ARM

Detalhes do cenário

Um cluster Kubernetes multilocatário é compartilhado por vários usuários e cargas de trabalho que são comumente chamados de "locatários". Essa definição inclui clusters do Kubernetes que são compartilhados por diferentes equipes ou divisões dentro de uma organização. Ele também inclui clusters que são compartilhados por instâncias por cliente de um aplicativo SaaS (software como serviço). A multilocação de cluster é uma alternativa ao gerenciamento de muitos clusters dedicados de locatário único. Os operadores de um cluster Kubernetes multilocatário devem isolar os locatários uns dos outros. Esse isolamento minimiza os danos que um locatário comprometido ou mal-intencionado pode causar ao cluster e a outros locatários. Quando vários usuários ou equipes compartilham o mesmo cluster com um número fixo de nós, há uma preocupação de que uma equipe possa usar mais do que sua justa parcela de recursos. As Cotas de Recursos são uma ferramenta para os administradores resolverem essa preocupação.

Ao planejar criar um cluster multilocatário do Serviço Kubernetes do Azure (AKS), você deve considerar as camadas de isolamento de recursos fornecidas pelo Kubernetes: cluster, namespace, nó, pod e contêiner. Você também deve considerar as implicações de segurança do compartilhamento de diferentes tipos de recursos entre vários locatários. Por exemplo, agendar pods de locatários diferentes no mesmo nó pode reduzir o número de máquinas necessárias no cluster. Por outro lado, talvez seja necessário impedir que determinadas cargas de trabalho sejam colocalizadas. Por exemplo, você pode não permitir que códigos não confiáveis de fora da sua organização sejam executados no mesmo nó que os contêineres que processam informações confidenciais. A Política do Azure pode ser usada para limitar a implantação ao AKS apenas de registros confiáveis.

Embora o Kubernetes não possa garantir um isolamento perfeitamente seguro entre locatários, ele oferece recursos que podem ser suficientes para casos de uso específicos. Como prática recomendada, você deve separar cada locatário e seus recursos do Kubernetes em seus próprios namespaces. Em seguida, você pode usar o RBAC do Kubernetes e as Diretivas de Rede para impor o isolamento do locatário. (RBAC significa controle de acesso baseado em função.) Por exemplo, a imagem a seguir mostra o modelo de provedor SaaS típico que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo vive em um namespace separado. Quando os locatários precisam de um nível mais alto de isolamento físico e desempenho garantido, suas cargas de trabalho podem ser implantadas em um conjunto dedicado de nós, pool dedicado ou até mesmo em um cluster dedicado.

Diagrama de multilocação

Transfira um ficheiro do Visio desta arquitetura.

O Application Gateway Ingress Controller (AGIC) é um aplicativo Kubernetes, que possibilita que os clientes do Serviço Kubernetes do Azure (AKS) usem um Gateway de Aplicativo do Azure para expor seus aplicativos em contêineres à Internet. O AGIC monitora o cluster do Kubernetes no qual ele está hospedado e atualiza continuamente um Application Gateway, para que os serviços selecionados sejam expostos à Internet. O Ingress Controller é executado em seu próprio pod na instância AKS do cliente. A AGIC monitora um subconjunto de Recursos do Kubernetes em busca de alterações. O estado do cluster AKS é traduzido para a configuração específica do Application Gateway e aplicado ao Azure Resource Manager (ARM). Este exemplo de arquitetura mostra práticas comprovadas para implantar um cluster público ou privado do Serviço Kubernetes (AKS), com um Gateway de Aplicativo do Azure e um complemento do Controlador de Ingresso do Gateway de Aplicativo.

Uma única instância do Azure Application Gateway Kubernetes Ingress Controller (AGIC) pode ingerir eventos e observar vários namespaces. Se o administrador do AKS decidir usar o Application Gateway como uma entrada, todos os namespaces usarão a mesma instância do Application Gateway. Uma única instalação do Ingress Controller monitorará namespaces acessíveis e configurará o Application Gateway ao qual ele está associado.

Potenciais casos de utilização

Use o Application Gateway Ingress Controller (AGIC) para expor e proteger cargas de trabalho voltadas para a Internet que estão sendo executadas em um cluster do Serviço Kubernetes do Azure (AKS) em um ambiente multilocatário.

Considerações

Embora algumas das considerações a seguir não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar essa solução. Isso inclui nossas considerações de segurança, desempenho, disponibilidade e confiabilidade, armazenamento, agendador, malha de serviço e monitoramento.

Considerações sobre multilocação

  • Projete clusters AKS para multilocação. O Kubernetes fornece funcionalidades que lhe permitem isolar logicamente equipas e cargas de trabalho no mesmo cluster. O objetivo deve ser fornecer o menor número de privilégios, com escopo para os recursos que cada equipe precisa. Um Namespace no Kubernetes cria um limite de isolamento lógico.
  • Use o isolamento lógico para separar equipes e projetos. Tente minimizar o número de clusters físicos do AKS que você implanta para isolar equipes ou aplicativos. A separação lógica de clusters geralmente fornece uma densidade de pod maior do que clusters fisicamente isolados.
  • Use pools de nós dedicados ou clusters AKS dedicados sempre que precisar implementar um isolamento físico rigoroso. Por exemplo, você pode dedicar um pool de nós de trabalho ou um cluster inteiro a uma equipe ou locatário em um ambiente multilocatário.
    • Você pode usar uma combinação de manchas e tolerâncias para controlar a implantação de pods em um pool de nós específico. Por favor, note que um nó no AKS pode ser contaminado apenas no momento da criação do pool de nós. Como alternativa, rótulos e seletores de nodePool podem ser usados para controlar a implantação da carga de trabalho em pools de nós específicos.

Considerações de segurança

Embora as considerações de segurança não estejam totalmente relacionadas à multilocação no AKS, acreditamos que elas são requisitos essenciais ao implantar esta solução.

Segurança da rede

  • Crie um ponto de extremidade privado para qualquer serviço PaaS usado por cargas de trabalho do AKS, como Key Vault, Service Bus ou Banco de Dados SQL do Azure. Isso é para que o tráfego entre os aplicativos e esses serviços não seja exposto à internet pública. Para obter mais informações, consulte O que é o Azure Private Link.
  • Configure seu recurso Kubernetes Ingress para expor cargas de trabalho via HTTPS e use um subdomínio e certificado digital separados para cada locatário. O Application Gateway Ingress Controller (AGIC) configurará automaticamente o ouvinte do Gateway de Aplicativo do Azure para terminação SSL (Secure Socket Layer).
  • Configure o Gateway de Aplicativo do Azure para usar uma Política de Firewall de Aplicativo Web para proteger cargas de trabalho voltadas para o público (que estão sendo executadas no AKS) contra ataques mal-intencionados.
  • Para integração com redes virtuais existentes ou redes locais, use a rede CNI do Azure no AKS. Este modelo de rede também permite uma maior separação de recursos e controles em um ambiente corporativo.
  • Use políticas de rede para segregar e proteger as comunicações dentro do serviço, controlando quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster Kubernetes podem enviar e receber tráfego sem limitações. Para melhorar a segurança, você pode usar as Políticas de Rede do Azure ou as Políticas de Rede do Calico para definir regras que controlam o fluxo de tráfego entre diferentes microsserviços. Para obter mais informações, consulte Diretiva de rede.
  • Não exponha a conectividade remota aos seus nós AKS. Crie um host bastião, ou caixa de salto, em uma rede virtual de gerenciamento. Use o host bastion para rotear com segurança o tráfego para seu cluster AKS para tarefas de gerenciamento remoto.
  • Considere usar um cluster AKS privado em seu ambiente de produção ou, pelo menos, proteger o acesso ao servidor de API, usando intervalos de endereços IP autorizados no Serviço Kubernetes do Azure.
  • A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques DDoS. Você deve habilitar a Proteção DDOS do Azure em qualquer rede virtual de perímetro.

Autenticação e autorização

  • Implante clusters AKS com a integração do Microsoft Entra. Para obter mais informações, consulte Integração do Microsoft Entra gerenciada pelo AKS. O uso do Microsoft Entra ID centraliza o componente de gerenciamento de identidades. Qualquer alteração na conta de usuário ou status do grupo é automaticamente atualizada no acesso ao cluster AKS. Use Roles ou ClusterRoles and Bindings para definir o escopo de usuários ou grupos para o menor número de permissões necessárias.
  • Use o RBAC do Kubernetes para definir as permissões que os usuários ou grupos têm para recursos no cluster. Crie funções e associações que atribuam o menor número de permissões necessárias. Integre o RBAC do Kubernetes com o ID do Microsoft Entra para que qualquer alteração no status do usuário ou na associação ao grupo seja atualizada automaticamente e o acesso aos recursos do cluster seja atual.
  • Use o RBAC do Azure para definir as permissões mínimas necessárias que os usuários ou grupos têm para recursos AKS em uma ou mais assinaturas. Para obter mais informações, consulte RBAC do Kubernetes e Usar o RBAC do Azure para autorização do Kubernetes.
  • Considere usar a ID de Carga de Trabalho do Microsoft Entra para atribuir uma identidade gerenciada para um recurso do Azure a microsserviços individuais, que eles podem usar para acessar recursos gerenciados (como o Cofre da Chave do Azure, o Banco de Dados SQL, o Service Bus e o Cosmos DB). Tudo sem a necessidade de armazenar e recuperar cadeias de conexão de uso ou credenciais de segredos do Kubernetes.
  • Considere usar o Driver CSI do Repositório Secreto para o Cofre de Chaves do Azure para acessar segredos, como credenciais e cadeias de caracteres de conexões do Cofre da Chave, em vez de segredos do Kubernetes.
  • Considere usar o bloco de construção Dapr Secrets Stores , com o repositório do Azure Key Vault com Identidades Gerenciadas no Kubernetes, para recuperar segredos (como credenciais e cadeias de conexão) do Cofre de Chaves.

Carga de trabalho e cluster

  • Proteger o acesso ao Kubernetes API-Server é uma das coisas mais importantes que você pode fazer para proteger seu cluster. Integre o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC) com o ID do Microsoft Entra para controlar o acesso ao servidor de API. Estes controlos permitem-lhe proteger o AKS da mesma forma que protege o acesso às suas subscrições do Azure.
  • Limite o acesso a ações que os contêineres podem executar. Use a Admissão de Segurança do Pod para habilitar a autorização refinada de criação e atualizações do pod. Forneça o menor número de permissões e evite o uso de escalonamento root/privilegiado. Para obter mais práticas recomendadas, consulte Proteger o acesso do pod aos recursos.
  • Sempre que possível, evite executar contêineres como um usuário raiz.
  • Use o módulo de segurança do kernel do AppArmor Linux para limitar as ações que os contêineres podem fazer.
  • Atualize regularmente seus clusters AKS para a versão mais recente do Kubernetes para aproveitar os novos recursos e correções de bugs.
  • O AKS baixa e instala automaticamente correções de segurança em cada nó Linux, mas não reinicia automaticamente o nó, se necessário. Use kured para observar reinicializações pendentes, nós de cordão e drenagem e, finalmente, aplique suas atualizações. Para nós do Windows Server, execute regularmente uma operação de atualização do AKS para conectar e drenar pods com segurança e implantar quaisquer nós atualizados.
  • Considere usar protocolos de transporte seguro HTTPS e gRPC para todas as comunicações intrapod e usar um mecanismo de autenticação mais avançado que não exija que você envie as credenciais simples em todas as solicitações, como OAuth ou JWT. A comunicação segura dentro do serviço pode ser alcançada aproveitando uma malha de serviço, como Istio, Linkerd ou Consul ou usando o Dapr.

Registo de Contentores do Azure

  • Analise suas imagens de contêiner em busca de vulnerabilidades e implante apenas imagens que passaram pela validação. Atualize regularmente as imagens base e o tempo de execução do aplicativo e, em seguida, reimplante cargas de trabalho no cluster AKS. Seu fluxo de trabalho de implantação de CI/CD deve incluir um processo para digitalizar imagens de contêiner. A segurança do Microsoft Defender for Cloud DevOps pode ser usada para verificar o código em busca de vulnerabilidades durante o tempo de compilação/implantação em seus pipelines automatizados. Como alternativa, ferramentas como Prisma Cloud ou Aqua podem ser usadas para digitalizar e permitir que apenas imagens verificadas sejam implantadas.
  • Ao usar imagens de base para imagens de aplicativos, use a automação para criar novas imagens quando a imagem base for atualizada. Como essas imagens básicas geralmente incluem correções de segurança, atualize todas as imagens de contêiner de aplicativos downstream. Para obter mais informações sobre atualizações de imagem base, consulte Automatizar compilações de imagem na atualização de imagem base com Tarefas do Registro de Contêiner do Azure.

Considerações de desempenho

Embora as considerações de desempenho não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar esta solução:

  • Para cargas de trabalho de baixa latência, considere implantar um pool de nós dedicados em um grupo de posicionamento de proximidade. Ao implantar seu aplicativo no Azure, espalhar instâncias de Máquina Virtual (VM) entre regiões ou zonas de disponibilidade cria latência de rede, o que pode afetar o desempenho geral do seu aplicativo. Um grupo de posicionamento de proximidade é um agrupamento lógico usado para garantir que os recursos de computação do Azure estejam fisicamente localizados próximos uns dos outros. Alguns casos de uso (como jogos, simulações de engenharia e negociação de alta frequência (HFT)) exigem baixa latência e tarefas que são concluídas rapidamente. Para cenários de computação de alto desempenho (HPC) como estes, considere o uso de grupos de posicionamento de proximidade (PPG) para os pools de nós do cluster.
  • Use sempre imagens de contêiner menores, pois isso ajuda você a criar compilações mais rápidas. Imagens menores também são menos vulneráveis a vetores de ataque, devido a uma superfície de ataque reduzida.
  • Use o dimensionamento automático do Kubernetes para dimensionar dinamicamente o número de nós de trabalho de um cluster AKS quando o tráfego aumentar. Com o Horizontal Pod Autoscaler e um cluster autoscaler , os volumes de nós e pods são ajustados dinamicamente em tempo real, para corresponder à condição de tráfego e evitar tempos de inatividade causados por problemas de capacidade. Para obter mais informações, consulte Usar o dimensionador automático de cluster no Serviço Kubernetes do Azure (AKS).

Considerações sobre disponibilidade e confiabilidade

Embora as considerações de disponibilidade e confiabilidade não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar essa solução. Considere as seguintes maneiras de otimizar a disponibilidade para seu cluster e cargas de trabalho AKS.

Contentores

  • Use as sondas de integridade do Kubernetes para verificar se seus contêineres estão vivos e saudáveis:

    • O livenessProbe indica se o contêiner está em execução. Se a sonda de vivacidade falhar, o kubelet mata o contêiner e o contêiner é submetido à sua política de reinicialização.
    • O proincisProbe indica se o contêiner está pronto para responder às solicitações. Se a sonda de prontidão falhar, o controlador de pontos de extremidade removerá o endereço IP do pod dos pontos de extremidade de todos os serviços que correspondem ao pod. O estado padrão de prontidão antes do atraso inicial é Falha.
    • O teste de inicialização indica se o aplicativo dentro do contêiner foi iniciado. Todos os outros testes são desativados se um teste de inicialização for fornecido, até que ele seja bem-sucedido. Se o teste de inicialização falhar, o kubelet matará o contêiner e o contêiner será submetido à sua política de reinicialização.

  • A contenção de recursos pode afetar a disponibilidade do serviço. Defina restrições de recursos de contêiner para que nenhum contêiner possa sobrecarregar a memória do cluster e os recursos da CPU. Você pode usar o diagnóstico do AKS para identificar quaisquer problemas no cluster.

  • Use o limite de recursos para restringir o total de recursos permitidos para um contêiner, para que um contêiner específico não possa matar a fome de outros.

Registo de contentor

  • Sugerimos armazenar imagens de contêiner no Registro de Contêiner do Azure e, em seguida, replicar geograficamente o Registro para cada região AKS usando a replicação geográfica do Registro de Contêiner do Azure. A replicação geográfica é um recurso dos registros ACR de SKU Premium.
  • Analise suas imagens de contêiner em busca de vulnerabilidades e implante apenas imagens que passaram pela validação. Atualize regularmente as imagens base e o tempo de execução do aplicativo e, em seguida, reimplante suas cargas de trabalho no cluster AKS.
  • Limite os registros de imagem que pods e implantações podem usar. Permita apenas registos fidedignos, onde valida e controla as imagens que estão disponíveis.
  • Ao usar imagens base para imagens de aplicativos, use a automação para criar novas imagens, quando a imagem base for atualizada. Como essas imagens básicas geralmente incluem correções de segurança, atualize todas as imagens de contêiner de aplicativos downstream. Recomendamos que você verifique as imagens de contêiner em busca de vulnerabilidades como parte do pipeline de CI/CD antes de publicar as imagens no registro de contêiner. O Azure Defender for Containers pode ser integrado a fluxos de trabalho de CI/CD.
  • Aproveite as Tarefas ACR no Registro de Contêiner do Azure para automatizar o sistema operacional e a aplicação de patches de estrutura para seus contêineres do Docker. As Tarefas ACR suportam a execução automatizada de compilação, quando a imagem base de um contêiner é atualizada, como quando você corrige o sistema operacional ou a estrutura do aplicativo em uma de suas imagens base.

Resiliência intrarregião

  • Considere implantar os pools de nós do seu cluster AKS, em todas as Zonas de Disponibilidade dentro de uma região, e use um Balanceador de Carga Padrão do Azure ou o Gateway de Aplicativo do Azure na frente dos pools de nós. Essa topologia fornece melhor resiliência, no caso de uma interrupção de um único datacenter. Dessa forma, os nós de cluster são distribuídos em vários datacenters, em três zonas de disponibilidade separadas dentro de uma região.
  • Habilite a redundância de zona no Registro de Contêiner do Azure, para resiliência intrarregião e alta disponibilidade.
  • Use as Restrições de Propagação de Topologia de Pod para controlar como os pods são distribuídos pelo cluster AKS entre domínios de falha, como regiões, zonas de disponibilidade e nós.
  • Considere o uso do SLA de tempo de atividade para clusters AKS que hospedam cargas de trabalho de missão crítica. O SLA de tempo de atividade é um recurso opcional para habilitar um SLA mais alto e com suporte financeiro para um cluster. O SLA de tempo de atividade garante 99,95% de disponibilidade do ponto de extremidade do servidor da API do Kubernetes, para clusters que usam zonas de disponibilidade. E garante 99,9% de disponibilidade para clusters que não usam zonas de disponibilidade. O AKS usa réplicas de nó mestre em domínios de atualização e falha, para garantir que os requisitos de SLA sejam atendidos.

Recuperação após desastre e continuidade de negócio

  • Considere implantar sua solução em pelo menos duas regiões emparelhadas do Azure dentro de uma geografia. Você também deve adotar um balanceador de carga global, como o Azure Traffic Manager ou o Azure Front Door, com um método de roteamento ativo/ativo ou ativo/passivo, para garantir a continuidade dos negócios e a recuperação de desastres.
  • Certifique-se de criar scripts, documentar e testar periodicamente qualquer processo de failover regional em um ambiente de controle de qualidade, para evitar problemas imprevisíveis se um serviço principal for afetado por uma interrupção na região primária.
  • Esses testes também se destinam a validar se a abordagem DR atende às metas de RPO/RTO, em conjunto com eventuais processos manuais e intervenções necessárias para um failover.
  • Certifique-se de testar os procedimentos de failback, para entender se eles funcionam conforme o esperado.
  • Armazene suas imagens de contêiner no Registro de Contêiner do Azure e replique geograficamente o registro para cada região AKS. Para obter mais informações, consulte Replicação geográfica no Registro de Contêiner do Azure.
  • Sempre que possível, não armazene o estado de serviço dentro do contêiner. Em vez disso, use uma plataforma do Azure como um serviço (PaaS) que ofereça suporte à replicação em várias regiões.
  • Se você usar o Armazenamento do Azure, prepare e teste como migrar seu armazenamento da região principal para a região de backup.
  • Considere implantar a configuração do cluster usando o GitOps. O uso do GitOps fornece uniformidade entre clusters primários e DR e uma maneira rápida de reconstruir novos clusters em caso de perda de cluster.
  • Considere o backup/restauração da configuração do cluster usando ferramentas como o Backup do Serviço Kubernetes do Azure ou o Velero.

Considerações sobre armazenamento

Embora as considerações de armazenamento não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar esta solução:

  • Considere implantar seu cluster AKS com discos efêmeros do sistema operacional que fornecem menor latência de leitura/gravação, juntamente com escalonamento de nó mais rápido e atualizações de cluster.
  • Entenda as necessidades do seu aplicativo para escolher o armazenamento certo. Use armazenamento de alto desempenho apoiado por SSD para cargas de trabalho de produção. Planeje um sistema de armazenamento baseado em rede, como o Azure Files, quando vários pods precisarem acessar simultaneamente os mesmos arquivos. Para obter mais informações, consulte Opções de armazenamento para aplicativos no Serviço Kubernetes do Azure (AKS).
  • Cada tamanho de nó suporta um número máximo de discos. Diferentes tamanhos de nós também fornecem diferentes quantidades de armazenamento local e largura de banda de rede. Planeje suas demandas de aplicativos para implantar o tamanho apropriado dos nós.
  • Para reduzir a sobrecarga de gerenciamento e permitir que você dimensione, não crie e atribua volumes persistentes estaticamente. Use o provisionamento dinâmico. Em suas classes de armazenamento, defina a política de recuperação apropriada para minimizar os custos de armazenamento desnecessários, depois que os pods forem excluídos.

Considerações sobre o agendador

Embora algumas das considerações do agendador não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar esta solução:

  • Certifique-se de revisar e implementar as práticas recomendadas para que os operadores de cluster e desenvolvedores de aplicativos criem e executem aplicativos com êxito no Serviço Kubernetes do Azure (AKS).
  • Planeje e aplique cotas de recursos no nível do namespace, para todos os namespaces. Se os pods não definirem solicitações e limites de recursos, rejeite a implantação. Monitore o uso de recursos e, em seguida, ajuste as cotas conforme necessário. Quando várias equipes ou locatários compartilham um cluster AKS com um número fixo de nós, as cotas de recursos podem ser usadas para atribuir uma parte justa dos recursos a cada equipe ou locatário.
  • Adote intervalos de limite para restringir alocações de recursos (para pods ou contêineres) em um namespace, em termos de CPU e memória.
  • Defina explicitamente solicitações de recursos e limites para uso de CPU e memória, para seus pods nos manifestos YAML ou gráficos Helm que você usa para implantar aplicativos. Quando você especifica a solicitação de recurso para contêineres em um pod, o agendador do Kubernetes usa essas informações para decidir em qual nó colocar o pod. Quando você especifica um limite de recursos (como a CPU ou a memória) para um contêiner, o kubelet impõe esses limites para que o contêiner em execução não possa usar mais desse recurso do que o limite definido.
  • Para manter a disponibilidade de aplicativos, defina Pod Disruption Budgets, para garantir que um número mínimo de pods esteja disponível no cluster.
  • As classes prioritárias podem ser usadas para indicar a importância de um pod. Se um pod não puder ser agendado, o agendador tenta antecipar (despejar) pods de prioridade mais baixa, a fim de tornar possível o agendamento do pod pendente.
  • Use as manchas e tolerâncias do Kubernetes para colocar aplicativos que consomem muitos recursos em nós específicos e para evitar problemas de vizinhos barulhentos. Mantenha os recursos do nó disponíveis para cargas de trabalho que os exijam e não permita que outras cargas de trabalho sejam agendadas nos nós.
  • Controle o agendamento de pods em nós, usando seletores de nós, afinidade de nó ou afinidade entre pods. Use as configurações de afinidade e antiafinidade entre pods para colocalizar pods que tenham comunicações tagarelas, para colocar pods em nós diferentes e para evitar a execução de várias instâncias do mesmo tipo de pod no mesmo nó.

Considerações sobre malha de serviço

Embora as considerações de malha de serviço não sejam totalmente referentes à multilocação no AKS, acreditamos que elas são requisitos essenciais ao implantar esta solução:

  • Considere o uso de uma malha de serviço de código aberto (como Istio, Linkerd ou Consul) em seu cluster AKS, a fim de melhorar a observabilidade, confiabilidade e segurança para seus microsserviços, via TLS mútuo. Você também pode implementar estratégias de divisão de tráfego (como implantações azuis/verdes e implantações canárias). Em resumo, uma malha de serviço é uma camada de infraestrutura dedicada para tornar a comunicação serviço-a-serviço segura, rápida e confiável. Para ver o complemento Istio integrado ao AKS, consulte: Istio service mesh AKS add-on

  • Considere a adoção do Dapr para criar aplicativos resilientes, sem monitoração de estado e com monitoração de estado. Você pode usar qualquer linguagem de programação e estrutura de desenvolvedor.

Considerações de DevOps

  • Implante suas cargas de trabalho no Serviço Kubernetes do Azure (AKS), com um gráfico Helm em um pipeline de CI/CD, usando um sistema DevOps, como GitHub Actions ou Azure DevOps. Para obter mais informações, consulte Criar e implantar no Serviço Kubernetes do Azure.

  • Introduza testes A/B e implantações canárias no gerenciamento do ciclo de vida do aplicativo, para testar adequadamente um aplicativo antes de disponibilizá-lo para todos os usuários. Há várias técnicas que você pode usar para dividir o tráfego em diferentes versões do mesmo serviço.

  • Como alternativa, você pode usar os recursos de gerenciamento de tráfego fornecidos por uma implementação de malha de serviço. Para obter mais informações, consulte:

  • Use o Registro de Contêiner do Azure ou outro registro de contêiner (como o Hub do Docker) para armazenar as imagens privadas do Docker implantadas no cluster. O AKS pode autenticar-se com o Azure Container Registry, utilizando a sua identidade Microsoft Entra.

Considerações de monitoramento

Embora as considerações de monitoramento não sejam totalmente referentes à multilocação no Serviço Kubernetes do Azure (AKS), acreditamos que elas são requisitos essenciais ao implantar esta solução:

  • Considere as opções de monitoramento integradas ao Azure para monitorar o status de integridade do cluster AKS e das cargas de trabalho.
  • Configure todos os serviços PaaS (como o Registro de Contêiner do Azure e o Cofre de Chaves) para coletar logs e métricas de diagnóstico para o Azure Monitor Log Analytics.

Otimização de custos

O custo dessa arquitetura depende de aspetos de configuração, como os seguintes:

  • Escalões de serviço
  • Escalabilidade, ou seja, o número de instâncias que são alocadas dinamicamente pelos serviços para dar suporte a uma determinada demanda
  • Scripts de automatização
  • Seu nível de recuperação de desastres

Depois de avaliar esses aspetos, vá para a calculadora de preços do Azure para estimar seus custos. Além disso, para obter mais opções de otimização de preços, consulte os Princípios de otimização de custos no Microsoft Azure Well-Architected Framework.

Implementar este cenário

O código-fonte para este cenário está disponível no GitHub. Você também pode encontrar um aplicativo de demonstração, como mostrado na figura a seguir, neste repositório GitHub.

O diagrama mostra a implantação deste AGIC com arquitetura AKS.

Transfira um ficheiro do Visio desta arquitetura.

Pré-requisitos

Para implantações online, você deve ter uma conta existente do Azure. Se precisar de uma, crie uma conta gratuita do Azure antes de começar.

Implantação no Azure

  1. Certifique-se de que tem as informações da sua subscrição do Azure à mão.

  2. Comece clonando o repositório GitHub do workbench:

    git clone https://github.com/Azure-Samples/aks-agic.git

  3. Siga as instruções fornecidas no ficheiro README.md.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Próximos passos

Azure Kubernetes Service

Gateway de Aplicação do Azure

Controlador de Entradas do Gateway de Aplicação do Azure

WAF do Gateway de Aplicação do Azure

Orientação arquitetónica

Arquiteturas de referência