Considerações do Serviço Kubernetes do Azure (AKS) para multilocação

O Serviço Kubernetes do Azure (AKS) simplifica a implantação de um cluster Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para a plataforma de nuvem do Azure. Como um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade. A plataforma Azure gerencia o plano de controle AKS e você paga apenas pelos nós AKS que executam seus aplicativos.

Os clusters AKS podem ser compartilhados entre vários locatários em diferentes cenários e maneiras. Em alguns casos, diversos aplicativos podem ser executados no mesmo cluster. Em outros casos, várias instâncias do mesmo aplicativo podem ser executadas no mesmo cluster compartilhado, uma para cada locatário. Todos esses tipos de compartilhamento são frequentemente descritos usando o termo guarda-chuva multilocação. O Kubernetes não tem um conceito de primeira classe de usuários finais ou locatários. Ainda assim, ele fornece vários recursos para ajudá-lo a gerenciar diferentes requisitos de locação.

Neste artigo, descrevemos alguns dos recursos do AKS que são úteis ao construir sistemas multilocatário. Para obter orientações gerais e práticas recomendadas para multilocação do Kubernetes, consulte Multilocação na documentação do Kubernetes.

Tipos de multilocação

O primeiro passo para determinar como compartilhar um cluster AKS entre vários locatários é avaliar os padrões e as ferramentas à sua disposição. Em geral, a multilocação em clusters Kubernetes se enquadra em duas categorias principais, embora muitas variações ainda sejam possíveis. A documentação do Kubernetes descreve dois casos de uso comuns para multilocação: várias equipes e vários clientes.

Várias equipas

Uma forma comum de multilocação é compartilhar um cluster entre várias equipes dentro de uma organização. Cada equipe pode implantar, monitorar e operar uma ou mais soluções. Essas cargas de trabalho frequentemente precisam se comunicar entre si e com outros aplicativos internos ou externos localizados no mesmo cluster ou em outras plataformas de hospedagem.

Além disso, essas cargas de trabalho precisam se comunicar com serviços, como um banco de dados relacional, um repositório NoSQL ou um sistema de mensagens, que está hospedado no mesmo cluster ou está sendo executado como serviços PaaS no Azure.

Nesse cenário, os membros das equipes geralmente têm acesso direto aos recursos do Kubernetes por meio de ferramentas, como o kubectl. Ou, os membros têm acesso indireto através de controladores GitOps, como Flux e Argo CD, ou através de outros tipos de ferramentas de automação de versão.

Para obter mais informações sobre esse cenário, consulte Várias equipes na documentação do Kubernetes.

Vários clientes

Outra forma comum de multilocação frequentemente envolve um fornecedor de software como serviço (SaaS). Ou, um provedor de serviços executa várias instâncias de uma carga de trabalho para seus clientes, que são considerados locatários separados. Nesse cenário, os clientes não têm acesso direto ao cluster AKS, mas só têm acesso ao seu aplicativo. Além disso, eles nem sabem que seu aplicativo é executado no Kubernetes. A otimização de custos é frequentemente uma preocupação crítica. Os provedores de serviços usam políticas do Kubernetes, como cotas de recursos e diretivas de rede, para garantir que as cargas de trabalho sejam fortemente isoladas umas das outras.

Para obter mais informações sobre esse cenário, consulte Vários clientes na documentação do Kubernetes.

Modelos de isolamento

De acordo com a documentação do Kubernetes, 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 diferentes equipes ou divisões compartilham dentro de uma organização. Ele também contém 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.

Com base no nível de segurança proporcionado pelo isolamento, podemos distinguir entre multilocação suave e multilocação rígida.

• A multilocação suave é adequada dentro de uma única empresa, onde os locatários são equipes ou departamentos diferentes que confiam uns nos outros. Nesse cenário, o isolamento visa garantir a integridade das cargas de trabalho, orquestrar recursos de cluster em diferentes grupos de usuários internos e defender contra possíveis ataques de segurança.
• A multilocação rígida é usada para descrever cenários em que locatários heterogêneos não confiam uns nos outros, muitas vezes de perspetivas de segurança e compartilhamento de recursos.

Ao planejar criar um cluster multilocatário do Serviço Kubernetes do Azure (AKS), você deve considerar as camadas de isolamento de recursos e multilocação fornecidas pelo Kubernetes:

• Cluster
• Espaço de Nomes
• Pool de nós ou nó
• Pod
• Contentor

Além disso, você deve considerar as implicações de segurança do compartilhamento de diferentes 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 cargas de trabalho específicas sejam colocadas. 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.

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 namespaces. Em seguida, você pode usar o RBAC (controle de acesso baseado em função) do Kubernetes e as Diretivas de Rede para impor o isolamento do locatário. Por exemplo, a imagem a seguir mostra o modelo típico de provedor SaaS que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo vive em um namespace separado.

Há várias maneiras de projetar e criar soluções multilocatárias com o Serviço Kubernetes do Azure (AKS). Cada um desses métodos vem com seu próprio conjunto de compensações, em termos de implantação de infraestrutura, topologia de rede e segurança. Esses métodos afetam o nível de isolamento, o esforço de implementação, a complexidade operacional e o custo. Você pode aplicar o isolamento de locatário nos planos de controle e dados, com base em suas necessidades.

Isolamento do plano de controlo

Se você tiver isolamento no nível do plano de controle, você garante que locatários diferentes não possam acessar ou afetar os recursos uns dos outros, como pods e serviços. Além disso, eles não podem afetar o desempenho dos aplicativos de outros locatários. Para obter mais informações, consulte Controlar isolamento de plano na documentação do Kubernetes. A melhor maneira de implementar o isolamento no nível do plano de controle é segregar a carga de trabalho de cada locatário e seus recursos do Kubernetes em um namespace separado.

De acordo com a documentação do Kubernetes, um namespace é uma abstração usada para suportar o isolamento de grupos de recursos dentro de um único cluster. Os namespaces podem ser usados para isolar cargas de trabalho de locatários que estão compartilhando um cluster do Kubernetes:

• Os namespaces permitem que cargas de trabalho de locatários distintas existam em seu próprio espaço de trabalho virtual, sem o risco de afetar o trabalho uns dos outros. Equipes separadas dentro de uma organização podem usar namespaces para isolar seus projetos uns dos outros, porque eles podem usar os mesmos nomes de recursos em namespaces diferentes sem o risco de sobreposição de nomes.
• As funções RBAC e as associações de função são recursos com escopo de namespace que as equipes podem usar para limitar usuários e processos locatários para acessar recursos e serviços somente em seus namespaces. Equipes diferentes podem definir funções para agrupar listas de permissões ou habilidades sob um único nome. Em seguida, eles atribuem essas funções a contas de usuário e contas de serviço, para garantir que apenas as identidades autorizadas tenham acesso aos recursos em um determinado namespace.
• As cotas de recursos para CPU e memória são objetos namespaced. As equipes podem usá-los para garantir que as cargas de trabalho que compartilham o mesmo cluster sejam fortemente isoladas do consumo de recursos do sistema. Esse método pode garantir que cada aplicativo locatário executado em um namespace separado tenha os recursos necessários para ser executado e evitar problemas de vizinhos barulhentos, que podem afetar outros aplicativos de locatário que compartilham o mesmo cluster.
• As diretivas de rede são objetos namespaced que as equipes podem adotar para impor qual tráfego de rede é permitido para um determinado aplicativo locatário. Você pode usar políticas de rede para segregar cargas de trabalho distintas que compartilham o mesmo cluster de uma perspetiva de rede.
• Os aplicativos de equipe executados em namespaces distintos podem usar contas de serviço diferentes para acessar recursos dentro do mesmo cluster, aplicativos externos ou serviços gerenciados.
• Use namespaces para melhorar o desempenho no nível do plano de controle. Se as cargas de trabalho em um cluster compartilhado forem organizadas em vários namespaces, a API do Kubernetes terá menos itens para pesquisar ao executar operações. Essa organização pode reduzir a latência de chamadas no servidor de API e aumentar a taxa de transferência do plano de controle.

Para obter mais informações sobre o isolamento no nível do namespace, consulte os seguintes recursos na documentação do Kubernetes:

• Namespaces (Espaços de nomes)
• Controlos de Acesso
• Quotas

Isolamento do plano de dados

O isolamento do plano de dados garante que pods e cargas de trabalho de locatários distintos estejam suficientemente isolados uns dos outros. Para obter mais informações, consulte Isolamento do plano de dados na documentação do Kubernetes.

Isolamento da rede

Quando você executa aplicativos modernos baseados em microsserviços no Kubernetes, geralmente deseja controlar quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster AKS podem enviar e receber tráfego sem restrições, incluindo outros aplicativos que compartilham o mesmo cluster. Para melhorar a segurança, você pode definir regras de rede para controlar o fluxo de tráfego. A política de rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre Pods. Você pode usar diretivas de rede para segregar comunicações entre aplicativos locatários que compartilham o mesmo cluster.

O Serviço Kubernetes do Azure (AKS) fornece duas maneiras de implementar políticas de rede:

1. O Azure tem sua implementação para políticas de rede, chamadas políticas de rede do Azure.
2. As políticas de rede Calico são uma solução de segurança de rede e rede de código aberto fundada pela Tigera.

Ambas as implementações usam Linux IPTables para impor as políticas especificadas. As políticas de rede são convertidas em conjuntos de pares IP permitidos e não permitidos. Esses pares são então programados como regras de filtro IPTable. Você só pode usar políticas de rede do Azure com clusters AKS configurados com o plug-in de rede CNI do Azure. No entanto, as políticas de rede do Calico suportam o Azure CNI e o kubenet. Para obter mais informações, consulte Proteger o tráfego entre pods usando políticas de rede no Serviço Kubernetes do Azure.

Para obter mais informações, consulte Isolamento de rede na documentação do Kubernetes.

Isolamento de armazenamento

O Azure fornece um conjunto avançado de repositórios de dados gerenciados de plataforma como serviço (PaaS), como o Banco de Dados SQL do Azure e o Azure Cosmos DB, e outros serviços de armazenamento que você pode usar como volumes persistentes para suas cargas de trabalho. Os aplicativos de locatário executados em um cluster AKS compartilhado podem compartilhar um banco de dados ou armazenamento de arquivos, ou podem usar um repositório de dados dedicado e um recurso de armazenamento. Para obter mais informações sobre diferentes estratégias e abordagens para gerenciar dados em um cenário multilocatário, consulte Abordagens arquitetônicas para armazenamento e dados em soluções multilocatário.

As cargas de trabalho em execução no Serviço Kubernetes do Azure (AKS) também podem usar volumes persistentes para armazenar dados. No Azure, você pode criar volumes persistentes como recursos do Kubernetes que são apoiados pelo Armazenamento do Azure. Você pode criar manualmente volumes de dados e atribuí-los a pods diretamente, ou pode fazer com que o AKS os crie automaticamente usando declarações de volume persistentes. O AKS fornece classes de armazenamento internas para criar volumes persistentes que são apoiados pelos Discos do Azure, Arquivos do Azure e Arquivos NetApp do Azure. Para obter mais informações, consulte Opções de armazenamento para aplicativos no Serviço Kubernetes do Azure (AKS). Por motivos de segurança e resiliência, você deve evitar o uso de armazenamento local em nós de agente via emptyDir e hostPath.

Quando as classes de armazenamento integradas do AKS não são adequadas para um ou mais locatários, você pode criar classes de armazenamento personalizadas para atender a diferentes requisitos de locatários. Esses requisitos incluem tamanho do volume, SKU de armazenamento, um contrato de nível de serviço (SLA), políticas de backup e o nível de preço.

Por exemplo, você pode configurar uma classe de armazenamento personalizada para cada locatário. Em seguida, você pode usá-lo para aplicar tags a qualquer volume persistente criado em seu namespace para cobrar de volta seus custos. Para obter mais informações sobre esse cenário, consulte Usar marcas do Azure no Serviço Kubernetes do Azure (AKS).

Para obter mais informações, consulte Isolamento de armazenamento na documentação do Kubernetes.

Isolamento do nó

Você pode configurar cargas de trabalho de locatário para serem executadas em nós de agente separados para evitar o problema do vizinho barulhento e reduzir o risco de divulgação de informações. No AKS, você pode criar um cluster separado, ou apenas um pool de nós dedicado, para locatários que têm requisitos rigorosos de isolamento, segurança, conformidade regulatória e desempenho.

Você pode usar manchas, tolerâncias, rótulos de nós, seletores de nós e afinidade de nós para restringir os pods dos locatários a serem executados apenas em um conjunto específico de nós ou pools de nós.

Em geral, o AKS fornece isolamento de carga de trabalho em vários níveis:

• No nível do kernel, executando cargas de trabalho de locatário em máquinas virtuais leves em nós de agente compartilhado e usando o Pod Sandboxing baseado em Kata Containers.
• No nível físico, hospedando aplicativos locatários em clusters dedicados ou pools de nós.
• No nível de hardware, executando cargas de trabalho de locatário em hosts dedicados do Azure que garantem que as VMs do nó do agente executem máquinas físicas dedicadas. O isolamento de hardware garante que nenhuma outra máquina virtual seja colocada nos hosts dedicados, fornecendo uma camada adicional de isolamento para cargas de trabalho de locatário.

Você pode combinar essas técnicas. Por exemplo, você pode executar clusters por locatário e pools de nós em um grupo de Host Dedicado do Azure para obter segregação de carga de trabalho e isolamento físico no nível de hardware. Você também pode criar pools de nós compartilhados ou por locatário que ofereçam suporte a FIPS (Federal Information Process Standard), máquinas virtuais confidenciais (CVM) ou criptografia baseada em host.

O isolamento de nós permite que você associe e cobre facilmente o custo de um conjunto de nós ou pool de nós para um único locatário. Está estritamente relacionado com o modelo de arrendamento que é adotado pela sua solução.

Para obter mais informações, consulte Isolamento de nó na documentação do Kubernetes.

Modelos de inquilinos

O Serviço Kubernetes do Azure (AKS) fornece mais tipos de isolamento de nó e modelos de locação.

Implantações automatizadas de locatário único

Em um modelo automatizado de implantação de locatário único, você implanta um conjunto dedicado de recursos para cada locatário, conforme ilustrado neste exemplo:

Cada carga de trabalho de locatário é executada em um cluster AKS dedicado e acessa um conjunto distinto de recursos do Azure. Normalmente, as soluções multilocatárias que são construídas usando esse modelo fazem uso extensivo da infraestrutura como código (IaC). Por exemplo, o Bicep, o Azure Resource Manager, o Terraform ou as APIs REST do Azure Resource Manager ajudam a iniciar e coordenar a implantação sob demanda de recursos dedicados ao locatário. Você pode usar essa abordagem quando precisar provisionar uma infraestrutura totalmente separada para cada um de seus clientes. Ao planejar sua implantação, considere usar o padrão Selos de Implantação.

Benefícios:

• Um dos principais benefícios dessa abordagem é que o Servidor de API de cada cluster AKS de locatário é separado. Essa abordagem garante o isolamento total entre os locatários de um nível de segurança, rede e consumo de recursos. Um invasor que consegue obter o controle de um contêiner só terá acesso aos contêineres e volumes montados que pertencem a um único locatário. Um modelo de locação de isolamento total é fundamental para alguns clientes com uma alta sobrecarga de conformidade regulatória.
• É improvável que os locatários afetem o desempenho do sistema uns dos outros, o que permite evitar o problema do vizinho barulhento. Essa consideração inclui o tráfego no Servidor de API. O servidor de API é um componente compartilhado e crítico em qualquer cluster Kubernetes. Os controladores personalizados, que geram tráfego não regulamentado e de alto volume no servidor de API, podem causar instabilidade no cluster. Essa instabilidade leva a falhas de solicitação, tempos limite e tempestades de repetição de API. O recurso Uptime SLA (contrato de nível de serviço) permite dimensionar o plano de controle de um cluster AKS para atender à demanda de tráfego. Ainda assim, o provisionamento de um cluster dedicado pode ser uma solução melhor para os clientes com requisitos fortes em termos de isolamento da carga de trabalho.
• As atualizações e alterações podem ser implementadas progressivamente entre locatários, o que reduz a probabilidade de uma interrupção em todo o sistema. Os custos do Azure podem ser facilmente cobrados de volta aos locatários, pois cada recurso é usado por um único locatário.

Riscos:

• A eficiência de custos é baixa porque cada locatário usa um conjunto dedicado de recursos.
• É provável que a manutenção contínua seja demorada, pois precisa ser replicada em vários clusters AKS, um para cada locatário. Considere automatizar seus processos operacionais e aplicar mudanças progressivamente em seus ambientes. Ajudaria se você também considerasse outras operações de implantação cruzada, como relatórios e análises em todo o seu patrimônio. Da mesma forma, certifique-se de planejar como consultar e manipular dados em várias implantações.

Implantações totalmente multilocatárias

Em uma implantação totalmente multilocatário, um único aplicativo atende às solicitações de todos os locatários e todos os recursos do Azure são compartilhados, incluindo o cluster AKS. Nesse contexto, você só tem um conjunto de infraestrutura para implantar, monitorar e manter. Todos os locatários usam o recurso, conforme ilustrado no diagrama a seguir:

Benefícios:

• Este modelo é atraente devido ao menor custo de operação de uma solução com componentes compartilhados. Ao usar esse modelo de locação, talvez seja necessário implantar um cluster AKS maior e adotar uma SKU mais alta para qualquer repositório de dados compartilhado para sustentar o tráfego gerado pelos recursos de todos os locatários, como repositórios de dados.

Riscos:

• Nesse contexto, um único aplicativo lida com todas as solicitações dos locatários. Você deve projetar e implementar medidas de segurança para evitar que os locatários inundem o aplicativo com chamadas. Essas chamadas podem tornar todo o sistema mais lento e afetar todos os locatários.
• Se o perfil de tráfego for altamente variável, você deve configurar o autoscaler de cluster AKS para variar o número de pods e nós de agente. Baseie sua configuração no uso de recursos do sistema, como CPU e memória. Como alternativa, você pode expandir e dimensionar o número de pods e nós de cluster, com base em métricas personalizadas. Por exemplo, você pode explorar o número de solicitações pendentes ou as métricas de um sistema de mensagens externo que usa o Kubernetes Event-driven Autoscaling (KEDA).
• Certifique-se de separar os dados de cada locatário e implementar salvaguardas para evitar vazamento de dados entre locatários diferentes.
• Certifique-se de controlar e associar os custos do Azure a locatários individuais, com base em seu uso real. Soluções de terceiros, como o kubecost, podem ajudá-lo a calcular e dividir os custos entre diferentes equipes e locatários.
• A manutenção pode ser mais simples com uma única implantação, já que você só precisa atualizar um conjunto de recursos do Azure e manter um único aplicativo. No entanto, também é muitas vezes mais arriscado, uma vez que quaisquer alterações na infraestrutura ou nos componentes do aplicativo podem afetar toda a base de clientes.
• Você também deve considerar limitações de escala. É mais provável que você atinja os limites de escala de recursos do Azure quando tiver um conjunto compartilhado de recursos. Para evitar atingir um limite de cota de recursos, você pode considerar distribuir seus locatários em várias assinaturas do Azure.

Implantações particionadas horizontalmente

Como alternativa, você pode considerar o particionamento horizontal de seu aplicativo Kubernetes multilocatário. Essa abordagem consiste em compartilhar alguns componentes da solução entre todos os locatários e implantar recursos dedicados para locatários individuais. Por exemplo, você pode criar um único aplicativo Kubernetes multilocatário e, em seguida, criar bancos de dados individuais, um para cada locatário, conforme mostrado nesta ilustração:

Benefícios:

• Implantações particionadas horizontalmente podem ajudá-lo a mitigar o problema do vizinho barulhento. Considere essa abordagem, se você identificou que a maior parte da carga de tráfego em seu aplicativo Kubernetes se deve a componentes específicos, que podem ser implantados separadamente, para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema, porque a carga de consulta é alta. Se um único locatário enviar um grande número de solicitações para sua solução, o desempenho de um banco de dados poderá ser afetado negativamente, mas os bancos de dados de outros locatários (e componentes compartilhados, como a camada de aplicativo) permanecerão inalterados.

Riscos:

• Com uma implantação particionada horizontalmente, você ainda precisa considerar a implantação e o gerenciamento automatizados de seus componentes, especialmente os componentes usados por um único locatário.
• Esse modelo pode não fornecer o nível de isolamento necessário para os clientes que não podem compartilhar recursos com outros locatários, por políticas internas ou motivos de conformidade.

Implantações particionadas verticalmente

Você pode aproveitar os benefícios dos modelos de locatário único e totalmente multilocatário usando um modelo híbrido que particiona verticalmente os locatários em vários clusters AKS ou pools de nós. Esta abordagem oferece as seguintes vantagens em relação aos dois modelos de arrendamento anteriores:

• Você pode usar uma combinação de implantações de locatário único e multilocatário. Por exemplo, você pode fazer com que a maioria de seus clientes compartilhe um cluster AKS e um banco de dados em uma infraestrutura multilocatário. Ainda assim, você também pode implantar infraestruturas de locatário único para os clientes que exigem maior desempenho e isolamento.
• Você pode implantar locatários em vários clusters AKS regionais, potencialmente com configurações diferentes. Esta técnica é mais eficaz quando tem inquilinos espalhados por diferentes geografias.

Você pode implementar diferentes variações desse modelo de locação. Por exemplo, você pode optar por oferecer sua solução multilocatária com diferentes níveis de funcionalidade a um custo diferente. Seu modelo de preços pode fornecer várias SKUs, cada uma fornecendo um nível incremental de desempenho e isolamento, em termos de compartilhamento de recursos, desempenho, rede e segregação de dados. Considere os seguintes níveis:

• Nível básico: as solicitações de locatário são atendidas por um único aplicativo Kubernetes multilocatário compartilhado com outros locatários. Os dados são armazenados em um ou mais bancos de dados que são compartilhados por todos os locatários da camada Basic.
• Camada padrão: as solicitações de locatários são atendidas por um aplicativo Kubernetes dedicado que é executado em um namespace separado, que fornece limites de isolamento em termos de segurança, rede e consumo de recursos. Todos os aplicativos dos locatários, um para cada locatário, compartilham o mesmo cluster AKS e pool de nós com outros clientes de camada padrão.
• Nível premium: o aplicativo locatário é executado em um pool de nós dedicado ou cluster AKS para garantir um contrato de nível de serviço mais alto, melhor desempenho e um maior grau de isolamento. Essa camada pode fornecer um modelo de custo flexível com base no número e na SKU dos nós do agente usados para hospedar o aplicativo locatário. Você pode usar o Pod Sandboxing como uma solução alternativa ao uso de clusters dedicados ou pools de nós para isolar cargas de trabalho de locatários distintas.

O diagrama a seguir mostra um cenário em que os locatários A e B são executados em um cluster AKS compartilhado, enquanto o locatário C é executado em um cluster AKS separado.

Da mesma forma, o diagrama a seguir mostra um cenário em que os locatários A e B são executados no mesmo pool de nós, enquanto o locatário C é executado em um pool de nós dedicado.

Esse modelo também pode oferecer diferentes contratos de nível de serviço para diferentes níveis. Por exemplo, o nível básico pode oferecer 99,9% de tempo de atividade, o nível padrão pode oferecer 99,95% de tempo de atividade e o nível premium pode oferecer 99,99%. O contrato de nível de serviço (SLA) mais alto pode ser implementado usando serviços e recursos que permitem metas de disponibilidade mais altas.

Benefícios:

• Como você ainda está compartilhando infraestrutura, ainda pode obter alguns dos benefícios de custo de ter implantações multilocatárias compartilhadas. Você pode implantar clusters e pools de nós que são compartilhados entre vários aplicativos de locatário de camada básica e de camada padrão, que usam um tamanho de VM mais barato para nós de agente. Esta abordagem garante uma melhor densidade e poupança de custos. Para clientes de nível premium, você pode implantar clusters AKS e pools de nós com um tamanho de VM maior e um número máximo de réplicas de pod e nós a um preço mais alto.
• Você pode executar serviços do sistema, como CoreDNS, Konnectivity ou Azure Application Gateway Ingress Controller, em um pool de nós dedicado no modo de sistema. Você pode usar taints, tolerations, rótulos de nó, seletores de nós e afinidade de nó para executar um aplicativo locatário em um ou mais pools de nós de modo de usuário.
• Você pode usar manchas, tolerâncias, rótulos de nó, seletores de nós e afinidade de nó para executar recursos compartilhados. Por exemplo, você pode ter um controlador de entrada ou sistema de mensagens em um pool de nós dedicado, com um tamanho de VM específico, configurações de dimensionamento automático e suporte a zonas de disponibilidade.

Riscos:

• Você precisa projetar seu aplicativo Kubernetes para oferecer suporte a implantações multilocatárias e de locatário único.
• Se você planeja permitir a migração entre infraestruturas, precisa considerar como migrar os clientes de uma implantação multilocatária para sua própria implantação de locatário único.
• Você precisa de uma estratégia consistente e um único painel de vidro (um ponto de vista) para monitorar e gerenciar mais clusters AKS.

Dimensionamento automático

Para acompanhar a demanda de tráfego gerada por aplicativos de locatário, você pode habilitar o autoscaler de cluster para dimensionar os nós de agente do seu Serviço Kubernetes do Azure (AKS). O dimensionamento automático ajuda os sistemas a permanecerem responsivos nas seguintes circunstâncias:

• A carga de tráfego aumenta durante horas de trabalho específicas ou períodos do ano.
• Cargas pesadas compartilhadas ou locatárias são implantadas em um cluster.
• Os nós do agente ficam indisponíveis devido a interrupções zonais.

Ao habilitar o dimensionamento automático para um pool de nós, você especifica um número mínimo e máximo de nós com base nos tamanhos de carga de trabalho esperados. Ao configurar um número máximo de nós, você pode garantir espaço suficiente para todos os pods de locatário no cluster, independentemente do namespace em que eles são executados.

Quando o tráfego aumenta, o dimensionamento automático do cluster adiciona novos nós de agente para evitar que os pods entrem em um estado pendente, devido à escassez de recursos em termos de CPU e memória.

Da mesma forma, quando a carga diminui, o dimensionamento automático do cluster diminui o número de nós de agente em um pool de nós, com base nos limites especificados, o que ajuda a reduzir os custos operacionais.

Você pode usar o dimensionamento automático de pods para dimensionar pods automaticamente, com base nas demandas de recursos. O Horizontal Pod Autoscaler (HPA) dimensiona automaticamente o número de réplicas de pods, com base na utilização da CPU/memória ou em métricas personalizadas. Com o Kubernetes Event-driven Autoscaling (KEDA), você pode conduzir o dimensionamento de qualquer contêiner no Kubernetes, com base no número de eventos de sistemas externos, como Hubs de Eventos do Azure ou Barramento de Serviço do Azure, que são usados por aplicativos locatários.

Manutenção

Para reduzir o risco de tempos de inatividade que podem afetar os aplicativos do locatário durante atualizações de cluster ou pool de nós, agende a Manutenção Planejada do AKS para ocorrer fora do horário de pico. A Manutenção Planejada permite agendar janelas de manutenção semanais para atualizar o plano de controle dos clusters AKS que executam aplicativos de locatário e pools de nós, o que minimiza o impacto da carga de trabalho. Você pode agendar uma ou mais janelas de manutenção semanais em seu cluster especificando um dia ou intervalo de tempo em um dia específico. Todas as operações de manutenção ocorrerão durante as janelas programadas.

Segurança

Acesso ao cluster

Quando você compartilha um cluster AKS entre várias equipes dentro de uma organização, você precisa implementar o princípio de menor privilégio para isolar diferentes locatários uns dos outros. Em particular, você precisa garantir que os usuários tenham acesso apenas aos seus namespaces e recursos do Kubernetes ao usar ferramentas, como kubectl, Helm, Flux, Argo CD ou outros tipos de ferramentas.

Para obter mais informações sobre autenticação e autorização com o AKS, consulte os seguintes artigos:

• Access and identity options for Azure Kubernetes Service (AKS) (Opções de acesso e de identidade do Azure Kubernetes Service (AKS))
• Integração do Microsoft Entra gerenciada pelo AKS
• Controle o acesso aos recursos do cluster usando o controle de acesso baseado em função do Kubernetes e as identidades do Microsoft Entra no Serviço Kubernetes do Azure

Identidade da carga de trabalho

Se você hospedar vários aplicativos de locatário em um único cluster AKS e cada um estiver em um namespace separado, cada carga de trabalho deverá usar uma conta de serviço e credenciais do Kubernetes diferentes para acessar os serviços downstream do Azure. As contas de serviço são um dos principais tipos de usuário no Kubernetes. A API do Kubernetes mantém e gerencia contas de serviço. As credenciais da conta de serviço são armazenadas como segredos do Kubernetes, o que permite que elas sejam usadas por pods autorizados para se comunicar com o Servidor de API. A maioria das solicitações de API fornece um token de autenticação para uma conta de serviço ou uma conta de usuário normal.

As cargas de trabalho de locatário implantadas em clusters AKS podem usar credenciais de aplicativo do Microsoft Entra para acessar recursos protegidos por ID do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. O Microsoft Entra Workload ID for Kubernetes integra-se com os recursos nativos do Kubernetes para federar com qualquer provedor de identidade externo.

Sandboxing de Pods

O AKS inclui um mecanismo chamado Pod Sandboxing que fornece um limite de isolamento entre o aplicativo de contêiner e o kernel compartilhado e os recursos de computação do host do contêiner, como CPU, memória e rede. O Pod Sandboxing complementa outras medidas de segurança ou controles de proteção de dados para ajudar as cargas de trabalho do locatário a proteger informações confidenciais e atender aos requisitos de conformidade regulamentar, do setor ou de governança, como o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), a Organização Internacional de Padronização (ISO) 27001 e a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA).

A implantação de aplicativos em clusters ou pools de nós separados permite isolar fortemente as cargas de trabalho de locatários de diferentes equipes ou clientes. O uso de vários clusters e pools de nós pode ser adequado para os requisitos de isolamento de muitas organizações e soluções SaaS, mas há cenários em que um único cluster com pools de nós de VM compartilhados é mais eficiente, por exemplo, quando você está executando pods não confiáveis e confiáveis no mesmo nó ou colocalizando DaemonSets e contêineres privilegiados no mesmo nó para uma comunicação local e agrupamento funcional mais rápidos. O Pod Sandboxing pode ajudá-lo a isolar fortemente os aplicativos do locatário nos mesmos nós de cluster sem a necessidade de executar essas cargas de trabalho em clusters ou pools de nós separados. Outros métodos exigem que você recompile seu código ou cause outros problemas de compatibilidade, mas o Pod Sandboxing no AKS pode executar qualquer contêiner sem modificações dentro de um limite de VM de segurança aprimorada.

O Pod Sandboxing no AKS é baseado em Kata Containers que são executados no host de contêiner do Azure Linux para a pilha AKS para fornecer isolamento imposto por hardware. Os Contêineres Kata no AKS são criados em um hipervisor do Azure com segurança reforçada. O isolamento por pod é obtido por meio de uma VM Kata leve aninhada que utiliza recursos de um nó de VM pai. Neste modelo, cada pod Kata obtém seu próprio kernel em uma VM convidada Kata aninhada. Esse modelo permite que você coloque muitos contêineres Kata em uma única VM convidada enquanto continua a executar contêineres na VM pai. O modelo fornece um forte limite de isolamento em um cluster AKS compartilhado.

Para obter mais informações, consulte:

• Sandboxing de pod com o Serviço Kubernetes do Azure (AKS)
• Suporte para Kata VM Isolated Containers no AKS for Pod Sandboxing

Azure Dedicated Host

O Host Dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure e fornece isolamento de hardware no nível do servidor físico. Esses hosts dedicados podem ser provisionados dentro de uma região, zona de disponibilidade e domínio de falha, e você pode colocar VMs diretamente nos hosts provisionados.

Você pode obter vários benefícios usando o Host Dedicado do Azure com o AKS, incluindo o seguinte:

• O isolamento de hardware garante que nenhuma outra VM seja colocada nos hosts dedicados, o que fornece uma camada adicional de isolamento para cargas de trabalho de locatário. Os hosts dedicados são implantados nos mesmos datacenters e compartilham a mesma rede e a mesma infraestrutura de armazenamento subjacente que outros hosts não isolados.

• O Host Dedicado do Azure fornece controle sobre eventos de manutenção iniciados pela plataforma Azure. Você pode escolher uma janela de manutenção para reduzir o impacto nos serviços e ajudar a garantir a disponibilidade e a privacidade das cargas de trabalho do locatário.

O Host Dedicado do Azure pode ajudar os provedores de SaaS a garantir que os aplicativos de locatário atendam aos requisitos de conformidade regulamentar, do setor e de governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar Host Dedicado do Azure a um cluster do Serviço Kubernetes do Azure (AKS).

Máquinas Virtuais Confidenciais

Você pode usar Máquinas Virtuais Confidenciais (CVMs) para adicionar um ou mais pools de nós ao seu cluster AKS para atender aos requisitos estritos de isolamento, privacidade e segurança dos locatários. Os CVMs usam um ambiente de execução confiável (TEE) baseado em hardware. AMD Secure Encrypted Virtualization - As VMs confidenciais do Secure Nested Paging (SEV-SNP) negam ao hipervisor e a outros códigos de gerenciamento de host acesso à memória e ao estado da VM, adicionando uma camada de proteção profunda contra o acesso do operador. Para obter mais informações, consulte Usar CVMs em um cluster AKS.

Normas Federais de Processo de Informação (FIPS)

O FIPS 140-3 é um padrão do governo dos EUA que define requisitos mínimos de segurança para módulos criptográficos em produtos e sistemas de tecnologia da informação. Ao habilitar a conformidade FIPS para pools de nós AKS, você pode melhorar o isolamento, a privacidade e a segurança de suas cargas de trabalho de locatário. A conformidade FIPS garante o uso de módulos criptográficos validados para criptografia, hashing e outras operações relacionadas à segurança. Com pools de nós AKS habilitados para FIPS, você pode atender aos requisitos de conformidade regulatória e do setor empregando algoritmos e mecanismos criptográficos robustos. O Azure fornece documentação sobre como habilitar o FIPS para pools de nós AKS, permitindo que você fortaleça a postura de segurança de seus ambientes AKS multilocatário. Para obter mais informações, consulte Habilitar FIPS para pools de nós AKS.

Traga suas próprias chaves (BYOK) com discos do Azure

O Armazenamento do Azure encripta todos os dados numa conta de armazenamento em repouso, incluindo o SO e os discos de dados de um cluster AKS. Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia no restante do sistema operacional e discos de dados de seus clusters AKS. Para obter mais informações, consulte:

• BYOK com discos do Azure no AKS
• Encriptação do lado do servidor do Armazenamento de Discos do Azure

Ativar a encriptação baseada no anfitrião

A criptografia baseada em host no AKS fortalece ainda mais o isolamento, a privacidade e a segurança da carga de trabalho do locatário. Quando você habilita a criptografia baseada em host, o AKS criptografa dados em repouso nas máquinas host subjacentes, ajudando a garantir que as informações confidenciais do locatário sejam protegidas contra acesso não autorizado. Discos temporários e discos efêmeros do sistema operacional são criptografados em repouso com chaves gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta.

No AKS, o sistema operacional e os discos de dados usam criptografia do lado do servidor com chaves gerenciadas pela plataforma por padrão. Os caches desses discos são criptografados em repouso com chaves gerenciadas pela plataforma. Você pode especificar sua própria chave de criptografia de chave (KEK) para criptografar a chave de proteção de dados (DEK) usando criptografia de envelope, também conhecida como encapsulamento. O cache do sistema operacional e dos discos de dados também são criptografados por meio do BYOK que você especificar.

A criptografia baseada em host adiciona uma camada de segurança para ambientes multilocatário. Os dados de cada locatário no sistema operacional e nos caches de disco de dados são criptografados em repouso com chaves gerenciadas pelo cliente ou pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para obter mais informações, consulte:

• Criptografia baseada em host no AKS
• BYOK com discos do Azure no AKS
• Encriptação do lado do servidor do Armazenamento de Discos do Azure

Rede

Restringir o acesso à rede ao servidor de API

No Kubernetes, o servidor de API recebe solicitações para executar ações no cluster, como criar recursos ou dimensionar o número de nós. Ao compartilhar um cluster AKS entre várias equipes dentro de uma organização, proteja o acesso ao plano de controle usando uma das seguintes soluções.

Clusters privados do AKS

Usando um cluster AKS privado, você pode garantir que o tráfego de rede entre seu servidor de API e seus pools de nós permaneça em sua rede virtual. Em um cluster AKS privado, o plano de controle ou servidor de API tem um endereço IP interno que só é acessível por meio de um ponto de extremidade privado do Azure, que está localizado na mesma rede virtual do cluster AKS. Da mesma forma, qualquer máquina virtual na mesma rede virtual pode se comunicar de forma privada com o plano de controle por meio do ponto de extremidade privado. Para obter mais informações, veja Criar um cluster do Azure Kubernetes Service privado.

IPs autorizados

A segunda opção para melhorar a segurança do cluster e minimizar ataques é usar IPs autorizados. Essa abordagem restringe o acesso ao plano de controle de um cluster AKS público a uma lista bem conhecida de endereços IP (Internet Protocol) e CIDR (Roteamento entre Domínios sem Classe). Quando você usa IPs autorizados, eles ainda são expostos publicamente, mas o acesso é limitado a um conjunto de intervalos de IP. Para obter mais informações, consulte Acesso seguro ao servidor de API usando intervalos de endereços IP autorizados no Serviço Kubernetes do Azure (AKS).

Integração de Link Privado

O Azure Private Link Service (PLS) é um componente de infraestrutura que permite que os aplicativos se conectem de forma privada a um serviço por meio de um ponto de extremidade privado (PE) do Azure definido em uma rede virtual e conectado à configuração IP de front-end de uma instância do Azure Load Balancer (ALB). Com o Azure Private Link, os provedores de serviços podem fornecer seus serviços com segurança a seus locatários que podem se conectar de dentro do Azure ou localmente, sem riscos de exfiltração de dados.

Você pode usar a Integração do Serviço de Link Privado do Azure para fornecer aos locatários conectividade privada para suas cargas de trabalho hospedadas pelo AKS de forma segura, sem a necessidade de expor qualquer ponto de extremidade público na Internet pública.

Para obter orientações gerais sobre como configurar o Private Link para uma solução multilocatária hospedada no Azure, consulte Multilocação e Azure Private Link.

Proxies reversos

Um proxy reverso é um balanceador de carga e um gateway de API que normalmente é usado na frente de aplicativos locatários para proteger, filtrar e despachar solicitações de entrada. Os populares proxies reversos suportam recursos como balanceamento de carga, terminação SSL e roteamento de camada 7. Os proxies reversos são normalmente implementados para ajudar a aumentar a segurança, o desempenho e a confiabilidade. Proxies reversos populares para Kubernetes incluem as seguintes implementações:

• NGINX Ingress Controller é um popular servidor proxy reverso que suporta recursos avançados, como balanceamento de carga, terminação SSL e roteamento de camada 7.
• Traefik Kubernetes Ingress provider é um controlador Kubernetes Ingress que pode ser usado para gerenciar o acesso a serviços de cluster suportando a especificação de entrada.
• HAProxy Kubernetes Ingress Controller é mais um proxy reverso para Kubernetes, que suporta recursos padrão, como terminação TLS, roteamento baseado em caminho de URL e muito mais.
• O Azure Application Gateway Ingress Controller (AGIC) é um aplicativo Kubernetes , que possibilita que os clientes do Serviço Kubernetes do Azure (AKS) aproveitem o balanceador de carga nativo do Application Gateway L7 do Azure para expor aplicativos locatários à Internet pública ou internamente a outros sistemas executados em uma rede virtual.

Ao usar um proxy reverso hospedado pelo AKS para proteger e lidar com solicitações de entrada para vários aplicativos de locatário, considere as seguintes recomendações:

• Hospede o proxy reverso em um pool de nós dedicado configurado para usar um tamanho de VM com uma largura de banda de alta rede e rede acelerada habilitada.
• Configure o pool de nós que está hospedando seu proxy reverso para dimensionamento automático.
• Para evitar o aumento da latência e dos tempos limite para aplicativos locatários, defina uma política de dimensionamento automático para que o número de pods do controlador de entrada possa ser expandido e contratado instantaneamente para corresponder às flutuações de tráfego.
• Considere fragmentar o tráfego de entrada para aplicativos de locatário, em várias instâncias do controlador de entrada, para aumentar o nível de escalabilidade e segregação.

Ao usar o Azure Application Gateway Ingress Controller (AGIC), considere implementar as seguintes práticas recomendadas:

• Configure o Application Gateway usado pelo controlador de entrada para Autoscaling. Com o dimensionamento automático habilitado, as SKUs do Application Gateway e do WAF v2 são dimensionadas ou aumentadas, com base nos requisitos de tráfego do aplicativo. Esse modo oferece melhor elasticidade ao seu aplicativo e elimina a necessidade de adivinhar o tamanho do gateway de aplicativo ou a contagem de instâncias. Esse modo também permite economizar custos, não exigindo que o gateway seja executado na capacidade provisionada de pico para a carga máxima de tráfego esperada. Você deve especificar uma contagem mínima (e, opcionalmente, máxima) de instâncias.
• Considere a implantação de várias instâncias do Application Gateway Ingress Controller (AGIC), cada uma associada a um Application Gateway separado, quando o número de aplicativos locatários exceder a quantidade máxima de sites. Supondo que cada aplicativo locatário seja executado em um namespace dedicado, use o suporte a vários namespaces para distribuir aplicativos locatários por mais instâncias do Application Gateway Ingress Controller (AGIC).

Integração com o Azure Front Door

O Azure Front Door é um balanceador de carga global de camada 7 e a moderna rede de entrega de conteúdo em nuvem (CDN) da Microsoft que fornece acesso rápido, confiável e seguro entre usuários e aplicativos Web em todo o mundo. O Azure Front Door suporta recursos como aceleração de solicitação, terminação SSL, cache de resposta, WAF na borda, roteamento baseado em URL, regravação e redirecionamentos que você pode explorar ao expor aplicativos multilocatários hospedados pelo AKS à Internet pública.

Por exemplo, você pode querer usar um aplicativo multilocatário hospedado pelo AKS para atender a todas as solicitações dos clientes. Nesse contexto, você pode usar o Azure Front Door para gerenciar vários domínios personalizados, um para cada locatário. Você pode encerrar conexões SSL na borda e rotear todo o tráfego para o aplicativo multilocatário hospedado pelo AKS configurado com um único nome de host.

Você pode configurar o Azure Front Door para modificar o cabeçalho do host de origem da solicitação para corresponder ao nome de domínio do aplicativo de back-end. O cabeçalho original Host enviado pelo cliente é propagado através do X-Forwarded-Host cabeçalho, e o código do aplicativo multilocatário pode usar essas informações para mapear a solicitação de entrada para o locatário correto.

O Azure Web Application Firewall (WAF), na Porta da Frente do Azure, fornece proteção centralizada para aplicativos Web. Você pode usar o WAF do Azure para defender aplicativos de locatário hospedados pelo AKS que expõem um ponto de extremidade público na Internet contra ataques mal-intencionados.

Você pode configurar o Azure Front Door Premium para se conectar de forma privada a um ou mais aplicativos de locatário executados em um cluster AKS, por meio de uma origem de balanceador de carga interno, usando o Serviço de Link Privado do Azure. Para obter mais informações, consulte Conectar o Azure Front Door Premium a uma origem de balanceador de carga interno com Private Link.

Ligações de saída

Quando os aplicativos hospedados pelo AKS se conectam a um grande número de bancos de dados ou serviços externos, o cluster pode estar em risco de esgotamento da porta SNAT. As portas SNAT geram identificadores exclusivos que são usados para manter fluxos distintos que são iniciados por aplicativos executados no mesmo conjunto de recursos de computação. Ao executar vários aplicativos de locatário em um cluster compartilhado do Serviço Kubernetes do Azure (AKS), você pode fazer um grande número de chamadas de saída, o que pode levar a um esgotamento da porta SNAT. Um cluster AKS pode lidar com conexões de saída de três maneiras diferentes:

• Azure Public Load Balancer: Por padrão, o AKS provisiona um Balanceador de Carga SKU Standard para ser configurado e usado para conexões de saída. No entanto, a configuração padrão pode não atender aos requisitos de todos os cenários, se IPs públicos não forem permitidos ou se saltos adicionais forem necessários para a saída. Por padrão, o Balanceador de Carga público é criado com um endereço IP público padrão que é usado pelas regras de saída. As regras de saída permitem definir explicitamente a conversão de endereços de rede de origem (SNAT) para um balanceador de carga padrão público. Essa configuração permite que você use o(s) IP(s) público(s) do seu balanceador de carga para fornecer conectividade de saída à Internet para suas instâncias de back-end. Quando necessário, para evitar o esgotamento da porta SNAT, você pode configurar as regras de saída do balanceador de carga público para usar endereços IP públicos adicionais. Para obter mais informações, consulte Usar o endereço IP frontend de um balanceador de carga para saída por meio de regras de saída.
• Azure NAT Gateway: Você pode configurar um cluster AKS para usar o Azure NAT Gateway para rotear o tráfego de saída de aplicativos de locatário. O NAT Gateway permite até 64.512 fluxos de tráfego UDP e TCP de saída por endereço IP público, com um máximo de 16 endereços IP. Para evitar o risco de esgotamento da porta SNAT ao usar um gateway NAT para lidar com conexões de saída de um cluster AKS, você pode associar mais endereços IP públicos ou um prefixo de endereço IP público ao gateway. Para obter mais informações, consulte Considerações do Gateway NAT do Azure para multilocação.
• Rota definida pelo usuário (UDR): Você pode personalizar a rota de saída de um cluster AKS para oferecer suporte a cenários de rede personalizados, como aqueles que não permitem IPs públicos e exigem que o cluster fique atrás de um dispositivo virtual de rede (NVA). Quando você configura um cluster para roteamento definido pelo usuário, o AKS não configura automaticamente os caminhos de saída. A configuração da saída deve ser feita por você. Por exemplo, você rotearia o tráfego de saída por meio de um Firewall do Azure. O cluster AKS deve ser implantado em uma rede virtual existente, com uma sub-rede que tenha sido configurada anteriormente. Quando você não estiver usando uma arquitetura de balanceador de carga padrão (SLB), deverá estabelecer uma saída explícita. Como tal, essa arquitetura requer o envio explícito de tráfego de saída para um dispositivo, como um firewall, gateway ou proxy. Ou, a arquitetura permite que a conversão de endereços de rede (NAT) seja feita por um IP público atribuído ao balanceador de carga ou dispositivo padrão.

Monitorização

Você pode usar o Azure Monitor e o Container Insights para monitorar aplicativos de locatário executados em um cluster AKS compartilhado e para calcular detalhamentos de custo em namespaces individuais. O Azure Monitor permite monitorar a integridade e o desempenho do Serviço Kubernetes do Azure (AKS). Ele inclui a coleta de logs e métricas, análise de telemetria e visualizações de dados coletados, para identificar tendências e configurar alertas para notificá-lo proativamente sobre problemas críticos. Você pode habilitar o Container insights para expandir esse monitoramento.

Você também pode adotar ferramentas de código aberto, como Prometheus e Grafana, que são amplamente utilizadas pela comunidade para monitoramento do Kubernetes. Ou, você pode adotar outras ferramentas de terceiros para monitoramento e observabilidade.

Custos

A governança de custos é o processo contínuo de implementação de políticas para controlar custos. No contexto do Kubernetes, há várias maneiras pelas quais as organizações podem controlar e otimizar custos. Isso inclui ferramentas nativas do Kubernetes para gerenciar e controlar o uso e o consumo de recursos e para monitorar e otimizar proativamente a infraestrutura subjacente. Ao calcular os custos por locatário, você deve considerar os custos associados a qualquer recurso usado por um aplicativo de locatário. A abordagem que você segue para cobrar taxas de volta aos inquilinos depende do modelo de locação adotado pela sua solução. Mais detalhes são explicados com os seguintes modelos de locação:

• Totalmente multilocatário: quando um único aplicativo multilocatário atende a todas as solicitações do locatário, é sua responsabilidade acompanhar o consumo de recursos e o número de solicitações geradas por cada locatário. Em seguida, cobra aos seus clientes em conformidade.
• Cluster dedicado: quando um cluster é dedicado a um único locatário, é fácil cobrar os custos dos recursos do Azure de volta ao cliente. O custo total de propriedade depende de muitos fatores, que incluem o número e o tamanho das máquinas virtuais, os custos de rede devido ao tráfego de rede, endereços IP públicos, balanceadores de carga, os serviços de armazenamento, como discos gerenciados ou arquivos do Azure usados pela solução de locatário, e assim por diante. Você pode marcar um cluster AKS e seus recursos no grupo de recursos do nó para facilitar as operações de cobrança de custos. Para obter mais informações, consulte Adicionar marcas ao cluster.
• Pool de nós dedicados: você pode aplicar uma marca do Azure a um pool de nós novo ou existente dedicado a um único locatário. As tags aplicadas a um pool de nós são aplicadas a cada nó dentro do pool de nós e persistem por meio de atualizações. As tags também são aplicadas a novos nós que são adicionados a um pool de nós durante operações de expansão. Adicionar uma tag pode ajudar em tarefas como controle de políticas ou cobrança de custos. Para obter mais informações, consulte Adicionando tags a pools de nós.
• Outros recursos: você pode usar tags para associar custos de recursos dedicados a um determinado locatário. Em particular, você pode marcar IPs, arquivos e discos públicos usando um manifesto do Kubernetes. As tags definidas dessa maneira manterão os valores do Kubernetes, mesmo que você os atualize posteriormente usando outro método. Quando IPs, arquivos ou discos públicos são removidos por meio do Kubernetes, todas as tags definidas pelo Kubernetes são removidas. As tags nesses recursos que não são rastreadas pelo Kubernetes permanecem inalteradas. Para obter mais informações, consulte Adicionar tags usando o Kubernetes.

Você pode usar ferramentas de código aberto, como KubeCost, para monitorar e controlar um custo de cluster AKS. A alocação de custos pode ter como escopo uma implantação, serviço, rótulo, pod e namespace, o que lhe dará flexibilidade na forma como você estorno ou mostra os usuários do cluster. Para obter mais informações, consulte Governança de custos com Kubecost.

Para obter mais informações sobre a medição, alocação e otimização de custos para um aplicativo multilocatário, consulte Abordagens arquitetônicas para gerenciamento e alocação de custos em uma solução multilocatário. Para obter orientações gerais sobre otimização de custos, consulte o artigo do Azure Well-Architected Framework, Visão geral do pilar de otimização de custos

Contribuidores

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

Autor principal:

• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

• John Downs - Brasil | Engenheiro de Software Principal
• Ed Preço | Gerente de Programa de Conteúdo Sênior
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Bohdan Cherchyk - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure

Próximos passos

Recursos de revisão para arquitetos e desenvolvedores de soluções multilocatário.