Considerações sobre o isolamento de pods no AKS (Serviço de Kubernetes do Azure)

O isolamento de pods no AKS (Serviço de Kubernetes do Azure) envolve considerações sobre gerenciamento de recursos, gerenciamento de memória, gerenciamento de CPU e segurança.

Gerenciamento de recursos na área restrita do Pod

Examine essas considerações ao especificar recursos para uma implantação, especialmente para cargas de trabalho grandes ou sensíveis a recursos.

Componentes Kata

Uma implantação do Kata inclui componentes que são executados no nó do AKS e componentes que são executados dentro da máquina virtual (VM) do pod. Essa divisão de host e convidado determina como a memória e o uso da CPU são contabilizados.

Gerenciamento de memória no pod sandboxing

Defina o limite de memória da VM do pod alto o suficiente para suportar sua carga de trabalho e os componentes convidados do Kata, sem alocar memória não utilizada.

Tamanho da memória da VM do pod

Cada VM do pod recebe memória para a carga de trabalho e todos os componentes convidados do Kata. Inclua memória além do consumo de carga de trabalho esperado para componentes convidados, como o agente Kata e o kernel de VM. Consulte os valores de uso de referência para valores de memória típicos.

O limite de memória do pod kubernetes determina o tamanho da memória da VM do pod. Altere o limite de memória do pod para alterar o tamanho da memória da VM associada ao pod.

RuntimeClass A sobrecarga de memória geralmente aumenta com o tamanho da memória da VM do pod.

RuntimeClass sobrecarga de memória

As cargas de trabalho de sandbox do pod vêm com um Kata RuntimeClass (kata-vm-isolation) padrão que inclui valores de sobrecarga de recursos padrão. Para um controle mais detalhado das cotas de recursos, configure um RuntimeClass personalizado com sobrecargas específicas de recursos. O limite de memória do pod dimensiona a memória do convidado disponível para a VM do pod. RuntimeClass a sobrecarga reserva a capacidade do nó para componentes do Kata no lado do host e não precisa levar em conta o consumo de memória esperado dos componentes convidados.

Você pode criar um runtime especializado e especificar a sobrecarga de memória por meio do overhead campo em seu RuntimeClass manifesto. Por exemplo, o manifesto a seguir cria um runtime para cargas de trabalho que devem ter menor consumo de recursos:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

O valor memory: "120Mi" adiciona 120Mi de sobrecarga fixa do pod quando o Kubernetes agenda o pod e dimensiona seu cgroup. O valor handler: kata deve corresponder ao manipulador de runtime Kata configurado nos nós do AKS.

Antes de usar um personalizado RuntimeClass, execute kubectl get runtimeclass e verifique se o manipulador tem suporte no cluster do AKS.

Não é necessário especificar a sobrecarga, mas é recomendável se você quiser um controle mais fino sobre os recursos reservados para suas cargas de trabalho. Se você usar o valor padrão kata-vm-isolationRuntimeClass e não especificar um limite de memória para o pod, o tamanho da VM do pod será definido por padrão como 512Mi. A configuração padrão RuntimeClass adiciona aproximadamente 88Mi de sobrecarga de memória dos componentes do host, o que resulta em um limite de 600Mi para o pod cgroup.

Cargas de trabalho do usuário

Sua carga de trabalho do Kata pode usar o tamanho de memória da VM do pod configurado, menos a memória consumida pelos componentes do convidado, como o agente do Kata e o kernel da VM convidada.

Para estimar a memória que esses componentes usam:

1. Conecte-se à VM do pod (por meio de kubectl exec ou kubectl debug para abrir um shell dentro do pod).
2. Execute o comando free.
3. Inspecione a coluna usada para estimar a memória que o kernel convidado e o agente Kata consomem.

Grupos de memória

Quando o Kubernetes agenda um pod Kata, o kubelet atribui o pod a uma memória cgroup. O cgroup impõe as requisições e os limites de memória do pod para que você possa definir os recursos disponíveis ao pod.

A memória cgroup tem dois campos importantes:

A qualquer momento, se o memory.current valor exceder o de memory.max, o kernel poderá disparar um OOMKill no pod se a pressão de memória for detectada.

Valores de uso de referência

Use os valores a seguir como exemplos típicos de uso de memória. Não há suporte para tamanhos de memória de Pod VM inferiores a 128 MiB.

Como ler esta tabela: memory.current inclui a alocação de memória da VM do pod e o uso atual dos componentes do host. O kubelet calcula memory.max com base no limite de memória do pod mais a sobrecarga de RuntimeClass. A diferença entre esses valores indica a capacidade disponível para uso extra do componente de host.

Práticas recomendadas de gerenciamento de memória

• Especifique os tamanhos de memória da VM do pod definindo limits.memory em seus manifestos e defina cotas de recursos adequadas para todas as implantações.
  • Use uma solicitação de memória do pod maior que zero para reservar capacidade no nó para a VM do pod antes de a VM iniciar. A solicitação deve considerar a VM do pod e os contêineres executados nela.
  • Use a sobrecarga de memória não nula RuntimeClass para levar em conta a capacidade do nó consumida pelos componentes do host Kata.
• Para cargas de trabalho com uso intensivo de recursos, defina um limite de memória de pod que fornece memória suficiente para a carga de trabalho e os componentes convidados.
• Defina a sobrecarga de memória de RuntimeClass como alta o suficiente para os componentes do host do Kata, sem reservar substancialmente mais capacidade do nó do que eles exigem.

Gerenciamento de CPU no isolamento de pods

Aloque recursos de CPU para cargas de trabalho Kata definindo limites de CPU para pods e sobrecarga RuntimeClass. Sem um limite de CPU, os componentes do host Kata podem usar qualquer capacidade de CPU disponível no nó.

Reservando a CPU

Defina um ou ambos os campos a seguir para reservar a capacidade da CPU para suas cargas de trabalho kata:

• A sobrecarga da RuntimeClass CPU
• O limite da CPU do pod

Quando pelo menos um dos dois valores é especificado, o plano de controle reserva o número especificado de CPUs no nó para sua carga de trabalho. Outros pods no mesmo nó não podem acessar essa capacidade reservada.

Limite da CPU do pod

Declare o limite da CPU do pod no manifesto do aplicativo. O limite controla quantas CPUs os contêineres na VM de pod associada podem usar.

Se você não declarar um limite de CPU para o pod, o AKS alocará uma vCPU para a VM do pod quando o nó tiver capacidade suficiente. Os componentes do host Kata não têm limite de consumo de CPU.

RuntimeClass Sobrecarga de CPU

Especifique a RuntimeClass sobrecarga para reservar a capacidade do nó para os componentes do host Kata antes de implantar uma carga de trabalho.

Você pode especificar a sobrecarga da CPU por meio do overhead campo em seu RuntimeClass manifesto. Por exemplo:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

O valor cpu: "250m" adiciona 0,25 vCPU de sobrecarga fixa do pod quando o Kubernetes agenda o pod e dimensiona seu cgroup. Ajuste esse valor com base no consumo de CPU esperado dos componentes do host Kata.

Práticas recomendadas de gerenciamento de CPU

• Se o nó normalmente tiver muita capacidade de CPU disponível, essas reservas podem ser desnecessárias.
• Se os nós normalmente forem executados até o limite com o consumo de CPU, uma reserva maior que zero garantirá que seus pods possam ser executados de forma mais confiável.
  • As requisições de CPU de pods ajudam o agendador do Kubernetes a reservar capacidade suficiente no nó para a carga de trabalho. A capacidade reservada para uma carga de trabalho específica não está disponível para outras cargas de trabalho no nó.
• Especifique as solicitações de CPU que sua infraestrutura pode acomodar. Se a capacidade disponível estiver próxima de zero ou sua solicitação for muito grande, suas cargas de trabalho poderão falhar ao iniciar.
• Alinhe suas solicitações de CPU com seus limites de CPU. As requisições afetam o agendamento do Kubernetes, mas o shim do Kata não as usa para definir o dimensionamento da VM do pod. O limite da CPU determina a alocação de vCPU da VM do pod. Se nenhum limite de CPU for declarado, a VM do pod receberá uma vCPU e os componentes do host Kata não terão limite de consumo de CPU.

Declarações de exemplo

Considerações de segurança para o isolamento de pods

A área restrita do pod isola cargas de trabalho de outras cargas de trabalho e do host, mas você ainda deve considerar os seguintes riscos de segurança.

Pods privilegiados

Algumas cargas de trabalho exigem pods privilegiados. Você pode criar pods privilegiados, mas os dispositivos do host não estão vinculados aos pods.

O uso de contêineres privilegiados fornece acesso raiz na VM convidada, mas os contêineres permanecem isolados do host.

Use pods privilegiados somente quando necessário, mesmo com o isolamento de pods. Permitir que somente usuários confiáveis gerenciem pods privilegiados.

Volumes de armazenamento de caminho do host

Montar volumes hostPath em pods Kata expõe parte do sistema de arquivos do host diretamente ao contêiner e pode enfraquecer o isolamento do sandbox do pod. Aplique as diretrizes de segurança upstream hostPath às cargas de trabalho de área restrita do Pod.

Os arquivos embaixo /dev são uma exceção porque são montados no contêiner do sistema convidado em vez do sistema de host. Esse comportamento mantém o isolamento do pod quando uma carga de trabalho requer esse caminho.

Bloqueie volumes hostPath com a Azure Policy

Azure Policy fornece proteções e imposição centralizadas e consistentes para seus componentes de cluster.

O AKS fornece definições de política internas que impõem práticas recomendadas. Atribua a política Os pods do cluster Kubernetes devem usar apenas os tipos de volume permitidos com o efeito Deny e exclua hostPath dos tipos de volume permitidos para bloquear pods que tentam montar volumes hostPath.

Próximas etapas

Saiba como implantar o pod sandboxing no AKS.