Configurar as políticas de cota de recursos do AKS usando o Azure Policy para Kubernetes
O Azure Policy ajuda você a impor padrões e a avaliar a conformidade em escala para seu ambiente de nuvem. É uma boa prática que as empresas implementam regras de negócio para definir como os funcionários deverão usar software, hardware e outros recursos da empresa na organização. Em geral, essas regras de negócio são descritas por meio de políticas que são colocadas em vigor, impostas e examinadas conforme definido em cada política. Uma política ajuda uma organização a atender a requisitos legais e de governança, além de implementar melhores práticas e estabelecer convenções organizacionais.
O AKS (Serviço de Kubernetes do Azure) permite orquestrar os aplicativos nativos de nuvem com eficiência. Essa facilidade permitiu que mais equipes de desenvolvimento da sua empresa adotassem o AKS como plataforma de desenvolvimento. Você percebe que precisa impor regras de negócio para gerenciar como as equipes usam o AKS a fim de garantir uma abordagem econômica para a criação de cargas de trabalho. Você pode usar o Azure Policy para aplicar essa mesma ideia ao modo como os recursos do Azure baseados em nuvem são usados.
Antes de discutirmos como usar o Azure Policy para o Kubernetes, precisamos abordar mais alguns conceitos que habilitam esse recurso no Kubernetes.
O que é um controlador de admissão do Kubernetes?
Um controlador de admissão é um plug-in do Kubernetes que intercepta as solicitações autenticadas e autorizadas para a API do Kubernetes antes da persistência do objeto do Kubernetes solicitado. Por exemplo, suponha que você implante uma nova carga de trabalho e essa implantação inclua uma solicitação de pod com requisitos específicos de memória. O controlador de admissão intercepta a solicitação de implantação e precisa autorizá-la antes que ela seja persistida no cluster.
Considere um controlador de admissão como um software que controla e impõe a maneira como o cluster é usado e projetado. Ele limita as solicitações para criar, excluir e modificar objetos do Kubernetes.
O que é um webhook do controlador de admissão?
O webhook do controlador de admissão é uma função de retorno de chamada HTTP que recebe solicitações de admissão e executa ações com base nessas solicitações. Os controladores de admissão existem como um plug-in de admissão compilado ou como uma extensão implantada que é executada como um webhook configurado em runtime.
Há dois tipos de webhooks de admissão disponíveis: o webhook de validação e o webhook de mutação. Um webhook de mutação é invocado primeiro e pode alterar e aplicar padrões nos objetos enviados ao servidor de API. Um webhook de validação valida valores de objeto e pode rejeitar solicitações.
O que é o OPA (Agente de Política Aberta)?
O OPA (Agente de Política Aberta) é um mecanismo de política de uso geral de software livre que fornece uma linguagem declarativa de alto nível para criação de políticas. Essas políticas permitem que você defina regras que supervisionam como o sistema deve se comportar.
O que é o Gatekeeper do OPA?
O Gatekeeper do OPA é um webhook de software livre de validação do controlador de admissão do Kubernetes que impõe políticas baseadas em CRD (Definição Personalizada de Recurso) usando o Agente de Política Aberta.
O objetivo do Gatekeeper do OPA é permitir que você personalize as políticas de admissão por meio de configuração em vez de regras de política embutidas em código para serviços. Ele também proporciona uma visão completa do cluster para identificar recursos que violam a política.
Você pode usar o Gatekeeper do OPA para definir políticas para toda a organização. Por exemplo, você pode exigir que:
Os limites máximos de recursos (como os limites de memória e de CPU) sejam impostos para todos os pods configurados.
A implantação de imagens seja permitida somente de repositórios aprovados.
Os rótulos de todos os namespaces de um cluster especifiquem um ponto de contato para cada namespace.
Os serviços de cluster tenham seletores exclusivos em âmbito global.
A versão atual do Gatekeeper do OPA (versão 3) é compatível com o Serviço de Kubernetes do Azure.
Azure Policy para AKS
O Azure Policy estende o OPA Gatekeeper versão 3 e se integra ao AKS por meio de políticas internas. Essas políticas aplicam imposições e proteções em escala ao cluster de maneira centralizada e consistente.
As equipes de desenvolvimento da sua empresa desejam otimizar o desenvolvimento e introduzir ferramentas de desenvolvimento, como o DevSpaces, para simplificar o fluxo de trabalho de desenvolvimento do Kubernetes. Você deseja ter certeza de que os membros da equipe respeitem os limites de recursos específicos para os respectivos projetos. Você decide colocar uma política em vigor que define os recursos de computação, os recursos de armazenamento e a contagem de objetos permitidos nos namespaces de desenvolvimento.
Para configurar os limites de recursos, você pode aplicar cotas de recursos no nível do namespace e monitorar o uso de recursos para ajustar as cotas de política. Use essa estratégia para reservar e limitar recursos para toda a equipe de desenvolvimento.
Como habilitar o complemento do Azure Policy para AKS
Há algumas etapas necessárias para registrar o recurso Complemento do Azure Policy para AKS.
Cuidado
Assim como os nós spot, o Complemento do Azure Policy para AKS é a versão prévia de um recurso. Depois que você habilitar a versão prévia de alguns recursos no Azure, os padrões poderão ser usados para todos os clusters do AKS criados na assinatura. Teste a versão prévia dos recursos em assinaturas que não sejam de produção a fim de evitar efeitos colaterais imprevistos nas implantações de produção.
Registre dois provedores de recursos usando o comando
az provider register
:Microsoft.ContainerService: Esse provedor de recursos é o mesmo usado anteriormente para registrar o recurso spotpoolpreview.
Microsoft.PolicyInsights: Esse provedor de recursos é compatível com ações como consultar informações sobre eventos de política. Ele também fornece a capacidade de consultar, criar ou atualizar e excluir a correção de política.
Aqui está um exemplo dos dois comandos de registro:
az provider register --namespace Microsoft.ContainerService az provider register --namespace Microsoft.PolicyInsights
Registre o recurso
AKS-AzurePolicyAutoApprove
com o provedor de recursosMicrosoft. ContainerService
. Aqui está um exemplo do comando:az feature register --namespace Microsoft.ContainerService --name AKS-AzurePolicyAutoApprove
Depois de confirmar o registro bem-sucedido do recurso, execute o comando
az provider register
com o parâmetro--namespace
para propagar o novo registro do recurso. Aqui está um exemplo do comando:az provider register -n Microsoft.ContainerService
Instale a extensão da versão prévia da CLI do Azure e habilite o Complemento do Azure Policy. Use o comando
az extensions add
e, em seguida, habilite o complementoazure-policy
usando o comandoaz aks enable-addons
.Aqui está um exemplo dos dois comandos:
az extension add --name aks-preview az aks enable-addons \ --addons azure-policy \ --name myAKSCluster \ --resource-group myResourceGroup
A ativação do complemento agendará as cargas de trabalho em dois namespaces do cluster. O primeiro namespace é kube-system, no qual você encontrará
azure-policy
eazure-policy-webhook
. O segundo namespace é gatekeeper-system, no qual você encontrarágatekeeper-controller-manager
. Essas cargas de trabalho são responsáveis por avaliar solicitações enviadas ao painel de controle do AKS. Com base nas políticas configuradas, o webhook da política permitirá ou negará as solicitações.
Atribuir uma definição de política interna
Gerencie as políticas do ambiente do Azure por meio do dashboard de conformidade de política do Azure. O dashboard permite fazer uma busca detalhada até um nível de detalhe por recurso e por política. Ele ajuda a colocar seus recursos em conformidade empregando a correção em massa de recursos existentes e a correção automática de novos recursos.
Para cada política, as seguintes informações de visão geral são listadas:
Item | Descrição |
---|---|
Nome | O nome da política. Por exemplo, [Versão prévia]: verificar se os limites de recursos de memória e de CPU do contêiner não excedem os limites especificados no cluster do Kubernetes. |
Escopo | O grupo de recursos de assinatura ao qual essa política se aplica. Por exemplo, "Visual Studio Enterprise/rg-akscostsaving". |
Estado de conformidade | O status das políticas atribuídas. O valor pode ser Em Conformidade, Conflitante, Não Iniciado ou Não Registrado. |
Conformidade do recurso | O percentual de recursos que está em conformidade com a política. Esse cálculo leva em conta os recursos em conformidade, sem conformidade e conflitantes. |
Recursos sem conformidade | Número de recursos exclusivos que violam uma ou mais regras da política. |
Políticas sem conformidade | O número de políticas sem conformidade. |
Aqui, você faz uma busca detalhada por recurso e por política, bem como por eventos disparados. Por exemplo, você pode examinar os detalhes de uma implantação de carga de trabalho que é negada.
Como atribuir políticas
As Políticas do Azure são atribuídas. Para atribuir uma política, selecione a opção Atribuições na seção Criação do painel de navegação do Azure Policy.
Você pode atribuir políticas do Azure de duas maneiras: como um grupo de políticas, chamado de iniciativa, ou como uma política individual.
Atribuição de iniciativa
Uma atribuição de iniciativa é uma coleção de definições de política do Azure agrupadas para atender a uma finalidade ou uma meta específica. Por exemplo, a meta poderia ser aplicar o Padrão de Segurança de Dados do Setor de Cartão de Pagamento em todos os recursos.
Atribuição de política
Uma atribuição de política atribui apenas uma política, por exemplo: não permitir contêineres privilegiados no cluster do Kubernetes.
Como atribuir uma política
Cada política é definida por meio de uma série de etapas de configuração. O volume de informações capturadas depende do tipo de política selecionado.
Por exemplo, para limitar a implantação de recursos pelos desenvolvedores no ambiente de nuvem da empresa, você pode atribuir uma das políticas internas do Azure ao Serviço de Kubernetes do Azure. O nome da política é Verificar se os limites de recursos de memória e de CPU do contêiner não excedem os limites especificados no cluster do Kubernetes.
A política exige que você defina o limite nos recursos permitidos solicitados por solicitações de implantação.
Vejamos as opções configuradas para atribuir uma política.
Informação básicas da política
A primeira etapa exige que você selecione e insira informações básicas que definam a nova política. Por exemplo, essas informações podem ser a política e o escopo de recurso que a política abrange. Esta tabela mostra cada item que será configurado:
Item | Descrição |
---|---|
Escopo | O escopo determina em quais recursos (ou grupos de recursos) a atribuição da política será imposta. Esse valor se baseia em uma assinatura ou em um grupo de gerenciamento. Você pode excluir recursos da seleção em um nível inferior ao nível do escopo. |
Definição de Política | A política que você deseja aplicar. Escolha uma entre várias opções de políticas internas. |
Nome da atribuição | O nome pelo qual a política atribuída será identificada. |
Descrição | Uma descrição em texto livre que descreve a política. |
Imposição de política | Essa opção alterna entre Habilitada e Desabilitada. Se ela estiver Desabilitada, a política não será aplicada e as solicitações não serão negadas por não conformidade. |
Atribuída por | Um valor de texto livre que usa como padrão o usuário registrado. Esse valor pode ser alterado. |
Parâmetros da política
As políticas exigem que você configure as regras de negócio que se aplicam a cada política específica. Nem todas as políticas têm as mesmas regras de negócio. É por isso que cada política tem parâmetros diferentes.
Por exemplo, a política Verificar se os limites de recursos de memória e de CPU do contêiner não excedem os limites especificados no cluster do Kubernetes exige a definição de três parâmetros:
- O máximo de unidades de CPU permitidas para um contêiner.
- O máximo de bytes de memória permitidos para um contêiner.
- Uma lista de namespaces do Kubernetes a serem excluídos da política.
Compare essa política com a política O Aplicativo Web só deve ser acessível via HTTPS, que não requer a configuração de nenhum parâmetro personalizado.
Todas as políticas têm uma configuração Efeito. Essa configuração habilita ou desabilita a execução da política. Assim como ocorre com os parâmetros, as políticas também podem ter diferentes opções de Efeitos.
Por exemplo, para a política de gerenciamento de recursos, você pode selecionar audit, deny ou disable como o valor do Efeito. Para a política de aplicativo Web, você só pode selecionar audit ou disable.
Esta tabela lista todos os efeitos atualmente compatíveis com as definições de política:
Efeito | Descrição |
---|---|
Append | Adiciona mais campos ao recurso solicitado. |
Audit | Cria um evento de aviso no log de atividades. |
AuditIfNotExists | Habilita a auditoria dos recursos relacionados ao recurso que corresponde à condição. |
Deny | Impede a aprovação de uma solicitação de recurso que não corresponde aos padrões definidos por meio de uma definição de política reprovando a solicitação. |
DeployIfNotExists | Executa uma implantação de modelo quando a condição é atendida. |
Disabled | Útil para situações de teste ou para quando a definição de política tiver parametrizado o efeito e você quiser desabilitar apenas uma atribuição. |
Modify | Adiciona, atualiza ou remove marcas de um recurso durante a criação ou a atualização. |
Correção de política
A etapa final é considerar a correção da política. Quando você atribui políticas, é possível que os recursos já existam e sejam afetados pela nova política. Por padrão, somente os recursos recém-criados são afetados pela nova política. Você pode atualizar os recursos existentes usando uma tarefa de correção após atribuir a política. As tarefas de correção serão diferentes dependendo do tipo de política aplicado.
No próximo exercício, vamos atribuir a política Verificar se os limites de recursos de memória e de CPU do contêiner não excedem os limites especificados no cluster do Kubernetes.
Precisa de ajuda? Confira nosso guia de solução de problemas ou forneça comentários específicos relatando um problema.