Editar

Compartilhar via

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

Azure
AKS (Serviço de Kubernetes do Azure)

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

Os clusters do AKS podem ser compartilhados entre múltiplos 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 geral 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 se criar sistemas multilocatários. Para obter diretrizes gerais e práticas recomendadas para multilocação do Kubernetes, consulte Multilocação na documentação do Kubernetes.

Tipos de multilocação

A primeira etapa para determinar como compartilhar um cluster AKS entre múltiplos locatários é avaliar os padrões e as ferramentas à sua disposição. Em geral, a multilocação em clusters do 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 equipes

Uma forma comum de multilocação é compartilhar um cluster entre várias equipes em uma organização. Cada equipe pode implantar, monitorar e operar uma ou mais soluções. Essas cargas de trabalho frequentemente precisam se comunicar umas com as outras e com outros aplicativos internos ou externos que estão 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 kubectl. Ou então, os membros têm acesso indireto por meio de controladores GitOps, como Flux e Argo CD, ou por meio de outros tipos de ferramentas de automação de lançamento.

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 então, 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 aplicativo. Além disso, eles nem sabem que seu aplicativo é executado no Kubernetes. A otimização de custos é frequentemente uma preocupação importante. Os provedores de serviços usam políticas do Kubernetes, como cotas de recursos e políticas 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árias clientes na documentação do Kubernetes.

Modelos de isolamento

De acordo com a documentação do Kubernetes, um cluster do 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 em uma organização. Ela também contém clusters compartilhados por instâncias por cliente de um aplicativo software como serviço (SaaS).

A multilocação de cluster é uma alternativa ao gerenciamento de vários clusters dedicados de locatário único. Os operadores de um cluster do 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 a fração justa de recursos alocada a ela. As cotas de recursos são uma ferramenta para os administradores resolverem essa preocupação.

Com base no nível de segurança fornecido pelo isolamento, podemos distinguir entre multilocação fácil e difícil.

  • A multilocação flexível é adequada em uma empresa única, em que 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-se 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, geralmente a partir de perspectivas de compartilhamento de recursos e seguranças.

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

  • Cluster
  • Namespace
  • Pool de nós ou nó
  • Pod
  • Contêiner

Além disso, você deve considerar as implicações de segurança do compartilhamento de diferentes recursos entre múltiplos locatários. Por exemplo, o agendamento de pods de locatários diferentes no mesmo nó pode reduzir o número de computadores necessários 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 um código não confiável fora da sua organização seja executado no mesmo nó que os contêineres que processam informações confidenciais.

Embora o Kubernetes não possa garantir um isolamento perfeitamente seguro entre os locatários, ele oferece recursos que podem ser suficientes para casos de uso específicos. Como uma melhor prática, você deve separar cada locatário e os respectivos recursos de Kubernetes em namespaces. Em seguida, você pode usar o controle de acesso com base em função do Kubernetes e as Políticas de Rede para impor o isolamento do locatário. Por exemplo, a imagem a seguir mostra o modelo típico de provedor de SaaS que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo reside em um namespace separado.

Diagrama que mostra um modelo de provedor SaaS que hospeda várias instâncias do mesmo aplicativo no mesmo cluster.

Há várias maneiras de projetar e criar soluções multilocatário com o Serviço de 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 de dados, de acordo com suas necessidades.

Isolamento do plano de controle

Se tiver isolamento no nível do plano de controle, você garantirá que diferentes locatários não possam acessar ou afetar os recursos uns dos outros, como pods e serviços. Além disso, eles não poderão afetar o desempenho dos aplicativos de outros locatários. Para obter mais informações, consulte Isolamento do plano de controle 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, namespace é uma abstração usada para dar suporte ao isolamento de grupos de recursos em 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 workspace virtual, sem o risco de afetar o trabalho uns dos outros. Equipes separadas em uma organização podem usar namespaces para isolar os projetos uns dos outros, porque eles podem usar os mesmos nomes de recursos em namespaces diferentes sem o risco de sobreposição de nomes.
  • Funções RBAC e 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 a acessar recursos e serviços somente em seus namespaces. Diferentes equipes podem definir funções para agrupar listas de permissões ou habilidades mediante um único nome. Em seguida, eles atribuem essas funções a contas de usuário e contas de serviço, a fim de garantir que apenas as identidades autorizadas tenham acesso aos recursos em um determinado namespace.
  • Cotas de recursos para CPU e memória são objetos com namespace. As equipes podem usá-las 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 executar e evitar problemas de vizinhos barulhentos, que poderão afetar outros aplicativos locatários que compartilham o mesmo cluster.
  • Políticas de rede são objetos com namespace que as equipes podem adotar para impor qual tráfego de rede é permitido para um determinado aplicativo locatário. Você pode usar as políticas de rede para segregar cargas de trabalho distintas que compartilham o mesmo cluster de uma perspectiva de rede.
  • Os aplicativos de equipe executados em namespaces distintos podem usar contas de serviço diferentes para acessar recursos no 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 durante a execução das 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:

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 um do outro. Para obter mais informações, consulte Isolamento do plano de dados na documentação do Kubernetes.

Isolamento da rede

Ao executar aplicativos modernos baseados em microsserviços no Kubernetes, muitas vezes você deseja controlar quais componentes podem se comunicar uns com os outros. 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 políticas de rede para segregar a comunicação entre aplicativos locatários que compartilham o mesmo cluster.

O Serviço de 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, denominadas 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 por Tigera.

Ambas as implementações usam o IPTables Linux para impor as políticas especificadas. As políticas de rede são convertidas em conjuntos de pares de IP permitidos e não permitidos. Esses pares são programados como regras de filtro IPTable. Você só pode usar políticas de rede do Azure com clusters do AKS configurados com o plug-in de rede CNI do Azure. No entanto, as políticas de rede do Calico oferecem suporte ao CNI do Azure e ao kubenet. Para obter mais informações, consulte Proteger o tráfego entre os pods usando as políticas de rede no Serviço de 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 da plataforma como serviço (PaaS) gerenciados, como o Banco de Dados SQL do Azure e o Azure Cosmos DB, além de outros serviços de armazenamento que você pode usar como volumes persistentes para suas cargas de trabalho. Os aplicativos locatários que são executados em um cluster do AKS compartilhado podem compartilhar um banco de dados ou repositório 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 de arquitetura para armazenamento e dados em soluções multilocatário.

As cargas de trabalho em execução no Serviço de 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 respaldados pelo Armazenamento do Azure. Você pode criar volumes de dados manualmente e atribuí-los a pods diretamente, ou você 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 sejam respaldados por Discos do Azure, Arquivos do Azure e Azure NetApp Files. Para obter mais informações, confira Opções de armazenamento para aplicativos no AKS (Serviço de Kubernetes do Azure). Por motivos de segurança e resiliência, evite usar o armazenamento local em nós de agente por meio de emptyDir e hostPath.

Quando as classes de armazenamento internas 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, SLA (contrato de nível de serviço), políticas de backup e o tipo de preços.

Por exemplo, você pode configurar uma classe de armazenamento personalizada para cada locatário. Em seguida, pode usá-la para aplicar marcas a qualquer volume persistente criado em seu namespace para estornar os custos aplicados a eles. Para mais informações sobre este cenário, consulte Usar as marcas do Azure no AKS (Serviço de Kubernetes do Azure).

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

Isolamento de nó

Você pode configurar cargas de trabalho de locatário para serem executadas em nós de agente separados, a fim de evitar o problema de 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 rígidos de isolamento, segurança, conformidade regulatória e desempenho.

Você pode usar taints, tolerations, rótulos de nó, seletores de nó e afinidade de nó para restringir os pods dos locatários a serem executados somente 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 a Restrição de Área de Pod com base em Contêineres Kata.
  • 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 nos hosts dedicados do Azure que garantem que as VMs de nó do agente sejam executadas em 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 as cargas de trabalho do 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 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 oferecem suporte ao FIPS (Federal Information Process Standard), a CVM (Máquinas Virtuais Confidenciais) ou à criptografia baseada em host.

O isolamento de nó permite associar e estornar facilmente o custo de um conjunto de nós ou pool de nós a um único locatário. Está estritamente relacionado com o modelo de locação que é adotado pela sua solução.

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

Modelos de locação

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

Implantações automatizadas de locatário único

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

Diagrama mostrando três locatários, cada um dos quais com implantações diferentes.

Cada carga de trabalho do locatário é executada em um cluster do AKS dedicado e acessa um conjunto distinto de recursos do Azure. Geralmente, as soluções multilocatário criadas 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 dos clientes. Ao planejar sua implantação, considere usar o padrão de Selos de Implantação.

Benefícios:

  • Um dos principais benefícios dessa abordagem é que o Servidor de API de cada cluster do AKS de locatário é separado. Essa abordagem garante o isolamento total entre locatários a partir de um nível de segurança, de rede e de 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.
  • É pouco provável que os locatários afetem o desempenho do sistema uns dos outros, permitindo evitar o problema de Vizinho Barulhento. Essa consideração inclui o tráfego no Servidor de API. O servidor de API é um componente crítico compartilhado em qualquer cluster do Kubernetes. Controladores personalizados, que geram tráfego não regulamentado e de alto volume no servidor de API, podem causar instabilidade de cluster. Essa instabilidade leva a falhas de solicitação, tempos limite e storms de repetição de API. O recurso SLA de tempo de atividade permite expandir o plano de controle de um cluster do AKS para atender à demanda de tráfego. Ainda assim, o provisionamento de um cluster dedicado pode ser uma solução melhor para aqueles clientes que têm fortes requisitos em termos de isolamento de carga de trabalho.
  • Atualizações e alterações podem ser distribuídas progressivamente entre locatários, o que reduz a probabilidade de uma interrupção em todo o sistema. Os custos do Azure podem ser facilmente estornados para os locatários, pois cada recurso é usado por um único locatário.

Riscos:

  • A economia é baixa, pois cada locatário usa um conjunto dedicado de recursos.
  • A manutenção contínua provavelmente será demorada, pois precisa ser replicada em vários clusters do AKS, um para cada locatário. Considere automatizar os processos operacionais e aplicar as alterações progressivamente por meio de seus ambientes. Ajudaria se você também considerasse outras operações de implantação cruzada, como relatórios e análises em toda a propriedade. Da mesma forma, planeje como consultar e manipular dados em várias implantações.

Implantações totalmente multilocatário

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 do AKS. Nesse contexto, você tem apenas um conjunto de infraestrutura para implantar, monitorar e manter. Todos os locatários usam o recurso, conforme ilustrado no diagrama a seguir:

Diagrama mostrando três locatários, todos usando uma só implantação compartilhada.

Benefícios:

  • Esse 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 do AKS maior e adotar uma SKU mais alta para qualquer repositório de dados compartilhado para sustentar o tráfego gerado por recursos de todos os locatários, como repositórios de dados.

Riscos:

  • Nesse contexto, um único aplicativo lida com as solicitações de todos os 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 lento e afetar todos os locatários.
  • Se o perfil de tráfego for altamente variável, você deverá configurar o dimensionador automático de cluster do AKS para variar o número de pods e nós do agente. Baseie sua configuração no uso de recursos do sistema, como CPU e Memória. Como alternativa, você pode expandir e reduzir 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 proteções para evitar o 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 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, muitas vezes também é mais arriscado, já que qualquer alteração nos componentes de infraestrutura ou do aplicativo podem afetar toda a base de clientes.
  • Você também deve considerar as limitações de escala. É mais provável que você atinja os limites da escala dos recursos do Azure ao ter 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 particionar horizontalmente o 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 aplicativo Kubernetes multilocatário único e, depois, criar bancos de dados individuais, um para cada locatário, como mostrado nesta ilustração:

Diagrama mostrando três locatários, cada um usando um banco de dados dedicado e um único aplicativo Kubernetes compartilhado.

Benefícios:

  • As implantações particionadas horizontalmente podem ajudá-lo a atenuar o problemas do Vizinho Barulhento. Considere essa abordagem, se você tiver identificado que a maior parte da carga de tráfego em seu aplicativo Kubernetes se deve a componentes específicos, que poderão ser implantados separadamente, para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema, pois a carga de consulta é alta. Se um locatário enviar uma grande quantidade 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 os componentes compartilhados, como a camada de aplicativo) permanecerão inalterados.

Riscos:

  • Com uma implantação particionada horizontalmente, você ainda precisa considerar a implantação automatizada e o gerenciamento de seus componentes, em especial os componentes usados por um locatário individual.
  • 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 do AKS ou pools de nós. Essa abordagem oferece as seguintes vantagens em relação aos dois modelos de locação 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 do AKS e um banco de dados em uma infraestrutura multilocatário. Ainda assim, você também pode implantar infraestruturas de locatário único para aqueles clientes que exigem maior desempenho e isolamento.
  • Você pode implantar locatários em vários clusters do AKS regionais, potencialmente com configurações diferentes. Essa técnica é mais eficaz quando você tem locatários 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ário com diferentes níveis de funcionalidade a um custo diferente. Seu modelo de preços pode fornecer vários SKUs, cada um fornecendo um nível incremental de desempenho e isolamento, no que diz respeito a compartilhamento de recursos, desempenho, rede e segregação de dados. Considere as seguintes camadas:

  • Camada básica: as solicitações de locatário são atendidas por um aplicativo Kubernetes multilocatário único, que é 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 Básica.
  • Camada standard: 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 no que diz respeito à segurança, rede e consumo de recursos. Todos os aplicativos dos locatários, um para cada locatário, compartilham o mesmo cluster do AKS e o pool de nós com outros clientes de camada standard.
  • Camada premium: o aplicativo locatário é executado em um pool de nós dedicado ou cluster do AKS para garantir um contrato de nível de serviço mais alto, melhor desempenho e um grau mais alto 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 para o 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 do AKS compartilhado, enquanto o locatário C é executado em um cluster do AKS separado.

Diagrama mostrando três locatários. Os locatários A e B compartilham um cluster AKS. O locatário C tem um cluster AKS dedicado.

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.

Diagrama mostrando três locatários. Os locatários A e B compartilham um pool de nós. O locatário C tem um pool de nós dedicado.

Esse modelo também pode oferecer contratos de nível de serviço diferentes para diferentes camadas. Por exemplo, a camada básica pode oferecer 99,9% de tempo de atividade, a camada standard pode oferecer 99,95% de tempo de atividade e a camada premium pode oferecer 99,99%. O SLA (contrato de nível de serviço) mais alto pode ser implementado usando serviços e recursos que permitem destinos de disponibilidade mais altos.

Benefícios:

  • Como você ainda está compartilhando a infraestrutura, ainda pode obter alguns dos benefícios de custo de ter implantações multilocatário compartilhadas. Você pode implantar clusters e pools de nós que são compartilhados entre vários aplicativos locatários de camada básica e standard, que usam um tamanho de VM mais barato para nós de agente. Essa abordagem garante maior densidade e redução de custos. Para clientes de camada premium, você pode implantar clusters do AKS e pools de nós com um tamanho de VM maior e um número máximo de réplicas de pods e nós a um preço mais alto.
  • Você pode executar serviços do sistema, como CoreDNS, Konnectivity ou Controlador de Entrada do Gateway de Aplicativo do Azure, em um pool de nós de modo de sistema dedicado. Você pode usar taints, tolerations, rótulos de nó, seletores de nó 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 taints, tolerations, rótulos de nó, seletores de nó 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 do dimensionador automático e suporte a zonas de disponibilidade.

Riscos:

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

Dimensionamento automático

Para acompanhar a demanda de tráfego gerada pelos aplicativos locatários, você pode habilitar o dimensionador automático de cluster para dimensionar os nós do agente do seu Serviço de 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 ou períodos do ano específicos.
  • Locatário ou cargas pesadas compartilhadas 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 um 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 no que diz respeito à CPU e memória.

Da mesma forma, quando a carga diminui, o dimensionamento automático de cluster reduz o número de nós de agente em um pool de nós, com base nos limites especificados, ajudando 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 Dimensionador Automático de Pod Horizontal (HPA) dimensiona automaticamente o número de réplicas de pods, com base na utilização da CPU/memória ou nas 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 locatários durante as atualizações do cluster ou do pool de nós, agende a Manutenção Planejada do AKS fora dos horários de pico. A Manutenção Planejada permite que você agende janelas de manutenção semanais para atualizar o plano de controle dos clusters do AKS que executam aplicativos locatários e pools de nós, minimizando o impacto na carga de trabalho. Você pode agendar uma ou mais janelas de manutenção semanais em seu cluster especificando um intervalo de dias ou horas em um dia específico. Todas as operações de manutenção ocorrerão durante as janelas agendadas.

Segurança

Acesso ao cluster

Ao compartilhar um cluster do AKS entre várias equipes de uma organização, você precisa implementar o princípio de privilégio mínimo para isolar locatários diferentes uns dos outros. Especificamente, você precisará garantir que os usuários tenham acesso apenas aos namespaces e recursos do Kubernetes quando usam ferramentas, como kubectl, Helm, Flux, Argo CD, ou outros tipos.

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

Identidade da carga de trabalho

Se você hospedar vários aplicativos locatários em um único cluster do AKS e cada um estiver em um namespace separado, cada carga de trabalho deverá usar uma conta de serviço do Kubernetes e credenciais diferentes para acessar os serviços do Azure downstream. As contas de serviço são um dos tipos de usuários primários no Kubernetes. A API Kubernetes mantém e gerencia contas de serviço. As credenciais de contas de serviço são armazenadas como segredos do Kubernetes, o que permite que sejam utilizadas por pods autorizados para se comunicar com o servidor de API. A maioria das solicitações de API fornecem 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 nos clusters do AKS podem usar credenciais de aplicativo do Microsoft Entra para acessar recursos protegidos pelo Microsoft Entra ID, como o Azure Key Vault e o Microsoft Graph. A ID de Carga de Trabalho do Microsoft Entra para Kubernetes integra-se aos recursos nativos do Kubernetes para federar com quaisquer provedores de identidade externos.

Área restrita do pod

O AKS inclui um mecanismo chamado Restrição de Área de Pod que fornece um limite de isolamento entre o aplicativo de contêiner e o kernel compartilhado e recursos de computação do host de contêiner, como CPU, memória e rede. A Restrição de Área de Pod 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 regulatória, do setor ou de governança, como o PCI DSS (Payment Card Industry Data Security Standard), a Organização Internacional de Normalização (ISO) 27001 e a HIPAA (Health Insurance Portability and Accountability Act).

A implantação de aplicativos em clusters ou pools de nós separados permite isolar fortemente as cargas de trabalho do locatário 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 colocando DaemonSets e contêineres privilegiados no mesmo nó para comunicação local mais rápida e agrupamento funcional. A Restrição de Área de Pod pode ajudá-lo a isolar fortemente os aplicativos locatários nos mesmos nós de cluster sem precisar 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 a Restrição de Área de Pod no AKS pode executar qualquer contêiner não modificado dentro de um limite de VM de segurança aprimorada.

A Restrição de Área de Pod no AKS é baseada em Contêineres Kata que são executados no host de contêiner do Azure Linux para a pilha do AKS para fornecer isolamento imposto por hardware. Os Contêineres Kata no AKS são criados em um hipervisor do Azure protegido por segurança. O isolamento por pod é obtido por meio de uma VM Kata leve aninhada que utiliza recursos de um nó de VM pai. Nesse modelo, cada pod do Kata obtém seu próprio kernel em uma VM convidada do 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 limite de isolamento forte em um cluster do AKS compartilhado.

Para saber mais, veja:

Host Dedicado do Azure

O Host Dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma assinatura única do Azure e fornece isolamento de hardware no nível do servidor físico. Esses hosts dedicados podem ser provisionados em 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 AKS, incluindo o seguinte:

  • O isolamento de hardware garante que nenhuma outra VM seja colocada nos hosts dedicados, fornecendo uma camada adicional de isolamento para cargas de trabalho de locatário. Os hosts dedicados são implantados nos mesmos data centers e compartilham a mesma rede e a 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 locatários atendam aos requisitos de conformidade regulatória, do setor e de governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar o Host Dedicado do Azure a um cluster de AKS (Serviço de Kubernetes do Azure).

Máquinas virtuais confidenciais

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

FIPS (Federal Information Processing Standards)

O FIPS 140-3 é um padrão do governo dos EUA que define os requisitos mínimos de segurança para módulos de criptografia em sistemas e produtos de tecnologia da informação. Ao habilitar a conformidade do FIPS para pools de nós do AKS, você pode aprimorar o isolamento, a privacidade e a segurança das cargas de trabalho de seus locatários. A conformidade com o FIPS garante o uso de módulos criptográficos validados para criptografia, hash e outras operações relacionadas à segurança. Com pools de nós do 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 do AKS, permitindo que você fortaleça a postura de segurança de seus ambientes do AKS multilocatário. Para obter mais informações, consulte Habilitar FIPS para pools de nós do AKS.

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

O Armazenamento do Azure criptografa todos os dados em uma conta de armazenamento inativa, incluindo o sistema operacional e os discos de dados de um cluster do AKS. Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para ter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar na criptografia inativa do sistema operacional e dos discos de dados de seus clusters do AKS. Para saber mais, veja:

Criptografia baseada em host

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 os dados inativos 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 do sistema operacional efêmero 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 a criptografia 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 a criptografia de envelope, também conhecida como wrapping. O cache do sistema operacional e dos discos de dados também são criptografados por meio da 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 nos caches do sistema operacional e dos dados são criptografados inativos com chaves gerenciadas pelo cliente ou pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para saber mais, veja:

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 do AKS entre várias equipes de uma organização, proteja o acesso ao plano de controle usando uma das soluções a seguir.

Clusters privados do AKS

Ao usar um cluster privado do AKS, é possível garantir que o tráfego de rede entre o servidor de API e os seus pools de nós permaneça em sua rede virtual. Em um cluster do AKS privado, o plano de controle ou o servidor de API tem um endereço IP interno que só é acessível por meio de um ponto de extremidade privado do Azure, localizado na mesma rede virtual do cluster do 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, consulte Criar um cluster particular do Serviço de Kubernetes do Azure.

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 do AKS público a uma lista bem conhecida de endereços IP (Internet Protocol) e CIDR (Roteamento de domínio interno 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, confira Proteger acesso ao servidor de API usando intervalos de endereços IP autorizados no AKS (Serviço de Kubernetes do Azure).

O Serviço de Link Privado do Azure (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 (PE) privado do Azure que é definido em uma rede virtual e conectado à configuração de IP de front-end de uma instância do Azure Load Balancer (ALB). Com o Link Privado do Azure, 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 dos dados.

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

Para obter orientação geral sobre como configurar o Link Privado para uma solução multilocatário hospedada no Azure, consulte Multilocação e Link Privado do Azure.

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 proxies reversos populares oferecem suporte a recursos como balanceamento de carga, terminação SSL e roteamento de camada 7. Os proxies reversos geralmente são implementados para ajudar a aumentar a segurança, o desempenho e a confiabilidade. Os proxies reversos populares para o Kubernetes incluem as seguintes implementações:

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

  • Hospede o proxy reverso em um pool de nós dedicado que está configurado para usar um tamanho de VM com uma largura de banda de rede alta e rede acelerada habilitada.
  • Configure o pool de nós que está hospedando seu proxy reverso para dimensionamento automático.
  • Para evitar maior latência e 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 expandir e contrair instantaneamente para corresponder às flutuações de tráfego.
  • Considere fragmentar o tráfego de entrada para aplicativos locatários, em várias instâncias do controlador de entrada, a fim de aumentar o nível de escalabilidade e segregação.

Ao usar o Controlador de Entrada do Gateway de Aplicativo do Azure (AGIC), considere implementar as seguintes práticas recomendadas:

Integração com o Azure Front Door

O Azure Front Door é um balanceador de carga global de camada 7 e uma CDN (rede de distribuição de conteúdo) em nuvem moderna da Microsoft que fornece acesso rápido, confiável e seguro entre os usuários e aplicativos Web em todo o mundo. O Azure Front Door oferece suporte a 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 no AKS à Internet pública.

Por exemplo, talvez você queira usar um aplicativo multilocatário hospedado no 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 terminar as conexões SSL na borda e rotear todo o tráfego para o aplicativo multilocatário hospedado no AKS que está configurado com um único nome de host.

Diagrama que demonstra como o Azure Front Door e o AKS se conectam.

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 cabeçalho X-Forwarded-Host 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 Firewall de Aplicativo Web (WAF) do Azure, no Azure Front Door, fornece proteção centralizada para seus aplicativos Web. Você pode usar o WAF do Azure para defender aplicativos locatários 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 locatários executados em um cluster do AKS, por meio de uma origem interna do balanceador de carga, 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 Link Privado.

Conexões de saída

Quando aplicativos hospedados do AKS conectam a um grande número de bancos de dados ou serviços externos, o cluster pode correr o risco de esgotamento da porta SNAT. As Portas SNAT geram identificadores exclusivos que são usados para manter fluxos distintos iniciados por aplicativos executados no mesmo conjunto de recursos de computação. Ao executar vários aplicativos locatários em um cluster compartilhado do Serviço de Kubernetes do Azure (AKS), você pode fazer um alto número de chamadas de saída, o que pode levar ao esgotamento de uma porta SNAT. Um cluster do 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 Load Balancer de SKU Standard a ser configurado e usado para conexões de saída. No entanto, a configuração padrão poderá não cumprir os requisitos de todos os cenários, se IPs públicos não forem permitidos ou se saltos adicionais forem necessários para saída. Por padrão, o Load Balancer 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 SNAT (conversão de endereços de rede de origem) para um balanceador de carga de padrão público. Essa configuração permite que você use os IPs públicos do balanceador de carga para fornecer conectividade de saída para a Internet às 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 os endereços IP de front-end de um balanceador de carga para saída por meio de regras de saída.
  • Gateway da NAT do Azure: você pode configurar um cluster do AKS para usar o Gateway da NAT do Azure para rotear o tráfego de saída de aplicativos locatários. O Gateway da NAT do Azure permite até 64.512 fluxos de tráfego UDP e TCP de saída por endereço IP público, com no máximo 16 endereços IP. Para evitar o risco de esgotamento da porta SNAT ao usar um Gateway da NAT para manipular conexões de saída de um cluster do 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 de Gateway da NAT do Azure para multilocação.
  • UDR (Rota definida pelo usuário): você pode personalizar a rota de saída de um cluster do AKS para oferecer suporte a cenários de rede personalizados, como aqueles que não permitem IPs públicos e requerem que o cluster fique atrás de uma NVA (solução de virtualização de rede). Quando você configurar um cluster para roteamento definido pelo usuário, o AKS não configurará automaticamente os caminhos de saída. A configuração de saída deve ser feita por você. Por exemplo, você roteará o tráfego de saída por meio de um Firewall do Azure. O cluster do AKS deve ser implantado em uma rede virtual existente, com uma sub-rede que foi previamente configurada. Quando você não está usando uma arquitetura de balanceador de carga padrão (SLB), deve 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ço de rede (NAT) seja feita por um IP público atribuído ao balanceador de carga ou dispositivo padrão.

Monitoramento

Você pode usar o Azure Monitor e o Container Insights para monitorar aplicativos locatários executados em um cluster do AKS compartilhado e para calcular detalhamentos de custo em namespaces individuais. O Azure Monitor permite monitorar a integridade e o desempenho do Serviço de Kubernetes do Azure (AKS). Ele inclui a coleta de logs e métricas, análise de telemetria e visualizações de dados coletados, a fim de identificar tendências e configurar alertas para notificar de forma proativa os problemas críticos. É possível habilitar o Insights de Contêiner 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 os custos. No contexto do Kubernetes, há várias maneiras pelas quais as organizações podem controlar e otimizar os custos. Isso inclui ferramentas nativas do Kubernetes para gerenciar e controlar o uso e o consumo de recursos e 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 estornar taxas aos locatários depende do modelo de locação adotado pela sua solução. Mais detalhes são explicados com os seguintes modelos de locação:

  • Multilocatário completo: 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, você cobra seus clientes de acordo.
  • Cluster dedicado: quando um cluster é dedicado a um único locatário, é fácil estornar os custos dos recursos do Azure para o 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, os endereços IP públicos, os 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 do 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 dedicado: você pode aplicar uma marca do Azure a um pool de nós novo ou existente que é dedicado a um único locatário. As marcas aplicadas a um pool de nós são aplicadas a cada nó dentro do pool de nós e são mantidas por meio de atualizações. As tags também são aplicadas a novos nós adicionados a um pool de nós durante operações de expansão. A adição de uma marca pode ajudar com tarefas como rastreamento de política ou cobrança de custo. Para obter mais informações, consulte Adicionando marcas a pools de nós.
  • Outros recursos: você pode usar marcas para associar custos de recursos dedicados a um determinado locatário. Especificamente, você pode marcar IPs Públicos, arquivos e discos usando um manifesto do Kubernetes. As tags definidas dessa maneira manterão os valores do Kubernetes, mesmo que você os atualize posteriormente com outro método. Quando IPs públicos, arquivos ou discos 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 marcas usando Kubernetes.

Você pode usar ferramentas de código aberto, como KubeCost, para monitorar e controlar um custo de cluster do 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ê estorna ou justifica usuários do cluster. Para obter mais informações, consulte Governança de custo com Kubecost.

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

Colaboradores

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

Autor principal:

Outros colaboradores:

  • John Downs | Engenheiro de software principal
  • Ed Price | Gerente sênior de programa de conteúdo
  • Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
  • Bohdan Cherchyk | Engenheiro de Cliente Sênior da FastTrack para Azure

Próximas etapas

Examine os Recursos para arquitetos e desenvolvedores de soluções multilocatário.