do Serviço Kubernetes do Azure (AKS) simplifica a implantação de um cluster Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para a plataforma de nuvem do Azure. Como o AKS é um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade e o plano de controle.
Os clusters AKS podem ser compartilhados entre vários locatários em diferentes cenários e maneiras. Em alguns casos, diversos aplicativos podem ser executados no mesmo cluster. Em outros casos, várias instâncias do mesmo aplicativo podem ser executadas no mesmo cluster compartilhado, uma para cada locatário. O termo multilocação 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ário. Para obter orientações gerais e práticas recomendadas para multilocação do Kubernetes, consulte de multilocação na documentação do Kubernetes.
Tipos de multilocação
A primeira etapa para determinar como compartilhar um cluster AKS entre vários locatários é avaliar os padrões e as ferramentas disponíveis para uso. Em geral, a multilocação em clusters do Kubernetes se enquadra em duas categorias principais, mas muitas variações ainda são possíveis. O de documentação do Kubernetes
Várias equipas
Uma forma comum de multilocação é compartilhar um cluster entre várias equipes dentro de uma organização. Cada equipe pode implantar, monitorar e operar uma ou mais soluções. Essas cargas de trabalho frequentemente precisam se comunicar entre si e com outros aplicativos internos ou externos localizados no mesmo cluster ou em outras plataformas de hospedagem.
Além disso, essas cargas de trabalho precisam se comunicar com serviços, como um banco de dados relacional, um repositório NoSQL ou um sistema de mensagens, que estão hospedados no mesmo cluster ou estão sendo executados como serviços de plataforma como serviço (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, os membros têm acesso indireto através de controladores GitOps, como Flux e Argo CD, ou através de outros tipos de ferramentas de automação de versão.
Para obter mais informações sobre esse cenário, consulte de várias equipes na documentação do Kubernetes.
Vários clientes
Outra forma comum de multilocação frequentemente envolve um fornecedor de software como serviço (SaaS). Ou, um provedor de serviços executa várias instâncias de uma carga de trabalho, que são consideradas locatários separados, para seus clientes. Nesse cenário, os clientes não têm acesso direto ao cluster AKS, mas só têm acesso ao seu aplicativo. Além disso, eles nem sabem que seu aplicativo é executado no Kubernetes. A otimização de custos é frequentemente uma preocupação crítica. Os provedores de serviços usam políticas do Kubernetes, como cotas de recursos e diretivas de rede, para garantir que as cargas de trabalho sejam fortemente isoladas umas das outras.
Para obter mais informações sobre esse cenário, consulte de vários clientes na documentação do Kubernetes.
Modelos de isolamento
De acordo com ode documentação do
A multilocação de cluster é uma alternativa ao gerenciamento de muitos clusters dedicados de locatário único. Os operadores de um cluster Kubernetes multilocatário devem isolar os locatários uns dos outros. Esse isolamento minimiza os danos que um locatário comprometido ou mal-intencionado pode causar ao cluster e a outros locatários.
Quando vários usuários ou equipes compartilham o mesmo cluster com um número fixo de nós, uma equipe pode usar mais do que sua justa parcela de recursos. Os administradores podem usar de cotas de recursos para resolver essa preocupação.
Com base no nível de segurança que o isolamento oferece, você pode distinguir entre multilocação flexível e multilocação rígida.
- A multilocação suave é adequada dentro de uma única empresa, onde os locatários são equipes ou departamentos diferentes que confiam uns nos outros. Nesse cenário, o isolamento visa garantir a integridade 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 multilocação rígida descreve cenários em que locatários heterogêneos não confiam uns nos outros, muitas vezes do ponto de vista da segurança e do compartilhamento de recursos.
Ao planejar a criação de um cluster AKS multilocatário, você deve considerar as camadas de isolamento de recursos e multilocação que Kubernetes fornece, incluindo:
- Aglomeração
- Espaço de nomes
- Pool de nós ou nó
- Pod
- Contentor
Além disso, você deve considerar as implicações de segurança do compartilhamento de diferentes recursos entre vários locatários. Por exemplo, você pode reduzir o número de máquinas necessárias 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 colocadas. Por exemplo, você pode não permitir que códigos não confiáveis de fora da sua organização sejam executados no mesmo nó que os contêineres que processam informações confidenciais.
Embora o Kubernetes não possa garantir um isolamento perfeitamente seguro entre locatários, ele oferece recursos que podem ser suficientes para casos de uso específicos. Como prática recomendada, você deve separar cada locatário e seus recursos do Kubernetes em seus namespaces. Em seguida, você pode usar de controle de acesso baseado em função (RBAC) do Kubernetes e diretivas de rede para impor o isolamento do locatário. Por exemplo, o diagrama a seguir mostra o modelo típico de provedor SaaS que hospeda várias instâncias do mesmo aplicativo no mesmo cluster, uma para cada locatário. Cada aplicativo vive em um namespace separado.
Há várias maneiras de projetar e construir soluções multilocatárias 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 controle e dados, com base em suas necessidades.
Isolamento do plano de controlo
Se você tiver isolamento no nível do plano de controle, você garante que locatários diferentes não possam acessar ou afetar os recursos uns dos outros, como pods e serviços. Além disso, eles não podem afetar o desempenho dos aplicativos de outros locatários. Para obter mais informações, consulte de 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 o
- Os namespaces permitem que cargas de trabalho de locatários distintas existam em seu próprio espaço de trabalho virtual, sem o risco de afetar o trabalho uns dos outros. Equipes separadas dentro de uma organização podem usar namespaces para isolar seus projetos uns dos outros, pois podem usar os mesmos nomes de recursos em namespaces diferentes sem o risco de sobreposição de nomes.
- funções RBAC e as associações de função são recursos com escopo de namespace que as equipes podem usar para limitar usuários e processos locatários para acessar recursos e serviços somente em seus namespaces. Equipes diferentes podem definir funções para agrupar listas de permissões ou habilidades sob um único nome. Em seguida, eles atribuem essas funções a contas de usuário e contas de serviço para garantir que apenas as identidades autorizadas tenham acesso aos recursos em um determinado namespace.
- As cotas de recursos para CPU e memória são objetos namespaced. As equipes podem usá-los para garantir que as cargas de trabalho que compartilham o mesmo cluster sejam fortemente isoladas do consumo de recursos do sistema. Esse método pode garantir que cada aplicativo locatário executado em um namespace separado tenha os recursos necessários para ser executado e evitar problemas de vizinhos barulhentos, que podem afetar outros aplicativos de locatário que compartilham o mesmo cluster.
- de políticas de rede são objetos namespaced que as equipes podem adotar para impor qual tráfego de rede é permitido para um determinado aplicativo locatário. Você pode usar políticas de rede para segregar cargas de trabalho distintas que compartilham o mesmo cluster de uma perspetiva de rede.
- Os aplicativos de equipe executados em namespaces distintos podem usar diferentes contas de serviço para acessar recursos dentro do mesmo cluster, aplicativos externos ou serviços gerenciados.
- Use namespaces para melhorar o desempenho no nível do plano de controle. Se as cargas de trabalho em um cluster compartilhado forem organizadas em vários namespaces, a API do Kubernetes terá menos itens para pesquisar ao executar operações. Essa organização pode reduzir a latência de chamadas no servidor de API e aumentar a taxa de transferência do plano de controle.
Para obter mais informações sobre isolamento no nível de 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 uns dos outros. Para obter mais informações, consulte de isolamento do plano de dados na documentação do Kubernetes.
Isolamento de rede
Quando você executa aplicativos modernos baseados em microsserviços no Kubernetes, geralmente deseja controlar quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster AKS podem enviar e receber tráfego sem restrições, incluindo outros aplicativos que compartilham o mesmo cluster. Para melhorar a segurança, você pode definir regras de rede para controlar o fluxo de tráfego. A política de rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre pods. Você pode usar políticas de rede para segregar comunicações entre aplicativos locatários 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 políticas de rede do Azure.
- Calico network policies é uma solução de segurança de rede e rede de código aberto fundada por Tigera.
Ambas as implementações usam Linux iptables para impor as políticas especificadas. As políticas de rede são convertidas em conjuntos de pares IP permitidos e não permitidos. Esses pares são então programados como regras de filtro iptables. Você só pode usar políticas de rede do Azure com clusters AKS configurados com o plug-in de rede CNI do
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 do 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 AKS compartilhado podem compartilhar um banco de dados ou armazenamento de arquivosou podem usar um repositório de dados dedicado e umde recursos de armazenamento. Para obter mais informações sobre diferentes estratégias e abordagens para gerenciar dados em um cenário multilocatário, consulte Abordagens arquitetônicas para armazenamento e dados em soluções multilocatárias.
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 que o Armazenamento do Azure suporta. Você pode criar manualmente volumes de dados e atribuí-los a pods diretamente, ou pode fazer com que o AKS os crie automaticamente usando declarações de volume persistentes. O AKS fornece classes de armazenamento internas para criar volumes persistentes que o Azure Disks, Azure Filese Azure NetApp Files suporte. 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 o uso de armazenamento local em nós de agente por meio emptyDir e hostPath.
Quando o AKS classes de armazenamento integradas 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 diferentes locatários. Esses requisitos incluem tamanho do volume, SKU de armazenamento, um contrato de nível de serviço (SLA), políticas de backup e o nível de preço.
Por exemplo, você pode configurar uma classe de armazenamento personalizada para cada locatário. Em seguida, você pode usá-lo para aplicar tags a qualquer volume persistente criado em seu namespace para cobrar de volta seus custos. Para obter mais informações, consulte Usar marcas do Azure no AKS.
Para obter mais informações, consulte de isolamento de armazenamento na documentação do Kubernetes.
Isolamento do nó
Você pode configurar cargas de trabalho de locatário para serem executadas em nós de agente separados para evitar 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 rigorosos de isolamento, segurança, conformidade regulatória e desempenho.
Você pode usar manchas, tolerações, rótulos de nó, seletores de nóe de afinidade de nó para restringir os pods dos locatários a serem executados apenas em um conjunto específico de nós ou pools de nós.
Em geral, o AKS fornece isolamento de carga de trabalho em vários níveis, incluindo:
- No nível do kernel, executando cargas de trabalho de locatário em máquinas virtuais (VMs) leves em nós de agente compartilhado e usando de Sandboxing de Pod com base em Kata Containers.
- No nível físico, hospedando aplicativos locatários em clusters dedicados ou pools de nós.
- No nível de hardware, executando cargas de trabalho de locatário em hosts dedicados que garantem que as VMs do nó do agente executem máquinas físicas dedicadas. 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 de grupo de Host Dedicado do
Use o isolamento de nós para associar e cobrar facilmente o custo de um conjunto de nós ou pool de nós para um único locatário. Está estritamente relacionado com o modelo de arrendamento que é adotado pela sua solução.
Para obter mais informações, consulte isolamento de nó na documentação do Kubernetes.
Modelos de arrendamento
O AKS fornece mais tipos de isolamento de nó e modelos de locação.
Implantações automatizadas de locatário único
Em um modelo automatizado de implantação de locatário único, você implanta um conjunto dedicado de recursos para cada locatário, conforme ilustrado neste exemplo:
Cada carga de trabalho de locatário é executada em um cluster AKS dedicado e acessa um conjunto distinto de recursos do Azure. Normalmente, as soluções multilocatárias que você cria usando esse modelo fazem uso extensivo de infraestrutura como código (IaC). Por exemplo, Bicep, 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 de seus clientes. Ao planejar sua implantação, considere usar o padrão Deployment stamps.
Benefícios:
- Um dos principais benefícios dessa abordagem é que o Servidor de API de cada cluster AKS de locatário é separado. Essa abordagem garante o isolamento total entre os locatários de um nível de segurança, rede e consumo de recursos. Um invasor que consegue obter o controle de um contêiner só 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 de vizinhos barulhentos. Essa consideração inclui o tráfego no Servidor de API. O servidor de API é um componente compartilhado e crítico em qualquer cluster Kubernetes. Os controladores personalizados, que geram tráfego não regulamentado e de alto volume no servidor de API, podem causar instabilidade no cluster. Essa instabilidade leva a falhas de solicitação, tempos limite e tempestades de repetição de API. Use o recurso de SLA de tempo de atividade para dimensionar o plano de controle de um cluster AKS para atender à demanda de tráfego. Ainda assim, o provisionamento de um cluster dedicado pode ser uma solução melhor para os clientes com fortes requisitos em termos de isolamento da carga de trabalho.
- Você pode implantar 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 custos é 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 AKS, um para cada locatário. Considere automatizar seus processos operacionais e aplicar mudanças progressivamente em seus ambientes. Outras operações de implantação cruzada, como relatórios e análises em todo o seu patrimônio, também podem ser úteis. Certifique-se de planejar como consultar e manipular dados em várias implantações.
Implantações totalmente multilocatárias
Em uma implantação totalmente multilocatário, um único aplicativo atende às solicitações de todos os locatários e todos os recursos do Azure são compartilhados, incluindo o cluster AKS. Nesse contexto, você só tem uma infraestrutura para implantar, monitorar e manter. Todos os locatários usam o recurso, conforme ilustrado no diagrama a seguir:
Benefícios:
- Este modelo é atraente devido ao menor custo de operação de uma solução com componentes compartilhados. Ao usar esse modelo de locação, talvez seja necessário implantar um cluster AKS maior e adotar uma SKU mais alta para qualquer repositório de dados compartilhado. Essas alterações ajudam a sustentar o tráfego que todos os recursos dos locatários, como repositórios de dados, geram.
Riscos:
- Nesse contexto, um único aplicativo lida com todas as solicitações dos locatários. Você deve projetar e implementar medidas de segurança para evitar que os locatários inundem o aplicativo com chamadas. Estas chamadas podem tornar todo o sistema mais lento e afetar todos os inquilinos.
- Se o perfil de tráfego for altamente variável, você deve configurar o autoscaler de cluster AKS para variar o número de pods e nós de agente. Baseie sua configuração no uso de recursos do sistema, como CPU e memória. Como alternativa, você pode expandir e dimensionar o número de pods e nós de cluster com base em métricas personalizadas. Por exemplo, você pode usar o número de solicitações pendentes ou as métricas de um sistema de mensagens externo que usa KEDA (Event Driven Autoscaler) baseado em Kubernetes.
- Certifique-se de separar os dados de cada locatário e implementar salvaguardas para evitar vazamento de dados entre locatários diferentes.
- Certifique-se de controlar e associar os custos do Azure a locatários individuais, com base em seu uso real. Soluções que não sejam da Microsoft, como kubecost, podem ajudá-lo a calcular e dividir os custos em 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 quaisquer alterações na infraestrutura ou nos componentes do aplicativo podem afetar toda a base de clientes.
- Você também deve considerar limitações de escala. É mais provável que você atinja os limites de escala de recursos do Azure quando tiver um conjunto compartilhado de recursos. Para evitar atingir um limite de cota de recursos, você pode distribuir seus locatários em várias assinaturas do Azure.
Implantações particionadas horizontalmente
Como alternativa, você pode considerar o particionamento horizontal de seu aplicativo Kubernetes multilocatário. Essa abordagem 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:
- Implantações particionadas horizontalmente podem ajudá-lo a mitigar problemas de vizinhos barulhentos. Considere essa abordagem se identificar que a maior parte da carga de tráfego em seu aplicativo Kubernetes se deve a componentes específicos, que podem ser implantados separadamente, para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema porque a carga de consulta é alta. Se um único locatário enviar um grande número de solicitações para sua solução, o desempenho de um banco de dados poderá ser afetado negativamente, mas os bancos de dados 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 e o gerenciamento automatizados 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 de política interna 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 os locatários em vários clusters AKS ou pools de nós. Esta abordagem oferece as seguintes vantagens em relação aos dois modelos de arrendamento anteriores:
- Você pode usar uma combinação de implantações de locatário único e multilocatário. Por exemplo, você pode fazer com que a maioria de seus clientes compartilhe um cluster AKS e um banco de dados em uma infraestrutura multilocatário. Você também pode implantar infraestruturas de locatário único para os clientes que exigem maior desempenho e isolamento.
- Você pode implantar locatários em vários clusters AKS regionais, potencialmente com configurações diferentes. Esta técnica é mais eficaz quando tem inquilinos espalhados por diferentes geografias.
Você pode implementar diferentes variações desse modelo de locação. Por exemplo, você pode optar por oferecer sua solução multilocatária com diferentes níveis de funcionalidade a um custo diferente. Seu modelo de preços pode fornecer várias SKUs que fornecem um nível incremental de desempenho e isolamento em termos de compartilhamento de recursos, desempenho, rede e segregação de dados. Considere os seguintes níveis:
- Nível básico: as solicitações de locatário são atendidas por um único aplicativo Kubernetes multilocatário compartilhado com outros locatários. Os dados são armazenados em um ou mais bancos de dados que todos os locatários da 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 AKS e pool de nós com outros clientes de camada padrão.
- Nível premium: o aplicativo locatário é executado em um pool de nós dedicado ou cluster AKS para garantir um SLA mais alto, melhor desempenho e um maior grau de isolamento. Essa camada pode fornecer um modelo de custo flexível com base no número e na SKU dos nós do agente que hospedam o aplicativo 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ários distintas.
O diagrama a seguir mostra um cenário em que os locatários A e B são executados em um cluster AKS compartilhado, enquanto o locatário C é executado em um cluster AKS separado.
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.
Este modelo também pode oferecer diferentes SLAs para diferentes níveis. Por exemplo, o nível básico pode oferecer 99,9% de tempo de atividade, o nível padrão pode oferecer 99,95% de tempo de atividade e o nível premium pode oferecer 99,99% de tempo de atividade. Você pode implementar o SLA mais alto usando serviços e recursos que permitem destinos de disponibilidade mais altos.
Benefícios:
- Como você ainda está compartilhando infraestrutura, ainda pode obter alguns dos benefícios de custo de ter implantações multilocatárias compartilhadas. Você pode implantar clusters e pools de nós que são compartilhados entre vários aplicativos de locatário de camada básica e de camada padrão, que usam um tamanho de VM mais barato para nós de agente. Esta abordagem garante uma melhor densidade e poupança de custos. Para clientes de nível premium, você pode implantar clusters AKS e pools de nós com um tamanho de VM maior e um número máximo de réplicas de pod e nós a um preço mais alto.
- Você pode executar serviços do sistema, como CoreDNS, Konnectivityou Azure Application Gateway Ingress Controller, em um pool de nós dedicado no modo de sistema. Você pode usar manchas, tolerações, rótulos de nó, seletores de nóe de 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 de manchas, tolerações, rótulos de nó, 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 dedicados 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 oferecer suporte a implantações multilocatárias e de locatário único.
- Se você planeja permitir a migração entre infraestruturas, precisa considerar como migrar os clientes de uma implantação multilocatária para sua própria implantação de locatário único.
- Você precisa de uma estratégia consistente e um único painel de vidro, ou um ponto de vista, para monitorar e gerenciar mais clusters AKS.
Dimensionamento automático
Para acompanhar a demanda de tráfego que os aplicativos de locatário geram, você pode habilitar o autoscaler de cluster
- A carga de tráfego aumenta durante horas de trabalho específicas ou períodos do ano.
- Cargas pesadas compartilhadas ou locatárias são implantadas em um cluster.
- Os nós do agente ficam indisponíveis devido a interrupções de uma zona de disponibilidade.
Ao habilitar o dimensionamento automático para um pool de nós, você especifica um número mínimo e máximo de nós com base nos tamanhos de carga de trabalho esperados. Ao configurar um número máximo de nós, você pode garantir espaço suficiente para todos os pods de locatário no cluster, independentemente do namespace em que eles são executados.
Quando o tráfego aumenta, o dimensionamento automático do cluster adiciona novos nós de agente para evitar que os pods entrem em um estado pendente devido à escassez de recursos, 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 da CPU ou da memória ou em métricas personalizadas. Usando KEDA, você pode direcionar o dimensionamento de qualquer contêiner no Kubernetes com base no número de eventos de sistemas externos, como de Hubs de Eventos do Azure ou do Barramento de Serviço do Azure , que os aplicativos locatários usam.
Vertical Pod Autoscaler (VPA) permite um gerenciamento eficiente de recursos para pods. Ao ajustar a CPU e a memória alocada aos pods, o VPA ajuda 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 a evitar problemas de vizinhos barulhentos.
Atribua grupos de reserva de capacidade a pools de nós para fornecer melhor alocação de recursos e isolamento para diferentes locatários.
Manutenção
Para reduzir o risco de tempo de inatividade que pode afetar os aplicativos do locatário durante atualizações de cluster ou pool de nós, agende o AKS de manutenção planejada fora do horário de pico. Agende janelas de manutenção semanais para atualizar o plano de controle dos clusters AKS que executam aplicativos de locatário e pools de nós 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 programadas.
Segurança
As seções a seguir descrevem as práticas recomendadas de segurança para soluções multilocatárias com o AKS.
Acesso ao cluster
Quando você compartilha um cluster AKS entre várias equipes dentro de uma organização, você precisa implementar o princípio de menor privilégio para isolar diferentes locatários uns dos outros. Em particular, você precisa garantir que os usuários tenham acesso apenas aos seus namespaces e recursos do Kubernetes ao usar ferramentas como kubectl, Helm, Fluxou Argo CD.
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 o AKS
- de integração do Microsoft Entra gerenciado pelo AKS
- controle de acesso baseado em função do Kubernetes com o Microsoft Entra ID no AKS
Identidade da carga de trabalho
Se você hospedar vários aplicativos de locatário em um único cluster AKS e cada aplicativo estiver em um namespace separado, cada carga de trabalho deverá usar um e credenciais de conta de serviço
As cargas de trabalho de locatário que você implanta em clusters AKS podem usar credenciais de aplicativo do Microsoft Entra para acessar recursos protegidos por ID do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. ID de carga de trabalho do Microsoft Entra para Kubernetes integra-se com os recursos nativos do Kubernetes para federar com quaisquer provedores de identidade externos.
Pod Sandboxing
O AKS inclui um mecanismo chamado Pod Sandboxing que fornece um limite de isolamento entre o aplicativo de contêiner e o kernel compartilhado e os recursos de computação do host do contêiner, como CPU, memória e rede. O Pod Sandboxing complementa outras medidas de segurança ou controles de proteção de dados para ajudar as cargas de trabalho do locatário a proteger informações confidenciais e atender aos requisitos de conformidade regulamentar, do setor ou de governança, como o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), a Organização Internacional de Padronização (ISO) 27001 e a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA).
Ao implantar aplicativos em clusters ou pools de nós separados, você pode isolar fortemente as cargas de trabalho de locatários de diferentes equipes ou clientes. O uso de vários clusters e pools de nós pode ser adequado para os requisitos de isolamento de muitas organizações e soluções SaaS, mas há cenários em que um único cluster com pools de nós de VM compartilhados é mais eficiente. Por exemplo, você pode usar um único cluster quando executa pods não confiáveis e confiáveis no mesmo nó ou colocalizar DaemonSets e contêineres privilegiados no mesmo nó para uma comunicação local e agrupamento funcional mais rápidos. de Sandboxing de Pod pode ajudá-lo a isolar fortemente os aplicativos locatários nos mesmos nós de cluster sem a necessidade de executar essas cargas de trabalho em clusters ou pools de nós separados. Outros métodos exigem que você recompile seu código ou cause outros problemas de compatibilidade, mas o Pod Sandboxing no AKS pode executar qualquer contêiner sem modificações dentro de um limite de VM de segurança aprimorada.
O Pod Sandboxing no AKS é baseado em Kata Containers que são executados no host de contêiner 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 com segurança reforçada. Ele alcança o 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. Este modelo fornece um forte limite de isolamento em um cluster AKS compartilhado.
Para mais informações, consulte:
Host Dedicado do Azure
de Host Dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure e fornece isolamento de hardware no nível do servidor físico. Você pode provisionar esses hosts dedicados dentro de 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 mesma infraestrutura de armazenamento subjacente que outros hosts não isolados.
O Host Dedicado do Azure fornece controle sobre os eventos de manutenção que a plataforma do Azure inicia. Você pode escolher uma janela de manutenção para reduzir o impacto nos serviços e ajudar a garantir a disponibilidade e a privacidade das cargas de trabalho do locatário.
O Host Dedicado do Azure pode ajudar os provedores de SaaS a garantir que os aplicativos de locatário atendam aos requisitos de conformidade regulamentar, do setor e de governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar Host Dedicado do Azure a um cluster AKS.
Karpenter
Karpenter é um projeto de gerenciamento do ciclo de vida do nó de código aberto criado para o Kubernetes. Adicionar o Karpenter a um cluster do Kubernetes pode melhorar a eficiência e o custo da execução de cargas de trabalho nesse cluster. Karpenter observa os pods que o agendador do Kubernetes marca como não escaloná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 multilocação 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ária no AKS, a Karpenter fornece recursos úteis para ajudá-lo a gerenciar diversos requisitos de aplicativos para oferecer suporte a diferentes locatários. Por exemplo, você pode precisar que alguns aplicativos de locatários sejam executados em pools de nós otimizados para GPU e outros para serem executados em pools de nós otimizados para memória. Se seu aplicativo requer baixa latência para armazenamento, você pode usar Karpenter para indicar que um pod requer um nó que é executado em uma zona de disponibilidade específica para que você possa colocalizar seu armazenamento e camada de aplicativo.
O AKS permite o provisionamento automático de nós em clusters AKS via 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ó . Se você precisar de uma personalização mais avançada, você pode optar por auto-hospedar Karpenter. Para obter mais informações, consulte o provedor AKS Karpenter.
VMs confidenciais
Você pode usar VMs confidenciais para adicionar um ou mais pools de nós ao cluster AKS para atender aos requisitos estritos de isolamento, privacidade e segurança dos locatários. VMs confidenciais usar um ambiente de execução baseado em hardware confiável. AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) VMs confidenciais negam o acesso do hipervisor e de outro código de gerenciamento de host à memória e ao estado da VM, o que adiciona uma camada de defesa e proteção aprofundada contra o acesso do operador. Para obter mais informações, consulte Usar VMs confidenciais em um cluster AKS.
Normas Federais de Processo de Informação (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 AKS, você pode melhorar o isolamento, a privacidade e a segurança de suas cargas de trabalho de locatário. conformidade com FIPS garante o uso de módulos criptográficos validados para criptografia, hashing e outras operações relacionadas à segurança. Com pools de nós AKS habilitados para FIPS, você pode atender aos requisitos de conformidade regulatória e do setor empregando algoritmos e mecanismos criptográficos robustos. O Azure fornece documentação sobre como habilitar o FIPS para pools de nós AKS, o que permite fortalecer a postura de segurança de seus ambientes AKS multilocatário. Para obter mais informações, consulte Habilitar FIPS para pools de nós AKS.
Traga suas próprias chaves (BYOK) com discos do Azure
O Armazenamento do Azure encripta todos os dados numa conta de armazenamento em repouso, incluindo o SO e os discos de dados de um cluster AKS. Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia no restante do sistema operacional e discos de dados de seus clusters AKS. Para mais informações, consulte:
- BYOK com discos do Azure no AKS.
- Criptografia do lado do servidor do Armazenamento em 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 nas máquinas host subjacentes, o que ajuda a garantir que as informações confidenciais do locatário sejam protegidas contra acesso não autorizado. Discos temporários e discos efêmeros do sistema operacional são criptografados em repouso com chaves gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta.
No AKS, o sistema operacional e os discos de dados usam criptografia do lado do servidor com chaves gerenciadas pela plataforma por padrão. Os caches desses discos são criptografados em repouso com chaves gerenciadas pela plataforma. Você pode especificar sua própria chave de criptografia de chave
A criptografia baseada em host adiciona uma camada de segurança para ambientes multilocatário. Os dados de cada locatário no sistema operacional e nos caches de disco de dados são criptografados em repouso com chaves gerenciadas pelo cliente ou pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para mais informações, consulte:
- Criptografia baseada em host no AKS
- BYOK com discos do Azure no AKS
- Criptografia do lado do servidor do Azure Disk Storage
Ligação em rede
As seções a seguir descrevem as práticas recomendadas de rede para soluções multilocatárias 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. Quando você compartilha um cluster AKS entre várias equipes dentro de uma organização, proteja o acesso ao plano de controle usando uma das seguintes soluções.
Clusters privados do AKS
Usando um cluster AKS privado, você pode garantir que o tráfego de rede entre seu servidor de API e seus pools de nós permaneça em sua rede virtual. Em um cluster AKS privado, o plano de controle ou servidor de API tem um endereço IP interno que só é acessível por meio de umde ponto de extremidade privado do
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 AKS público a uma lista bem conhecida de endereços IP e intervalos CIDR (Classless Inter-Domain Routing). 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
Você pode usar de integração do serviço Private Link para fornecer aos locatários conectividade privada para suas cargas de trabalho hospedadas pelo AKS de forma segura, sem a necessidade de expor qualquer ponto de extremidade público na Internet pública.
Para obter mais informações sobre como configurar o Private Link para uma solução multilocatária hospedada no Azure, consulte Multilocação e Link Privado.
Proxies reversos
Um de proxy reverso
- NGINX Ingress Controller é um popular servidor proxy reverso que suporta recursos avançados, como balanceamento de carga, terminação SSL e roteamento de camada 7.
- de provedor de ingresso do Kubernetes Traefik é um controlador de ingresso do Kubernetes que pode ser usado para gerenciar o acesso a serviços de cluster suportando a especificação de entrada.
- HAProxy Kubernetes Ingress Controller é mais um proxy reverso para Kubernetes, que suporta recursos padrão, como terminação TLS, roteamento baseado em caminho de URL e muito mais.
do Azure Application Gateway Ingress Controller (AGIC) é um aplicativo Kubernetes, que possibilita que os clientes AKS usem um balanceador de carga L7 Application Gateway nativo do Azure para expor aplicativos locatários à Internet pública ou internamente a outros sistemas executados em uma rede virtual.
Quando você usa 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 dedicados configurado para usar um tamanho de VM com alta largura de banda de rede e rede acelerada habilitada.
- Configure o pool de nós que está hospedando seu proxy reverso para dimensionamento automático.
- Para evitar o aumento da latência e dos tempos limite para aplicativos locatários, defina uma política de dimensionamento automático para que o número de pods do controlador de entrada possa ser expandido e contratado instantaneamente para corresponder às flutuações de tráfego.
- Considere fragmentar o tráfego de entrada para aplicativos de locatário, em várias instâncias do controlador de entrada, para aumentar o nível de escalabilidade e segregação.
Ao usar oAGIC (Controlador de Ingresso do Gateway de Aplicativo do Azure) do
- 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 de aplicativo Web (WAF) v2 são dimensionadas ou aumentadas, 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 a economizar custos, não exigindo que o gateway seja executado na capacidade provisionada de pico para a carga máxima de tráfego esperada. Você deve especificar uma contagem mínima (e, opcionalmente, máxima) de instâncias.
- Considere a implantação de várias instâncias do AGIC, cada uma associada a um gateway de aplicativo separado, quando o número de aplicativos locatários exceder a quantidade máxima de sites. Supondo que cada aplicativo locatário seja executado em um namespace dedicado, use de suporte a vários namespaces para distribuir aplicativos de locatário por mais instâncias do AGIC.
Integração com o Azure Front Door
Azure Front Door é um balanceador de carga global de camada 7 e uma moderna rede de entrega de conteúdo em nuvem (CDN) da Microsoft que fornece acesso rápido, confiável e seguro entre usuários e aplicativos Web em todo o mundo. O Azure Front Door suporta recursos como aceleração de solicitação, terminação SSL, cache de resposta, WAF na borda, roteamento baseado em URL, regravação e redirecionamentos que você pode usar quando expõe aplicativos multilocatários hospedados pelo AKS à Internet pública.
Por exemplo, você pode querer usar um aplicativo multilocatário hospedado pelo AKS para atender a todas as solicitações dos clientes. Nesse contexto, você pode usar o Azure Front Door para gerenciar vários domínios personalizados, um para cada locatário. Você pode encerrar conexões SSL na borda e rotear todo o tráfego para o aplicativo multilocatário hospedado pelo AKS configurado com um único nome de host.
Você pode configurar o Azure Front Door para modificar o cabeçalho do host de origem da solicitação para corresponder ao nome de domínio do aplicativo de back-end. O cabeçalho Host original 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 ode locatário correto.
Azure Web Application Firewall, no Azure Front Door, fornece proteção centralizada para aplicativos Web. O Azure Web Application Firewall 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 de forma privada a um ou mais aplicativos de locatário executados em um cluster AKS, por meio de uma origem de balanceador de carga interno, usando Private Link. Para obter mais informações, consulte conectar o Azure Front Door Premium a uma origem de balanceador de carga interno com o Private Link.
Conexões de saída
Quando os aplicativos hospedados pelo AKS se conectam a um grande número de bancos de dados ou serviços externos, o cluster pode estar em risco de esgotamento da porta SNAT (conversão de endereços 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 AKS compartilhado, você pode fazer um grande número de chamadas de saída, o que pode levar a um esgotamento da porta SNAT. Um cluster AKS pode lidar com conexões de saída de três maneiras diferentes:
- Azure Load Balancer: Por padrão, o AKS provisiona um Balanceador de Carga SKU Standard para ser configurado e usado para conexões de saída. No entanto, a configuração padrão pode não atender aos requisitos de todos os cenários se os endereços IP públicos não forem permitidos ou se forem necessários saltos extras para a 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 que você defina 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 seu balanceador de carga para fornecer conectividade de saída à 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 front-end de um balanceador de carga para saída por meio de regras de saída.
- Azure NAT Gateway: Você pode configurar um cluster AKS para usar o Gateway NAT do Azure para rotear o tráfego de saída de aplicativos de locatário. O NAT Gateway permite até 64.512 fluxos de tráfego UDP e TCP de saída por endereço IP público, com um máximo de 16 endereços IP. Para evitar o risco de esgotamento da porta SNAT quando você usa um gateway NAT para lidar com conexões de saída de um cluster AKS, você pode associar mais endereços IP públicos ou um prefixo de endereço IP público ao gateway. Para obter mais informações, consulte Considerações sobre o Gateway NAT do Azure para multilocação.
-
Rota definida pelo usuário (UDR): Você pode personalizar a rota de saída de um cluster AKS para oferecer suporte a cenários de rede personalizados, como aqueles que não permitem endereços IP públicos e exigem que o cluster fique atrás de um dispositivo virtual de rede (NVA). Quando você configura um cluster para de roteamento definido pelo usuário, o AKS não configura automaticamente os 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 umdo Firewall do
Azure . Você deve implantar o cluster AKS em uma rede virtual existente com uma sub-rede que você configurou anteriormente. Quando você não estiver usando uma arquitetura de balanceador de carga padrão, deverá estabelecer uma saída explícita. Como tal, essa arquitetura requer o envio explícito de tráfego de saída para um dispositivo, como um firewall, gateway ou proxy. Ou, a arquitetura permite que a conversão de endereços de rede (NAT) seja feita por um IP público atribuído ao balanceador de carga ou dispositivo padrão.
Monitorização
Você pode usar do Azure Monitor e de informações de contêiner para monitorar aplicativos de locatário que são executados em um cluster AKS compartilhado e para calcular detalhamentos de custo em namespaces individuais. Use o Azure Monitor para monitorar a integridade e o desempenho do AKS. Ele inclui a coleta de logs de e métricas, análise de telemetria e visualizações de dados coletados para identificar tendências e configurar alertas que notificam proativamente sobre problemas críticos. Você pode habilitar informações 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 para monitoramento do Kubernetes. Ou, você pode adotar outras ferramentas que não sejam da Microsoft para monitoramento e observabilidade.
Custos
A governança de custos é o processo contínuo de implementação de políticas para controlar custos. No contexto do Kubernetes, existem vários métodos que as organizações podem usar para controlar e otimizar custos. Esses métodos incluem o uso de ferramentas nativas do Kubernetes para gerenciar e controlar o uso e o consumo de recursos e para monitorar e otimizar proativamente a infraestrutura subjacente. Ao calcular os custos por locatário, você deve considerar os custos associados a qualquer recurso usado por um aplicativo locatário. A abordagem que você segue para cobrar taxas de volta aos inquilinos 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 do locatário, é sua responsabilidade acompanhar o consumo de recursos e o número de solicitações geradas por cada locatário. Em seguida, cobra aos seus clientes em conformidade.
- Cluster dedicado: quando um cluster é dedicado a um único locatário, é fácil cobrar os custos dos recursos do Azure de volta ao cliente. O custo total de propriedade depende de muitos fatores, 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 locatária usa. Você pode marcar um cluster AKS e seus recursos no grupo de recursos do nó para facilitar as operações de cobrança de custos. Para obter mais informações, consulte Adicionar marcas ao cluster.
- Pool de nós dedicados: você pode aplicar uma marca do Azure a um pool de nós novo ou existente dedicado a um único locatário. As tags são aplicadas a cada nó dentro do pool de nós e persistem por meio de atualizações. As tags também são aplicadas a novos nós que são adicionados a um pool de nós durante operações de expansão. Adicionar uma tag pode ajudar em tarefas como controle de políticas ou cobrança de custos. Para obter mais informações, consulte Adicionando tags a pools de nós.
- Outros recursos: você pode usar tags para associar custos de recursos dedicados a um determinado locatário. Em particular, você pode marcar endereços IP públicos, arquivos e discos usando um manifesto do Kubernetes. As tags definidas dessa forma mantêm os valores do Kubernetes, mesmo que você os atualize posteriormente usando outro método. Quando endereços IP públicos, arquivos ou discos são removidos através do Kubernetes, todas as tags definidas pelo Kubernetes são removidas. As tags em recursos que o Kubernetes não rastreia permanecem inalteradas. Para obter mais informações, consulte Adicionar tags usando o Kubernetes.
Você pode usar ferramentas de código aberto, como KubeCost, para monitorar e controlar o custo de um cluster AKS. Você pode definir o escopo de alocação de custos para uma implantação, serviço, rótulo, pod e namespace, o que lhe dá flexibilidade na forma como você cobra ou mostra de volta os usuários do cluster. Para obter mais informações, consulte Governança de custos com Kubecost.
Para obter mais informações sobre a medição, alocação e otimização de custos para um aplicativo multilocatário, consulte Abordagens arquitetônicas para gerenciamento e alocação de custos em uma solução multilocatária. Para obter orientações gerais sobre otimização de custos, consulte o artigo do Azure Well-Architected Framework, Overview of the Cost Optimization pillar.
Governação
Quando vários locatários compartilham a mesma infraestrutura, o gerenciamento da privacidade de dados, da conformidade e dos requisitos normativos pode se tornar complicado. Você precisa implementar fortes medidas de segurança e políticas de governança de dados. Os clusters AKS compartilhados apresentam um risco maior de violações de dados, acesso não autorizado e não conformidade com os regulamentos de proteção de dados. Cada locatário pode ter requisitos exclusivos de governança de dados e políticas de conformidade, o que dificulta a garantia da segurança e da privacidade dos dados.
Microsoft Defender for Containers é uma solução de segurança de contêiner nativa da nuvem que fornece recursos de deteção e proteção contra ameaças para ambientes Kubernetes. Usando o Defender for Containers, você pode aprimorar sua postura de governança e conformidade de dados ao hospedar vários locatários em um cluster Kubernetes. Use o Defender for Containers para ajudar a proteger dados confidenciais, detetar e responder a ameaças analisando o comportamento do contêiner e o tráfego de rede e atender aos requisitos regulamentares. Ele fornece recursos de auditoria, gerenciamento de logs e geração de relatórios para demonstrar conformidade aos reguladores e auditores.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Paolo Salvatori - Brasil | Engenheiro de Clientes Principal
Outros contribuidores:
- Bohdan Cherchyk | Engenheiro de Clientes Sênior
- John Downs | Engenheiro de Software Principal
- Chade Kittel | Engenheiro de Software Principal
- Arsen Vladimirskiy | Engenheiro de Clientes Principal