Considerações do AKS (Serviço de Kubernetes do Azure) para multilocatário

AKS (Serviço de Kubernetes do Azure) simplifica a implantação de um cluster kubernetes gerenciado no Azure descarregando a sobrecarga operacional para a plataforma de nuvem do Azure. Como o AKS é um serviço do Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade e o plano de controle.

Os clusters do AKS podem ser compartilhados entre vários locatários de 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. O termo multilocatário frequentemente descreve todos esses tipos de compartilhamento. 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.

Este artigo descreve alguns dos recursos do AKS que você pode usar ao criar sistemas multilocatários. Para obter diretrizes gerais e práticas recomendadas para multilocatário do Kubernetes, consulte de vários locatários na documentação do Kubernetes.

Tipos de multilocação

A primeira etapa para determinar como compartilhar um cluster do AKS entre vários locatários é avaliar os padrões e as ferramentas disponíveis para uso. Em geral, a multilocatário em clusters kubernetes se enquadra em duas categorias principais, mas muitas variações ainda são possíveis. A documentação do Kubernetes descreve dois casos de uso comuns para multilocatário: várias equipes e vários clientes.

Várias equipes

Uma forma comum de multilocatário é 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ão hospedados no mesmo cluster ou estão em execução como serviços paaS (plataforma como serviço) 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, os membros têm acesso indireto por meio de controladores GitOps, como flux e de CD Argo, ou por meio 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 multilocatário frequentemente envolve um fornecedor saaS (software como serviço). Ou, um provedor de serviços executa várias instâncias de uma carga de trabalho, que são consideradas locatários separados, para seus clientes. Nesse cenário, os clientes não têm acesso direto ao cluster do AKS, mas só têm acesso ao aplicativo. Além disso, eles nem sabem que o aplicativo é executado no Kubernetes. A otimização de custo é frequentemente uma preocupação crítica. 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á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 geralmente são conhecidas como locatários . Essa definição inclui clusters do Kubernetes que diferentes equipes ou divisões compartilham em uma organização. Ele também contém clusters que são instâncias por cliente de um compartilhamento de aplicativos SaaS.

A multilocatário de cluster é uma alternativa para gerenciar muitos clusters dedicados de locatário único. Os operadores de um cluster Kubernetes multilocatário devem isolar 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, uma equipe pode usar mais do que seu compartilhamento justo de recursos. Os administradores podem usar cotas de recursos para resolver essa preocupação.

Com base no nível de segurança fornecido pelo isolamento, você pode distinguir entre multilocatário flexível e dura.

• A multilocatário flexível é adequada em uma única empresa 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 da carga de trabalho, orquestrar recursos de cluster em diferentes grupos de usuários internos e se defender contra possíveis ataques de segurança.
• A multilocatário dura descreve cenários em que locatários heterogêneos não confiam uns nos outros, muitas vezes de perspectivas de segurança e compartilhamento de recursos.

Quando você planeja criar um cluster do AKS multilocatário, deve considerar as camadas de isolamento de recursos e multilocatário que o Kubernetes fornece, incluindo:

• Cluster
• Namespace
• Pool ou nó de nós
• Vagem
• Recipiente

Além disso, você deve considerar as implicações de segurança do compartilhamento de recursos diferentes entre vários locatários. Por exemplo, você pode reduzir o número de computadores necessários no cluster agendando pods de diferentes locatários no mesmo nó. Por outro lado, talvez seja necessário impedir que cargas de trabalho específicas sejam agrupadas. Por exemplo, talvez você não permita que código não confiável de fora da sua organização seja executado no mesmo nó que 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 rbac (controle de acesso baseado em função) do Kubernetes e políticas de rede para impor o isolamento do locatário. Por exemplo, o diagrama a seguir mostra o modelo de provedor SaaS típico que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo reside em um namespace separado.

Há várias maneiras de projetar e criar soluções multilocatários com o 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 dados e controle, com base em seus requisitos.

Controlar o isolamento do plano

Se você tiver isolamento no nível do plano de controle, 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 podem afetar o desempenho dos aplicativos de outros locatários. Para obter mais informações, consulte o isolamento do plano de controle na documentação do Kubernetes. A melhor maneira de implementar o isolamento no nível do plano de controle é separar 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 que você usa para dar suporte ao isolamento de grupos de recursos em um único cluster. Você pode usar namespaces para isolar cargas de trabalho de locatário que compartilham um cluster do Kubernetes.

• Os namespaces permitem que cargas de trabalho de locatário distintas existam em seu próprio workspace 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 nomes sobrepostos.
• 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 de locatário para acessar recursos e serviços somente em seus namespaces. Equipes diferentes podem definir funções para agrupar listas de permissões ou habilidades em 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.
• Cotas de recursos para CPU e memória são objetos com espaçamento de nomes. O Teams pode 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 todos os aplicativos de locatário executados em um namespace separado têm os recursos necessários para serem executados e evitar problemas de vizinhos barulhentos, o que pode afetar outros aplicativos de locatário que compartilham o mesmo cluster.
• políticas de rede são objetos com espaçamento que as equipes podem adotar para impor qual tráfego de rede é permitido para um determinado aplicativo de locatário. Você pode usar políticas de rede para separar 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 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 isolamento no nível do namespace, consulte os seguintes recursos na documentação do Kubernetes:

• Namespaces
• controles Access
• cotas de

Isolamento do plano de dados

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

Isolamento de rede

Ao executar aplicativos modernos baseados em microsserviços no Kubernetes, você geralmente deseja controlar quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster do 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 separar as comunicações entre aplicativos de locatário que compartilham o mesmo cluster.

O AKS fornece duas maneiras de implementar políticas de rede:

• O Azure tem sua implementação para políticas de rede, chamadas de políticas de rede do Azure.
• de políticas de rede do Calico é uma solução de segurança de rede e rede de software livre fundada pelo Tigera.

Ambas as implementações usam iptables do Linux para impor as políticas especificadas. As políticas de rede são traduzidas em conjuntos de pares IP permitidos e não permitidos. Esses pares são programados como regras de filtro de iptables. Você só pode usar políticas de rede do Azure com clusters AKS configurados com o CNI do Azure plug-in de rede. No entanto, as políticas de rede calico dão suporte a de CNI do Azure e kubenet. Para obter mais informações, consulte Tráfego seguro entre pods que usam políticas de rede no Serviço de Kubernetes do Azure.

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

Isolamento de armazenamento

O Azure fornece um conjunto avançado de repositórios de dados paaS gerenciados, como banco de dados SQL do Azure e do 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 compartilhado do AKS podem compartilhar um banco de dados ou um repositório de arquivosou 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ários.

As cargas de trabalho executadas no AKS também podem usar volumes persistentes para armazenar dados. No Azure, você pode criar volumes persistentes como recursos do Kubernetes compatíveis com o Armazenamento do Azure. Você pode criar volumes de dados manualmente e atribuí-los diretamente aos pods ou 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 do Azure Disks, de Arquivos do Azure e suporte do Azure NetApp Files. Para obter mais informações, consulte Opções de armazenamento para aplicativos no AKS. Por motivos de segurança e resiliência, você deve evitar usar o armazenamento local em nós de agente por meio de emptyDir e hostPath.

Quando o AKS classes de armazenamento internas não são uma boa opção para um ou mais locatários, você pode criar classes de armazenamento personalizadas para atender aos requisitos de locatários diferentes. Esses requisitos incluem tamanho do volume, SKU de armazenamento, um SLA (contrato de nível de serviço), políticas de backup e o tipo 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 marcas a qualquer volume persistente criado em seu namespace para cobrar de volta seus custos a eles. Para obter mais informações, consulte Usar marcas do Azure no AKS.

Para obter mais informações, consulte de 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 para evitar problemas de vizinhos barulhentos 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 estritos para isolamento, segurança, conformidade regulatória e desempenho.

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

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

• No nível do kernel, executando cargas de trabalho de locatário em VMs (máquinas virtuais leves) em nós de agente compartilhado e usando de área restrita de pod com base emde contêineres kata .
• No nível físico, hospedando aplicativos de locatário em clusters dedicados ou pools de nós.
• No nível do hardware, executando cargas de trabalho de locatário em hosts dedicados do Azure que garantem que as VMs do nó do agente executem computadores físicos dedicados. O isolamento de hardware garante que nenhuma outra VM seja colocada nos hosts dedicados, o que fornece uma camada extra 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 Hosts Dedicados do Azure para alcançar a segregação de carga de trabalho e o isolamento físico no nível do hardware. Você também pode criar pools de nós compartilhados ou por locatário que dão suporte do FIPS (Federal Information Process Standard), de VMs confidenciais ou de criptografia baseada em host.

Use o isolamento de nó para associar e cobrar facilmente o custo de um conjunto de nós ou pool de nós a um único locatário. Ele está estritamente relacionado ao modelo de locação que é adotado pela sua solução.

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

Modelos de locação

O AKS fornece mais tipos de modelos de isolamento e locação 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, conforme ilustrado neste exemplo:

Cada carga de trabalho de locatário é executada em um cluster do AKS dedicado e acessa um conjunto distinto de recursos do Azure. Normalmente, soluções multilocatários criadas usando esse modelo fazem uso extensivo de de iac (infraestrutura como código). Por exemplo, Bicep, do Azure Resource Manager, Terraformou as APIs REST do Azure Resource Manager ajudar 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 seus clientes. Ao planejar sua implantação, considere usar o padrão de selos de implantação .

Benefícios do :

• 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 de um nível de segurança, rede e consumo de recursos. Um invasor que consegue obter o controle de um contêiner só tem 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, portanto, você evita problemas barulhentos do vizinho. Essa consideração inclui o tráfego no servidor de API. O servidor de API é um componente compartilhado e crítico em qualquer cluster do 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 novas tentativas de API. Use o recurso SLA de tempo de atividade para escalar horizontalmente 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 os clientes com requisitos fortes em termos de isolamento de carga de trabalho.
• Você pode distribuir atualizações e alterações 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 porque cada recurso é usado por um único locatário.

Riscos :

• A eficiência de custo é baixa porque cada locatário usa um conjunto dedicado de recursos.
• É provável que a manutenção contínua seja demorada porque você precisa repetir as atividades de manutenção em vários clusters do AKS, um para cada locatário. Considere automatizar seus processos operacionais e aplicar alterações progressivamente por meio de seus ambientes. Outras operações de implantação cruzada, como relatórios e análises em toda a sua propriedade, também podem ser úteis. Verifique se você planeja como consultar e manipular dados em várias implantações.

Implantações totalmente multilocatários

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 uma infraestrutura para implantar, monitorar e manter. Todos os locatários usam o recurso, conforme ilustrado no diagrama a seguir:

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 aks maior e adotar uma SKU mais alta para qualquer repositório de dados compartilhado. Essas alterações ajudam a sustentar o tráfego que todos os recursos de locatários, como repositórios de dados, geram.

riscos:

• Nesse contexto, um único aplicativo manipula todas as solicitações dos locatários. Você deve projetar e implementar medidas de segurança para evitar que os locatários inundam o aplicativo com chamadas. Essas chamadas podem diminuir a velocidade de todo o sistema 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 escalar horizontalmente e dimensionar o número de pods e nós de cluster com base em métricas personalizadas. Por exemplo, você pode usar o número de solicitações pendentes ou as métricas de um sistema de mensagens externo que usa KEDA (Dimensionador Automático Controlado por Eventos) baseado em Kubernetes.
• Certifique-se de separar os dados de cada locatário e implementar proteções para evitar vazamento de dados entre locatários diferentes.
• Certifique-se de acompanhar e associar os custos do Azure a locatários individuais, com base em seu uso real. Soluções que não são da Microsoft, 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 porque você só precisa atualizar um conjunto de recursos do Azure e manter um único aplicativo. No entanto, também pode ser mais arriscado porque qualquer alteração na infraestrutura ou nos componentes do aplicativo pode 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 distribuir seus locatários em várias assinaturas do Azure.

Implantações particionadas horizontalmente

Como alternativa, você pode considerar o particionamento horizontal do aplicativo Kubernetes multilocatário. Essa abordagem compartilha alguns componentes da solução em todos os locatários e implanta 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 do :

• Implantações particionadas horizontalmente podem ajudá-lo a atenuar problemas de vizinhos barulhentos. Considere essa abordagem se você identificar que a maior parte da carga de tráfego em seu aplicativo Kubernetes é devido a componentes específicos, que você pode implantar separadamente, para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema porque a carga da 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 e componentes compartilhados de outros locatários, 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, especialmente os componentes que um único locatário usa.
• Esse modelo pode não fornecer o nível de isolamento necessário para clientes que não podem compartilhar recursos com outros locatários por motivos internos de política ou 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 locatários em vários clusters ou pools de nós do AKS. Essa abordagem fornece 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 dos seus clientes compartilhe um cluster do AKS e um banco de dados em uma infraestrutura multilocatário. 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 regionais do AKS, 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 camadas de funcionalidade a um custo diferente. Seu modelo de preços pode fornecer vários SKUs que fornecem um nível incremental de desempenho e isolamento em termos de 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 único aplicativo Kubernetes multilocatário compartilhado com outros locatários. Os dados são armazenados em um ou mais bancos de dados que todos os locatários de camada básica compartilham.
• Camada padrão: as solicitações de locatário 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 e pool de nós do AKS com outros clientes de camada padrão.
• Camada Premium: o aplicativo de locatário é executado em um pool de nós dedicado ou cluster do AKS para garantir um SLA mais alto, um 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 que hospedam o aplicativo de locatário. Você pode usar o Pod Sandboxing como uma solução alternativa para clusters dedicados ou pools de nós para isolar cargas de trabalho de locatário distintas.

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

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 SLAs diferentes para diferentes camadas. Por exemplo, a camada básica pode oferecer 99,9% tempo de atividade, a camada padrão pode oferecer 99,95% tempo de atividade e a camada premium pode oferecer 99,99% tempo de atividade. Você pode implementar o SLA mais alto usando serviços e recursos que permitem destinos de disponibilidade mais altos.

Benefícios do :

• Como você ainda está compartilhando a infraestrutura, ainda pode obter alguns dos benefícios de custo de ter implantações multilocatários compartilhadas. Você pode implantar clusters e pools de nós compartilhados em 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. Essa abordagem garante uma melhor densidade e economia de custos. Para clientes de camada premium, você pode implantar clusters e pools de nós do AKS com um tamanho de VM maior e um número máximo de réplicas e nós de pod a um preço mais alto.
• Você pode executar serviços do sistema, como CoreDNS, konnectivityou do Controlador de Entrada do Gateway de Aplicativo do Azure, em um pool de nós dedicado do modo de sistema. Você pode usar , tolerâncias, rótulos de nós, seletores de nó e de afinidade de nó para executar um aplicativo de locatário em um ou mais pools de nós no modo de usuário.
• Você pode usar , tolerâncias, rótulos de nós, seletores de nó e de 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 que tenha 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 dar suporte a implantações multilocatários 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 sua própria implantação de locatário único.
• Você precisa de uma estratégia consistente e um único painel de vidro, ou 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 de locatário, você pode habilitar o de dimensionamento automático de cluster para dimensionar os nós do agente do 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 específicos do ano.
• Cargas pesadas compartilhadas ou de locatário são implantadas em um cluster.
• Os nós do agente ficam indisponíveis devido a interrupções de uma zona de disponibilidade.

Ao habilitar o dimensionamento automático para um pool de nós, especifique 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 impedir que os pods entrem em um estado pendente devido à escassez de recursos, como CPU e memória.

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. HorizontalPodAutoscaler dimensiona automaticamente o número de réplicas de pod com base na utilização de CPU ou memória ou métricas personalizadas. Usando 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 os aplicativos de locatário usam.

VPA (Dimensionador Automático de Pod Vertical) habilita o gerenciamento eficiente de recursos para pods. Ajustando a CPU e a memória alocadas para pods, a VPA ajuda você a reduzir o número de nós necessários para executar aplicativos de locatário. Ter menos nós reduz o custo total de propriedade e ajuda você a evitar problemas barulhentos de vizinhos.

Atribua grupos de reserva de capacidade a pools de nós para fornecer melhor alocação de recursos e isolamento para locatários diferentes.

Manutenção

Para reduzir o risco de tempo de inatividade que pode afetar aplicativos de locatário durante as atualizações do pool de clusters ou nós, agende o AKS de manutenção planejada durante o horário de pico. Agende janelas de manutenção semanais para atualizar o plano de controle dos clusters do AKS que executam aplicativos de locatário e pools de nós para minimizar 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 ocorrem durante as janelas agendadas.

Segurança

As seções a seguir descrevem as melhores práticas de segurança para soluções multilocatários com o AKS.

Acesso ao cluster

Ao compartilhar um cluster do AKS entre várias equipes dentro de uma organização, você precisa implementar o princípio de privilégios mínimos para isolar locatários diferentes uns dos outros. Em particular, você precisa garantir que os usuários tenham acesso apenas a seus namespaces e recursos do Kubernetes ao usar ferramentas como kubectl, Helm, flux ou cd do Argo.

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

• opções de acesso e identidade para do AKS
• de integração do Microsoft Entra gerenciada pelo AKS
• controle de acesso baseado em função do Kubernetes com a ID do Microsoft Entra no AKS

Identidade da carga de trabalho

Se você hospedar vários aplicativos de locatário em um único cluster do AKS e cada aplicativo estiver em um namespace separado, cada carga de trabalho deverá usar um conta de serviço do Kubernetes diferente e credenciais 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, portanto, os pods autorizados podem usá-las 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 que você implanta em clusters do AKS podem usar as credenciais do aplicativo Microsoft Entra para acessar recursos protegidos pela ID do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. 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 de pod

O AKS inclui um mecanismo chamado de Área Restrita de Pod que fornece um limite de isolamento entre o aplicativo contêiner e os recursos compartilhados de kernel e computação do host de 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 de locatário a proteger informações confidenciais e atender aos requisitos de conformidade regulatória, do setor ou de governança, como PCI DSS (Payment Card Industry Data Security Standard), ISO (International Organization for Standardization) 27001 e HIPAA (Health Insurance Portability And Accountability Act).

Ao implantar aplicativos em clusters ou pools de nós separados, você pode isolar fortemente as cargas de trabalho de 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, você pode usar um único cluster ao executar pods não confiáveis e não confiáveis no mesmo nó ou colocar DaemonSets e contêineres privilegiados no mesmo nó para comunicação local mais rápida e agrupamento funcional. o Pod Sandboxing pode ajudá-lo a isolar fortemente os aplicativos de 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 não modificado dentro de um limite de VM de segurança aprimorado.

O Pod Sandboxing no AKS baseia-se no contêineres kata que são executados no host de contêiner do Linux do Azure para a pilha de do AKS para fornecer isolamento imposto por hardware. Os contêineres kata no AKS são criados em um hipervisor do Azure protegido pela segurança. Ele obtém isolamento por pod por meio de uma VM Kata aninhada e leve 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. Use esse modelo para colocar muitos contêineres Kata em uma única VM convidada enquanto continua a executar contêineres na VM pai. Esse modelo fornece um limite de isolamento forte em um cluster compartilhado do AKS.

Para obter mais informações, consulte:

• área restrita de pod com do AKS
• suporte para contêineres isolados de VM kata no AKS para de área restrita de pod

Host Dedicado do Azure

host dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure e fornecem isolamento de hardware no nível do servidor físico. Você pode provisionar esses hosts dedicados em uma região, zona de disponibilidade e domínio de falha e pode colocar VMs diretamente nos hosts provisionados.

Há vários benefícios em usar o Host Dedicado do Azure com o AKS, incluindo:

• O isolamento de hardware garante que nenhuma outra VM seja colocada nos hosts dedicados, o que fornece uma camada extra 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 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 do 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 de 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 da governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar o Host Dedicado do Azure a um cluster do AKS.

Karpenter

o Karpenter é um projeto de gerenciamento de ciclo de vida de nó de software livre criado para o Kubernetes. Adicionar o Karpenter a um cluster do Kubernetes pode melhorar a eficiência e o custo de execução de cargas de trabalho nesse cluster. O Karpenter observa os pods que o agendador do Kubernetes marca como não programáveis. Ele também provisiona e gerencia dinamicamente nós que podem atender aos requisitos do pod.

O Karpenter fornece controle refinado sobre o provisionamento de nós e o posicionamento da carga de trabalho em um cluster gerenciado. Esse controle melhora a multilocatário otimizando a alocação de recursos, garantindo o isolamento entre os aplicativos de cada locatário e reduzindo os custos operacionais. Quando você cria uma solução multilocatário no AKS, o Karpenter fornece recursos úteis para ajudá-lo a gerenciar diversos requisitos de aplicativo para dar suporte a diferentes locatários. Por exemplo, talvez seja necessário que alguns aplicativos de locatários sejam executados em pools de nós com otimização de GPU e outros para serem executados em pools de nós com otimização de memória. Se o aplicativo exigir baixa latência para armazenamento, você poderá usar o Karpenter para indicar que um pod requer um nó executado em uma zona de disponibilidade específica para que você possa colocar seu armazenamento e camada de aplicativo.

O AKS habilita o provisionamento automático de nós em clusters do AKS por meio do Karpenter. A maioria dos usuários deve usar o modo de provisionamento automático do nó para habilitar o Karpenter como um complemento gerenciado. Para obter mais informações, consulte de provisionamento automático de nós. Se você precisar de personalização mais avançada, poderá optar por hospedar o Karpenter automaticamente. Para obter mais informações, consulte o provedor AKS Karpenter.

VMs confidenciais

Você pode usar de VMs 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. VMs confidenciais usar um ambiente de execução confiável baseado em hardware. AMD Secure Encrypted Virtualization – Proteção de Paginação Aninhada (SEV-SNP) VMs confidenciais negam o hipervisor e outro acesso de código de gerenciamento de host à memória e ao estado da VM, o que adiciona uma camada de proteção de defesa e proteção detalhada contra o acesso do operador. Para obter mais informações, consulte Usar VMs confidenciais em um cluster do AKS.

Padrões do Processo de Informações Federais (FIPS)

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 conformidade fips para pools de nós do AKS, você pode aprimorar o isolamento, a privacidade e a segurança das cargas de trabalho de locatário. conformidade de 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, o que permite fortalecer a postura de segurança de seus ambientes multilocatários do AKS. Para obter mais informações, consulte Habilitar o FIPS para pools de nós do AKS.

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

O Armazenamento do Azure criptografa todos os dados em uma conta de armazenamento em repouso, 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 obter mais controle sobre chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia em repouso do sistema operacional e discos de dados de seus clusters do AKS. Para obter mais informações, consulte:

• BYOK com discos do Azure no AKS.
• criptografia do lado do servidor do Armazenamento de Disco do Azure.

Criptografia baseada em host

de 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 nos computadores host subjacentes, o que ajuda a garantir que as informações confidenciais do locatário estejam protegidas contra acesso não autorizado. Discos temporários e discos de so efêmeros são criptografados em repouso com chaves gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta.

No AKS, os discos de dados e do sistema operacional 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 para criptografar a chave de proteção de dados usando criptografia de envelope, também conhecida como encapsulamento. O cache para o sistema operacional e os 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ários. Os dados de cada locatário nos caches de sistema operacional e de disco de dados são criptografados em repouso com chaves gerenciadas pelo cliente ou gerenciadas pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para obter mais informações, consulte:

• criptografia baseada em host no do AKS
• BYOK com discos do Azure no AKS
• criptografia do lado do servidor do Armazenamento de Disco do Azure

Rede

As seções a seguir descrevem as melhores práticas de rede para soluções multilocatários com o AKS.

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

Clusters privados do AKS

Usando um cluster do AKS privado, você pode garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça dentro da rede virtual. Em um cluster privado do AKS, o plano de controle ou o servidor de API tem um endereço IP interno que só pode ser acessado por meio de um de ponto de extremidade privado do Azure, que está localizado na mesma rede virtual do cluster do AKS. Da mesma forma, qualquer máquina virtual na mesma rede virtual pode se comunicar privadamente com o plano de controle por meio do ponto de extremidade privado. Para obter mais informações, consulte Criar um cluster do AKS privado.

Intervalos de endereços IP autorizados

A segunda opção para melhorar a segurança do cluster e minimizar ataques é usar intervalos de endereços IP autorizados. Essa abordagem restringe o acesso ao plano de controle de um cluster público do AKS a uma lista conhecida de endereços IP e intervalos CIDR (roteamento de Inter-Domain sem classe). Quando você usa endereços IP autorizados, eles ainda são expostos publicamente, mas o acesso é limitado a um conjunto de intervalos. Para obter mais informações, consulte Acesso seguro ao servidor de API usando intervalos de endereços IP autorizados no AKS.

Integração de Link Privado

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

Você pode usar de integração de serviço de Link Privado para fornecer aos locatários conectividade privada às cargas de trabalho hospedadas pelo AKS de forma segura, sem a necessidade de expor nenhum ponto de extremidade público na Internet pública.

Para obter mais informações sobre como você pode configurar o Link Privado para uma solução multilocatário hospedada no Azure, consulte Multilocatário e Link Privado.

Proxies reversos

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

• controlador de entrada NGINX é um servidor proxy reverso popular que dá suporte a recursos avançados, como balanceamento de carga, terminação SSL e roteamento de camada 7.
• provedor de entrada do Kubernetes traefik é um controlador de entrada do Kubernetes que pode ser usado para gerenciar o acesso aos serviços de cluster dando suporte à especificação de entrada.
• controlador de entrada haproxy kubernetes é mais um proxy reverso para Kubernetes, que dá suporte a recursos padrão, como terminação TLS, roteamento baseado em caminho de URL e muito mais.
• do AGIC (Controlador de Entrada do Gateway de Aplicativo do Azure) é um aplicativo do Kubernetes, o que possibilita que os clientes do AKS usem um Gateway de Aplicativo nativo do Azure balanceador de carga L7 para expor aplicativos de locatário à Internet pública ou internamente a outros sistemas executados em uma rede virtual.

Ao usar um proxy reverso hospedado pelo AKS para ajudar a 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 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 de locatário, 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 de locatário, em várias instâncias do controlador de entrada, para aumentar o nível de escalabilidade e segregação.

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

• Configure o gateway de aplicativo que o controlador de entrada usa para de dimensionamento automático. Com o dimensionamento automático habilitado, as SKUs do gateway de aplicativo e do FIREWALL do aplicativo Web (WAF) v2 são dimensionadas ou in, com base nos requisitos de tráfego do aplicativo. Esse modo fornece 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 ajuda você a economizar em custos, não exigindo que o gateway seja executado em 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 implantar várias instâncias do AGIC, cada uma associada a um gateway de aplicativo separado, quando o número de aplicativos de locatário exceder a quantidade máxima de de sites. Supondo que cada aplicativo de locatário seja executado em um namespace dedicado, use suporte a vários namespaces para espalhar aplicativos de locatário em mais instâncias dodo AGIC .

Integração com o Azure Front Door

Azure Front Door é um balanceador de carga global de camada 7 e uma CDN (rede de distribuição de conteúdo de nuvem) moderna 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 dá suporte a recursos como aceleração de solicitação, encerramento de SSL, cache de resposta, WAF na borda, roteamento baseado em URL, regravação e redirecionamentos que você pode usar ao expor aplicativos multilocatários hospedados pelo AKS à Internet pública.

Por exemplo, talvez você queira 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 as 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 de host de origem da solicitação para corresponder ao nome de domínio do aplicativo de back-end. O cabeçalho de Host original enviado pelo cliente é propagado por meio 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.

do Firewall do Aplicativo Web do Azure, no Azure Front Door, fornece proteção centralizada para aplicativos Web. O Firewall do Aplicativo Web do Azure pode ajudá-lo a 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 privadamente a um ou mais aplicativos de locatário executados em um cluster do AKS, por meio de uma origem interna do balanceador de carga, usando link privado. Para obter mais informações, consulte Conectar o Azure Front Door Premium a uma origem interna do balanceador de carga com o Link Privado.

Conexões de saída

Quando 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 (conversão de endereço de rede de origem). portas SNAT gerar identificadores exclusivos que são usados para manter fluxos distintos que os aplicativos executados no mesmo conjunto de recursos de computação iniciam. Ao executar vários aplicativos de locatário em um cluster compartilhado do 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 do AKS pode lidar com conexões de saída de três maneiras diferentes:

• ado Azure 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 pode não atender aos requisitos de todos os cenários se os endereços IP públicos não forem permitidos ou se forem necessários saltos extras para saída. Por padrão, o balanceador de carga público é criado com um endereço IP público padrão que as regras de saída usar. As regras de saída permitem definir explicitamente o SNAT para um balanceador de carga padrão público. Essa configuração permite que você use os endereços IP públicos do balanceador de carga para fornecer conectividade de saída com a Internet para suas instâncias de back-end. Quando necessário, para evitar de esgotamento da porta SNAT, você pode configurar as regras de saída do balanceador de carga público para usar mais endereços IP públicos. Para obter mais informações, consulte Usar o endereço IP de front-end de um balanceador de carga para saída por meio de regras de saída.
• o Gateway de NAT do Azure: você pode configurar um cluster do AKS para usar o Gateway de NAT do Azure para rotear o tráfego de saída de aplicativos de locatário. O Gateway nat 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 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 do Gateway NAT do Azure parade multilocatário.
• UDR (rota definida pelo usuário): você pode personalizar a rota de saída de um cluster do AKS para dar suporte a cenários de rede personalizados, como aqueles que não permitem endereços IP públicos e exigem que o cluster fique atrás de um NVA (dispositivo virtual de rede). Quando você configura um cluster para de roteamento definido pelo usuário, o AKS não configura automaticamente caminhos de saída. Você deve concluir a configuração de saída. Por exemplo, você roteia o tráfego de saída por meio de umado Firewall do Azure . Você deve implantar o cluster do AKS em uma rede virtual existente com uma sub-rede configurada anteriormente. Quando você não estiver usando uma arquitetura de balanceador de carga padrão, deverá estabelecer saída explícita. Dessa forma, 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 NAT (conversão de endereços de rede) seja feita por um IP público atribuído ao balanceador de carga ou dispositivo padrão.

Monitorização

Você pode usar do Azure Monitor e insights de contêiner para monitorar aplicativos de locatário executados em um cluster compartilhado do AKS e calcular divisões de custos em namespaces individuais. Use o Azure Monitor para monitorar a integridade e o desempenho do AKS. Ele inclui a coleção de logs e métricas, análise de telemetria e visualizações de dados coletados para identificar tendências e configurar alertas que notificam você proativamente sobre problemas críticos. Você pode habilitar de insights de contêiner para expandir esse monitoramento.

Você também pode adotar ferramentas de software livre, como prometheus e grafana, que são amplamente usados para monitoramento do Kubernetes. Ou você pode adotar outras ferramentas que não são da Microsoft 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ários métodos que as organizações podem usar para controlar e otimizar os custos. Esses métodos incluem o uso de 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 cobrar taxas de volta aos locatários depende do modelo de locação que sua solução adota. A lista a seguir descreve os modelos de locação com mais detalhes:

• Totalmente multilocatário: quando um único aplicativo multilocatário atende a todas as solicitações de locatário, é sua responsabilidade controlar o consumo de recursos e o número de solicitações geradas por cada locatário. Em seguida, você cobra seus clientes adequadamente.
• Cluster dedicado: quando um cluster é dedicado a um único locatário, é fácil cobrar os custos dos recursos do Azure de volta para o cliente. O custo total de propriedade depende de muitos fatores, incluindo o número e o tamanho das VMs, os custos de rede do tráfego de rede, endereços IP públicos, balanceadores de carga e os serviços de armazenamento, como discos gerenciados ou arquivos do Azure que a solução de locatário usa. Você pode marcar um cluster do AKS e seus recursos no grupo de recursos do nó para facilitar as operações de carregamento 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 dedicado a um único locatário. As marcas são aplicadas a cada nó dentro do pool de nós e são mantidas por meio de atualizações. As marcas 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 marca pode ajudar com tarefas como acompanhamento de políticas ou cobrança de custos. Para obter mais informações, consulte Adicionar marcas a pools de nós.
• Outros recursos: você pode usar marcas para associar custos de recursos dedicados a um determinado locatário. Em particular, você pode marcar endereços IP públicos, arquivos e discos usando um manifesto do Kubernetes. As marcas definidas dessa forma mantêm os valores do Kubernetes, mesmo se você atualizá-los mais tarde usando outro método. Quando endereços IP públicos, arquivos ou discos são removidos por meio do Kubernetes, todas as marcas que os conjuntos do Kubernetes são removidas. As marcas nos recursos que o Kubernetes não rastreia permanecem não afetadas. Para obter mais informações, consulte Adicionar marcas usando o Kubernetes.

Você pode usar ferramentas de software livre, como kubeCost, para monitorar e controlar o custo de um cluster do AKS. Você pode definir o escopo da alocação de custos para uma implantação, serviço, rótulo, pod e namespace, o que oferece flexibilidade na forma como você cobra de volta ou mostra os usuários de volta do cluster. Para obter mais informações, consulte Governança de custos com o Kubecost.

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

Governança

Quando vários locatários compartilham a mesma infraestrutura, o gerenciamento de privacidade, conformidade e requisitos regulatórios de dados pode se tornar complicado. Você precisa implementar medidas de segurança fortes e políticas de governança de dados. Os clusters compartilhados do AKS apresentam um risco maior de violações de dados, acesso não autorizado e não conformidade com regulamentos de proteção de dados. Cada locatário pode ter requisitos de governança de dados exclusivos e políticas de conformidade, o que dificulta a segurança e a privacidade dos dados.

o Microsoft Defender para Contêineres é uma solução de segurança de contêiner nativa de nuvem que fornece recursos de detecção e proteção de ameaças para ambientes do Kubernetes. Usando o Defender para Contêineres, você pode aprimorar sua postura de conformidade e governança de dados ao hospedar vários locatários em um cluster do Kubernetes. Use o Defender para Contêineres para ajudar a proteger dados confidenciais, detectar e responder a ameaças analisando o comportamento do contêiner e o tráfego de rede e atender aos requisitos regulatórios. Ele fornece recursos de auditoria, gerenciamento de logs e geração de relatórios para demonstrar a conformidade com reguladores e auditores.

Contribuintes

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

Autor principal:

• Paolo Salvatori | Engenheiro de cliente principal

Outros colaboradores:

• Bohdan Cherchyk | Engenheiro sênior de clientes
• John Downs | Engenheiro de Software Principal
• Chad Kittel | Engenheiro de Software Principal
• Arsen Vladimirskiy | Engenheiro de cliente principal

Recurso relacionado

• Recursos para arquitetos e desenvolvedores de soluções multilocatários