Considerações sobre o isolamento em sandbox de pods no Azure Kubernetes Service (AKS)

O sandboxing pod no Azure Kubernetes Service (AKS) inclui considerações de gestão de recursos, memória, CPU e segurança.

Gestão de recursos no sandboxing de pods

Reveja estas considerações ao especificar recursos para uma implementação, especialmente para cargas de trabalho grandes ou sensíveis a recursos.

Componentes do kata

Uma implementaçã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. Esta divisão entre host e guest determina como o uso de memória e CPU é contabilizado.

Gestão de memória no sandboxing Pod

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

Tamanho da memória da VM pod

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

O limite de memória do pod Kubernetes determina o tamanho da memória da VM do pod. Mude o limite de memória do pod para alterar o tamanho da memória da VM do pod.

RuntimeClass a sobrecarga de memória normalmente aumenta com a dimensão da memória da VM do pod.

RuntimeClass Sobrecarga de memória

As cargas de trabalho de pods em sandbox incluem um Kata RuntimeClass predefinido (kata-vm-isolation) que inclui valores predefinidos de sobrecarga de recursos. Para um controlo mais granular das quotas de recursos, configure um personalizado RuntimeClass com sobrecargas de recursos específicas. O limite de memória pod dimensiona a memória do lado dos convidados disponível para a VM pod. RuntimeClass overhead reserva capacidade do nó para componentes Kata do lado do host e não precisa de ter em conta o consumo esperado de memória dos componentes convidados.

Podes criar um runtime especializado e especificar a sobrecarga de memória através do overhead campo no teu RuntimeClass manifesto. Por exemplo, o seguinte manifesto cria um tempo de execução para cargas de trabalho que se espera terão menor consumo de recursos:

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

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

Antes de usares um personalizado RuntimeClass, executa kubectl get runtimeclass e verifica se o seu handler é suportado no teu cluster AKS.

Não é obrigatório especificar a sobrecarga, mas é recomendável fazê-lo se pretender um controlo mais preciso sobre os recursos reservados para as suas cargas de trabalho. Se usares o padrão kata-vm-isolationRuntimeClass e não especificares um limite de memória pod, o tamanho da VM pod é de 512Mi. O padrão RuntimeClass adiciona aproximadamente 88Mi de sobrecarga de memória para os componentes do host, o que resulta num limite de pod cgroup de 600Mi.

Cargas de trabalho do utilizador

A sua carga de trabalho do Kata pode usar o tamanho de memória configurado da VM do pod, menos a memória que os componentes da máquina virtual convidada, como o agente Kata e o kernel da máquina virtual convidada, consomem.

Para estimar a memória, estes componentes utilizam:

1. Ligue-se à VM do pod (através de kubectl exec ou kubectl debug para abrir um terminal dentro do pod).
2. Execute o comando free.
3. Inspecionar a coluna usada para estimar a memória que o kernel convidado e o agente Kata consomem.

Cgrupos de memória

Quando o Kubernetes agenda um pod Kata, o kubelet atribui o pod a uma memória cgroup. O cgroup aplica as solicitações e os limites de memória ao pod, permitindo definir os recursos disponíveis para o pod.

A memória cgroup tem dois campos importantes:

A qualquer momento, se o valor de memory.current exceder o de memory.max, o kernel pode desencadear um OOMKill no pod se for detetada pressão de memória.

Valores de utilização de referência

Use os seguintes valores como exemplos típicos de utilização de memória. Memórias pod VM com menos de 128 MiB não são suportadas.

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

Boas práticas de gestão de memória

• Especifique os tamanhos de memória das VMs de pods ao definir limits.memory nos seus manifestos e defina quotas de recursos adequadas para todas as implementações.
  • Utilize um pedido de memória do pod não nulo para reservar capacidade no nó para a VM do pod antes de a VM arrancar. A solicitação deve ter em conta a VM do pod e os contentores que nela são executados.
  • Use sobrecarga de memória não nula RuntimeClass para contabilizar a capacidade do nó que os componentes do host Kata consomem.
• Para cargas de trabalho intensivas em recursos, defina um limite de memória pod que forneça memória suficiente para a carga de trabalho e componentes convidados.
• Defina uma sobrecarga de memória RuntimeClass suficientemente elevada para os componentes do host do Kata, sem reservar uma capacidade do nó substancialmente superior à de que necessitam.

Gestão de CPU no sandboxing Pod

Atribua recursos de CPU às cargas de trabalho do Kata, definindo os limites de CPU do pod e a sobrecarga RuntimeClass. Sem um limite de CPU, os componentes do host Kata podem usar qualquer capacidade de CPU disponível no nó.

Reserva de CPU

Defina um ou ambos os seguintes campos para reservar a capacidade da CPU para as suas cargas de trabalho Kata:

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

Quando pelo menos um dos dois valores é especificado, o plano de controlo reserva o número especificado de CPUs no nó para a sua carga de trabalho. Outros pods no mesmo nó não conseguem aceder a esta capacidade reservada.

Limite de CPU do pod

Declara o limite de CPU do pod no manifesto da tua aplicação. O limite controla quantos CPUs os contentores na VM pod associada podem usar.

Se não declarar um limite de CPU do pod, o AKS atribui um vCPU à VM do pod quando o nó tem capacidade suficiente. Os componentes do host Kata não têm limite de consumo de CPU.

RuntimeClass Sobrecarga da CPU

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

Podes especificar a overhead da CPU através do overhead campo no teu RuntimeClass manifesto. Por exemplo:

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

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

Melhores práticas de gestão de CPU

• Se o seu nó normalmente tiver muita capacidade de CPU livre, estas reservas podem ser desnecessárias.
• Se os seus nós normalmente atingem o limite com o consumo de CPU, então uma reserva não nula garante que os seus pods podem ser executados de maneira mais confiável.
  • Os pedidos de CPU de um pod ajudam o scheduler do Kubernetes a reservar capacidade suficiente nos nós para uma carga de trabalho. A capacidade reservada para uma carga de trabalho específica não está disponível para outras cargas no nó.
• Especifique pedidos de CPU que a sua infraestrutura possa acomodar. Se a sua capacidade disponível estiver próxima de zero, ou se o seu pedido for demasiado grande, as suas cargas de trabalho podem não começar.
• Alinha os teus pedidos de CPU com os teus limites de CPU. Os pedidos afetam o agendamento do Kubernetes, mas o shim Kata não os usa para dimensionar a VM do pod. O limite de CPU determina a alocação de vCPU da VM pod. Se não for declarado limite de CPU, a VM pod recebe um vCPU, e os componentes do host Kata não têm limite de consumo de CPU.

Exemplos de declarações

Considerações de segurança para o isolamento em sandbox do Pod

O sandboxing pod isola as cargas de trabalho de outras cargas e do anfitrião, mas deve ainda assim considerar os seguintes riscos de segurança.

Pods privilegiados

Algumas cargas de trabalho exigem pods privilegiados. Podes criar pods privilegiados, mas os dispositivos anfitriões não estão ligados aos pods.

Usar containers privilegiados dá acesso root na VM convidada, mas os containers permanecem isolados do host.

Usa pods privilegiados apenas quando necessário, mesmo com sandboxing de pods. Permitir que apenas utilizadores de confiança gerenciem pods privilegiados.

Volumes de armazenamento do caminho do host

Montar volumes hostPath em pods Kata expõe diretamente ao contentor parte do sistema de ficheiros do anfitrião e pode enfraquecer o isolamento do pod em sandbox. Aplique as diretrizes de segurança upstream hostPath às cargas de trabalho em sandbox do Pod.

Os ficheiros abaixo /dev são uma exceção porque são montados no contentor a partir do sistema convidado em vez do sistema anfitrião. Este comportamento mantém o isolamento dos pods quando uma carga de trabalho requer este caminho.

Bloquear volumes hostPath com a Azure Policy

O Azure Policy proporciona imposição centralizada e consistente e salvaguardas para os componentes do seu cluster.

O AKS fornece definições de políticas incorporadas que aplicam as melhores práticas. Atribua a política os pods do cluster do Kubernetes só devem utilizar tipos de volume permitidos com o efeito Deny e exclua hostPath dos tipos de volume permitidos para bloquear pods que tentem montar volumes hostPath.

Próximos passos

Aprenda a implementar sandboxing Pod no AKS.